[nycbug-talk] SSH attacks

[George Rosamond]

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.

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.

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. . .)

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.

g