Tip

How to properly implement firewall egress filtering

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.

    Requires Free Membership to View

IT pros struggle with corporate firewall rules

Changing firewall rules could result in disrupting business communications or opening a hole for unauthorized traffic. Learn how firewall management tools ease the burden.
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.

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

Don't miss need-to-know info!

Security pros can't afford to be the last to know. Sign up for email updates from SearchSecurity.com and you'll never be behind the curve!
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.

This was first published in February 2010

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

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:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.