-
-
Notifications
You must be signed in to change notification settings - Fork 24
Use cases
This document illustrates 15 critical enterprise deployment scenarios (Use Cases), highlighting how to configure and leverage SysWarden's military-grade capabilities (HIDS/WAAP/L2-L7) via the syswarden config command.
Warning
Disclaimer: Environment-Specific Adaptation
The IP addresses, CIDR blocks, ASNs, GeoIP country codes, and application log paths provided in these use cases are illustrative examples. They must be rigorously adapted and tailored to reflect the exact topology, architecture, and requirements of your specific enterprise environment. Never blindly copy-paste values into a production environment without validating them against your infrastructure map.
Caution
Risk Analysis & Business Impact Assessment (BIA)
Aggressive OSI Layer 3 filtering specifically GeoIP (SYSWARDEN_ENABLE_GEO) and ASN Blocking (SYSWARDEN_ENABLE_ASN) are powerful Zero-Trust measures. However, in an enterprise environment, they must be preceded by a formal Risk Analysis. Blocking entire countries or cloud providers (e.g., AWS, Azure) without prior traffic study can lead to critical denial of service for legitimate partners, API integrations, or remote employees. Always map your business workflows before enforcing wide-scale L3 drops.
Context: You host a critical e-commerce website exposed to the internet via Nginx. You are constantly subjected to vulnerability scanners (Nuclei, SQLmap), SQL injection attempts on your payment portal, and attacks from botnets.
SysWarden Approach: A combination of the hardware firewall (L3) fueled by global Threat Intelligence and the WAAP engine (L7) to intercept complex malicious payloads.
Configuration (syswarden config):
# Enable Global OSINT blocklist (1 = Standard Data-Shield feed)
SYSWARDEN_LIST_CHOICE="1"
# Enable GeoIP Blocking and explicitly target hostile regions
SYSWARDEN_ENABLE_GEO="y"
SYSWARDEN_GEO_CODES="ru cn kp ir"
# Enable WAAP Auto-Discovery (Zero-Config)
# Dynamically tails logs and instantly blocks L7 payloads (SQLi, XSS, LFI)
SYSWARDEN_BRUTEFORCE_LOGS="auto"
SYSWARDEN_BRUTEFORCE_THRESHOLD="3"Execution & Best Practices:
# Hot-reload the configuration without dropping active connections
syswarden reload
# Monitor blocked attacks live
syswarden tuiTip
Pro Tip (Zero-Overhead): Massive automated scans will be destroyed by the kernel (Nftables L3) via GeoIP and OSINT before even reaching Nginx. Only "clean" requests will reach Nginx, where the WAAP (L7) will analyze the HTTP payload in real-time with 0% CPU impact.
Context: You are securing a strictly internal PostgreSQL database server (LAN). It has no internet access (Air-Gapped). You fear lateral movement or Man-in-the-Middle (ARP Spoofing) attacks if another machine on the local network is compromised.
SysWarden Approach: Enable LAN mode (to save RAM by disabling external OSINT downloads) and strictly lock down the Data Link Layer (L2) via ARP protection.
Configuration (syswarden config):
# Optimize RAM/CPU for isolated servers (Disables external feeds)
SYSWARDEN_LAN_MODE="y"
# Aggressive L2 Protection
SYSWARDEN_ENABLE_L2="y"
# Enable strict ARP request limiting (hardcoded at 10/sec) to prevent ARP Spoofing
SYSWARDEN_ARP_PROTECT="y"
Important
In LAN_MODE, SysWarden intelligently bypasses its external download routines, making it perfect for highly secure environments, SCADA systems, or isolated database clusters.
Context: You run multiple Docker containers (API, Redis, Node.js) on a single host. Natively, Docker alters iptables and often exposes internal ports to the outside world, bypassing traditional firewalls like UFW.
SysWarden Approach:
SysWarden integrates natively into the DOCKER-USER chain via Nftables. All malicious IPs are intercepted before Docker routing occurs.
Configuration (syswarden config):
# Critical threat intelligence for cloud servers
SYSWARDEN_LIST_CHOICE="2"
# Radical blocking of Anonymous IP ranges and Cloud Hosters (AWS, Azure, Tor)
SYSWARDEN_ENABLE_ASN="y"
# Example: Block AS16509 (AWS) if they have no legitimate reason to call your API
SYSWARDEN_ASN_LIST="AS16509 AS14061"Execution & Best Practices:
# Permanently whitelist your administration IP
syswarden whitelist 192.168.1.100
# Immediately ban an entire attacking subnet
syswarden block 10.50.0.0/16Context: Your Security Operations Center (SOC) team uses an enterprise SIEM and collaborates on Discord. You require real-time telemetry of all incidents (L3 and L7) to trigger your Incident Response playbooks (SOAR).
SysWarden Approach: Transmit WAAP telemetry in native JSON format via UDS (Unix Domain Socket) to Rsyslog, with TLS encryption to the SIEM, combined with instant Discord Webhook alerts.
Configuration (syswarden config):
# Webhook Configuration
SYSWARDEN_ENABLE_WEBHOOK="y"
SYSWARDEN_WEBHOOK_URL_DISCORD="https://discord.com/api/webhooks/your_token"
# SIEM Integration (Syslog/JSON Transmission)
SYSWARDEN_SIEM_ENABLED="y"
SYSWARDEN_SIEM_IP="192.168.1.200"
SYSWARDEN_SIEM_PORT="6514"
SYSWARDEN_SIEM_PROTO="tls"
# CA Certificate to force strict TLS encryption (CWE-319 Mitigation)
SYSWARDEN_SIEM_TLS_CA="/etc/ssl/certs/siem-ca.crt"Tip
The Rsyslog bridge will natively forward the /var/log/syswarden/waf.json file via the imfile module. Your SIEM will ingest structured logs (Action, IP, Jail, HTTP Payload) without needing complex Regex parsing.
Context: You own a Load Balancer infrastructure distributed across two nodes. If an attacker strikes Node 1, they must be banned on Node 2 instantly before they attempt to bypass defenses via DNS Round-Robin.
SysWarden Approach: Activate the HA Cluster orchestrator. Nodes dynamically share the state of their memory ban tables securely over SSH.
Configuration (syswarden config): (On Node 1, pointing to Node 2)
# Enable Cluster Synchronization
SYSWARDEN_HA_ENABLED="y"
SYSWARDEN_HA_PEER_IP="10.0.0.2"
SYSWARDEN_HA_PEER_PORT="62026"
# MitM protection
SYSWARDEN_HA_STRICT_HOST_KEY="y"Important
IPs received from the HA peer will be categorized under the special [HA-Cluster] Jail. This prevents infinite network synchronization loops while guaranteeing instant cross-node mitigation.
Context: You host a self-managed GitLab instance for enterprise CI/CD. It is a high-value target for source code theft and SSH brute-force attacks on git repositories.
SysWarden Approach: Monitor SSH authentication natively (port 22) and utilize WAAP L7 protection to mitigate Remote Code Execution (RCE) attempts on the GitLab web interface.
Configuration (syswarden config):
# Ensure SSH port is actively monitored (leave empty for auto-detect)
SYSWARDEN_SSH_PORT=""
# Rapidly ban bruteforcers
SYSWARDEN_BRUTEFORCE_THRESHOLD="4"
# Explicitly monitor GitLab's custom embedded Nginx logs
SYSWARDEN_BRUTEFORCE_LOGS="/var/log/gitlab/nginx/gitlab_access.log"Context: Your enterprise ERP contains highly sensitive financial data. It is only utilized by internal employees and should never be accessible from cloud data centers or automated scrapers.
SysWarden Approach: Following a rigorous Risk Analysis verifying that no legitimate third-party API depends on these cloud networks, enforce strict ASN blocking to prevent automated scraping or corporate espionage. Explicitly whitelist your corporate subnets.
Configuration (syswarden config):
SYSWARDEN_ENABLE_ASN="y"
# Block DigitalOcean, OVH, AWS, Azure, and Google Cloud ASNs
SYSWARDEN_ASN_LIST="AS14061 AS16276 AS16509 AS8075 AS15169"
# Explicitly monitor the ERP's custom application logs for L7 exploits
SYSWARDEN_BRUTEFORCE_LOGS="/var/log/odoo/odoo-server.log /var/log/nginx/access.log"Execution & Best Practices:
# Manually whitelist your company's VPN/Office CIDR to guarantee access
syswarden whitelist 198.51.100.0/24Context: You are running an exposed authentication bridge (e.g., FreeIPA or an LDAP proxy). Only specific branch offices should communicate with it.
SysWarden Approach:
Utilize SysWarden's strict CIDR whitelisting combined with the Catch-All mechanism to explicitly drop all unauthorized connection attempts silently without returning TCP RST packets.
Execution & Best Practices:
# Whitelist the entire branch office subnet (O(1) Kernel matching)
syswarden whitelist 10.200.0.0/16Context: You are running a Kubernetes cluster. You want to drop massive botnets and vulnerability scanners at the Host OS level before the traffic even reaches the K8s Ingress Controller (which consumes excessive memory under heavy load).
SysWarden Approach: Deploy SysWarden on the bare-metal worker nodes running the Ingress. SysWarden acts as a hyper-efficient kernel proxy shield.
Configuration (syswarden config):
# Enable Data-Shield (Choice 1) to block known bad IPs instantly
SYSWARDEN_LIST_CHOICE="1"
# Enable Spamhaus ASN Drop list for extra botnet protection
SYSWARDEN_USE_SPAMHAUS="y"
# Explicitly monitor the Ingress controller access logs
SYSWARDEN_BRUTEFORCE_LOGS="/var/log/ingress-nginx/access.log"Context: Your mail server is constantly hammered by dictionary attacks attempting to guess employee passwords via SMTP/IMAP.
SysWarden Approach: Tail the mail logs natively. SysWarden’s engine replaces Fail2ban entirely and bans SMTP brute-forcers instantly.
Configuration (syswarden config):
# Add mail logs to the monitoring queue alongside web logs
SYSWARDEN_BRUTEFORCE_LOGS="auto /var/log/mail.log"
SYSWARDEN_BRUTEFORCE_THRESHOLD="5"Context: You host WordPress sites. They are plagued by xmlrpc.php abuse, wp-login.php brute-force, and malicious plugins causing SQL injections.
SysWarden Approach:
Zero-Config WAAP natively detects SQL injections (e.g., union select) and Cross-Site Scripting (XSS) in the URL payloads without breaking legitimate WordPress functionalities.
Configuration (syswarden config):
# Auto-discovery will find Nginx/Apache logs automatically
SYSWARDEN_BRUTEFORCE_LOGS="auto"
SYSWARDEN_LIST_CHOICE="1"Tip
WAAP's substring matching is significantly faster than ModSecurity. It immediately intercepts ../../wp-config.php (LFI) attempts without requiring complex rulesets.
Context: You have a public-facing API. You want to prevent attackers from using tools like sqlmap or zgrab to enumerate your endpoints.
SysWarden Approach: SysWarden natively detects the signatures of popular hacking tools (Nuclei, Masscan, SQLmap) within the HTTP traffic and enforces an immediate, permanent hardware ban.
Configuration (syswarden config):
SYSWARDEN_BRUTEFORCE_LOGS="auto"
# Strict threshold to block API enumeration instantly
SYSWARDEN_BRUTEFORCE_THRESHOLD="2"Context: Your database is on a dedicated VPS. It should only be queried by your Web Server VPS. Any other connection attempt is inherently malicious.
SysWarden Approach:
Ensure the Catch-All rule (default behavior in SysWarden's firewall backend) silently drops all internet noise hitting closed or unprotected ports. Only explicitly whitelisted IPs will be allowed through seamlessly.
Configuration (syswarden config):
# Hardening mode strictly secures the OS
SYSWARDEN_HARDENING="y"Execution & Best Practices:
# Whitelist the Web Server IP via CLI
syswarden whitelist 203.0.113.50
# Check the Live Alerts to verify malicious connections are dropped
syswarden alertsContext: You run a modern SPA (Single Page Application) served by Nginx, routing API requests to a Node.js backend.
SysWarden Approach: SysWarden monitors the Nginx reverse proxy logs. Because the WAAP Engine parses logs asynchronously, your Node.js backend experiences zero latency overhead while remaining fully protected from L7 exploits.
Configuration (syswarden config):
# Fully optimized for asynchronous web stacks
SYSWARDEN_BRUTEFORCE_LOGS="auto"
SYSWARDEN_BRUTEFORCE_WINDOW="120"Context: A staging server where developers frequently trigger 404 errors while building features, or use weird payloads for testing. You don't want them getting banned accidentally.
SysWarden Approach:
Utilize the configuration variable SYSWARDEN_WHITELIST_IPS to permanently protect the corporate IP range, ensuring developers are immune to WAAP blockades during active testing.
Configuration (syswarden config):
# Permanently whitelist the developer office IPs in the core config
SYSWARDEN_WHITELIST_IPS="203.0.113.100 203.0.113.101"
# Increase the threshold for 404/403 errors during active development
SYSWARDEN_BRUTEFORCE_THRESHOLD="50"Caution
Governance & Compliance Prerequisite
Implementing a Zero-Trust Strict ALLOW policy (Default-Deny) is a radical architectural shift. A formal Risk Analysis and Business Impact Assessment (BIA) approved by the CISO/Governance Board is mandatory. By explicitly defining SYSWARDEN_GEO_ALLOWED or SYSWARDEN_ASN_ALLOWED, the firewall universally drops all other global traffic at the hardware layer. Ensure all third-party dependencies, API callbacks (e.g., Stripe, PayPal), and monitoring probes (e.g., Datadog, UptimeRobot) are securely mapped and whitelisted beforehand.
Context: You operate a strictly domestic governmental portal or regional utility service. Compliance (e.g., NIS2, ISO 27001) and risk analysis mandate that the service must be entirely invisible and inaccessible to foreign IP space to mitigate state-sponsored DDoS and targeted APT reconnaissance.
SysWarden Approach:
Enforce absolute Zero-Trust Geo-Fencing. By populating the SYSWARDEN_GEO_ALLOWED variable, SysWarden drops the entire world at Layer 3 with O(1) latency, permitting only traffic originating from the authorized domestic territories.
Configuration (syswarden config):
# Disable classic module to prevent redundant memory allocation
SYSWARDEN_ENABLE_GEO="n"
# Zero-Trust Strict ALLOW: Only accept traffic from France (FR) and Germany (DE)
SYSWARDEN_GEO_ALLOWED="FR DE"Context: Your enterprise exposes a high-value B2B financial API endpoint. Risk analysis dictates that this endpoint must only be queried by three specific corporate partners operating out of known, static datacenters. The public internet must be entirely blocked.
SysWarden Approach: Instead of managing thousands of individual partner IPs, SysWarden restricts access exclusively to the Autonomous System Numbers (ASNs) owned by your partners. Any IP outside of these specific ASNs is violently dropped by Nftables.
Configuration (syswarden config):
# Disable classic module to prevent redundant memory allocation
SYSWARDEN_ENABLE_ASN="n"
# Zero-Trust Strict ALLOW: Only accept traffic from these specific ASNs
SYSWARDEN_ASN_ALLOWED="AS1234 AS5678 AS91011"Context: A regional European bank requires web traffic to be restricted strictly to EU member states (L3 Governance). However, the CISO risk assessment identifies that domestic compromised botnets (e.g., infected IoT devices within the allowed countries) could still launch SQL Injections or Brute-Force attacks against the banking portal.
SysWarden Approach:
SysWarden establishes the baseline perimeter by dropping all non-EU traffic via hardware Nftables (Zero-Trust L3). Simultaneously, the autonomous WAAP Engine (L7) actively monitors the allowed domestic traffic. If a whitelisted domestic IP attempts an exploit, the WAAP retains absolute independence: it intercepts the malicious payload, instantly overrides the whitelist via the banned_ips set, and reports the breach to the SIEM.
Configuration (syswarden config):
# L3 Hardware Lock-down (Only allow specific EU countries)
SYSWARDEN_ENABLE_GEO="n"
SYSWARDEN_GEO_ALLOWED="FR DE IT ES BE LU"
# L7 WAAP Active Monitoring (Ensuring malicious domestic IPs are still banned)
SYSWARDEN_BRUTEFORCE_LOGS="auto"
SYSWARDEN_BRUTEFORCE_THRESHOLD="3"Execution & Best Practices:
# Verify the strict ALLOW deployment and L7 telemetry status
syswarden auditContext: Your enterprise leverages FreeBSD 14+ Jails for high-density microservices. Unlike Linux Docker, Jails natively share or securely virtualize the network stack (VNET). You need to ensure that hostile IPs are dropped at the host level before reaching the exposed microservices running inside the Jails.
SysWarden Approach:
SysWarden natively hooks into the FreeBSD pf (Packet Filter) engine. By defining dynamic <syswarden_blacklist> and <banned_ips> tables, SysWarden blocks threats at the host OS perimeter (L3), shielding all downstream Jails without requiring complex NAT bridging or manual rule replication within each Jail.
Configuration (syswarden config):
# Global Threat Intel blocking for FreeBSD
SYSWARDEN_LIST_CHOICE="1"
SYSWARDEN_ENABLE_GEO="y"
SYSWARDEN_GEO_CODES="ru cn kp"
# The WAAP automatically protects exposed Jail ports (e.g., Nginx running in a Jail)
SYSWARDEN_BRUTEFORCE_LOGS="/var/log/nginx-jail/access.log"
SYSWARDEN_BRUTEFORCE_THRESHOLD="5"Context: A critical TrueNAS/FreeBSD storage appliance utilizing ZFS is accessible over the internal network. You need to defend the administration interface (HTTPS) and SSH access against brute-force attacks and lateral movement from potentially compromised internal segments.
SysWarden Approach:
By deploying SysWarden locally on the FreeBSD storage node, the Go engine continuously tails the authentication logs (/var/log/auth.log). Any brute-force attempts on SSH are intercepted, and the attacking IP is instantly pushed into the PF <banned_ips> table, effectively isolating the storage appliance from the infected subnet.
Configuration (syswarden config):
# Optimized for isolated storage arrays (no external OSINT downloads)
SYSWARDEN_LAN_MODE="y"
# Explicit FreeBSD SSH Port protection
SYSWARDEN_SSH_PORT="22"
SYSWARDEN_BRUTEFORCE_LOGS="auto"Context: A FreeBSD 14+ server acts as an edge router running FRRouting (FRR) using BGP. It is subjected to constant BGP hijacking attempts, SYN floods on exposed management ports, and scanning from malicious ASNs.
SysWarden Approach:
SysWarden directly orchestrates pf to enforce strict ASN blocking at the edge. The integration creates a hardware-level drop for any packets originating from blacklisted ASNs or known malicious IPs (Data-Shield) before they consume FRR routing resources. The Go engine applies these millions of CIDRs cleanly into PF tables.
Configuration (syswarden config):
# Drop hostile ASNs (e.g., known bulletproof hosters) at the edge router
SYSWARDEN_ENABLE_ASN="y"
SYSWARDEN_ASN_LIST="AS12345 AS98765"
# Sync global blocklists into PF tables
SYSWARDEN_LIST_CHOICE="1"Context: An internal infrastructure administrator's machine has been compromised by malware or a malicious insider. The attacker is attempting to scan the internal network, perform brute-force attacks, or exploit web vulnerabilities (L7). Because the administrator's IP is globally whitelisted (SYSWARDEN_WHITELIST_IPS) to prevent accidental service lockouts, traditional IDS/IPS systems might ignore or bypass their traffic.
SysWarden Approach:
SysWarden's native Shadow Mode actively monitors whitelisted IPs. Instead of enforcing a ban that would disrupt legitimate operations, any malicious L7 WAAP triggers or L3 Honeyport hits originating from the whitelisted IP will silently generate a SHADOW-ALERT.
Configuration (syswarden config):
# Whitelist the administrator subnet
SYSWARDEN_WHITELIST_INFRA="y"
SYSWARDEN_WHITELIST_IPS="10.0.50.0/24"
# Enable webhooks for silent alerting
SYSWARDEN_ENABLE_WEBHOOK="y"
SYSWARDEN_WEBHOOK_URL_SLACK="https://hooks.slack.com/services/YOUR_WORKSPACE_ID/YOUR_CHANNEL_ID/YOUR_SECRET_TOKEN"
# Configure Honeyports to trap lateral movement scanners
SYSWARDEN_HONEYPORTS="6379, 3306, 27017, 5432"Execution & Best Practices:
# The SOC monitors the live feed for ORANGE alerts
syswarden alertsTip
The SOC immediately receives a Slack/Discord notification explicitly tagged [SOC-ALERT] INSIDER THREAT DETECTED and can isolate the compromised administrator's machine out-of-band without dropping critical production connections.
Context: You want to proactively catch unauthorized internal lateral movement targeting typical database infrastructure.
SysWarden Approach: Deploy Honeyports directly at the kernel perimeter (Nftables/PF) on a standard application node. By exposing fake database ports, any internal scanner (e.g., Nmap) or automated ransomware worm that touches these ports is instantly trapped.
Configuration (syswarden config):
# Expose decoy ports for Redis, MySQL, MongoDB, and PostgreSQL
SYSWARDEN_HONEYPORTS="6379, 3306, 27017, 5432"Important
If a non-whitelisted internal IP connects to these ports, they are instantly and permanently banned at OSI Layer 3. If a whitelisted IP connects, it triggers a Shadow Alert. External IPs scanning the internet are caught identically and dropped before reaching the application layer.