HIDS はサーバーの中で「ファイル・ログ・プロセスに何が起きたか」を見張り、NIDS はネットワーク上で「どんな通信が流れたか」を見張る侵入検知の仕組みです。見ている場所が違うため、見つけられる攻撃と見落とす攻撃も異なります。この記事では両者の違いを整理し、代表的なソフトウェア、WordPress を載せた VPS 1台のような小さな環境で何から始めるかまでを説明します。
IDS とは何か、IPS との違い
IDS（Intrusion Detection System、侵入検知システム）は、不正アクセスやその兆候を見つけて知らせる仕組みです。基本は「検知して通知する」までで、通信を止めることはしません。これに対して IPS（Intrusion Prevention System、侵入防止システム）は、通信経路の途中に入って、検知した通信をその場で遮断します。
同じソフトウェアが設定次第で IDS にも IPS にもなることがあり、たとえば Suricata は監視だけのモードと、通信を通過させながら遮断するインラインのモードを持っています。遮断は誤検知があったときに正常な通信まで止めてしまうため、最初は検知のみで運用し、ルールの精度を見てから遮断を検討するのが一般的です。
HIDS（ホスト型IDS）の特徴
HIDS は監視したいサーバー自体にエージェントやツールを入れて動かします。主に次のようなものを見ます。
- ファイルの改ざん：システムのバイナリ、設定ファイル、WordPress のコアファイルなどのハッシュ値を記録し、変化を検知します（ファイル整合性監視、FIM）。
- ログ：認証ログ、Web サーバーのログなどから、ログイン失敗の連続や不審な操作を見つけます。
- プロセスや設定の変化：見覚えのないプロセス、新しく増えたユーザー、権限の変更などです。
強みは、サーバーの中で実際に何が起きたかが分かることです。通信が HTTPS で暗号化されていても、サーバー側では復号されたあとの結果（ログやファイルの変化）を見られます。WordPress のファイルに不審な PHP が置かれた、wp-config.php が書き換えられた、といった事象は HIDS が得意とする領域です。
弱みは、監視対象のサーバーそれぞれに導入と管理が必要なこと、そしてサーバーが乗っ取られると HIDS 自体やそのログが改ざんされうることです。後者への対策として、検知結果は別のサーバーやログ収集基盤に送って保管します。
代表的なソフトウェアには次のものがあります。
- Wazuh：OSSEC から派生したオープンソースの基盤で、エージェントがファイル整合性監視・ログ解析・脆弱性の検出などを行い、マネージャーに集約します。
- OSSEC：ログ解析とファイル整合性監視を中心とした老舗の HIDS です。
- AIDE / Tripwire：ファイル整合性監視に特化したツールです。基準となるデータベースを作り、定期的に差分を調べます。
- auditd：Linux カーネルの監査機能で、特定ファイルへのアクセスやコマンド実行を記録できます。単体では検知ルールが少ないため、他のツールと組み合わせて使うことが多いです。
NIDS（ネットワーク型IDS）の特徴
NIDS はネットワークを流れるパケットを観測し、既知の攻撃パターン（シグネチャ）や不自然な通信の振る舞いを検知します。ネットワークの境界や、スイッチのミラーポート・TAP からコピーした通信を受けて動かすのが典型的な構成です。
強みは、1か所で複数のサーバーの通信をまとめて見られること、そして監視対象のサーバーに何も入れなくてよいことです。ポートスキャン、既知の脆弱性を狙ったリクエスト、マルウェアの外部通信（C2 通信）などを、ネットワーク全体の視点で捉えられます。
弱みは、暗号化された通信の中身は見えないことです。HTTPS の通信では、宛先や通信量、TLS のハンドシェイクの情報などは見えても、リクエストの本文までは分かりません。また、トラフィックが多いと処理性能が必要になり、誤検知の調整にも手間がかかります。
代表的なソフトウェアには次のものがあります。
- Suricata：マルチスレッドで動くオープンソースの IDS/IPS です。
suricata-updateで ET Open などのルールセットを取得・更新できます。 - Snort：シグネチャ型 NIDS の代表格で、現在は Snort 3 が中心です。
- Zeek：シグネチャで警告を出すというより、通信の記録（接続・DNS・HTTP・TLS などのログ）を詳しく残すネットワーク監視ツールです。調査や振る舞いの分析に向きます。
違いを一覧で比べる
| 観点 | HIDS（ホスト型） | NIDS（ネットワーク型） |
|---|---|---|
| 監視する場所 | 各サーバーの内部 | ネットワーク上の通信 |
| 得意な検知 | ファイル改ざん、ログ上の不審な操作、権限変更 | スキャン、既知の攻撃通信、外部への不審な通信 |
| 暗号化通信 | 復号後の結果（ログ・ファイル）で判断できる | 中身は見えず、メタ情報が中心 |
| 導入の手間 | サーバーごとに導入・管理が必要 | 観測点を作れば対象サーバーには入れなくてよい |
| 侵害時の弱さ | ホストが乗っ取られると改ざんされうる | ホスト内部だけで完結する活動は見えない |
| 負荷 | 各サーバーの CPU・ディスクを少し使う | 観測点の機器に通信量相応の性能が必要 |
両者は代わりになるものではなく、補い合う関係です。NIDS で外からの攻撃の試みを捉え、HIDS でサーバーの中で実際に変化が起きたかを確かめる、という組み合わせが基本の考え方になります。
小さな環境では何から始めるか
WordPress を載せた VPS が1〜数台という環境では、NIDS の前提になる「ネットワークの観測点」を作るのが難しいことが多くあります。VPS ではミラーポートを使えないのが普通で、クラウドのトラフィックミラーリング機能（AWS の VPC Traffic Mirroring など）も、対応するインスタンスや費用面の条件があります。
そのため、次の順番で始めるのが現実的です。
- 基本の防御を先に固める：OS とプラグインの更新、SSH の公開鍵認証、不要なポートを閉じるファイアウォール、fail2ban による試行のブロック。IDS は防御の代わりにはなりません。
- ファイル整合性監視を入れる：AIDE などで、システムファイルと WordPress のコアファイルの変化を毎日チェックします。WordPress ではアップロードディレクトリや更新のたびに変わるファイルが多いため、監視対象と除外対象を分けて誤検知を減らします。
- ログの監視を加える：Wazuh のエージェントなどで認証ログや Web サーバーのログを集め、通知を受けられるようにします。
- 必要になったら NIDS：サーバーが増えて自前のネットワーク（VPC など）を管理するようになったら、境界やミラーした通信に Suricata などを置くことを検討します。
AIDE の場合、最初に基準データベースを作り、以後は差分を確認する流れです（コマンドや設定ファイルの場所はディストリビューションによって異なります）。
# Debian/Ubuntu の例：基準データベースの作成（初回、時間がかかります）
sudo aideinit
# 差分のチェック（cron などで定期実行し、結果をメールや通知に送る）
sudo aide --config /etc/aide/aide.conf --checkWordPress や OS を更新したあとは正当な変更が大量に出るため、更新作業の直後に差分を確認して基準データベースを更新する、という運用の手順をあらかじめ決めておきます。
運用でつまずきやすい点
IDS は入れただけでは役に立たず、運用で差が出ます。
- 誤検知の多さ：初期設定のままでは通知が多すぎて見なくなりがちです。最初の数週間は通知を見ながら、正当な動作の除外ルールを整えます。
- ルールとソフトウェアの更新：シグネチャ型の検知は、ルールが古いと新しい攻撃を見逃します。ルールの自動更新を設定し、更新が止まっていないかも監視します。
- 通知の受け手：誰がいつ確認し、検知したら何をするかを決めておきます。検知後の初動（隔離、ログの保全、パスワードや鍵の変更）を手順にしておくと慌てずに済みます。
- 検知できるのは一部：どの IDS も攻撃のすべてを見つけられるわけではありません（2026年10月現在の主要なツールでも同じです）。バックアップと復旧手順は IDS とは別に用意しておきます。
まとめ
- HIDS はサーバー内部（ファイル・ログ・プロセス）を、NIDS はネットワーク上の通信を監視します。
- HIDS は暗号化された通信の結果も見られる一方、各サーバーへの導入が必要で、侵害されると改ざんされえます。NIDS は1か所でまとめて見られる一方、暗号化通信の中身は見えません。
- 両者は補い合う関係で、小さな環境では基本の防御、ファイル整合性監視、ログ監視の順に始め、ネットワークを管理するようになったら NIDS を検討します。
- 誤検知の調整、ルールの更新、通知後の対応手順まで含めて運用を設計します。