私が管理しているサーバーの 1 つが、Wordpress インストールに対するブルート フォース攻撃に参加しているようです。
私は何度もこの攻撃を受けたことがあるので、これを防ぐために取るべき手順はよく知っています。しかし、私が苦労しているのは、発信攻撃の検出です。サーバーは、多数の vhost を備えた典型的な Apache サーバーです。もちろん、これが複雑になるところです。そこに vhost が 1 つだけあれば、それほど難しくはありません。
現在、次のコマンドを使用して、tcpflow を使用して、このサーバーの任意のポートから他のマシンのポート 80 に送信されるトラフィックをログに記録しています。
tcpflow -i eth0 dst port 80 and src host <my_servers_ip> and port not 22
私は tcpdump よりもこれが好ましいと感じました。しばらくすると、その出力を調べるのがちょっと頭が混乱してしまいます :) tcpflow は各リクエストを別々のファイルに格納します。
以下は、疑わしいアクティビティであると思われるファイルからの出力です。
POST /wp-login.php HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Host: somedomain.com
Accept: */*
Cookie: wordpress_test_cookie=WP+Cookie+check
Content-Length: 97
Content-Type: application/x-www-form-urlencoded
log=jacklyn&pwd=london&wp-submit=Log+In&redirect_to=http://somedomain.com/wp-admin/tes1a0&testcookie=1
注意してください、上記の「ホスト:」は難読化されていますが、これは攻撃されているホストであると考えられます (これで正しいでしょうか?)。
私の本当の質問は、この悪意のあるトラフィックを生成している仮想ホストをどのように検出するかということです。それができれば、クライアントに知らせることができ、クライアントはサイトを調査して、それを阻止するために必要な変更を加えるための手順を実行できます。
解決策があれば、ぜひ教えてください :)
答え1
あなたのおっしゃることから、allow_url_fopen を使用してクライアントからの URL ダウンロードを制限できない設定になっていると推測します。
その場合、表示される tcpflow ログには実際にはその情報が埋め込まれていないため、元の PHP スクリプトに戻るのは実際にはかなり困難です。
検討すべき簡単なオプションの 1 つは、送信リクエストに、リクエストを作成した実際のクライアントを識別するために使用できる公開ユーザー エージェントを強制することです。
例えば、client1ウェブサイトのvhost定義に命令を追加することができます。
php_admin_value user_agent client1
これにより、その Web サイトによって行われたすべての http 要求はユーザー エージェント「client1」を使用するように強制され、tcpflow ログに表示されるため、要求の発信元が誰であるかがわかります。
プライバシーが懸念される場合は、実際のクライアントにマップできるユーザーエージェント (クライアント名の暗号化など) を使用することをお勧めします。
ただし、一部の Web サイトは提供された user_agent に応じて異なって表示されるため、この設定により、クライアントによる変更の試みが意図的に防止されるため、ユーザビリティが損なわれる可能性があります。