Last updated at Fri, 12 Jan 2024 15:34:48 GMT
Why And How You Should Control What's Leaving Your Network
Most companies have firewall rules that restrict incoming traffic, but not everyone thinks to restrict data leaving the network. That's a shame, because a few easy configurations can save you a lot of headaches.
Firewall egress filtering controls what traffic is allowed to leave the network, which can prevent leaks of internal data and stop infected hosts from contacting their command & control servers. NAT alone won't help you - you actually have to restrict the ports through which your internal hosts can communicate with the outside world. Consider this interesting story on the Spiceworks Community about a company getting heavily infected with malware - and one of their lessons learned:
"We've concluded that it's worth it to configure a firewall with an "Allow Only/Deny All" rule set for a LAN. That is to only allow the LAN services specifically defined in the firewall's rule sets and otherwise deny all other traffic. There have been discussions before about the risk implications of the reciprocate method, which is what we were configured with at the time -- a "Deny Only/Allow All" LAN rule set. That is where ALL LAN sources using ANY TCP/UDP protocol are allowed to reach ANY LAN or WAN destination unless otherwise specifically denied. The argument for that is it allows your internal services to function and allow your traffic OUT unhindered while still keeping things from getting IN, which is true and is a common practice. However, it is abundantly clear that had we been using the more restrictive methodology of "Allow Only/Deny All" on our LAN just as is always the case for the WAN, we would have inherently been blocking outgoing traffic on the 8xxx and 9xxx ports this thing was using to contact its Command & Control servers and dump sites."
If you don't do any firewall egress filtering today, there are two basic directions you could go in:
- If you have a high appetite for security, block everything except ports you really need and filter all web traffic through a proxy. However, this approach requires you to know which ports are required by your business, and which ones show traffic but are not necessary. The risk of getting it wrong is relatively high, so you need to do a lot of upfront work talking to the business owners of all internal applications to map out which ports are required from which systems.
- The easier route is to allow everything but block certain ports and ranges that are most likely to expose your network. For example, just blocking IRC and NetBIOS/SMB traffic can save quite a bit of future pain.
The Firewall Egress FAQ from SANS is a great paper to help you with your journey. In a nutshell, here is the minimum level of traffic you should be filtering:
- MS RPC (TCP & UDP 135)
- NetBIOS/IP (TCP 139 & UDP 137)
- SMB/IP (TCP 445)
- Trivial File Transfer Protocol - TFTP (UDP 69)
- Syslog (UDP 514)
- Simple Network Management Protocol – SNMP (UDP 161-162)
- SMTP from all IP's but our mail server (TCP 25)
- Internet Relay Chat – IRC (TCP 6660-6669)
- ICMP Echo-Replies (type 0 code 0)*
- ICMP Host Unreachables (type 3 code 1)*
- ICMP Time Exceeded in Transit (type 11 code 0)*
*Some folks will argue that blocking ICMP breaks with RFC 1812 and is generally anti-social, but it can be a good idea security-wise. Feel free to comment below if you have a point of view on this.
There is an easy way to test whether these ports are blocked on your firewall: The latest version of Metasploit Pro includes a Firewall Egress Testing MetaModule that contacts an external server on any TCP ports you specify and provides you with a report of open, filtered, and closed ports. It's so easy to use that it doesn't really require an explanation - here's a screenshot of the interface: