Preventing brute force ssh attacks
Repeatedly 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.)
| Index entries for this article | |
|---|---|
| Security | Tools/Password guessing prevention |
Posted Oct 25, 2007 2:28 UTC (Thu)
by bferrell (subscriber, #624)
[Link] (3 responses)
Posted Oct 25, 2007 2:29 UTC (Thu)
by bferrell (subscriber, #624)
[Link]
Posted Oct 25, 2007 8:09 UTC (Thu)
by jordanb (guest, #45668)
[Link]
Posted Oct 25, 2007 8:47 UTC (Thu)
by madhatter (subscriber, #4665)
[Link]
Posted Oct 25, 2007 5:35 UTC (Thu)
by eru (subscriber, #2753)
[Link] (1 responses)
Posted Oct 25, 2007 12:46 UTC (Thu)
by i3839 (guest, #31386)
[Link]
Posted Oct 25, 2007 6:16 UTC (Thu)
by drag (guest, #31333)
[Link] (3 responses)
Posted Oct 25, 2007 11:14 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Oct 25, 2007 13:00 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
Posted Oct 25, 2007 16:25 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Oct 25, 2007 11:10 UTC (Thu)
by nix (subscriber, #2304)
[Link] (7 responses)
Posted Oct 25, 2007 15:16 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (4 responses)
Posted Oct 25, 2007 16:27 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Oct 25, 2007 18:23 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (1 responses)
Posted Oct 25, 2007 21:56 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Oct 30, 2007 16:31 UTC (Tue)
by droundy (subscriber, #4559)
[Link]
Posted Oct 25, 2007 20:00 UTC (Thu)
by njs (guest, #40338)
[Link] (1 responses)
Posted Oct 25, 2007 22:14 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Oct 25, 2007 14:03 UTC (Thu)
by Tet (subscriber, #5433)
[Link] (2 responses)
Of 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.
Posted Oct 25, 2007 15:40 UTC (Thu)
by apollock (subscriber, #14629)
[Link] (1 responses)
Posted Oct 30, 2007 16:34 UTC (Tue)
by droundy (subscriber, #4559)
[Link]
Posted Oct 25, 2007 14:11 UTC (Thu)
by leopinheiro (guest, #45660)
[Link]
Posted Oct 25, 2007 15:26 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (6 responses)
Posted Oct 25, 2007 16:29 UTC (Thu)
by nix (subscriber, #2304)
[Link] (5 responses)
Posted Oct 25, 2007 18:16 UTC (Thu)
by madscientist (subscriber, #16861)
[Link] (2 responses)
Posted Oct 25, 2007 21:22 UTC (Thu)
by utoddl (guest, #1232)
[Link]
Posted Oct 25, 2007 21:52 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Nov 2, 2007 0:16 UTC (Fri)
by endecotp (guest, #36428)
[Link] (1 responses)
Posted Nov 2, 2007 12:53 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Oct 25, 2007 17:00 UTC (Thu)
by copsewood (subscriber, #199)
[Link]
Posted Oct 25, 2007 19:12 UTC (Thu)
by Fats (guest, #14882)
[Link] (4 responses)
Posted Oct 25, 2007 21:43 UTC (Thu)
by njs (guest, #40338)
[Link] (3 responses)
Posted Oct 28, 2007 17:36 UTC (Sun)
by oak (guest, #2786)
[Link] (2 responses)
Posted Oct 28, 2007 20:58 UTC (Sun)
by njs (guest, #40338)
[Link]
Posted Oct 28, 2007 21:02 UTC (Sun)
by njs (guest, #40338)
[Link]
Posted Oct 25, 2007 21:42 UTC (Thu)
by storner (subscriber, #119)
[Link]
Posted Oct 25, 2007 22:51 UTC (Thu)
by dowdle (subscriber, #659)
[Link]
Posted Oct 26, 2007 0:14 UTC (Fri)
by kh (guest, #19413)
[Link] (1 responses)
Posted Oct 26, 2007 11:43 UTC (Fri)
by hein.zelle (guest, #33324)
[Link]
Posted Oct 29, 2007 18:24 UTC (Mon)
by dag- (guest, #30207)
[Link]
Posted Nov 3, 2007 15:29 UTC (Sat)
by Baylink (guest, #755)
[Link]
Posted Nov 7, 2007 12:31 UTC (Wed)
by jlmassir (guest, #48904)
[Link]
Preventing brute force ssh attacks
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
oops, they're in the offsite article
Preventing brute force ssh attacks
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
I wrote a slightly more detailed article on this that some may find useful, at
http://www.teaparty.net/technotes/ssh-rate-limiting.html
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?
Fix sshd?
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
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
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
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
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
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
> 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
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
> 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
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
> 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
>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
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...
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
Preventing brute force ssh attacks
Preventing brute force ssh attacks
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
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
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
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
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
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
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
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
> 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
Lovely. I shall give it a try.
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.
Denyhosts
Nitpicking (Preventing brute force ssh attacks)
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)
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)
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)
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)
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
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?
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
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
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)
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
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
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.