On Mon, Aug 13, 2007 at 10:10:14AM +0100, Stuart Henderson wrote:
quoted text
> On 2007/08/09 12:22, Joachim Schipper wrote:
> > > > 
> > > > # Define some variable for clarity
> > > > SSH_LIMIT="(max-src-conn-rate 3/30, overload <scanners> flush global)"
> > > > 
> > > > # Allow quick valid traffic to ssh but log all attempts as well
> > > > pass in log quick on $ext_if inet proto tcp from ! <scanners> \
> > > >    to $ext_if port ssh flags S/SA keep state \
> > > >    $SSH_LIMIT
> > > 
> > > I've added something like this to pf.conf but it's only partially
> > > successful. I would appreciate any clues as to why it's not blocking all
> > > brute-force attempts.
> > 
> > You would probably be better served by a clue about why this is a
> > terribly bad idea, but you'll most likely have heard all the arguments
> > already. Or maybe not - 'flush' enables an attacker to not only prevent
> > you connecting, but actually to log you out as well.
> 
> This still needs a 3-way handshake to be completed, it's not so
> easy to blindly spoof. Main problem is if the attacker comes from
> the same IP address as a legitimate user (NAT etc).

Yes, that is one of the main problems. The other is that it takes time
to set up which would be better spent doing something useful - like
setting up a log watcher.

quoted text
> > Plus, SSH scans are about as dangerous as some skiddie scanning for old
> > versions of PHPMyAdmin, and we don't take steps to prevent the latter
> > either.
> 
> Depends how much CPU is spent handling the connections.

I'm fairly sure that on a modern system attached to a 100 Mbps link
network capacity will run out before this becomes a problem.

quoted text
> > Finally, Subversion over SSH uses lots of connections, should you ever
> > want to use that.
> 
> connection multiplexing can be useful for this sort of thing.

Yes, it would be, but I never got it to work reliably (Subversion likes
to close connections before opening the next one, etc). Did you? If so,
could you share the script/... you used?

Still, the point is that this policy has some odd results, costs real
time (albeit a little) to implement, increases complexity, and does not
gain you anything.

		Joachim

-- 
TFMotD: lm (4) - National Semiconductor LM78/79/81 temperature, voltage,
and fan sensor