web-dev-qa-db-ja.com

IPTABLESブロックUser-Agent

Wordpress Pingback BOTNETでDDoSを取得しました。ここで、UseragentsにWordpressを含むすべてのクライアントをブロックしたいと思います。例：

WordPress/4.0; http://vk.lokos.net; verifying pingback from 107.158.239.82

HTTPポート80とHTTPSポート443の両方をブロックする必要があります。これを行うにはどうすればよいですか？

iptablesddosflooding
1
user3135461

最初に：以下で説明するように、このようにしたくない。

第二に：非常に類似した問題がここで答えられます http://spamcleaner.org/en/misc/w00tw00t.html 。私はあなたの特定の質問に彼らの解決策を伝えています。ブラウザエージェントを照合するために使用できるiptablesstringモジュールがあります。ただし、iptablesはすべてのパケットを検査します...これはconnmarkモジュールで最適化できます。私はそれを試したことがないので、私の答えは正しい方向へのナッジだけです：

<other rules>
iptables -t mangle -A PREROUTING -m connmark --mark 0xBAD1 -j DROP
iptables -t mangle -A PREROUTING -m connmark --mark 0xBAD0 -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -m string --string "User-Agent: " -j CHECK_UAGENT
iptables -t mangle -A CHECK_UAGENT -m string --string "User-Agent: WordPress/4.0" -j CATCH
iptables -t mangle -A CHECK_UAGENT -j CONNMARK --set-xmark 0xBAD0
<otherrules>
iptables -t mangle -N CATCH 
iptables -t mangle -A CATCH -j LOG --log-level alert --log-prefix "WordPress attack "
iptables -t mangle -A CATCH -j CONNMARK --set-xmark 0xBAD1
iptables -t mangle -A CATCH -j DROP

これがアイデアです。 connmarkモジュールと関連するターゲットは、必要に応じてパケットにマークを付け、その接続ストリーム内の後続のパケットにも同様にマークを付けます。したがって、ポート80に向かうパケットを探し、「ユーザーエージェント」文字列を使用します。彼らが望ましくないユーザーエージェントを持っている場合、それを0xBAD1としてマークします-それをblaclistingします。次に、ログに記録してドロップします。それ以外の場合は、「ユーザーエージェント」が表示されても望ましくないものが表示されない場合は、0xBAD0でホワイトリストに登録されます。ホワイトリストに登録することで、パケットインスペクターの負荷を軽減します（これは最適化のステップです）。そうでなければ、アップロードされたすべての画像のすべてのパケットを検索することになります-無意味な無駄です。

**上記が悪い考えである理由** 1つ：HTTPSはパケットフィルターレベルでデコードできません。 2：上記のDDOS攻撃が可能であるため。接続が開始され、Webサーバーで接続が開かれ、が消えます（Webサーバーの観点から）。それ以上のパケットの通過が許可されなくなったクライアントをあきらめる前に、長い間待機します。その間、より多くの試みが行われるでしょう。最終的に、HTTPはリソースを使い果たし、noリクエストは通過します。 （この問題を解決する1つの方法は、recentモジュールを使用することです。より徹底的な方法は、プロセスに「WordPress攻撃」のログファイルを監視させ、リモートIPとポートを記録させ、接続を cutter で閉じるか、接続を関連付けられたサーバーPIDと相互参照してから、そのプロセスを強制終了します。）

同様の質問 が提起され、次のように回答されました：リバースプロキシを使用してください。これが最良のオプションですが、多くの再構成とサーバーの介入が必要になる場合があります。

代わりにこの方法で実行してくださいmod_rewrite（Apache/* ngnx内）を使用してUser-Agent文字列を照合し、ロギング用の環境変数を設定して、 403エラーステータス。それはリモート側をシャットダウンします。ここで、より永続的にするために、そのようなドロップされた接続のログファイルを監視する別のプロセスを用意し、remote-ipをrecentテーブルに追加します。これにより、iptablesは次の5分間から新しい接続をドロップします。 。そう...

# Apache config
RewriteCond %{HTTP_USER_AGENT}  ^WordPress/4\.0
RewriteRule - [L,R=403,E=WordPress]
LogFormat "%t\t%a\t%{remote}p\t%{User-Agent}i"
CustomLog wordpress wordpress.log env=WordPress

カスタムログ形式により、外部プロセスのデコードが容易になります。 IPtablesは1つのルールにすぎません。

iptables -A INPUT --syn -m recent --name WordPress --rcheck --seconds 300 -j DROP

外部プロセス（rootとして実行）は次のようになります。

#!Perl 
open(STDIN,"tail -f /var/log/http/wordpress.log|")
while (<>) {
   my ($time,$ip,$port,$useragent)=split('\t');
   open(RECENT,"> /proc/net/xt_recent/WordPress")
   print RECENT "+$ip\n"
   close RECENT
}

タイムスタンプとユーザーエージェント文字列は、期待どおりに機能している/機能していないことを確認できるようにするためのものです。物事を行うmod-rewriteの方法で、拒否/禁止するものの柔軟性が大幅に向上することを追加します。

4
Otheus

次のコマンドを実行すると、この特定の攻撃がブロックされます。

iptables -N Wordpress-PingVerify
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /' -j Wordpress-PingVerify
iptables -A Wordpress-PingVerify -p tcp --dport 80 -m string --to 80 --algo bm ! --string 'User-Agent: WordPress/' -j RETURN
iptables -A Wordpress-PingVerify -p tcp --dport 80 -m string --to 300 --algo bm --string 'verifying pingback from' -j DROP
iptables -A Wordpress-PingVerify -j RETURN

上記のルールは、攻撃がHTTP（ポート80）を宛先としていることを前提としています。

別の方法として、これらのルールを使用してすべてのWordPress pingbackリクエストをブロックできます。これにより、pingback検証だけでなくpingbackもブロックされます。

iptables -N Wordpress-PingBacks
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /' -j Wordpress-PingBacks
iptables -A Wordpress-PingBacks -p tcp --dport 80 -m string --to 80 --algo bm ! --string 'User-Agent: WordPress/' -j RETURN
iptables -A Wordpress-PingBacks -p tcp --dport 80 -j DROP
iptables -A Wordpress-PingBacks -j RETURN

ソース： https://sysadminblog.net/2016/05/blocking-wordpress-pingback-verification-ddos/

1
Ehsan Chavoshi