The Case For Outbound Filtering

We filter and block what comes into our networks, but often forget about what goes out. Attackers know this, and their attack plans even rely on it. Malware that has compromised an internal machine is often programmed to connect to a command-and-control system that resides outside the enterprise. And of course, attackers use outbound connections to transmit stolen data to their own repositories.

The problem for IT is that you can't simply shut off certain ports and protocols. For instance, HTTP and HTTPS outbound are required by most organizations. Instead of cutting off outgoing Web traffic, use a proxy or a Web filter that can inspect traffic for malicious payloads and kill outbound traffic based on domains. Other commonly unfiltered outbound services include SMTP, FTP, IRC, SSH/SCP and SMB.  All of these services are used in various attacks. Do yourself a favor and send these outbound connections through a proxy too, because if the attacker or malware is not configured to access the proxy, you've trumped them.

Another option is to block network services that your business doesn't require. Recently, I had a discussion with someone whose work PC was infected with a trojan. The trojan changed the PC's DNS settings, forcing the PC to use a pair of malicious DNS servers, so all traffic was routing through a third party. These DNS servers responded with the same sets of IP addresses for all websites requested, so that every transaction the user made was logged by a malicious host. If the company had filtered outbound DNS queries, this attack would not have worked and the company's data would not have been exposed.

Unfortunately, outbound filtering can be tricky, which is probably why many organizations don't bother to do it. One problem is that you don't always know which services your users or applications need. So start by logging one service at a time. Don't block the traffic, just log and see if anything or anyone uses the service for business purposes.  Chances are you'll see malware or other malicious activity. Let the logging run for a month and if no legitimate traffic appears, block the service.

You can also reverse the process: log all your traffic and to get a baseline of legitimate usage of common services. Then you can block everything else. However, this method may lead to mistakes. For instance, a business process may only use a service once per quarter, and if your baseline analysis missed that usage, you may end up getting an angry phone call from a line-of-business executive. That said, filtering outbound traffic is a practical, cost-effective control and a useful way to thwart attackers who rely on an unfettered outbound communications channel.