web-dev-qa-db-ja.com

リクエストやユーザーエージェントなしでログで408エラーを取得する

次のようなApacheログで多くのリクエストが表示されます

www.example.com:80 10.240.1.8 - - [06/Mar/2013:00:39:19 +0000] "-" 408 0 "-" "-" -

リクエストもユーザーエージェントもないようです。誰かこれを見たことがある？

apache-2.2httphttp-status-code-408
38
Glenn Slaven

Elastic Load Balancerの背後でAmazonのWebサーバーを実行している可能性はありますか？

それは 彼らは彼らのヘルスチェックのために408応答をたくさん生成します のようです。

そのフォーラムスレッドからのソリューションのいくつか：

  • RequestReadTimeout header=0 body=0

    これにより、リクエストがタイムアウトした場合に408応答が無効になります。

  • ELBヘルスチェックを別のポートに変更します。

  • ELB IPアドレスのロギングを無効にします。

    SetEnvIf Remote_Addr "10\.0\.0\.5" exclude_from_log
CustomLog logs/access_log common env=!exclude_from_log

そして このブログ投稿 から：

  • リクエストのタイムアウトを60以上に調整します。
32
Ladadadada

ここにはすでにかなりの数の良い答えがありますが、具体的には取り上げられていないもう1つの注意点を危険にさらしたいと思います。以前のコメント投稿者の多くがすでに述べたように、408はタイムアウトを示します。また、Webサーバーでタイムアウトが発生するさまざまな状況があります。

そうは言っても、サーバーがエクスプロイトをスキャンされているさまざまなケースで408エラーが生成される可能性があります。このような場合、クライアントがユーザーエージェントを表示することはほとんどなく、接続が突然終了することが多いため、その接続が強制終了され、408エラーが発生する可能性があります。

たとえば、私がインターネットをスキャンして、POODLEの脆弱性に対して依然として脆弱なコンピュータを探している、卑劣なハッカーだとします。そのため、SSLバージョン3を受け入れるサーバーを見つけるために、IPアドレスの大きなチャンクへの接続を開くスクリプトを作成しました。後で、そのリストを使用して、特にPOODLEエクスプロイトをスキャンします。この最初のスクリプトが行うのは、opensslを使用して接続を確立し、次のようにSSLv3を確認することだけです。

openssl s_client -connect [IP]:443 -ssl3

このコマンドは、Apacheの多くの構成で、ユーザーが説明したとおりに408メッセージを表示します。私の2台のサーバーでこのコマンドを実行すると、アクセスログに次のエントリが表示されました。

<remote IP address>  - - [04/Nov/2015:08:09:33 -0500] "-" 408 - "-" "-"

OPがどのような形式の負荷分散も使用していない状況でも、408エラーはさまざまな状況で発生する可能性があることを明確にしたいと思います。悪意のあるエラー、クライアントの問題を示すエラー、サーバーの問題を示すエラーなどです。 （OPが提供するログで、ローカルIPがリモートIPとして示されていることに気付きましたが、OPはロードバランサーの使用について具体的に言及していなかったため、OPが単にルーティング不可能なIPを目的に使用していたのかどうかわかりませんでしたデモンストレーションの、彼はURLでしたように）

とにかく、私の投稿が明らかに遅すぎてOPを助けることができなかったとしても、うまくいけば、ここに到着した他の人がこれらのいまいましいタイムアウトエラーの解決策を探すのに役立つかもしれません。

11
Josh Wieder

何かがポートに接続していて、データを送信していない。 HTTP 408は「タイムアウト」エラーです。ここに良い記事があります： http://www.checkupdown.com/status/E408.html

9
Insyte

408タイムアウトにはさまざまな理由があります。しかし、すべてが正常であるという前提から始めましょう。ある時点で、これらの408がアクセスログに表示され始めます。つまり、408 0 "-" "-"です。

ネット上の多くの指摘と同様に、408は接続が作成されたことを示しますが、適切なタイムスケールで要求が送信されないため、サーバーは408との接続をドロップします。 -「タイムアウトのどの部分がわからない」。

私はそれは非常に初心者の回答であり、いくつかのセキュリティメソッドがWebサーバーソフトウェアでどのように機能するかについて完全に理解していないことを示しています。

最初に戻ると、なぜこれらの408がすべて表示されるのですか。他のサーバー管理と共通することの1つは、毎日受け取る膨大な量の攻撃です。さて、これらについてどうしますか？まあ：あなたはそれらに対処するためにあなたが選んだセキュリティ方法を採用します、これは何が変わるかです。

非常に簡単な例であるIPアドレスの削除を見てみましょう。 iptabesファイル（rules.v4）に含まれ、「-A ufw-user-input -s 37.58.64.228 -j DROP」が含まれている。したがって、37.58.64.228ファイアウォールがIPを認識し、接続をドロップします。多くの構成では、ドアがノックされていることすらわかりません。

次に、より高度な例として、いくつかの基準に基づいて接続をドロップします。 iptabesファイル（rules.v4）に含まれている「-A INPUT -p tcp -m tcp --dport 80 -m string --string "cgi" --algo bm --to 1000 -j DROP」。これは、このiptableルールでは、リクエスト文字列の最初の1000バイトを見て、「cgi」のサブ文字列が見つかるかどうかを確認し、そのサブ文字列が見つかった場合は何も実行しないためです。さらに、接続をドロップするだけです。

ここではセキュリティ方法は優れていますが、ログに関する限り、誤解を招くおそれがあります。生成された408 0 "-" "-"は、Apacheがこのような状況で実行できる最高の方法です。文字列比較ルールを適用するには、接続が確立され、要求がある程度まで受け入れられる必要がありました。これは、ルールが接続を削除するための基準を満たしているため、最終的には408になります。ですから、私たちの小さな初心者のダーリンは、彼らが試みたとしても、もっと間違ったことはありません。接続が確立され、要求が受信されました（このような状況では、それを表示できなくなります）。 408は生成されますが、「タイムアウト」ではありません。ファイアウォールルールに関連してリクエストが行われた後、サーバーは単に接続をドロップしました。他の多くのルールがあり、同じ408状況を作成します。サーバーエラーコード408の説明-'Request Timed Out'を文字どおりに受け入れないでください。

理想的には、Apacheで生成された別のエラーコードが存在することが理想的です。

最新のWebサーバーソフトウェアを使用すると、DOS攻撃を実質的に排除でき、予測機能を組み込んだ新しい種類のブラウザーは、この問題を引き起こしません。

つまり、408が生成されるのは、サーバーが要求に応答しなかったためです。クライアントに関する限り、実際にはサーバーが要求を読み取ったが、タイムアウト待ち以外の理由で接続をドロップした場合、接続はタイムアウトしました。リクエスト。

6
Kev

私たちはこの非常に問題を抱えており、しばらくの間戸惑っていました。私たちが思いついた最善のソリューションは、AWSサポートのELBチームによって提案されました。これは基本的に、httpdサーバーのタイムアウト設定がすべてELB _idle timeout_設定（デフォルトでは60秒）より大きいことを確認することにかかっています。

  • ApacheのTimeoutディレクティブの値がELBの_idle timeout_設定の2倍であることを確認してください。
  • KeepAlive機能をオンにし、MaxKeepAliveRequestsが非常に大きいこと（無限の場合は0または2000のように非常に大きいこと）、およびKeepAliveTimeoutがELBの_idle timeout_。

KeepAlive（および関連する設定）の設定により、408の数が実質的に0に具体的に削減されたことがわかりました（いくつかありますが、ごくわずかです）。

5
dsummersl

AWS Elastic Load Balancerの背後にこの問題がありました。ヘルスチェックにより、ログに膨大な量の408応答が生成されました。

私のために働いた唯一の解決策は、ロードバランサーのアイドルタイムアウト設定を低くすることでしたヘルスチェックの応答よりも低い）タイムアウト。

3
Přemysl Růžička

同僚は最近、私の最後の投稿で408がどのようにセキュリティ対策と関連付けられるかについては有効な説明をしましたが、それは解決策を提供しないと述べました。

パイプアクセスログは私の個人的な解決策です。

以下は、ほとんどのUbuntu構成ですぐに使用でき、他のApache構成では最小限の調整を行う必要があります。 PHPを理解するのが最も簡単なので選択しました。2つのスクリプトがあります。1つ目は408がアクセスログに書き込まれないようにします。2つ目はすべての408を別のログファイルに送信します。どちらの場合も、結果はアクセスログに408でなくなり、実装するスクリプトを選択できます。

お気に入りのテキストエディターを使用して、私はnanoを使用します。 「LogFormat」および「CustomLog」ディレクティブがあるファイルを開きます。通常の＃でオリジナルをコメントアウトし、以下を追加します。これらのディレクティブは以下のファイルにあります。

Sudo nano/etc/Apache2/sites-available/default

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" AccessLogPipe

CustomLog "|/var/log/Apache2/PipedAccessLog.php" AccessLogPipe env=!dontlog

注：アクセスログには画像を記録しません。 etc/Apache2/httpd.confファイルに次の行を含めます

SetEnvIfNoCase Request_URI ".(gif)|(jpg)|(png)|(css)|(js)|(ico)$" dontlog

これに関心がない場合は、env=!dontlogはCustomLogディレクティブから。

ここで、次のいずれかを作成しますPHPスクリプト（#!/usr/bin/phpはインタープリターの場所への参照です。場所がシステムに正しいことを確認してください-$プロンプトで次のように入力してください。 whereis php-php: /usr/bin/php /usr/bin/X11/php /usr/share/man/man1/php.1.gz。ご覧のように #!/usr/bin/phpは私のセットアップに適しています）。

Sudo nano /var/log/Apache2/PipedAccessLog.php

#!/usr/bin/php
<?php
  $file = '/var/log/Apache2/access.log';
  $no408 = '"-" 408 0 "-" "-"';
  $stdin = fopen ('php://stdin', 'r');
  ob_implicit_flush (true);
  while ($line = fgets ($stdin)) {
    if($line != "") {
      if(stristr($line,$no408,true) == "") {
        file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
      }
    }
  }
?>

Sudo nano /var/log/Apache2/PipedAccessLog.php

#!/usr/bin/php
<?php
  $file = '/var/log/Apache2/access.log';
  $file408 = '/var/log/Apache2/408.log';
  $no408 = '"-" 408 0 "-" "-"';
  $stdin = fopen ('php://stdin', 'r');
  ob_implicit_flush (true);
  while ($line = fgets ($stdin)) {
    if($line != "") {
      if(stristr($line,$no408,true) != "") {
        file_put_contents($file408, $line, FILE_APPEND | LOCK_EX);
      }
      else {
        file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
      }
    }
  }
?>

PipedAccessLog.php 脚本; $プロンプトで次のコマンドを実行して、rootが所有権を持っていることを確認します。

Sudo chown -R root:adm /var/log/Apache2/PipedAccessLog.php

PipedAccessLog.phpスクリプトには読み取り/書き込みと実行の権限が必要なので、$プロンプトで次を実行します。

Sudo chmod 755 /var/log/Apache2/PipedAccessLog.php

最後に、すべてを機能させるには、Apacheサービスを再起動する必要があります。 $プロンプトで以下を実行します。

Sudo service Apache2 restart

Apacheログが別の場所にある場合は、構成に合わせてパスを変更します。幸運を。

0
Kev