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
Protocol: 6 sport=10000 -> dport=3372
Seq=3640110148 Ack=536397245 Off=5 Res=0 Flags=***A**** Win=65535 urp=15810
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
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;
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
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.