LPIC-3 Security303-300 v3.0Weight 4Configure / Use
334.2 Network Intrusion Detection
334.3でTrafficを制御した次に、「どれだけ使われているか」「攻撃らしいPacketか」「Targetに既知の脆弱性があるか」を別々の観測手段で見る。
最終到達点：帯域利用をMonitorし、Snortを設定・実行してRuleを管理し、OpenVAS/NASLのScan構造とFeed更新を説明・操作判断できる。
Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は 末尾の問題へ。
LPI 334.2：Implement bandwidth usage monitoring / Configure and use Snort including rule management / Configure and use OpenVAS including NASL. DescriptionにはSecurity Scannerの更新・管理も含む。
Bandwidth Monitoring誰が・どのProtocolが・どれだけTrafficを使うか。→ ntop
Network IDS流れているPacketをRuleと照合しAttack兆候をAlert。→ Snort
Vulnerability ScannerTargetへTestを行い、既知の弱点を探す。→ OpenVAS
3つを混ぜない：通信量が多いこと自体はAttack確定ではない。Snort AlertもVulnerabilityの存在証明とは限らない。OpenVASは「今流れているAttackを受動検知するTool」とは役割が違う。
01 Bandwidth02 Snort Engine03 Snort Rules04 OpenVAS05 NASL / VT06 Update / Maintenance
334.2 · 01/0601 Bandwidth Monitoring
🔴 Implementntop
帯域監視は「Packetの中身」より先にTraffic量の偏りを見る
このページの到達点：Interface上のTrafficを継続観測し、Host / Protocol / Volumeの偏りから「詳しく調べるべき通信」を見つけられる。
公式要求：Implement bandwidth usage monitoring. Partial utility:
ntop.役割を先に確認
Network Interface
↓ traffic observation
Bandwidth Monitor
├─ Host別 Traffic量
├─ Protocol別 Traffic量
├─ 時間推移
└─ 上位Talker / 急増
↓
「このHost/Protocolを詳しく見る」
↓
Wireshark / Snort等へ
Bandwidth Monitoringで答える質問
| 質問 | 見るもの |
|---|---|
| 誰が大量通信している? | Host / Address別Volume |
| 何の通信が増えた? | Protocol / Port / Application別 |
| いつから増えた? | 時間推移 / Rate |
| 平常時との差は? | Baselineとの比較 |
ntopの位置付け
LPIの用語は
ntop：現在は後継のntopngが広く使われる。試験では「Bandwidth/Traffic利用状況をHost・Protocol等で可視化する系統」として役割を結ぶ。# 現行ntopngでInterfaceを指定する代表例
ntopng -i eth0
-i：監視するInterfaceまたはCapture Sourceを指定する。重要なのはCommand暗記より、「どのInterfaceを観測しているか」を最初に確認すること。Scenario：夜間だけ1台のHostから外部へのTrafficが通常の20倍。
→ Bandwidth Monitorで異常候補を絞り、そのHostのPacket/FlowをSnortやPacket Captureで詳しく調べる。
EXAM DECISION
Bandwidth Monitorは「量と傾向」
- Packet PayloadのSignature Match → Snort
- 脆弱性Test → OpenVAS
- Traffic量/上位Host/Protocol → ntop
334.2 · 02/0602 Snort Engine
🔴 Configure / Usesnort / /etc/snort/*
SnortはPacketを「Ruleに一致するか」で検査する
このページの到達点：SnortのInput→Decode/Inspect→Rule Match→Alert/Logの流れを理解し、ConfigとRule Fileを指定して検査を開始する判断ができる。
公式要求：Configure and use Snort, including rule management. Partial:
snort, /etc/snort/*.Snortの処理
Packet / pcap
↓
Snort Engine
↓ decode / normalize / inspect
Rules
↓ match?
├─ No → continue
└─ Yes → alert / log / action
ConfigとRuleを分ける
| 要素 | 役割 |
|---|---|
| Snort Config | Network変数、Inspector、Rule File読込、出力等の全体設定。 |
| Rule | どのTraffic条件で何を検知/Alertするか。 |
| HOME_NET | 守る側Networkを表す代表変数。 |
| EXTERNAL_NET | 外部側Networkを表す代表変数。 |
まず設定をTestしてから起動
# Exam-era package layoutでよく見る例
snort -T -c /etc/snort/snort.conf
# Interfaceを指定して検査する代表形
snort -c /etc/snort/snort.conf -i eth0
Version差：Snort 3では
snort.luaを使う構成も一般的。LPI Objectiveは特定Major Versionの設定File名を固定していない一方、Partial listには/etc/snort/*があるため、試験では「Config Directory / Rule管理 / Engine」の関係を優先して理解する。起動前に確認：HOME_NETを誤ると「守るNetwork」の向きが崩れる。RuleのSyntaxだけ正しくても、変数やInterfaceが違えば欲しいTrafficを見られない。
EXAM DECISION
Snortの基本
- Engine本体 →
snort - Config/Rules →
/etc/snort/*系 - Rule Match → Alert/Log等
334.2 · 03/0603 Snort Rules
🔴 Rule Managementsnort-stat / pulledpork.pl
Snort RuleはHeaderでTrafficを絞り、Optionsで「何が一致したか」を決める
このページの到達点：RuleをAction / Protocol / Source / Direction / Destination / Optionsへ分解し、Rule更新・Alert集計のUtilityを役割で識別できる。
公式Partial：
snort-stat, pulledpork.pl.Rule Anatomy
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 ( ... )
│ │ │ │ │ │
Action Proto Source Direction Destination Options
Options例
msg / flow / content / sid / rev
Action
alertなど。Match時に何をするか。HeaderProtocol、Source/Destination、Port、Direction。
Detection
flow、content等で条件を細かくする。Identity
sidでRuleを識別、revでRevision。安全なTest Rule例
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"LPIC303 test string"; flow:to_server,established; content:"LPIC303TEST"; sid:1000001; rev:1;)
見る順：どの方向/Protocol/Port → Session条件 → Payload条件 → Alert Message → Rule ID。
Ruleを管理するUtility
pulledpork.plSnort Rule Setの取得・更新・有効/無効化等を管理するToolとして試験範囲に登場する。
snort-statSnort Alert/Logを集計・要約するUtilityとして試験範囲に登場する。
更新が重要な理由：Signature型検知はRuleが古いと新しいAttack Patternを認識できない。Engine更新とRule更新は別物として考える。
Version注意：
pulledpork.plやsnort-statは現在のすべてのSnort 3環境で標準という意味ではない。LPI 303-300 v3.0のPartial listに明示される試験用Utilityとして役割を識別する。EXAM DECISION
Rule管理で問われたら
- Rule取得/更新 →
pulledpork.pl - Alert/Log集計 →
snort-stat - Traffic Match条件 → Snort Rule Header / Options
334.2 · 04/0604 OpenVAS
🔴 Configure / UseOpenVAS
OpenVASは「TargetへVulnerability Testを実行するScanner」
このページの到達点：Target→Scanner→VT→Result/Reportの流れを理解し、Snortとの違い、旧OpenVAS管理Utilityの役割を識別できる。
公式要求：Configure and use OpenVAS, including NASL. Partial:
openvassd, openvas-adduser, openvas-rmuser, openvas-mkcert, /etc/openvas/*.Scanの流れ
Target Host / Service
↓ active tests
OpenVAS Scanner
↓
Vulnerability Tests (VT / NVT)
↓
Finding / Severity / Evidence
↓
Report
↓
Remediation / Rescan
Target何をScanする?
ConfigどのTestを使う?
ScannerTestを実行
ResultFindingを生成
Rescan修正後に確認
Snortとの違い
| Snort | OpenVAS | |
|---|---|---|
| 中心 | 流れているTrafficを検査 | TargetへVulnerability Test |
| 検出対象 | Attack Pattern / Suspicious Traffic | 既知のVulnerability / Misconfiguration等 |
| データ | Snort Rules | VT/NVT Feed |
公式に出る旧OpenVAS Utility
openvassdOpenVAS Scanner daemon本体を表す旧名称。
openvas-adduserOpenVAS利用Userを追加。
openvas-rmuserUserを削除。
openvas-mkcertOpenVASで使うCertificate作成系Utility。
/etc/openvas/*OpenVAS設定Directoryとして試験範囲に登場。
現在のGreenboneとの名前差：現行Greenbone Vulnerability Managementでは
openvas-scanner、ospd-openvas、gvmd等へ構成が変わっている。上記UtilityはLPIの303-300 v3.0に明示されたExam-era名称なので、試験では役割を取り違えない。EXAM DECISION
OpenVAS = Vulnerability Scanner
- 流れているAttack PacketをRuleでAlert → Snort
- TargetへVTを実行し脆弱性を探す → OpenVAS
334.2 · 05/0605 NASL / VT
🔴 Configure / UseNASL
NASLはOpenVASのVulnerability Testを記述する言語
このページの到達点：NASL→VT/NVT→Scanner→Resultという関係を説明し、Feed更新が「Scanner本体更新」と別で必要な理由を理解できる。
公式要求：Configure and use OpenVAS, including NASL.
NASLの位置
NASL Script
↓ defines a vulnerability test
VT / NVT Collection
↓ loaded by scanner
OpenVAS Scanner
↓ tests Target
Result
↓
Report / remediation
NASL = Network Attack Scripting Language。Greenbone/OpenVASでは多数のVulnerability Testが
.naslとしてFeedで提供され、Scannerがそれらを処理する。「Scannerを入れた」だけでは最新検査にならない
理由：Scanner Engineと「何を検査するか」のVT Feedは別。新しい脆弱性のTestがFeedへ追加されるため、Feed同期・読み込み状態を保守する必要がある。
| 要素 | 変わるもの |
|---|---|
| Scanner Software更新 | Engine/機能/不具合修正 |
| VT/NVT Feed更新 | 検査できるVulnerability Test内容 |
| Scan Config更新 | どのTestをどの強度/条件で使うか |
Reportをそのまま「侵害済み」と読まない
Vulnerability Finding：脆弱性や設定上の問題の可能性を示す。実際に侵害された証拠とは別。False Positive、Version Detection、Credentialed Scanの有無等を確認して判断する。
Scenario：Scan後にHigh Severityが出た。
→ 対象Version/証拠を確認 → 修正/Mitigation → 同条件でRescan。Reportを見ただけで「攻撃成功」とは断定しない。
EXAM DECISION
NASLの位置を1本で
- NASL → Vulnerability Test記述
- VT/NVT Feed → Test集合
- OpenVAS → TargetへTestを実行
334.2 · 06/0606 Update / Maintenance
🔴 MaintainFeed / Scanner
Network IDS/Scanner運用は「Rule/Feedを最新にする」までがセット
このページの到達点：Snort Rule更新とOpenVAS Feed更新を分け、LPIが列挙するLegacy Utilityと現在のGreenbone Toolの関係を整理できる。
公式Description：includes updating and maintaining security scanners. Partial:
openvas-nvt-sync, openvas-feed-update.更新対象を分ける
Snort
Engine ──────────────┐
Rules ─ pulledpork.pl ├→ current detection
│
OpenVAS │
Scanner Engine ───────┤
VT/NVT Feed ─ sync ───┘
「Softwareは新しいがRule/Feedが古い」も運用品質NG
LPIに出るOpenVAS更新Utility
openvas-nvt-syncNVT Feedを同期する旧Utility。
openvas-feed-updateOpenVAS Feed更新系の旧Utility。
現在のGreenbone：現行Community Documentationでは
greenbone-feed-syncでVT/NASL、SCAP、CERT、GVMD Data等を同期する構成が使われる。LPI ObjectiveのUtility名は旧世代なので、試験用語と現在運用を混同しない。# 現在のGreenboneでVT/NASL Feedを同期する代表例
sudo greenbone-feed-sync --type nasl
# 全Feed同期の代表例
sudo greenbone-feed-sync
試験では：
openvas-nvt-sync/openvas-feed-updateを「古いから無視」しない。303-300 v3.0のPartial listに明記されるため、役割は回答できるようにする。334.2 全体を比較
| 目的 | 代表 | 更新するもの |
|---|---|---|
| Traffic量を観測 | ntop | Tool/設定 |
| Packet Patternを検知 | Snort | Engine + Rules |
| 脆弱性をScan | OpenVAS | Scanner + VT/NVT Feed |
即答：「新しいCVE向けのVulnerability Testを追加したい」→ Feed更新。「新しいPacket SignatureをSnortへ入れたい」→ Rule更新。
OBJECTIVE COMPLETE
334.2完了条件
- Bandwidth Monitoringを「通信量・利用状況を見る」と説明できる
- SnortをConfigure/Useし、RuleのHeaderとOptionsを読める
- Snort Rule更新とScanner本体更新を区別できる
- OpenVASをVulnerability ScannerとしてConfigure/Useする流れを説明できる
- NASL / VT(NVT)がVulnerability Testを記述・配布する位置を説明できる
- openvas-nvt-sync / openvas-feed-update等の試験用語と現行Greenboneの名称差を区別できる
- Security ScannerはRule/Feedの更新・Maintenanceまでが運用だと判断できる
次に334.4へ進む理由： 観測→制御→検知まで揃ったので、最後はRouting・Filtering・認証・暗号をVPNへ統合する。
334.2 Network IDS · CHECKPOINTObjective末尾
Weight 4客観判定50 → 75 → 100%
334.2 Network IDS：学習直後にここで解く
本文を読み終えた直後に、そのObjectiveだけを確認する。別ページへ移動して問題を探さない。誤答した問題から該当ノートへ戻り、再度ここへ戻る。
合格条件： 50%は基礎選択式8問中7問以上、75%は選択肢なし再現7問中6問以上。75%到達から72時間後、専用実戦Bankから10問中9問以上で100%。さらに各段階で全小テーマを最低1問正解する必要がある。毎回Question Bankからランダム出題する。
現在の到達度
選択式から開始
0%
小テーマ別履歴問題を解くと正答率を表示
Objective Check
出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。
この問題の役割：Objective理解の客観Checkpoint。50%/75%はObjective理解の確認、100%は専用実戦Bankで状況判断・設定/出力読解・近い選択肢まで確認する。