LPIC-3 Security303-300 v3.0Weight 5Use / Configure6 themes / 8 pages

332.2 Host Intrusion Detection：何が起きたか・何が変わったかを検出する

332.1で攻撃面を減らし、332.3でResource境界を作った。次は「それでも侵害や改ざんが起きたら、何を根拠に気付くか」を学ぶ。

332.2の最終到達点：Linux Auditを設定してEventを検索・集計し、Rootkit/Malware scanを実行・更新・定期化する。RPM/DPKGとAIDEでFile Integrityを検証し、OpenSCAPの位置付けを識別する。

Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は末尾の問題へ。

何をした?Linux Audit

Rootkit?chkrootkit / rkhunter

Malware?Linux Malware Detect

Fileが変わった?RPM/DPKG / AIDE

LPI公式：Linux AuditのUse/Configure、chkrootkit、rkhunterのUse/Configure/Update、Linux Malware Detect、cron自動化、RPM/DPKG integrity verification、AIDE rule management、OpenSCAP Awareness。

学習の軸：Tool名を暗記するのではなく「何を基準に異常を見つけるToolか」で分ける。Audit=Event、Rootkit/Malware scanner=兆候、Package verification=Package DB、AIDE=自分で作ったBaseline。

← 332.3 Resource Control 332.2を開始 →

332.2 · 01/0801 Linux Audit

🔴 Use / Configureauditd

Linux Audit①：Kernel EventをRuleで拾い、auditdが記録する

このページの到達点：Auditの処理経路と、auditd.conf・audit.rules・auditctlの役割を区別できる。

まず全体経路

Process / User action ↓ syscall / security event Linux Kernel Audit subsystem ↓ Audit ruleに一致? Audit record ↓ auditd ↓ /var/log/audit/audit.log ↓ ausearch / aureport

auditd

Kernel Audit subsystemからEventを受け取り、Audit Logへ記録するDaemon。

auditd.conf

Audit Daemon自体の動作・Log出力やRotation等を設定するFile。

audit.rules

「どのEventを記録するか」というAudit Ruleを永続化する側。

auditctl

Kernel内のAudit RuleやAudit subsystem状態を実行中に確認・変更するCLI。

Daemon設定とRule設定を混ぜない

目的	見る場所
Log File・Rotation等	`auditd.conf`
何を監査するか	`audit.rules` / `auditctl`
現在のAudit状態	`auditctl -s`
現在読み込まれたRule	`auditctl -l`

# Audit subsystemの状態 sudo auditctl -s # 現在のRule一覧 sudo auditctl -l

試験判断：auditd.confは「Daemonをどう動かすか」、audit.rulesは「何を監査するか」。同じ設定Fileではない。

← 全体像次のページ →

332.2 · 02/0801 Linux Audit

🔴 Use / Configureauditctl / PAM

Linux Audit②：Ruleを作り、必要なEventだけ記録する

このページの到達点：File変更監視Ruleを設定し、r/w/x/aの意味、Key、永続Rule、pam_tty_audit.soの役割を説明できる。

Ruleが決めるもの

対象: /etc/shadow ↓ どんな操作? write / attribute change ↓ 識別用Key: identity ↓ Eventが起きたらAudit Logへ

File変更を監査する

# 学習上よく見る簡潔なwatch形式 sudo auditctl -w /etc/shadow \ -p wa -k identity # 現行auditctlが推奨するsyscall rule形式の例 sudo auditctl -a always,exit \ -F arch=b64 \ -F path=/etc/shadow \ -F perm=wa \ -k identity

ここでのr/w/x/a：Unix File Permissionのrwxではなく、Audit Ruleで検知するAccess種別。r=read / w=write / x=execute / a=attribute change。

現在のLinuxでは：-w path -p ...形式は互換性のため残っているが、auditctlの現行Manualではsyscall-based ruleへの移行が推奨されている。試験で旧形式を見ても役割は判断できるようにする。

永続化はRule Fileへ

# /etc/audit/audit.rules のイメージ -w /etc/shadow -p wa -k identity

実行中だけauditctlで追加したRuleはReboot等で消える。永続化する場合はDistributionのAudit Rule読込方式に合わせてRule Fileへ置く。LPIのPartial listではaudit.rulesが明示されている。

TTY入力をAuditへ：pam_tty_audit.so

# PAM session設定例 session required pam_tty_audit.so \ disable=* enable=root # 記録されたTTY EventのReport aureport --tty

注意：TTY Auditは入力内容を記録し得るため、機密情報の扱いに注意する。目的は「管理操作の監査」であって、無差別に秘密情報を収集することではない。

← 前のページ次のページ →

332.2 · 03/0801 Linux Audit

🔴 Useausearch / aureport

Linux Audit③：ausearchでEventを探し、aureportで集計する

このページの到達点：Rule→Event発生→ausearch→aureportを一続きで実行し、検索とReportの違いを判断できる。

auditctl
Rule

→

Event
発生

→

auditd
Log

ausearch
Event検索

→

event number

→

aureport
集計

安全なLab Fileで確認：

touch /tmp/lpic303-audit-demo sudo auditctl -w /tmp/lpic303-audit-demo \ -p wa -k lpic303_demo echo test >> /tmp/lpic303-audit-demo sudo ausearch -k lpic303_demo -i sudo aureport -f -i

type=SYSCALL ... auid=alice uid=alice exe="/usr/bin/bash" ... type=PATH ... name="/tmp/lpic303-audit-demo" ...

読む場所：auidはLogin時のAudit User IDを追跡する重要情報、uidはその時点のUser ID、exeは実行Program、nameは対象Path。

Tool	目的
`ausearch`	Audit Logから条件に一致するEventを検索。Key・Event番号・User・時間等で絞る。
`aureport`	Audit LogをSummary Reportとして集計。ReportのEvent番号から`ausearch -a`で詳細へ戻れる。

EXAM DECISION

検索か集計か

特定Eventを探す → ausearch
Audit全体をSummary化 → aureport
「Ruleを追加」→ auditctl

← 前のページ次のページ →

332.2 · 04/0802 Rootkit Detection

🔴 Use / Configurechkrootkit / rkhunter

Rootkit Detection：chkrootkitとrkhunterを役割で分ける

このページの到達点：両Toolを実行し、rkhunterの設定・更新・Property DB更新を区別し、検出結果を「感染確定」と短絡しない。

chkrootkitSystemがRootkit等で改変された兆候を検査。

rkhunterRootkit/不審File/Property等を検査し、ConfigとData更新も扱う。

共通結果は調査の起点。Warning=即感染確定ではない。

chkrootkit

# 全体Scan sudo chkrootkit # 問題がないTestの出力を抑える sudo chkrootkit -q # 別Root FSをScanする例 sudo chkrootkit -r /mnt/suspect

rkhunter：Update → Check → 確認

# rkhunterのData Fileを更新 sudo rkhunter --update # Checkを実行。--skは確認PromptをSkip sudo rkhunter --check --sk

/etc/rkhunter.conf

Scan・Allowlist・Update等の設定。

--update

rkhunterが利用するData File更新を確認・取得。

--propupd

File Property Databaseを「現在の正しい状態」として更新する操作。

--propupdを先に実行しない：侵害後の状態をBaselineとして登録すると、異常を正常として覚えさせる危険がある。正当な変更を確認した後に更新する。

EXAM DECISION

rkhunterは「Use」だけでなくConfigure / Update

簡単なRootkit scan → chkrootkit
Config/Update/Property DBまで含む → rkhunter

← 前のページ次のページ →

332.2 · 05/0803 Malware / Automation

🔴 Usemaldet / cron

Linux Malware Detect：Malware Scanを更新し、cronで定期化する

このページの到達点：maldetでSignature更新・Scanを行い、conf.maldetの位置付けを理解し、Host Scanをcronで自動化できる。

Scanの運用Cycle

Signature / Data更新 ↓ 対象DirectoryをScan ↓ Alert / Report確認 ↓ 誤検知・侵害を調査 ↓ 定期実行へ

# Signature/Data更新 sudo maldet -u # 対象PathをScan sudo maldet -a /var/www

conf.maldet：Linux Malware Detectの設定File名。Install方法によって実Pathは異なるため、環境上のConfig Pathを確認して使う。

cronでHost Scanを自動化

まずcommand -v rkhunter / command -v maldetで実Binary Pathを確認し、そのPathをcronへ設定する。

# /etc/cron.d/lpic303-host-scan の例 # 毎日03:15にrkhunter 15 3 * * * root /usr/bin/rkhunter --check --sk --nocolors # 毎日03:45にWeb領域をmaldetでScan 45 3 * * * root /usr/local/sbin/maldet -a /var/www

Pathは例：rkhunterやmaldetのInstall先は環境で異なる。cronではInteractive ShellとPATHが違うことがあるため、絶対Pathで書く方が安全。

cronの5項目：minute / hour / day-of-month / month / day-of-week。/etc/cron.d形式ではその後に実行Userを置く。

← 前のページ次のページ →

332.2 · 06/0804 Package Integrity

🔴 Userpm / dpkg

Package Integrity：RPM/DPKGのDatabaseを基準にInstalled Fileを検証する

このページの到達点：rpm -Vとdpkg -Vを使い、Package管理情報と現在Fileの差分を読める。

Package DB
Install時のmetadata / digest

↔

現在のFile
size / digest / owner等

RPM：複数Attributeを比較

# 指定PackageをVerify rpm -V bash # 全Installed PackageをVerify rpm -Va

S.5....T. c /etc/example.conf

文字	差分
S	Size
M	Mode / Permission / Type
5	Digest
D	Device major/minor
L	Symlink target
U / G	User / Group owner
T	mtime
P	File Capability

通常は差分だけ出る：RPM VerifyはPackage Metadataと一致した項目を.で表し、不一致部分に記号が出る。Config Fileは正当な管理変更でも差分が出得るので、差分=侵害とは限らない。

DPKG：現在は主にmd5sumを確認

# Package指定 sudo dpkg -V coreutils # Package名省略で全Package対象 sudo dpkg -V

RPMとの違い：現行dpkgの--verifyは、DatabaseにMD5 metadataがあるFileについて内容のmd5sum検証を行うのが中心。RPMのように多数Attributeを同じ形で検査するわけではない。

EXAM DECISION

「何を基準に比較？」

RPM/DPKG → Package Managerが持つInstall時情報
次のAIDE → 管理者が作成したBaseline Database

← 前のページ次のページ →

332.2 · 07/0805 AIDE

🔴 Configure / UseBaseline / Rules

AIDE①：正常状態のBaselineを作り、何を比較するかRuleで決める

このページの到達点：AIDEのBaseline方式を理解し、/etc/aide/aide.confで監視対象と属性を設定して初期Databaseを作れる。

Package Verifyとの最大の違い

正常と確認した時点 ↓ AIDE --init ↓ Baseline Database ↓ 時間経過現在File ↓ AIDE --check ↓ Added / Removed / Changed

AIDE = Advanced Intrusion Detection Environment。名前はIDSだが、中心機能はFile/Directory Integrity Checker。Config Ruleで選んだFileの属性・Digest等をDatabaseへ保存し、後で現在状態と比較する。

Ruleは「Path + 比較Attribute」

# /etc/aide/aide.conf の学習例 /etc/ssh/sshd_config p+i+n+u+g+s+m+c+sha256 # 頻繁に変わるLogは対象外にする例 !/var/log/.*

Permission

i / n

inode / link count

u / g

User / Group

Size

m / c

mtime / ctime

sha256

File content digest

# Initial Databaseを作成 sudo aide --init

Baselineは「正常時」に作る：侵害された後にInitial Databaseを作れば、侵害状態が正常値になる。Install直後・Hardening後など、信頼できる状態で作成する。

Rule management：「何でも全部監視」ではなく、変化しない重要Binary/Configを厚く、頻繁に変化するLog/Temporary dataを適切に除外する設計が重要。

← 前のページ次のページ →

332.2 · 08/0805 AIDE / OpenSCAP

🔴 Configure / Use⚪ OpenSCAP Awareness

AIDE②：差分を調査してからBaseline更新。OpenSCAPとは目的を分ける

このページの到達点：aide --check / --updateの順序と判断を理解し、OpenSCAPをFile Integrity Toolと混同しない。

AIDEの運用Cycle

# 現在状態とBaselineを比較 sudo aide --check # 正当な変更を確認した後、新Database候補を作る sudo aide --update

Summary: Total number of entries: ... Added entries: 1 Removed entries: 0 Changed entries: 1

差分検出
Added / Removed / Changed

→

原因調査
正当なChange? 侵害?

「差分が出た → 即update」はNG：侵害による変更なら、更新したDatabaseに異常を正常値として取り込む。Change管理・Package更新等と照合してから新Baselineへ切り替える。

OpenSCAPはAwareness

AIDE

自分で作ったFile Integrity Baselineと現在状態を比較する。

OpenSCAP

SCAP Security Policy/Benchmarkを読み、SystemがSecurity Baselineへ準拠しているか評価するEcosystem/Scanner。

332.2での深度：OpenSCAPはAwareness。oscapの複雑なProfile操作を大量暗記する章にはしない。

332.2 EXIT CHECK

auditd / auditctl / audit.rulesを区別✓

ausearch=検索 / aureport=集計✓

chkrootkitとrkhunterをUseでき、rkhunter updateを説明✓

maldet scanとcron自動化✓

RPM/DPKG Integrity Verificationを比較✓

AIDE Rule→Baseline→Check→調査→Update✓

OpenSCAPはCompliance/Baseline評価のAwareness✓

監査基準：LPI 303-300 v3.0 Objective 332.2、Linux Audit userspace Manual、Linux-PAM pam_tty_audit、RPM/dpkg verify documentation、AIDE documentation、OpenSCAP。Distribution差があるPath/運用は固定値として暗記させない。

332.2 COMPLETE

Host Securityの流れが完成

332.1：攻撃面・権限を減らす
332.3：Resource境界を作る
332.2：Event・Rootkit/Malware・File改ざんを検知する

次に331.1へ進む理由： Host側の「制限・Resource・検知」まで完成したので、次は暗号側の共通知識であるKey / Signature / Certificate / Trustを作る。332.1のSSH CAで使った「署名して信頼する」考え方も、ここで一般化できる。

← 前のページ Objective問題へ →

332.2 Host IDS · CHECKPOINTObjective末尾

Weight 5客観判定50 → 75 → 100%

332.2 Host IDS：学習直後にここで解く

本文を読み終えた直後に、そのObjectiveだけを確認する。別ページへ移動して問題を探さない。誤答した問題から該当ノートへ戻り、再度ここへ戻る。

合格条件： 50%は基礎選択式9問中8問以上、75%は選択肢なし再現8問中7問以上。75%到達から72時間後、専用実戦Bankから11問中10問以上で100%。さらに各段階で全小テーマを最低1問正解する必要がある。毎回Question Bankからランダム出題する。

現在の到達度

選択式から開始

問題プール 39問小テーマ 7 実戦Bank 20問直近重複を抑制未出題優先

小テーマ別履歴問題を解くと正答率を表示

全体到達度を見る

Objective Check

JavaScriptが無効：このCheckpointの自動採点と進捗保存はJavaScript実行環境で利用してください。本文はそのまま閲覧できます。

100%専用： 72時間後の再テストでは既存564問ではなく、このObjective専用の実戦相当20問から出題する。各問は複数知識・近い誤答・設定/出力/状況判断のいずれかを含み、誤答時は全選択肢の違いまで確認する。

出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。

この問題の役割：Objective理解の客観Checkpoint。実試験の出題再現ではないが、固定問題の暗記だけでは突破しにくい構成にする。

← Objective本文の最後へ次の推奨Objectiveへ →

← 332.3 Resource Control

全体進捗·Checkpoint

331.1 X.509 / PKI →