web-dev-qa-db-ja.com

Apache / Linuxサーバー、自身のIPからのDoS攻撃

しばらく診断しようとしていた異常な問題があります。

  • これは、PHP、Red5、MySQL 5.5（標準バイナリ）、sendmail（ディストリビューションバージョン）、およびcrashplanを備えたApache 2.2のカスタムコンパイルを実行しているDebianサーバーに関するものです。

  • 隔日でランダムファイル、主に画像への大量のHTTPリクエストが表示されます-私たちは千の同時接続を上向きに話しているのです。

  • これらのリクエストは、サーバー自身のIPアドレスから送信されます（！）。

  • これは通常、何度も何度もリクエストされる限られたファイルのセットです。実際のパターンは見えませんが、誰かが情報をこすり取っているようではなく、DoSの試みのようです。

  • Cronは、200を超える接続を持つIPを一時的に禁止するスクリプトを実行するため、これは通常、本当に問題になる前に抑制されます。 1〜3分で10分間禁止すると、攻撃は通常停止します。

  • これは何ヶ月も続いています。攻撃がキャッチされ抑制されているので、私はポイントを完全に見逃しています。

  • ランダムな時間と間隔で発生しますが、通常はUTCの午前中頃です。

  • これらのリクエストではリファラーやエージェントは送信されません。

サーバー上のスクリプトがそれ自体にクエリを送信するために悪用されたが何も見つからなかった場合に備えて、関連するリクエストのwebserverとred5ログをほぼ同時に確認しました。その頃のApacheエラーログやsyslogには何もありません。 Rkhunterも異常なことは何も見つかりませんでした。サーバーはルートパケットを送信しないため、なりすましも選択できません。

私は方法と理由について完全に途方に暮れています。何をチェックすべきかについてのアイデアは大歓迎です。 :)

UPDATE：Isernisのアドバイスに従って、次の発生に関する情報をキャッチするメカニズムを用意しました。これは（少し一般化されたバージョンの）メソッドです： http://Pastebin.com/6uSUKVbh

ANSWER：これは、FCK Editorを使用してmySpaceタイプのプロファイルを許可するソーシャルメディアサイトです。これはセキュリティの悪夢のようなものなので、ユーザーが投稿したプロファイルは広範なチェックを受けます。 1つはこれらのチェックでサイト所有ドメインを除外しなかったもので、2つはリダイレクトに関連するバグのため、すべてのリンクまたは画像が1回ではなく10回ヒットしました。そのため、サイト自体への広範なリンクを含むプロファイルを持つユーザーが保存ボタンを押すと、サイト自体がDoSになります。 ：P特に、これは彼女のプロファイルに膨大な数のアイテムがあり、頻繁に保存する傾向がある1人のユーザーに関係していました。

この問題を診断する方法を正しく理解してくれたIserniに感謝します。

ANSWER EDIT：バグについて間違っていました。彼女は実際にプロファイル内にいくつかの画像を10回以上持っています。具体的には、保存ごとに1000近くのリンクと画像を確認します。私はそれが来るのを見ませんでした。 ：P

linuxhttpapachedenial-of-serviceip-spoofing
13
Someone

まず、これらのリクエストがどこから来ているのかを調べます。ローカルプロセスである必要があります。最新のLinuxプラットフォームでTCPハンドシェイクを偽装できるものは他にありません（何もない、つまりwasteランダムな画像を要求することのような偉業）。

再発するURLがある場合は、RewriteRuleの背後に隠して、そのようなリクエストが実際にscriptをトリガーするようにすることができます。スクリプトで追加のチェックを実行して、リクエストが正当なものであるかどうか（そして、正当なクライアントが期待するイメージであるかのように適切なヘッダーを出力します）、またはそれが偽のリクエストの1つであるかどうかを確認できます。偽のリクエストに対して、あなたはログに記録できます。着信ポート。これで武装して、netstatをクエリしてプロセスを調べることができます。 psを実行して、偽のリクエストの瞬間にすべてのアクティブなプロセスを検査することもできます。

私は犯人がApache自体であることを確信しています（vhostの変更により、「キャッシュプライミング」スクリプトが悪用されたことがあります-スクリプトをcrontabに置くのを忘れていました-本当に奇妙な症状が出ました。それがすべて私に戻ってくるまであなたのものです;しかしあなたのケースは違うと感じます）。

コストを抑えながらシーンをさらに洗練するために、ApacheのCustomLogにPID/TIDを追加できます。その後、Apache子の不正アクセスポイントから受け取ったリクエストをクロスチェックできます。

別の可能性は、正確に決定することですhowこれらの要求が行われます。 Apacheを介する場合、これはfopen_wrappers、cURL、ソケット関数、または多分シェルユーティリティを意味します（ただし、これらは両方ともps出力に表示され、サーバーの過負荷がはるかに大きくなります）。次の一連のスクリプトを準備できます。

  • apacheを正常に再起動します変更なし
  • ""、無効化一時的にこれらの関数の1つ
  • ""、再有効化同じ

再起動でnotが問題を修正したことを（念のために）確認した後（修正した場合は、まったく異なるワームの缶になる可能性があります）、一時的に無効にすることができます-数十秒それぞれ、これ以上はありません-次々と機能します。 curlを無効にすると、システムはすぐに通常に戻ると仮定します。cURLを使用してスクリプトへの調査を制限できます。ロギングラッパーを使用してwrap cURL関数を制限することもできます。

有罪者がApacheでないことが判明した場合でも、whatがこれを行っているかどうかを判断できます。次に、影響を受けるプログラムを再インストールする（ランダムな異常が原因でプログラムがrepeat-HTTP-GET-requestorに変わる可能性が低い場合でも）か、その構成、補助データファイル、スクリプトなどを調べて、既知のクリーンインストールとの違いについて。私は通常グレムリンを信じないので、結局いくつかの違いが目立つようになると思います。

5
LSerni

Unix（およびLinux）には、このようなものを分析するための豊富なツールがあります。私の最初の停止は、netstat -napの出力を取得することです。私のローカルマシンで...

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
...
tcp        0      0 192.168.0.2:80              192.168.0.2:59875           ESTABLISHED 5281/httpd
...
tcp        0      0 192.168.0.2:59875           192.168.0.2:80              ESTABLISHED 32588/chrome
...

ここでは、chrome（pid 32588）がポート80/httpd（pid 5281）に接続されている）よりも確認できます。これはApacheのpre-forkインストールなので、httpdに関する詳細情報を取得できます％Pをログに記録するか、/ proc/5281/fdを調べて処理します（おそらく、要求時にデータを取得するためにスクリプトが必要になります）。

これにより、クライアントプロセスを識別できます。

最も可能性の高い候補は、正しく構成されていないプロキシまたはバグのあるコードです。

3
symcbean

これが私のサーバーであれば、Apacheでstraceを実行します。これをpreforkモードのすべての子プロセスで実行すると、特にサーバーがすでに過負荷になっている場合は、ディスクにかなりの負荷がかかる可能性があります。ディスク容量が不足すると、Apacheがリクエストの処理を停止するため、ディスク容量にも注意する必要があります。

リクエスト全体をキャプチャするのに十分な長さのスナップ長を使用していることを確認してください：-s 400で実行できます。

Apacheがそれ自体に要求を行っている場合、GETストリングは、2つの異なるPID（要求を行ったものと受け取ったもの）のstraceダンプに表示されます。リクエストを行ったもので、それが自分自身にリクエストを行ったときに受け取って処理していたリクエストを見つけたいと思います。

私は通常次のようなことをします：

for x in `ps -ef | grep Apache | awk '{print $2}'`; do strace -s 2000 -p $x -o trace.$x & done

パフォーマンス上の理由でApacheの子のサブセットに制限したい場合は、そこにheadを追加します。

for x in `ps -ef | grep Apache | head | awk '{print $2}'`; do strace -s 2000 -p $x -o trace.$x & done

ただし、これにより、何が起こっているかをキャプチャする可能性が低くなることに注意してください。

これらのバックグラウンドタスクはすべてセッションに書き込むことができるため、2つのSSHセッションが開いていることを確認してください。階層化を停止する場合は、Apacheを再起動するか、もう一方で実行します。

 for x in `ps -ef | grep strace | awk '{print $2}'`; do kill $x; done

これに関する私の直感は、クライアントに送信する前に画像を前処理（たとえば、サイズ変更）するPHPで記述された「静的」モジュールであり、include($image)でこれを実行します。 $imageに、ローカルファイルシステムからのファイルパスではなく、自分のサイトからの画像URLが含まれている場合、再帰的なリクエストが発生します。

curl()ではなくinclude()関数を使用している可能性があります。

2
Ladadadada

典型的なDOS攻撃のように聞こえます。彼らはおそらくサーバーがそれ自体からのリクエストに応答することを望んでおり、そして「死のping」のようなループを得ることを望んでいます。また、一部のファイアウォールルールを回避して一般的な頭痛の種となる便利な方法でもあります。ファイアウォールで外部IPをブロックするのがおそらく最善の策であり、ドアでリクエストを取得できません。

1
AJ Henderson

サーバーのIPを偽装するDDoS攻撃のように聞こえます。ルーターを使用するとファイアウォールの負荷が軽減されるため、ファイアウォールルールを使用するのではなく、外部ルーターにパケットフィルターを配置するのが最善のアクションです。シスコルータでは、単純な解決策は、送信元をパブリックブロック、宛先を任意にしてアクセスリストを作成し、それを「ipアクセスグループイン」として外部インターフェイスに適用することです。

ICMPのレート制限も良い考えです。彼らはあなたにpingフラッディングを試みるかもしれません。

有効なトラフィックのレート制限についても検討する必要があります。次のDDoS攻撃では、独自のIPを偽装することはありません。有効なIPアドレスを使用するため、顧客を除外せずにフィルタリングすることはできません。適切に選択されたレート制限は、サーバーがリソースを使い果たすことを防ぎます。

0
GdD