I apologize in advance for the gross simile. But I want to be clear: public IP addresses you get from cloud providers like AWS are very dangerous. They’re like using someone else’s toothbrush — someone who had an infection.
Can you avoid using public IP addresses in AWS and other cloud providers? Not completely. Is there a better solution on the horizon? Yes, but it’s not imminent.
Allow me to elaborate. I was reviewing bandwidth charges for an AWS client and noticed very small (less than $0.01) charges for bandwidth from AWS regions in Asia-Pacific, Ireland and Japan. This client has no resources in any region outside the US. I wondered, “Where did these charges come from?”
Simple answer: they come from the malignant “background radiation” of malware and bots that’s ever-present on the Internet, searching for something to infect. Remember the old pre-firewall days when we used to connect client machines with public IPs to the ‘Net? You would be pwned instantly. Today, we hide behind routers and firewalls but that doesn’t mean the bad stuff has gone away. It’s still out there, looking for anything to get a toe-hold on. Plus, we are talking about assigning public IPs to servers, not clients. So if I were a bot looking for a mark, I’d check ARIN and RIPE, find all the public cloud providers’ IP address ranges and have at it. It’s easy pickings.
Even worse, the public IP addresses you typically get from a cloud provider may have been recently used and released by badware servers and applications. That IP address you’ve just connected to a new website might have recently hosted command-and-control for a botnet. Or, it could have been the server IP for a ransomware gang. Shockingly, a significant number of the banned IPs I am seeing on my Ubuntu Azure virtual machine come from address ranges in — wait for it — Microsoft’s own assigned IP space. I am sure AWS and Azure do what they can to evict bad guys, but at the scale of the cloud they could never be very effective. And inheriting an IP used maliciously may just make your cloud server even more exposed to being banned or blocked.
So, if you are connecting your server to one of these nasty IP addresses and if it’s listening on standard ports (ssh on 22; HTTP on 80; TLS on 443; RDP on 3389), you’re inviting every piece of slime on the ‘Net to come at you.
Let’s take a look. In AWS, you can assign a public IP to a running instance at launch either by policy or by specification in the AWS console. You get an IP of unknown provenance that lasts for as long as this instance runs.
AWS’s warning about what you are doing can only be described as coming from a split personalty. First, it tells you (in somewhat colorful terms) that your tuchis is to the wind; then it recommends that you “open additional ports…” It also recommends that you open ports only to known IP addresses, something that cannot work for public-facing servers, like WordPress sites.
So, what can be done? First, don’t use dynamically assigned, temporary IP addresses in AWS. Instead, get yourself an Elastic IP. You don’t own these, of course, but they are added to your account (and you’ll pay if you don’t use them) and, over time, as the ‘Net adjusts to IPs that are malicious, your EIP is less likely to end up on blacklists. If you are auto-scaling up and down, it’s more work of course. But it’s also far safer.
Another technique (which also costs more) is to put all your instances behind an Elastic Load Balancer. ELBs give you the ability, for example, to terminate TLS at the ELB and, since they use DNS CNAMEs for their IP addresses, AWS can (and probably does based on the documentation) rotate the IPs associated with the ELB.
If you’re running Linux, check out Fail2Ban. This log-scanning tool will automatically ban IPs that it decides are attempting to hack you via ssh logins or Apache probes.
I also think AWS could be more proactive in managing IPs to prevent them from becoming a honeypot that gets attached to your pristine new Apache server. If they know enough to bill a user $0.00001 for inbound traffic over a month from Tokyo, they know enough to understand it was probably an ssh probe. They’ll say, “An IP is an IP and we don’t want to be in the business of policing them”. But I say the cloud is all about added-value and this is an area in desperate need of attention.
The real solution, IMO, is IPv6. Then we can all have enormous address spaces that don’t have to be reused. Bottom line, we need IPv6 because while we haven’t reached total scarcity of IPv4 addresses, we are reusing them as a way of managing their limited number. And that’s why if you are brushing your new server’s teeth with a public IP address from a cloud vendor, you better rinse really well.
Leave a Reply