Importance of Egress Filtering

“Egress filtering is the practice of monitoring and potentially restricting the flow of information outbound from one network to another. Typically, it is information from a private TCP/IP computer network to the Internet that is controlled.” - Wikipedia


During a recent external network penetration test I was able to leverage application functionality to test the client’s current egress filtering capabilities in an attempt to capture sensitive information. This post will cover some of the tactics I used in order to capture sensitive information as well as common mitigation strategies organizations can take to narrow down outbound traffic.


During the engagement I discovered a publicly facing web application. While mapping out the application I noticed there were areas within the application that contained pre-configured Microsoft SQL (MSSQL) connection strings. The connection strings contained information like hostname, database, username, and password. At times a user can inspect the HTML code to find the password, however, in this instance, I was unable to discover the password.

One toolset that came to mind was Responder - Responder can perform a wide variety of functions but in this specific instance the built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication servers are exactly what we are looking for. With Responder installed on an Internet facing host, I started it with the following command:

sudo ./ -I eth0

Now that we had Responder up and running we can switch over to the application. As I stated previously, while mapping out the application I discovered multiple MSSQL connection string configurations. Looking at the screenshot below, there was a JDBC connection pool alias with previously configured information. The database URL contained the host information the application was connecting to as well as a user ID and password as well. Another important functionality was the “Test Connection” feature to verify the connection works.


In the screenshot below we changed the database URL to the IP address of our externally facing Responder agent then clicked the “Test Connection” button.


In the next screenshot, our Responder window showed us that the application reached outbound via MSSQL and attempted to authenticate to the simulated MSSQL server. The credentials have been blurred to prevent any client disclosure.



Larger organizations that haven’t yet implemented egress filtering mitigations might look at this as being a daunting task. There are many configuration changes, device implementations, and process improvement that can be made to get egress filtering under control. Some practices that can be done include:

  • Firewall - Default Deny

    • Default deny denies any service / protocol not explicitly allowed through the firewall. This is definitely more secure posture however it does require individuals to understand the flow of information that leaves the network.

  • Filter internal-only services

    • Ensure that services that don’t typically run across the internet be blocked. Any requirement for outbound access should be filtered to a specific external IP address.

  • Implement Web Proxy

    • Only allow approved outbound web traffic. Force all web browsers to utilize the web proxy to perform web browsing.

  • Business Justification For Outbound Rules

    • Ensure there is a documented business justification for any outbound allow rules. The justification should include information about:

      • Why the rules were created?

      • Who created the rules?

      • What applications or users are utilizing the rules?

      • Who created / maintains the rules?

Brett DeWall