Blocking All SSH / Reccurring Hacks

[easyprosys]

I have been running Plesk web hosting for years behind a firewall appliance. Before that we were rooted often enough. Now we've added cPanel and almost instantly 100/100 strong passwords are hacked. cPanel knows nothing We installed APF/BFD and they got right around it. We installed CSF and they got around it because we had not blocked SSH. We seem to think that they are getting in from cPanel. Maybe not. We're running Centos 7.2 with OpenVZ containers now with CSF in each container. I've got to reinstall everything. :-(

How do I add a command in CSF command line to block all SSH and Telnet? We'll add exceptions to the Allowed file.

I miss having a hardware firewall but it isn't in the cards at the moment. Any suggestions are very welcome. I didn't even get a chance to work on Mod_Sec, if it would have stopped the entry. How the heck can they get in so quick? For reference here's where were at:

Code: Select all

Linux ***** 3.10.0-229.7.2.vz7.9.22 #1 SMP Thu Jan 14 18:21:17 MSK 2016 x86_64 x86_64 x86_64 GNU/Linux

Thank you for your help.

[Pietro Aretino]

First of all, if you DON'T need a service, like SSH, blocking it is silly. Just REMOVE it entirely. Uninstall SSH altogether if no one is accessing the servers that way. In fact, you should highly consider setting up a DENY ALL policy in your iptables, and then ONLY allowing the services/ports you require.

If you do need SSH, make sure you're utilizing SSH v2 and if you're getting hacked all the time regardless, make sure,
A) They don't have root access elsewhere on your server, that allows them to manipulate change SSH configuration files
B) If A has been checked and all is well, remove PAM from SSH and setup private-public keys that are stored elsewhere, like on your work desktops or laptops inside encrypted files/folders. That way they can't brute-force attack your server because SSH won't even accept regular linux/unix password authentication.
C) To go above and beyond, remove ROOT login via SSH altogether. Setup a user account with extremely limited privileges, use that for SSH login via public-private key, and once you are inside your server, then escalate up to your Root account when needed. Your passwords should be 12+ character long, alpha-numeric-symbolic passwords with no redundancy or logic, completely random.
D) Make sure you're not somehow storing passwords in the clear-text on your server, especially if you're running databases. All passwords should be hashed with SHA-256 or 512. If you're hashing crap with SHA-1 still, you're in for a world of hurt.