Based on security assessment results, penetration testers often recommend hiding an enterprise network’s ports behind a whitelist. However, corporate IT teams don’t always understand the need for such a countermeasure. Even some admins and DevOps specialists with tons of experience wonder why this is necessary.
Let’s take a dive into the risks of keeping ports open and the common vectors of cyber attacks exploiting them. Below is a list of these perils in descending order by their occurrence and possible damage.
- Configuration error
- DDoS over IP
- Brute force
- Service vulnerabilities
- Kernel stack vulnerabilities
- DDoS amplification
This is the most common scenario that leads to serious adverse consequences. Here’s how it usually happens. When a developer needs to check some hypothesis, he/she sets up a temporary server running MySQL / MongoDB / Elasticsearch / Redis (and we had numerous security breaches proving this).
The dev sticks with a complex password that he reuses for many other services. Then, he makes the service open to the world because he finds it convenient to connect through a GUI right from his PC without using any VPNs along the way. Recalling the iptables command syntax is too tedious – the server is temporary anyway.
A few more days of development elapse, and the project seems good enough to show it to the customer. The customer thinks it’s great. There’s no time to additionally fine-tune it, and so the coder moves on to the deployment stage.
This example is laid on with a trowel to a certain extent so that we can zoom in on all the mistakes:
- They say there is nothing more permanent than a temporary solution. I personally dislike this phrase, but from my experience, nearly half of such temporary servers stay up and running for a long time.
- Reusing a password for multiple services is a slippery slope, even if it’s very hard to guess. Why? Because one of these services may be compromised. Data dumps based on major breaches usually form a single large database that’s used for brute force attacks. It’s also worth mentioning that MongoDB, Elasticsearch, and Redis servers are accessible without authentication once set up, thereby complementing the existing open databases.
- You are wrong if you are sure nobody will scan your port 3306 in just a few days. Cybercriminals can leverage the Masscan tool that’s capable of scouring 10 million ports per second. There are roughly 4 billion IPv4 addresses on the Internet. If you do the math you’ll realize that every port 3306 in existence can be spotted in merely 7 minutes!
You might say no one would ever bother doing that, but I can prove you wrong based on a quick glimpse of dropped packets statistics. Where can 40,000 scan attempts a day from 3,000 unique IPs come from? Everyone – from low-profile hackers to governments – is scanning the Internet these days. This activity is a no-brainer to check: get a random VPS for a couple of bucks, enable logs of dropped packets, and take a look at the statistics in a day or so.
DDoS over IP
If adversaries know your IP they can fire a DDoS attack at your server that may last for several hours or days. Not all hosting providers have DDoS protection mechanisms in place, therefore your server will simply get knocked off the network. In case you hid your server behind a CDN, be sure to change the IP address or else the malefactors will find it on a search engine and get around the CDN to DDoS your server regardless. This is a very common mistake.
As mentioned above, there is a database containing hundreds of millions of easy-to-type passwords. If your password consists of characters that are close to each other on the keyboard, then you run the risk of falling victim to a successful brute force attack.
Even the most extensively tested and critical software has flaws that are discovered over time. There’s a sort of a joke in InfoSec circles: you can gauge the defenses of infrastructure by the last time an update was applied. If your network is full of Internet-facing ports and you haven’t updated your software for a year, then any security analyst will say you are vulnerable and have probably been hacked already.
Furthermore, keep in mind that all documented vulnerabilities were once unknown. If a black hat hacker discovers a new security flaw and runs a 7-minute scan of the World Wide Web to spot networks susceptible to this zero-day bug – voila, a new epidemic is just about to break out. Obviously, applying updates is a must. You might say, though, that it may affect the stability of your software. Well, this objection only holds true if you have installed packages from unofficial OS repositories. Updates from certified repositories are very unlikely to ever impact the product.
Kernel stack vulnerabilities
There are cases when it doesn’t even matter which service is opening a port as long as the kernel stack proper is exposed to exploitation. In other words, any TCP/UDP socket on a 2-year-old system is potentially vulnerable and can be used to pull off a DDoS attack.
This attack vector probably won’t cause direct harm, but it may congest your network channel and raise the system load. To top it off, your IP will end up on some kind of a blacklist and you will receive an abuse complaint from the web hosting provider.
It’s not in your interest to face all these risks, is it? So consider adding your home and work IP to a whitelist. If it’s dynamic, then perform the login via the hosting service’s admin dashboard or web interface and simply add another one.
I have been building and protecting IT infrastructures for more than a decade, and there is a rule of thumb I always follow: there shouldn’t be a single Internet-facing port that’s not on a whitelist. For instance, the most secure web server is one whose ports 80 and 443 are only open for CDN/WAF. Meanwhile, the service ports such as ssh, bacula, metadata, and PHPMyAdmin, should be at least hidden behind a whitelist, or more preferably, behind a VPN service. If they aren’t, your network will be low-hanging fruit and may be compromised.