Why does SikkerGuard need elevated privileges?

NET_ADMIN is required to create and manage iptables rules and ipset sets. SYSLOG allows reading /dev/kmsg so SikkerGuard can show blocked connections in real time. network_mode: host gives access to the host network stack since iptables rules are per-network namespace.

Install SikkerGuard

Block known malicious IPs at the kernel level with a single Docker container. Powered by real-time threat intelligence from 39+ high-interaction honeypots.

5 minute setup · Free tier available · Full documentation

Prerequisites

✓Linux server with Docker and Docker Compose
✓Free SikkerAPI account and a free API key
✓SSH or terminal access to the server

Step 1

Get your API key

Create a free account if you don't have one. Once logged in, open the user menu and navigate to API Keys.

SikkerAPI dashboard user menu with API Keys navigation item highlighted — Open the user menu and click API Keys

Copy your API key. Any key type works — free keys include full blacklist access with up to 5,000 IPs per pull. Higher subscription tiers unlock larger blocklists.

SikkerAPI API Keys page showing existing keys with Copy and Regenerate buttons — Click Copy to copy your API key to the clipboard

Step 2

Create a project directory

SSH into your server and create a directory for SikkerGuard. This is where your docker-compose.yaml and .env files will live.

Terminal

$ mkdir sikkerguard && cd sikkerguard

Step 3

Create docker-compose.yaml

Create a docker-compose.yaml file and paste the configuration below. SikkerGuard needs NET_ADMIN to manage iptables and ipset rules, SYSLOG to read the kernel log for real-time block monitoring, and network_mode: host for access to the host network stack.

docker-compose.yaml

services:
  sikkerguard:
    image: sikkerapi/guard:latest
    network_mode: host
    cap_add:
      - NET_ADMIN
      - SYSLOG
    devices:
      - /dev/kmsg:/dev/kmsg
    env_file:
      - .env
    volumes:
      - sikkerguard-data:/var/lib/sikkerguard
    restart: unless-stopped

volumes:
  sikkerguard-data:

Nano editor showing the complete docker-compose.yaml with SikkerGuard service definition including network_mode host, NET_ADMIN and SYSLOG capabilities, and persistent volume — Paste the configuration and save

Step 4

Create your .env file

Create a .env file containing your API key. This is the only required setting. Optional variables like SIKKER_SCORE_MIN and SIKKER_PULL_INTERVAL let you fine-tune blocking behavior. See the full configuration reference for all available options.

.env

# API key (required)
SIKKER_API_KEY=sk_free_your_key_here

# Optional: only block high-confidence threats (default: 50)
SIKKER_SCORE_MIN=60

# Optional: refresh interval in minutes (default: 1440)
SIKKER_PULL_INTERVAL=1440

Terminal showing nano .env command to create the environment file — Create the .env file

Nano editor showing .env file with SIKKER_API_KEY, SIKKER_SCORE_MIN set to 60, and SIKKER_PULL_INTERVAL set to 1440 — Paste your API key and save

Security tip: Add .env to your .gitignore to keep credentials out of version control.

Step 5

Start SikkerGuard

Start the container in detached mode. Docker pulls the latest SikkerGuard image automatically on first run.

Start the container

$ sudo docker compose up -d

Terminal showing docker compose up output: creating volume sikkerguard-data, creating sikkerguard_1 done — Container created and running

Check the logs to verify SikkerGuard pulled the blocklist and started blocking:

View logs

$ sudo docker compose logs

SikkerGuard logs showing startup: score threshold 60, safety whitelist of 9 IPs and 8 CIDR ranges, firewall ready, pulling blocklist from SikkerAPI, SikkerGuard running, blocking 56450 IPs, connectivity test passed — SikkerGuard is protecting the server — blocking 56,450 known malicious IPs

Done. Your server is now protected. SikkerGuard automatically refreshes the blocklist, logs blocked connections, and reports them back to improve threat data for everyone. Read the full documentation for configuration options, safety guarantees, health checks, and monitoring.

Limits

Blacklist limits by plan

The number of IPs SikkerGuard can block depends on your subscription tier. The blacklist limit determines how many IPs are returned when SikkerGuard pulls the blocklist from the API.

Plan	Blacklist IPs	Price
Free	5,000	$0/mo
Basic	50,000	$7/mo
Small Business	75,000	$14/mo
Medium Business	150,000	$28/mo
Large Business	350,000	$56/mo

All plans include full blacklist access, community reporting, and automatic blocklist updates. Higher tiers block more IPs and include email support. See the pricing page for a full comparison of all features.

FAQ

Frequently asked questions

What does SikkerGuard actually do?

SikkerGuard pulls a list of known malicious IPs from the SikkerAPI blacklist and loads them into an ipset — a kernel-level hash table. Incoming packets from those IPs are dropped before they reach your applications. It also logs blocked connections in real time and reports them back to SikkerAPI so the threat data improves for everyone.

Why does it need elevated privileges (NET_ADMIN, SYSLOG)?

NET_ADMIN is required to create and manage iptables rules and ipset sets — these are kernel-level firewall operations that need root-equivalent network permissions. SYSLOG allows reading /dev/kmsg (the kernel message buffer) so SikkerGuard can tail iptables LOG entries and show you blocked connections in real time. Without SYSLOG, blocking still works but you won't see live logs.

Why does it need network_mode: host?

iptables rules are per-network namespace. With the default bridge network, SikkerGuard would only modify the container's own firewall — not the host's. network_mode: host gives the container access to the host's network stack so it can manage the host's INPUT chain, detect the default gateway, and read the host's DNS configuration.

Can SikkerGuard lock me out of my server?

No. SikkerGuard has seven layers of lockout prevention. On startup, it auto-whitelists your default gateway, DNS servers, host IPs, LAN subnets, and the SikkerAPI endpoint. All private IP ranges (RFC1918) are permanently whitelisted. After every blocklist update, a connectivity self-test checks gateway, DNS, and API reachability — if any test fails, rules are rolled back immediately. You can also manually whitelist IPs with the SIKKER_WHITELIST environment variable. See the safety guarantees documentation for details.

Does it permanently modify my firewall?

No. All iptables rules and ipset sets are held in kernel memory only — nothing is written to disk or persisted to firewall config files. On graceful shutdown ( docker compose down), every rule and set is removed. Your firewall returns to exactly how it was before SikkerGuard started. If the container crashes, rules stay in place for protection and are cleaned up on the next start.

What happens if SikkerGuard crashes?

If the process crashes unexpectedly, the firewall rules are intentionally left in place — your server stays protected. On the next container start, SikkerGuard cleans up stale rules before applying a fresh blocklist. With restart: unless-stopped in your docker-compose, Docker will restart the container automatically.

Does it work alongside UFW or firewalld?

SikkerGuard inserts its rules at the top of the iptables INPUT chain, so they execute before most other rules. It generally coexists with UFW (which also wraps iptables). With firewalld, direct iptables manipulation can conflict with zone-based state tracking — test connectivity after deploying if you use firewalld. For best results, use SIKKER_DRY_RUN=true first to verify before applying rules.

What is the performance impact?

Negligible. ipset uses a kernel-level hash table for O(1) per-packet lookups — no user-space processing per packet. A typical blocklist of 50,000 IPs uses roughly 10MB of kernel memory. The container itself idles at under 100MB RAM and near-zero CPU. The only brief spike is during blocklist updates (a few seconds while loading IPs into ipset).

Does it support IPv6?

Yes. SikkerGuard maintains separate ipset sets and ip6tables rules for IPv6 traffic. Both IPv4 and IPv6 attackers are blocked transparently from the same blocklist pull.

How often is the blocklist updated?

By default, every 24 hours. You can change this with SIKKER_PULL_INTERVAL (in minutes, minimum 60). The blocklist is cached to a persistent volume, so container restarts don't burn an extra API call if the cache is still fresh.

What does SikkerGuard report back?

Every 30 minutes (configurable), SikkerGuard sends a bulk report of blocked IPs, including packet counts and detected protocols (SSH, HTTP, MySQL, etc.). This feeds back into SikkerAPI's threat intelligence, improving blocklist accuracy for all users. Reporting can be disabled with SIKKER_REPORT_ENABLED=false.

Is SikkerGuard free?

Yes. SikkerGuard works on the free SikkerAPI plan with up to 5,000 blocked IPs. Paid tiers unlock larger blocklists (up to 350,000 IPs on the Large Business plan).