web-dev-qa-db-ja.com

サーバーからのブルートフォース攻撃

私が管理しているサーバーの1つは、Wordpressインストールに対するブルートフォース攻撃に参加しているようです。

私はこれを何度も受けているので、これを防ぐために実行できる手順をよく知っています。しかし、私が苦労しているのは、発信攻撃を検出することです。サーバーは典型的なApacheサーバーであり、その上に多数のvhostがあります-これはもちろん複雑な問題です-そこに1つしかない場合は、それほど難しくはありません！

私は現在、次のコマンドを使用して、このサーバーの任意のポートから他のマシンのポート80に向かうトラフィックをログに記録するためにtcpflowを使用しています。

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

上記の「ホスト：」を難読化したことに注意してください。これが攻撃されているホストだと思います（これは正しいですか？）。

だから私の質問は本当に、この悪意のあるトラフィックを生成している仮想ホストを検出するにはどうすればよいですか？それができれば、クライアントに知らせることができ、クライアントはサイトを調査し、サイトを停止するために必要な変更を加えることができます。

どんな解決策も非常にありがたく受けました:)

linuxphpbrute-force-attacks
5
ticktockhouse

あなたの言うことから、allow_url_fopenを使用してクライアントからのURLダウンロードを制限できない設定になっていると思います。

この場合、表示するtcpflowログには実際にはその情報が埋め込まれていないため、元のphpスクリプトに戻るのは実際には非常に困難です。

考慮すべき簡単なオプションの1つは、送信要求に、それを作成した実際のクライアントを識別するために使用できる、明らかにするユーザーエージェントを強制することです。

たとえば、client1Webサイトのvhost定義に命令を追加できます。

php_admin_value user_agent client1

これにより、そのWebサイトによって行われたhttp要求は、ユーザーエージェント「client1」を使用するように強制されます。これはtcpflowログに表示されるため、誰が発信したかを知ることができます。

プライバシーが懸念される場合は、実際のクライアントにマップできるのは自分だけのuser_agent（クライアント名の暗号化など）を使用することをお勧めします。

ただし、一部のWebサイトは、提供されたuser_agentに応じて表示が異なり、この設定により、クライアントによる変更の試みが意図的に防止されるため、ユーザビリティが損なわれる可能性があります。

1
eltrai