How-Tos

How-To: Web Server Quick Wins a Read-Only Audit Will Find

Leave a comment

A careful read-only audit of a web server almost always turns up the same handful of things. None of them are fancy, and all of them are easy to fix. My earlier post covers hardening a new Linux server. This one is about the web layer.

1. Hidden folders like .git

If your site was deployed from a git checkout, /.git/ may be downloadable, and with it your whole history. Test it:

curl -sI https://example.com/.git/HEAD     # want 403 or 404, never 200

Block dot-directories in Apache:

<DirectoryMatch "/\.(git|svn|hg)">
    Require all denied
</DirectoryMatch>

If it was ever exposed, treat every secret that was ever in that repo as leaked. Rotate database passwords, app salts and API keys.

2. Directory listings and ~user folders

Old Apache defaults can leave mod_userdir and autoindex on, so /~someuser/ lists files for the world. Turn them off unless you really use them:

sudo a2dismod userdir autoindex
# or, per site:  Options -Indexes
sudo apachectl configtest && sudo systemctl reload apache2

3. Backups and database dumps lying around

Pre-upgrade dumps tend to get left behind, readable by everyone on the box or, worse, inside the web root. Find them:

sudo find / -xdev \( -name '*.sql' -o -name '*.sql.gz' \) -perm -o+r 2>/dev/null

Then chmod 600 them, or better, move them off the server.

4. sudo rules that are secretly root

A NOPASSWD rule for something like chown, chmod, cp or tar is as good as full root, because the user can take ownership of any file. Check with sudo -l -U <user>. Remove those lines, or point them at one small wrapper script with fixed arguments, and always edit with visudo so a typo can’t lock you out.

5. WordPress user enumeration

By default, /?author=1 and the REST users endpoint can reveal login names. Block or redirect author archives and restrict the users endpoint to logged-in users, so attackers only have half of the login to guess.

The process matters

Audit read-only first so nothing breaks while you look. Then fix one item at a time, back up first, and re-test with the same command that found the problem.

Have a blessed day! And Happy Hacking!

References & Further Reading

Subscribe (RSS) Follow How-Tos via RSS

Leave a note

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.