SSHd attack?

[Chris]

A few minutes ago one of my servers become unresponsive via SSH, after
checking my auth.log i soon found out why;

Sep 11 17:16:46 sandbox sshd[63191]: Did not receive identification
string from 201.223.78.194
Sep 11 17:16:46 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:47 sandbox last message repeated 19 times
Sep 11 17:16:47 sandbox sshd[63192]: Did not receive identification
string from 201.222.183.31
Sep 11 17:16:47 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:47 sandbox last message repeated 8 times
Sep 11 17:16:47 sandbox sshd[63183]: Did not receive identification
string from 190.232.240.248
Sep 11 17:16:47 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:47 sandbox sshd[63195]: Did not receive identification
string from 190.27.7.144
Sep 11 17:16:47 sandbox sshd[63196]: Did not receive identification
string from 189.129.20.137
Sep 11 17:16:47 sandbox sshd[63149]: Did not receive identification
string from 148.239.131.135
Sep 11 17:16:47 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:48 sandbox last message repeated 19 times
Sep 11 17:16:48 sandbox sshd[63194]: Did not receive identification
string from 201.160.145.71
Sep 11 17:16:48 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:50 sandbox last message repeated 45 times
Sep 11 17:16:50 sandbox sshd[63169]: Did not receive identification
string from 200.83.77.61
Sep 11 17:16:50 sandbox sshd[63187]: Did not receive identification
string from 200.83.77.61
Sep 11 17:16:51 sandbox sshd[63203]: Did not receive identification
string from 200.83.77.61
Sep 11 17:16:51 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:51 sandbox last message repeated 4 times
Sep 11 17:16:51 sandbox sshd[63205]: Did not receive identification
string from 190.157.225.139
Sep 11 17:16:51 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:51 sandbox sshd[63200]: Did not receive identification
string from 190.160.201.96
Sep 11 17:16:51 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:53 sandbox last message repeated 58 times
Sep 11 17:16:53 sandbox sshd[63201]: Did not receive identification
string from 200.106.199.131
Sep 11 17:16:53 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:55 sandbox last message repeated 47 times
Sep 11 17:16:55 sandbox sshd[63208]: Did not receive identification
string from 200.35.169.230
Sep 11 17:16:55 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:16:55 sandbox last message repeated 3 times
Sep 11 17:16:55 sandbox sshd[63212]: Did not receive identification
string from 190.47.221.64
Sep 11 17:16:55 sandbox sshd[17125]: error: accept: Software caused
connection abort
Sep 11 17:17:01 sandbox last message repeated 247 times
Sep 11 17:17:01 sandbox sshd[63204]: Did not receive identification
string from 189.175.33.180
Sep 11 17:17:01 sandbox sshd[17125]: error: accept: Software caused
connection abort

There was 1000s of such lines. The offenders have been banned now but
I'm posting this message to warn other users if they haven't come
across this type of attack before and also to remind myself to make a
decoder and matching rule in the morning so that Ossec picks this up
in the future.

Chris

[Kevin Reiter]

Chris wrote:
: A few minutes ago one of my servers become unresponsive via SSH, after

: checking my auth.log i soon found out why;
:
: Sep 11 17:16:46 sandbox sshd[63191]: Did not receive identification
: string from 201.223.78.194
: Sep 11 17:16:46 sandbox sshd[17125]: error: accept: Software caused
: connection abort

<snip>

: Sep 11 17:17:01 sandbox sshd[17125]: error: accept: Software caused

: connection abort
:
: There was 1000s of such lines. The offenders have been banned now but
: I'm posting this message to warn other users if they haven't come
: across this type of attack before and also to remind myself to make a
: decoder and matching rule in the morning so that Ossec picks this up
: in the future.
:
: Chris

You can do a number of things on the box (aside from OSSEC) to help with this:
- Edit sshd_config and use the 'AllowUsers' option to limit which users can SSH in.
- Configure your firewall to only allow incoming connections to tcp/22 from trusted hosts.
- Block countries you're sure don't have any legitimate reason for connecting (i.e. China, Korea, etc.)

There were a lot of discussions about this in the past few days across various lists, since it seems there was a spike on this. Google should be caught up now with the threads...

hth

-Kevin

This message may contain confidential or proprietary information and is intended solely for the individual(s) to whom it is addressed. If you are not a named addressee you should not disseminate, distribute or copy this e-mail or act upon the information contained herein. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.

[Chris]

Hi Kevin,
Thanks for your input, I have taken your ideas on board. In case
anyone is interested here is an OSSEC configuration that works well
for me;

decoder.xml:

<decoder name="ssh-scan2">
<parent>sshd</parent>
<prematch>^Did not receive identification|^Bad protocol version</
prematch>
<regex offset="after_prematch"> from (\d+.\d+.\d+.\d+)$</regex>
<order>srcip</order>
</decoder>


sshd_rules:

<rule id="5706" level="4">
<if_sid>5700</if_sid>
<match>Did not receive identification string from</match>
<description>SSH insecure connection attempt (scan).</description>
</rule>

<rule id="100160" level="10" frequency="4" timeframe="360">
<if_matched_sid>5706</if_matched_sid>
<description>Possible scan or breakin attempt </description>
<description>(high number of identification failures).</
description>
</rule>


You may or may not need to change some things such as the rule
id="100160". Also note that the decoder rule (and sshd rule 5706)
probably already exists for you but I changed it a bit. This works
fine for me by banning hosts who give me four identification failures
in 360 seconds.

Chris

[cnk]

Hey Kevin,

I don't think it was necessary to modify the decoder since the current
decoder decodes that log line fine. Were you having issues with the
decoder?

Your custom rule should be all you need to alert on this kind of attack.

Cheers,

cnk

[Jimi Schwar]

I am having trouble building OSSEC on Leopard 10.5.5. Everything seems
to go fine until I get to this point:

*** Making os_maild ***

gcc -g -Wall -I../ -I../headers -DDEFAULTDIR=\"/var/ossec\" -DCLIENT
-DUSE_OPENSSL -DDarwin -DHIGHFIRST -DARGV0=\"ossec-maild\"
-DXML_VAR=\"var\" -DOSSECHIDS maild.c config.c os_maild_client.c
sendmail.c mail_list.c ../config/*.c ../shared/lib_shared.a
../os_net/os_net.a ../os_regex/os_regex.a ../os_xml/os_xml.a -o ossec-maild
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld:
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libSystem.dylib unknown
flags (type) of section 6 (__TEXT,__literal16) in load command 0
collect2: ld returned 1 exit status
make[1]: *** [maild] Error 1

Error Making os_maild
make: *** [all] Error 1

Error 0x5.
Building error. Unable to finish the installation.

Does anyone have any suggestions or instruction about how to build the
software on Leopard?

Thanks in advance

Jimi

[Chris]

Hi cnk,
I guess you meant to direct that message to me. Your probably right
about the decoder.xml not needed to be changed but I did mess around
quite a bit and forgot exactly what I had and hadn't changed so I
thought I'd include all relevant code. My advice to other users
wanting to include support for this type of log is to start off by
adding just the second of the two rules I included and then testing to
see if the log is picked up and dealt with in the right way (http://
www.ossec.net/dcid/?p=136). However, as far as I know OSSEC doesn't
support testing of rules that watch for multiple logs in a specified
time frame (rules that include frequency="x" timeframe="x") so for
that I do a bit of manual testing like so;

# echo 'Sep 11 07:07:02 sandbox sshd[91780]: Did not receive
identification string from 99.99.99.99' >> /var/log/auth.log
# echo 'Sep 11 07:07:02 sandbox sshd[91777]: Did not receive
identification string from 99.99.99.99' >> /var/log/auth.log
# echo 'Sep 11 07:07:02 sandbox sshd[91779]: Did not receive
identification string from 99.99.99.99' >> /var/log/auth.log
# echo 'Sep 11 07:07:02 sandbox sshd[91778]: Did not receive
identification string from 99.99.99.99' >> /var/log/auth.log
# echo 'Sep 11 07:07:02 sandbox sshd[91776]: Did not receive
identification string from 99.99.99.99' >> /var/log/auth.log

Note: You may need to modify this to match the location of your auth
log.

After a few seconds the custom OSSEC rule should pick this up and send
you an alert.

Chris

[Jimi Schwar]

I solved my own problem. Upgrading Xcode tools to 3.1.1 (the leopard
verison) from 2.5 (the tiger version) fixed it. Sorry to bug the list
with this.