[nycbug-talk] SSH attacks

[Yarema]

George Rosamond wrote:
> Yarema wrote:
>> Steven Kreuzer wrote:
>>> Yarema wrote:
>>>> Hey, is anyone else seeing an upsurge in distributed SSH attacks over
>>>> the past week or two?
>>>>
>>>> This annoyed me enough to get me reading The Book of PF.  I've been
>>>> using the BlockSSHd script to block and send me notices by watching
>>>> auth.log.  Problem was that durring heavy attacks my INBOX would get
>>>> fooded.  And the reaction time was a bit slow.
>>>>
>>>> A couple of meetings ago Steven Kreuzer suggested I use PF's
>>>> max-src-conn method.  Works like a charm. 
>>> Glad I can help. I will send you the routing number for my Cayman Island
>>> offshore holding subsidiary
>>> and you can just deposit my consulting fee into that
>>>
>>>> I also use the pam_af plugin.  It never gets a chance to block
>>>> anything,
>>>> but provides useful info on when and where a login was coming from.
>>>>   
>>> Out of curiosity, would you be able to take the IPs you are blocking and
>>> try and figure out
>>> the country most of these connections are coming from?
>>>
>>> If you don't ever expect to get connections from China and Korea, you
>>> can load the following
>>> into pf and pretend like they don't even exist.
>>>
>>> http://www.openbsd.org/spamd/chinacidr.txt.gz
>>> http://www.openbsd.org/spamd/koreacidr.txt.gz
>>
>> Just found an interesting resource:
>> http://www.DShield.org/port.html?port=22
>>
>> The Targets/Day graph for September correspond to what I've been
>> experiencing.  Any idea how they collect the data?
> 
> I've peripherally followed DShield for a while. . . and not sure how
> they collect, but it's a cool project.  I am not using anywhere.
> 
> I mean, if you update spamd with Beck's list. . . you're using one large
> list he centralizes and updates. ..  DShield is doing the same with more
> complex data from a larger pool.  SANS has a nice network of people.

Yeah, for spamd there's no better than using all the goodies Beck
provides.  I've been using his greyscanner script to preemptively
blacklist spammers for a few years now.  Good stuff.

> On the original thread issues. . . I do the following, usually:
> 
> 1.  move sshd to a nonprivileged port. . . Max's point is valid, but
> those who argue that it's 'security through obscurity' miss the point.
> It's not about security, it's about not having annoying zombies eat up
> system resources and spam auth logs.  That's the goal of moving it to
> another port. . . nothing else.  I was convinced of this a while back
> when someone explained how they moved sshd to another port on a heavily
> hit box, and boom, system utilization plummeted.

I get the point that it's about protecting CPU & IO resources.  I've
been under pretty much non stop attack for over a week now.  Today has
been especially heavy.  Starting around 9AM and they're still at it.
This level of attack used to bring my servers to their knees.  Unable to
log in at all, etc.  Today, with PF tuned to max-src-conn-rate 5/3 on
the ssh port, I wouldn't even know I was under attack if I hadn't been
watching how it behaves.

The only load spike on the firewall causing it to be unresponsive for a
minute or so was because I ran nmap -O in parallel on every IP address
in the blocked table.  Oops.  Should've had the patience to run it on
each IP at a time.  Lesson learned.  Don't background nmap in a loop
like this one:

pfctl -t badhosts -T show | while read adr
do { nmap -O ${adr} >& /tmp/${adr} &! }
done

:)  FreeBSD never dropped a packet and didn't fail over even though
system load shot up above 20 something and I couldn't type or log in
until it calmed down.

> 2.  black listing certain countries.  There's a lot of countries no one
> needs access from. . . block them.  There's lots of links to find
> country net blocks. . . even if Nigeria is part of Britain and other
> confusions.  Dump them to text and put them in as a table in pf or
> /etc/hosts.allow.  (so so old school. . .)

Not really an option for me cuz I serve users in countries I don't even
know, nor do I know why my clients have a presence there.  Same goes for
non standard ports.  Dealing with support issues on the level of
"someone put an icon on my desktop to run dreamweaver to update the
site.  What's ssh?" ... not something I wanna get into.

> 3.  AllowUsers is cool also.  Nice tip from Max from that past NYCBUG
> meeting.
> 
> 4.  Keys keys keys. . . that is *the* security component here that is
> meaningful.  2 & 3 lightly augment security, but this is the only thing
> that really matters, IMHO.
> 
> On the most recent attacks. . . I haven't seen them, since the zombies
> aren't hitting the alternate sshd port.
> 
> But I've seen that quirky attack before. . . it's basically a
> distributed ssh brute force zombie attack (aka DSBFZA? :)
> 
> Clearly, it's a bit more sophisticated than past zombie attacks, but
> inevitably it's just as meaningless as a security risk.

Dunno if it's all that much more sophisticated.  All I can tell is that
the DSBFZA is coordinated.  They go alphabetically and the same login
will be tried from many different IPs until they move on to the next
login.  I suppose that's how they get more than one crack at each login
since they're getting blocked now after one maybe two attempts.  They
are definitely more persistent and they probably have a larger pool of
zombies to unleash.  My badhosts table had at most 105 IPs blocked at
one time today.  I expire the blocked IPs after one hour.  I'll probably
raise that to a few more hours.  I wanted to ensure any false positives
would clear reasonably quickly if I wasn't around.

-- 
Yarema