Re: [bitfolk] The perils of opening tcp/22 to the Internet

HI James,

On Sun, Mar 14, 2010 at 09:12:08AM +0000, James Gregory wrote:
> Hi Andy et al,
>
> > This very long email is about possible pro-active measures I could
> > take to prevent customers being compromised by SSH dictionary
> > attacks.
> *snip*
>
> Yes, a very long email :)

Thanks for reading.

> > 6) Move sshd to another port.
>
> More of a security by obscurity approach, but it would limit the
> inbound attacks.

Indeed, but as I haven't seen individual customers targeted, just
moving the SSH port takes people out of the pool of potential
victims.[1]

Then again, so does doing almost anything else to protect yourself,
so I don't think anyone need feel bad about keeping their SSH on
port 22 as long as they know the risks.

> > More?
>
> I don't really know how you 'filter' outbound connections (I expect
> little is done)

Ah yes, I should have gone into that.

The hosts have a ulog target in their outbound iptables rules to log
all port 22 SYN packets, and I just monitor the "background" rate of
these to work out what is normal.

4 in 15 minutes is normal; 1000+ isn't. :)

> but could you set up an outbound SSH rule that dropped any
> connections from a server that was making, say, 100 hundred
> outbound connections in 10 seconds? Would any server have a
> legitimate reason for doing this? It wouldn't stop the compromised
> host, but it would limit the possibility of them compromising
> other hosts.

Interesting idea. You're right that slowing down outbound SSH to
10/second or 100/10 seconds would severely limit SSH scanning to the
point of uselessness,

It would also interfere with legitimate scanning like pentests and
probably also remote monitoring (Nagios can be quite aggressive), so
would definitely have to be opt-out.

I'll have a think about it but my immediate thoughts are that I'm
loathe to do it because of the inconvenience for legitimate users,
and the amount of extra state it's going to involve keeping on the
host machines.

I'd still like to focus on what can be pro-actively done to stop us
getting to the point of having to try to contain an SSH scanning
run.

On that topic, it could of course be done inbound! I missed off
rate-limiting in the firewall as one of the ways people defend
against SSH dictionary attacks. BitFolk could actually do that for
you. Not sure I want to be responsible for that, or keep the state
though...

Cheers,
Andy

[1] If I was writing an ssh scanner I might be tempted to try ports
1222, 2222, 2022, etc. if 22 was blocked. It's only a handful
more connections when you're going to do thousands anyway if you
find the right port. At some point, trying all 65k ports will
be nothing compared to how many connections you'll make once you
find the open port. I've got TCP/22 SYN logs going back a few
months so I could work out how many tried