アクセスログから不正アクセスの兆候を見つける7つの集計（nginx/Apache対応・コピペOK）

手順 0：ログに「本当のクライアントIP」が入っているか確認する

ここを確認しないと以降の集計は全部むだになります。Cloudflare・ロードバランサ・リバースプロキシ配下では、何もしなければ記録されるのはプロキシのIPです。上位が全部同じIPになり、そのまま fail2ban に食わせると自サイトへの入口ごと遮断してしまいます。

tail -1 /var/log/nginx/access.log

nginx の場合（realip モジュール）

set_real_ip_from 173.245.48.0/20;   # 信頼するプロキシのレンジを列挙
real_ip_header    CF-Connecting-IP;  # 既定は X-Real-IP
real_ip_recursive off;

• モジュールの有無は nginx -V 2>&1 | tr ' ' '\n' | grep realip で確認（パッケージ版には通常含まれる）
• set_real_ip_from に書いていない相手からのヘッダは無視される。0.0.0.0/0 のように全開にすると誰でもIPを詐称できるので、必ず経路のレンジだけ書く

Apache の場合（mod_remoteip）

ログ書式を %h から %a に変えるのがポイント（%a = 復元後のクライアントIP、%{c}a = 直前の接続元＝プロキシ）。

RemoteIPHeader       CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20

LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined_realip
CustomLog ${APACHE_LOG_DIR}/access.log combined_realip

反映後、自分の回線からサイトを開いて tail -1 に自分のIPが出れば準備完了です。

集計の共通部分（awk のフィールド位置）

combined 形式は nginx・Apache ともフィールド位置が同じなので、同じ awk がそのまま使えます。

203.0.113.10 - - [10/Sep/2026:07:12:33 +0900] "POST /wp-login.php HTTP/1.1" 200 1234 "-" "curl/8.5.0"
$1           $2$3 $4                    $5    $6    $7             $8       $9  $10  $11  $12

• $1 = 送信元IP ／ $6 = メソッド（先頭に " が付く）／ $7 = パス ／ $9 = ステータス ／ $10 = 応答サイズ
• ローテート済み過去分も対象に。GNU の zcat -f は非圧縮ファイルもそのまま流すので .gz と生ログを混ぜて渡せる

LOGS="/var/log/nginx/access.log /var/log/nginx/access.log.1 /var/log/nginx/access.log.*.gz"
zcat -f $LOGS | wc -l

Apache は /var/log/apache2/access.log*（RHEL系は /var/log/httpd/access_log*）に読み替え。

7つの集計コマンド

1送信元IPの上位 — 全体像の把握

zcat -f $LOGS | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

• 上位に自社の監視サービス・クローラ・CDNが並ぶのは正常。知らないIPが桁違いのリクエスト数で1位なら以降の集計で中身を確認

2ログイン系エンドポイントへの POST — 最も分かりやすい兆候

zcat -f $LOGS | awk '$6=="\"POST" && $7 ~ /wp-login\.php|xmlrpc\.php/ {print $1}' \
  | sort | uniq -c | sort -rn | head -20

• 正規の運用で wp-login.php にPOSTが飛ぶのは担当者がログインした回数だけ。1つのIPから数百〜数千回あれば総当たり攻撃（ブルートフォース）
• xmlrpc.php は使っていなければ本来0件。数字が立つこと自体が異常

3404を量産しているIP — 脆弱性スキャナの動き

zcat -f $LOGS | awk '$9==404 {print $1}' | sort | uniq -c | sort -rn | head -20

• 存在しないパスを片端から叩いている相手。1つのIPから数百件の404 = サイトを狙って調べられている

4「何を探されているか」の一覧

zcat -f $LOGS | awk '$9==404 {print $7}' | sed 's/?.*//' \
  | sort | uniq -c | sort -rn | head -30

• 狙われている対象がそのまま並ぶ（/.env, /.git/config, /wp-config.php.bak, /phpinfo.php 等）。このリストは「自分のサイトで絶対に200を返してはいけないパスの一覧」でもある

5そのうち2xxで返ってしまっているもの — ⚠️ 最重要

zcat -f $LOGS | awk '$9 ~ /^2/ && $7 ~ /\.env|\.git|\.bak|\.old|\.sql|\.zip|wp-config|phpinfo|adminer|phpmyadmin|\.DS_Store/ {print $7}' \
  | sed 's/?.*//' | sort | uniq -c | sort -rn | head -30

6転送量の多い送信元 — 持ち出し検知

zcat -f $LOGS | awk '$9 ~ /^2/ {b[$1]+=$10} END {for (i in b) printf "%15.0f  %s\n", b[i], i}' \
  | sort -rn | head -20

• 応答サイズをIPごとに合計。1件ずつは目立たなくても合計が突出している相手は、コンテンツ大量取得やファイル持ち出しの可能性（Apacheの %b は0バイト時 - だが、awkの加算では0扱いなので影響なし）

7User-Agent の偏り

zcat -f $LOGS | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20

• ダブルクォート区切りで6番目がUA。空の - やツール名が上位なら集計1〜3と突き合わせる。ただしUAは自由に名乗れるので単独の根拠にはしない

兆候を「1日1回の差分」にする運用

手で叩くのは最初の1回だけにして、あとは日次で回し前日との差分だけを見るのが続けるコツ。スクリプト /usr/local/bin/access-log-digest.sh を cron で毎朝6:05に回し、前日分のダイジェスト差分をメールで受け取る構成が紹介されています。

• 404を出しているIP上位10 と 2xxで返っている要注意パス（空であること） の2集計を日次出力し diff -u で差分確認
• 「毎日全文を読む運用は続きません。差分だけを見て、増えた行があるときだけ元ログを開く」

見つけた相手を fail2ban で自動遮断する

集計2・3で常連が特定できたら自動遮断へ。fail2ban の既定値は maxretry=5 / findtime=10m / bantime=10m（1.1.0）＝「10分以内に5回で10分BAN」。

自作フィルタとjailの例

# /etc/fail2ban/filter.d/wordpress-auth.conf
[Definition]
failregex = ^<HOST> .* "POST [^"]*/(wp-login\.php|xmlrpc\.php)
ignoreregex =

# /etc/fail2ban/jail.local
[wordpress-auth]
enabled  = true
filter   = wordpress-auth
port     = http,https
logpath  = /var/log/nginx/access.log
maxretry = 10        # 正規の打ち間違いを弾かない程度に緩める
findtime = 10m
bantime  = 1h
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24   # 自社オフィス・監視サービスのIPを必ず入れる

[recidive]           # 繰り返しBANされる常習者を長期BAN
enabled  = true

有効化前の確認コマンド

# 手元のログに何件マッチするか確認（BANはしない）
fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress-auth.conf

fail2ban-client reload
fail2ban-client status wordpress-auth      # 現在のBAN一覧
fail2ban-client set wordpress-auth unbanip 203.0.113.10   # 誤爆の解除

誤爆させないための3ポイント

1. ignoreip に自社IP・監視サービス・決済/予約システムのWebhook送信元を先に入れる。自分が締め出されるのが最も多い事故
2. リバースプロキシ配下では手順0を必ず先に。復元していないとCDNのIPをBANして全訪問者が落ちる
3. maxretry はいきなり絞らない。数日 bantime = 10m で様子を見てから伸ばす

ログが残っていない、という落とし穴

• 保持期間：侵入の発覚は数週間後になることが多いのに、日次・十数世代のままの環境が目立つ。/etc/logrotate.d/nginx の rotate を確認し、compress 併用で90日程度まで伸ばす
• バッファリング：access_log ... combined buffer=64k flush=5m; だと直近の行はすぐ出ない。調査中は flush を意識
• ノイズ：死活監視で1日数万行が埋まるなら除外すると集計が読みやすくなる

  # nginx: ヘルスチェックだけログに書かない
  location = /healthz {
      access_log off;
      return 200;
  }

  # Apache: 条件付きロギング
  SetEnvIf Request_URI "^/healthz$" dontlog
  CustomLog ${APACHE_LOG_DIR}/access.log combined_realip env=!dontlog

まとめ

• 最初にログのクライアントIPが本物かを確認する（realip / mod_remoteip）
• 集計5（2xxで返っている要注意パス）だけは意味が違う。出たら遮断より先にファイルの削除と認証情報の変更
• 日次のダイジェスト＋差分で回し、増えたときだけ元ログを開く
• 常連は fail2ban へ。ignoreip を先に埋め、fail2ban-regex で当たりを確認してから有効化する

関連記事（著者による）

• 「.git」「.env」が公開されていないかを 1 行で防ぐ設定
• nginx レート制限で総当たり・スクレイピング・軽量 DoS を緩和する設定
• WordPress ログイン総当たり対策 5 選（wp-login.php 保護・xmlrpc 無効化）