Block Malicious IPs Automatically with New Nginx and iptables Integrations
We just shipped two integrations that SikkerAPI users have been asking for: Nginx and iptables/ipset blocking powered by real-time honeypot threat intelligence. Both are free to use, require no code changes, and can be set up in under five minutes.
If you run a Linux server, you can now automatically block malicious IPs at the web server or kernel level — using threat intelligence from our 39+ global honeypots and community-reported incidents that power the rest of SikkerAPI.
Why Server-Level Blocking Matters
Application-level security (rate limiting, WAF rules, login throttling) is important, but it still means your server is processing requests from known attackers. Every malicious request that reaches your application consumes CPU, memory, and bandwidth.
Blocking at the Nginx or iptables level stops traffic before it touches your application:
- iptables/ipset drops packets at the kernel level — the lowest overhead possible
- Nginx geo module blocks requests before they reach your upstream — no application changes needed
Both use SikkerAPI's Blacklist API to fetch IPs ranked by confidence score, so you're blocking based on real evidence — observed honeypot attacks and credibility-weighted community reports.
Nginx Integration
The Nginx integration uses Nginx's built-in geo module to block IPs before they reach your application. No custom modules, no recompilation.
How it works
- A cron job fetches the latest threat IPs from SikkerAPI's Blacklist API
- The script writes them to a file Nginx can read
- Nginx reloads and starts blocking
Quick setup
Download the update script and save your API key:
sudo curl -o /usr/local/bin/sikkerapi-nginx-update.sh \
https://sikkerapi.com/nginx/sikkerapi-nginx-update.sh
sudo chmod +x /usr/local/bin/sikkerapi-nginx-update.sh
echo "sk_free_your_key_here" | sudo tee /etc/nginx/sikkerapi.key
sudo /usr/local/bin/sikkerapi-nginx-update.shThen add the geo block to your nginx.conf:
geo $sikkerapi_blocked {
default 0;
include /etc/nginx/sikkerapi_blocklist.conf;
}
server {
if ($sikkerapi_blocked) {
return 403;
}
}Schedule with cron to update the blocklist every 12 hours:
0 */12 * * * /usr/local/bin/sikkerapi-nginx-update.shTwo-tier blocking
For more control, you can run two blocklists at different confidence thresholds:
- Hard-block IPs with confidence 90+ (drop the request entirely)
- Challenge IPs with confidence 50-89 (serve a captcha or interstitial page)
This lets you be aggressive with known attackers while giving borderline IPs a chance to prove they're human. The full Nginx guide covers the two-tier setup in detail.
Reverse proxy support
If you're behind a CDN or load balancer, the integration works with Nginx's realip module to extract the real client IP from X-Forwarded-For. You can also filter by protocol — add protocols=http to only block IPs that attacked HTTP honeypots, keeping your blocklist focused.
iptables/ipset Integration
The iptables/ipset integration blocks IPs at the Linux kernel level. Packets from malicious IPs are dropped before any application sees them — the lowest-overhead blocking possible.
How it works
- A cron job fetches threat IPs from SikkerAPI
- The script separates IPv4 and IPv6 addresses into separate ipsets
- Uses atomic swap (
ipset swap) to replace the live sets instantly — zero downtime - iptables rules in the INPUT chain drop all traffic from those IPs
Quick setup
Download the update script and save your API key:
sudo curl -o /usr/local/bin/sikkerapi-ipset-update.sh \
https://sikkerapi.com/iptables/sikkerapi-ipset-update.sh
sudo chmod +x /usr/local/bin/sikkerapi-ipset-update.sh
echo "sk_free_your_key_here" | sudo tee /etc/sikkerapi.key
sudo chmod 600 /etc/sikkerapi.key
sudo /usr/local/bin/sikkerapi-ipset-update.shAdd the iptables rules for IPv4 and IPv6:
sudo iptables -I INPUT -m set --match-set sikker4 src -j DROP
sudo ip6tables -I INPUT -m set --match-set sikker6 src -j DROPSchedule with cron to update the blocklist daily at 3 AM:
0 3 * * * /usr/local/bin/sikkerapi-ipset-update.shWhy ipset instead of raw iptables rules?
A naive approach would add one iptables rule per IP. With 5,000 IPs, that means 5,000 rules evaluated sequentially for every incoming packet. ipset uses hash tables internally — lookups are O(1) regardless of set size. Whether you're blocking 100 IPs or 100,000, the performance impact is the same.
The atomic swap is equally important. Without it, you'd need to flush the old rules and add new ones — leaving a window where no blocking is active. ipset swap replaces the entire set in a single kernel operation with no gap.
Persistence across reboots
On Debian/Ubuntu, install ipset-persistent and the sets survive reboots automatically:
sudo apt install ipset-persistentOn RHEL/CentOS/Rocky, save the sets to disk and create a systemd unit to restore them before iptables loads. The full iptables guide covers distribution-specific persistence in detail.
Filtering options
Both integrations support the full range of Blacklist API filters:
- Confidence score — block only high-confidence threats (90+), or cast a wider net (50+)
- Protocol — block only IPs that attacked specific protocols (SSH, HTTP, SMTP, etc.)
- Country/ASN — exclude trusted regions or focus on specific origins
- IP version — IPv4-only mode if you don't need IPv6 blocking
Configure via environment variables:
SIKKERAPI_SCORE=90 SIKKERAPI_EXTRA="protocols=ssh" \
/usr/local/bin/sikkerapi-ipset-update.shThis example only blocks IPs with confidence 90+ that attacked SSH honeypots.
Works on the Free Tier
Both integrations work with the free tier — no credit card, no paid plan required. The free tier includes a daily blacklist quota that's separate from your lookup quota, so blocking IPs doesn't eat into your API calls.
IPs are returned sorted by confidence score (highest first), so even if your quota limits the total number, you're always getting the most dangerous IPs first.
Need higher limits? Paid plans start at $7/month.
What Makes This Different
There are plenty of static blocklists you can download. What makes these integrations different is the data behind them.
SikkerAPI's blocklist is backed by two independent data sources. First, our network of 39+ honeypots observes real attacker behavior across 16 protocols — brute-forcing SSH credentials, running SQL injection queries against database honeypots, attempting lateral movement via SMB, or downloading malware through HTTP traps. Second, community-reported incidents across 16 categories (from Fail2Ban auto-reports, bulk CSV uploads, and manual submissions) contribute additional signal from security practitioners worldwide.
The confidence score weighs both sources. Honeypot evidence carries weight because it's directly observed behavior. Community reports are credibility-weighted by unique reporters, category diversity, and whether they corroborate what the honeypots already saw. When both sources agree on an IP, the corroboration multiplier kicks in — making the score more reliable than either source alone.
When you set scoreMinimum=70, you're blocking IPs backed by real evidence — observed attacks, verified community reports, or both.
Combine with Fail2Ban and CSF
These new integrations complement our existing Fail2Ban and CSF Firewall integrations:
- Fail2Ban reports your attackers back to SikkerAPI, contributing to the community threat database
- Nginx/iptables blocks known attackers proactively, before they ever touch your server
- CSF combines both — pre-emptive blocking and automatic reporting
Using them together creates a feedback loop: your Fail2Ban bans feed into SikkerAPI's scoring, which improves the blocklists that protect everyone else's servers.
Get Started
- Nginx integration guide — full setup with two-tier blocking, reverse proxy support, and troubleshooting
- iptables/ipset integration guide — full setup with persistence, IPv6, and filtering options
- Blacklist API reference — all available filters and response formats
- Pricing — free tier included, paid plans from $7/month
Both scripts take under five minutes to set up. If you run into issues, reach out — we're happy to help.
Comments
No comments yet. Be the first to share your thoughts!