[xorcist]

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.

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.

[feld]

The invention of containers (FreeBSD jails) was to automate restoring vulnerable web apps that couldn't be patched / updated (edit: as well as allowing shared hosting with different perl requirements to co-exist on the same server) Every time tampering was detected they automated restoration and watched the attacker squirm as their changes kept reverting and files were disappearing.

Don't dismiss this concept. It's a perfectly valid approach in some scenarios.

[drieddust]

> 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.

[ris]

> I would also add that attackers are actually after the data.

Not strictly true - depending on the parties it's still a very desirable goal to be able to snoop on a site's continued operations, inject some code into visitors' pages, or just have a platform for further attacks.

[wepple]

I agree that rolling back an image to a "known good" state is not the appropriate solution; if you can do it efficiently, what's stopping you from doing it very regularly?

Attacking a system that disappears and restarts on a regular basis is a nightmare for current attackers; it's not something that they have the tooling to deal with yet.

I believe some of these ideas were discussed by Dino Dai Zovi in a talk[1] he did which combined a whole bunch of rather out of the box ideas on defense.

[1] https://www.youtube.com/watch?v=_A6Y62AcQ2g

[hodgesrm]

I'm not sure I understand the argument against reverting state. If you are cleaning up any sort of mess--including getting hacked--it's vastly easier to start with a good before-things-got-messed up state. This is one of the reasons people buy expensive storage arrays that support fast snapshot reversion.

Also, the author is arguing fix now but preserve all information for fault diagnosis later. For a lot of problems that seems like exactly the right choice.

[Senji]

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.

[toomuchtodo]

If attackers get your database, you lose. Containers don't fix application vulnerability mitigation and leaking data.