[jonssons]

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.

Debian: fine if you like pain :) it's stable.

[ge96]

How do you make PHPMyAdmin not public aside from say using one of those directory passwords.

Also it is somewhat of a similar question as to how Git is public but private.(Not GitHub your own setup)

[jonssons]

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.

[ge96]

Oh man I feel so dumb, you know despite what I can do. I guess that's the problem of trying to do everything you can only get so deep.

Use certificates? What is that not keypairs?

I logged into this Digital Ocean droplet and was surprised to see 15,000+ failed login attempts to SSH. I hadn't seen that before.

I don't know if using PHPMyAdmin is noobish. I still primarily use MySQL/Maria (only).

Thanks for the tips. I learn a lot though HN.

[jonssons]

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).

Easy (read easier) to do with nginx: https://www.google.de/search?q=nginx+client+side+certificate...

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.