On 2007/08/13 12:14, Joachim Schipper wrote: > > > > 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.
Well, this *is* useful, and much safer than some log watchers. See e.g. http://www.ossec.net/en/attacking-loganalysis.html which closes with these lines: Please be aware that a few other tools also "block ssh scans", but some of them are so vulnerable that I didn't even bother mentioning. My advice is don't use tools that are shell-script based or have not been updated in a while. Not only they are vulnerable to remote DoS, but also to command execution via hosts.deny (yes, you can configure it to execute programs) and other means. > > > 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. Between the disk writes for logging, and the crypto setup, this can bring an otherwise-useful machine to it's knees, with much less than a 100Mbps. Been there, done that, written the PF rules, at least for the affected boxes that need SSH open from all locations (note to readers: for machines where you can restrict SSH to certain IP/IPv6 addresses only, it is a Good Idea to do so). > > > 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? I haven't tried with svn, but you can probably "ssh -N <host>" first and leave that open until you're finished.
