With an office network most companies will use ingress filtering to add a level of security, however few take advantage of egress filtering to protect their networks. The use of egress filtering will of course cause issues for some users as it requires policy changes for all new software that is deployed but does the protection it offers for instance against botnets outweigh the cost of extra management for most organisations?

What are the pros and the cons of Egress filtering? Specifically when referring to the network of a medium sized software development business.

From Area 51 Proposal Question

  • I am so confused by the question and the answers here. I don't even see a definition of what "Egress filtering" is. I'm pretty sure that you have both the word spelling and its definition incorrect. See RFC 2827 -- ietf.org/rfc/rfc2827.txt
    – atdre
    Commented Apr 11, 2011 at 18:23
  • @atdre, Egress filtering is pretty well defined, and the spelling seems to be correct to me (unless there's some weird American/British/European differences, ah @Rory?). See even en.wikipedia.org/wiki/Egress_filtering
    – AviD
    Commented Apr 12, 2011 at 17:45
  • The terminology is a poor choice. Egress is traffic entering a network, and ingress is traffic leaving a network. Maybe I'm wrong about this, but I tend to not believe Wikipedia occasionally.
    – atdre
    Commented Apr 12, 2011 at 19:11
  • Websters 'egress' a place or means of going out. Commented Apr 12, 2011 at 20:09
  • @atdre The RFC is written from a service provider viewpoint -- "ingress filtering" there means filtering traffic coming "in" to the SP network from a customer, i.e. going out towards the Internet. The equivalent on the customer side (which this question is about) is egress filtering.
    – Jakob Borg
    Commented Apr 23, 2011 at 20:49

7 Answers 7


PRO: strict control over everything that moves out of your network (and by extension, much of what moves in it).
CON: Your users feel the control. Considering that you're a development business, your users are pretty much technical, and would probably resent it.
CON: Considering that you're a development business, and your users pretty much technical, they are likely to legitimately install new programs, in the course of their work (how long was it till skype was allowed through?), and it will be difficult to keep track and update the filters.
PRO: your users are in effect restricted in what they can install :)
CON: Don't even consider this for each machine, while not completely pointless, its much easier to bypass.
PRO: As you mentioned, it can block certain usages of botnets and other unwitting malware.
PRO: It can hypothetically assist (as a first step) in data leakage prevention.

UBER-CON: It is trivial to bypass in most malicious scenarios by simply tunnelling over any ports/protocols you DO have open (this includes many types of adaptive worms), whereas in the non-malicious cases it's a real **tch to deal with.

Bottom Line: Egress filtering is a very good tool to give you control, but not very good for security.

  • 2
    +1 for your "UBER-CON". I was interested to learn that if we continue to have increased HTTPS traffic, instead of HTTP, that the default protocol for the web will be encrypted somewhere around 12 months from now. That makes egress monitoring and data loss prevention a bit more difficult. Good point.
    – pboin
    Commented Nov 24, 2010 at 15:37

A major advantage of egress filtering is that it forces you to get an understanding of what legitimate outbound traffic is required by your staff and systems. However the downside is that managing that will take time and money. Whether it's worth it will depend on whether you think that the threats you're mitigating are worth the cost.

In terms of how you do the egress filtering, where I've seen it done is mainly larger companies where there's no direct access to the Internet for end-users, and all outbound traffic has to go through proxy servers.

This has the advantage of enforcing a choke-point in your network where all the user Internet traffic will flow, and where it can be inspected, so in theory you can deploy IDS/IPS/DLP at this point to get a view of what content is coming into and leaving your network.

Of course to be really effective, you need to terminate and re-establish all SSL sessions there, so you can do content inspection.

As I said, the major question is, whether that level of cost and extra work is worth it for a given organisation.


Especially communication between servers have very predefined patterns of communications. By only allowing this traffick you are sure that noone will accidently compromise the server by adding new software, and thus raise the security.

The cons by doing this is the work it takes to maintain these filters. Not only do you need to open once new software is deployed, but you also need to make sure that you close once the sofwater is no longer needed or once it changes.

Using egress filters forces you to learn and know about the communication channels used by your server and software.



  • Increased security
  • Increased visibility of network traffic
  • Increased control


  • Increased overhead++
  • Increased complexity

I believe the answer is yes, but it all depends on your environment. At the very least organizations should consider a segmented network that controls ingress and egress traffic to their servers. I disagree that egress filtering is trivial to bypass. If it is implemented properly egress filtering can be a strong defensive layer. Implemented properly means that everything goes through a proxy. Exceptions should only be allowed to known and trusted endpoints.

  • Unless the proxy is the only machine that can get access to Internet DNS, then it is always possible to build a DNS covert channel using tools like skullsecurity's dnscat or doxpara's OzymanDNS
    – atdre
    Commented Apr 11, 2011 at 19:07
  • Good point and I agree. When I say everything goes through the proxy I mean everything.
    – sdanelson
    Commented Apr 13, 2011 at 3:00
  • Cool. Do you also whitelist the traffic/destinations that go through the proxy?
    – atdre
    Commented Apr 13, 2011 at 6:24
  • Depends on the business requirements. If security is the priority, yes. A middle of the road implementation would be to whitelist categories versus individual sites and block anything unlisted. Blocking anything unlisted creates a management pain point, but if you don't do it you might as well just leave things wide open.
    – sdanelson
    Commented Apr 14, 2011 at 0:11

I think the Pros and Cons have been well discussed and all point to the real issue here is in fact that of protecting against data loss.

I agree that Firewalls should be used to both protect you from others and at the same time others from you (i.e. from a worm outbreak) with sensible outbound filters. If you like its basically a good neighbour policy.

However as discussed, they are a blunt tool that can be trivially bypassed if someone is looking to ex-filtrate information from the organisation.

So the focus should be to protect against data loss and use the firewall as one component of this approach. Organisations should be monitoring outbound traffic as part of an overall organisational DLP (data loss protection) approach, which requires the monitoring of network traffic itself and looking for trends / exceptions / volume.


The problem that most people encounter is setting up ways to prevent the flow of DNS and HTTP/TLS outbound traffic. I'm fairly sure it's better to just install Whitetrash than even to use a firewall (including fancy ones like Palo Alto Networks) or secure web gateway.

If you are using a whitelist web gateway such as Whitetrash, and you've prevented all other outbound traffic, then you still need to worry about DNS covert channels. The easiest way is to just have an internal DNS server with no outbound connectivity -- and then to have the Squid proxy that runs Whitetrash either host Internet DNS or have it connect to a separate network that hosts Internet DNS servers. The browsers will get their DNS through the proxy. Yes, this actually works, but users will not be able to use any protocol traffic to the Internet which is not HTTP or SSL (and even that must go through the proxy). I suppose FTP and Gopher would work, too, if Squid was configured to allow them.

This would be a frustrating network to be connected to, and would only be possible in the most strict environments with oppressive infosec policies.

I'm not a fan of inspecting SSL traffic, but if you do -- make sure to not inspect banks/etc with the use of a whitelist. If you're using Whitetrash, you already probably have an extensive list to manage anyways.


I am surprised at the people saying this "might" be a good idea or "maybe" this is a good thing to do. It is absolutely the right thing to do. It won't stop something like a reverse tcp connection like what metasploit and others can set up over port 80 or 443 in a non proxy environment but it will stop random workstations from sending spam or other malware out on the net in some situations. It does add complexity but that is why we are paid the big bucks, right? :)

  • 1
    The question itself asks for both pros and cons. Not all office networks are alike and in some circumstances the impacts of egress filtering can hurt the business far more than the averted risk. There is no one right network configuration. Check out Rory's answer and note that AviD's answer points out the limitations of egress filtering.
    – nealmcb
    Commented Apr 23, 2011 at 17:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .