How to properly implement firewall egress filtering

Deploying outbound rules on a firewall can be a tricky task; if not done properly, it can lead to business interruptions. Scott Floyd reviews best practices for avoiding mistakes when blocking outbound network traffic.

Deploying egress firewall traffic filtering is sometimes easier said than done. Deployment may seem simple: Implement an access control list (ACL) on a firewall to block all outbound traffic, then only allow traffic that is approved by the company's security policy.

But if implementing egress firewall traffic filtering is so easy, then why do so few companies do it? The answer usually involves not knowing which applications or services will break when blocking outbound traffic to the Internet.

In this tip, let's review how to implement firewall egress filtering on the perimeter firewall while minimizing any business interruptions or common mistakes.

Planning for egress firewall traffic filtering

Before starting the project, we will make a few assumptions. First, let's assume all firewall changes are in line with corporate security policy. Second, we need to assume that our starting point is a default configuration, which allows traffic originating from the trusted network (inside interface) out to the Internet unrestricted. Lastly, it's a given that all configuration changes should be tested before applying them in the production environment.

All firewall configuration references will be based on a Cisco Systems Inc. ASA version 8.2(1) multipurpose security appliance (which, of course, includes firewall functionality). While it goes without saying, we'll say it anyway: Specific configuration details will differ from one device to the next. We will also use Splunk, an IT search and analysis engine that collects and indexes all logs from the firewall so they can be easily analyzed. Splunk offers a free version of its product for 60 days. After 60 days, Splunk will only index 500 MB of raw logs daily. The trial version, though, will easily meet our requirements.

IT pros struggle with corporate firewall rules

Learn how firewall management tools can ease the burden of changing firewall rules.

By default, the Cisco ASA has two implicit ACL rules for the inside interface of the firewall. The first rule permits all outgoing traffic to less-secure networks, and the second rule blocks all outgoing traffic. Rules are applied from the top down, meaning the first rule allows all traffic out, and the second rule is never actually applied After a rule is applied to an inside interface, the first implicit rule will disappear, causing administrator problems and blocking traffic. This default configuration allows any hosts behind the inside interface unfiltered access to the Internet. In this example, the ACL "inside_access_in" will be applied to the inside interface of the firewall, essentially enabling inside access to the Internet:

access-group inside_access_in in interface inside

Logging

Next, install Splunk. Splunk can be deployed on a laptop, workstation or dedicated server. Once Splunk is installed, configure a "data input," which allows Splunk to serve as a syslog server listening on UDP port 514 so it can receive log data input from the firewall. Next, using the example below, configure the firewall to send syslog messages to Splunk. The example assumes no logging is currently enabled.

logging enabled
logging timestamp
logging trap Informational
logging host inside 192.168.10.10

[*192.168.10.10 is an example IP address for Splunk. The admin can use any IP address for the Splunk server that is reachable from the inside interface of the firewall.]

After the initial setup, verify that you see events being indexed by the tool. Depending on how busy your firewall is, you may have to use a logging filter to reduce the number of events being sent to Splunk. .

Firewall configuration

To monitor and implement firewall egress filtering, we need to set up a network object and three service objects that will be used in the firewall rules. Object groups allow collections of IP hosts, networks and protocols, and each IP address in a network object group is considered a member of that group.

Let's look at the example below:

object-group network egress_allow_networks
description Allowed egress networks
network-object host 10.10.10.100
object-group service egress_allow_ports
description Allowed egress ports
service-object tcp eq http
service-object tcp eq https
object-group service egress_block_ports
description Blocked egress ports
service-object tcp-udp range 65534 65535 object-group service egress_monitor_ports
description Monitor egress ports
service-object tcp-udp range 50000 65533

To create object groups, a member has to be added. Here in the example, we added the TCP/UDP port range 65534 – 65535 to the blocked egress ports group. Blocking these ports outbound by default should be pretty safe. I also added the IP 10.10.10.100 as an example of an allowed egress destination network.

Then, let's set up five rules using the object groups just created, which will be applied in the following order (remember firewall rules are applied from the top down).

Allow network

This rule will allow all traffic and any known Internet connectivity to specific network destinations, which could include business partners. The rule is an open one and can be tightened down in the future if needed:

access-list inside_access_in extended permit ip any object-group
egress_allow_networks log 6 interval 300

Allow service

This rule will be used for network services we know to be allowed out to the Internet. Common services include HTTP and HTTPS. Best practice would be to add your proxy server as the only source for this rule; however, in this example we will allow "any" as the source:

access-list inside_access_in extended permit object-group egress_allowed_ports any
any log 6 interval 300

If you wanted to only allow your proxy server, using an example IP address for proxy server 192.168.10.20, outbound, you would use this rule:

object-group egress_allowed_ports host 192.168.10.20 any log 6 interval
300

Monitor service

This rule will monitor and identify what services we can safely block:

access-list inside_access_in extended permit object-group egress_monitor_ports any
any log 6 interval 300

Block service

This rule will enable outbound traffic filtering and, in turn, enforce your corporate security policy. The rule uses the "egress_block_ports" object group to block outbound traffic by protocol, and it is also critical to ongoing monitoring: 

access-list inside_access_in extended deny object-group
egress_block_ports any any log 6 interval 300

Allow all

An important step is to create a rule that allows all outbound traffic. Once we add a rule, the first implicit rule that permits all traffic to less secure networks goes away and the second implicit rule will deny all other traffic:

access-list inside_access_in extended permit ip any any

Verify all rules

ciscoasa# show run access-list inside_access_in
access-list inside_access_in extended permit ip any object-group egress_allow_networks log informational
access-list inside_access_in extended permit object-group egress_allowed_ports any any log informational
access-list inside_access_in extended permit object-group egress_monitor_ports any any log informational
access-list inside_access_in extended deny object-group egress_block_ports any any log informational
access-list inside_access_in extended permit ip any any

You should see syslog messages associated with these rules showing up in Splunk. Each firewall rule has a unique hex identifier, which will make it easier to search for. We will focus on the "Monitor service" rule. To find the unique identifier for this rule, use this firewall command:

ciscoasa# show access-list inside_access_in | include egress_monitor_ports
access-list inside_access_in extended permit object-group egress_monitor_ports any any log informational
0x221e3425

Using Splunk, search for the hexadecimal number 0x221e3425. The search results will show you any hits on this specific rule.

Implementation

Monitor the hits on the "monitor service" rule using the hexadecimal number 0x221e3425. The results from Splunk should include any outbound traffic on TCP/UDP ports 50000 through 65533. If it's determined that there is no approved egress traffic in this port range, change the object-group "egress_blocked_ports" from 65534 through 65535 to 50000 through 65535. Also change the object-group "egress_monitor_ports" to the next range of ports that you want to monitor. Example: TCP/UDP 30000 through 49999. Continue this process, working your way from the high network ports to the low. When an allowable destination network is identified, add the network to the "egress_allowed_networks" object group. Also add any allowed network ports to the "egress_allowed_ports" object group. When all ports have been monitored, the "Allow all" rule should not have any hits and can be disabled. As a safety measure, move the "Allow all" rule to the top of the rules list and enable it in case of emergency. You should also be able to disable and remove your "Monitor service" rule. Continue to monitor the "Block service" rule as well. Any hits on this rule can help identify infected machines on your network, data leakage and misconfigured network devices.

Next Steps

Learn how to use firewall logs to decipher valid traffic from threats

Check out this firewall learning guide

This was first published in February 2010
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Related Discussions

Scott Floyd, Contributor asks:

What issues has your enterprise run into when implementing firewall egress filtering and how has it overcome them?

0  Responses So Far

Join the Discussion

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close