I had an interesting question from a client last month. They were looking for guidance on “egress filtering.” Egress filtering is the concept of tuning your perimeter defenses (firewalls, routers, IDS*, and UTM* devices) to review and restrict the flow of information that is leaving your network.
Historically, most perimeter defenses are are designed to keep bad things from coming INTO your network. This may have been sufficient in the past, but in a threat environment where most attacks start as a phishing email (arriving on unfiltered ports 80, 110, 995, 143, 993), these attacks appear and act as an insider attack. To detect this sort of an intrusion, your security systems have to be looking for outbound command and control (C2) traffic, and stolen data leaving via FTP. This is where egress filtering comes into play.
I replied to the client with a list of my favorites. Good ports to block are FTP (20 and 21), Telnet (23), and all the MS SMB ports (135, 137, 138. 139. 445). These protocols are should not be leaving the building, especially File Transfer Protocol which could be evidence of unauthorized data exfiltration. FTP and Telnet are unencrypted, clear text protocols, and a packet sniffer could harvest your user credentials easily. SMTP (25) outbound mail from any host other than the mail server should be blocked to prevent an attacker from using a system as a SPAM bot, so the rule is block ALL, allow mail server IP only. SSH (22) needs to be protected with a strong user name and password combination, not admin or administrator for user, passwords at least 12 characters, in order to beat automated brute force attacks.
Digging deeper, I found a couple of excellent resources on the subject, which I’ve listed below. The Security Skeptic recommended “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. This creates a “nothing leaves my network without explicit permission” security baseline. Next, add rules to allow authorized access to the external 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.”
I found the article to be a great short read with a step-by-step plan to help you put an egress filtering policy into practice.
The SANS Institute was quick read full of useful information, including a list of outbound ports to block. Most of these were not on my list.
- MS RPC (TCP&UDP 135), NetBIOS/IP (TCP&UDP 137-139), SMB/IP (TCP/445)
- Trivial File Transfer Protocol – TFTP (UDP/69)
- Syslog (UDP/514)
- Simple Network Management Protocol – SNMP (UDP 161-162)
- SMTP from all IP’s but our mail server (TCP/25)
- Internet Relay Chat – IRC (TCP 6660-6669)
- ICMP Echo-Replies (type 0 code 0)
- ICMP Host Unreachables (type 3 code 1)
- ICMP Time Exceeded in Transit (type 11 code 0)
So there are two ways to proceed. The first is a BLOCK ALL, permit explicit services approach that is probably the strongest approach, but one that will have unexpected access issues for a while as you tune your permission to match your network’s requirements. The second it to block specific ports, and add to the block list as others become problematic. Either way, I would recommend reviewing both articles before starting your egress filtering project.
- IDS – intrusion detection system
- UTM – Unified Threat Management system, such as AlienVault