Does a constantly dynamic cluster of short-lived instances reduce attack surface?

Question

The 4am Idea

The general idea is that every instance that gets launched on my cluster is preloaded with a 'suicide script' that after a preset Time To Live (say, 27 minutes) launches a replacement instance, and then terminates itself.

The result is a 'constantly rolling' cluster where no IP address exists for longer than the TTL of any given instance.

I don't have a comprehension of attack vectors or attack surface theory like I'm sure most of you do, but this sort of approach seems to offer some interesting advantages.

Here's What I'm Thinking Could Be Achieved

• Reduce Overall Intrusion Attempts Per Instance: The short lifespan of each IP would reduce the time available for any intrusion attempts. Once a target IP is found, the attacker has only the TTL before the window closes, thus reducing the overall number of attempts, thus reducing the overall probability of a successful attack.
• Frequent Security Updates: The instances would handle their security updates upon launching, which means they would never be more than 27 minutes out of date with security patches.
• Eliminate Deployment Layer: If you handle app deployment upon launching, which I do, this would automate the process even further by obviating the need for Githooks or Dockerhubhooks, for better or worse.

A quick thought experiment would also reveal that if you reduce the TTL down to a point where any given instance only has time to handle starting itself up, handling a handful of requests (the 'suicide script' could also be triggered after a certain number of requests have been handled, like say, 27), and then it goes down it seems to me that it would greatly increase the difficulty of an attack. If the attack requires more than 27 requests then the attacker would never be able to complete all the steps needed to succeed.

So I think those are interesting, good things. There are obviously many more factors to take into consideration, not least of which is the impact this could have on how requests are handled by your router, and whether or not your cloud provider would even allow this considering the extra CPU load it would put on their system.

Would this reduce the attack surface for the following attack vectors?

• Attempts to compromise open-ssl
• Port Scanning
• HTTP/HTTPS which is listening on 80 and 443 on each instance

It's worth noting the the applications on each instance would be ephemeral apps, the session storage is a remote Mongo cluster (running in the same AWS region), and Nginx would be used on each instance to handle the routing of traffic to the correct IP:PORT of each app installed on the instance, which is why 80 and 443 need to be open.

Thanks in advance for any information you may want to share.

Answer 1

Does a constantly dynamic cluster of short-lived instances reduce attack surface?

Reduce the attack surface?

I don't think it does significantly. It wouldn't necessarily allow you to run any fewer services or have any fewer services exposed to potential attackers. The overall exposed surface of your system stays the same.

Reduce the threat?

I don't think so either, it doesn't necessarily reduce the number of vulnerabilities which might exist in your system or the number potential attackers who are motivated and capable of exploiting your system. It may reduce the threat slightly if this could lead vulnerable software to be updated more quickly, but that could also be achieved without replacing the instance.

Reduce the risk?

Yes, I think it would - the question is by how much. You're making it more difficult for an attacker to exploit your system, and therefore reducing the chance that they will succeed but you're not fundamentally removing any attack vectors.

I'd consider this somewhat like an intrusion prevention system (IPS) that generally attempts to block suspicious requests. In that case you're reducing the chance that an attacker will succeed because they first have to circumvent the IPS, but you're not actually removing any vulnerabilities from your system.

Also, there's certain attack vectors which would be entirely unaffected by this:

• SQL injections - Could be exploited regardless of which instance served the request
• DDoS against a computationally expensive request delivered via your load balancer
• Malicious code stored in shared infrastructure - eg. your DB

the attacker would never be able to complete all the steps needed to succeed

This would be valid if you could guarantee that a vulnerability cannot be exploited in 27 minutes - otherwise the effectiveness will vary greatly between attack vectors. Some attacks could easily be orchestrated in less than a minute.

For example, in real life time-delay locks works because if you know that the police will arrive in 20 minutes but the safe can't be opened for 30 minutes. Unless you could recreate this scenario I don't think any vulnerabilities are eliminated.

Attempts to compromise open-ssl

I doubt it assuming all of your instances are running a vulnerable version. Maybe if it takes longer than 27 minutes to exploit.

Port Scanning

No, all your instances would presumably have the same open ports and active services. When one instance goes offline they could just continue the scan on another instance where they left off.

HTTP/HTTPS which is listening on 80 and 443 on each instance

There's a huge variety of exploits that could be delivered over HTTP, but in general I don't think it would make much difference. Typically load balanced systems are designed to serve the same response from every instance, therefore if an SQL injection can be performed against one instance it would almost certainly work against another.