Node-Level Firewall Rules
Per-server firewall rules
that fire before you wake up.
Flowtriq executes firewall commands directly on each server the moment an attack is detected, and reverses them when the incident resolves. This is your first line of defense at the node level. For network-wide BGP mitigation and cloud scrubbing, see BGP Mitigation and Cloud Scrubbing.
How It Works
Trigger → Command → Undo. Fully automated.
You configure a rule with a trigger condition (PPS threshold, severity level, or attack family) and a firewall action. When detection fires and the trigger matches, FTAgent executes the exact command you approved - on the server, immediately.
Every rule has a live command preview so you see the exact shell command before it ever runs. When the incident resolves, the paired undo command runs automatically to restore normal traffic flow.
A cooldown timer prevents repeated firing on the same attack, and the full audit trail records every execution with timestamp, rule name, and incident ID.
| Trigger types | PPS threshold, severity, attack family, any incident |
| Action tools | iptables, ipset, nftables, ufw, tc, null route, fail2ban, Cloudflare WAF, DigitalOcean Firewalls, Vultr Firewalls |
| Command preview | Exact shell command shown before activation |
| Auto-undo | Paired undo command runs on incident resolution |
| Cooldown | Configurable per rule (default 5 min) |
| Target scope | All nodes or specific nodes per rule |
Trigger: PPS > 50,000
Action: iptables drop UDP INPUT
09:44:19 ⚠ PPS=47,821 threshold crossed
→ Trigger matched · executing...
→ iptables -A INPUT -p udp -j DROP
✓ Rule applied (0.3s)
09:52:04 incident resolved
→ iptables -D INPUT -p udp -j DROP
✓ Rule removed · normal traffic
_
Execution Timeline
From detection to mitigation in under a second
Attack detected (T+0s)
FTAgent detects threshold crossing, classifies the attack, and opens an incident. The event is dispatched to all configured mitigation rules immediately.
Trigger evaluation (T+0.01s)
Each active rule's trigger condition is checked against the incident: does the PPS exceed the threshold? Does the severity match? Is this the right attack family? Rules that match proceed.
Command execution (T+0.05–0.3s)
The exact shell command you approved is executed on the server via the FTAgent. The command is the same one shown in the live preview when you configured the rule - no surprises.
Audit log entry (T+0.3s)
Execution is recorded in the audit log with rule name, incident ID, command, timestamp, and result. Immutable and exportable.
Auto-undo on resolution
When the incident resolves (PPS drops below threshold), the paired undo command removes the firewall rule automatically. You don't need to remember to clean up.
Action Types
Every major Linux firewall tool, plus kernel-level mitigations
Drop protocol
Drop all inbound packets of a given protocol. Stops single-protocol floods instantly.
Drop source IP / CIDR
Block all traffic from an identified attacker address or subnet.
Drop destination port
Block traffic on a specific port. Stops amplification attacks (DNS 53, NTP 123).
Rate limit source IP
Throttle packets per second from identified sources using hashlimit.
Ban to ipset
Add attacker IP to a named ipset with automatic TTL expiry.
Drop protocol / port
nftables-native drop rules for modern kernel firewall setups.
Deny protocol / IP
ufw deny rules for Ubuntu/Debian servers using ufw as their primary firewall.
Rate limit interface
Linux tc ingress policing to limit interface throughput during volumetric floods.
Blackhole source IP
Route attacker IP to null - drops packets at the routing layer before they reach the firewall.
Ban IP in jail
Add attacker IP to a specific fail2ban jail using the fail2ban-client.
Kernel-Level Mitigations (via Agent)
Five additional intent types executed directly by ftagent via pending_commands. These configure kernel and nftables state on the target node, rather than going through BGP adapters.
Per-source-IP rate limit
nftables meter rule limits PPS from each source IP independently. Stops botnet floods without blocking all traffic to the destination.
SYN cookies
Enables net.ipv4.tcp_syncookies=1 and adds an nft SYN rate-limiter. Prevents SYN flood exhaustion without dropping legitimate connections.
Conntrack UDP timeouts
Sets short nf_conntrack_udp_timeout sysctls and applies an nft ct timeout policy. Flushes UDP conntrack entries faster during floods to reduce state exhaustion.
Drop fragmented UDP
Adds ip frag-off != 0 drop nftables rule for the target IP. Blocks fragmented UDP used in amplification attacks while passing normal UDP traffic.
Challenge-response (SYNPROXY)
Deploys TCP SYNPROXY nftables rule plus ct state invalid drop. Validates TCP handshakes at the kernel before forwarding to the application. Effective against SYN flood botnets.
Intelligent Mitigation Controls
Confidence scoring, dry-run, and soft-whitelist
Flowtriq's mitigation engine assigns a confidence score to each attack event (0.0-1.0) based on severity, number of corroborating nodes, and attack family certainty. You can set a minimum confidence threshold below which events only trigger alerts instead of deploying rules.
Dry-run mode lets you validate your escalation policy without deploying anything. Rules are logged as if they were announced, but no adapter or kernel command is invoked. Use it when tuning thresholds on production traffic.
Soft-whitelist converts drop intents to rate-limit intents for protected CIDRs. Traffic from a partner range or internal network gets throttled instead of blackholed, preserving connectivity while still limiting attack volume.
Severity: high Nodes: 3
Confidence: 0.88 Threshold: 0.65
✓ Confidence sufficient — generating intents
Mode: DRY-RUN
→ Would announce: syn_cookie
→ Would announce: drop_tcp_syn
[DRY-RUN] No commands queued.
_
Cloud Firewall Integrations
Block attacks at the cloud edge
In addition to local Linux firewall tools, Flowtriq can push block rules directly to cloud provider firewalls, stopping attacker traffic before it ever reaches your server.
Auto-create WAF block rules
Auto-create Cloudflare WAF rules blocking attacker IPs by CIDR. Integrates with your existing zone rules. No manual dashboard access needed.
Add IPs to Cloud Firewall deny list
Add attacker source IPs to your DigitalOcean Cloud Firewall deny list automatically. Works across all Droplets in the firewall group.
Block IPs at Vultr firewall level
Block attacker IPs at the Vultr firewall level before they reach your server. Configured with your Vultr API key and firewall group ID.
Manual vs. Automated
Every second without mitigation costs you
Manual mitigation
- Alert fires - on-call engineer wakes up
- SSH to server (1–5 min if they're asleep)
- Run iptables command from memory or runbook
- 2–10 minutes of unmitigated attack traffic
- Remember to remove rule when attack ends
- No audit trail unless you write it manually
Flowtriq Firewall Rules
- Attack detected in under 1 second
- Firewall rule executes within the same second
- No human involved for standard attack patterns
- Rule auto-removes when incident resolves
- Full audit trail with timestamps and commands
- Configurable risk warnings for broad rules
FAQ
Common questions about firewall rules
Does Flowtriq have root access to my server?
No. The FTAgent runs as whatever user you choose. For mitigation rules that require root (iptables, tc, etc.), the agent needs to be run with sudo or as root. You install it yourself and control the permissions. Flowtriq never stores or transmits your server credentials.
What if a firewall rule blocks legitimate traffic?
Every broad rule (blocking a protocol, dropping all UDP) shows an inline risk warning in the dashboard before you save it. The undo command runs automatically when the incident resolves. You can also disable a rule instantly from the dashboard without SSH access.
What is the cooldown timer for?
It prevents the same rule from firing repeatedly on a single sustained attack or on closely-spaced incidents. The default is 5 minutes. You can set it from 1 to 1,440 minutes per rule.
Can I test a rule without a real attack?
Yes. You can see the exact command that will execute in the live command preview before saving the rule. The audit log shows every historical execution so you can verify rules worked as expected.
How is this different from fail2ban running standalone?
Fail2ban reacts to log entries, which adds latency and requires log parsing config. Flowtriq triggers from real-time network metrics - the moment traffic crosses the threshold, not after log lines accumulate. And unlike standalone fail2ban, you get a full audit trail, per-node targeting, and central management without SSH.
What is dry-run mode?
Dry-run mode processes attack events and generates mitigation intents normally, but logs every rule as if it were deployed without actually executing any adapter call or kernel command. This lets you validate your confidence threshold, escalation policy, and soft-whitelist configuration against real production traffic before committing to live deployment. Enable it in Escalation Policy settings.
What are kernel-level mitigations and do they require root?
Kernel-level mitigations (per-src-IP rate limiting, SYN cookies, conntrack UDP timeouts, drop fragmented UDP, and SYNPROXY challenge-response) are nftables rules and sysctl changes queued via pending_commands to nodes running ftagent. The ftagent must run as root on the target node to apply these. They are distinct from BGP adapter rules and execute directly on the server kernel, not via BGP announcement.
Related Features
Firewall rules work best alongside these
FAQ