Topic
#Nginx
Loot, blog posts and adjacent themes connected to this topic. Follow the tag to keep it in your orbit.
Loot
More from this topic
#Server Security#Linux Admin#SSH Hardening#Fail2Ban#Nginx#Deployment Checklist
A practical workflow that combines SSH hardening, UFW firewall configuration, Fail2Ban, non-root deployment practices, and Nginx setup into one server launch kit. For Linux admins and deployments needing a cohesive security checklist for initial server setup. If your app is clean but your server is weak, your launch is still exposed. This paid Loot gives you a practical hardening workflow you can apply before go-live on a small VPS or production box. It is designed for builders who want a clear sequence, copy-pasteable examples, and a verification checklist instead of vague security advice. What is inside A go-live hardening order that prevents common self-inflicted mistakes SSH lock-down guidance with key-based access and root-login restrictions A minimal firewall policy for public app servers Fail2Ban setup notes to reduce brute-force noise Safer deployment guidance so your app does not run as root An Nginx reverse proxy baseline with HTTPS and upstream separation A final verification checklist you can run before launch The 5-layer hardening sequence 1) Lock down SSH before you expose anything else Your SSH configuration is the front door to the box. If you still allow password login and root login, brute-force attempts will find you quickly on a public IP. Baseline goal: Use SSH keys only Disable direct root login Keep one verified admin user with sudo access Example flow: Important settings to check: Reload carefully: Do not close your current session until you confirm a second SSH login works with your key. 2) Add a firewall that defaults to deny A public server should not expose every listening service. The simplest win is a firewall policy that only allows the few ports your app actually needs. Typical public web app policy: Allow 22 only for SSH Allow 80 and 443 for web traffic Deny everything else Example with UFW: If your database does not need public internet access, do not open its port. Internal-only services should stay internal. 3) Install Fail2Ban to cut down repeated login abuse Fail2Ban will not make a weak server secure on its own, but it is a cheap and useful friction layer. It watches logs and temporarily bans IPs that keep failing. Minimal setup: Basic jail example: Create it via /etc/fail2ban/jail.local, then restart: 4) Never run the app as root If an attacker lands inside your application process and that process runs as root, the blast radius becomes the whole system. Keep runtime privileges narrow. Baseline goal: App runs as its own user App files are owned by that user System services are restricted where possible Example user + directory ownership: Example systemd service: That single change removes a huge amount of unnecessary risk. 5) Put Nginx in front of the app A reverse proxy gives you one clean public edge. It handles TLS, forwards requests to the internal app port, and keeps your runtime less exposed. Minimal Nginx idea: Nginx listens on 80/443 Your app listens on localhost only Nginx proxies to the app Example server block: Once the proxy works, add TLS with your preferred certificate flow, then redirect HTTP to HTTPS. Pre-launch verification checklist Use this quick pass before you announce the product or point real traffic to it: [ ] I can log in with SSH keys from a second terminal [ ] Root login is disabled [ ] Password authentication is disabled [ ] Firewall only exposes required ports [ ] Fail2Ban is installed and the sshd jail is active [ ] The app runs as a dedicated non-root user [ ] The app is not publicly exposed on a random high port [ ] Nginx sits in front of the app [ ] TLS is enabled or scheduled before public launch [ ] I have a rollback path before changing SSH settings Common mistakes this Loot helps you avoid Locking yourself out by disabling SSH access before testing a second session Leaving a database port open to the internet Running the web app as root because it felt convenient Exposing the application port directly and skipping a reverse proxy Treating Fail2Ban as a substitute for real access control Best use case Use this as your lightweight go-live SOP before a launch, migration, or fresh VPS setup. If you want the shortest version: fix SSH, reduce exposed ports, add login-abuse friction, drop root privileges, and put a proper public edge in front of the app. Those basics will not make your server invincible, but they will eliminate a lot of avoidable risk fast.
Blog