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.

Comments

Dustin said…
Hey Richard,

Is Brazil competing in some cracker challenge? :)

http://blog.netjitsu.net/2007/02/cisco-ios-display-bug.html
Anonymous said…
There is one thing to consider, however. You mentioned that Sguil didn't alert on this traffic, which could pose problems if analysts rely on one 'main' tool to begin the investigative process. This has been a long-time problem with IDS tools; if a signature doesn't exist, the security event may not be 'caught'. The longer I work with an IDS centric defense approach, the more I see it as a shortcoming in attempting to detect security events on a network or infrastructure. SAGE SysAdmin #12 "Building a Logging Infrastructure" and "Security Log Management" by Sygnress help to show that IDS data should only be one of several inputs for the alerting process. Unfortunately, Snort doesn't widely detect rate based attacks (DDos, unless looking for a specific type of packet related to one), and could lead to a late arrival in detection and defense. Understandably, nothing will catch everything, however, utilizing tools that rely on 'signatures of known activity' may not be the best approach either. Taking in IDS data, along with other network events (such as traffic throughput and host logs) to generate an alert, and then using session data for verification, may be a better way to tackle the problem.
Anonymous -- not to be rude, but you must be new here. I certainly don't rely on alerts as you seem to imply, and neither does my NSM process.
Anonymous said…
Hi Richard,

I am happy to see that you are now using ossec. However, in the same way that you have your independent network sensor you should have your independent log server. You should never go directly to the box that generated the alert to look at more logs...

In case of an alert like that, you could go to the log server and check for other events from the same IP (same thing you did with Sguil). If you have your firewall logs, you would be able to see all connections (denied and allowed) from this IP or any authentication related event.

Thanks,

Daniel Cid
Anonymous said…
This comment has been removed by a blog administrator.
Anonymous said…
Hello.Yes its the latest and greatest 31337 attack.Contact me for details at packetgod[at]gmail.com
Anonymous said…
< QUOTE SNIP >

I am happy to see that you are now using ossec. However, in the same way that you have your independent network sensor you should have your independent log server. You should never go directly to the box that generated the alert to look at more logs...

< / QS>

Ouch...indeed. And there's nothing new or cutting edge about a remote log server. Logging to multiple machines is even more insurance.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics