Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

6/30/2010
02:31 PM
John H. Sawyer
John H. Sawyer
Commentary
50%
50%

Protecting SSH From The Masses

SSH brute-force attacks are not uncommon against computer systems sitting on public IP addresses. Script kiddies and botnet-infected systems are scanning the Internet looking for low-hanging fruit (think: weak passwords) to leverage for additional attacks, website defacements, or attack-tool storage.

SSH brute-force attacks are not uncommon against computer systems sitting on public IP addresses. Script kiddies and botnet-infected systems are scanning the Internet looking for low-hanging fruit (think: weak passwords) to leverage for additional attacks, website defacements, or attack-tool storage.Usually, the scans come from the same source trying user names like admin, root, test, and db. The passwords are typically the same as the user name plus common ones like I had mentioned in my blog about FireForce. The sad thing is that the scans are successful -- and that's why they continue.

In a way it's a little amusing, because I've seen it time and again where the user or admin who you were sure had extremely well-secured systems ended up being compromised because he was doing some testing, created a test account with an easy password, and forgot to delete it. The irony is that these particular systems probably have some of most complex passwords you've ever seen, but they fell because of a guessable one where the admin was being lazy.

During mid-June, we saw an uptick in the number of distributed SSH attacks where each account attacked was done by a different IP. There have been various combinations over the years, but it's always interesting to see these because you know that the machine connecting to you is infected and part of some botnet. ISC also noted the increase in its June 18 diary.

There are several good steps for securing SSH. The easiest is to change the port to something other than 22. While this seems silly, it is effective at eliminating the usual daily scanning. We all know that security through obscurity surely shouldn't be the only defensive measure, but in this case it cuts down the noise. If you start getting brute-force attempts on the new port, then you're obviously dealing with someone more determined at getting in because he had to perform a port scan to find the new SSH port.

The other effective measure is to disable password authentication and used only SSH keys. This means you'll always need your key with you when you're accessing the server remotely, but it prevents password attacks.

I also like fail2ban for automatically blocking IPs that are attempting repeated logins. It monitors your logs looking for repeated failures and can add a firewall rule using a host-based firewall like ipfw and iptables to block the attacker after a configurable number of failed logins over a user-configured amount of time.

Looking back through my fail2ban log for June, I can see the same trend that others saw, whereas the beginning of June was pretty quiet with a sudden jump from 330 blocked IPs on the 16th to nearly 2,500 on the 17th. Since then, it has been consistently 1,000 to 1,500 hosts blocked every day.

Securing SSH is not hard, but it does require a small amount of effort to make the configuration changes, create keys, and install a tool like fail2ban. But the time required is certainly less than what you'll spend rebuilding the system if it gets owned.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11494
PUBLISHED: 2020-04-02
An issue was discovered in slc_bump in drivers/net/can/slcan.c in the Linux kernel through 5.6.2. It allows attackers to read uninitialized can_frame data, potentially containing sensitive information from kernel stack memory, if the configuration lacks CONFIG_INIT_STACK_ALL, aka CID-b9258a2cece4.
CVE-2020-7619
PUBLISHED: 2020-04-02
get-git-data through 1.3.1 is vulnerable to Command Injection. It is possible to inject arbitrary commands as part of the arguments provided to get-git-data.
CVE-2020-7620
PUBLISHED: 2020-04-02
pomelo-monitor through 0.3.7 is vulnerable to Command Injection.It allows injection of arbitrary commands as part of 'pomelo-monitor' params.
CVE-2020-7621
PUBLISHED: 2020-04-02
strong-nginx-controller through 1.0.2 is vulnerable to Command Injection. It allows execution of arbitrary command as part of the '_nginxCmd()' function.
CVE-2020-7623
PUBLISHED: 2020-04-02
jscover through 1.0.0 is vulnerable to Command Injection. It allows execution of arbitrary command via the source argument.