My backend dev diary 📔✨

Notes on my journey learning to code & all things backend

I set up a Media Server with Urve Pi, Nginx, and a Dynu dynamic DNS (Part 2)

AMartin1987 | Published on: Oct. 11, 2025, 10:59 p.m.

Continuing from Part 1, in this section I focused on making the server secure with HTTPS and ensuring the site is safe and easy for my family to use.

Step 6: Enabling HTTPS with Let’s Encrypt and Nginx

To protect the connection, I enabled HTTPS using Let’s Encrypt. HTTPS is the secure version of HTTP, which means everything exchanged between the browser and the server (like login credentials, file listings, or media files) travels through an encrypted connection so nobody can intercept or alter it.

Let’s Encrypt is a free and trusted provider of SSL/TLS certificates, that is, the digital keys that allow a website to use HTTPS. Also, to make the setup easier, I used Certbot, a command-line tool that automatically requests, installs, and renews these certificates. Thanks to Certbot, I didn’t have to manually generate keys or configure complex files, because it runs a background service (a daemon) that handles everything.

After installing Certbot and connecting it to Nginx, I used it to issue a certificate for my domain. This created a set of files on the server containing the certificate and its private key. Then, I updated my Nginx configuration to point to those files and added a redirect from HTTP to HTTPS, so any unencrypted request is automatically sent to the secure version. Now, whenever someone visits the site, the browser shows the padlock icon, indicating that the connection is private and protected.

Step 7: Monitoring and Blocking Suspicious Connections

While trying to check what incoming connections my server was receiving, I learned to use some Linux and Nginx commands to inspect the logs. I started with tail -f /var/log/nginx/access.log to watch requests in real time, I checked the configuration with nginx -t, and soon discovered tools like ftop for live traffic stats and ngxtop for more detailed and colorful reports, which are even exportable to HTML so I could open them in a browser.

That’s when I noticed a lot of mysterious and persistent connection attempts from unknown sources. Some were clearly bots, some were just weird malformed requests. I got really curious about monitoring them and preventing unwanted access. An AI assistant suggested I install Fail2Ban and provided a configuration with different rules to automatically ban IPs showing various types of suspicious behavior, like repeated failed HTTP requests or exploit scanning.

Claude (my fav AI assistant so far) created a little script to watch Nginx logs and Fail2Ban activity in real time, with colors for easy spotting of errors, bans, and stats. Running this made it obvious that the server was under constant connection attempts from bots trying to find weaknesses.

For instance, one of the incoming requests looked like this in the logs:

93.174.93.12 - - [11/Oct/2025:20:53:26 +0000] "\x16\x03\x02\x01o\x01\x00\x01k\x03\x02RH\xC5\x1A#\xF7:N\xDF\xE2\xB4\x82/\xFF\x09T\x9F\xA7\xC4y\xB0h\xC6\x13\x8C\xA4\x1C=\x22\xE1\x1A\x98 \x84\xB4,\x85\xAFn\xE3Y\xBBbhl\xFF(=':\xA9\x82\xD9o\xC8\xA2\xD7\x93\x98\xB4\xEF\x80\xE5\xB9\x90\x00(\xC0" 400 157 "-" "-"

The AI assistant said that this is a malformed request. The server replied 400 Bad Request. Another clear example was this request:

134.199.152.171 - - [11/Oct/2025:21:28:35 +0000] "GET /.env HTTP/1.1" 301 169 "-" "Mozilla/5.0; Keydrop.io/1.0(onlyscans.com/about);"

Claude said the following about this attempt:

  • Goal of the attacker: Try to access the .env file.

  • Why it matters: .env files often store sensitive information like database credentials, API keys, passwords, access tokens, or secret configs.

  • Analysis:

    • IP: 134.199.152.171 (likely an automated bot)

    • Request: GET /.env – attempting to reach a configuration file

    • Response code: 301 (redirect) – your server redirected the request, probably from HTTP to HTTPS

    • User-Agent: "Mozilla/5.0; Keydrop.io/1.0(onlyscans.com/about);" – clearly a scanning bot

Are you protected? ✅ Yes:

  • The server responded with a redirect, not 200 OK or 403 Forbidden

  • The .env file is not in the public web directory

  • Nginx blocks files starting with a dot by default

Seeing all this in action really inspired my curiosity about cybersecurity these days. This is why I started reading “Linux Hardening in Hostile Networks” (by Kyle Rankin). The whole subject is amazing and it’s making me want to dive deeper into learning about securing servers and network defense in general.

Ale 💜🌿✨
 


PS. Look at my new ebook reader 😊 (amazing way to avoid doomscrolling on X every night, btw). I'm really happy with it because I got it really cheap on Wallapop, it's good as new and does exactly what I wanted it to do, and nothing else (It's a Woxter Scriba 150, a model from 2010). Also, it has a small wheel on the side that lets you scroll through pages very comfortably. I’m alternating between reading the Linux security book and the the third novel from R. A. Salvatore’s "The Legend of Drizzt (Sojourn)" which is absolutely gripping ⚔️


 

Categories:

 

Sysadmin  

About me
notByAI badge