[nycbug-talk] Analyzing malicious SSH login attempts

[Jeff Quast]

On 9/13/06, Isaac Levy <ike at lesmuug.org> wrote:
> Hi All,
>
> Some SSH food for thought,

yummy

> On Sep 12, 2006, at 2:54 PM, csnyder wrote:
>
> >> I think parsing logs and injecting rules is just plain ridiculous.
> >> Especialy using 3rd party languages not native to your OS. Its just
> >> more custom stuff to re-implement on the next os rebuild.
> >
> > Look, I know it's ridiculous, but it's also more portable (for now)
> > than pf.
>
> Forgive my possible naiveté, but how does any ssh/packet-filter
> incorporation strategy really secure anything, big picture
> (regardless of the implementation)?
>
> What happens when ssh passwords come under distributed dictionary
> attack by a botnet (many IP addresses)?  Wouldn't it render the
> filter moot, and perhaps even create a resource attack as a side
> effect of dynamically loading gargantuan filter rulesets?

your pf rule for always allowing pass in from your administrative
machine would still alow you to log in. Your pf rule for allowing only
so many connections per state per time, and only so many global
connections globally would prevent this botnet from attempting any
more than X per Y seconds.

Serial ports are found on all server equipment for a good reason. Let
sshd crash from resource exhaustion. You have other things to worry
about at this point, but ssh is not the only point of entry from an
administrator viewpoint.

> What happens when an attacker spoofs the IP addresses you use, with
> the effect of blocking you from your own systems?

That wouldn't happen with the option i recommended. Its a stateful
tracking option. You can't create state with a spoofed IP (syn+ack
networking 101).

> --
> Additionally, what happens when SSH itself meets it's inevitable zero-
> day (could be tomorrow, could be 50 years from now)?  Doesn't any
> complicated intermingling with other parts of the system make ssh
> that much more difficult and error prone to replace quickly?

ssh is extremely easy to upgrade. If you're so paranoid then you're
subscribed to all of the announcement lists? development lists? Your
OS manages your software well, doesn't it?

> I'm not lookin' to pick a flame-fight, I'm just discussing, and I
> feel many packet-filter strategies give a false sense of security.
> Convince me it's a sane strategy, and I'll likely go implement it
> tomorrow :)

Whats your alternative? Use telnet with no packet filter?

> Rocket-
> .ike

I repeat, brute forcing is nothing new at all. There are very very
very simple solutions to enforce strong passwords, I already listed
these. Now this discussion has wandered off into brute forcing ssh
keys. I would like to see this done successfully for even a smaller
than default keysize. Brute forcing an ssh key would take a very
strong machine a very long time to crack locally.

Now add tcp/ip and the Internet to this, and we're talking several
lifetimes... make a botnet and we're talking a single lifetime.

Then we're talking a filled /var from the size of the logfiles of bad guesses.

Make a botnet to guess stupidly easy and predictable passwords and you
have thousands of more poorly administered machines to add to your
botnet. That they were running ssh is of no correlation, they would
have joined a botnet sooner or later (or may be part of many!).

I've done an nmap on a few dozen of these "brute forcers" out of
curiosity. I have found most of these machines to have telnet open,
vulnerable sendmail versions, redhat linux from the mid-90's,
vulnerable ftp servers with anonymous upload access (sometimes used as
warez sites). Even stupidly old sun os running network services I
haven't seen or heard of for nearly a decade.

That these machines had an easily guessable password and were hacked
in this method is totally unrelated. I have yet to see a secure or
modern BSD machine as a victim. All but one (the SunOS) that I could
identify were linux machines of old or poor distributions. I suspect
many of these were not hacked through ssh passwords, they are often
acting as web servers with commonly vulnerable php software etc.

For some of these I have been able to find a contact and emailed or
called to let them know. I have only done this a dozen times or so
over the years, because as a result sometimes I am suddenly suspected
as the person who broke into their box, or I get flood of mails from
corporate management asking me how to fix it and how it happened etc.
etc. Being nice can take too much time. I haven't done this in over a
year now, I'm not so sure I'd do it again since the last time I was
damn near made at fault.

I really truly think it is not ssh's responsibility to have a "prevent
brute forcing" option of some kind. The ssh daemon running while uid 0
almost does more than I am comfortable with as it is. Outside of an
authenticated user's context (and so setuid()'d), I wouldn't like to
see any more features added at all.

There is snort, john the ripper, a plethora of unix tools to automate
it all and communicate results and reporting. Advanced firewalls can
limit heavy distributed brute forcing to a trickle, making the
possibility of bruting within your lifetime a feat. Your pager and
cellphone could go off long before they get the chance.


There is disabling passwords all together, there are ssh
keys+passphrases, there are ssh agents for every OS I've ever used
that make keys easy to manage despite what others have said here. When
I log in to my xdm I have it set to run ssh-add (and get the nifty x11
frontend!) for several keys. ssh-add -x locks those keys when I'm not
around. I forward these keys to trusted machines. I type my
passphrases only once in a great while. Like three times a week per
key, yet I use them several times a day for authenticating. 10 minutes
of work has made managing ssh accounts extraordinarily easy for me.

As for worrying about a zero-day, sshd is the least of your problems.
Using an OS with strong stack protection and memory allocation
protections, many potential sshd vulnerabilities are thwarted, and the
developers of ssh, though a few small embarrassing problems early on,
have taken great care to write correct code. Some software code (or
disassembly) is looked at by dozens of experienced hackers every day.
ssh is no exception, having your own back-door hack to sshd is a bit
of a holy grail these days.

Since there seems to be so much discussion and interest on ssh, I
recommend the O'Reilly book on it,
http://www.oreilly.com/catalog/sshtdg/

jdq