web-dev-qa-db-ja.com

w00tw00t.at.ISC.SANS.DFind iptablesの修正-乱用可能?

それは単なるアイデアです。最近、私のサーバーがw00tw00tツールによってスキャンされていることをログに記録しました。

Apache mod-securityfail2banの使用など、これに対する多くの解決策を見つけました。

私がお話ししたいのは、Apacheログマッチングに基づいて、iptablesを使用してそのようなIPをブロックすることです。

これらのスキャンアドレスをブロックする方法について提示されたアイデアを使用する場合、重要な事実を指摘する必要があります。つまり、IPを要求することはほぼ毎回スプーフィングされますつまり、それらは攻撃者のものではありません。

このアイデアは、一般的なユーザーに損害を与えていませんか?攻撃者になりすまされたIPをブロックすると、実際に被害を与えていない誰かをブロックすることになります。つまり、iptablesベースの防御は使用できません、または私は間違っていますか?

さらに悪いことに、このサーバー側の予防策は攻撃として使用できるでしょうか?誰かがサイトにアクセスするのを防ぐ必要がある場合、私は彼のIPを偽装し、iptablesブロッキングを使用してこの予防システムによってブロックされますね?

学習資料:
http://blog.urlvoid.com/w00tw00t-at-isc-sans-dfind-web-scanner/
https://serverfault.com/questions/125607/dealing-with-http-w00tw00t-attacks
http://profi-admin.com/Articles/Showfull/06/05/2010/Administration/How-i-got-rid-of-the-w00tw00t-entries-in-my -server-logs
http://foxpa.ws/2010/07/14/using-dfind-exe-and-blocking-w00tw00t-at-isc-sans-dfind/
http://www.myatus.com/2010/07/17/blocking-w00tw00t-scans/
http://spamcleaner.org/en/misc/w00tw00t.html

3
Marek Sebera

TCP接続は簡単にスプーフィングされません。この理由は、接続が「確立された」と見なされる前に完了する必要がある three-way-handshake です。 HTTP要求を送信する前に、接続を確立する必要があります。

UDPパケットは簡単に偽装されますが、Apacheを攻撃するために使用することはできません。

HTTPはTCP接続で動作するため、ブロックしているIPアドレスがその時点で実際に攻撃していることを確信できます。

今日攻撃しているIPアドレスは、明日の正当なユーザーが所有している可能性があります。また、正当なユーザーが感染していて、ボットネットの一部である場合は、同時に所有する可能性もあります。最後の攻撃が確認された後、ファイアウォールルールが期限切れになることを確認することは価値があります。

特に誤検知が心配な場合は、帯域外の方法で連絡する(メールアドレスや電話番号など)カスタム403ページを作成し、ApacheでDeny from 1.2.3.4を使用してIPアドレスをブロックできます。構成。

1
Ladadadada