----- Original Message -----
From: "Stuart Henderson" <[EMAIL PROTECTED]>
To: "OpenBSD" <misc@openbsd.org>
Sent: Monday, August 13, 2007 1:30 PM
Subject: Re: [misc] SSH brute force attacks no longer being caught by PF
rule
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.
maybe somewhat off-topic, but:
why don't you just switch your ssh port to a different one.
we've been running with this configuration since years and
a log examination of the ssh-logs and connection logs from
the firewall shows that there was not even 1 (!) connect to
the ssh-port from "bad" IPs.
