Egress Filtering 101: What it is and how to do it Egress Filtering 101: What it is and how to do it

Egress Filtering 101: What it is and how to do it

by Calyptix, October 16, 2015

egress-filteringThe firewall is an essential part of your network security, but only if it’s configured properly. One area people often overlook and misconfigure is the egress filter.

Egress filtering controls the traffic that is attempting to leave the network. Before an outbound connection is allowed, it has to pass the filter’s rules (i.e. policies). These rules are set by the administrator.

Almost every UTM firewall provides egress filtering (also known as outbound filtering). However, it is never enabled by default. The out-of-the-box setup typically allows any machine on the network to connect to any host over any port.

Since it is disabled by default, many small and medium-size organizations never use egress filtering. But if you are serious about security, then it’s an absolute must.

Why should I use egress filtering?

Egress filtering is essential. It prevents outbound connections to dangerous and unwanted hosts. It won’t solve all of your security needs, but there are many reasons to use it:

Disrupt malware

If a machine on your network is infected with malware, then an egress filter can prevent it from connecting to the malware’s command server. And if the malware tries to export the machine’s data, then the egress filter can prevent it from connecting to the destination.

Block unwanted services

Let’s say users are not allowed to browse the internet or chat with friends on Skype. An egress filter can block the ports and protocols used for these services so users cannot access them. It can also limit the block to only certain source IPs or IP ranges.

Stop contributing to attacks

Egress filtering is also good for the greater community. By blocking certain types of traffic, it prevents your machines from being used for DDoS attacks, malware hosting, spamming, and botnets.

Greater awareness of network traffic

Using an egress filter will make you more aware of the unauthorized activity on the network.

For example, the filter in AccessEnforcer will provide you with valuable logging information under Network Alerts. If a machine attempts to make unauthorized connections, then alerts will be shown in the logs, and you will know to follow-up to find the cause.

Where to use an egress filter

The best place to deploy egress filtering is on the edge of the network. This is typically where a UTM firewall like AccessEnorcer is placed, which makes it the perfect choice for the task.

Everything on the network must pass through the firewall to leave. The only hardware beyond the filter is the modem.

egress-filtering-whack-a-moleHow to configure egress filtering

There are two approaches to egress filtering: default-allow and default-deny.

Default allow policy

This is the easiest type of egress filter to deploy. All outbound traffic is permitted unless a policy states that it is not allowed.

This approach can feel like playing network whack-a-mole. The admin has to allow all traffic and find the bad traffic and stamp it out.

In general, policies are created to block traffic that uses protocols and destination ports that are unnecessary or often abused.

For example, the SANS Institute recommends blocking outbound traffic that uses the following ports:

  • MS RPC – TCP & UDP port 135
  • NetBIOS/IP – TCP & UDP ports 137-139
  • SMB/IP – TCP port 445
  • Trivial File Transfer Protocol (TFTP) – UDP port 69
  • Syslog – UDP port 514
  • Simple Network Management Protocol (SNMP) – UDP ports 161-162
  • Internet Relay Chat (IRC) – TCP ports 6660-6669

This list is only a starting point. There are many moles left to whack. For example, if the organization does not need FTP, then then TCP port 21 can also be blocked.

Egress policies can also prevent specific source IPs from making outbound connections. This can be useful for locking-down terminals that are used for payment processing and have to comply with PCI DSS.

needle-in-haystack-networkDefault deny policy

A default-deny egress filter is typically more secure (assuming it’s configured properly). It blocks all types of outbound traffic unless a policy states that it is allowed.

Many small organizations unfortunately do not use default-deny, even though it’s in the best interest of their security. This is because default-deny can be disruptive.

With default-deny, every application that uses the internet – such as email, IM, and web browsers – must have a policy that allows it to pass traffic. The problem is that most small organizations do not know the full scope of systems and applications they use, so they do not know which types of traffic to pass.

Network administrators know they will need policies to pass common types of traffic, such as:

  • HTTP – TCP port 80
  • HTTPS – TCP port 443
  • DNS – UDP port 53
  • SMTP – TCP port 25
  • NTP – UDP port 123
  • FTP – TCP port 21

But there are many other types of outbound traffic that the business needs to function normally – and most admins do not know them offhand.

Instead of network whack-a-mole, they have to look for needles in the network haystack. Often times they will:

  1. Put the default-deny egress filter in place
  2. See what applications stop working
  3. Review network logs to uncover the associated traffic
  4. Create a new policy to allow the traffic

Also, if a new application is deployed on a machine, the admin will likely have to create a new egress filter policy to grant it access to the internet.

Many organizations do not want the headache of putting default-deny in place, so use default-allow even though it is less secure.

Default-deny filtering by IP address

With default-deny, you can also allow specific IP addresses and ranges to make outbound connections, and you can control the services they are allowed to use.

For example, if only one machine on the network needs to browse websites, than you can create a policy to allow only that IP address to pass HTTP and HTTPS traffic (TCP ports 80 and 443).

More good ideas:

  • Limit outbound traffic to sources that are within your networks’ IP subnet. This can help prevent IP-spoofing attacks.
  • If you use a third-party email service, limit SMTP and POP connections to the third-party’s servers.
  • If you use an internal email server, allow only this server to make outbound SMTP connection
  • Limit DNS queries to DNS servers that are known and trusted

This can be an excellent opportunity for a proxy server to further secure the network. The proxy can be set as the only allowed source of outbound traffic. Services can be limited to select protocols such as HTTP, HTTPS, and DNS. Then all work stations can be set to only connect with the proxy.

That way, should a machine be infected, it will not be able to connect directly with the internet.

Balance of security and convenience

The process of identifying and allowing legitimate traffic is more than some companies wish to bear. Like everything in security, this is a balance of convenience and security. A default-allow policy may be less likely to interrupt normal business operations, but it’s also less secure.

Effective egress filtering is not easy to implement, but it is worth the effort. And it may become more common in the future. For example, PCI DSS requires it, and other industry regulations may follow suit.

Egress filtering, and even default-deny, are in the best interest of the organization’s security, even if they are inconvenient at times.

https-web-filter-overview-CTA

Related resources

SANS Institute: Egress Filtering FAQ

SANS Institute: Performing egress filtering

DDoS Attacks: Trends show a stronger threat in 2015

Top Threats: Massive denial-of-service attacks

PCI DSS for IT Providers: See how the rules apply to your business.

No Comments


    Leave a Reply

    Your email address will not be published Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *