疑似障害から学ぶ!アクセスログ解析とLinuxディスク容量調査コマンド

2026.07.07

• 技術ブログ
• インフラ関連

3

15

はじめに

初めまして！26卒インフラエンジニアのえび🦐です！！

インフラエンジニアの実務研修の一環として、先輩社員が仕掛けた「疑似障害 (サーバー攻撃）」に対処する疑似障害研修を行いました。

今回は、実際にサーバーを襲った2つの疑似障害の概要と、統合監視ツール「Zabbix」のアラートを起点に、私たちがどのように原因を調査・特定したのかを技術的に解説します👓！

今回のサーバー構成

今回のサーバー構成は以下の通りです。

今回障害が起きたのはWEBサーバーのうちの一台です。

サーバーを襲った2つの「疑似障害」

今回の研修では、以下の2つの攻撃が仕掛けられました💀

1. ブルートフォース・ディレクトリ・スクレイピング ：Webサーバーに対し、公開されていないファイルやディレクトリのパスを総当たり (ブルートフォース)で探索し、情報を抜き取ろうとするWeb攻撃です。今回はこれによりWebサーバーのCPU負荷が急上昇しました。
2. ディスク容量の圧迫 （ダミーファイルの大量生成）：サーバー内部の各ディレクトリに、人為的に大容量のダミーファイルを生成し、ディスクの空き容量を無くすことでシステムを機能不全に陥らせる攻撃です。
   いずれも実際の運用保守において遭遇する可能性が高い、実戦的な攻撃たちです！

異変を検知した監視ツール「Zabbix」

Zabbixとは？

Zabbixは、サーバー、ネットワーク、アプリケーションの状態を24時間365日監視し、障害検知やアラート通知を自動化する世界シェアトップクラスのオープンソース (OSS)統合監視ソフトウェアです。

参考：Zabbix公式 （https://www.zabbix.com/jp）

【主な機能】

• 死活監視・リソース監視：Pingによる応答確認、CPU使用率、メモリ使用量、ディスク残容量などを測定します。
• 障害検知：事前設定した「しきい値」（今回の例で言えばCPU負荷「5」やディスク「80%」など）を超えた場合に自動で異常を検知します。
• アラート通知：障害発生時に電子メールやチャットツール （Chatwork,Slackなど）で即座に担当者へ通知します。
• 可視化(グラフ化)：収集したデータをブラウザ上でリアルタイムにグラフ化し、ダッシュボードで一元管理できます。

【メリットとデメリット】

• メリット：ライセンス費用が完全に無料 （オープンソース）でありながら、商用ツールに匹敵する高度な監視と拡張性を備えています。
• デメリット：システム自体の自前構築はもちろん、Datadog等のほかSaaSに比べて「設定が自由すぎてGUIも独特」なのがZabbixの難点です。独自の概念をマスターするまでの学習コストが高く、閾値のチューニングもすべて自力で行うため、運用工数がかかってしまいます…💦

下記リンクではより詳しく解説しているので参考にしてみてください！！

参考：Zabbixとは？ 監視の基本概念と導入のメリット（https://qiita.com/minesyouto8833/items/68f2c39eafc8a8bd2f47）

今回のアラート通知

今回、これらの異常をいち早く検知し、私たちに通知してくれたのが、統合監視ツールである「Zabbix (ザビックス）」です。 障害発生時、Zabbixから以下のようなアラート通知が届きました。

① Webサーバーのアラート（CPU高負荷）： PROBLEM: <研修用サーバーの名前> CPU Load Averageが 5 を超えました。

• 現在の値： 24.185 （深刻度：Warning）

② 踏み台サーバーのアラート（ディスク圧迫）： PROBLEM: <研修用サーバーの名前> の disk / 使用率が80% を超えました。

• 現在の値： 82.09 % （深刻度：Warning）

攻撃手法の特定と解決に使用したコマンド・ログ解説

ここからは、私たちが実際に原因特定のために使用したコマンドやログの読み解き方を解説します。

 攻撃の足跡を暴く「アクセスログの解析」

 Webサーバーの急激なCPU高負荷の原因を特定するには、アクセスログにおける「大量アクセスIP」「リクエストパス」「HTTPステータスコード」の3点をクロスチェックすることが重要です。なぜなら、外部からのWeb攻撃は必ずWebサーバーのアクセスログにその痕跡が残るため、トラフィックの異常な急増を確認した際は、ログの生データを見ることで攻撃手法を特定できるからです！

今回使用したコマンドはgrepコマンドとawkコマンドです。

grepコマンドとは、ファイルやコマンドの出力から指定した文字列や正規表現に一致する行を検索・抽出する強力なLinuxコマンドです。

awkコマンドとは、テキストデータやログファイルを1行ずつ読み込み、指定した条件に一致する行の抽出や、列 （フィールド）ごとの加工・集計を効率的に行えるテキスト処理コマンドです。

これら2つを組み合わせることでアラート発生時間のアクセスログのみと見たい情報のみが表示されるようにしました。

下記は使用例です！アラート発生時間の該当IPからの分間アクセス数を表示させるのに使用しました！

# ログから「アラート発生時間」を抽出し、時間帯ごとの発生件数を多い順に集計
$ grep -E "アラート発生時間" /var/log/httpd/xxxxxx | awk '{print $1}' | sort | uniq -c | sort -nr

下記リンクではより詳しく、わかりやすく解説しているので参考にしてみてください！！

参考：grepやawkコマンドで、ログファイルから欲しい情報を取得する！ （https://cgs580.hatenablog.com/entry/2023/12/03/155302）

実際に確認したアクセスログの一部抜粋が以下となります。

▼ アラート発生時間の該当IPからの分間アクセス数 (※左端の数字がアクセス件数)
383 54.250.xx.xx ★日本
292 47.128.xx.xx ★シンガポール

▼ 該当IPがアクセスしたパスとリクエストステータス (※左端の数字がアクセス件数)
10 54.250.xx.xx/swagger-ui.html 404
9 54.250.xx.xx/www.zip 404
8 54.74.xx.xx/.env.production 404

日本やシンガポール、アメリカなどの複数IPから、/swagger-ui.html や /.env.production といった重要な設定ファイルを狙った、短時間での大量アクセスが確認されました。 幸い、リクエストステータスはすべて 「404 (Not Found）」 であり、Webサーバー側で正しく「存在しない」と返していたため、現時点での攻撃による情報漏洩はないと判断できました。なお、攻撃IPからのアクセスが止まったため、CPU負荷も正常値に戻っています。

このように、CPU高負荷時は単にサーバーを再起動するだけでなく、アクセスログから「誰が（IP）」「どこに（パス）」「どうなった（404など）」を読み解くことが、正しいWeb攻撃の状況把握に繋がります！

 内部の異常を見つける「Linuxディスク容量調査コマンド」

ディスク圧迫アラートを解決するためには、df コマンドで全体の状況を把握し、du コマンドや ls コマンドを使ってディレクトリを階層ごとに絞り込んでいくアプローチが適切です。 Zabbixのアラートだけでは「どこのファイルが容量を食いつぶしているか」までは分からないため、OSレイヤー（Linux）のコマンドを駆使して、異常に肥大化しているディレクトリや隠しファイルを特定していく必要があります。

実際に調査した流れは以下の通りです。

# 1. ファイルシステムの種類と、全体のディスク使用状況を確認
$ df -hT
# → ルートディレクトリ (/)の使用率が82%になっていることを確認

# 2. 他のファイルシステムを除外して、ルート直下の容量を大きい順に並び替えて調査
$ du -hx --max-depth=1 / | sort -hr
# → /root などが通常より不自然に大きいことを特定

# 3. ターゲットのディレクトリ (/root)をさらに深く、大きい順に並び替えて絞り込み
$ du -hx --max-depth=1 /root | sort -hr

# 4. 隠しファイルも含めて、ファイル単体の容量まで全て洗い出す
$ du -hax --max-depth=1 /root | sort -hr

# 5. lsコマンドで詳細情報を確認
$ ls -laH /root

# 6. 容量と同時に「最終更新日時」も表示させ、いつ生成されたダミーファイルかを特定する
$ du -hax --time --max-depth=1 /root | sort -hr

この詳細調査により…以下の計約14GBもの不審なダミーファイル（dummyfile）が発見されました👀！！

• /opt/dummy_data.bin (3.5G）
• /home/.dummy_backup.tar (3.5G）
• /var/log/dummy_app.log.bak (4.0G）
• /tmp/.dummy_cache.dat (3.5G）

今回このサーバーのストレージは20GBなので結構ミッチミチになってしまっていますね…(;'∀')

確認したところ中身はすべて空（0書き込み）であり、先輩が仕込んだ疑似障害用のファイルであることが判明しました。私たちはこれらを速やかに削除（クリーンアップ）し、ディスク容量を元の安全な状態へと復旧させました。

duコマンドについてもう少し詳しく！

du (disk usage)コマンドは、LinuxやmacOSなどのUNIX系OSで、ファイルやディレクトリが占有しているディスク容量を調べるコマンドです。

以下はdu (disk usage)コマンドの主なオプション一覧です。

よく使うものをまとめてみました！

 最もよく使われる基本オプション

 研修を終えて

今回の疑似障害対応を通じて、インフラエンジニアに必要な「ログ分析能力」と「OS内部の調査能力（Linuxコマンドの扱い方）」の大切さを身を以て学ぶことができました。

障害発生時は一瞬焦ってしまいますが、Zabbixが発報したアラートを元に、一つずつ論理的に原因を紐解いていくことで、安全かつ確実に復旧させることができます！

今回の研修で得た経験とスキルをもとに、今後どのような障害が発生しても、冷静に対処できる頼もしいエンジニアを目指して、これからも日々の業務に全力で励んでいきます！

最後まで読んでいただき、ありがとうございました<(_ _)>

この記事がお役に立てば【 いいね 】のご協力をお願いいたします！

3

読み込み中...

3

15