第26章　セキュリティ運用タスクと侵入検知

LPIC-2 212.4 相当

ファイアウォールのようなその場限りの設定だけでなく、継続的なセキュリティ運用の考え方と、改ざん検知・監査ログ・不正アクセスの自動遮断の基礎を扱います。VPN（OpenVPN）による拠点間・リモートアクセスの構築は次章で扱います。

日常的なセキュリティ運用タスク

これらのタスクの多くは、単発で終わらせず「定期的に繰り返す」ことが本質です。パッケージ更新はunattended-upgradesのような自動化の仕組みを使うこともできますが、自動再起動が業務時間中に発生しないよう適用タイミングを制御するなど、運用ルールとセットで設計する必要があります。

ファイル整合性の監視（AIDE）

AIDE（Advanced Intrusion Detection Environment）は、あらかじめ重要なファイルのハッシュ値などを含むデータベースを作成しておき、その後の状態と比較することで、改ざんの有無を検出するツールです。

$ sudo aideinit                    # 初期データベースを作成
Start timestamp: 2026-08-21 09:02:14 +0900 (AIDE 0.18.6)
AIDE initialized database at /var/lib/aide/aide.db.new

Number of entries:     48213

---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.new
 MD5      : Zt0m9QeXk1234567890ABCDEFghijk==
 SHA256   : c2b1a9...（省略）

End timestamp: 2026-08-21 09:03:47 +0900 (run time: 1m 33s)
$ sudo aide --check                # 現在の状態と比較してレポートを表示
AIDE 0.18.6

Summary:
  Total number of entries:     48215
  Added entries:                2
  Removed entries:               0
  Changed entries:               1

---------------------------------------------------
Changed entries:
---------------------------------------------------
f  /etc/passwd
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /etc/passwd
 SHA256   : X0K3nq...          | Y8mPqz...
 Mtime    : 2026-08-18 14:02:11 | 2026-08-21 08:55:03

この行のこの値に注目： Changed entriesに表示されたファイル（この例では/etc/passwd）が、初期化後に変更されたことを意味します。Mtime行のように変更前後のハッシュ値・更新日時が並記され、心当たりのない変更であれば侵入や改ざんを疑う手がかりになります。ユーザー追加など正当な変更であれば、確認後にsudo aideinitを再実行してデータベースを更新します。

侵入者がバックドアを仕込んだり、ログを改ざんしたりしても、ハッシュ値の不一致からその痕跡を検知できる可能性が高まります。ただしデータベース自体が改ざんされては意味がないため、データベースは書き込み不可のメディアや別サーバーに保管するのが望ましいとされています。

auditd — システムコール監査

auditd（Linux Audit Framework）は、特定のファイルへのアクセスやシステムコールの発行をカーネルレベルで記録する仕組みです。「誰かが/etc/shadowを読み取ろうとした」「特定のバイナリが実行された」といった痕跡を、通常のsyslogより詳細な形で残せます。

$ sudo auditctl -w /etc/shadow -p wa -k shadow_watch   # 正常時は無出力
# /etc/shadowへの書き込み(w)・属性変更(a)を監視し、shadow_watchというキーでタグ付け
$ sudo ausearch -k shadow_watch     # タグを指定してログを検索
----
type=PATH msg=audit(1755741600.123:456): item=0 name="/etc/shadow" inode=131094 dev=fd:01 mode=0100640 ouid=0 ogid=42 rdev=00:00
type=SYSCALL msg=audit(1755741600.123:456): arch=c000003e syscall=2 success=yes exit=3 a0=... comm="vipw" exe="/usr/sbin/vipw" key="shadow_watch"
$ sudo aureport --summary          # 監査ログのサマリレポートを表示
Summary Report
======================
Range of time in logs: 08/21/2026 00:00:07.123 - 08/21/2026 09:10:22.456
Selected time for report: 08/21/2026 00:00:07 - 08/21/2026 09:10:22
Number of changes in configuration: 3
Number of changes to accounts, groups, or roles: 0
Number of logins: 12
Number of failed logins: 2
Number of authentications: 15
Number of files: 8
Number of AVC's: 0

この行のこの値に注目： ausearchの結果にあるcomm="vipw"・exe="/usr/sbin/vipw"から、どのコマンドが/etc/shadowにアクセスしたかが分かります。aureport --summaryのNumber of failed loginsのような集計値は、監査ログ全体の傾向を素早く把握するのに便利で、ここで異常な件数が出ていれば、ausearchで個別のイベントを深掘りする流れになります。

ルールを永続化するには /etc/audit/rules.d/audit.rules に追記します。監査ログはコンプライアンス対応（PCI DSSなど）や、侵入事後の調査（フォレンジック）でも重要な情報源になります。

実行されたコマンドを監査する例
$ sudo auditctl -a always,exit -F arch=b64 -S execve -k command_exec   # 正常時は無出力
# 64ビット環境でのプログラム実行(execveシステムコール)をすべて記録

fail2ban — 不正アクセスの自動遮断

fail2ban は、ログを監視して、短時間に何度もログイン失敗を繰り返すIPアドレスを自動的にファイアウォールでブロックするツールです。SSHへの総当たり攻撃（ブルートフォース攻撃）対策として広く使われています。

$ sudo systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-08-21 06:00:12 JST; 3h 12min ago
       Docs: man:fail2ban(1)
   Main PID: 812 (fail2ban-server)
      Tasks: 5 (limit: 4649)
     Memory: 14.2M
        CPU: 890ms
     CGroup: /system.slice/fail2ban.service
             └─812 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
$ sudo fail2ban-client status sshd     # sshd向けの現在のブロック状況を確認
Status for the jail: sshd
|- Filter
|  |- Currently failed: 3
|  |- Total failed:     47
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 2
   |- Total banned:     9
   `- Banned IP list:   198.51.100.23 203.0.113.77

この行のこの値に注目： Currently bannedとBanned IP listで、いま実際にブロックされている送信元IPアドレスが分かります。Total bannedとCurrently bannedの差は、bantime経過によってすでに解除されたIPの数を表します。誤って正規の利用者のIPをブロックしてしまった場合は、この一覧から該当IPを確認し、次に説明するunbanipで解除します。

設定は「jail（監獄）」という単位で、監視対象のログファイル、検知条件、ブロック方法をサービスごとに定義します。既定の設定を直接編集せず、/etc/fail2ban/jail.localを作成して上書きするのが推奨される運用方法です（アップデートで設定が上書きされるのを防ぐため）。

/etc/fail2ban/jail.local の例
[sshd]
enabled = true
maxretry = 5
findtime = 600
bantime = 3600
# 600秒以内に5回失敗したIPアドレスを3600秒間ブロックする

$ sudo fail2ban-client set sshd unbanip 192.0.2.99   # 誤ってブロックされたIPアドレスを手動で解除
1

この行のこの値に注目： fail2ban-clientのset系サブコマンドは、成功すると処理結果を表す数値（この例では、解除できたIPの件数1）だけを1行返します。0が返る場合は、指定したIPがそもそもブロックリストに存在しなかったことを意味します。

日常的なセキュリティ運用タスクのチェックリスト

ここまでの各章で個別に扱ってきた要素を、日常運用の観点で整理すると次のような定期タスクにまとめられます。

個々の作業自体は本章までで扱ってきた内容の延長線上にありますが、重要なのは「思いついたときにだけやる」のではなく、こうした定期タスクとして仕組み化しておくことです。cronやsystemdタイマー（中級第13章・本章第3章）でチェックスクリプトを自動化し、結果を通知する仕組みを整えておくと、属人的な運用に頼らずセキュリティレベルを維持しやすくなります。

脆弱性情報のキャッチアップ体制

セキュリティ運用は、自サーバーの内部だけを見ていても不十分です。利用しているディストリビューションやミドルウェア（OpenSSH、OpenSSL、Webサーバー、DBサーバーなど）に関する脆弱性情報を、日頃から追いかける体制も欠かせません。多くのディストリビューションはセキュリティアドバイザリのメーリングリストやRSSフィードを公開しており、CVE（Common Vulnerabilities and Exposures）番号で個々の脆弱性が識別されます。かつてはBUGTRAQのようなメーリングリストが脆弱性情報の主要な共有経路として使われており、現在もCERT（Computer Emergency Response Team、各国・組織ごとに設置されたセキュリティ対応チーム）が発行するアドバイザリは重要な一次情報源です。

深刻度の指標としてはCVSS（Common Vulnerability Scoring System）スコアがよく参照され、これをもとに「緊急パッチが必要か」「定例のメンテナンスウィンドウまで待てるか」を判断します。重大な脆弱性が公表された際に自社のシステムが影響を受けるかどうかを即座に判断できるよう、稼働中のソフトウェアとバージョンの一覧を日頃から整備しておくことも、実務上のセキュリティ運用の一部です。

CVSS（現行のバージョン3系）のスコアは、単一の数値ではなく複数の観点を組み合わせて算出されます。

Baseスコア（0.0〜10.0）は、深刻度に応じて次のように区分されます。

実務では、Criticalに区分される脆弱性が自組織の稼働ソフトウェアに該当する場合、定例のメンテナンスウィンドウを待たずに緊急パッチ適用を検討するといった判断基準として、このスコアが活用されます。

nmapによるポートスキャンの基礎

nmapは、対象ホストがどのポートを開放しているかを外部から調査するツールです。自分が管理するサーバーに対して定期的に実行することで、「意図せず外部に公開されてしまっているサービスがないか」を確認する、いわば外側からの棚卸し作業に使えます。

$ nmap -sS -sV -O -T4 -p- -oN scan-result.txt 192.168.1.10
# SYNスキャン＋バージョン検出＋OS検出を、比較的速いタイミングで全ポートに対して実行し、結果をファイルに保存

PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
111/tcp  filtered rpcbind
135/tcp  closed   msrpc

この行のこの値に注目： STATE列に表示される3つの状態には明確な違いがあります。openはそのポートで実際にサービスが応答している状態、closedはポートへの到達性はあるがそのポートでは何も待ち受けていない（RSTが返る）状態、filteredはファイアウォールなどにパケットが遮断され、応答が得られず開いているか閉じているか判断できない状態を示します。filteredが多いホストは、何らかのフィルタリング機構の背後にあることが読み取れます。

$ nmap -sS 192.168.1.10               # SYNスキャン（要root権限）
Starting Nmap 7.94 ( https://nmap.org ) at 2026-08-21 09:20 JST
Nmap scan report for 192.168.1.10
Host is up (0.00042s latency).
Not shown: 997 closed tcp ports (reset)
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 1.84 seconds
$ nmap -sV 192.168.1.10               # 開いているポートのサービス・バージョンを推定
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.5 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http    nginx 1.24.0
443/tcp open  ssl/http nginx 1.24.0
$ nmap -p 1-65535 192.168.1.10        # 全ポートを対象にスキャン
Not shown: 65530 closed tcp ports (reset)
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
3306/tcp open  mysql

Nmap done: 1 IP address (1 host up) scanned in 4.62 seconds

この行のこの値に注目： -sVを付けるとSERVICE列の右にさらにVERSION列が加わり、稼働中のソフトウェア名とバージョンが推定表示されます。全ポートスキャン（-p 1-65535）で3306/tcp（MySQL）のように、意図せず外部からアクセスできる状態のサービスが見つかった場合は、ファイアウォールで塞ぐか、そのサービス自体をローカルホスト限定にバインドし直す対応を検討します。

nc（netcat）による疎通確認とバナー取得

nc（netcat）は、TCP/UDPの生の接続を手軽に扱える汎用ツールで、「ネットワークのスイスアーミーナイフ」とも呼ばれます。ポートスキャンほど本格的でなくても、単純な疎通確認や簡易的な通信テストに重宝します。

$ nc -zv 192.168.1.10 22
Connection to 192.168.1.10 22 port [tcp/ssh] succeeded!
# -z: 実際にデータを送らず接続確認のみ, -v: 詳細表示

受信側（ファイルを受け取る、正常時は無出力のまま待機し続ける）
$ nc -l -p 1234 > received_file.txt
送信側（ファイルを送る、正常時は無出力）
$ nc 192.168.1.10 1234 < send_file.txt

この行のこの値に注目： どちらのncも成功時は画面に何も表示されません。転送が完了したかどうかは、受信側をCtrl+Cで終了させた後にls -l received_file.txtでファイルサイズを比較するか、送信側のシェルにプロンプトが戻ってきたことで判断します。

ncを使って手動でサービスに接続し、応答（バナー）を確認することもできます。多くのサービスは接続直後にソフトウェア名やバージョンを名乗るため、意図せず古いバージョンの情報が外部に漏れていないかを確認する簡易チェックとしても使えます。

$ nc mail.example.com 25
220 mail.example.com ESMTP Postfix

telnet・openssl s_clientによるサービスの生確認

telnetは、任意のTCPポートに対して手動でテキストベースのコマンドを送受信できる古典的なツールです。SMTPの手動セッション実演はすでに「メール配送」の章で扱いましたが、HTTPサーバーに対しても同様の手法で、レスポンスヘッダーを直接確認できます。

$ telnet example.com 80
Trying 203.0.113.10...
Connected to example.com.
> HEAD / HTTP/1.1
> Host: example.com
>
HTTP/1.1 200 OK
Server: nginx/1.24.0
Date: Thu, 20 Aug 2026 10:00:00 GMT
Content-Type: text/html

この行のこの値に注目： Server:ヘッダーにWebサーバーソフトウェアの名前とバージョン（この例ではnginx/1.24.0）がそのまま表示されています。バージョン情報が外部から丸見えになっていると、そのバージョンに存在する既知の脆弱性を狙われる手がかりを与えてしまうため、公開サーバーではserver_tokens off;（Nginx）やServerTokens Prod（Apache）のような設定で、詳細なバージョン情報を隠すことが推奨されます。

HTTPS（TLS）で保護されたサービスに対しては、telnetでは途中までしか確認できません。証明書の内容やTLSのプロトコルバージョンまで踏み込んで確認したい場合は、openssl s_clientを使います（「HTTPS化とSSL/TLS証明書管理」の章で扱った内容と同じ手法です）。

$ openssl s_client -connect example.com:443 -servername example.com
CONNECTED(00000003)
Certificate chain
 0 s:CN = example.com
   i:CN = Let's Encrypt Authority X3
...
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

証明書の発行者・有効期限や、実際に使われているTLSのバージョン・暗号スイートをその場で確認でき、証明書の更新漏れや、意図せず古いプロトコル（TLS1.0/1.1など）が有効なままになっていないかの点検に使えます。

脆弱性スキャナとディストリ付属のセキュリティチェックツール

OpenVAS/Greenboneのような本格的な脆弱性スキャナ以外にも、各ディストリビューションには、インストール済みパッケージのうちセキュリティ修正が必要なものを手軽に確認できるツールが用意されています。

$ debsecan                                  # インストール済みパッケージの既知の脆弱性を一覧表示
CVE-2025-31234 openssl (unfixed)
CVE-2025-33456 libxml2 (fixed 2:2.9.14+dfsg-1.3ubuntu1)
CVE-2025-30112 curl (unfixed)
$ sudo dnf updateinfo list security          # セキュリティ関連のアップデートのみを一覧表示
FEDORA-EPEL-2026-abcd123 Important/Sec. openssl-3.2.2-2.el9.x86_64
FEDORA-EPEL-2026-efgh456 Moderate/Sec.  curl-8.5.0-3.el9.x86_64
$ sudo dnf update --security                 # セキュリティ関連のアップデートのみを適用
Dependencies resolved.
================================================================
 Package        Arch    Version           Repository       Size
================================================================
Upgrading:
 openssl        x86_64  3.2.2-2.el9       baseos-security  1.2 M
 curl           x86_64  8.5.0-3.el9       baseos-security  312 k

Transaction Summary
================================================================
Upgrade  2 Packages

Complete!

この行のこの値に注目： debsecanの(unfixed)は、そのディストリのバージョンではまだ修正パッケージが提供されていない脆弱性であることを示し、(fixed バージョン)は、表示されたバージョン以降に上げれば修正済みであることを示します。dnf updateinfo list securityのImportant/Sec.・Moderate/Sec.は深刻度を表し、Important以上のものを優先的に適用するのが実務上の判断基準になります。

これらのディストリ付属ツールは、OpenVASのようなネットワーク経由の能動的スキャンとは異なり、ローカルにインストールされているパッケージのバージョン情報とディストリ側の脆弱性データベースを突き合わせるだけの軽量な仕組みです。日常的なパッチ管理の一環として、まずこれらの軽量ツールで定期的にチェックし、より網羅的な診断が必要な場合にOpenVASのような本格的なスキャナを併用する、という使い分けが実務的です。

IDS/IPSの概要（Snort・Suricata・OpenVAS）

fail2banやauditdが「自ホスト内で起きたこと」を対象にするのに対し、ネットワークの通信そのものを監視し、既知の攻撃パターンと照合する仕組みがIDS（Intrusion Detection System、侵入検知システム）です。Snortは代表的なオープンソースIDS/IPSで、シグネチャ（攻撃パターンのルール）に基づいてパケットを検査し、疑わしい通信を検知（IDSモード）またはブロック（IPS＝Intrusion Prevention Systemモード）します。

一方OpenVAS（Open Vulnerability Assessment Scanner）は、既知の脆弱性データベースをもとに対象ホストを能動的にスキャンし、「パッチが未適用の脆弱性がないか」を網羅的に洗い出す脆弱性スキャナです。nmapがポートの開放状況を調べるのに対し、OpenVASはより踏み込んで、各サービスの具体的な脆弱性の有無まで診断します。両者は「攻撃を検知・防御する（Snort）」と「弱点を事前に発見する（OpenVAS）」という異なる役割分担で、セキュリティ運用を補完し合います。

Snortと並んでよく使われるオープンソースIDS/IPSにSuricataがあります。Snortとルール形式に高い互換性を持ちながら、マルチスレッド処理に対応し、高トラフィック環境でもSnort単体より高いスループットを発揮しやすい設計になっている点が特徴です。

IDSは監視対象の範囲によって、さらに2種類に分類されます。

この章の前半で扱ったAIDEやTripwireはHIDSに分類されるツールです。ネットワークの通信内容そのものは見ていませんが、「ホストの中で何が変わったか」を検知するという意味で、広い意味でのIDS（侵入検知システム）の一種として位置づけられます。NIDSとHIDSは監視する層が異なるため、両方を組み合わせることで、ネットワーク経由の攻撃の検知と、万が一侵入を許してしまった後の痕跡検知の両方をカバーできます。