When a volumetric DDoS attack hits your server, every second matters. Legitimate traffic drops off. The server starts choking under load. If the attack sustains long enough — full outage. Detecting the attack is only half the problem. Responding fast enough to actually limit the damage is where most setups fall short.
Approach Comparison: Three Ways to Handle Volumetric DDoS
Infrastructure teams deal with volumetric attacks in roughly three ways — and the cost-versus-protection tradeoff looks very different across each one:
1. Manual Monitoring + Manual Response
Someone watches dashboards or responds to an alert, then SSHs in to add firewall rules. This works for small setups where attacks are rare, but response time is measured in minutes — not seconds. By the time you confirm it’s an actual attack, the damage is already done.
2. Cloud-Based DDoS Scrubbing Services
Services like Cloudflare Magic Transit or AWS Shield Advanced route your traffic through scrubbing centers before it reaches your infrastructure. Highly effective, zero configuration on your servers — but the cost can be prohibitive. We’re talking hundreds to thousands of dollars per month depending on bandwidth.
3. On-Premise Automated Detection with FastNetMon
Run a traffic analysis daemon on your own hardware. When it detects anomalous traffic patterns, it automatically triggers mitigation — BGP blackholing, iptables rules, or API calls to upstream providers. Reaction time: under 10 seconds.
Which Approach Actually Fits Your Setup
- Manual: No cost, full control — but too slow, prone to human error, and completely useless when attacks hit at 3am.
- Cloud scrubbing: Works without touching your servers — but expensive, adds latency, and creates vendor lock-in.
- FastNetMon (on-premise): Reacts in seconds, runs on your own infra, community edition is free — setup requires BGP or firewall integration work, but it’s a one-time investment.
For most VPS operators and small-to-medium infrastructure owners, FastNetMon hits the right balance. I’ve run this in production — attacks get detected within 5–10 seconds and blocked before they saturate the uplink. Hasn’t missed one yet.
Why Manual Detection Fails Under Pressure
A UDP flood or ICMP amplification attack at multi-Gbps gives you no time to react manually. By the time an alert fires, you SSH in, and you confirm it’s actually an attack — the connection table is already exhausted. Legitimate users are being dropped while you’re still figuring out what’s happening. A solid automated mitigation setup needs three things:
- Faster than human reaction time — ideally under 30 seconds from detection to block
- Fully automated with no manual intervention required during the attack
- Precise enough to avoid blocking legitimate traffic alongside the attack sources
FastNetMon runs as a daemon that captures and analyzes traffic in real time. It can ingest sFlow or NetFlow data from your router, or capture directly via libpcap/AF_PACKET on the server itself — no special hardware required for a basic deployment.
Recommended Setup
For a typical VPS or bare-metal server, the simplest deployment is direct packet capture on the host:
[Internet] → [Your Server running FastNetMon + iptables]For a more robust setup where you control the upstream router:
[Internet] → [Router sending sFlow to FastNetMon] → [BGP Blackhole upstream]This guide covers the single-server setup with AF_PACKET capture and iptables response — it runs on any Linux server without needing BGP peering. The BGP blackhole section at the end is an optional upgrade.
Implementation Guide
Step 1: Install FastNetMon Community Edition
sudo apt-get update && sudo apt-get install -y wget
wget https://install.fastnetmon.com/installer -O installer
sudo chmod +x installer
sudo ./installerThe installer runs for about 5–10 minutes and pulls in all dependencies automatically. It also registers a systemd service.
Step 2: Configure Traffic Monitoring Thresholds
sudo nano /etc/fastnetmon.conf# Network interface to monitor
interfaces = eth0
# Protected IP networks (CIDR notation)
networks_list = /etc/networks_list
# Enable threshold-based detection
ban_for_pps = on
ban_for_bandwidth = on
ban_for_flows = on
# Thresholds — adjust based on your baseline traffic
threshold_pps = 20000 # 20K packets/sec
threshold_mbps = 1000 # 1 Gbps
threshold_flows = 3500 # 3500 flows/sec
# How long to block the attacker
ban_time = 3600 # 1 hour# Create your networks list — replace with your actual IP range
echo "203.0.113.0/24" | sudo tee /etc/networks_listStep 3: Create the Automated Response Script
FastNetMon calls a script whenever it detects or clears an attack. This is where you define the actual mitigation action:
sudo nano /usr/local/bin/fastnetmon_notify.sh#!/bin/bash
ACTION=$1 # "ban" or "unban"
IP=$2
DIRECTION=$3 # "incoming", "outgoing", "both"
LOG_FILE="/var/log/fastnetmon_actions.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
case "$ACTION" in
ban)
iptables -I INPUT -s "$IP" -j DROP
iptables -I FORWARD -s "$IP" -j DROP
echo "$TIMESTAMP - BANNED $IP (direction: $DIRECTION)" >> "$LOG_FILE"
# Optional: send Telegram notification
# curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \
# -d "chat_id=${CHAT_ID}&text=DDoS blocked: ${IP}"
;;
unban)
iptables -D INPUT -s "$IP" -j DROP 2>/dev/null
iptables -D FORWARD -s "$IP" -j DROP 2>/dev/null
echo "$TIMESTAMP - UNBANNED $IP" >> "$LOG_FILE"
;;
esacsudo chmod +x /usr/local/bin/fastnetmon_notify.shWire the script into FastNetMon’s config by adding this line:
# Add to /etc/fastnetmon.conf
notify_script_path = /usr/local/bin/fastnetmon_notify.shStep 4: Start FastNetMon and Verify Traffic Capture
sudo systemctl enable fastnetmon
sudo systemctl start fastnetmon
sudo systemctl status fastnetmonCheck real-time traffic stats with the built-in client:
sudo fastnetmon_clientYou’ll see output like this, updated every few seconds:
FastNetMon v1.2.7 client
Incoming traffic: 235 Mbps / 45K pps
Outgoing traffic: 45 Mbps / 8K pps
Top hosts by packets (incoming):
203.0.113.45 UDP 12450 pps 450 Mbps ← Attack candidate
198.51.100.22 TCP 234 pps 12 MbpsTraffic showing up in the stats means capture is working. Any IP that blows past your thresholds will trigger the notify script automatically — no further intervention needed for basic protection.
Step 5: BGP Blackholing for Upstream Mitigation (Advanced)
If your hosting provider supports BGP communities for blackholing — most major providers do — FastNetMon can announce the attacked IP via BGP. Traffic gets dropped at your ISP’s edge, before it ever reaches your network:
# Add to /etc/fastnetmon.conf
gobgp = on
gobgp_next_hop = 192.0.2.1 # Blackhole next hop (provider-specific)
gobgp_announce_host = on
gobgp_community = 65000:666 # Your ISP's blackhole communityBGP announcements typically propagate within 60 seconds. After that, no traffic destined for the attacked IP touches your server at all. That’s the critical difference from iptables: kernel-level rules still absorb traffic up to your NIC’s capacity; BGP blackholing kills the flood upstream before it gets anywhere near your hardware.
Tuning and Avoiding False Positives
After running for a few days, check your action log to see if legitimate IPs are getting caught:
grep BANNED /var/log/fastnetmon_actions.log | awk '{print $5}' | sort | uniq -c | sort -rnCDN providers (Cloudflare, Fastly, Akamai) appearing repeatedly in that list is a red flag. A legitimate traffic spike from those IP ranges can look identical to an attack. Whitelist their CIDRs — otherwise you’ll end up blocking your own CDN during a busy day:
# Add trusted IPs or CIDRs to the whitelist
echo "103.21.244.0/22" | sudo tee -a /etc/white_list # Cloudflare example
sudo systemctl restart fastnetmonAlso review your thresholds against real baseline traffic. If your server routinely handles 15K pps during normal business hours, a 20K threshold will fire on busy afternoons, not just attacks. Pull a week of traffic stats before locking in those numbers:
# Check current peak traffic in FastNetMon logs
grep "pps" /var/log/fastnetmon.log | tail -100How It Behaves During an Actual Attack
The sequence is fast. FastNetMon spots the anomaly within one sampling period — typically 2–5 seconds. The notify script fires. The attacking source gets blocked at the kernel level. Traffic from every other IP continues unaffected, including sources in the same subnet as the attacker.
The community edition covers the scenarios you’re most likely to hit: UDP floods, ICMP amplification, SYN floods. Need per-prefix analytics, rate-limiting instead of hard blocks, or more granular reporting? FastNetMon Advanced handles that. For raw volumetric protection without a commercial budget, community edition is more than enough for the real-world attacks most servers actually see.
