If you have an existing userbase, you can't just switch to public key authentication, depending on the type of customer. pubkey auth is also generally inconvenient if people tend to use different computers. This is also a problem we just ran into. Fortunately, recent versions of OpenSSH support match blocks and chroot. This allows you to a) selectively enable/disable password authentication, which reduces the possibility of a successful brute force attack, and b) re-root anybody to their respective homes so even if somebody successfully breaks into your system, there's no much he could do then. It also allows you to completely disable FTP access, which not only prevents passwords being transmitted in plain text but also closes a hole in your firewall setup. Combined with thorough system monitoring (prelude, snort, samhain, zabbix...) and a generally strict security policy (proper file system permissions, mount options and so on, any proactive security measures), any system can be made pretty hard to attack. On the other hand, as the recent key vulnerabilities caused by the Debian OpenSSL version have shown (http://lists.debian.org/debian-security-announce/2008/msg00152.html), you can't make sure that the programs your security policy relies on don't have holes in themselves. "Pretty hard to attack" is usually just a question of how skilled and persistent the attacker is. A script kiddy running a simple brute force attack can usually easily be blocked by having something like denyhosts running in the background. Somebody who really wants to break into your system and actually knows what to look for won't be stopped by such measures. If somebody from within the system tries to do bad things, you usually have a valid contract with that person which makes it easy to sue him for any damages or downtimes caused. Depending on the user type, it would also be possible to mount the user fs noexec and only allow access to a read-only fs containing executables from within his chroot (proactive approach again).
> -----Original Message----- > From: Henrique de Moraes Holschuh [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 21, 2008 5:21 PM > To: Michael Tautschnig > Cc: [EMAIL PROTECTED] > Subject: Re: What to do about SSH brute force attempts? > > On Thu, 21 Aug 2008, Michael Tautschnig wrote: > > > * use a Firewall to prevent other IP address to connect to your ssh > > > service. restrict just to yours (iptables script can be easy to find on > > > the web) > > Well, I should have added that my hosts must be world-wide accessible using > > password-based authentication, so this is no option. > > In the long term, switch to key-based auth. > > > I'm not a huge fan of security by obscurity, so I'd rather stick with 22 for > > now. > > Switch to key-based auth. Brute-forcing the keys is much harder. > > Meanwhile, you really should do something to reduce your attack surface, so > fail2ban and the like, plus non-standard ports are a damn good idea while > you implement the proper "fix" (drop passwords). > > > What remains open is what could one do proactively? I don't really feel like > > striking back, but getting rid of the attackers would be kind of nice... > > Strike against a botnet? That's a waste of effort, really, with very few > exceptions. > > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
