Firewall Egress Blocking and Monitoring

Firewalls. We all have them. We all know we use them to keep unwanted stuff out of our networks. One thing we sometimes don’t think about is to whom our systems inside the network are talking.

Why should we be concerned with what connections are being made from within our networks to the outside world? Data exfiltration, (malware and/or insider threats using VPN, TOR, etc.) using rogue DNS, botnets, DDOS attacks, SPAM generation, and so on, can occur from within your network, and can have significant consequences not only for you, but for others.

Let’s take DNS for example. A malware-compromised machine can be configured to use a rogue DNS server. At this point, it’s possible to facilitate fake banking sites, mail servers, serve ads, circumvent spam filters, and so on. By configuring your firewall's outbound rules to only allow DNS communication to: a) your ISP’s DNS servers, (or external DNS you otherwise control) or b) only allow your internal DNS server to forward requests to specific external DNS servers, you can mitigate this type of compromise.

Set Policy

Before embarking on the task to lock down egress traffic with your firewall, it’s important to understand what systems need to access which services on the Internet. Does your company have a policy around acceptable use? Does it include a policy for outbound connections? If the answer to either of those is no, then it’s important to first gather the stakeholders, and define the policies.

Getting consensus from stakeholders - be they the Compliance/Risk team, sysadmins, or business owners can be tricky; but having a defined policy is crucial to implementing a sustainable strategy.

Keep in mind that there will inevitably be exceptions to these policies, and it’s important to have a plan to deal with them, and assess the risks these exceptions introduce.

Determine which Internet accessible services are needed. Here are some basic ideas to get you started:

• End users typically will need ports 80 and 443 open, and not much else unless you have IMAP/POP/SMTP services that are hosted outside.
• Are there servers on your internal network that host DNS, mail, NTP, Intranet, and so on? Internal servers like domain controllers and file servers typically only need access to update servers (if you aren’t hosting them internally) and DNS.
• Block IP spoofing; ensure only your internal networks and subnets are allowed out as source addresses. Be specific; only allow those networks you actually have.
• Get rid of that any/any rule on your firewall

Monitor that Firewall!

Having a tool like AlienVault Unified Security Management (USM) ingesting logs from the firewall, and monitoring ingress/egress traffic is a strong additional layer to add to your risk mitigation strategies. IP reputation and Open Threat Exchange (OTX) indicators of compromise will help identify weaknesses in your rule sets, and aid you in further improving your security posture. As this thread on Spiceworks demonstrates, practitioners struggle with monitoring of firewall logs without a platform like USM.

Here are some screen shots of using USM to monitor a firewall.