Port-based Alerts Are a Bad Idea

For my 1700th post (as reported by the new Blogging infrastructure) I thought I would report on an issue I'm looking at in Sguil right now.

I have 1586 of the following alerts like the following aggregated in my Sguil console. This is the text representation.

Count:1 Event#1.130182 2006-12-15 15:57:32
DOS MSDTC attempt
a.b.c.d -> e.f.g.h
IPVer=4 hlen=5 tos=0 dlen=1388 ID=16858 flags=0 offset=0 ttl=55
 chksum=38030
Protocol: 6 sport=10000 -> dport=3372

Seq=3640110148 Ack=536397245 Off=5 Res=0 Flags=***A**** Win=65535 urp=15810
 chksum=0
Payload:
35 69 86 C2 00 00 04 1E B1 B6 7E 19 FC 4A 28 87 5i........~..J(.
18 7C 2E F4 12 68 F1 79 66 F6 D0 17 D0 26 5A 48 .|...h.yf....&ZH
C6 0A 54 AB 58 42 9A F4 83 7A 85 3F E3 40 AD CB ..T.XB...z.?.@..
AF 1C 03 EE DE CD 38 94 1E 1F 55 8C 99 E8 1A 4E ......8...U....N
...truncated...

They were caused by this rule:

alert tcp $EXTERNAL_NET any -> $HOME_NET 3372 (msg:"DOS MSDTC attempt"; 
flow:to_server,established; dsize:>1023; reference:bugtraq,4006;
reference:cve,2002-0224; reference:nessus,10939; classtype:attempted-dos;
sid:1408; rev:11;)

Basically this says any packet with more than 1023 bytes of application data to port 3372 TCP will generate an alert, although the flow keyword says the packet should be from a client to a server.

I think this is really traffic from a client (e.f.g.h) using source port 3372 TCP to a server (a.b.c.d) using destination port 10000 TCP, perhaps Veritas backup?

One way to validate that idea is to find other sessions involving a.b.c.d and e.f.g.h, where a.b.c.d is also offering port 10000 TCP. Sure enough, when I check Sguil and look at sessions involving those IPs, I find exactly that.

If you really need to see what is happening, you look for full content data and find the actual three way handshake:

10:47:15.932338 IP e.f.g.h.3372 > a.b.c.d.10000: S 536218454:536218454(0) win 65535
10:47:15.959516 IP a.b.c.d.10000 > e.f.g.h.3372: S 3638950519:3638950519(0)
 ack 536218455 win 65535
10:47:15.970914 IP e.f.g.h.3372 > a.b.c.d.10000: . ack 1 win 65535
10:47:16.886497 IP e.f.g.h.3372 > a.b.c.d.10000: . 1:871(870) ack 1 win 65535
...truncated...

I used to cringe when our Air Force ASIM sensors fired alerts on port 1524, causing hours of wasted analyst time. Thankfully our tools for inspecting these sorts of alerts have improved, although the rationale behind rules like this is still weak.

Comments

Dan Weber said…
Ah, dear old ASIM. It's been a long time.

Goes to show the old rule about failing to learn about history, I guess.
10:30 AM
Anonymous said…
Port TCP 10000 screams Cisco VPN. If one does IPSec encapsulated it defaults to UDP 10000 but will use TCP if the VPN concentrator can't be reached.

Have you seen anything that looks like encapsulated IKE, ESP, or AH?

Thomas
2:36 PM
Richard Bejtlich said…
Thomas,

Aha, I bet you are right. A VPN is far more likely. I don't see anything that looks like those protocols, but I still think you're right.
2:48 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