This guide outlines a method to quickly assess the egress traffic filtering of a firewall using the Nmap port scanner.
Egress Traffic are connections that are initiated from within an organsiation / system to an external Internet host.
Ingress Traffic are connections that are coming into a system, this is typically web servers, mail servers and other services. So if a web server is protected by a firewall typically the firewall will allow ingress traffic on ports 80 and 443 (HTTP and HTTPS), other ports are blocked by the firewall. To test ingress traffic filtering try our free online port scanner.
Why test for Egress Filtering?
On a network where the router or firewall is performing NAT for the internal clients, the ingress traffic will typically be denied from the Internet to any of the internal systems. Many systems however will have more open rules allowing the client systems direct access to external Internet IP addresses. This can be due to poor configuration, or a need for specific applications.
Poorly managed filtering of egress traffic, opens up the network to attack from reverse shells and data ex-filtration. A reverse shell means if an attacker can execute code on a Internal host then they can effectively gain full access to the system by initiating a connection outbound to a machine the attacker controls. Data ex-filtration can occur through simple file transfers using anything from netcat to secure copy using ssh.
Using Nmap to test Egress Firewall Rules
This is a simple test and does not replace a full firewall rule audit. However this is a quick and easy test that can reveal ports that are open outbound from an internal host.
In this test we will initiate an nmap port scan using all TCP ports (65535) from an internal host to an Internet host. The target host we will use is the scanme.nmap.org this is hosted by the creator of Nmap and has no firewall protecting it. A requirement for the test we are going to perform.
Since the target host has no firewall, any ports that are determined to be open or closed in our results will be ports that are not being blocked by our internal firewall. Any ports that are filtered are being blocked by the firewall at our end.
sudo nmap -Pn -p 1-65535 scanme.nmap.org
This will perform a TCP syn based port scan against the host scanme.nmap.org. It will not first attempt to ping the host (in case your internal firewall is blocking external ping).
Results: After running the scan review the results and take note of any ports that show closed or open. If "all ports are closed" apart from the few open services on scanme.nmap.org then this indicates that the firewall is doing no blocking on egress traffic.
Internal network best practice
The most secure way your external firewall can be configured to allow Internet access by Internal clients is to have all direct outbound connections blocked. Web access is then provided by an internal filtering proxy and email is through an internal email server. This provides the ability to perform filtering on the HTTP and SMTP traffic, for not only malware but also malicious domains.
Additional risks
To fully lock down an internal environment can be difficult to achieve, application aware firewalls may be helpful in this matter however take note of the following examples. There are techniques that attackers can use other than direct outbound connections in order to initiate a reverse shell or data ex-filtration.
DNS; it is possible to use a series of dns lookups in order to communicate outbound from a network, the dns lookups can go via an internal DNS server and the control traffic can be in TXT records or even the host subdomains.
HTTPS over a proxy; remote control access to internal machines is possible over a proxy server using the HTTPS protocol. This can avoid filtering and monitoring systems unless SSL connections are being inspected. Not a trivial thing to implement for most organisations.
An example of this https tunneling is included in this post that shows the use of the metasploit meterpreter payload over a HTTPs proxy.