Firewall Best Practices - Egress Traffic Filtering Too many network administrators think only to protect private network resources from external attacks when assessing security threats. Todays landscape is littered with threats that emanate from malware-infected endpoints. Attackers can use these to collect and forward sensitive information from your network, to attack or spam other networks. Companies large and small are better served when network administrators are equally concerned with threats that are associated with outbound connections. In this column, I discuss ways organizations can improve their risk profile and be better netizens by implementing egress traffic filtering. Filter Egress Traffic to Protect Yourself If you dont restrict the services that hosts in your internal networks can access, malware that will inevitably find its way onto some of your hosts may exfiltrate data to a location that an attacker controls. Data exfiltration could be unintentional, i.e., an insider might incorrectly attach sensitive information an email message to upload it to a document sharing service. Exfiltration can result from configuration error: NetBIOS, DNS, or other service traffic that leaks from your trusted networks may be captured or exploited by external parties. Exfiltration can also be malicious, the result of hosts having been infected with an advanced persistent threat (APT). Irrespective of the cause, data exfiltration is a threat you can’t mitigate without egress traffic enforcement, and one you can’t readily detect if you dont log and monitor traffic behavior associated with permitted and prohibited services. Filter Egress Traffic to Do No Harm to Others In the most lax of configurations – and sadly, in many default configurations - a firewall or router may treat as valid and forward traffic it receives from any source address. Fred Avolio calls this “The Nefarious Any”. Such configurations are green fields for attacks that leverage forged source IP addresses (IP spoofing). Compromised or unauthorized hosts that gain access to your local networks often use IP spoofing to attack (DDoS) other networks, to store child abuseor other illegal material, or to conduct spam or phishing campaigns. This is problem enough in NAT environments: in poorly implemented router configurations, especially where you have multiple access points to the Internet, your organization can inadvertently behave as a transit network for forged, malicious traffic emanating from other organizations. Compromised or unauthorized systems can play roles in criminal activities without the use of spoofed addresses. A compromised server or user device on any of your internal networks (trusted, DMZ, guest) can be used to generate spam, host malware or phishing sites. A compromised DNS name server can host zone data for a malicious domain. Improperly configured, your DNS resolver – or possibly any UDP-based service you use (chargen, NTP) - can support a criminal conspiracy! Just as egress traffic filtering can help mitigate data exfiltration from your networked assets, so can it help you protect the world from your network. Step #1: Egress Traffic Enforcement Policy Motivated? Good. Begin by consulting your companys Security Policy and/or Acceptable Use Policy (AUP). If you dont have such policies, gather stakeholders and define them. Include as stakeholders individuals who are not only responsible for implementing your companys network security but also those individuals who are party to risk management and mitigation. Without clearly-defined notions of network security and a strict application and traffic policy you intend to enforce, your firewall configuration will end up being little more than an ad hoc and troublesome listing of outbound rules to meet users perceived needs, instead of a well conceived policy designed to protect the companys resources. 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, NTP, and HTTP/HTTPS. Think, too, about malicious destinations - botnet C&Cs, hijacked address space, notorious (bad) hosting providers - and how you might block these. If your organization supports services like email and DNS from its own servers, compose a list of these services and service hosts (domain names and IP addresses). List any Internet servers these must communicate with. If, for example, you run a split-DNS then include any public servers your DNS server contacts for zone transfers, uses as resolvers, etc. If you run SMTP, include any mail servers with which you exchange mail directly (typically, your ISPs mail hosts). If you intend to implement content exit control at a proxy or firewall, enumerate the types of content you will permit or deny. You many also find it necessary to identify permission sets for user groups if your content exit control is not a one glove fits all policy. Accept the fact that your firewall configuration will deviate from the ideal enforcement policy you develop following this exercise. Such deviations or exceptions may be necessary to accommodate senior management, business relationships, or sometimes for lack of a better or more secure path to completing a critical project. Assess the risk of each deviation, call attention to the security risks inherent in any alteration you are required to make to the firewalls egress policy, and consider how you might compensate by implementing a complementary security measure. Step #2: Kill the Nefarious ANY The best way to configure egress traffic filtering 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 access to the services identified in your egress traffic enforcement policy. Add (granular, restrictive) 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. Lets 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: Block IP spoofing. Only allow source addresses from the IP network numbers you assign to internal networks to pass through your firewall (trusted, DMZ, guest). This includes primary and secondary network numbers, and subnets that are routed to the Internet through your firewall (including addresses reserved for VPN clients). Only allow traffic from address space you actually use. Apply appropriate subnet masks to internal 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 172.16.0.0 and only assigning numbers from 172.16.1.x, use 255.255.255.0 (or /24) and not 255.255.0.0 (or /16) as your subnet mask. (Same rule applies for RFC 4913 Private addresses for IPv6. Block traffic from any RFC 1918 or RFC 4913 private addresses from being forwarded over your Internet access circuit. Many ISPs block incoming traffic containing private addresses but youre forcing your ISP to process traffic you ought to block. Block outbound traffic from VLAN workgroups or entire network segments that has no business establishing client connections to Internet servers. Block broadcast traffic. Most Internet-facing firewalls operate in routed mode where broadcasts will not pass across LAN segments. Understand the implications(limitations?) of using transparent (layer 2) firewalls in Internet firewall deployments. Block all outbound traffic from internal servers that have no business establishing client connections to destinations outside your trusted networks. An example might be an intranet server that relies entirely on internally provided services (DNS, mail, time, etc.) and by design uses no applications that require Internet access. Block outbound traffic with destinations that are listed on DROP (Don’t router or peer) or BGP filter lists. Spamhaus, for example, maintains lists of networks that have been hijacked by spammers, phishers, botnet C&C’s and other malicious traffickers. Data centers, universities, and large end user networks especially benefit from this kind of filtering when their ISPs do not implement them. Restrict Internet-Accessible Services (Destinations) The Nefarious ANY appears again in the default egress traffic policy of firewalls that allow hosts on internal networks to access any service (port) on Internet hosts if forwarding to the destination is permitted. Limit the destination ports on Internet-directed traffic in the following ways: Allow outbound connections only to those services your egress traffic enforcement policy allows for client hosts. Wherever possible, only allow client hosts to access authorized services from authorized external servers. If your employees use your ISP for email services, for example, limit outbound SMTP and POP connections to your ISPs POP and SMTP servers. Only allow client hosts to send DNS queries to resolvers you manage or responsibly managed open resolvers. Open resolvers are routinely exploited in DDoS attacks:harden your resolvers and dont use others that operate open badly. For inter-server communications involving external servers, only 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 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 resolvers as forwarders for your internal networks. If you make use of a private namespace that is not delegated from the public DNS, consider measures to prevent private name space queries from leaking into the public DNS (hard) or use a FQDN (fully qualified domain) for your private name space. Dont leak topology information. 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 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. Testing and Monitoring Egress Traffic Policies Firewall configuration testing remains an acquired skill, effectively performed by firewall experts, auditors or security professionals with this special expertise. Because many egress traffic-handling policies will be source address dependent, you can achieve some 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 could 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. Consider, too, tools like ftester (now deprecated but still available), NMAP, Nessus, or some of the commercial software listed at Security Wizardry if you are looking for automated alternatives. Conclusion- When I first wrote this article with Nathan Buff in 2003 we concluded that configuring egress traffic policies is admittedly more time consuming than not, and that your organization should rightly assess whether the time invested and the improved risk profile you achieve when you take this initiative is justified. This was perhaps too soft a sell. Events throughout the past 18 months (2013-2014) bear evidence that motives to exfiltrate data will only increase. I now believe that governments and private organizations are near the tipping point and no longer willing to passively accept the current threat condition but now actively investigating ways to mitigate harm resulting from the lax security practices of others. It may only be a small matter of time before regulatory compliance or fear of being held contributory to a criminal act or liable for financial loss will drive many organizations to choose to implement stringent egress traffic policies.
Posted on: Sat, 20 Dec 2014 14:59:01 +0000
Trending Topics
Recently Viewed Topics
© 2015