Maybe I have been lucky
I am using nginx now on top of centos for one site but the reverse proxy for example not using that.
I am on an Amazon EC2 in this particular case, also curious that Apache was also on there but only nginx is running. Had a long TTFB was trying to figure out what was wrong. Upon restart (new instance) I guess I got lucky, now back to regular site speed around 2 seconds load (full page).
Sorry rambling, cool stuff. Been on VPS, I guess EC2 is still the same thing but next would be serverless I guess.
I am a sysadmin with approx 15 years of experience running linux systems and open source software. When I set things up, I tend to form things my way. I usually have little resources for monitoring or staff, so automation is the best to do.
A server serves, it may produce errors and you can act upon that (error 404 for not finding phpmyadmin (which should _never_ be public => add ip to drop table). There are scripts that can do this for you.
However, the application which is being served, may produce different errors (failed login attempt, attempt for sql injection, cross site attack, ...). Some things are better logged by the application, Then the application needs to produce these logs. An awful lot of applications do nothing when presented with any of these type of attacks, making them extremely vulnerable. It's the dev's job to provide logging.
There are lots of possibilities.
For example: Only allow web connections through localhost and start an x session through ssh. This would require you to install a webbrowser though, so that's another security risk. Perhaps you could set up a VM with a dedi IP and only allow connections from there. (secure it well)
Another possibility would be to first pass a reverse proxy that will request a client-side certificate. That'd make it pretty secure.
A password protected directory is just asking for a brute force through a botnet. Your failtoban won't even block anything because the attacker would only let 1 host attempt a password once per 30 min or per hour. But if he has thousands of bots to his disposal, he can still bruteforce a couple times a second.
That's OK you say. I have a strong password. Don't forget: Each connection and failed login attempts is logged. Your logfile will quickly grow. If you did not set a seperate VAR partition on your disk, your root disk will quickly get full and server will crash. Additionally, it will fill up your bandwith and be as effective as a ddos attack.
Don't use passwords. Use certificates. easier for you, impossible to hack.
There are other methods of course, but these would be my preferred methods. Setting phpmyadmin publically is asking to get your data stolen. Do not assume there are not exploits in the latest phpmyadmin. But don't forget to update it within the first 10 minutes when a security patch comes along, otherwise your data may well already be compromised.
using certificates is getting advanced. Here you'll allow the server to request a client certificate from the visitor. The visitor will have to supply the certificate (which is 4096b if you take security serious).
It requires quite a bit of steps, but is as secure as it gets what web access is concerned.
You should not be surprised to see 15k+ failed login attempts on ssh with popular ISP's. As I said, a system is the most vulnerable when it has just been installed and a/the default root password has not yet been changed.
Simply disallow password login on ssh, change the port and only allow non-root users you need to allow.
I have on my systems only 1 user allowed to login, authenticated by a 4096b key. There is no way an attacker can use ssh if not using an ssh exploit. The system is updated automatically every hour. This way known exploits are very quickly taken care of.
For me, server security has been a practice over many years and it takes many years to perfect your 'secure server setup'. It's depressing how many companies do not adhere good security practices and just leave their systems unprotected.
Especially mail servers.
Also curious as to why Ubuntu isn't suitable for production.