I See You

In recent posts like Consider This Scenario, I posted information collected from my live network connection. I don't worry about exposing real data, as long as it belongs to my own network. I obviously don't expose client data!

Today I received a new alert from OSSEC:

OSSEC HIDS Notification.
2007 Feb 08 09:46:13

Received From: macmini->/var/log/auth.log
Rule: 5701 fired (level 12) -> "Possible attack on the ssh server
 (or version gathering)."
Portion of the log(s):

Feb  8 09:46:11 macmini sshd[21224]: Bad protocol version identification
 'Yo. I just read your blog about this SSH server'
 from ::ffff:201.11.74.161

Interesting. Here is an OSSEC alert -- but is there anything else? How many people think I should check my macmini host again? Rather than poke around on that box, I first check my independent NSM Sguil sensor to see what it says about the event.

I didn't see any Snort alerts, so I did a session query and got one result.

Sensor:cel433 Session ID:5029174672303084694
Start Time:2007-02-08 14:46:16 End Time:2007-02-08 14:46:39
201.11.74.161:60096 -> 69.143.202.28:22
Source Packets:6 Bytes:49
Dest Packets:6 Bytes:60

This is probably the connection that prompted the OSSEC alert. I can generate a human-readable transcript of the event. Here's what that looks like.

Sensor Name:    cel433
Timestamp:      2007-02-08 14:46:16
Connection ID:  .cel433_5029174672303084694
Src IP:         201.11.74.161   (201-11-74-161.jvece7004.dsl.brasiltelecom.net.br)
Dst IP:         69.143.202.28   (c-69-143-202-28.hsd1.va.comcast.net)
Src Port:               60096
Dst Port:               22
OS Fingerprint: 201.11.74.161:60096 -
 Linux 2.6, seldom 2.4 (older, 4) (NAT!) [priority1] (up: 33 hrs) 
OS Fingerprint:   -> 69.143.202.28:22
 (distance 20, link: pppoe (DSL))

DST: SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.6
DST: 
SRC: Yo. I just read your blog about this SSH server
SRC: 
DST: Protocol mismatch.
DST: 

As you can see, someone from an IP in Brazil connected to port 22 TCP, entered the string you see, and then disconnected.

The nice aspect of having this sort of data available is I can see exactly what transpired for this event. I queried and found only one session from the .br IP. I can query on the destination (my) IP for other connections to port 22 TCP, and see other activity from Hong Kong that resulted in no successful connections. There is no guesswork or assumptions that need to be made. I have real data and can make real judgments about what is happening.

Is this the latest and greatest uber 31337 attack? Of course not. Is this the ultimate mega network carrying umpteen billion bps? Nope. However, you will find these methods will help you when something more significant is happening. Here, as elsewhere in my blog, I use small, simple cases to try to illustrate lessons from bigger cases that may not be suitable for public discussion.