Best way to secure SSH?

[lewis-teck]

I have recently had a huge attack from China against my servers SSH services. I get emails every time I someone gets blocked for 5 failed attempts from ConfigServer's Firewall... and over Christmas it ramped up from a few times a day to several an hour, and my mailbox is now full with almost 100 of these emails. I know I can disable the emails but no need now as the attack seems to have stopped. It also doesn't seem to be any form of DDOS attack, just brute forcing with a regular change of IPs.

I'm not an SSH person. I log in and use it but only from a cheat sheet of commands I've built up over time. I have protected my cPanel logins with cPHult to block all countries but mine and US (where BuycPanel's support comes from) because I don't need any countries logging in... and the WHM interface has 2FA enabled... but correct me if I'm wrong, if someone gets the password, can't they just log in to SSH without any form of country or 2FA protection? At least I can login at home.

I believe I can turn off the password feature and use keys instead but I would prefer not. IP whitelisting my own IPs is also an option but I don't want to risk getting myself locked out. What's the next best option for securing SSH? I have a very secure password but it would be neive to say there's no risk.

Thanks!

 

[GOT]

Just close the port in the firewall and only whitelist ips that actually need access.

 

[cPanelHB]

Hello,

correct me if I'm wrong, if someone gets the password, can't they just log in to SSH without any form of country or 2FA protection? At least I can login at home.

SSH logins will bypass your WHM/cPanel 2FA settings but not the cPhulkd country blocks. They will still end up blocked even with the correct password. If they use key-based authentication, cPhulkd should not block them, though.

I believe I can turn off the password feature and use keys instead but I would prefer not. IP whitelisting my own IPs is also an option but I don't want to risk getting myself locked out. What's the next best option for securing SSH?

SSH brute force attacks are pervasive.
Switching to key-based authentication is the best solution, but I understand you may be hesitant. I have seen many people accidentally lock themselves out of SSH when doing this without properly configuring keys first (or losing their key later).

However, if you want something slightly lower risk, you can change your SSH port to something non-standard. It won't stop a persistent attacker (they can scan and find the new port, and then attack that). However, it will prevent the vast majority of login attempts. Most of the automated bots just attack everything with port 22 open; it's probably not worth the effort for them to scan all the other ports.

 

[quietFinn]

I would suggest that you permit root logins in SSHD config.

1st create a new user in SSH command line:
adduser USERNAME
(USERNAME is the user you want to add)

then set the password:
passwd USERNAME

Add that user to the Wheel Goup in WHM -> Security Center -> Manage Wheel Group Users

Test that you can login with that user name, and when logged in you su to root, command
su -
and give root password.

When you know it works you permit root login in /etc/ssh/sshd_config, set
PermitRootLogin no
and restart SSHD
service sshd restart

After that nobody can login in SSH as root, and only users in the wheel group can su to root.

 

[lewis-teck]

Just close the port in the firewall and only whitelist ips that actually need access.

I may consider this in the future, but I do not want to risk getting locked out or not being able to access it on my mobile phone which has a dynamic and frequently changing IP address.

Hello,



SSH logins will bypass your WHM/cPanel 2FA settings but not the cPhulkd country blocks. They will still end up blocked even with the correct password. If they use key-based authentication, cPhulkd should not block them, though.



SSH brute force attacks are pervasive.
Switching to key-based authentication is the best solution, but I understand you may be hesitant. I have seen many people accidentally lock themselves out of SSH when doing this without properly configuring keys first (or losing their key later).

However, if you want something slightly lower risk, you can change your SSH port to something non-standard. It won't stop a persistent attacker (they can scan and find the new port, and then attack that). However, it will prevent the vast majority of login attempts. Most of the automated bots just attack everything with port 22 open; it's probably not worth the effort for them to scan all the other ports.

Thank you for the information, especially on CPHulk which was good to know, I thought it only applied to logins via the web. That is good that logins from those other countries will be blocked, with only 2 countries needing access, that's probably 95% of the failed attempts that will be blocked by country anyway.

With my inexperince of SSH, I am hesitatant to move to keys. I should probably explore this option in the future but I will need to do extensive research to satisfy myself that I won't lock myself out and understand the keys system, which frankly I don't at the moment.

One thing I didn't consider was your port suggestion, which was fantastic and I have now implemented. Such an easy change that, like you say, will block out most automated attacks that look for defaults. Thankfully I am familiar enough with CSF to change the port settings and not lock myself out from a port change, thank you for the suggestion, definitely the easiest way to bump up security without too much compromise or learning curve.

I would suggest that you permit root logins in SSHD config.

1st create a new user in SSH command line:
adduser USERNAME
(USERNAME is the user you want to add)

then set the password:
passwd USERNAME

Add that user to the Wheel Goup in WHM -> Security Center -> Manage Wheel Group Users

Test that you can login with that user name, and when logged in you su to root, command
su -
and give root password.

When you know it works you permit root login in /etc/ssh/sshd_config, set
PermitRootLogin no
and restart SSHD
service sshd restart

After that nobody can login in SSH as root, and only users in the wheel group can su to root.

Interesting, I've seen that Wheel option but never understood it's purpose so just kind of looked over it. Unfortunately when it asks for the password, it doesn't seem to accept the root password. When I can figure out why, this will definitely be a great option to consider, which like changing the port, helps to enhance security but not enhance the chances that my noob fingers get myself locked out until I can understand keys or consider an IP whitelist.

Thank you all for your suggestions!

 

[quietFinn]

Interesting, I've seen that Wheel option but never understood it's purpose so just kind of looked over it. Unfortunately when it asks for the password, it doesn't seem to accept the root password. When I can figure out why...

If you added the USERNAME to the wheel group while you had SSH connection with USERNAME, you must log out and log in again, then you can su to root.

 

[weetabix]

Just do what quietfinn said, you could also set PermitRootLogin to without-password if you want to be able to login with key as well as doing a su to root.

You shouldn't worry too much about the bruteforce attacks unless they are impacting your servers performance. CSF is blocking them for you and it seem to work as intended. Make sure you have strong passwords and maintain a high degree of security on the devices you are connecting from.

 

[keat63]

Host Access Control should perform what you require.
Just make sure that you leave yourself a few backdoors in case your IP address changes.

https://documentation.cpanel.net/display/68Docs/Host+Access+Control

 

[lewis-teck]

I never came back to reply to my thread here, so I'd just like to say thanks for all of the suggestions.

I changed the port of my small server simply to number 10, allowed it in the firewall, and I haven't had a single failed attempt in the 4 or 5 months since the change. Nothing.

Easy change that flew over my head before making this thread, yet the most effective way to cut out bots for my server with practically zero compromise!