Network Egress and Ingress Fundamentals

There is a lot of confusion about network ingress and egress. This isn't limited to junior staff; I've witnessed this many times among software engineers and technology leaders alike. Often only network and firewall engineers really comprehend the topic fully, though this should not be the case.

A network connection must begin with an "initiator". This is usually thought of as a "client" in a traditional "client server" model. The client is defined not by their intention, purpose, or operating system, but simply by whether they are the first one to initiate a connection - usually by submitting a packet destined for the "server" to the network. Once a connection is established, it is true that both sides - client and server - generate packets intended for the other party. The notion of which party goes first, however, is essential for several reasons.

First, simple network architecture limits which party is able to receive an initial packet. Most "end-user computing" devices such as laptops and mobiles are not exposed to the Internet in a way that they can have packets addressed to them. Rather, they hide behind network gateways and can only speak outbound (egress). What distinguishes servers and makes it non-trivial to host a service on the Internet is that you need a valid routable IP address and network port that is always up and listening, waiting for inbound connections.

These conditions dictate that in most network communication end-user devices act as a client. They can egress an initial packet toward a server. When they do so, the network gateway that is usually hiding them remembers the attempted connection. When a response packet is received from the server, the gateway knows precisely which hidden internal device has sent it, and it ensures the response is able to make it to the client. Without this egress initiation, it would not be possible for server packets to make it back to the client. The server will never see the clients true IP address and identity; rather it will think the gateway is communicating with it.

When a client establishes a connection to a server, that communication is considered egress from the client perspective, and ingress from the server perspective. Despite the fact that millions of packets and gigabytes of data may be transmitted back and forth during the subsequent network session, it is that first packet - the initiation from the client - that defines which party can consider that entire communication an egress connection (the client) or an ingress connection (the server). Using an example, if you use your phone to visit a website such as dropbox.com and download a 100gB file, you have made an egress connection from your phone. Dropbox's servers will see an ingress connection from your gateway. The overwhelming majority of packets and data will be headed FROM the server TO your client (phone), but that changes nothing. The server is NOT performing egress. It is merely replying to ingress. The phone spoke first. That defined this entire communication as egress for the phone, and ingress for dropbox.com.

As a result, in the simple example above the server does NOT require egress network access! Yes, the server may reply to ingress traffic and technically transmit a large amount of data outbound. But all of that traffic is in response to ingress, and NOT egress connections.

This is exceedingly important, because security devices and rules work in the language of ingress (aka inbound) and egress (aka outbound). If you are running a server such as the one in our dropbox example, you would have to set up firewall rules or security groups that dictate what communication is permitted to or from the server. In this case you should define that connections can come INTO the server (ingress) on the specific web site port (usually 443 for HTTPS). You do NOT, however, need to permit any egress. The server does NOT need to initiate any communications outbound. If you set up rules like this, they will function perfectly for the designated purpose (allowing people to log in and download content) but the server itself will not be able to initiate connections or "surf the web". The only collateral damage in this case is that administrators on the server console will find that they cannot reach out to the Internet to update the operating system, download tools and packages, or transmit logs to Internet destinations. This is good and noble. Production enterprise servers should not be permitted to run updates and download software directly from the Internet. Rather, they should have deployments and upgrades conducted via internal networks from centralized infrastructure that does not communicate via Internet.

In addition to forcing compliance with policies prohibiting live updates from the Internet, denying egress connections from servers also means that they cannot establish command & control sessions to attacker infrastructure to grant them persistent access. It means they cannot be instructed to reach out to attacker-controlled servers and download malware even when there is a remote code execution vulnerability exploited. It means they cannot open outbound file transfer connections such as SFTP to exfiltrate stolen data. Killing egress access from servers destroys many attacker capabilities and disrupts the kill chain in the majority of high-profile cyber attacks. It is rarely performed, however, because the majority of technologists do not understand the difference in network ingress and egress. A common misconception is that egress access is required so customers can download files or view web content. This is inaccurate. A seasoned firewall admin will quickly recognize this conversation:

Software Engineer: "I need port 443 open on my server, please"
Firewall Engineer: "In which direction?"
Software Engineer: "Both".

Wrong. That's always wrong. In some organizations, that will put the Software Engineer on a "no-fly list" and prohibit them from making any future firewall requests. Ok that part isn't true. But a LOT of firewall engineers have thought about it. Trust me.

You want INGRESS access only. Don't worry about the reply packets making it back to the client. That's included by default.

For the more technically minded, there are little caveats and gotchas all around this. None of them matter. Yes, it requires a stateful network device to perform all the magic listed above. Everything on the planet is stateful these days. Yes UDP technically doesn't support statefulness because there are no flags available. Again, that doesn't matter. Gateways observe communication paths and "synthesize" state so return packets are routed properly. Yes, there is no such thing as a "gateway" despite all the vendor coursework. There are really firewalls, routers, and/or NAT devices. The overlap among those categories has gotten messier and messier over the years, so let's just call them all gateways and get on with it. 

It's worth investing the time and research to understand these distinctions. In addition to being able to comprehend specific forensic details and incident discussions with more accuracy, this knowledge empowers you to enable simple, zero-cost controls that can create significantly more network protection that expensive, complex cyber-specific commercial tools.