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

3 points·bsaunder··5 comments

Hoping to create a discussion here on ideas on how to defend against the current bash RCE. Probably just a subset of existing "best practices" 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/down individually rather than as a set.

View on HN

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.

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.

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.

1. Patch or otherwise fix Bash.

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

Make sure tripwire is installed/configured/monitored.

Watch for unexpected changes to public servers.

Reply on news.ycombinator.com