Nearly every firewall policy is written as if attacks only arrive. Inbound rules are argued over line by line; outbound is left at "allow all" because that is what happens when you write nothing.
But the inbound rules only decide whether an intrusion starts. The outbound rules decide what it can do afterwards — and afterwards is where the cost is.
Once a process on your server is executing code it should not be, it needs the network to be worth anything to the attacker. Stolen data has to be uploaded somewhere. A dropper has to fetch its second stage. A mining payload has to reach a pool. A foothold has to check in with a control channel and wait for instructions.
All four are outbound connections to destinations your application has no legitimate reason to contact. An egress policy that lists the destinations your application does need turns every one of them into a failed connection and a log line, on a schedule the attacker does not control.
It also catches the boring failures. A misconfigured backup job writing to the wrong bucket, a library phoning home with telemetry, a staging instance pointed at the production database: all show up as denied egress before they become an incident.
The reason egress stays open is that nobody knows what the application talks to. Find out empirically rather than from documentation.
Start with what you know a normal application tier needs: DNS to your resolver, TCP 443 to your package mirror and container registry, the database port to the database tag, and the specific third-party APIs the code calls — payment provider, mail relay, object storage endpoint. That list is usually four to eight destinations, and it is shorter than people expect.
Then add rules for what you find. Watch denied outbound connections in the log for a full business cycle — a week, including whatever runs at month end — before you tighten anything in production. Nightly jobs, certificate renewals and update checks only appear when they run, and a quarterly report generator that reaches an external service will not show up in a Tuesday afternoon sample.
Prefer tags and internal ranges over hostnames where you can. A rule that says "to tag: database on 5432" stays correct when the database is rebuilt; an allow list of IP addresses for a SaaS API will not, because the provider changes them without telling you. For those, allow the port to a narrow set and accept that you will revisit it.
A common objection is that outbound rules will break replies to inbound traffic. They do not. A stateful firewall tracks sessions: a request allowed inbound has its response allowed out automatically, with no counterpart rule. You are writing policy for connections your servers initiate, which is a much smaller set than all traffic.
The corollary is that your outbound list is about the application's dependencies, not its users. That is the list your team should be able to write down anyway.
Not every tier deserves the same rigour. Rank by what an attacker would want.
The data tier should be close to silent: replication, backup target, resolver, nothing else. A database initiating an HTTPS connection to the internet is either a misconfiguration or an exfiltration in progress, and there is no third option.
The application tier is where the allow list lives, and where the work is. The web tier usually needs even less than the application tier — package mirror, resolver, and the application tag it forwards to.
Anything holding regulated data — cardholder scope, health records, personal data under a processing agreement — gets an explicit outbound policy for a second reason: it is evidence. "Outbound restricted to four approved endpoints, rule set exported monthly" is a control an auditor can test. "Allow all" is a finding.
Inbound rules decide whether an intrusion starts; outbound rules decide what it achieves. Build the allow list from a week of denied-connection logs rather than from documentation, use tags for internal destinations, and be strictest on the data tier. Stateful rules mean replies to allowed sessions need no rule of their own — you are only describing what your servers dial out to.
Antyxsoft Cloud Firewalls apply inbound and outbound rules together in one stateful policy, attached to a tag rather than a list of servers — see how Cloud Firewalls work.