Protection and Monitoring Modules

Protection and Security-Monitoring Modules

Type: Module inventory (canonical) · Terminology: Glossary & Vocabulary Last reviewed for terminology: v1.220.1; per-module runtime details are validated on each module page.

This is the canonical module inventory. Each row states four separate things — protection/monitoring domain, primary evidence, runtime owner, and enforcement behavior — because they are genuinely different concepts. OSI "layer" labels and bare "daemon YES/NO" flags are intentionally not used.

Module	Protects or Monitors	Signal Source	Operation
DDoS Protection	Network and transport-layer floods	nftables meters and counters	Kernel-enforced; daemon provides runtime management/telemetry where applicable
BotGuard (HTTP Guard)	HTTP abuse and connection attacks	nftables HTTP signals	Go daemon with centralized enforcement
BotScan (HTTP Exploit Scanner)	Malicious HTTP requests and exploit probes	Web access logs	Scheduled scanner + daemon consumer (centralized enforcement)
Portscan Detection	Reconnaissance and connection scanning	Connection-pattern analysis	Go daemon module + centralized enforcement (classic / Suricata paths as configured)
Login Monitoring	Brute-force and authentication abuse	Journald, service logs, panel logs, web-auth logs, Suricata	Go daemon detection + centralized enforcement (legacy shell path in-tree, not deployed)
Blacklist & Threat Feeds	Known hostile addresses	Manual entries and external intelligence feeds	Multiple producers with centrally synchronized enforcement
Suricata IDS Integration	IDS-detected network threats	Suricata EVE JSON (external IDS engine)	External IDS producer + NFTBan event processing
RBL Monitoring	Server-IP reputation and mail-delivery blocklisting risk	Public IPv4/IPv6 DNSBL checks	Scheduled and on-demand; observe-only; alerts and reports (no bans, no nftables writes)
DNS Tunnel Detection	Suspicious DNS behavior	DNS-query analysis	Advisory and non-blocking

Reading the table

• Evidence ≠ enforcement. A signal source (access logs, EVE JSON, DNSBL results, nft counters) is what a module observes. Enforcement is a separate step performed through the daemon-owned nftables path.
• Detection ≠ direct set ownership. Detection modules produce findings or durable ban evidence; the daemon consumer performs centralized enforcement. BotScan, for example, hands ban evidence to the daemon — it does not write blacklist_manual_* directly.
• Observe-only vs enforcing. RBL Monitoring and DNS Tunnel Detection produce findings without changing packet enforcement. Enabling RBL controls scheduling and alerts, not firewall enforcement.
• Suricata is external. NFTBan consumes eligible Suricata EVE JSON events; NFTBan is not the deep-packet-inspection engine, and not every alert results in a ban.

Module pages

BotGuard · BotScan · DDoS Protection · Portscan Detection · Login Monitoring · Blacklist & Threat Feeds · Suricata IDS Integration · RBL Monitoring · DNS Tunnel Detection.

See the Architecture Overview for the truth-authority model and the Health & Validation page for how module health is derived.