DebianとUbuntuでは、Nginxは/var/log/nginx/access.logとerror.logにログを出力し、Apacheは/var/log/apache2/access.logとerror.logにログを出力します。RHEL、Rocky、Almaの場合、Apacheは/var/log/httpd/access_logとerror_logを使用し、アンダースコアがあり拡張子はありません。公式のNginxイメージから作成されたコンテナでは、ログファイルがまったくなく、すべてがstdoutとstderrに出力されるため、docker logsがエクスポート手段となります。
ウェブサーバーログは、侵入者が残す最初の痕跡になることがしばしばあります:.envファイルをスキャンするスキャナー、エクスプロイト文字列、存在しないはずのファイルへのPOSTなどです。Prime Coreは、337のMITRE ATT&CK技術にマッピングされたウェブサーバーログ用の812の検出ルールを持っています。その中には、公開アプリケーションの脆弱性悪用(T1190)、ウェブシェル(T1505.003)、脆弱性スキャン(T1595.002)があります。
始める前に
実際のパスを見つける。 仮想ホストはしばしばカスタムな場所にログを出力します。サーバー自身に尋ねてください:
# Nginx: 全有効設定をダンプし、ログディレクティブを選び出す
sudo nginx -T 2>/dev/null | grep -E 'access_log|error_log'
# Apache
sudo apachectl -S
sudo grep -Ri -E 'CustomLog|ErrorLog' /etc/apache2/ /etc/httpd/ 2>/dev/null
DebianベースのApacheでは、独自のCustomLogを持たない仮想ホストは、他の_vhosts_access.logに出力されます。それを見逃す人はしばしばいます。
ログしているIPを確認してください。 ロードバランサー、CDN、またはリバースプロキシの背後では、すべてのリクエストがプロキシからのように見えることがあります。サーバーが本来のクライアントをログするように設定されていない限り、そのようになります:Nginxのset_real_ip_fromとreal_ip_header、Apacheのmod_remoteipです。すべての行に同じ数の内部IPが表示される場合、攻撃者のアドレスはX-Forwarded-For(ログしている場合)はやプロキシ自身のログにのみあります。
フォーマットを確認。 両方のサーバーはデフォルトで“combined”フォーマットを使用しますが、多くの設定がこれをカスタマイズしています(Nginxのlog_format、ApacheのLogFormat)。アップロードする前にあなたのものがどのように見えるか確認してください。
権限。 DebianとUbuntuではこれらのログはrootとadmグループが読み取れます;他のところでは、sudoを計画しておいてください。
ログファイルからエクスポート
ログは毎日または毎週ローテートするので、ローテートされたファイルを含めてください。zcat -fはプレーンファイルとgzippedファイルの両方を読み込みます:
# Nginx、現在とローテートされたもの、最古のものから
sudo zcat -f $(ls -tr /var/log/nginx/access.log*) > web-03_nginx_access.log
# RHEL上のApache
sudo zcat -f $(ls -tr /var/log/httpd/access_log*) > web-03_httpd_access.lo
単一の日の場合、結合形式のタイムスタンプでgrepが十分です:
grep '19/Oct/2026' web-03_nginx_access.log > web-03_access_1019.log
エラーログも取ってください。上流の失敗、PHPエラー、および一部のエクスプロイト試行はそこにのみ表示されます。
コンテナからエクスポート
# Docker: stdoutはアクセスログ、stderrはエラーログ
docker logs --since 2026-10-19T00:00:00 --until 2026-10-20T00:00:00 nginx > nginx_access.log 2> nginx_error.log
# Kubernetes
kubectl logs deploy/nginx --since=24h > nginx.log
コンテナログは、何かがそれらを収集しない限り、コンテナと共に消えます。ポッドが交換された場合は、クラスタのログコレクタを確認してください。
注目すべき点
| パターン | 通常の意味 |
|---|---|
| /.env, /.git/config, /wp-login.php, /phpmyadminへの404のバースト | 自動スキャン |
| ../, ${jndi:, union select, のURL内 | エクスプロイト試行:トラバーサル、Log4Shell、SQLインジェクション、XSS |
| アップロードディレクトリ下の奇妙なファイルへのPOSTでの200 | 可能なウェブシェル;IPが他に何を要求したかを見てみてください |
| sqlmap, nikto, nucleiのようなユーザーエージェント | 隠そうとしなかったツール |
| 奇妙なリクエスト後の5xxのスパイク | 何かが壊れた、恐らくエクスプロイトが成功したため |
LogTotalでアップロード、サニタイズ、レビュー
- アップロード。 開く logtotal.com そしてファイルをドロップします。
- サニタイズ。 [what gets masked: client IPs, hostnames, usernames and tokens in URLs]. Look it over before you continue. Query strings often carry session tokens.
- レビュー。
それがうまくいかないとき
| 症状 | 考えられる原因 | Fix |
|---|---|---|
| /var/log/nginxがない | カスタムパス、またはコンテナ内で実行される | nginx -T、またはdocker logs |
| access.logは存在するが空 | ログはstdoutに出力されるか、access_logがオフ | 設定とコンテナを確認 |
| すべてのリクエストが同じIPから来ている | プロキシまたはロードバランサーが前にあり;実際のIPが設定されていない | X-Forwarded-Forまたはプロキシのログを使用 |
| 最近数日だけ | ローテートされたファイルが除外された | *グロブを使用してzcat -fコマンドを使う |
| 権限がない | rootでない、admに属していない | sudo |
FAQ
アクセスログとエラーログのどちらが重要ですか?
アクセスログは何が要求されたかを教えてくれます。エラーログは何が壊れたかを教えてくれます。エクスプロイトのケースでは、両方を横に並べて確認したいです。
IISについてはどうですか?
IISはデフォルトでC:inetpublogsLogFilesにW3Cログを書き込みます。それ専用のガイドがあります。