QA Cyber Security Trainer, Graeme Batsman, discusses how you need to focus on outbound as much as (or more than) inbound rules.
Remember the last Hollywood film you watched? The bad guys or bad girls break into a bank vault, museum full of priceless artefacts or an Indiana Jones style secret cave crammed full of Inca or Maya treasure. They manage to get in, find what they want and then annoyingly the security protocol is triggered, and the security shutters come down or a curse is activated. Of course, they manage to escape in the end or the film would cease quickly. Inbound defences in this (fictitious) case are good and outbound are even better yet not in the real physical or cyber world in a lot of cases.
If a burglar or hacker breaks into your building or network, he/she needs to get out with or without his/her loot. It is of course not good if someone breaks in but if they can extract a diamond or file even worse… Not that you want a burglar trapped in your house permanently! The aim of most hackers is to exploit a vulnerability, download a payload or open a SSH connection for future use and then extract the organisations secrets. General un-targeted mass market ransomware is the same, once it downloads the .exe it needs to reach out to generate a public/private key pair. If it can't reach out or the domain name is blocked by the web filter, the decryption process will not happen.
In the past and still to this day most home users, businesses and public-sector organisations focus more on inbound rules. This is not greatly difficult since most firewalls and home router/modems have a default inbound deny rule by default. Inbound rules are not that hard and block everything but HTTP/HTTPs/SMTP and allow that to your mail or web server only. SSH and RDP should not be open generally and should be filtered to source IP addresses so any old person on the wild west web cannot try and brute force remote access protocols.
Even inbound rules can be defeated by flaws in web applications, or layer eights (also known as: human end users) opening malicious emails or clicking on links. Once the web application or end computer been exploited it either needs to download the payload and/or exfiltrate data or download a public key for un-wanted data encryption. If you can stop the download of the payload or exfiltration of data, then the whole attack may stop in its tracks. Strict outbound port control or better still port control coupled application and/or URL filtering is what you should be doing.
Exfiltration or malware often uses known ports such as HTTP (80/TCP) or HTTPs (443/TCP) which are always open for end computers at least. Outside of this attackers may configure their malicious software to dial out using a high port 1024-49152 or dynamic port 49152-65535.
Defending end computers
Only HTTP and HTTPs should be open with SSH & RDP being allowed out on a case by case basis filtered to destination IPs. Now the problem is the two most common protocols which allow an assortment of applications and services to run – HTTP(s). The conventional response is install a web filter which permits 35/40 categories. What's the problem? This method permits everything and tries to blacklist a few percent of the known malicious/unwanted internet. It is impossible to keep up with what is bad, and new domains will likely be missed. A better though stricter way of doing this is surveying your employees and allowing a few thousand websites out. Thus, new websites and malware sites would struggle to work due to the URL whitelisting approach over blacklisting. You could go further and run an application filter which inspects below the general port and can block applications running on single port like HTTPs.
Server admins do use Windows servers to browse the internet, even domain controllers and this is a big no no. Why do they do it? Since end computers may block pornography, gambling and webmail, and servers should but do not have web filtering policies always applied. Servers are meant to well… serve not be used to browse the internet. Very few ports should be open outbound, with DNS being locked to the internal DNS server and HTTP & HTTPs being locked to the update servers only. Java, Silverlight, Flash, Adobe PDF etc. should not be installed. If HTTPs is permitted outbound then LogMeIn and TeamViewer could be installed to bypass remote access policies. Filtering the destination IPs and/or which applications can run over a port is an excellent practice. If browsing is needed an internal proxy should be used which only permits access to certain websites. Application whitelisting for end computers and servers is another strong defence.
Now we have covered the virtual side, let's jump over to the non-fictional physical side quickly… your office and data centre. Coming in you should be using 'something you have' (ID card) and 'something you know' (4-digit PIN) though most organisations only have one of two. If someone can tailgate or blag their way into a building, then they need to get out as everyone else does unless they wish to jump out of a window into a rubbish truck like in the films! Getting in involves going through a barrier which should only allow one person out at a time. Going out should be the same with two methods of authentication and/or better a turnstile which is stricter than a general door or barrier.
Work article: Endpoint and network firewalling needs to change
- Hits: 168