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つの他の解決策を思いついた、誰かがそれらについて良いかどうかについてコメントすることができます。

1. 私の頭に浮かぶ最初の解決策は、Apacheエラーログからこれらの攻撃を除外することです。これにより、他の緊急エラーが発生したときに簡単に見つけることができ、長いログを吐き出す必要がなくなります。

2. 2番目のオプションの方が良いと思います。それは、正しい方法で送信されないホストをブロックすることです。この例では、w00tw00t攻撃はホスト名なしで送信されるため、正しい形式ではないホストをブロックできると思います。

更新2

答えをたどった後、私は次の結論に達しました。

1. Apacheのカスタムロギングを使用するには、いくつかの不必要なリソースが消費されます。本当に問題がある場合は、おそらく何も欠落していない完全なログを確認する必要があります。

2. ヒットを無視して、エラーログを分析するより良い方法に集中することをお勧めします。ログにフィルターを使用することは、これに適したアプローチです。

主題に関する最終的な考え

上記の攻撃は、少なくとも最新のシステムがあればマシンには届かないので、基本的に心配はありません。

エラーログとアクセスログの両方が非常に大きくなるため、しばらくしてから実際の攻撃からすべての偽の攻撃を除外することは困難です。

これが何らかの形で発生するのを防ぐと、リソースが消費されます。重要でないものにリソースを無駄にしないことをお勧めします。

現在使用しているソリューションはLinux logwatchです。ログの概要が送信され、それらはフィルタリングされてグループ化されます。これにより、重要なものと重要でないものを簡単に分離できます。

助けてくれてありがとう、そしてこの投稿が他の誰かにも役立つことを願っています。

エラーログから、リクエストのHost：部分なしでHTTP / 1.1リクエストを送信しています。私が読んだことから、Apacheはmod_securityに引き渡す前に、この要求に対して400（悪い要求）エラーで応答します。したがって、ルールが処理されるようには見えません。（mod_securityに引き渡す必要がある前にそれを処理するApache）

自分で試してください：

telnetホスト名80
GET /blahblahblah.html HTTP / 1.1（入力）
（入る）

400エラーが表示され、ログに同じエラーが表示されるはずです。これは悪いリクエストであり、Apacheは正しい答えを提供しています。

適切なリクエストは次のようになります。

GET /blahblahblah.html HTTP / 1.1
ホスト：blah.com

この問題を回避するには、mod_uniqueidにパッチを適用して、失敗したリクエストに対しても一意のIDを生成し、Apacheがリクエストをリクエストハンドラに渡すようにします。以下のURLは、この回避策についての議論で、あなたが使用することができmod_uniqueidためのパッチが含まれています http://marc.info/?l=mod-security-users&m=123300133603876&w=2

他の解決策が見つからず、実際に解決策が必要かどうか疑問に思いました。

IPをフィルタリングするのは得策ではありません。知っている文字列をフィルタリングしてみませんか？

というのは：

iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP

Ivはまた、ログファイルでこれらのタイプのメッセージを見始めました。これらのタイプの攻撃を防ぐ1つの方法は、fail2ban（http://www.fail2ban.org/）をセットアップし、iptablesルールでこれらのIPアドレスをブラックリストに登録する特定のフィルターをセットアップすることです。

これらのメッセージの作成に関連するIPアドレスをブロックするフィルターの例を次に示します

[Tue Aug 16 02:35:23 2011] [error] [client]ファイルが存在しません：/var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t messages jail -正規表現とフィルター===刑務所

 [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に従ってChina、Poland、Denmarkなどを報告します。そのため、Deny IPまたは解決可能なホスト名のセットアップは1時間以内に変更されるため、ほとんど不可能です。

私は個人的にIPtablesルールを自動追加するPythonスクリプトを書きました。

これは、ログやその他のジャンクのないわずかに短縮されたバージョンです。

#!/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)

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

このアプローチは、実際にファイルへの直接のログ記録に使用されていたよりも実際に何倍ものリソースを使用することに注意してください。ウェブサーバーが非常に混雑している場合、これが問題になる可能性があります。

とにかく、できるだけ早くすべてのログをリモートロギングサーバーに送信することをお勧めします。これは、行われたことの監査証跡を消去するのがはるかに難しいため、侵入された場合に役立ちます。

IPTablesブロックはアイデアですが、パフォーマンスに影響を与える可能性のある非常に大きなiptablesブロックリストが作成される場合があります。IPアドレスにパターンがありますか、それとも大規模な分散ボットネットからのものですか？iptablesから利益を得るには、重複のX％が必要になります。

あなたはアップデート2で言います：

まだ残っている問題残っている問題は次のとおりです。これらの攻撃は、サーバー上の特定のファイルを検索するボットによるものです。この特定のスキャナーは、ファイル/w00tw00t.at.ISC.SANS.DFind :)を検索します。

これで、最も推奨される無視することができます。問題は、いつか何らかの形でこのファイルをサーバー上に置いた場合、何らかのトラブルが発生することです。

前回の返信から、Apacheが不適切な形式のHTML 1.1クエリのためにエラーメッセージを返していることがわかりました。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機能です。おそらく、w00tw00t IP（または他の既知の悪意のあるIP）を提供するRBLオンラインがあります。ただし、これは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ルーターなどをターゲットとするために、時折、焦点を広げて、等しいシェアを持つすべてのシステム間で防御努力を分割するのに役立ちます。すなわち、ルータールールを実装し、ファイアウォールルールを実装します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:

私にとってはうまくいきます。

hiawathaWebサーバーを使用する場合、reverse proxyこれらのスキャンはゴミとclient禁止として自動的に削除されます。また、フィルタリングXSSとCSRF悪用も行います。