Again and again, after conducting an audit, I face a wall of misunderstanding when I recommend hiding ports behind a whitelist. Even very experienced admins/DevOps ask, "Why?!?"
I suggest considering the risks in descending order of likelihood and damage.
- Configuration error
- DDoS by IP
- Brute force
- Service vulnerabilities
- Kernel stack vulnerabilities
- DDoS attack amplification
Configuration error
The most typical and dangerous situation. How it happens. A developer needs to quickly test a hypothesis, so they set up a temporary server with mysql/redis/mongodb/elastic. The password, of course, is complex, and they use it everywhere. They expose the service to the public — it’s convenient for them to connect from their PC without those pesky VPNs. And they feel too lazy to recall the syntax for iptables, seeing as the server is temporary. A couple more days of development — it turned out great, ready for the client. The client likes it, there’s no time to redo anything, let’s go live!
An intentionally exaggerated example to cover all the pitfalls:
- Nothing is more permanent than temporary — I don’t like this phrase, but from subjective experience, 20-40% of such temporary servers stick around for a long time.
- A complex universal password that is used across many services is bad. Because one of the services where that password was used could have been breached. Sooner or later, databases from breached services merge into one, which is used for [brute forcing]*.
It’s worth adding that redis, mongodb, and elastic are actually accessible after installation without authentication, and often contribute to . - It may seem that no one will scan your port 3306 in just a couple of days. This is a misconception! Masscan is an excellent scanner and can scan at a speed of 10 million ports per second. And there are only 4 billion IPv4 addresses on the internet. Accordingly, all 3306 ports on the internet can be found in 7 minutes. Carl!!! Seven minutes!
"Who needs this, anyway?" — you might retort. I’m surprised too, looking at the statistics of dropped packets. Where do 40,000 scan attempts from 3,000 unique IPs come from in just one day? Everyone is scanning now, from amateur hackers to governments. It's very simple to check — take any VPS for $3-5 from any low-cost provider, enable dropped packet logging, and check the log after a day.
Enable logging
In /etc/iptables/rules.v4, add at the end:
-A INPUT -j LOG —log-prefix "[FW — ALL] " —log-level 4
And in /etc/rsyslog.d/10-iptables.conf
:msg,contains,»[FW — » /var/log/iptables.log
& stop
DDoS by IP
If an attacker knows your IP, they can DDoS your server for hours or even days. Not all budget hosting providers offer DDoS protection, and your server may simply be disconnected from the network. If you have hidden your server behind a CDN, don't forget to change your IP; otherwise, the hacker can find it online and DDoS your server bypassing the CDN (a very common mistake).
Service vulnerabilities
All popular software eventually has bugs, even the most tested and critical ones. In the security community, there’s a half-joke: you can assess the security of infrastructure based on the date of its last update. If your infrastructure has many exposed ports and you haven’t updated it in a year, any security expert will tell you without hesitation that you have vulnerabilities and are likely already compromised.
It's also worth mentioning that all known vulnerabilities were once unknown. Imagine a hacker who found such a vulnerability and scanned the entire internet for it in 7 minutes… And thus, a new viral epidemic. You need to update, but this might harm production, you might say. You would be right if the packages are not installed from the official OS repositories. In my experience, updates from the official repository rarely break production.
Brute force
As mentioned above, there is a database of half a billion passwords that can be easily typed on a keyboard. In other words, if you didn’t generate a password and typed adjacent characters on the keyboard, be sure — you will be brute-forced.
Kernel stack vulnerabilities.
It can happen that it doesn’t even matter which specific service opens the port when the network stack of the kernel is vulnerable. This means any tcp/udp socket on a two-year-old system is susceptible to vulnerabilities leading to DDoS.
Amplification of DDoS attacks
While it won’t cause direct damage, it can congest your network, increase system load, your IP might end up in some black-list, and then you will receive complaints from the hoster.
Do you really need all these risks? Add your home and work IP to the white-list. Even if it’s dynamic — log into the hoster’s admin panel, through the web console, and simply add another one.
I have been building and protecting IT infrastructures for 15 years. I formulated a rule that I strongly recommend to everyone — no port should be exposed to the outside world without a white-list..
For example, the most secure web server is one that only has ports 80 and 443 open for CDN/WAF. Service ports (ssh, netdata, bacula, phpmyadmin) should at least be behind a whitelist, or even better, behind a VPN. Otherwise, you risk being compromised.
That's all for me. Keep your ports closed!
- (1) UPD1: you can check if your awesome universal password (don't do this without replacing this password with random ones across all services), has been leaked in a breached database. you can see how many services have been hacked where your email appeared, and accordingly determine if your awesome universal password has been compromised.
- (2) To Amazon's credit — there are minimal scans on LightSail. Apparently, they filter somehow.
- (3) An even more secure web server is one that is behind a dedicated firewall, with its own WAF, but we’re talking about public VPS/Dedicated.
- (4) Segmentsmak.
- (5) Firehol.
Only registered users can participate in the survey. , please.
Do you have ports exposed to the outside?
- Always
- Sometimes
- Never
- I don't know, maybe
54 users voted. 6 users abstained.
Source: habr.com
