Rundown on SSH Brute Force Attacks

An anonymous reader writes "Whitedust has a very interesting article on the recent SSH brute force attacks. The article goes into depth on how to monitor these attackes and to report them to the authorities. It also discusses various tools that are available. According to the article, mostly compromised Linux systems from outside of North America are responsible for the attacks. Even the author's DSL connection was getting break-in attempts."

Comments

Highly annoying

[oGMo]

I have seen tons of these for 12+ months. Highly annoying. Last week I had one with over 10k connection attempts. What I need is an IDS that will just drop the remote IPs into iptables. Anyone have something like that? Of course if anyone is actually interested in reports on all the IPs, most of which usually are in .cn, I've got back logs for quite awhile. ;-P

Re:Highly annoying

[cdrguru]

We use a script called sshd_sentry. It is set up so that after five failed attempts the IP address is blocked for 24 hours.

This has essentially ended the problem for us. It allows SSH to be wide open so out-of-the-office employees can log in from a hotel or Treo in case something bad happens and it absolutely blocks dictionary attacks.

No longer a problem.

Re:Highly annoying

[str8]

Perl is an appropiate tool for this in my mind. I did what you did but had syslog send the entries to a FIFO which the script reads from.
I give them 2 tries in 10 seconds or 3 in 60 before they get put into the bit bucket. I then send an email to myself with the IP, times, and usernames.
Kinda fun to watch my gmail account get 4-5 of these a day.

Psst. Hey buddy. Can you spare a .sig?

Re:Highly annoying

[Anonymous Coward]

I have a script that log scans for suspicious activity. If I pick up on more than 5 fails/errors from any 1 location, they're auto-banned in hosts.deny

Nothing more than a simple little cat/grep/awk tally script, but it does the job for the home server.

I've been running it thru cron at rather short intervals for 6 months now, and dropped 340 ips into hosts.deny.

Re:Highly annoying

[justMichael]

We use a script called sshd_sentry. It is set up so that after five failed attempts the IP address is blocked for 24 hours.

While this approach looks like a great solution on the surface, it can have some rather unfortunate side effects.

You want to be careful where you deploy this type of setup.

Take this example. You run a fairly successful ecommerce site in a very competitive space. One of your competitors discovers you use this method and decides they don't want you to compete with them on Googe, Yahoo etc. They setup a script that bangs on your box once a day spoofing all the known bot IP addresses. After a while you will start to wonder why you aren't in the indexes any longer.

That's pretty nasty business, but if you think people wont do it, you underestimate your competitors.

Re:Highly annoying

[corpsiclex]

Nice thought, but it won't do much to stop a script that uses a new proxy every x attempts from a large list. You could block public proxies, but the bigger botnet owners might still have a fair shot over a several day long attack.

Re:Easy fix

[brsmith4]

To bad you posted AC... this is very informative to newer users that are unaware of /etc/ssh/sshd_config.

Re:As always...

[ben_white]

I had my home machine compromised this way. I have only 3 users on my home box, and choose all passwords myself to keep them strong. One night I was working on getting a backup system up and created an account backup with the excellent password "backup." I fully intended to change the password and disable remote logins for this account once I got it working. It was getting late, and I just didn't do it prior to hanging it up for the night. The next morning I had found the password had been changed to that account, and reviewing the bash log was able to trace what the intruder had done (ie root kit attempts, using my machine to run further automated attacks on other ip blocks). These weren't very sophisticated blokes, as their changing the password that was my tipoff that I had been cracked.

I take security seriously, but a momentary lapse of judgement, and my machine was compromised. If the idiots hadn't changed the password I might not have noticed for several days. Just an illustration of how vulnerable the internet is, even if you think you are careful and know what you are doing.

Ben

Re:DenyHosts

[Anonymous Coward]

Does a login attempt really take so much CPU time that these attacks affect performance? If not, it might be simpler to use a strong password, never look at /var/log/auth.log, and carry on with business. If yes, it might be simpler to optimize the ssh login code to make it faster.

Re:As always...

[SlightOverdose]

One of my clients had apache running as root, and an attacker was able to create a new account on the system via a hole in a php script.

The attacker then tried about 50 times to login to the new account via ssh, but wasn't in AllowUsers. Eventually the idiot gave up- most likely a script kiddie who didn't realise the potential of his initial attack.

Moral of the story? AllowUsers is a really good idea :-P

They actually got in on my parent's computer

[yorgasor]

I made an account for my dad on my mom's computer so he could have a samba share over the network, and gave it a really easy, completely forgetting that it was also accessible via ssh. Fortunately, I added their computer to my personal DNS domain so I could remember how to get to it easier. Shortly after it was compromised, I got an email informing me that phish spams were being sent from the computer.

I analyzed the system, and quickly determined that the person was not a big time hacker. Looking at his .bash_history file His only attempt to gain root access was to run 'sudo'. He copied over a list of people to spam, a mail script, and an email. He fired off a test email first, and then spammed the email list. A couple days later, he copied over a different list and message and sent those off. After that, I was tipped off and sealed off his entry.

Since he made no effort to cover his tracks or avoid detection, either this script-kiddie didn't know how to, or had so many computers to manage it wasn't worth his while to do so.

First, I put ssh on another port, then...

[Dr. Manhattan]

... I wrote a program that was utterly immune to buffer overflow and other attacks, and use that program to enable SSH for just the IP address I'm coming from. See the .sig for the details.

I sleep just fine now.

Youre, right, this has NOTHING to do with Linux.

[DaedalusHKX]

This has to do with Linux getting to the mainstream... people are using lame passwords and leaving unnecessary services with weak passwords open to the public. (Hey, if you'd know how many people **I** alone know that use "password" or "god" or "mom" as their root (*nix/bsd) or admin (windows) passwords. (Or, funnier still, the ones who leave it blank for ease of use.)

Do people on slashdot NOT know what a brute force / dictionary / wordlist attack is??? It is an attempt to connect to a service, using a random or scripted password and username generator or a list of commonly used ones (root and administrator on various systems obviously comes to mind.)

Most people use SSH without redirecting it through a trusted tunnelling protocol or connection. There are many ways to secure even the most trivial home network.

A word to the wise... instead of clicking okay and next mindlessly when installing your OS, start making a practice of READING the warnings and learning something... it should keep the brown fat cells from drowning out your otherwise idle brain as you get older. (IANAMS - I am not a med student, but so I've heard)

-DaedalusHKX

Re:Non-default Port

[failure-man]

Not only that but changing the port really helps with spotting a real attack. Dumb scripts always try port 22. Since I run SSH on a different port all that random noise falls away. If I see failed login attempts I know I'm looking at something with some intelligence.

Simple iptables-only port knocking for Linux

[Anonymous Coward]

I use simple iptables based port knocking for an added layer of protection. It has absolutely no resistance to sniffing (to find the port sequence), but I don't care about that. It goes something like this:

$IPTABLES -A INPUT -p tcp --dport 50 -m recent --remove --name SSH_PART2
$IPTABLES -A INPUT -p tcp --dport 50 -m recent --remove --name SSH_PART3
$IPTABLES -A INPUT -p tcp --dport 40 -m recent --remove --name SSH_PART3
$IPTABLES -A INPUT -p tcp --dport 50 -m recent --set --name SSH_PART1
$IPTABLES -A INPUT -p tcp --dport 40 -m recent --set --name SSH_PART2
$IPTABLES -A INPUT -p tcp --dport 30 -m recent --set --name SSH_PART3
$IPTABLES -A INPUT -p tcp --dport 22 -m recent --rcheck --seconds 30 --name SSH_PART1 --name SSH_PART2 --name SSH_PART3 -j ACCEPT

You have to connect to port 50, 40, 30, then 22 within 30 seconds to actually get to sshd. This way I can access my box from anywhere, but I don't have to leave 22 open. This also has the huge advantage of not needing to log attempts and run a daemon/cron job to periodically check and modify the firewall. The kernel does it all for me.

Re:DenyHosts

[theCoder]

I recently stumbled upon sshdfilter. It analyzes sshd output in real time by running sshd in with the -e option and adds attempts to login with invalid usernames to an iptables chain to drop all packets from that host. I've only been running it for a week or so, but it seems to be working well.

Seems like a similar idea to DenyHosts, just a different implementation.

My box was compromised by this

[Malc]

A few months back my Debian Woody system was compromised by this. I had major security issues: a weak password and an old unpatched kernel.

I got up in the morning and looked at my logcheck emails. It was odd: there were messages saying the ethernet card had entered promiscuous mode, and several kernel modules loaded. Further investigation revealed two connections to remote port ircd, but netstat wouldn't show the process ID(s) that owned this connections. The machine was in a mess: I couldn't run man, or gzip (needed by the apt-get process) and several other key commands as they immediately seg faulted. Rebooting resulted in the same issues: ethernet card in prom. mode, etc. Perhaps a packet sniffer was running on my networking looking for passwords to upload.

My problems started when I created an account for a friend and gave it a weak password without making him change it. The ssh dictionary attack broke in that way. Furthermore, I wasn't running a normal Debian kernel. Instead one that somebody else had created with MPPE support (it would be nice after all these years if one could have MS-CHAP support for PPP straight out of the box). I hadn't kept tabs on the kernel notices and ensured that this kernel was ok with them - it hadn't been updated for at least a year. Thus the script that broke in via SSH was able to exploit a local security hole and elevate privileges - game over.

I write all this as a reminder to people to take care. Debian is fairly secure if you use standard packages and keep them up to date. I'm generally quite carefull about what I install, which services run, what ports are exposed to the internet, keeping and eye on it, etc. Two careless mistakes and I had to rebuild the system and change all my passwords - thankfully nothing more. Be warned.

Re:As always...

[theonetruekeebler]

Easily done, but:

Do you have an SMS-enabled cell phone? For an operating systems class project this spring I wrote a simple PAM module what would look up the user's cell phone number then send an eight-digit random number to the user's cell phone, which the user has to type in at the login prompt. I used this module to secure the outward-facing sshd (on port 7xxx), blocking port 22 at the firewall so I could continue to ssh around my home network without spending $0.15 every time I rebooted my laptop.

As long as your phone has a signal, you have effective token-based authentication.