Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [Snort-sigs] odd rule behaviour ??? |
|---|---|
| Date: | Tue, 29 Nov 2005 11:04:57 +1300 |
Here we have an old rule which detects UDP traffic with a destination
port of 0.
alert udp $EXTERNAL_NET any <> $HOME_NET 0 (msg:"BAD-TRAFFIC udp port 0
traffic"; reference:bugtraq,576; reference:cve,1999-0675;
reference:nessus,10074; classtype:misc-activity; sid:525; rev:9;)
Recently I started getting lots of hits on this rule (60,000 a day) and
I decided to add something to the threshold file to keep the noise down.
Then I noticed that the traffic that is triggering the rule has a
*source* port of zero, not a destination port of zero. Now I'm sorely
puzzled - some one please tell me there is a straight forward
explanation and that I'm an idiot :)
Here is a dump of a packet that caused this rule to trigger:
META
--------
SID CID TimeStamp Signature
6 6044755 2005-11-28 10:57:23 BAD-TRAFFIC udp port 0 traffic
Sig ID
525
Sensor Hostname Sensor Interface
hihi.insec.auckland.ac.nz new dmz sensor
IP
--------
Source Address Dest Address Ver Hdr Len
179.188.7.0 130.216.139.1 4 5
TOS length ID flags offset TTL chksum
0 519 55732 0 0 52 58011
Resolved Source
Could Not Resolve
Resolved Dest
mcmu01.auckland.ac.nz
UDP
--------
Source Port Dest Port Length Checksum
0 1025 499 0
DATA
--------
04007800100000000000 ..x.......
00000000000000000000 ..........
00000000F8917B5A00FF ......{Z..
D011A9B200C04FB6E6FC ......O...
00000000000000000000 ..........
00000000000000000000 ..........
01000000000000000000 ..........
FFFFFFFF980100000000 ..........
0A000000000000000A00 ..........
00004D6963726F736F66 ..Microsof
74000000230000000000 t...#.....
000023000000696E666F ..#...info
726D20796F752061626F rm you abo
75742061207669727573 ut a virus
20646574656374696F6E detection
00004201000000000000 ..B.......
.....
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [Snort-sigs] new rule for detect icmp undefined code (>18), rmkml |
|---|---|
| Next by Date: | Re: [Snort-sigs] odd rule behaviour ???, Frank Knobbe |
| Previous by Thread: | [Snort-sigs] new rule for detect icmp undefined code (>18), rmkml |
| Next by Thread: | Re: [Snort-sigs] odd rule behaviour ???, Frank Knobbe |
| Indexes: | [Date] [Thread] [Top] [All Lists] |