Linuxエンジニア養成講座 第33回｜全36回・フェーズ4「サーバー構築と運用」の6回目（6/9回目）です。
前回: 第32回で Prometheus + node_exporter による監視を体験し、「ユーザーが気づく前にエンジニアが検知する」という監視の設計思想を学びました。
今回学ぶこと: CVE の読み方、セキュリティアップデート、fail2ban による攻撃緩和、aide によるファイル改ざん検知を実践します。
前回の予告で「CVE の読み方、dnf update --security によるセキュリティアップデート、fail2ban や aide を使ったセキュリティ対策を扱います。第3回で学んだセキュリティ意識の基本を、具体的なツールと手順で実践する回です」とお伝えしました。第3回ではパスワード管理や情報の取り扱いといった「意識」を学びましたが、今回はその意識を「ツールと手順」で具体化します。
この記事を読み終えると、以下のことができるようになります。
- CVE 番号の意味を理解し、
dnf updateinfoでセキュリティ通知を確認できる dnf update --securityでセキュリティアップデートの対象を把握できる- fail2ban を導入し、SSH ブルートフォース攻撃への自動防御を設定できる
- aide でファイルのベースラインを作成し、改ざん検知の仕組みを構築できる
なぜセキュリティ運用が必要か
サーバーを構築して終わりではありません。なぜ運用フェーズでもセキュリティを意識し続ける必要があるのか、考えてみてください。
ソフトウェアの脆弱性は日々発見されています。昨日まで安全だったサーバーが、今日公開された脆弱性によって攻撃対象になることがあります。攻撃者は自動ツールでインターネット上の脆弱なサーバーを探し回っており、パッチが当たっていないサーバーを見つけると即座に攻撃を仕掛けてきます。
攻撃が成功すると何が起きるでしょうか。ユーザーの個人情報やクレジットカード情報が漏洩する。ランサムウェアで業務データが暗号化され事業が停止する。情報漏洩の規模によっては賠償金と信用失墜で企業の存続すら危うくなります。セキュリティ運用は「技術的な作業」ではなく、ユーザーのデータを守り、事業を存続させるための責任です。パッチ1つの放置が、最悪の場合、会社を潰しかねません。
セキュリティは「一度設定すれば終わり」ではなく、継続的に守り続ける運用です。そのためには複数の防御層を組み合わせる「多層防御」の考え方が重要です。今回学ぶ3つのツールは、この多層防御の中でそれぞれ異なる役割を担います。
- CVE / セキュリティアップデート: 脆弱性の特定と修正 — 既知の脆弱性にパッチを当てる
- fail2ban: 攻撃の自動緩和 — ブルートフォース攻撃を検知して自動的にブロックする
- aide: 侵害の検知 — ファイルが改ざんされていないか定期的に確認する
これらの対策に共通する設計思想がアタックサーフェス（攻撃対象面）の最小化です。アタックサーフェスとは、攻撃者がシステムに侵入できる「入口」の総面積のことです。
このシリーズで学んできたセキュリティ対策を振り返ると、すべてアタックサーフェスの縮小につながっています。
- 第20回 firewalld — 不要なポートを閉じる = 入口を減らす
- 第27回 sshd ハードニング — パスワード認証を無効化、root ログイン禁止 = 入口を狭める
- 第28回 SELinux — プロセスのアクセス範囲を制限 = 侵入後の被害を限定
- 今回: CVE パッチ = 既知の入口を塞ぐ、fail2ban = 残った入口への攻撃を緩和、aide = 侵入されたことを検知
セキュリティ対策の本質は「攻撃者が使える入口を減らし、残った入口を守り、万が一突破されても気づける」ことです。
CVE の読み方とセキュリティアップデート
もしセキュリティアップデートをしなかったら何が起きるか、考えてみてください。脆弱性が公開されると、攻撃者はその脆弱性を悪用するツールを作成します。パッチが適用されていないサーバーは、その攻撃に対して無防備な状態です。
CVE とは
CVE（Common Vulnerabilities and Exposures）は、ソフトウェアの脆弱性を一意に識別するための番号体系です。「CVE-2024-1234」のように「CVE-年-番号」の形式で付与されます。ある脆弱性について話すときに「あの Apache のバグ」ではなく「CVE-2024-XXXX」と言えば、世界中のエンジニアが同じ脆弱性を指していると確認できます。
CVE にはそれぞれ深刻度（Critical / Important / Moderate / Low）が付いています。深刻度が高いほど、攻撃された場合の影響が大きいことを意味します。
セキュリティ通知の確認
AlmaLinux では dnf updateinfo コマンドでセキュリティ通知を確認できます。まず、現在利用可能なセキュリティアップデートの概要を見てみます。
alma-main で実行:
実行コマンド:
$ sudo dnf updateinfo summary実行結果:
更新情報の概要: 利用可能
93 セキュリティー通知
32 重要セキュリティー通知
60 中レベルセキュリティー通知
1 低レベルセキュリティー通知
1 バグ修正通知93件のセキュリティ通知が利用可能で、そのうち32件が「重要」（Important）です。「重要」は、リモートからの攻撃や権限昇格など影響の大きい脆弱性を意味します。
個別のセキュリティ通知を確認するには list security を使います。
実行コマンド:
$ sudo dnf updateinfo list security | head -10実行結果:
ALSA-2025:23343 中レベル/セキュリティ binutils-2.35.2-67.el9_7.1.x86_64
ALSA-2025:23343 中レベル/セキュリティ binutils-gold-2.35.2-67.el9_7.1.x86_64
ALSA-2026:1350 中レベル/セキュリティ curl-7.76.1-35.el9_7.3.x86_64
ALSA-2025:22175 重要/セキュリティ expat-2.5.0-5.el9_7.1.x86_64
...（以下多数）「ALSA-2025:23343」がアドバイザリ ID です。この ID で AlmaLinux のセキュリティアドバイザリページを検索すると、対応する CVE 番号や詳細な説明を確認できます。
セキュリティアップデートのドライラン
セキュリティアップデートを適用する前に、どのパッケージが更新されるかを確認します。--assumeno を付けると、実際にはインストールせずにトランザクションの概要だけを表示します。
実行コマンド:
$ sudo dnf update --security --assumeno実行結果（抜粋）:
インストール 10 パッケージ
アップグレード 67 パッケージ
ダウンロードサイズの合計: 144 M
操作が中断されました。--assumeno により「操作が中断されました」と表示され、実際のアップデートは行われません。本番環境では、このドライランでどのパッケージが更新されるかを確認してから、メンテナンスウィンドウ（計画停止時間）の中で実際のアップデートを適用するのが一般的です。
dnf updateinfo の詳しいオプションは man dnf の「UPDATEINFO COMMAND」セクションで確認できます。
dnf-automatic で自動化する
手動で dnf update --security を実行する運用は、忘れるリスクがあります。本番環境では dnf-automatic パッケージを使って、セキュリティアップデートのチェックを自動化するのが一般的です。
dnf-automatic は systemd timer で毎日自動実行されます（第24回で学んだ仕組みです）。デフォルト設定ではアップデートのダウンロードのみを行い、適用は手動で行う安全な構成になっています。設定ファイルは /etc/dnf/automatic.conf です。今回はインストールしませんが、「セキュリティアップデートの自動化にはこのツールがある」と覚えておいてください。
現場のヒヤリハット: 「動いているから」でアップデートを放置
ヒヤリハット: セキュリティアップデートを半年間放置して攻撃された
ある現場で、テスト用サーバーのセキュリティアップデートを「テスト環境だから」と半年間放置していました。ある日、そのサーバーから不審な通信が発生していることが監視で検知されました。調査の結果、半年前に公開された CVE の脆弱性を突かれてマルウェアが仕込まれていたことがわかりました。
テスト環境であっても、社内ネットワークに接続されていれば踏み台にされる可能性があります。「動いているから」「テスト環境だから」でアップデートを後回しにするのは危険です。定期的なセキュリティアップデートの適用は、サーバー運用の基本中の基本です。
fail2ban で SSH ブルートフォース攻撃を防ぐ
もし fail2ban がなかったら、SSH に何回でもパスワードを試せるとしたらどうなるか考えてみてください。攻撃者は辞書攻撃やブルートフォース攻撃で、何万通りものパスワードを自動で試行します。たとえパスワードが複雑でも、試行回数に制限がなければ突破される可能性は時間とともに高まります。
fail2ban は、ログを監視して認証失敗を検知し、一定回数失敗した IP アドレスを自動的にブロック（ban）するツールです。第20回で学んだ firewalld のルールを自動で追加・削除することで、攻撃元の通信を遮断します。
インストールと起動
fail2ban は EPEL リポジトリに含まれています。第19回で EPEL は導入済みなので、そのままインストールできます。
alma-main で実行:
実行コマンド:
$ sudo dnf install -y fail2banインストールが完了したら、サービスを起動して自動起動を有効にします。第13回で学んだ systemctl の操作です。
実行コマンド:
$ sudo systemctl start fail2ban
$ sudo systemctl enable fail2ban実行結果:
Created symlink /etc/systemd/system/multi-user.target.wants/fail2ban.service → /usr/lib/systemd/system/fail2ban.service.起動状態を確認します。
実行コマンド:
$ systemctl status fail2ban --no-pager -l実行結果（抜粋）:
● fail2ban.service - Fail2Ban Service
Active: active (running)active (running) と表示されていれば正常に起動しています。
現在の jail 状態を確認する
fail2ban では、監視対象のサービスごとに「jail」（監獄）という単位で設定を管理します。インストール直後は jail が1つも有効になっていません。
実行コマンド:
$ sudo fail2ban-client status実行結果:
Status
|- Number of jail: 0
`- Jail list:jail が0件です。SSH を保護するために sshd の jail を設定していきます。
sshd jail の設定
fail2ban の設定ファイルは /etc/fail2ban/jail.conf にデフォルト値がありますが、直接編集してはいけません。パッケージのアップデートで上書きされるためです。カスタム設定は /etc/fail2ban/jail.d/ ディレクトリに個別のファイルを作成します。
実行コマンド:
$ sudo tee /etc/fail2ban/jail.d/sshd.conf << 'EOF'
[sshd]
enabled = true
port = ssh
maxretry = 3
bantime = 600
findtime = 600
EOF各パラメータの意味は以下のとおりです。
enabled = true: この jail を有効にするport = ssh: 監視対象のポート（ssh は 22/tcp を意味する）maxretry = 3: 認証失敗が3回に達したら ban されるbantime = 600: ban の期間（秒）。600秒 = 10分間ブロックするfindtime = 600: この期間内（600秒）に maxretry 回失敗したら ban する
つまり「10分間に3回パスワードを間違えたら、10分間その IP からの SSH 接続をブロックする」という設定です。
設定を反映するために fail2ban を再起動します。
実行コマンド:
$ sudo systemctl restart fail2bansshd jail が有効になったか確認します。
実行コマンド:
$ sudo fail2ban-client status sshd実行結果:
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd + _COMM=sshd-session
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:sshd jail が有効になりました。Currently failed: 0 は現在の認証失敗回数、Currently banned: 0 は現在ブロック中の IP 数を示しています。Journal matches の行は、fail2ban が systemd のジャーナルから sshd の認証ログを読み取っていることを意味します。
fail2ban のコマンドや設定の詳細は man fail2ban および man jail.conf で確認できます。
aide でファイル改ざんを検知する
もし攻撃者がシステムファイルを書き換えたとして、それに気づく方法はあるか考えてみてください。設定ファイルが1行変更されていても、目で見ただけでは気づけません。
aide の仕組み
aide（Advanced Intrusion Detection Environment）は、ファイルの改ざんを検知するツールです。仕組みはシンプルです。
- 初期化: 現在のシステムファイルのハッシュ値（指紋のようなもの）をデータベースに記録する。これを「ベースライン」と呼ぶ
- チェック: ベースラインと現在のファイルのハッシュ値を比較する。1ビットでも変更があれば検知する
つまり「正常な状態を記録しておき、変化があったら報告する」という仕組みです。攻撃者がバックドアを仕込んだり、設定ファイルを改ざんしたりした場合に、次回のチェックで差分として検出されます。
インストール
aide は BaseOS リポジトリに含まれています。EPEL は不要です。
alma-main で実行:
実行コマンド:
$ sudo dnf install -y aideベースラインの初期化
aide をインストールしたら、まず現在のシステムの状態をベースラインとして記録します。
実行コマンド:
$ sudo aide --init実行結果（末尾のみ抜粋）:
End timestamp: 2026-04-04 17:42:47 +0900 (run time: 0m 13s)システム全体のファイルをスキャンするため、十数秒かかります。初期化が完了すると、/var/lib/aide/aide.db.new.gz にデータベースが生成されます。
aide がチェック時に参照するのは /var/lib/aide/aide.db.gz です。初期化で生成されたファイルをこの名前にコピーします。
実行コマンド:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz初期化時のファイルを aide.db.new.gz として生成し、チェック用のファイル aide.db.gz とは別にしている理由は、意図しない上書きを防ぐためです。管理者が明示的にコピーすることで、「この状態をベースラインとして採用する」という意思決定を挟む設計になっています。
チェックの実行
ベースラインと現在の状態を比較します。
実行コマンド:
$ sudo aide --checkベースラインを記録した直後なので、変更は検出されずに正常終了します。
改ざん検知のテスト
aide が本当にファイルの変更を検出できるか確認してみます。テスト用のファイルを /etc ディレクトリに作成し、aide --check を実行します。
実行コマンド:
$ sudo touch /etc/test-aide実行コマンド:
$ sudo aide --check今度は差分が検出されます。出力には /etc/test-aide が「added」（新規追加）として報告されます。aide はベースライン作成時に存在しなかったファイルが追加されたことを検知しています。
テスト用ファイルを削除しておきます。
実行コマンド:
$ sudo rm /etc/test-aideベースラインの定期更新
aide を運用する上で重要な点があります。ベースラインは定期的に更新する必要があるということです。
セキュリティアップデートを適用するとシステムファイルが変わります。正規のパッケージ導入でも設定ファイルが追加されます。こうした正当な変更がベースラインに反映されていなければ、aide --check のたびに大量の差分が報告され、本当の改ざんとの区別がつかなくなります。
運用の流れは以下のとおりです。
- セキュリティアップデートやパッケージ導入などの正規の変更を行った後に
aide --initを実行してベースラインを再作成する - 差分を確認して問題がなければ
cp aide.db.new.gz aide.db.gzで新しいベースラインを採用する - 第24回で学んだ cron を使って、
aide --checkを定期実行することも有効
aide の設定ファイル（/etc/aide.conf）では、監視対象のディレクトリやチェック項目をカスタマイズできます。詳細は man aide および man aide.conf で確認してください。
やってみよう
ここまでの内容を使って、以下の2つの課題に取り組んでみてください。
課題1: dnf updateinfo summary を実行し、セキュリティ通知の件数を確認してください。重要セキュリティー通知は何件ありますか。
実行コマンド:
$ sudo dnf updateinfo summary出力の中から「重要セキュリティー通知」の件数を確認してください。環境やタイミングによって件数は異なります。
課題2: fail2ban-client status sshd を実行し、Currently banned と Banned IP list を確認してください。
実行コマンド:
$ sudo fail2ban-client status sshd設定直後であれば Currently banned: 0 のはずです。もし ban されている IP があれば、それはこの演習中に認証を複数回失敗した IP です。fail2ban-client unban --all で全 IP の ban を解除できます。
クリーンアップ
今回導入した fail2ban と aide はサーバー運用で継続的に使うツールのため、アンインストールせずに残しておきます。fail2ban は systemd で管理されているため、サーバー再起動後も自動で起動します。
aide のテスト用ファイル /etc/test-aide は、前のセクションで削除済みです。
まとめと次回予告
今回のポイントを3つにまとめます。
- CVE / セキュリティアップデートは脆弱性の「特定と修正」。
dnf updateinfoで通知を確認し、dnf update --securityでパッチを適用する - fail2ban は攻撃の「緩和」。ログを監視して認証失敗を検知し、攻撃元の IP を自動でブロックする
- aide は侵害の「検知」。ベースラインと現在のファイルのハッシュ値を比較し、改ざんがあれば報告する
第3回で「パスワード管理」「情報の取り扱い」というセキュリティの意識を学びました。今回はその意識を、CVE の確認・攻撃の自動緩和・ファイル改ざん検知という具体的なツールと手順で実践しました。セキュリティは「意識」と「仕組み」の両輪です。意識があっても仕組みがなければ守れず、仕組みがあっても意識がなければ運用できません。
多層防御の考え方も重要です。脆弱性のパッチ適用、攻撃の自動ブロック、改ざんの検知。1つの層が突破されても次の層で防ぐ。この重ね合わせがサーバーの安全性を高めます。
次回は第34回「Git基本操作」です。git init / add / commit / diff / log / branch の基本操作を学び、/etc 配下の設定ファイルを Git で管理する実践を行います。今回の aide が「ファイルの変化を検知する」ツールだとすれば、Git は「ファイルの変更履歴を記録し、いつでも過去の状態に戻せる」ツールです。
理解度チェック
今回の内容を○×形式で確認します。
問1: CVE は、ソフトウェアの脆弱性を一意に識別するための番号体系である。
→ ○。CVE（Common Vulnerabilities and Exposures）は「CVE-年-番号」の形式で脆弱性を識別する。世界共通の番号体系であり、エンジニア間で脆弱性を正確に特定するために使われる。
問2: dnf update --security --assumeno を実行すると、セキュリティアップデートが即座に適用される。
→ ×。--assumeno はドライランオプションで、トランザクションの概要を表示するだけで実際のアップデートは行わない。本番環境ではまずドライランで影響範囲を確認するのが基本。
問3: fail2ban は、認証失敗を一定回数繰り返した IP アドレスを自動でブロックする。
→ ○。fail2ban はログを監視して認証失敗を検知し、maxretry で設定した回数を超えた IP を bantime の期間だけブロックする。
問4: fail2ban の設定をカスタマイズするには、/etc/fail2ban/jail.conf を直接編集する。
→ ×。jail.conf はパッケージのアップデートで上書きされるため、直接編集してはいけない。カスタム設定は /etc/fail2ban/jail.d/ ディレクトリに個別のファイルを作成する。
問5: aide は、ベースライン（初期状態のハッシュ値）と現在のファイルを比較することで改ざんを検知する。
→ ○。aide は --init で記録したベースラインと --check 時のファイルのハッシュ値を比較し、変更があれば差分を報告する。
問6: aide のベースラインは一度作成すれば、その後更新する必要はない。
→ ×。セキュリティアップデートやパッケージ導入などの正規の変更を行うとシステムファイルが変わるため、ベースラインを定期的に更新しないと大量の差分が報告され、本当の改ざんとの区別がつかなくなる。
シリーズ一覧
フェーズ1: エンジニアのいろは
フェーズ2: Linux基礎
- 第4回 Linuxとは何か＋環境確認
- 第5回 SSH接続とターミナル操作
- 第6回 ファイルシステムとディレクトリ構造
- 第7回 基本コマンド（ファイル操作）
- 第8回 基本コマンド（テキスト処理・パイプとリダイレクト）
- 第9回 viエディタ
- 第10回 ユーザーとグループ管理
- 第11回 パーミッションと所有権
- 第12回 プロセス管理
- 第13回 systemd
- 第14回 シェルスクリプト入門
- 第15回 フェーズ2まとめ演習
フェーズ3: ネットワークとインフラ基盤
- 第16回 ネットワーク基礎
- 第17回 ネットワーク設定と疎通確認
- 第18回 企業ネットワークの仕組み
- 第19回 パッケージ管理
- 第20回 ファイアウォール（firewalld）
- 第21回 ボンディング/チーミング
- 第22回 VLAN
- 第23回 ログ管理
- 第24回 cron / systemd timer
- 第25回 ストレージ管理（LVM）
- 第26回 シェルスクリプト実践
- 第27回 SSH応用
フェーズ4: サーバー構築と運用
