「allrequestsallowed.com」…ハッキングの試み？

私の（小さな、個人的な、まったく重要ではない）Webサーバーで多くの試みがありますが、通常、apacheとfail2banは適切に機能します。しかし、私を心配させるログエントリがあります。

xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"

問題は、答えが404コードではなく、代わりに200だったことです。それは大丈夫ですか？私には奇妙に思えますが、この分野（および他の多くの分野）での私の知識は、そっと言うと、限られています。

server security webserver

— ルリ
ソース

新しい回答を投稿することは許可されていないようですが、ログに次のようなエントリが見つかり、curl：でリクエストを再現することで危険ではないことを確認できましたcurl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80。デフォルトの設定は、ubuntuシステムで、意味のあるコンテンツのない「Welcome to nginx」ページを返すようです。したがって、200の応答ですが、単純なキャッチオールページです。実際には、要求を他の場所またはそのようなものにプロキシするわけではありません。

— フランクファーマー

最初に、事前に、推定攻撃者が何を達成しようとしているのかわかりません。たぶん、奇妙なセッションID攻撃に対して脆弱なPHPスクリプトまたはPHPバージョンがあります。ただし、おそらく心配する必要はありません。

サーバーは期待どおりに動作しました。200は、Apacheが渡されるURLをどのように解釈するかにより、その特定の状況で予期されるコードです。

最初に、http://allrequestsallowed.comより一般的な「Host：」ヘッダーのように扱われ~~ます（これはRFCで指定されているとは思わず、他のサーバーがこのよう~~に~~解釈しない可能性があることに注意してください~~、これはセクション5.1のRFC 2616で指定されています。 2、クライアントがそのフォームを使用することはめったにありませんが、すみません、しばらく前に書いたHTTPサーバーの実装を修正する必要があります...）。

さて、おそらく「allrequestsallowed.com」という名前のサイトはないでしょう。それでは、ApacheがHost:認識しないホスト名のヘッダー（または同等のもの）を取得するとどうなりますか？デフォルトとして最初の仮想ホストを選択します。これは、Apacheの明確に定義され、文書化された動作です。したがって、最初の仮想ホスト（または仮想ホストが存在しない場合はメインサーバーの構成）が何であれ、その名前が何であっても引き継ぎます。

これで、指定されたURLの残りの部分は、パス/、およびGETパラメーター（?PHPSESSID...ビット）の2つの部分で構成されます。

これで、/ほとんどすべてのWebサーバーにパスが存在するはずです。ほとんどの場合、それindex.htmlはindex.phpスクリプトのようなものまたはおそらくスクリプトにマップされますが、もちろんこれはオーバーライドできます。

静的なHTMLファイルにマップする場合、異常なことはまったく起こりません。ファイルのコンテンツが返されます。つまり、パラメーターは単に無視されます。（特定の高度な設定ディレクティブが設定されていないと仮定すると、ほぼ確実に設定されません。）

一方、それがなんらかのスクリプトである場合、そのPHPSESSID変数はスクリプトに渡されます。スクリプトが実際にその変数を使用する場合（この特定のケースでは、PHPの組み込みセッション処理を使用するPHPスクリプトのみが使用される可能性が高い）、その動作はコンテンツに依存します。

ただし、おそらく、/セッションを使用してPHPスクリプトにマップしたとしても、特筆すべきことは何も起こりません。セッションIDはおそらく存在しないため、無視されるか、スクリプトにエラーが表示されます。

まれに、セッションIDが存在する場合、攻撃者は誰かのセッションをハイジャックする可能性があります。それは悪いことですが、それ自体は実際にはセキュリティホールではありません-攻撃者がセッションID情報を取得した場所であればどこでもホールになります（HTTPSを使用していない場合、ワイヤレスネットワークを探るのは良い候補です）。実際には、元々セッションが実行されていたユーザーが実行できなかったことを実行することはできません。

編集：さらに、SESSIONID内の '％5C'はバックスラッシュ文字にマップされます。これは、Windowsホストでのディレクトリトラバーサル攻撃のテストのようです。

— ニコラス・ナイト
ソース

nginxまたはを実行しているサーバーで同様のリクエスト404、500、403、および20xがあり、lighttpdIP /ソースホストをサイバー分析会社に送信した後、特にサーバーの穴を悪用する試みであることが確認されました。OP、異なるホストによって指定されたリクエストと同様のリクエスト。それらは完全に無視されるべきだと言っていますか？彼らが本当に心配しているのなら、彼らはでホストをブロックできるからiptablesです。

— トーマス・ウォード

@The Evil Phoenix：URL内のホストはリクエストの送信元ではなく、 'Host：'ヘッダーに相当します。OPによって隠されている実際のクライアントIPアドレスは、希望すればiptablesでブロックできますが、リクエストであふれない限り、それは実際には問題ではありません。誰かが穴を悪用しようとするからといって、穴が存在するわけではありません。私は毎日ホールを悪用することを目的とした多くの奇妙なリクエストを記録する多数の（Linux）サーバーを管理しています-それらのほとんどはWindows / IISホールです！ブラインドスキャンです。ヒットしない場合、次のIPアドレスに移動します。

— ニコラスナイト

@The Evil Phoenix：さらに、穴が存在する場合、それを悪用したIPアドレスをブロックしても、少しの効果はありません。サーバーは既に侵害されていて、他のソースからの同じ攻撃に対して脆弱です。そして、ソースはたくさんあります。そこにあるすべてのゾンビシステム（および数百万）は、悪意のあるスキャンの潜在的なソースです。

— ニコラスナイト

素敵で徹底的な説明....どうもありがとう。彼/彼女がip-ego-surfsした場合に備えて、問題の IPを隠しました:)。私の/は、Apacheのデフォルトの "It works"にマップされます（私は知っています、プロではありません...しかし、私はそれが個人的だと言いました、笑）。したがって、同じIPが苦痛にならない限り、何もしない必要があると思います。その場合、iptables（またはhosts.denyでさえ）でブロックします。再度、感謝します。

— ルリ

すべての駐車場ドメインのAレコードとして使用されるIPで、このallrequestsallowedをログに記録しました。

私の狙いは、このホスト名が、ターゲットホストを指す「攻撃者」のローカルホストファイルと組み合わせて使用されることです。

31.44.184.250の実際のWebサーバーは、外部要求を処理するためのものです。

私の意見：全く無害。ホストファイル内の他の偽のドメイン名でできることを除いて、付加価値のある使用法を見ないでください。

— カイジェ
ソース