I travel for a living. I log near 3000 miles per week via America’s highways and Interstates. My travel companion is my new Toshiba A105-S4284 laptop running Fedora Core 6.
Consequently I connect to the internet from various travel locations with WiFi access using various different providors. I was amazed to find my logs filled with dictionary attacks on my sshd service.
Have a look at your logs (tail -n 10000 /var/log/secure | grep “password”) and then tighten up your sshd.
The default configuration is a little weak in my opinion. I only need to ssh into my laptop when I am at home and the laptop is charging (I have a desktop machine I use while at home).
So let’s tighten up ssh a little more than what is provided by the default installation.
First let’s create an optional Banner file. Although this isn’t required the man page for sshd_config has this entry:
In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. The contents of the specified file are sent to the remote user before authentication is allowed. This option is only available for protocol version 2. By default, no banner is displayed.
So we’ll go ahead and create the banner. Just create the file /etc/ssh/banner and edit it to include a warning message. Something like “Authorized users only” or whatever you feel is appropriate for your situation.
Finally lets edit /etc/ssh/sshd_config as root and make a few customizations to tighten it up a little.
Make sure these are uncommented or entered if not present in the file:
Specifies the port number that sshd listens on. The default is 22. Often changed to a non-standard port to dodge common script based attacks.
Specifies the protocol versions sshd supports. Protocol 1 should not be used as it is obsolete and vulnerable to “man-in-the-middle” attacks.
If this option is set to “no” root is not allowed to login. Admin should login as a regular user and sudo or su instead. The root user should never be permitted to login directly via ssh.
When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings. User accounts could be created with no passwords. This would block those types of accounts from logging in via ssh.
AllowUsers user1 user2
Tightens up ssh to allow only specific users to login via ssh. In this example only two users are allowed to access via ssh. If you have many users requiring access look into using AllowGroups instead.
Specifies whether sshd should check file modes and ownership of the user’s files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable.
Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6.
The server disconnects after this time if the user has not successfully logged in. If the value is 0, there is no time limit. The default is 120 seconds.
Specifies the maximum number of concurrent unauthenticated connections to the sshd daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10.
Alternatively, random early drop can be enabled by specifying the three colon separated values “start:rate:full” (e.g., “10:30:60”). sshd will refuse connection attempts with a probability of “rate/100” (30%) if there are currently “start” (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches “full” (60).
The contents of the specified file are sent to the remote user before authentication is allowed.
Once these changes and additions have been made you must restart the sshd process for the changes to take effect (sudo /sbin/service sshd restart).
THIS IS BY NO MEANS THE ONLY OR BEST WAY TO SECURE SSHD. IT IS BETTER THAN THE DEFAULTS AND IS SUFFICIENT FOR MOST PEOPLE WHO TRAVEL AND USE A LINUX LAPTOP ON PUBLIC WIFI NETWORKS WITH THE SSHD SERVICE RUNNING. BY FAR THE SIMPLEST AND MOST SECURE METHOD WOULD BE TO SIMPLY STOP RUNNING THE SSHD DAMEON WHILE AWAY FROM HOME.
Other means to access/secure sshd include, but are not limited to:
I am sure there are other solutions based on iptables and intrusion detection programs out there. But this should give you a place to investigate further so one can assess their needs and requirements. The bottom line is to tighten up the defaults at least a little.