When considering best practices in egress filtering, it is important to remember that egress filtering is not focused on protecting your network, but rather on protecting other organizations' networks. For example, the May 2017 Wannacry Ransomware attack is believed to have exploited an exposed vulnerability in the server message block (SMB) protocol and was rapidly spread via communications over port 445. Egress and ingress filtering of port 445 would have helped limit the spread of Wannacry. In this post--a companion piece to Best Practices for Network Border Protection, which highlighted best practices for filtering inbound traffic--I explore best practices and considerations for egress filtering.

Egress filtering can be a time-consuming practice with few immediate incentives; however, when executed, this practice might have mitigated damage in a number of malicious incidents. The 2016 Dyn attack involved infected devices sending large amounts of traffic over port 53 (DNS) to target Dyn's infrastructure. If your organization has its own DNS servers for use by internal clients, there should be no reason to allow all internal devices to send outbound traffic over port 53. This simple practice might limit the impact of similar attacks.

It is important to understand the egress filtering information flow. At a very high level, outbound traffic on a system can be considered at two levels:

• Application Layer. Filtering here targets communication to specific websites, including various social media applications (i.e., Facebook and Twitter).
• Transport Layer. Egress filtering, as discussed in this blog post, focuses on the types of protocols that you will allow outbound from your network at the network and transport layers of the OSI model.

Note that, similar to our best practices in network border security, these recommendations are geared toward large organizations and government agencies and would not likely be appropriate for a home network.

Here are some things to think about as you consider implementing egress filtering:

• Usability vs. security. When trying to decide what to filter, it is important to understand that you will always be making a tradeoff between security and functionality and convenience for your users. Locking down your system more tightly may improve security, but you may be filtering services that users want--not just must-have services that their jobs depend on, but also conveniences that may fall into a gray area.
  
  On the other hand, allowing users access to certain services may create risks. For example, allowing users to access public DNS resolvers, like those run by Google, could allow an external party to track your users' DNS queries. Allowing your users the ability to run certain network diagnostics to the Internet from their desktops, like ping or traceroute, could expose an organization to risks as well; the inbound ICMP reply and time-exceeded packets can be used for network mapping and for DDoS, among other things. ICMP can also be used to exfiltrate data from your network, disguising sensitive information as uninteresting control traffic.
  
  
• Default permit or default deny? When configuring egress filtering, your security stance can either permit everything outbound by default and choose to deny specific outbound traffic, or it can deny everything by default and choose specific inbound traffic to permit.
  
  Default deny is the more secure posture, but requires you to know about all the flow of information that needs to leave your network so you can choose what traffic to permit.
  
  Default permit is the easier option to implement, but it can allow all sorts of unknown traffic to leave your network, which could lead to problems. When setting up a brand new network, it is more feasible to start with a default deny policy because it allows you to permit new outbound applications as needed. If you're imposing default deny egress filtering to an existing network, you run the risk of breaking needed applications you didn't know about.

Best Practices for Egress Filtering

The following best practices for egress filtering are based on our experience helping enterprise organizations, both in the government and industrial sector, as well as on our understanding of network design, Internet operations, and the threat landscape.

• Deploy anti-spoofing filters. Distributed denial of service (DDoS) attacks often rely on sending packets with IP addresses that appear to originate from fraudulent sources, a practice known as spoofing.
  
  Anti-spoofing filters, which prevent the outbound flow of traffic with forged source addresses from a network, help prevent the spread of deliberate malicious activity by users or malicious activity caused by infections, botnets, and other malware.
  
  When applying filters, it is important to only allow outbound packets sourced from a block of IP addresses that belong to your network. It is also important to ensure that you are only permitting traffic sourced from your registered (Internet-routable) IP addresses.
  
  Don't accidentally leak traffic to the Internet that has been sourced from a private, request for comments (RFC) 1918 IP address, such as the 10.x.x.x block. Such leakage will contribute to the amount of junk traffic on the Internet, and smart network operators will block traffic from RFC 1918 addresses.
  
  
• Filter internal-only services. Certain services don't typically need to run across the Internet and are usually reserved for internal networks. Some of those services can be associated with vulnerabilities, malicious activity, or with the leaking of sensitive data.
  
  The decision to block these services must be made with knowledge of your network's requirements. If you need one of these services to run outbound to an external partner or vendor (such as your cloud service provider), you should filter the traffic to permit the service only to that partner's IP addresses.
  
  Examples of services that should be blocked from leaving your network include:

• • MS RPC (TCP/UDP 135)
  • NetBIOS (TCP/UDP 137-139)
  • SMB (TCP 445)
  • TFTP (UDP 69)
  • Syslog (UDP 514)
  • SNMP (UDP 161-162)

• Filter services that are often associated with malicious activity. Consider blocking services outbound known to be used for malicious purposes rather than for business purposes. For example, consider blocking IRC (typically TCP 6660-6669), which is frequently used as a channel for compromised systems to speak to a command-and-control server.

• Filter services that should be restricted to a small number of known hosts. While certain services are critical to an organization's operation, they only need to be run from a small number of known hosts. You can filter outbound to allow only those known hosts to communicate over certain ports. This practice can prevent data exfiltration (e.g., users transmitting sensitive data disguised as DNS traffic), or users running unauthorized servers (e.g., a user running their own mail server, bypassing the security controls and filtering executed on the organization's mail server). Additionally, if you have an outbound proxy for web traffic, you might want to filter to allow only that proxy to communicate over normal web ports. Specific services to consider limiting outbound from known source IP addresses include the following:
  
  
  • DNS (TCP/UDP 53)
  • SMTP (TCP 25)
  • HTTP/S (TCP 80, 443)

Wrapping Up and Looking Ahead

Egress filtering continues to be a challenge for the Internet community. Few incentives exist for implementing best practices beyond the satisfaction of knowing that your organization has prevented the spread of malicious activity and acted on behalf of the greater good. However, if all organizations implemented basic egress filtering, we could limit the spread of unwanted and malicious activity on the Internet, to everyone's benefit.

This article is the latest in a series of blog posts offering best practices for network security. The series is intended to help government agencies and other enterprises address hidden sources of vulnerabilities within their networks. Read our series of posts: Distributed Denial of Service Attacks: Four Best Practices for Prevention and Response, Six Best Practices for Securing a Robust Domain Name System (DNS) Infrastructure, Best Practices for NTP Services, Best Practices for Network Border Protection, and Best Practices for Cloud Security.

We welcome your feedback and suggestions for future topics regarding best practices for network security in the comments section below.

Additional Resources

Read all the posts in the Best Practices in Network Security series.