Do Not Neglect Outbound Firewalling

If we are talking in extremes (which we often need to in today's security landscape) then the only true method of ensuring absolutely no possibility of unwanted connections to a device is to unplug the connection to that device.

Simple, elegant and completely useless.

It might make sense for people like intelligence agencies and the CIA to have truly air-gapped networks to ensure no hackers can get in but the rest of us have to run updates every 2 weeks and Brenda in accounting needs to do her Asda shop.

The closest we can get realistically to air gaps is with firewalling and closed rulesets that drop all traffic, but the question remains why would you want to and why am I still rambling on about this?

Attack Vectors

I bring up attack vectors for 2 reasons: firstly it sounds cool and makes my post look cool but more importantly there are many different types of attack utilised by the modern hacker. A lot of these attacks come from the outside, penetrating Web Applications and then moving from system to system, but there is also a great deal of attacks or breaches that begin with an initial foothold and an outbound connection.

A piece of malware can be executed and generate an outbound connection to perform a range of tasks including allowing a hacker in to control the software or picking up a key from a server so it can encrypt your files and ransom them back to you.

Some hackers will even skip the malware and opt for gaining physical access to the network through social engineering or old fashioned breaking and entering.

Whatever method used an available outbound connection is a must for these types of breaches to occur. Even when our team is performing penetration tests there is a request to NAT some sort of connection back to the tester proving this is a potential problem on most networks.

But I Need ALL Ports Open!

Do you though?

Do you really though?

Lets look at the average access needed on a modern network and we can make sure we are running the minimum amount of leakage possible to reduce the change our connection could be used against us.

Web Browsing:

This is a given that ports 80 + 443 are going to be open but we can still apply a lot of control to this traffic. All web traffic should be filtered and logged to start, HTTPS inspection should be applied to the traffic on port 443 so it is decrypted and fully inspected. The rules should be authentication based, usually most firewalls with a connection to your Active Directory can be used to achieve this. And Last a full suite of AntiVirus and IPS scans against the traffic should pick up any malware transferred or known attack traffic.

DNS:

Always lock this down to just the DNS server don’t allow any machine to perform DNS connections.

Email:

Again, this should be locked down to mail servers only.

Updates:

Try to utilise an update manager so access is only needed for a single device, if that isn’t possible try to minimise the number of devices performing the downloads for required updates. As a range of ports could be required with minimal filtering, try to create firewall rules that only allow the connections to the required update sites. If you find yourself unable to be specific, then try using scheduled firewall rules to air-gap the device virtually. If it runs updates at 10pm then have the firewall rule only activate just before that time and to deactivate as soon as possible while ensuring the task completes.

To take this one step further you could also schedule the update connections for the machines to update from the management server and again using firewalling only allow those connections at specific times creating a sort of virtual airlock for traffic where a malicious user would otherwise be able to connect to the update box to generate a route out of the network.

Miscellaneous Connections:

On every network there will be a need for a connection that does not adhere to the above mentioned. It could be a specific piece of software or the need to connect to remote customer sites but all these things can be locked down and controlled by either the source address or destination address minimising the usability of the rule to only the desired connections.

If a user has none standard software that connects out then lock down the rule to just that user and if possible just the target destination, only use the specific ports the software needs and if possible use scheduling to lock down access to specific times.

Wherever possible use user-based rules instead of IP's or interfaces as the source this ensures a device must be authenticated to access the rule.

Jump Boxes

Certain key servers or devices will inevitably end up with more access or some may be considered more at risk due to placement within the infrastructure. Servers hosting web applications or externally accessible resources are a good example of this. Usually those boxes will be placed in a DMZ or segmented in some way to ensure they cannot talk to the main network apart from specific required connections.

Often though I see that the firewall is set to allow all traffic to these devices as the threat is perceived as coming from the outside so the rules going to the DMZ are relaxed for easier management and access.

The fact is if the attacker has a foothold already and is seeking an outbound connection to perform a task these boxes are a perfect route out. With open rules to the DMZ an attacker can generate a connection that allows the compromised server in the DMZ to send traffic back allowing the attacker to download files or route inbound connections.

So we get the catch 22, if we cut off all ports we cant manage the devices in the DMZ and administration becomes impossible especially for machines not located locally.

The answer to this is to place a jump box in its own DMZ. This box has all the tools needed to manage the DMZ servers and perform whatever administration is required and the firewalling should only allow connections to the DMZ servers from this box on only the specific ports required.

As this box is in its own DMZ you then need to create access rules to it from the main network which again should be locked down to only administrators and utilising whatever scanning and authentication is available.

For maximum security the jump box itself should utilise high security settings and preferably some form of two factor authentication technology to make unwanted connections extremely difficult to achieve.

Never too late for a spring clean

Have a look at your network layout and ask yourself how open are you really?

If you were to take a laptop and pick a random port what could you do from there?

If a hacker compromised a workstation or one of your servers, what can they connect to from there?

There is no perfect solution i'm sure, but the less connections available especially when talking about outbound connections the less chance an attacker has to establish a required connection. Avoid rules that feature words like ALL or ANY and try to justify each connection. Where rules can’t be avoided always try to think how you can minimise what that rule can be used for and if it has to be there then try to schedule its availability and make sure it is as fully scanned as possible.