不正アクセスのログ確認・解析方法｜見るべきログと攻撃痕跡の調べ方を実践解説

サーバーが不正アクセスを受けたか調べる作業は、当てずっぽうにログを眺めても進まない。「どのログを・どの順で・何を手がかりに見るか」が決まっていれば、Webサーバーのアクセスログと認証ログだけでも侵入の痕跡はかなり絞り込める。このページでは、確認すべきログの種類、アクセスログの読み方、grepでの痕跡抽出、送信元IPの評価、そして見落とされがちなログ改ざんへの備えまでを、実際のコマンドと攻撃パターン別の判断基準つきで解説する。

まとめ：不正アクセスのログ確認は「対象ログ→抽出→痕跡照合」の順で進める

• 確認するログは3層：Webサーバーのアクセスログ（Apache／Nginx）、OSの認証ログ（Linux auth.log／secure・Windowsイベントログ）、ネットワーク境界のWAF／ファイアウォールログ。侵入経路の推定にはこの3つを突き合わせる。
• 手がかりは4パターン：連続する認証失敗（ブルートフォース）、404の連発（スキャン・探索）、URLに紛れた攻撃文字列（SQLインジェクション・ディレクトリトラバーサル）、見慣れないファイルへのPOST（Webシェル）。
• 抽出はgrep／awkで機械的に。まず送信元IPを頻度集計し、上位IPの時系列とステータスコードを追う。目視で全行を読まない。
• 送信元IPは外部評価と照合：WHOIS・AbuseIPDB・Shodanで素性を確認し、正当なクローラーか攻撃元かを切り分ける。
• ログ自体が改ざん・消去される前提で守る：ログを別ホストへ集約し、証拠として保全してから解析する。改ざん済みログは「痕跡が無い＝安全」ではない。

不正アクセスの調査で押さえるログ（Web・OS・境界の3層）

不正アクセスの痕跡は1種類のログには収まらない。攻撃者はWeb経由で侵入し、OSにログインし、外部へ通信する。それぞれの段階が別のログに残るため、調査は「Web→OS→境界」の3層で対象を押さえる。

Webサーバーのアクセスログ（Apache／Nginx）

公開サーバーへの攻撃は、まずWebサーバーのアクセスログに現れる。Apacheは既定で/var/log/apache2/access.log（RHEL系は/var/log/httpd/access_log）、Nginxは/var/log/nginx/access.logに、どのIPがどのURLへどのメソッドでアクセスし、サーバーが何を返したか（ステータスコード）を1行ずつ記録する。攻撃の探索行為・脆弱性の悪用試行はここに残るため、調査の起点になる。エラーログ（error.log）も併読すると、PHPの実行エラーや拒否された処理から侵入試行を裏取りできる。

OSの認証ログ（Linux auth.log／secure・Windowsイベントログ）

SSHやログイン認証への攻撃はOSの認証ログに残る。Debian／Ubuntu系は/var/log/auth.log、RHEL／CentOS系は/var/log/secureに、SSHログインの成否・sudoの実行・アカウント操作が記録される。Windowsではイベントビューアーの「セキュリティ」ログで、イベントID4625（ログオン失敗）の多発がブルートフォース、4624（ログオン成功）の見慣れない時間帯・アカウントが侵入の兆候になる。アカウント作成（4720）や権限昇格も同ログで追える。イベントビューアーの「現在のログをフィルター」でイベントIDを指定すれば絞り込め、コマンドラインならwevtutil qe Security /q:"*[System[(EventID=4625)]]" /f:textでログオン失敗だけを抽出できる。

ネットワーク機器・WAF・ファイアウォールのログ

境界のログは「そもそも到達したか／防がれたか」を示す。WAFのログには遮断した攻撃パターン（SQLインジェクション、クロスサイトスクリプティング等）のシグネチャ名が残り、ファイアウォールのログにはポートスキャンや許可外ポートへの接続試行が並ぶ。SSL／TLSの接続ログ（ssl_access.log等）はHTTPS経由の通信を分離して確認でき、暗号化通信に紛れた攻撃の切り分けに使う。WAFの役割と選び方はWAFの仕組みとIPS・IDSとの違いを解説した記事にまとめている。

アクセスログのフォーマットと不審な兆候の読み方

Apache／Nginxの標準的な記録形式は「Combined Log Format」で、以下のフィールドが空白区切りで並ぶ。フィールドの意味を押さえておくと、どこを見れば攻撃を判別できるかが分かる。

203.0.113.45 - - [18/Jul/2026:03:12:44 +0900] "GET /admin/login.php HTTP/1.1" 401 512 "-" "sqlmap/1.8"

ステータスコードは判断の軸になる。401・403の連続は認証突破の試行、404の連発は管理画面や脆弱なファイルを探すスキャン、攻撃文字列を含むURLに対する200は攻撃が成立した疑いを示す。User-Agentがsqlmap・nikto・masscanのような診断ツール名、あるいは空欄・不自然な文字列のリクエストも警戒対象になる。ただしUser-Agentは容易に詐称できるため、単独の証拠にはせず送信元IPと挙動で裏付ける。

不審なアクセスログの痕跡を見つける手順

数万行のログを目視で追うのは非効率で見落としも出る。grepとawkで機械的に絞り込み、頻度と時系列で異常を浮かび上がらせる。

送信元IP・ステータスを集計して異常を絞り込む

まず送信元IPを頻度順に集計し、突出したIPを洗い出す。次にそのIPのアクセスだけを抜き出し、時系列とステータスを追う。

# 送信元IPをアクセス回数の多い順に集計
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

# 特定IPのアクセスを時系列で確認
grep '203.0.113.45' access.log

# 認証失敗(401/403)だけを抽出して攻撃元を特定
awk '$9==401 || $9==403 {print $1}' access.log | sort | uniq -c | sort -rn

短時間に同一IPから数百〜数千のリクエストが集中していれば自動化ツールによる攻撃、少数のIPが多数のパスに404を出していれば探索行為だと判断できる。SSHのブルートフォースは認証ログ側で確認する。

# SSHログイン失敗の送信元IPを集計（Debian/Ubuntu系）
grep 'Failed password' /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn

攻撃パターン別の痕跡（スキャン・SQLi・トラバーサル・Webシェル）

攻撃の種類ごとにログに残る文字列は決まっている。以下のパターンをgrepで照合すると、成立・未遂を問わず試行の痕跡を拾える。

# SQLインジェクション・トラバーサルの試行痕跡を横断検索
grep -Ei "union select|' or |\.\./|etc/passwd|<script" access.log

ポートスキャンはWebアクセスログではなくファイアウォール／IDSのログに現れる。単一の送信元IPが短時間に多数のポート宛て接続を試みていれば、侵入前の下見（探索）と判断してよい。この段階で送信元IPを遮断すれば、本格的な攻撃の前に食い止められる。

送信元IPの信頼性を評価する方法

集計で浮かんだIPが「正当なクローラー」か「攻撃元」かは、外部の評価サービスで裏取りする。IPアドレスだけで善悪は判断できないため、複数ソースを突き合わせる。

• WHOIS：IPの割り当て組織・国を確認する。自社と無関係な海外のホスティング事業者からの管理画面アクセスは警戒対象。
• AbuseIPDB：そのIPが過去に攻撃・スパムで報告されているかを信頼度スコアで確認できる。
• Shodan：IPが公開しているサービス・ポートを調べ、攻撃用ホストか踏み台かを推定する。
• VirusTotal：IP・ドメイン・URLの評価を複数のセキュリティベンダー横断で確認する。

正当なGooglebot等はWHOISと逆引きで公式レンジと一致するかを確認できる。逆引きが一致しないのに検索エンジンを名乗るUser-Agentは偽装であり、遮断対象と判断する。

不正アクセスのログ解析に使えるツール

手作業のgrepで当たりを付けたら、専用ツールで網羅性と継続性を補う。

IPA iLogScanner（攻撃兆候の自動検出）

IPA（情報処理推進機構）が無償公開するiLogScannerは、Webサーバーのアクセスログを読み込み、SQLインジェクションやディレクトリトラバーサル等の攻撃兆候を自動で検出する。SSH・FTPサーバーのログにも対応する。かつてのオンライン版は2019年1月16日に終了したが、オフライン版はIPA公式サイトから引き続きダウンロードできる（動作にJava実行環境が必要。IPA公式ではOpenJDK 25までが対応で、JDK 26以降は非対応。GUI／コマンドライン両対応）。まず全体の攻撃兆候を機械的に把握する用途に向く。

CyberChef（難読化されたリクエストのデコード）

攻撃リクエストはURLエンコードやBase64で難読化されていることが多い。ブラウザで動くGCHQ製のCyberChefを使えば、ログから抜き出した%2e%2e%2fのような文字列をURLデコード・Base64デコードして、実際に何を送っていたかを復元できる。具体的には「URL Decode」→「From Base64」のレシピをドラッグで繋ぎ、入力欄にログの文字列を貼れば復元結果が右に出る。ペイロードの意図を読み解く際の定番ツールになる。

SIEM・fail2banによる継続的な監視

1回の調査で終わらせず継続的に監視するなら、fail2banで認証失敗が閾値を超えたIPを自動遮断し、SIEMで複数サーバーのログを集約・相関分析する。個別のログでは見えない「同一IPがWebと認証を横断して試行している」といった攻撃も、集約して初めて浮かぶ。仕組みはSIEMの機能とEDR／SOARとの違いを解説した記事を参照してほしい。

ログ改ざんへの備えと証拠保全

見落とされがちだが、攻撃者は侵入後に自らの痕跡を消す。サーバー上のログを消去・改ざんできる状態のまま解析すると、「痕跡が無い＝安全」という誤った結論に至る。ログは改ざんされる前提で守り、解析前に証拠として保全する。

• ログを別ホストへ集約する：syslog転送やログ収集基盤で、侵入されたサーバーの外にリアルタイムで複製を持つ。攻撃者がローカルのログを消しても集約先が残る。
• 改ざんを検知する：ファイル整合性監視（AIDEやTripwire等）でログ・重要ファイルのハッシュを定期照合し、書き換えを検出する。ログの日時が不連続に飛んでいたら消去・改ざんのサイン。
• 解析前に証拠保全する：調査は元ログのコピーに対して行い、原本はハッシュ値（SHA-256等）を取って保全する。法的対応や外部報告に備え、取得日時・取得者を記録しておく。

証拠保全を後回しにすると、解析中に自分でタイムスタンプを上書きし、証拠能力を損なうことがある。「触る前にコピーとハッシュ」を徹底する。

不正アクセスを検知した後の初動対応

ログから侵入が確認できたら、解析と並行して被害の拡大を止める。優先順位は「隔離→範囲特定→認証情報の無効化→報告」。

• 隔離：侵害されたサーバーをネットワークから切り離し、攻撃元IPを遮断する。ただし証拠保全前に電源を落とすと揮発性の証拠が消えるため、ネットワーク遮断を優先する。
• 範囲特定：ログの時系列から、いつ・どこから侵入され、どのアカウント・データに触れたかを追う。認証ログとアクセスログの突き合わせで横展開の有無を確認する。
• 認証情報の無効化：侵害された可能性のあるアカウントのパスワード・APIキー・SSH鍵をすべて再発行する。
• 報告：個人情報の漏えいが疑われる場合は、社内規程と法令に沿って速やかに報告する。実際の企業インシデントの経緯は村田製作所の不正アクセス事例（原因と対応）が参考になる。

よくある質問

不正アクセスのログはどこを見ればいいですか？

Webサーバーのアクセスログ（Apacheはaccess.log、Nginxは/var/log/nginx/access.log）を起点に、OSの認証ログ（Linuxはauth.log／secure、Windowsはイベントビューアーのセキュリティログ）、WAF・ファイアウォールのログを突き合わせます。Web経由の攻撃はアクセスログ、ログイン試行は認証ログに残ります。

ログから不正アクセスの痕跡を検索するにはどうすればいいですか？

grepとawkで送信元IPを頻度集計し、突出したIPの時系列とステータスコードを追います。401・403の連続はブルートフォース、404の連発はスキャン、URLにunion selectや../を含むリクエストはSQLインジェクション・ディレクトリトラバーサルの痕跡です。IPA iLogScannerで攻撃兆候を自動検出すると網羅的に把握できます。

アクセスログが改ざんされていないか確認するには？

ファイル整合性監視ツール（AIDE・Tripwire等）でハッシュを定期照合し、書き換えを検出します。ログの日時が不連続に飛んでいる、特定期間だけ記録が欠けている場合は消去・改ざんの疑いがあります。改ざんに備え、ログは別ホストへリアルタイムに集約しておくのが確実です。

ポートスキャンのログはどう確認しますか？

ポートスキャンはWebアクセスログではなく、ファイアウォールやIDSのログに現れます。単一の送信元IPが短時間に多数のポート宛てへ接続を試みていればスキャンです。侵入前の探索段階なので、この時点で送信元IPを遮断すれば本格的な攻撃を未然に防げます。

不正アクセスの証拠としてログを保全するには？

解析は元ログのコピーに対して行い、原本はSHA-256等のハッシュ値を取得して保全します。取得日時・取得者を記録し、原本には手を加えません。触る前にコピーとハッシュを取ることで、解析中の上書きによる証拠能力の毀損を防げます。

関連記事

• SIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説【2026年時点】
• WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説
• 村田製作所の情報漏洩（2026年不正アクセス）｜原因・被害範囲8.8万件と取引先の対策