サーバChromeのpreconnectによりlogwatchに408のレポートが大量に表示されるようになり、はや一年。前回は打つ手なしと諦めてましたが、logwatchのhttpフィルタを自分でカスタマイズすれば良いことに今更ですが気づきましたので早速弄ってみましょう。昨日・今日になってApacheのアクセスログに大量の408が記録されるようになりました。何が起きたのか確認してみます。19:12logwtachのhttpdを再確認logwatchに対し修正したいことは主に2つ。server」が邪魔なこと。これを解決するのが今回の目的です。Requestlogwatchのhttpフィルタをカスタマイズするため/etcにコピーするデフォルトのhttpフィルタを直接編集してもダメではないのですが、logwatchがアップデートされた時に上書きされて戻ってしまうので、カスタマイズ用を/etc配下に準備します。5の時に表示されないようにします。>5)」に書き換えてしまいましょう。4)」を探してコメントアウト「#」の解除と数値を修正します。2行下にある「#}」のコメントアウト削除も忘れないでください。case-insensitive」セクションででアクセスログのファイル種別を振り分けているようです。中身を見てみるとWordPressには適していない条件設定なのがわかります。そこで自サイトのアクセスログを確認し、比較的アクセスの多い文字列を条件に追加してみました。#この行だけは解説が必要かと思います。$content_types.'|\/archives/(..*)|\/page/\d{1,3}';「\/archives/(..*)」は本サイトの記事には「/archives/」が入っていることから正規表現「(..*)」を使ってワイルドカードを設定、「\/page/\d{1,3}」はリストページの2ページ以降に入る「/page/**(数値)」に対応するため、正規表現「\d{1,3}」で1~3桁の数値を指定しています。カスタマイズ結果/etc/logwatch/scripts/services/httpを修正したのでlogwatchを実行してみます。Unauthorized----------------------------------------------------------------------------------------transferredの分類が以前よりは最適化されました。408のIPアドレスが表示されなくなり長々としていたレポートがスッキリしています。server」の行自体は残しているので、この件数を確認すれば408の原因がChromeなのかDDOS攻撃なのかの動向はつかめるはずです。コメントをキャンセルメールアドレスが公開されることはありません。