Security recommendation

Running an own server implies strictly stat you inform yourself about general security vulnerabilities and options to protect your network, server and data.

General

Attackers can access your machine via network protocols and ports that are opened or forwarded to your server machine. Most users will have a router to access the www through. In such case it is about the router and its internal firewall to block incoming connections and forward them to the internal network machines. When your server is attached to the www directly, then it MUST have an own firewall active to handle this.

When having a router in front of your local network

• Assure that ONLY those ports are forwarded to the server, that you absolutely require.
• Enable all firewall and security features. This should be the case by default on modern routers + their OS.

When having your machine attached directly to the www

• Install iptables (or nftables as the modern replacement, or BPFilter as the upcoming most modern firewall implementation)
• Use it to block all incoming connections by default. Allow connections only on required ports and protocols.
• Avoid using any software based firewalls. iptables/nftables will use the Linux kernel internal mechanism, which is strongly recommended.

SSH

• SSH is enabled by default on DietPi systems on port 22 with root user login permissions.
• It is strongly advised to change the root user password, as you are asked to on first boot/first run setup.
• Use a strong password far away from any of the most used passwords: https://en.wikipedia.org/wiki/List_of_the_most_common_passwords
• At best further enhance security by using key authentication instead of user/password authentication.

Opening SSH from www

• You should only open SSH to www, if you strongly require it.
• If you open SSH to www, install fail2ban via dietpi-software. It is configured by default to block IPs that fail to connect too often via SSH.
• Most secure solution is to not forward the SSH port directly from your router. Instead, use a VPN server (OpenVPN or WireGuard) on your machine. Forward incoming VPN connections and connect to SSH only via VPN.
• Second secure solution is, when having key authentication enabled, to not forward external port 22, but use a different random port and forward it to internal port 22 by the router. The reason is that port 22 is a typical target for brute-force attacks. So you would face many failing SSH connection attempts, done by bots that randomly try to connect with often used user account names (especially root) with a list of commonly/most used passwords.
• Anything below the above security is not recommended, when opening SSH to the web!
• It is advised as well to disable root user login for your SSH server (optionally for the whole system, if you are okay to use sudo on a regular basis for maintenance tasks). Similar to how port 22 is the most used brute-force attack target, root is the most attempted login user. You can do this with Dropbear by setting DROPBEAR_EXTRA_ARGS='-w' in /etc/default/dropbear, and with OpenSSH by setting PermitRootLogin=no in /etc/ssh/sshd_config.

HTTPS/TLS

• When you need to access a website or web application from outside your local network (outside of VPN), always enable and force HTTPS respectively TLS connections.
• For webserver-based websites (accessible via port 80), use e.g. dietpi-letsencrypt to have HTTPS enabled on your webserver. Configure HTTPS redirection and at best HSTS as well.
• For other web applications that run their own internal web interface (accessible via different port than 80), read it's documentation about how to enable HTTPS. You can use the same certificate that is used with the webserver. But note that you rely on the security of their HTTPS implementation which is at least not as well proven as it is for commonly used webservers like Apache, Nginx or Lighttpd.

System updates

• Keep your system up-to-date by regularly updating DietPi and your APT packages: G_AGUP && G_AGUG (error handled and non-interactive wrappers for: apt update && apt upgrade)
• Also regularly update your kernel packages. In most cases that requires: apt full-upgrade (or G_AGDUG, but be careful since this will not ask you to confirm, even if incompatible packages are purged!)