NginxとApacheのアクセスログの見つけ方

NginxとApacheのアクセスログの見つけ方

SOC Prime Team
SOC Prime Team linkedin icon フォローする

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でアップロード、サニタイズ、レビュー

  1. アップロード。 開く logtotal.com そしてファイルをドロップします。
  2. サニタイズ。 [what gets masked: client IPs, hostnames, usernames and tokens in URLs]. Look it over before you continue. Query strings often carry session tokens.
  3. レビュー。

それがうまくいかないとき

症状考えられる原因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ログを書き込みます。それ専用のガイドがあります。

SOC PrimeのDetection as Codeプラットフォームに参加し ビジネスに最も関連性のある脅威に対する可視性を向上させましょう。開始して即座に価値をもたらすためには、今すぐSOC Primeの専門家とのミーティングを予約してください。