web-dev-qa-db-ja.com

パス内のURLを要求するボットの処理

サーバーログで、少なくとも1つのIPアドレスが、扱いにくい場所で完全なURLを要求していることがわかりました。たとえば、クライアントがサーバーに送信するヘッダーは次のとおりです。

GET http://www.3rdpartysite.com/file.php HTTP/1.1

そして、ここでは、リクエストヘッダーが次のようになることを期待しています。

GET /path/to/file.php HTTP/1.1
Host: example.com

これにより、ハッカーが私のウェブサイトを破壊しようとしているように思われますが、ここで http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html を見て、最初にそれについて説明しますGET要求はプロキシに対して有効です。

サーバーにはcpanelとwhmがインストールされていますが、Webサイトにプロキシを使用していません。私の質問は、Apacheにエラーを返すか、すべてのHTTPリクエストヘッダーにリダイレクトさせるかどうかです...

GET http://

...そして、この形式のヘッダーを発行するようにリモートシステムに要求します...

GET /path/to/resource HTTP/x.x
Host: example.com

私のアイデアはすべてのWebブラウザーで機能しますか?または、少なくとも1つの正当なWebブラウザーが壊れますか?

一部のハッカーがサーバーを使用して別のサーバーに接続していると感じています。

3
Mike

HTTP 1.1仕様 は、

GET /path/to/resource HTTP/1.1
Host: example.com

そして

GET http://example.com/path/to/resource HTTP/1.1

同等のリクエストです。これは、要求がRequest-Lineとして定義されているMethod-Token Request-URI Protocol-Versionで始まり、Request-URIが絶対値である可能性があるためです:"*" | absoluteURI | abs_path | authority

リクエストのさまざまな形式に異なって応答するようにWebサーバーを構成しようとしないでください。仕様に違反することになります。現在のブラウザは通常、以前のリクエスト形式を使用していますが、今後も引き続き使用する保証はありません。一部のブラウザの最新バージョンでの動作が突然停止することは望ましくありません。


代わりに、サーバーが不明なホストのコンテンツを提供しないようにする必要があります。サードパーティのサイトへのリクエストは、見つからない404(または400の不良リクエスト)を返す必要があります。サードパーティのサイトをリクエストするボットは、通常、オープンプロキシサーバーをテストしています。

Webサーバーを構成する1つの方法は、404ページを返すように最初の(デフォルト)仮想ホストを構成することです。すべての正当なサイトは、後の仮想ホストディレクティブに含まれます。

1

これらは常に起こります。これは、サーバーログに1日に少なくとも12回表示されます。最善の策は、ファイアウォールやゲートウェイからの接続をブロックすることです。そうすれば、サーバーにヒットすることはありません。この接続に関連する他のエラーが表示された場合は、無視しても問題ありません。

0