This week, we’re discussing outbound traffic filtering. This is filtering provided at the network edge by a firewall with rules (ACLs) restricting what internal users are allowed to access. Some firewalls have the ability to filter by an application (layer 7 firewalls), but we’re going to concentrate on standard packet-filtering firewalls and their capabilities. There are several reasons for wanting to restrict outbound communications, such as defeating malware, making data exfiltration harder, and the detection of infected hosts.
What Traffic Should Be Blocked Outbound?
When someone decides to implement outbound filtering, usually the first question they ask is, “What ports should I block?” The answer is simple: Whatever ports are necessary. If you only need HTTP, HTTPS, and DNS traffic outbound, then that’s your answer. If you have internal mail servers, you’ll need to open up SMTP ports. The point is, it depends on the requirements of your environment. For simplicity’s sake, I’ve listed out some commonly blocked ports below that you would use if following a blacklist approach:
- Microsoft RPC (TCP/UDP 135)
- NetBIOS (TCP/UDP 137-139)
- SMB (TCP 445)
- TFTP (UDP 69)
- Syslog (UDP 514)
- SNMP (UDP 161-162)
- Telnet (TCP 23)
- SSH/SCP (TCP 22)
- DNS (TCP/UDP 53), except from internal DNS servers
- SMTP (TCP 25), except from internal mail servers
- Ephemeral ports (TCP/UDP) 1024-65535
Instead of denying a bunch of ports, try a whitelisting approach, which blocks all outbound ports and only permits those you approve, such as HTTP, HTTPS, and DNS (from an internal DNS server). We discuss whitelist and blacklist approaches in the CompTIA CySA+ course here at Linux Academy.
Now, let’s dig into the main reasons why we want to restrict outbound communications.
Most malware these days is known as command and control (CNC) malware. Once it’s installed, the malware will phone home to a control server and check in. The malware will continue checking in periodically, waiting to receive a command to do something. The CNC malware is coded with a destination address and port where the controller server can be reached. Oftentimes, the port used is an ephemeral port (1024-65535). If we are blocking these ports outbound, the malware can never contact its control server; therefore, it’s rendered useless.
Ransomware generally works the same way — phoning home to send information about the host it’s infected and receive encryption keys necessary for encrypting files on the target. Yes, it’s true that some malware uses common ports such as 80 and 443 to communicate over, but not all ransomware does. If we can stop 20% of the ransomware with outbound filtering, it’s worth it.
Make Data Exfiltration Harder
Another benefit of outbound filtering is to make data exfiltration harder. If an attacker gains access to your infrastructure, they may feel the need to exfiltrate data. The easiest way to do this is via some type of shell, like Meterpreter. The outbound communications from a Meterpreter session will use ephemeral ports. Another easy way is via FTP or SCP (both of which we mentioned above, as far as blocking their ports). If you’re not familiar with Meterpreter, take a look at this CompTIA Pentest+ course to see how to use it in a penetration test.
In the port list above, you’ll see DNS is listed with the note, “except from internal DNS server.” This is because DNS has become a favorite of data exfiltrators via a technique called DNS tunneling. This is where data is tunneled over DNS. Since DNS is so important, many networks don’t prevent DNS outbound, and attackers know this. We definitely should be blocking outbound DNS from our network for all internal hosts, except our internal DNS servers that require DNS to be open so they can perform recursive queries. No, we cannot completely prevent data exfiltration, but we can make it harder.
Prevent Nefarious Activities
Nefarious activities are those we don’t want happening and that can cause us headaches. One of those nefarious activities is SMTP relay. You could have an infected host sending out spam emails or being used as a bot in a DDoS attack, and outbound filtering can help prevent this activity. I’m sure many of us have dealt with our IP addresses getting blacklisted because of these types of activities. When this happens, it takes away our valuable time in order to get our IP addresses removed from these blacklists.
Review Your Firewall Logs to Find Infections
Now that outbound filtering is enabled, we can review firewall logs for blocked outbound traffic. This can quickly identify internal systems attempting to communicate on odd ports. These systems need to be checked for malware or misconfigurations. So not only can outbound filtering help protect us, but it can also help us identify active infections not identified by other controls, such as anti-virus or anti-malware.
Wrapping Up Outbound Filtering
In the end, outbound filtering is not a silver bullet, but, then again, nothing in security is. Remember: We address security with a layered approach. Each layer we add makes us more resilient to attacks. Think of it like a bulletproof vest: A single layer of Kevlar will not stop a bullet, but when you have 20 layers, the vest will stop a bullet. That’s how we need to approach security — layer by layer.
As you’re securing your infrastructure, don’t forget to have an incident response plan. Use vulnerability scanning to see what vulnerabilities are in your infrastructure, and keep in mind the importance of data backups, as well as passwords and policies such as using MFA and proactively identifying compromised passwords.