Frequently Asked Questions

Let me make a couple points in response to some comments I've seen regarding this script and active blacklisting in general.

1. My passwords are secure. Who cares if someone is hacking at them?

In your case and, perchance, my case, this may be true. If you are certain your passwords will not fall to a dictionary, brute force or intelligent attack and you see no other need to thwart hacking attempts, I say, "Good on ya!" Move on now and don't worry about sshblack (and don't bother to check your logs because you won't be able to find anything buried in those 2000 lines of failed ssh logins). However, if you are administering a system where you might have 100 or 1000 users and have no idea how strong all those passwords are, you might want to protect yourself. Ask anyone who administers a large system and they will tell you that, despite best efforts to enforce strong passwords, there will always be someone who uses "password" or "temp". Fortuntately many system have integrated password screening that will not allow users to set weak passwords. Many do not. Also, even smart people make stupid mistakes. Perhaps you are setting up a test account or installing a new piece of code that requires a user account. You forgot to remove that account when you were done testing or forgot to disable logins for that user. Many machines run by smart people have been compromised when these kind of mistakes are exploited. Don't worry, sshblack has your back.

2. It would take nine years to hack even a five character password! That's safe enough.

Your math is flawed. First, this assumes a brute force attack which may or may not be a good assumption. Secondly, you are assuming that you are only going to attack on one socket at a time and wait for the ssh daemon to time out or fail each time. That's (usually) not the way it works. Most operating systems running ssh have the ability to open more than one socket/port/thread. That means your ssh daemon can be serving 10, 20 or 1000 log in attempts all at the same time. It's extremely simple to fork a password hacker to open multiple login attempts at the same time. Do the math on that. Fortunately most of the Linux ssh code allows you to adjust the number of threads (either logged-in or initializing) in a config file. Some systems do not have this limiting feature. Yet even if you limit this to five simultaneous login prompts, you are still not safe. See the next paragraph. I would also point out that MANY people use sshblack to monitor/control things other than ssh daemons so it's utility goes well beyond failed password attempts.

3. I've limited the number of threads in my ssh daemon and use strong passwords. It would take someone over 12,000 years to hack me!

They don't have to be successful at cracking a password to hurt you. They can use a multi-thread attack to tie up all of your ssh sockets or at least run up your process count and suck up bandwidth. Obviously the biggest threat here is denial of service. If they have all your ssh threads tied up with their hacking attempts, how are you going to log in? This is why it is so important to stop these attacks at the most primary layer. In the case of sshblack this is done at the IP layer. By the time you are checking passwords or access databases, its too late.

4. Someone could spoof my address and get me blacklisted from my own machine!

There are several SIGNIFICANT issues with this argument. First, to even attempt this denial of service, someone would have to assume that you are actually running a script such as this. That's knowledge that your average attacker isn't going to have and knowledge the script kiddie is never going to slow down to acquire. I would also hope that most people have an upstream router that should be ignoring local-net spoofed packets and not forwarding them on to your SSH host. As for spoofing your remote address, such as your home DSL, yes, I suppose if someone was so determined and had a HUGE amount of a priori knowledge they could launch such an attack. Secondly, let's assume that someone has all this knowledge, maybe a disgrunteled ex-employee. Lauching a blind TCP spoof attack is not impossible but also not that likely. Remember, we are not talking about a smurf attack or anything like that. They have to get the ssh daemon to believe that it is talking to a routed host when it really isn't. What are the chances someone is going to go to all that trouble just for DoS? There are much more efficient DoS attacks they could use. Welcome to the Internet. Lastly, and most importantly, a whitelist function is included with sshblack so you should be able to whitelist any host or network you like and the rest of this discussion becomes nonsequitur. If you use the WHITELIST this problem should be significantly minimized.

5. The attacker could use a botnet or spoof addresses until my iptables fills up with thousands of entries!

Well, they could except for the fact that sshblack shuts itself down for 24 hours if it detects such an attack. You can limit the total number of blacklist entries to 50 or 200 or 10,000. Whatever you're comfortable with. And when it shuts down, the hacking attempts go on unabated. But you are the same folks that said nobody should be using a script like this in the first place so that's fine with you. You don't check logs or worry about the machine anyway so what's one more DoS attack, right? They've probably tied up all your ssh sockets so you can't log in anyway. This whole argument falls to some of the same fallacies that the self-blacklisting-blind-spoofing DoS threat does.

6. Why would you care?

I don't know how I can make this any more clear: If you never look at your logs and/or don't care about hundreds or even (yes) thousands of lines of hacking attempts in your logs, do not bother with this script. I tend to do everything I can to limit my exposure to viruses, trojans, script kiddies, spammers and the like. This is one small tool I use to limit one aspect of that exposure. I use blacklists on mail servers too. If that offends your sense of society, please don't use them. My passwords are strong, my software is up to date. It is not that I think these attempts are going to be successful at cracking my SSH daemon. I just get tired of seeing all the garbage. I trust the deadbolt on my front door too. That doesn't mean I want guys lining up in the street trying random house keys.

7. Locking out users after X many failed attempts is a bad idea.

Really? I'm the first one who's ever thought of this? Wow! I think if you look, you'll find dozens of operating systems, applications and servers that do exactly this. SSH is not for your grandma. If a user can't manage to enter a password correctly after four (or more) attempts, maybe they should take up a new profession or avocation.

Other Objections

The script works very well as it is however, many of the discussion boards have also presented some other options. I use a few of these myself. Only a couple of these will put a complete stop to the problem, but they have their associated drawbacks. Quite a few of these are simply good general security measures that should be done even if you don't have an SSH attack problem.

  • Change your listening port number so that the SSH daemon listens on a port other than 22. This can be done in your sshd config file, usually /etc/ssh/sshd_config. This will certainly keep many of the script kiddies out of your machine. Smoothwall Firewall does this. Most hacker tools can see right through this though and will find your daemon no matter what port you put it on. Note this may not be an option for people behind corporate firewalls or with other limitations on their traffic or SSH client. A perfect option if only one or two knowledgeable people need access to the server. Use the ListenAddress ip address:port option in /etc/ssh/sshd_config


  • Set the PermitRootLogin option to no. This does absolutely nothing to keep people from attempting to hack your system. It does add a tiny bit of security because there is no way for someone to log in as root. That is, you could have "temp" as your root password (please don't) and it wouldn't matter in terms of SSH attack because an SSH user could not log in as root. There are other ways to do this (see next item).
    To do this, again, look in the /etc/ssh/sshd_config file and set the PermitRootLogin no¦yes option.

PermitRootLogin no

  • Configure your /etc/passwd file to deny logins to anyone who doesn't need access. This would include mail-only or FTP-only users. Simply, people who don't need shell access. Most adduser (or useradd) applications enable shell access by default.
    Look in the /etc/passwd file and change the last item to /sbin/nologin

uucp:x:56:15:uucp:/var/spool/uucp:/sbin/nologin games:x:58:100:games:/usr/games:/sbin/nologin gopher:x:99:2:gopher:/var/gopher:/sbin/nologin bubba:x:600:611:Bubba Gump:/home/bubba:/sbin/nologin

  • Set the LoginGraceTime and MaxStartups variables in /etc/ssh/sshd_config to be something a bit more aggressive than the default. This again, will only slow down an attacker, it will do nothing to prevent it. LoginGraceTime adjusts the amount of time that the ssh daemon will wait for a valid login to be completed. It normally defaults to 120 seconds. I set it much lower. [There is a potential problem with doing this but that will be left as an exercise for the student.] MaxStartups determines how many simultaneous, unauthenticated (not logged in) connections the ssh daemon will allow. This defaults to 10. See the manual page for sshd_config for some more fine-tuning options on MaxStartups.
    Note that neither of these options has any effect on the maximum number of simultaneous ssh users that can be successfully logged in.
    In /etc/ssh/sshd_config:

LoginGraceTime 20 MaxStartups 1

  • Use SSH Keys instead of passwords. This works well for smaller numbers of users and is generally considered more secure. I'm also not sure if this would actually stop anyone from attempting to log in and continuing to clutter up your logs. It can also get interesting if you regularly log in from several different machines. A USB stick can be used to hold the key.
  • Implement door-knocking. If your version of iptables has all the extensions, you could try something like this. Truly an elegant solution but requires a small amount of monitoring/maintaining. Some have argued about the viability of door-knocking schemes and dismissed them as weak security through obscurity. I use several forms of door-knocking for various things.
  • Use pam_tally. See pam_tally instructions. It basically locks accounts with too many failed passwords. I have no idea if this will work with your ssh, it is designed for pam databases. Also consider the huge risk of denial-of-service with something like this. It will also do nothing to keep 1000 lines of "guest" attempts out of your logs.