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!
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
Use another port than 22. I have not noticed one single bruteforce attempt after I did that.
objorkum dot com
bfd is a good program to run with APF.
/var/log/secure file and automatically adds attackers to your /etc/apf/deny_hosts.rules file.
http://www.rfxnetworks.com/bfd.php
it looks through your
It works really well for me. Catches a lot of attackers.
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 #!
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.
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
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"
# You'd like awk
/var/log/authlog | uniq >> /etc/hosts.allow
awk '/Illegal user/ { print " ALL:" $10 ":deny" }' \
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.
I use Python script called BlockHosts to block hosts that fail more than a given number of times in a row. These types of attacks get quite annoying so it's nice to know they're getting blocked after a few tries.