Increasing Attacker Cost Using Immutable Infrastructure
diogomonica.com
Increasing Attacker Cost Using Immutable Infrastructure
1–10 of 37 posts
Re: Increasing Attacker Cost Using Immutable Infrastructure
#2I know the author is pitching the immutable infrastructure side, which definitely has its merits. But the ability to so easily diff the image and running state of a container also opens some intriguing opportunities for honeypot automation.
Are there any open source solutions that already take advantage of features like this? Or are those mostly kept secret for security and business reasons at this time?
Re: Increasing Attacker Cost Using Immutable Infrastructure
#3This is definitely one of the main reason we decided to this road for VMs as well at Boxfuse (https://boxfuse.com): minimal images (5 MB for a full VM with a Go application) and immutable infrastructure all the way.
Re: Increasing Attacker Cost Using Immutable Infrastructure
#4So I am confused, how does any of this increase attacker cost? Cant you do the same thing at the OS level already? Wouldn't making the dir read only do the same thing?
If your data gets stolen and your website defaced what's the use of immutability? I mean you can always run a diff tool against the current code on the server with the code you have on your repo right?
Re: Increasing Attacker Cost Using Immutable Infrastructure
#5It is not a good idea to restore attacker-owned applications to a "known good" state before you have done at least a cursory post mortem. Not only do are the security holes intact but since the attacker now knows they been found out, you can invite more serious damage.
The article tries to pitch read only Docker images some kind of solution, but running your applications read only (and what other permissions you grant your application) has nothing to do with Docker images. Using file system and process namespaces for application isolation is a good idea.
But lately it seems to be getting more popular to drop untrusted applications in containers (possibly even under outside control and full of who-knows-what) as if that somehow solves "security". The thing is, you still need to be able to reason about what permissions your respective application requires, there's no getting away from that.
Re: Increasing Attacker Cost Using Immutable Infrastructure
#6It is not a good idea to restore attacker-owned applications to a "known good" state before you have done at least a cursory post mortem. Not only do are the security holes intact but since the attacker now knows they been found out, you can invite more serious damage. The article tries to pitch read only Docker images some kind of solution, but running your applications read only (and what other permissions you gran…
Should probably just tiger-tree-hash your containers. If they deviate you give them a copy of your database, but it's a "virtual" shadow copy. No writes to it reflect on the real database.
Re: Increasing Attacker Cost Using Immutable Infrastructure
#7So I am confused, how does any of this increase attacker cost? Cant you do the same thing at the OS level already? Wouldn't making the dir read only do the same thing? If your data gets stolen and your website defaced what's the use of immutability? I mean you can always run a diff tool against the current code on the server with the code you have on your repo right?
it's pretty hard to diff filesystems that aren't designed for it. Either you need to lock the whole filesystem somehow - e.g. by taking it offline - or you have to deal with the fact that other processes are reading/writing as you scan the filesystem, which is rather difficult to reason about.
And it's not just about diffing your code with your repo - that only works if the attacker tried to attack your code. What about other running processes? New files on the system containing malicious code, outside of the paths you usually deploy code to? what about new, unexpected cron jobs?
Overall, it could become a pretty complex job. A filesystem with some intrinsic snapshotting makes this a lot easier.
Re: Increasing Attacker Cost Using Immutable Infrastructure
#8Docker is not (designed to be) a security technology. Yes, rolling back servers/VMs/containers to their previous state is a good capability to have (although most of us just use backups for that!), but assuming that an attacker cannot break out of a container is, at least, optimistic.
Re: Increasing Attacker Cost Using Immutable Infrastructure
#9I know the author is pitching the immutable infrastructure side, which definitely has its merits. But the ability to so easily diff the image and running state of a container also opens some intriguing opportunities for honeypot automation. Are there any open source solutions that already take advantage of features like this? Or are those mostly kept secret for security and business reasons at this time?
Intriguing indeed. Something like when a write happens, instead of just plain blocking it redirect the write to a honeypot environment and send out an alert. Sure, that won't fool a good attacker for a very long time, but would be interesting to capture various drive-by and skriptkiddie attacks.
Re: Increasing Attacker Cost Using Immutable Infrastructure
#10It is not a good idea to restore attacker-owned applications to a "known good" state before you have done at least a cursory post mortem. Not only do are the security holes intact but since the attacker now knows they been found out, you can invite more serious damage. The article tries to pitch read only Docker images some kind of solution, but running your applications read only (and what other permissions you gran…
> It is not a good idea to restore attacker-owned applications to a "known good" state before you have done at least a cursory post mortem. Not only do are the security holes intact but since the attacker now knows they been found out, you can invite more serious damage.
I would also add that attackers are actually after the data. Exploiting application vulnerabilities is just a mean to that end so bringing back exploitable application from the previous image is a BAD idea.
Having said that previous image can be a good starting point to patching up the vulnerabilities and bringing the application online.