Weekly Edition
Return to the Security page
| |||||||||||||
Preventing brute force ssh attacksRepeatedly trying to log in via ssh using multiple username/password pairs, is a common attack against systems; it works often enough that relatively unsophisticated attackers ("script kiddies") continue to try to exploit it. As with most internet threats, this one, known as a brute force ssh attack, rises and falls in popularity; it currently seems to be on the upswing. There are a number of techniques that can be used to reduce the effectiveness of this attack, starting with the most obvious: pick good passwords. These attacks cannot succeed, in any sensible length of time, if the passwords on all the accounts are well-chosen, long, and contain a mix of numbers, upper and lower case, and punctuation. Bruce Schneier has good advice on choosing a password based on his research into passwords and guessing algorithms. But it is difficult to ensure that all passwords on a system conform or that some new guessing scheme doesn't happen to randomly hit upon the same password a user chose. Because of that, other evasive measures are often used. One of the drawbacks to being subjected to a brute force attack is the bandwidth and processing power needed to deal with the log in attempts, even if unsuccessful. A simple way to avoid that, at least for most unsophisticated attackers, is to simply run the ssh server at a port other than 22. Legitimate users can be told what port to use, while unsophisticated attackers will not find a server to connect to. An attacker using Nmap, or a similar port scanning tool, will find the ssh server pretty quickly, though. In a similar vein, port knocking hides the server by only enabling it after getting a certain sequence of connection requests. For example, a server could wait until it got a connection to port 1037, followed by connections to 42 and 6666, in quick succession from the same IP address, before it would open up port 22 (or some other port to combine with the above) for ssh traffic. After a timeout of a minute or so, the port would be closed down again. Both port knocking and changing the port rely on "security through obscurity," which is no defense against a determined attacker, but may be just fine to convince a script kiddie to move on to an easier target. Anyone who has access to the traffic bound for the server, though, will be able to spot ssh to a non-standard port as well as port knocking. To repel more sophisticated attackers, who may be targeting specific hosts, rather than trawling, other techniques can be used. An effective countermeasure against repeated connections is to ban the offending IP address for some period of time. There are several mechanisms to do this, one of the most straightforward is to use iptables to limit the number of ssh connections per minute to some small number. If a host exceeds that limit, its IP address is not allowed to make ssh connections for another minute. This slows down the traffic rather severely, but does have some drawbacks: iptables cannot distinguish between successful and unsuccessful log ins, so a fourth log in attempt would fail even if the previous three had been successful. Other tools, such as Fail2ban, monitor the ssh server log file to determine if there are too many failures, based on configurable criteria, from a given host and then modify firewall or tcp_wrapper rules to stop the offending host from connecting for some period of time. All of the techniques that ban IP addresses are effective against hosts that are used again and again. It is not inconceivable that a botnet could be used to do a distributed brute force attack which, depending on how many hosts were available and the timeouts on the server, might be very effective. Perhaps the most secure solution of all is eliminating passwords entirely, as long as the other endpoints are reasonably secured. The ssh server can be configured to not allow password authentication, only accepting connections from users that have their public key stored in the authorized_keys file. An attacker that gets access to the corresponding private key will have an easy entry to the host system, so this technique must be used carefully. Brute force attacks against ssh are more annoying than they are dangerous generally, but they can lead to intrusions. An intrusion of even a regular user account is only a privilege escalation bug away from being a complete takeover of the system. It makes sense to monitor log files periodically to determine if your host is being attacked and to take appropriate countermeasures. (For more details, see this article at the samhain labs website.) (Log in to post comments)
Preventing brute force ssh attacks Posted Oct 25, 2007 2:28 UTC (Thu) by bferrell (subscriber, #624) [Link] I found this set of iptables rules in an article somewhere (sorry, I don't remember where) that sure takes the wind out of the brute force types. iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 6 --rttl --name SSH -j DROP
Preventing brute force ssh attacks Posted Oct 25, 2007 2:29 UTC (Thu) by bferrell (subscriber, #624) [Link] oops, they're in the offsite article
Preventing brute force ssh attacks Posted Oct 25, 2007 8:09 UTC (Thu) by jordanb (guest, #45668) [Link] This has worked very well for me for a long time. The only problem is if you type your password wrong a few times you can trigger the block, but at least it expires after a minute of no connection attempts, so you just have to wait a while.
Preventing brute force ssh attacks Posted Oct 25, 2007 8:47 UTC (Thu) by madhatter (subscriber, #4665) [Link] I wrote a slightly more detailed article on this that some may find useful, at http://www.teaparty.net/technotes/ssh-rate-limiting.html
Fix sshd? Posted Oct 25, 2007 5:35 UTC (Thu) by eru (subscriber, #2753) [Link] Looking at the article, the text at Samhain, and the man page of sshd, I could see no mention of sshd itself being able to implement automatic banning or lengthening moratorium times between retry attempts for hosts that keep trying wrong passwords. Surely this would be the simplest and most secure solution? Or did I just miss the place where this sshd capability is mentioned?
Fix sshd? Posted Oct 25, 2007 12:46 UTC (Thu) by i3839 (guest, #31386) [Link] Totally agreed, it seems something sshd should handle safely instead of outside tools, sshd is the one trying to be secure after all.
Preventing brute force ssh attacks Posted Oct 25, 2007 6:16 UTC (Thu) by drag (subscriber, #31333) [Link] I put ssh on port 23 to avoid log spam. I am lazy like that. I use ssh keypairs with passphrase (which is actually 3DES encryption of the private key..) so if I 'misplace' the key then I am not much worse off then if I just used plain passwords. Then I disable the use of ssh passwords. On my desktop (er laptop) I use as my base of operations. I realy don't use any other computer. So it's the only one that I keep my ssh keys on. On my laptop I have zero network services (well, other then avahi).. so it's secure. Don't even have sshd running. For file transfer I just use sshfs.. no samba or nfs for my stuff. So for my personal stuff brute-force is impossible and the chances of obtaining a key is slim to none for a attacker. Not also to mention that most of this stuff is firewalled from the internet via a pc-based router. for multi-user environment though, especially corporate-land stuff, then passwords are still a way of life. Oh well.
Preventing brute force ssh attacks Posted Oct 25, 2007 11:14 UTC (Thu) by nix (subscriber, #2304) [Link] To be completely pedantic, a machine with no network services running is not necessarily completely secure. Most obviously, attacks can come in from compromised hosts you connect to. This is the most common attack vector these days thanks to malware on websites. Secondly, attacks can exploit vulnerabilities in the networking stack which can be tripped without a connection succeeding. I can think of two: the ping of death, and that nice information leak a while back where Linux was sending out Ethernet frames padded with random uninitialized rubbish from kernel memory (which could of course contain private data).
Preventing brute force ssh attacks Posted Oct 25, 2007 13:00 UTC (Thu) by drag (subscriber, #31333) [Link] That's why I said "slim to none" chance.. not "mission impossible". :) For daemons that may need to use ssh for whatever don't forget that you can configure your keys in such a way that they only allow certain commands to be executed. This still leaves a lot of holes if the attacker gets the daemon's private keys, but I suppose it can help. on a side note: One huge benifit that disabling passwords and using ssh-agent + passkey exclusively that is of a secondary nature and not obvious is that it reduces the chances of hacked host, that you log into, from compromising the rest of your networks. Like I said it's completely secondary and it has to do with human nature. We've all done something like this: log into host a from host a log into host b. from host b use scp to copy a file to your home desktop. That's easy to do and fairly standard unixy shell stuff.. When your busy and have lots of shells open on lots of computers its a pretty natural thing to do. But if 'host a' is rooted then the attacker now has a decent chance of obtaining your passwords for 'host b' and your home computer. So if you have passwords disabled and only keep your private keys on your localhost then that makes that sort of bad behavior much more difficult and makes 'doing the right thing', were you do not jump from host to host, much more easier... since your using ssh-agent and such you effectively have SSO so even if you have passwords aviable then it's much easier not to. It's a completely side thing and a very so-so thing, but I think it's nice.
Preventing brute force ssh attacks Posted Oct 25, 2007 16:25 UTC (Thu) by nix (subscriber, #2304) [Link] Quite so, ssh-agent is lovely and things like keychain make it usable :) (Of course it won't protect you if the machine on which the agent is running is rooted: they could keylog you, install a malicious agent, et seq ad nauseam. But it's useful if machines you connect to from the agent machine are compromised.)
Preventing brute force ssh attacks Posted Oct 25, 2007 11:10 UTC (Thu) by nix (subscriber, #2304) [Link] An attacker that gets access to the private key corresponding to a public key in an authorized_keys file on your system will have access to it *if and only if that key is unpassphrased or they determine the passphrase*. i.e. at worst passphrased keys are as insecure as passwords, and they're much more secure if the remote host is not compromised itself. (Unpassphrased keys should only be used inside a trust boundary, and even there with care: it's best to use an SSH agent instead, and passphrase everything, but that might be tricky if some of the keys are used by daemons, who can't reasonably ask a human to provide a passphrase to the agent: if they provide the passphrase themselves, that passphrase becomes as tappable as the private key, so passphrasing becomes pointless. It would be nice if SSH had a way to refuse entry to unpassphrased keys, or if I had a way to determine that the private key corresponding to some public key were unpassphrased, so I could audit authorized_keys files for unpassphrased keys and remove them. Of course the ability to do that would itself be an information leak with security consequences...)
Preventing brute force ssh attacks Posted Oct 25, 2007 15:16 UTC (Thu) by madscientist (subscriber, #16861) [Link] > It would be nice if SSH had a way to refuse entry to unpassphrased keys, or > if I had a way to determine that the private key corresponding to some > public key were unpassphrased, so I could audit authorized_keys files for > unpassphrased keys and remove them. I don't see how this could work; the entire point of PPK is that you never have to hand out your private key to anyone. So there's no way that the server can see whether the client's private key had a passphrase or not. Of course the protocol could just include that information in the request but that's completely useless as a security precaution, because the attacker just needs to tweak his SSH client code to always say that the key was passphrased, even if it wasn't.
Preventing brute force ssh attacks Posted Oct 25, 2007 16:27 UTC (Thu) by nix (subscriber, #2304) [Link] Exactly: I don't think it's doable, although I sort of wish it was. The closest you can get is to hack ssh-keygen so that it refuses to generate non-passphrased keys, and force everyone to generate new keys, pissing everyone off.
Preventing brute force ssh attacks Posted Oct 25, 2007 18:23 UTC (Thu) by madscientist (subscriber, #16861) [Link] > The closest you can get is to hack ssh-keygen so that it refuses to > generate non-passphrased keys, and force everyone to generate new keys, > pissing everyone off. Of course there's no way to guarantee that someone hasn't created a key using an older version of ssh-keygen, or a version that's been hacked back again. If the server cannot see the private key it _cannot_ reliably know whether it was locked or not. And not allowing the server to see the private key is one of the key features of PPK. Not to mention that there are very legitimate uses for password-less login, and non-PPK password-less login has no security at all. If you have to have password-less login (and sometimes you do, particular for automation purposes) then using a passphrase-less private key can, with proper attention to detail, give you a "pretty secure" way to do it.
Preventing brute force ssh attacks Posted Oct 25, 2007 21:56 UTC (Thu) by nix (subscriber, #2304) [Link] Yeah. What I'm really interested in here is being confident that an intruder who steals the private key of someone with login rights to my system cannot use it to log in... but I suppose even passphrases won't help there, as if they can steal a key they can almost certainly get root and install a keylogger, and the passphrase is toast.
Preventing brute force ssh attacks Posted Oct 30, 2007 16:31 UTC (Tue) by droundy (subscriber, #4559) [Link] > Of course the protocol could just include that information in the request but that's > completely useless as a security precaution, because the attacker just needs to tweak his SSH > client code to always say that the key was passphrased, even if it wasn't. Actually, this sounds very reasonable to me: the point of refusing access to passphraseless keys isn't to protect from an attacker, but to protect from a lazy user, who doesn't want to type his passphrase. This wouldn't protect from sophisticated lazy users, but those lazy users will probably realize it's easier to run an ssh-agent than to compile a modified ssh client. But this would prevent the stupid lazy user from logging in with his/her passphraseless key, which ought to gain something.
Preventing brute force ssh attacks Posted Oct 25, 2007 20:00 UTC (Thu) by njs (guest, #40338) [Link] >at worst passphrased keys are as insecure as passwords Not true, unfortunately -- standard passwords can be (in practice) perfectly protected against guessing attacks by using rate-limiting; there's no way to rate-limit attempts to guess a compromised key's decryption passphrase. Whether one cares or not is another matter (most of us are unlikely to be facing attackers who are willing to spend the necessary time to crack a decent passphrase in any case, and keyloggers and memory scanners are going to remain much cheaper and easier ways to get at decrypted keys), but there are tradeoffs.
Preventing brute force ssh attacks Posted Oct 25, 2007 22:14 UTC (Thu) by nix (subscriber, #2304) [Link] Hm. Interesting. Of course the passphrase can be much stronger than a password (since you only need to type it in once in a blue moon thanks to ssh-agent), but even so, that's food for thought...
Preventing brute force ssh attacks Posted Oct 25, 2007 14:03 UTC (Thu) by Tet (subscriber, #5433) [Link] If a host exceeds that limit, its IP address is not allowed to make ssh connections for another minute. This slows down the traffic rather severely, but does have some drawbacksOf course, the problem with that is the existence of legitimate access patterns that hit the ssh server many times a second. The darcs source control system, for example, uses a new ssh connection for each patch when syncing two repositories. Whether that's a sane thing to be doing is questionable, but it's the current behaviour. Using ssh connection sharing is probably helpful here, but it's simply not viable to expect users to know about that.
Preventing brute force ssh attacks Posted Oct 25, 2007 15:40 UTC (Thu) by apollock (subscriber, #14629) [Link] With OpenSSH, I think you could address this issue by configuring SSH to reuse existing connections, rather than spawning new ones. You'd even get a performance improvement. See the ControlMaster and ControlPath configuration directives in ssh_config(5)
Preventing brute force ssh attacks Posted Oct 30, 2007 16:34 UTC (Tue) by droundy (subscriber, #4559) [Link] This approach sort of works. But there is a bug in ssh that causes it to occasionally hang when working with a control master. So it's not yet a general solution. :( (And no, I've no idea what triggers this bug, it appears to be platform-dependent, showing up more often on MacOS X. And yes, it's been reported to the OpenSSH developers.)
Preventing brute force ssh attacks Posted Oct 25, 2007 14:11 UTC (Thu) by leopinheiro (guest, #45660) [Link] A simple way I use is to put the following line inside sshd_config: MaxAuthTries 1 So that an attacker can only try 2 wrong passwords. It's sometime annoying when I myself type the wrong password 2 times and get the connection dropped, but most times I type the password correctly, so that's not a problem at all.
Preventing brute force ssh attacks Posted Oct 25, 2007 15:26 UTC (Thu) by madscientist (subscriber, #16861) [Link] One thing I rarely find mentioned in these docs, but that I personally think is handy, is the AllowUsers field in sshd_config. If you set it up to allow only your own account then you don't need to worry about weaker passwords on other accounts (my kids both have accounts on my Linux system and they can't be bothered to remember complex passwords). I'd love to use a different port but I can't: my company has a very strict firewall that allows only ports 22 and 80 _outgoing_ (I know, right?), so if I change my port I won't be able to get in from work. Same issue with port knocking and similar solutions.
Preventing brute force ssh attacks Posted Oct 25, 2007 16:29 UTC (Thu) by nix (subscriber, #2304) [Link] You think that's strict. Ours allows only port 80 and that through a transproxy that mangles `advanced' features like HTTP/1.1 or pipelining. No 443, no 22, and ssh is `too insecure' although unsecured telnet is fine if the connection initiator happens to be in management. (Yes, I need to switch jobs.)
Preventing brute force ssh attacks Posted Oct 25, 2007 18:16 UTC (Thu) by madscientist (subscriber, #16861) [Link] Oh right, we do allow 443 as well. And our IT department just installed a proxy here too. WHAT A PAIN! I've been filing case after case getting them to re-open access to sites I need. And, there's some bizarre feature that I don't completely understand, where all HTTPS traffic is forwarded through the proxy and so it comes with the wrong (or anyway additional) encryption, so signatures don't match and all sorts of other messy things. Of course the thing is only tightly integrated with Internet Explorer, so if you use any other browser, even on Windows, you have to enter your password info, which then times out again (how anyone can imagine that promoting the use of IE is a security _enhancement_ utterly escapes me but...) I've arrived at work in the morning and had 100's of dialogs I have to get rid of from my RSS feeds, my weather applets, etc. when my password times out after I've left for the day. It's hard for me to believe the benefits really outweigh the costs here, but I guess I only see the costs and not the benefits.
Preventing brute force ssh attacks Posted Oct 25, 2007 21:22 UTC (Thu) by utoddl (subscriber, #1232) [Link] This is why I like working for a university. Firewall? Sure, you can install your own if you want one. And we do have _some_ things walled off, but by and large most hosts are highly exposed to the internet. It drives vendors nuts, 'cause many of their products assume there's a draconian firewall between them an the world, so they claim they don't need to deal with security issues. They often know nothing about SSL, kerberos, keys,... they just trust the firewall which, to their amazement, isn't there! One of the best was a demo by an ERP vendor. They were showing off their stuff, how cool and secure it was. Then somebody in the back of the room with a wireless Mac laptop took over the presenter's session. He gave it back, but not before making his (and breaking the presenter's) point about the system's security.
Preventing brute force ssh attacks Posted Oct 25, 2007 21:52 UTC (Thu) by nix (subscriber, #2304) [Link] Our lot blocked Google (`Proxy Avoidance'), *.oracle.com, and *.redhat.com (`Software Download') for a month. We're an Oracle-on-RHEL shop, so this was pretty disruptive, but apparently only the filter authors could remove the blocks, and the auditors wouldn't allow them to disable the filtering. It's all utterly insane.
Preventing brute force ssh attacks Posted Nov 2, 2007 0:16 UTC (Fri) by endecotp (guest, #36428) [Link] > You think that's strict. Ours allows only port 80 and that through a > transproxy that mangles `advanced' features like HTTP/1.1 or pipelining. That's the sort of situation that I wrote Anyterm for. http://anyterm.org/
Preventing brute force ssh attacks Posted Nov 2, 2007 12:53 UTC (Fri) by nix (subscriber, #2304) [Link] Lovely. I shall give it a try.
Denyhosts Posted Oct 25, 2007 17:00 UTC (Thu) by copsewood (subscriber, #199) [Link] This has matured into a very usable, effective and easily configured program over the last couple of years, including packaging support within Debian and Ubuntu. It saves me the hassle of maintaining an iptables script. For details visit the Denyhosts project site.
Nitpicking (Preventing brute force ssh attacks) Posted Oct 25, 2007 19:12 UTC (Thu) by Fats (subscriber, #14882) [Link] The port nocking method is not security through obscurity. All authentication mechanisms are based on some private information: a public key, a password, ... You can think of the port nocking sequence as part of this private information.
Nitpicking (Preventing brute force ssh attacks) Posted Oct 25, 2007 21:43 UTC (Thu) by njs (guest, #40338) [Link] You're right in your facts, but I think not-quite-right in spirit. Port-knocking adds some entropy to your effective password, yes. But if all you wanted was some extra entropy, you'd be much better off just choosing a slightly longer password or key -- just as secure, and substantially more convenient. But people use port knocking despite this. AFAICT, there are two reasons: (1) its rube-goldbergian complexity and attendent ritual appeal to a certain sort, who feel it *must* therefore be secure. This is exactly the impulse that security people are (rightfully) trying to squash when they sneer about security through obscurity. (2) it's relative scarcity does provide some security benefit -- since only weirdos use port-knocking, the script kiddies don't bother trying to brute-force it, and casual attackers will in fact be repelled. This also makes it easier to distinguish casual and determined attackers -- e.g. only one leaves lines in the ssh logs -- and so on. If it ever becomes popular, of course, the script kiddies will catch on and this effect will disappear. So port knocking provides no magic bullet against determined attackers (but people who encounter it often fall for (1) and think it does, and the more it gets advocated the more this nonsense gets carried along), not much benefit in the long run (which makes it curious that people advocate it at all; if you are using port knocking for the "right" reasons, you should discourage everyone else from using it, which may make some suspicious whether people *are* using it the right reasons), and engineering-wise it is just so *silly* that it leaves a bad taste in the mouth -- no-one wants this to become the usual way of designing security systems.
Nitpicking (Preventing brute force ssh attacks) Posted Oct 28, 2007 17:36 UTC (Sun) by oak (guest, #2786) [Link] Assuming the attacker cannot sniff which ports you're using (i.e. they have to attack blindly), using a sequence of ports could be considered also a password of a kind, with an *64K* alphabet.
Nitpicking (Preventing brute force ssh attacks) Posted Oct 28, 2007 20:58 UTC (Sun) by njs (guest, #40338) [Link] Yes. I'm not sure what your point is, though -- I already agreed that adding port knocking is like making your password longer, and there's nothing magical about a 64K alphabet. It just means that a single knock gives you about 16 bits of entropy, as compared to 6 bits from a random ascii character, so 1 knock gives a bit less than 3 (good) password characters. Or... you can just use a 4096-bit key and be done with it.
Nitpicking (Preventing brute force ssh attacks) Posted Oct 28, 2007 21:02 UTC (Sun) by njs (guest, #40338) [Link] Oh, right, and should have also pointed out -- passwords/keys remain safe even if the attacker is allowed to sniff all they want, no extra work is required to be secure in that case.
Preventing brute force ssh attacks Posted Oct 25, 2007 21:42 UTC (Thu) by storner (subscriber, #119) [Link] An alternative solution to this problem is simply not having an SSH daemon available on your public IP address. I only permit ssh access from either my internal network or from a VPN link. (OpenVPN, since IPsec is too horrible for words to configure). Since I only need ssh access from a limited number of computers (two: my computer at work or my laptop), having them setup to establish a VPN connection and run ssh through it is not a problem. Apart from keeping SSH off the public IP, the VPN connection also allows me to access other ressources - e.g. I can nfs mount my home directory from a remote location through the VPN link, which does come in handy at times.
How to prevent apache probes? Posted Oct 25, 2007 22:51 UTC (Thu) by dowdle (subscriber, #659) [Link] Ever looked at your log watch and seen messages that there were X number of probes on your webserver? I'm assuming the vast majority of these "probes" come from script kiddies running things like nikto. Are there any tools out there like denyhosts but for httpd's logs... to block IPs that appear to be probing the webserver? If so, I'd really like to get that deployed. I've heard that fail2ban can be used with httpd but I believe it is only for finding failed .htaccess login attempts and I'd rather detect nikto scans and block those. Anyone?
Preventing brute force ssh attacks Posted Oct 26, 2007 0:14 UTC (Fri) by kh (subscriber, #19413) [Link] I was getting so many brute force attempts on ssh that the server was not able to do anything else but check passwords - thus a DOS. I started using denyhosts on all internet facing servers and have not had that problem since. I find I really like the simplicity of denyhosts.
Preventing brute force ssh attacks Posted Oct 26, 2007 11:43 UTC (Fri) by hein.zelle (guest, #33324) [Link] I'm surprised nobody mentions sshdfilter in these posts, apparently it's less popular. From what I've heard it does about the same as denyhosts, using the sshd logs and iptables to block connections. Since installing it and switching to only-passkeys, and limiting the valid users with AllowedUsers in sshd_config, I feel quite secure about having sshd on port 22, and I don't get many attempts at all. I'm not sure how valid the comment in the article is, about such an approach not working for a botnet: sshd_filter typically blocks after the first invalid username, so only one attempt comes through. If a thousand hosts tried at the same time this may indeed blow up.
Preventing brute force ssh attacks (pam_shield) Posted Oct 29, 2007 18:24 UTC (Mon) by dag- (subscriber, #30207) [Link]
Something that I haven't seen mentioned in these discussions is pam_shield. It hooks into PAM,
actively knows and registers when a failed attempt to logon has happened and takes action when
something is beyond a certain treshold.
The default action it takes is to null-route the source ip address for a certain amount of
time. (configurable)
You can provide a list of networks that it should never null-route (to protect your own
systems from being blocked this way).
To me this system is perfect since:
- it does not have to scan a log files every X time
- it does not mess around with the firewall (or it could if you so like)
- it works on more than just SSH (FTP or else anything in PAM)
- it is pretty simple and straightforward to use
- it is very customizable as the action to take can be a simple script
You can get pam_shield from:
http://www.ka.sara.nl/home/walter/pam_shield/
Preventing brute force ssh attacks Posted Nov 3, 2007 15:29 UTC (Sat) by Baylink (guest, #755) [Link] How odd that this should come up this week; someone's been reading my mail. I just found the Samhain site last week, while on a business trip, and installed their last (hosts.allow/sshblock.sh) setup on several Linux boxen I'm responsible for. Works quite nicely.
Preventing brute force ssh attacks Posted Nov 7, 2007 12:31 UTC (Wed) by jlmassir (guest, #48904) [Link] The article fail to cover the standard pam module pam_tally. It locks for some time an account being attacked and is very simple to configure. In my debian server I put in /etc/pam.d/common-account: account required pam_tally.so in /etc/pam.d/common-auth: auth required pam_tally.so deny=5 unlock_time=300 That will lock an account being attacked for 300 seconds if password failed 5 times. It is effective for all services using pam authentication, like imap and authenticated smtp. Just warn users that they will have to expect 5 minutes if they fail to log in for 5 times. Also, with any brute force attack counter measures, in a multi user system one must be sure that passwors are strong (if some user chooses as the password its own username, chances are that the account will be cracked in a single try). One cannot rely on advising people to be responsible. Therefore, password cracking tools like john the ripper are very useful. That should be covered in the article too.
|
|||||||||||||