Slashdot Mirror
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."
If possible, restrict access by source IP address, limit the user accounts w/ SSH access, and don't allow remote root logins.
Another step to improve security if there are very few users is just to ONLY allow public key authentication. I've never seen such a box compromised remotely.
Throw the bums out!
What are we going to see next on Slashdot? A review for the movie "Scr1pt k1dd15"? I was interested when I saw the link and after clicking on it, I was sadly disappointed. This has nothing to do with SSH, and could just as easily be used on Apache logins, FTP, Telnet, IRC, etc. Brute forcing is an old concept and is the whole reason you are supposed to use strong passwords (well that and offline password attacks).
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
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
i have had this on a number of occasions.. i just set the max auth attepts to 4, this renders the attempts useless
I use DenyHosts http://denyhosts.sourceforge.net/ from a cronjob. It detects any suspicious logins in /var/log/auth.log and adds the ip address of the user into the /etc/hosts.deny file. It also sends me an email telling me the IP address that was last added to the file.
Lately I have been getting atleast 1 hack attempt a day on my personal computer connected to the internet over a cable connection. On weekends I get more.
Just this morning I had two ssh dictionary attacks. DenyHosts caught them both.
Use a non-default port on any service whenever possible. This simple change goes a long way. Obviously it is not all you should do.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
I got annoyed enough that I wrote a little script to pull the data out of my logs in real time and add an entry to my firewall, but the attacks are harmless to any sysadmin with a clue.
-Matt
The simple, old attacks are sometimes the most dangerous because you start to assume there's no problem with them. You forget about them. They become a blind spot. The point of the article is to remind you, linux can be just as insecure as windows if you do stupid things like choose bad passwords.
Use another port than 22. I have not noticed one single bruteforce attempt after I did that.
objorkum dot com
The idea of brute force is extremely old, but the fact that somebody is out there actually doing them is important. The use of strong passwords is no longer just a theoretical "it would be a good idea" policy, but now somebody actually is looking to get through.
Other Slashdot readers are reporting the same effect: a recent rise in brute-force, scripted attacks, possibly by compromised boxes.
Most accounts of all sorts remain secure simply because they're obscure, and it's tempting to be lulled by past successes. We always knew that this was possible, but the fact that somebody is actually doing it is news.
I've been seeing these attacks for QUITE a while now. Repeated access attempts which were guesses of people's first names as logins. I used to ban the entire source subnet, but it's futile. Now I just whitelist acceptable IPs.
To-do List: Receive telemarketing call during a tornado warning. Check.
If you only need access from a limited set of machines which can have pre-generated keys, you can disable password authentication entirely (PasswordAuthentication no) and use RSA instead, with optional passphrase. In addition to PermitRootLogin no, I suggest judicious use of AllowUsers in sshd_config.
you had me at #!
A good thing to do is to use the AllowUsers configuration directive for sshd in /etc/ssh/sshd_config. The following would allow some account named 'unprivguy' authenticated ssh access from anywhere. All other ssh connections must come from local and local domain authenticated users. So root@localhost or root@*.mydomain.com could log in. All others are blocked, even if they have the password.
AllowUsers unprivguy *@*.mydomain.com *@localhost
You still see the attempts in your logs, but now you also see:
User root not allowed because not listed in AllowUsers
I tried to post this in the talkback on the article but it got horribly munged.
Here are the iptables rules I use to dynamically stop this kind of thing (with a good degree of success):
# SSH
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck --hitcount 3 --seconds 600 -j LOG --log-prefix "SSH attack: "
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck --hitcount 3 --seconds 600 -j DROP
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --set -j DNAT --to-destination $INTERNAL:22
-A OUTPUT -m tcp -p tcp -d $EXTERNAL --dport 22 -j DNAT --to-destination $INTERNAL:22
Your mileage may vary. This blocks attempts for 1 minute after 3 attempts (successful or failed, so if someone forgets their password, they may trip it as well).
Green's Law of Debate: Anything is possible if you don't know what you're talking about.
That's probably the IP of one their previous victims. If you wanted to have fun, rename the role account they're trying for, create a "root" with almost no access and uses Zork (dungeon) as its shell. (Probably best to try this on the junk spare Pentium box, just in case.)
One line blog. I hear that they're called Twitters now.
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.
.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.
I analyzed the system, and quickly determined that the person was not a big time hacker. Looking at his
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.
Looking for a computer support specialist for your small business? Check out
I sleep just fine now.
PHEM - party like it's 1997-2003!
I've been logging and reporting these attacks since last October (when I first started using BFD). I'm figuring they've been going on for a long long time. A simple install of APF and BFD will keep you from having too much trouble though. That and making sure noone is using easy to guess passwords.
APF and BFD can be got here: RFX Networks.
StrategyTalk.com, PC Game Forums
The article goes into depth on how to monitor these attackes and to report them to the authorities.
... how very ... twentieth-century.
....
The authorities
Better we should self-organize our collective defense.
Peer-to-peer government -- making the nation-state obsolete, one node at a time
-kgj
-kgj
I just disabled any SSH use without a key. Duh, right?
-- 'The' Lord and Master Bitman On High, Master Of All
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
" What luck for rulers that men do not think" - Adolf Hitler
if your ssh server needs to be publicly available, you can always have it listen on a different port. that seems to thwart 100% of these automated attacks.
Gyrate Dot Org - "Where high-tech meets low-life"
If the people you are giving shell accounts too are not smart enough to figure out how to change the port on the client, you have other problems. The exception to this may be restricted accounts, such as sftp. But if people are smart enough to change the dropdown from "ftp" to "sftp," they are smart enough to change the port value from 22 to 22222.
Changing the port does work. I went from having hundreds of attacks a day to zero. Not a single attempt in months.
47% of all statistics are made up on the spot.
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.