A few months ago, I had a blog post about how bad actors are using Certificate registration requests to immediately go to your new web site and try to hack it before it is fully up and properly protected. One of the fixes I suggested at the time was to protect the new site with Basic Web Authentication, i.e. a username and a password, before bringing it up for the first time. Recently, I revisited the topic because I wanted to password protect an Etherpad-lite instance to limit its use to authorized users. Etherpad-lite makes it really hard to have usernames and passwords, and I have to say, I gave up on finding out how it works. So let’s kill two birds with one stone and figure out how to use Basic Web Authentication directly on the Nginx reverse proxy I use on my cloud installation. It turned out it’s super simple to do:
For most of my web projects that I access over https and a domain name, I use Evert Ramos’ reverse Nginx proxy / Letsencrypt container setup. It’s open source and can be installed in 60 seconds with 3 shell commands. Password protecting one or more of the websites behind it is easy enough as well. In the proxy directory, there is a ‘data/htpassword‘ directory in which configuration files for usernames and passwords for individual websites can be created. Here are the 3 shell commands required to create a username and password combination for a website served by the proxy:
sudo sh -c "echo -n 'martin:' >> ./data/htpasswd/my.website.com"
sudo sh -c "openssl passwd -apr1 >> ./data/htpasswd/my.website.com"
docker-compose down; docker-compose up -d
The commands add user ‘martin‘ with a password to that is requested on the shell by the openssl command for the website ‘my.website.com‘. That’s the first two commands. The docker-compose command at the end restarts the proxy containers. The official documentation uses an nginx reload command for that, but that didn’t work for me. So while shutting down the docker containers of the proxy and starting new instances result in a short outage for all websites behind the proxy, it does do its job.
Also nifty: The commands above create or a append to text files, so removing users later on is as simple as removing the user’s configuration line from the file and restarting the reverse proxy containers.
Thanks Evert, just what I needed!