“Those who cannot remember the past are condemned to repeat it.” – George Santayana
Default broken
I was reminded, last week, of how old issues repeat.
Back in the 90s it was a truism that if you put an “Out Of The Box” RedHat
4 (not RedHat Enterprise; the original freeware version) server on the
internet then it would be compromised within hours. And so we learned;
our default builds didn’t have telnet, didn’t have every possible
service installed, didn’t have vulnerable configurations. The installer
would try and install patches at built time. The root account may not be
directly accessed via ssh. Windows machines now have firewalls to block
non-local traffic…
Lots of security improvements.
Of course you can put bad machines on the net, but it’s harder to do.
Unfortunately there’s a new generation of developers who failed to learn these lessons. The Mirai botnet spread via Internet Of Things (IoT) devices that failed to do basic security (exposed telnet ports, default unchangeable passwords). This was made worse by using UPnP to expose many of these machines directly onto the internet. These are 20+ year old mistakes, being repeated today.
New ingress points
We learned how to protect environments; firewalls, WAFs, traffic monitoring and so on. We track CVEs, we patch, we have configuration management tools… all in an effort to prevent bad services from being exposed, and to defend against incoming rogue traffic.
However these can only protect against known paths. What happens when a new ingress method is created? For example, IPv6. This can create routes and methods of ingress that bypass existing technologies. For home users used to being behind NAT it may now expose desktops and IoT devices directly to the outside world that were previously protected.
What’s that, you say? No IoT? You don’t have a DVR? A games console? A cellphone? A smart TV? Nothing? Then you’re lucky. So many devices, these days, talk to the internet… and many of those may become directly reachable when IPv6 becomes prevalent.
Cloud
Repeating the mistakes of the past is pretty common when it comes to companies moving into the cloud.
Your traditional corporate datacenter has a lot of technology in place to protect servers within the (virtual) 4 walls of the company. Starting with multi-tier architectures and firewalls (both internal and external), proxies, automation, access controls… companies spend a fortune on technology to help protect servers and data.
And yet it’s not uncommon to see teams deploying servers and software out in the cloud on their own. This “shadow IT” is being created by teams who don’t know (and may not even be aware) of the technology protecting their apps. So they spin up an Amazon account, create networks, expose servers to the internet… and then wonder why they got broken into.
Containers
The same problem applies to container based solutions. We may expose software directly from inside a container (eg a tomcat instance, or something running Apache Struts, or a bad version of OpenSSL), and this is not controlled or even visible to corporate monitoring systems (containers tend to be opaque boxes, and are so dynamic that existing tools may not even be able to handle them, requiring new tools and solutions).
Summary
People deploying solutions need to remember the lessons of the past. We can never go backwards because attacks against those old issues still happen; they’ve been automated into scripts and don’t require any human action to be probed for. Out of curiousity I told my firewall to report incoming port 23 (telnet) connections… I turned the reporting off again a few hours later because the logs were being flooded.
We’re not talking about targeted attacks, this is just random background internet noise. But if you make a mistake then you will be breached and find your server part of a botnet, or a bitcoin miner. If you’re being targeted then these decade old issues will be attempted before the attacker has even sat down with his first cup of coffee.
This isn’t a technology problem, although many companies approach it in that manner. This is an education problem. We need to teach teams why certain processes and procedures exist; why they shouldn’t use shiny-toy-of-the-month; why… Don’t dictate rules, but bring them in as partners.
There will still be tension (“move faster!”) but maybe they’ll be willing to help build the solutions needed to use the shiny-shiny.