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
2:17 PM
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.
11:42 AM
Richard Bejtlich said…
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.
2:54 PM
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
1:30 PM
Anonymous said…
This comment has been removed by a blog administrator.
6:17 AM
Anonymous said…
Hello.Yes its the latest and greatest 31337 attack.Contact me for details at packetgod[at]gmail.com
3:55 AM
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.
4:40 PM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technical or pol
Read more