Egress filtering by blocking unused ports

Question

Our company wants to block data exfiltration. They want to control outbound traffic going out from unused ports. I did traffic flow analysis at our edge firewalls to know which ports are used by our applications. There are some 2000 ports through which traffic is going out(to outside network or Internet) which means some 65535 - 2000 -1024(reserved ports) 62511 ports are unused so can be blocked or we can set Access Control List(ACL)s to allow only the 2000+1024 ports = 3024 ports and block the remaining. I know using 62511 ACL rules to block the unused ports is lot longer than writing 3024 ACL rules to whitelist the used ports.

I understand a nation state attacker can use tunneling to exfiltrate data using commonly used ports such as 443, but we are trying to limit data exfiltration. We use Cisco gear and ASA firewalls.

I know using range command in ACL, I can group the contiguous ports something like

object-group service CLOSE-PORTS tcp port-object range 2000 3000 port-object eq 80 port-object eq 443

access-list TEST extended permit tcp host internal_host host outside_network_host object-group CLOSE-PORTS

where internal_host and outside_network_host can be IP addresses with subnet masks like 10.0.0.1/24

1. Is blacklisting ports(blocking unused ports) better or whitelisting(only allowing outbound traffic from ports) better?

2. How can I ensure the ACL is not too long which can impact router/firewall performance? Is there a way to reduce ACL length?

3. Any other suggestions on how to do this to prevent data exfiltration would be helpful.

Thanks

Answer 1

The first thing you need to do is categorize the hosts/networks inside your company:

1. Desktop hosts (used by employees for web surfing)
2. Datacenter hosts (used by specific applications for specific purposes)
3. Compliance hosts (PCI, HIPPA, FERPA)

Datacenter and compliance hosts are the easiest to apply egress rules. Because these hosts are used by specific applications, you can (eventually, after log and traffic analysis) block egress access to the Internet, except for specific sockets needed for specific applications. My "standard datacenter ACLs" for new datacenter subnets included a deny-by-default egress rule permitting access to other datacenter nets, but denying egress access to desktop and internet networks.

(my standard datacenter ACL also had datacenter->datacenter ingress rules, not discussed here).

For desktop networks, it is infeasible to apply egress rules. As soon as you allow people to websurf, you can't stop it. But there are two things you can do:

1. Use netflow data to detect large egress data flows. Some vendors sell products to look for data exfiltration from netflow and network tap data.
2. Prevent desktop networks from accessing datacenter networks without authentication (I like having a separate "datacenter VPN" for IT personnel only, desktop networks are considered outside the datacenter security perimeter)

Compliance hosts have special requirements. I'll assume PCI for the rest of this discussion, since that's what I'm familiar with.

PCI hosts are not allowed unrestricted egress access to the internet. One test most PCI auditors do is attempt to ping the internet from hosts that are in-scope. If they can ping the internet (or websurf the internet) that requires remediation.

Specific egress sockets to specific destinations are ok for business reasons (you've got to be able to reach your credit card processor).

That gives you 3 levels of security, in increasing order:

1. Desktop hosts
2. Datacenter hosts
3. Compliance hosts (hopefully in restricted part of datacenter, but public helpdesk personnel taking customer credit card numbers are a difficult case).

Prevent #2 and #3 from egress access to the internet, and restrict access between the security levels.

Naturally, ingress access from the internet should already be blocked to all 3, except public-facing internet services. Stateful firewalls are explicitly required for PCI compliance zones.

Answer 2

Generally, most data exfil uses HTTPS with the standard 443 port. Blocking 'exotic' ports will not likely help but increase your support calls.

If you do want to filter uncommon ports, don't forget to establish an easy procedure to allow users to have required ports added to the whitelist, even temporarily.

How are you planning to distinguish data exfil via Wetransfer, Dropbox, ... from legitimate use?

Is blacklisting ports(blocking unused ports) better or whitelisting(only allowing outbound traffic from ports) better?

Best practice is to permit/whitelist known traffic and block everything else.

How can I ensure the ACL is not too long which can impact router/firewall performance? Is there a way to reduce ACL length?

This can get tricky. If you need granular control you might need to shorten/optimize ACLs in regular intervalls. If they are kept well-structured that should be manageable.

Any other suggestions on how to do this to prevent data exfiltration would be helpful.

A good firewall with decent DLP features, SSL deep inspection, granular application awareness and user authentication will make the task much simpler and likely more successful than simple port-based filtering. However, DLP needs to start at each client - controlling and managing applications and ports, containing threats and infections. The firewall can only be one piece of your total strategy.

Answer 3

Another way to describe your suggestion is allowing traffic from your network to anywhere on the Internet as long as it's bound for one of 2000 ports, many of which are in common use. Since attackers can easily have control of an Internet host (e.g. by renting a server) it is absolutely guaranteed an attacker who has access to your network will be able to find a way back out.

It sounds like this might be your first foray into developing a more granular network security policy. I suggest you work with your system administrators on a policy for each type/group of hosts.

Without more granularity, you are only able to (try to) design your ACL policy around the least-secure, or most-talkative, host on your whole network.

I hope this helps.