Firewall Best Practices - Egress Traffic Filtering
David M. Piscitello, Core Competence, Inc.
Originally published in the ISSA Journal, February 2003,
with Nathan Buff, Watchguard Technologies
Altogether too many firewalls and access routers implement lax egress (outgoing) traffic handling policies: in plain speak, they allow hosts access to virtually any services outside their firewall without considering the consequences. Generally speaking, organizations should be as concerned with the origins and kinds of Internet-directed traffic as they are with incoming requests. In this column, we discuss ways organizations can improve their risk profile and be better 'netizens by implementing egress traffic filtering.
Why Bother?
Too many Network Security professionals think only from the outside in when assaying security treats and configuring their company's firewall(s). Companies large and small would be well served if network administrators were just as concerned with what can happen with outbound connections. Like protective parents trembling while their small child makes her first solo trip to the corner store, the person responsible for network security should be very worried when any internet-enabled device behind the firewall can make outbound connections anywhere, or broadcast information everywhere.
Without proper egress traffic filters, your organization can't detect outbound IP spoofing: every source address will be considered valid. If you don't restrict the kinds of services that can be accessed by hosts in your trusted networks, you are leaving the door open for remote administration tools (root kits) attackers install on compromised hosts within your trusted network to "call home" or attack other networks, host chat rooms, or host pornographic or illegal material. If you have multiple access points to the Internet, your organization can inadvertently behave as a transit (carrier) network for traffic from other organizations (or be directed to do so by malicious code).
With lax egress enforcement, your company can be victimized when internal hosts transmit out sensitive information. If policies aren't in place or not enforced, this could happen intentionally, like the disgruntled soon-to-be ex-employee FTPing or emailing out all of next year's marketing proposals and sales projections to the competition; or unintentionally, as with NetBIOS broadcasts that can be sniffed for internal host names, browse lists and service advertisements. If compromised, Internet services you operate from servers on your trusted (including DMZ) networks - e-mail and DNS, for example - can be used to generate SPAM, propagate worms, and poison domain name databases. Employees can share copyrighted music and movies.
If your firewall provides outbound Network Address Translation, machines behind it that are infected with malware that causes them to send out gargantuan numbers of packets (such as the recent MS Blast/LoveSan/Nachi/Welchia outbreak) can cause the firewall's NAT ports to be exhausted if those packets are allowed to pass. At best, a moderate number of hosts infected with a virus like MS Blast or Nachi (or the next, more virulent strain) will cause denial of outbound services until the NAT pool is replenished - and soil your company's good name when a certain little corner of the Internet becomes flooded with your dirty laundry. At worst, it can bring down an otherwise robust firewall device that could have withstood the barrage had those packets been dropped instead.
Consult Your Policies
Motivated? Good. Begin by consulting your company's Security Policy and/or Acceptable Use Policy (AUP). If you don't have such policies, design them now.
Without clearly-defined notions of network security and a strict AUP you intend to enforce, your firewall's configuration will end up being little more than an ad hoc listing of outbound rules to meet users' perceived needs, instead of enforcing a company-mandated policy designed to protect the company's resources. Keep in mind your Ultimate Goal as the person or department responsible for your company's network security, or as the implementer of those security policies: protection and preservation of the company's resources and reputation.
Accept the fact that your firewall's configuration will be forced to deviate from a Perfect Egress Policy at times (often due to the desires of upper management, sometimes for lack of a better or more secure path to completing a critical project). Always weigh these requests against the Ultimate Goal, and make every effort to point out, in no uncertain terms, the security risks inherent in any alteration you are required to make to the firewall's egress policy. We should not need to point out to our audience the age-old conundrum of Security vs. Convenience, but it is this challenge that will be the primary driving force in all the following decisions.
Compose a list of the Internet-accessible services your organization will allow hosts on your trusted networks to access. For an organization that outsources email and DNS, this list might include DNS, POP/IMAP, SMTP, and of course HTTP/HTTPS.
If your organization supports services like email and DNS from its own servers, compose a list of these services and service hosts. List the Internet servers each must communicate with. If, for example, you run a split-DNS include any public servers your DNS server contacts for zone transfers, uses as forwarders, etc. If you run SMTP, include any mail servers with which you exchange mail directly (typically, your ISP's mail hosts).
The simple way to configure egress policies is to begin with a DENY ALL outbound policy, packet filter, or firewall rule. From this "nothing leaves my network without explicit permission" security posture, add rules to allow authorized users access to the services identified in your security policy and AUP as permissible. Add rules to allow administrators access to network and security systems outside your firewall. Lastly, add rules to allow servers you operate from your trusted network to communicate with Internet-hosted servers.
Let's examine each of these general policies in some detail.
Restrict Internet Access to Authorized Sources
In many firewalls, the default egress traffic policy for trusted networks is to allow any source address in outbound packets: literally, if the source address is syntactically correct, your firewall will forward it. This is overly permissive for any network, large or small. Prune it. List the IP subnet numbers or individual IP addresses of hosts that are authorized (trusted) to make use of externally hosted services.
Limit the addresses allowed to send traffic to Internet destinations by
configuring policies such as these:
 |
Only allow source addresses from the IP network numbers you assign to trusted segments behind your firewall(s), including DMZ networks. This includes primary and secondary network numbers, and subnets that are routed to the Internet through your firewall (including addresses reserved for VPN clients). |
|
Apply appropriate subnet masks to trusted networks, i.e., masks that are sufficiently long to identify only that fragment of the IP network number that you are using. For example, if you are using an RFC 1918 Private Address from the Class B number 172.16.0.0, and only assigning numbers from 172.16.1.x, use 255.255.255.0 (or /24), not 255.255.0.0 (or /16) as your subnet mask. |
|
Block broadcasts from traversing the firewall's interfaces. While most broadcasts will not pass across LAN segments, take measures to ensure this is especially true for Internet-bound packets - or packets destined for any untrusted segment. |
|
Prevent traffic from any RFC 1918 private addresses from being forwarded over your Internet access circuit. While ISPs block incoming traffic containing private addresses, you're forcing your ISP to process traffic you ought to block |
|
Block outbound traffic from VLAN workgroups or entire network segments that have no business establishing client connections to Internet servers. |
|
If you have internal servers that have no business establishing client connections to Internet servers, block all outbound traffic from such systems. An example might be an intranet server that relies entirely on internally provided services (DNS, mail, time, etc.) and uses no applications that require Internet access. |
Restrict Internet-Accessible Services (Destinations)
The default egress policy of many firewalls is to allow hosts on trusted networks to access any service (port) on Internet hosts. Under this policy, trusted hosts can attempt connections to any TCP/UDP port, from those with obvious business purposes, e.g., DNS, SMTP/POP, HTTP/HTTPS, FTP; to some with possible business purposes, e.g., AOL, NetMeeting; to some with questionable or suspicious purposes, e.g., IRC, finger, rlogin, peer-to-peer applications of the Napster ilk; to Truly Evil Services, e.g., Back Orifice.
Limit the destination ports on Internet-directed traffic in the following ways:
|
Allow outbound connections only to those services your security and acceptable use policies allow for client hosts. |
|
Wherever possible, only allow clients to access authorized services from authorized servers. If your employees use your ISP for email services, for example, limit outbound SMTP and POP connections to your ISP's POP and SMTP servers. |
|
Allow access to service ports your internal servers must use to operate correctly, and only allow your internal servers access to these services. If you operate your own mail servers, make certain that only these servers establish outbound SMTP connections. (If such measures had been practiced, the Sobig worm, which installed its own SMTP mailing engine, would not have spread so rapidly.) |
|
If you operate an HTTP proxy, or a proxy system that performs some form of web URL or content filtering, only allow outbound connections through your firewall from the proxy(ies). |
|
If you provide DNS internally, or use a split DNS, use internal servers as forwarders for your trusted network, and only allow outbound DNS requests from your DNS servers so configured. |
|
Unless your firewall is participating in routing, block routing protocols at your firewall. This is important for large enterprises with multiple firewalls and Internet access routers as well as small businesses with broadband connections that use a firewall to exchange and negotiate PPP over Ethernet (PPPoE). |
|
Allow any authorized services that make use of unique ports for remote desktop, subscription, licensing channels (e.g., GoToMyPC, BackWeb, Microsoft). Allow access to these services from hosts that are authorized to use them. |
|
Certain network and security vendors use unique ports for proprietary (and secure) management access. Permit these, but only from hosts used by the administrators of such equipment. |
|
Certain network and security vendors use unique ports for proprietary (and secure) management access. Permit these, but only from hosts used by the administrators of such equipment. |
Testing and Monitoring Egress Traffic Policies
Until recently, firewall configuration testing has been an acquired skill, effectively performed by firewall gurus, auditors and security professionals with this special expertise. Because many egress traffic-handling policies will be source address dependent, we believe you can achieve only a limited degree of confidence that your configuration satisfies your policies by logging intensely, running address and port scanning tools, and confirming that your allow/deny results are what you expect. Rigorous logging of denied outbound connections can help identify scofflaws that are either ignorant or defiant of your AUP, as well as provide early warning of infections. Where possible, cause potentially dangerous denied outbound packets to trigger notification for further investigation.
The emergence of tools like ftester (http://www.infis.univ.trieste.it/~lcars/ftester/) and firewalk (http://www.packetfactory.net/Projects/firewalk/), and commercial software (Firewall Informer, http/www.blade-software.com), offer evidence that, increasingly, organizations are looking for automated alternatives. We believe the development of configuration verification software is on the increase, because the market is large and the need rather obvious.
Conclusion
Configuring egress traffic policies is admittedly more time consuming than not. Your organization must assess whether the time invested and the improved risk profile you achieve when you take this initiative, to whatever degree you choose, is justified. We believe it is only a matter of time before regulatory compliance and fear of litigation will drive many organizations to choose to implement stringent egress traffic policies.