On SSH Security... am I being a helicopter admin?

[jlpeifer]

Semi-Newbie, first-time poster here...

I manage a linux server that faces the public Internet. Every day there are thousands-upon-thousands of SSH login attempts on the "root" account (40,000 in the last several days). Within that sample are about 600 unique IPs that are attempting to brute-force my root account. Most of these IPs are on separate subnets. Almost all of the IPs are from outside my country (U.S.).

For various reasons I have chosen not to disable SSH login on this server. I have changed the default SSH port, but know that this is a relatively futile masquerade for someone who's hell-bent on hacking into the host.

I've attempted various methods at thwarting brute-force attacks via IPTABLES and CSF, but given the sheer magnitude of IPs and associated subnets from which the login attempts are coming I've found my efforts to be futile.

The password for the root account is semi-complex using UPPERCASE, lowercase, numbers, and symbol characters. It would not be included in any dictionaries. A hacker would need to attempt a maximum of 6,704,780,954,517,120 password combinations before a successful login. Websites that calculate such things tell me that it could take several centuries for someone to brute-force my root password.

So my questions, finally, are...

1. Do I actually have a need to be concerned about all these attempts at hacking 'root', or can I pretty much ignore them considering the sheer magnitude/time it would take to successfully guess the password?
2. By leaving my server open to SSH login attempts, what other problems/downsides am I potentially not considering (like additional server load)?
3. What are recommended ways to limit SSH logins to specific geographies/countries?

Many thanks!
Joe

 

[UnixSH]

Hey,

1. Firstly, the root account shouldn't be available directly.... (use an other account without privileges, and use sudo)
3. For the SSH login limit, if I were you, use SSH key rather passwords. Also, you eventually can restrict the SSH access only for you IP, you should be able to edit in /etc/hosts.allow

 

[f33dm3bits]

I would disable being able to login as root through ssh by configuring PermitRootLogin prohibit-password.
How are the normal users logging in? You could choose to disable password authentication for ssh and then only allow publickey authentication.
1. I would be since they are bruteforce attempts. You can install fail2ban, then set it up to scan your authentication log files to scan for ssh login attempts and if it finds a failed login within a specified amount of time it will ban/block the ip through firewall rules from being able to access the ssh port.
2. No idea, since you haven't shared your hardware specifications and what you are running on the server and how many users are using the server.
3. You could write a script to automatically update your firewall rules to allow the ip from ip blocks from specific countries by using the information provided by ipdeny.com.

 

[jlpeifer]

Thanks for your replies. Again, I'll reiterate that I'm not fluent with linux, so please lend your patience with the following...

I did some research and found some articles explaining how to create a new user and add them to sudo users. Problem is... I don't think sudo is even currently an option on this host.

-bash: sudo: command not found

My goal here is to:

1. Add a 'newuser' to the system
2. Grant 'newuser' admin rights
3. Confirm SSH/SFTP access for 'newuser'
4. Maintain certificate-based SSH/SFTP authentication for 'root', and disable password authentication for same

Is my first move here to install sudo? If so, are there any negative ramifications aside from having to add 'sudo' in front of every command I want to issue?

 

[f33dm3bits]

What distribution are you running?
1. usually: useradd username
2. usermod -aG wheel/sudo username (The group depends on the distribution)
I think you may want to switch 3 and 4 around.
3. Configure
- sshd_config: PermitRootLogin no and PasswordAuthentication no (Restart sshd after making a change to the configuration)
- How to configure ssh Key based authentication
4. Check if the user can login with their sshkeys.

 

[jlpeifer]

Thanks @f33dm3bits

This host is using Debian 9

I already did steps 1 & 2 of your instruction however instead of using...

usermod -aG wheel/sudo username

I used this instead...

usermod -aG sudo username

The user is able to log in via SSH but isn't able to do much of anything. Once logged in as the user via SSH any attempt to issue a command prefixed with sudo is met with the following error...

-bash: sudo: command not found

 

[f33dm3bits]

You may need to install the sudo command, switch to the root user and then install.

apt install sudo

 

[jlpeifer]

So I installed sudo and now face an inconvenience. I use FileZilla to up/download files to the server. When logged in as a sudo-enabled user my actions are restricted because.... sudo.

There appear to be work-arounds, but they create additional steps that involve moving files into directories that are readable by non-root user, then using SSH and sudo, manipulating those files on the server. The annoying downside of this is that it adds complexity and burden to workflow.

This all brings me back to the #1 and #2 questions of my original post. Let's say I change the root password to something insane.... 128 random alphanumsymbolic characters. There's just no way that someone is going to guess that PW. Yes, I'll have to copy/paste it when I need to use it, but that involves much less effort than the roadblocks sudo is going to create.

Please give me your honest assessment and tell my why I don't want to do this.

 

[f33dm3bits]

Your actions aren't restricted because of sudo, you can't use sudo from within filezilla or any other ftp client because ftp clients don't support sudo so for you the sudo setup doesn't work in your setup. Instead you you could do the following which is still safer than allowing authentication by password for the root user. In sshd_config change PermitRootLogin no to PermitRootLogin prohibit-password then restart sshd, then on your machine where you are connecting from generate a private and public sshkey. Then add that public key to /root/.ssh/authorized_keys and then you should be able to directly login to the account of the root user using ssh keys even with an ftp client.
I see this as a workaround as well because if you have the locations where you are uploading/downloading your files to/from setup correctly with permissions you wouldn't need the root user account or sudo privileges to access the files. I would never use password authentication from for ssh since passwords can be bruteforced eventually, with ssh key authentication you would need the privatekey (and the passphrase if you used one) which is alot safer than password authtication. You could also setup two-factor authentication for ssh but I doubt that any ftp client would support that either.

 

[jlpeifer]

@f33dm3bits ... this has been extremely helpful. Many, many thanks! I have followed your guidance and have verified that the 'root' account is excluded from logging in with simple password authentication. Cert-based login is working like a charm for console and FileZilla. Sudo is working great for sudoers as well. Gracias!

 

[f33dm3bits]

@jlpeifer Glad to have helped out!

 

[jlpeifer]

@f33dm3bits ... it's been a couple of days since I implemented the changes you suggested. The maddening crush of 'root' login attempts have almost entirely stopped. I assume the bots or their maintainers realized things had changed and they've backed away. There are still lots of attempts using randomly selected usernames, but this isn't nearly as much of a concern. Again, thank you for your guidance.

 

[f33dm3bits]

@jlpeifer
Have a look at fail2ban you can set it up to have it scan your ssh log file for failed authentication attempts and then it will ban/block that ip for configured amount of time if it's found X time within a configured range of time.