

Ask HN: Good ideas to defend against the bash RCE? - bsaunder

Hoping to create a discussion here on ideas on how to defend against the current bash RCE.  Probably just a subset of existing &quot;best practices&quot; that are particularly relevant for the current attack vector for the bash RCE.  Recommend keeping posts to one recommendation per post so that the best can filter up&#x2F;down individually rather than as a set.
======
tptacek
Suggestions to lock down applications to least privileges and to set up
monitoring on servers are a good idea, but they're not going to help that much
here. You should operate under the assumption that an attacker who gets any
code exec on your machine under any uid is going to have root, usually
milliseconds later.

------
bsaunder
Run externally accessible applications under a user id with no login and no
ownership of the application files it's running. Make sure that the euid of
the process can only write to the specific areas of the system that are
absolutely necessary. This would help quarantine the system impact of remote
code execution like this.

------
bsaunder
Block outbound request from publicly accessible servers (or white list them if
necessary).

This would make it harder for attackers to fetch/install more tools.

------
wglb
1\. Patch or otherwise fix Bash.

2\. Understand the chain of how environment variable values might flow through
your web stack. Eliminate them.

------
bsaunder
Make sure tripwire is installed/configured/monitored.

Watch for unexpected changes to public servers.

