{"id":1347,"date":"2026-10-09T23:06:57","date_gmt":"2026-10-09T23:06:57","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1347"},"modified":"2026-10-09T23:06:57","modified_gmt":"2026-10-09T23:06:57","slug":"auditing-outbound-egress-firewall-rules-vps-security","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/auditing-outbound-egress-firewall-rules-vps-security\/","title":{"rendered":"Auditing Outbound Egress Rules with nftables and ufw to Catch Data Exfiltration"},"content":{"rendered":"\n

Most firewall reviews focus on inbound ports. That is backwards for a VPS threat model. An attacker who has already executed code does not need inbound access; they need outbound<\/em> reachability to move your data somewhere else. Auditing egress rules is the highest-value security exercise most small deployments never do. This article covers how to inspect what your nftables or ufw rules really allow outbound, and how to build a baseline that surfaces unexpected traffic.<\/p>\n\n\n\n

Default Policies Decide Everything<\/h2>\n\n\n\n

The single most important setting is the OUTPUT chain policy. A default of accept<\/code> means every process on the box, including a compromised one, can open any outbound connection it likes. Start by reading the live ruleset rather than assuming what an installer created.<\/p>\n\n\n\n

# nftables: show the full ruleset with handles\nsudo nft list ruleset\nsudo nft -a list chain inet filter output\n\n# ufw: show the raw backing rules, not the friendly summary\nsudo ufw status verbose\nsudo iptables -S OUTPUT\nsudo iptables -L OUTPUT -n -v<\/code><\/pre>\n\n\n\n
ufw’s status verbose<\/code> hides a lot. Always drop to iptables -S<\/code> to see the actual ACCEPT and DROP rules, including the ones ufw inserts above your own. If you see -P OUTPUT ACCEPT<\/code> with no restrictive chain, you have no egress control at all.<\/p>\n\n\n\n
What Legitimate Egress Looks Like<\/h2>\n\n\n\n
Before you can block, you must enumerate. A typical web or API VPS legitimately talks to: DNS resolvers (53\/853), package repositories (80\/443), NTP (123), your database replica, your object storage endpoint, and your monitoring\/APM collector. Everything else deserves a reason.<\/p>\n\n\n\n
Direction<\/th>Purpose<\/th>Typical dest<\/th>Default action<\/th><\/tr><\/thead>
UDP 53\/853<\/td>DNS resolution<\/td>Configured resolvers<\/td>Allow, pin to resolver IPs<\/td><\/tr>
TCP 80\/443<\/td>Updates, APIs, object storage<\/td>Known CIDRs<\/td>Allow to allowlist<\/td><\/tr>
UDP 123<\/td>NTP time sync<\/td>NTP pool<\/td>Allow<\/td><\/tr>
TCP 25\/465\/587<\/td>SMTP<\/td>Relay only<\/td>Block direct, allow relay<\/td><\/tr>
TCP 1-1024<\/td>(no common need)<\/td>any<\/td>Log and block<\/td><\/tr>
TCP 4444\/1337\/31337<\/td>common C2 ports<\/td>any<\/td>Block<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Building a Logging-First Egress Policy<\/h2>\n\n\n\n
Do not jump straight to DROP. First log outbound attempts for a week to build a baseline, then restrict. With nftables, create a dedicated chain and log before the decision.<\/p>\n\n\n\n
table inet audit {\n  chain egress {\n    type filter hook output priority 0; policy accept;\n\n    ct state established,related accept\n    oifname \"lo\" accept\n\n    # log and count new outbound connections\n    ct state new log prefix \"EGRESS-NEW: \" level info\n    ct state new counter\n  }\n}\n# load it\nnft -f \/etc\/nftables.d\/audit-egress.nft\n# watch the log\njournalctl -k -f | grep EGRESS-NEW<\/code><\/pre>\n\n\n\n
With ufw you can approximate this using a LOG rule placed before your allow rules, but nftables gives far better control over chain order and counters. Whichever you use, the point is the same: establish what normal looks like before you break something in production.<\/p>\n\n\n\n
Red Flags in the Baseline<\/h2>\n\n\n\n
Reviewing the baseline log, look for these patterns, which are classic exfiltration and command-and-control indicators:<\/p>\n\n\n\n