HTTP w00tw00t攻撃への対処
私はApacheを備えたサーバーを持っていて、これによって多くの攻撃を受けるので、最近mod_security2をインストールしました：
私のApacheバージョンはApache v2.2.3で、mod_security2.cを使用しています
これはエラーログのエントリでした：
[Wed Mar 24 02:35:41 2010] [error]
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Wed Mar 24 02:47:31 2010] [error]
[client 202.75.211.90] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Wed Mar 24 02:47:49 2010] [error]
[client 95.228.153.177] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Wed Mar 24 02:48:03 2010] [error]
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
Access_logのエラーは次のとおりです。
202.75.211.90 - -
[29/Mar/2010:10:43:15 +0200]
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - -
[29/Mar/2010:11:40:41 +0200]
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - -
[29/Mar/2010:12:37:19 +0200]
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
私はこのようにmod_security2を設定してみました：
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecFilterSelective REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"
Mod_security2で重要なのは、SecFilterSelectiveを使用できないことです。エラーが発生します。代わりに、次のようなルールを使用します。
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecRule REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"
これでもうまくいきません。どうすればいいか分からない。誰かアドバイスはありますか？
アップデート1
Mod_securityを使用してこの問題を解決できる人はいないようです。これまでのところ、ip-tablesを使用することはこれを行うための最良のオプションのように思われますが、IPは1日に数回サーバーの変更を行うため、ファイルは非常に大きくなると思います。
私は他に2つの解決策を考え出しましたが、誰かがそれらが良いかどうかについてコメントすることはできますか？.
私の頭に浮かぶ最初の解決策は、これらの攻撃をApacheエラーログから除外することです。これにより、他の緊急のエラーが発生し、長いログを介して吐き出す必要がないため、他の緊急のエラーを見つけやすくなります。
2番目のオプションは私が考えるより優れており、それは正しい方法で送信されないホストをブロックしています。この例では、w00tw00t攻撃はホスト名なしで送信されるため、正しい形式でないホストをブロックできると思います。
アップデート2
答えを調べた後、私は以下の結論に達しました。
Apacheのカスタムロギングを使用すると、不要なリソースが消費されます。本当に問題がある場合は、何も欠落していない完全なログを確認することをお勧めします。
ヒットを無視して、エラーログを分析するより良い方法に集中することをお勧めします。ログにフィルターを使用することは、このための良いアプローチです。
主題に関する最終的な考え
上記の攻撃は、少なくとも最新のシステムを使用している場合はマシンに到達しないため、基本的に心配はありません。
エラーログとアクセスログの両方が非常に大きくなるため、しばらくしてからすべての偽の攻撃を実際の攻撃から除外するのは難しい場合があります。
これが何らかの形で発生するのを防ぐと、リソースが消費されます。重要でないものにリソースを浪費しないことをお勧めします。
私が現在使用しているソリューションはLinux logwatchです。それは私にログの要約を送り、それらはフィルタリングされ、グループ化されます。このようにして、重要なものから重要でないものを簡単に分離できます。
助けてくれてありがとう、そしてこの投稿が他の誰かにも役立つことを願っています。
エラーログから、リクエストのHost：部分なしでHTTP/1.1リクエストが送信されています。私が読んだことから、Apacheはmod_securityに渡す前に、このリクエストに対して400（bad request）エラーで応答します。そのため、ルールが処理されるようには見えません。 （Apacheはmod_securityに引き渡す必要がある前にそれを扱います）
自分で試してください：
telnetホスト名80 GET /blahblahblah.html HTTP/1.1（入力） （入力）
400エラーが発生し、ログに同じエラーが表示されるはずです。これは悪い要求であり、Apacheは正しい答えを出しています。
適切なリクエストは次のようになります。
GET /blahblahblah.html HTTP/1.1 ホスト：blah.com
この問題の回避策は、Apacheがリクエストをリクエストハンドラーに渡すために、mod_uniqueidにパッチを適用して、リクエストが失敗した場合でも一意のIDを生成することです。次のURLはこの回避策に関するディスカッションであり、使用できるmod_uniqueidのパッチが含まれています。 http://marc.info/?l=mod-security-users&m=123300133603876&w=2
他の解決策が見つからず、実際に解決策が必要かどうか疑問に思いました。
IPのフィルタリングは良い考えではありません、imho。知っている文字列をフィルタリングしてみませんか？
というのは：
iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP
また、ログファイルにこれらのタイプのメッセージが表示されるようになりました。これらのタイプの攻撃を防ぐ1つの方法は、fail2ban（ http://www.fail2ban.org/ ）をセットアップし、特定のフィルターをセットアップして、iptablesルールでこれらのIPアドレスをブラックリストに登録することです。
これらのメッセージの作成に関連するIPアドレスをブロックするフィルターの例を次に示します。
[2011年8月16日02:35:23] [エラー] [クライアント]ファイルが存在しません：/var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === Apache w00t w00tメッセージの刑務所-正規表現とフィルター===刑務所
[Apache-wootwoot]
enabled = true
filter = Apache-wootwoot
action = iptables[name=HTTP, port="80,443", protocol=tcp]
logpath = /var/log/Apache2/error.log
maxretry = 1
bantime = 864000
findtime = 3600
フィルタ
# Fail2Ban configuration file
#
# Author: Jackie Craig Sparks
#
# $Revision: 728 $
#
[Definition]
#Woot woot messages
failregex = ^\[\w{1,3} \w{1,3} \d{1,2} \d{1,2}:\d{1,2}:\d{1,2} \d{1,4}] \[error] \[client 195.140.144.30] File does not exist: \/.{1,20}\/(w00tw00t|wootwoot|WootWoot|WooTWooT).{1,250}
ignoreregex =
w00tw00t.at.blackhats.romanian.anti-secはハッキングの試みであり、なりすましIPを使用するため、VisualRouteなどのルックアップは、そのときに出向されているIPに従って中国、ポーランド、デンマークなどを報告します。したがって、拒否IPまたは解決可能なホスト名を設定することは、1時間以内に変更されるため、ほとんど不可能です。
Mod_securityが機能しない理由は、Apacheがリクエスト自体を解析できなかったためであり、仕様外です。あなたがここで問題を抱えているかどうかはわかりません-Apacheはネット上で起こっている奇妙なたわごとをログに記録しています。それがログに記録されない場合、あなたはそれが起こっていることにさえ気付かないでしょう。リクエストのログに必要なリソースはおそらく最小限です。誰かがログをいっぱいにしているのはイライラすることですが、本当に必要な場合にのみログを無効にすると、さらにイライラします。誰かがあなたのウェブサーバーに侵入し、彼らが侵入した方法を示すためにログが必要であるように。
1つの解決策は、syslogを介してErrorLoggingをセットアップし、rsyslogまたはsyslog-ngを使用して、w00tw00tに関するこれらのRFC違反を具体的にフィルタリングして破棄することです。または、単にそれらを別のログファイルにフィルター処理して、メインのErrorLogを読みやすくすることもできます。 Rsyslogはこの点で非常に強力で柔軟性があります。
したがって、httpd.confでは次のようにすることができます。
ErrorLog syslog:user
次に、rsyslog.confに次のように記述します。
:msg, contains, "w00tw00t.at.ISC.SANS.DFind" /var/log/httpd/w00tw00t_attacks.log
このアプローチは実際には何回も使用しますより多くのリソース最初にファイルに直接ログを記録するときに使用したものよりも注意してください。 Webサーバーが非常にビジーな場合、これが問題になる可能性があります。
とにかく、すべてのログをできるだけ早くリモートロギングサーバーに送信することをお勧めします。これにより、侵入された場合に、行われた監査証跡を消去することがはるかに困難になるため、利益が得られます。
IPTablesブロッキングはアイデアですが、パフォーマンスに影響する可能性のある非常に大きなiptablesブロックリストが作成される可能性があります。 IPアドレスにパターンはありますか、それとも大規模な分散型ボットネットからのものですか？ iptablesを利用するには、重複のX％が必要です。
私は個人的にPythonスクリプトを作成して、IPtablesルールを自動追加しました。
以下は、ロギングやその他のジャンクを含まない、少し省略したバージョンです。
#!/usr/bin/python
from subprocess import *
import re
import shlex
import sys
def find_dscan():
p1 = Popen(['tail', '-n', '5000', '/usr/local/Apache/logs/error_log'], stdout=PIPE)
p2 = Popen(['grep', 'w00t'], stdin=p1.stdout, stdout=PIPE)
output = p2.communicate()[0].split('\n')
ip_list = []
for i in output:
result = re.findall(r"\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b", i)
if len(result):
ip_list.append(result[0])
return set(ip_list)
for ip in find_dscan():
input = "iptables -A INPUT -s " + ip + " -j DROP"
output = "iptables -A OUTPUT -d " + ip + " -j DROP"
Popen(shlex.split(input))
Popen(shlex.split(output))
sys.exit(0)
あなたはアップデート2で言う：
まだ残っている問題まだ残っている問題は次のとおりです。これらの攻撃は、サーバー上の特定のファイルを検索するボットからのものです。この特定のスキャナーは、ファイル/w00tw00t.at.ISC.SANS.DFind :)を検索します。
今、あなたはそれを無視することができますが、これは最も推奨されています。問題が残っているのは、このファイルがサーバーに何らかの形で存在していると、何らかの問題が発生することです。
以前の返信から、不適切な形式のHTML 1.1クエリが原因でApacheがエラーメッセージを返していることがわかりました。 HTTP/1.1をサポートするすべてのWebサーバーは、このメッセージを受信するとエラーを返すはずです（RFCを再確認していません-RFC2616が教えてくれます）。
サーバー上でw00tw00t.at.ISC.SANS.DFind：を持っていると、神秘的に「問題が発生している」という意味ではありません... DocumentRootまたはDefaultDocumentRootそれは問題ではありません...スキャナーが壊れたHTTP/1.1リクエストを送信していて、Apacheは「いいえ、それは悪いリクエストです...さようなら」と言っています。 w00tw00t.at.ISC.SANS.DFind：ファイルのデータは提供されません。
本当にしたい場合（ポイントがない場合）を除いて、この場合にmod_securityを使用する必要はありません...この場合、手動でパッチを適用する方法を確認できます（他の回答のリンク）。
もう1つの使用方法は、mod_securityのRBL機能です。おそらく、RBLがオンラインであり、w00tw00t IP（または他の既知の悪意のあるIP）を提供している場合があります。ただし、これはmod_securityがすべてのリクエストに対してDNSルックアップを行うことを意味します。
Modsecurityにルールを追加するのはどうですか？このようなもの：
SecRule REQUEST_URI "@rx (?i)\/(php-?My-?Admin[^\/]*|mysqlmanager
|myadmin|pma2005|pma\/scripts|w00tw00t[^\/]+)\/"
"severity:alert,id:'0000013',deny,log,status:400,
msg:'Unacceptable folder.',severity:'2'"
ほとんどのソリューションはすでに上記でカバーされているようですが、すべてのクライアントがホスト名なしでHTTP/1.1リクエストを送信した攻撃がサーバーに直接向けられているわけではないことを指摘しておきます。サーバーの前にあるネットワークシステムのフィンガープリントや悪用を試みるさまざまな試みがあります。
client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /tmUnblock.cgi
linksysルーターなどを対象とするため、フォーカスを拡大し、防御の取り組みをすべてのシステム間で同等のシェアで分割することが役立つ場合があります。つまり、ルータールールの実装、ファイアウォールルールの実装（できればネットワークに1つある）、サーバーファイアウォール/ IPテーブルの実装ルールと関連サービス、つまりmod_security、fail2banなど。
これはどう ？
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j LOG --log-level 4 --log-prefix Hacktool.DFind:DROP:
私にとってはうまくいきます。
hiawatha web server をreverse proxyとして使用すると、これらのスキャンはゴミとして自動的にドロップされ、clientは禁止されます。また、XSS＆CSRFエクスプロイトをフィルタリングします。