--On Tuesday, July 28, 2009 02:34:59 PM -0500 Nicolas Williams <Nicolas.Williams at sun.com> wrote:
> On Tue, Jul 28, 2009 at 02:49:00PM -0400, Jeffrey Hutzelman wrote: >> --On Tuesday, July 28, 2009 11:38:41 AM -0500 Nicolas Williams >> <Nicolas.Williams at sun.com> wrote: >> > The master sshd knows which connections have authenticated >> > successfully, and which have not. IMO this makes the master sshd the >> > best place to put any logic such as "no more than N/s connections with >> > unsuccessful authentication from any remote IP" and so on. >> >> It's the best place to decide which things to block, but not the best >> place to do the blocking -- you want to arrange to drop packets from >> those hosts entirely, rather than letting them consume resources and >> explore an attack surface in sshd. Also, typically sysadmins deal with >> things like this by writing tools to process the logs, decide which >> peers are being unhappy, and then block traffic from them. They don't >> do it by adding lots of new code to the SSH server and rebuilding it >> from source. > > Oh, perhaps, but sshd already does something not unlike this now via the > MaxStartups feature. No, MaxStartups is very unlike this. The heuristic is something like "if a host makes 10 ssh connections in a row within a space of one second, and none of them were successful, _I don't ever want to hear from that host again_". That host is an attacker, and I want it GONE, period. MaxStartups doesn't do that; it allows an attacker to trivially lock out legitimate users while it continues to beat on the door indefinitely. Lowering the priority of unauthenticated connections effectively does the same. I do _not_ want the attacker and legitimate connections to share the same fate; I want the attacker GONE with no interference to legitimate connections. Nico, this is one of those cases where "it would be nice if..." is trumped by what people are actually seeing in the real world, and what actually works to combat it. For the moment, a lot of what we see is hosts that connect over and over and over again, trying different usernames or different passwords or to exploit some weakness, or all three. What works, for the moment, is to notice repeated connections and filter away the offending hosts, at least for some period of time. This is not theory; it's widely-deployed practice; see www.fail2ban.org for one common tool. -- Jeff
