All posts

Securing your own server – six ground rules from practice

Published on · 2 min read

  • Linux
  • Security
  • SSH
  • Firewall
  • Debian

A server on the internet gets scanned from the very first minute. You notice it the first time you look at the logs. Since I started running my own Linux server – with several websites, my own DNS and a mail server – security is no longer an add-on for me but part of every change. These are the ground rules I work by.

1. Everything closed by default

The firewall (UFW in my case) blocks incoming connections by default. Only what a service really needs is opened – and every new rule is a deliberate decision. One lesson along the way: Docker creates its own firewall rules and can bypass UFW. That is why I only publish container ports on the local interface.

2. Services only where they are needed

A database used only by applications on the same server does not need to be reachable from the internet. My databases listen locally only. What cannot be reached cannot be attacked.

3. SSH: key plus a second factor

Password logins alone are too weak. On my server, every SSH login requires a key and a time-based one-time code (TOTP). An emergency plan is essential: backup codes and access via the provider’s console – otherwise one mistake locks you out.

4. Automatic updates and brute-force protection

Security updates are installed automatically by unattended-upgrades. fail2ban blocks addresses that repeatedly fail to log in to SSH or mail.

5. Minimal permissions

The web server may read the website files – nothing more. The files belong to my user; the web server only has access through its group. If an application is compromised, it cannot modify its own code.

6. Encryption everywhere – and kept separate

Every website has its own TLS certificate from Let’s Encrypt with automatic renewal. Several domains used to share one certificate – when one of them went away, renewal failed for all of them. Separate certificates make the system more robust. For e-mail, SPF, DKIM, DMARC, MTA-STS and DANE are added, and the zone is signed with DNSSEC.

Conclusion

None of these measures is spectacular on its own. Security comes from the combination – and from the habit of checking every change before it goes live: test the configuration, then reload, then verify from the outside.

More about how the server is set up can be found in the project My own Linux server.