I want to second this point.
Any open ssh server will get pounded constantly from all sorts of random places. So, I suggest, at the very least, something like sshguard, Fail2Ban, or DenyHosts. These are often available in the standard repos and the default configs are a quick and easy thing to put in place.
Also: Disable password authentication, if you can (look into ssh keypairs), and if you can, allow only known IPs in to your server. Though, that can be tricky, especially if you're mobile.
And most importantly, make sure that box is always updated.
I forgot to add that you need to take precautions when exposing services to the public. I'm not sure what your exact plans are but botnets and unsavory folk will find your exposed service and try to brute force their way into it.
For example, I run an SSH server on another raspberry PI and I'm using SSH Guard to detect and block brute force SSH attacks.
Do your homework and take all the necessary security measures.
sshguard is another great option, and works with many different firewalls as backends. Like fail2ban, it can also monitor login attempts for several services, not just ssh.
Wow, that's a huge system to be managing! I think it's a bit outside the scope I expect from r/selfhosted lol :P
Your reasoning does make sense.
> It does not, however, natively protect from brute force attacks
True, but https://www.sshguard.net/
Ah, I see. Looks like according to the documentation, it supports a number of other programs - but I think it's configured to do just SSH out-of-the-box (though I can't be sure. I should really take some time to read the docs thoroughly sometime :P
Great guide!
I love the "why" that you have going on here.
One suggestion: I'd recommend SSHGuard over fail2ban though, as it's much more stable & easier to configure (read: no configuration at all IIRC!).
I find SSHGuard easier to setup & use then fail2ban.
While Cloudflare does provide DDOS protection, it's important to note that this won't protect your real server's IP from attack directly.
It's also worth noting that if you're going to use Cloudflare, you may not need a web-application-firewall (WAF), as Cloudflare has one built-in already.
It all depends what you're trying to do. For example, I run a personal website on a box that I rent from KimSufi. Since it's only a personal website, I haven't bothered with a WAF or Cloudflare, as I feel it's unnecessary.
I think you might be somewhat confused where you say
> running app only from user, not from system-wide webserver (no default pathes like /var/www/html) and no system-wide users like www-data
A web server listens on a particular TCP port. Ports are defined at host-level - i.e. only 1 application on a system can listen on TCP port 443 at a time. This can only be circumvented if you run either a) a virtual machine or b) a container (like LXC or Docker). These solutions have their own internal IP address, so a process can listen on port 443 inside the VM or container. Doing that means you'd need to use port-forwarding to allow incoming connections on the host system to be passed through to the guest.
With the users, the same thing applies. A user account on a standard Linux machine is system-wide. As far as I'm aware, you should use a different username for each service - i.e. www-data
for the web server, vmail
for the mail server, etc. As for SSH, I recommend disabling root login and creating a new user account with sudo
privileges.
As with the port issue, you can use containers or VMs to circumvent this - but such solutions add additional complexity to the system, which makes it more difficult to secure - which defeats your initial purpose!
sshguard is written in C and functions similarly to fail2ban. I'm confused why people assume I take no further precautions when I mention disabling password authentication.