|
|
|
|
Snort Forums Archive
Archive Home » Rules » False Positive with SID 1948
Please note that the categories listed below represent an archived version of our forums pages. To view the current version and be able to post and reply to threads, please register and login here to go to the full forums pages.
[ Notice: Full Version of This Topic ]
False Positive with SID 1948
Posted by BruceBriggs on April 05, 2005 07:11:24
SID 1948 DNS zone transfer UDP
source port = 53
dest port = 53
If a DNS server within $HOME_NET accesses a DNS server on $EXTERNAL_NET and the $HOME_NET DNS server choose a source port = 53 for the conversation, then a response packet from the $EXTERNAL_NET DNS server on port 53 is a false positive for a UDP Zone transfer request to the $HOME_NET DNS server.
|
|
Posted by nigel on April 05, 2005 09:52:19
Have you observed this situation? Is the external DNS server a secondary name server for your domain? Do you have packet captures to show this event?
The content match indicates a zone transfer request, this content should not occur in a reply to such a request. |
|
Posted by BruceBriggs on April 05, 2005 11:16:05
Yes I had some packets within the last 2 weeks.
I've deleted them a few days ago and set up a PASS so I don't have any right now.
I'll turn off my PASS statements and get some for you. |
|
Posted by BruceBriggs on April 05, 2005 11:35:51
OK, here you go.
I have 4 already.
Output from BASE 1.1:
Source IP Addr: 195.188.53.113 ns2.blueyonder.co.uk
Dest IP addr: 141.254.1.11 ns.suny.edu
Source Port 53 UDP
Dest port 53 UDP
Payload:
length = 205
000 : F2 83 84 90 00 01 00 01 00 03 00 04 0C 38 32 2D .............82-
010 : 33 36 2D 31 36 34 2D 36 36 05 63 61 62 6C 65 05 36-164-66.cable.
020 : 75 62 72 30 35 04 70 65 72 72 0A 62 6C 75 65 79 ubr05.perr.bluey
030 : 6F 6E 64 65 72 02 63 6F 02 75 6B 00 00 01 00 01 onder.co.uk.....
040 : C0 0C 00 01 00 01 00 00 70 80 00 04 52 24 A4 42 ........p...R$.B
050 : C0 19 00 02 00 01 00 00 70 80 00 05 02 6E 73 C0 ........p....ns.
060 : 2A C0 19 00 02 00 01 00 00 70 80 00 06 03 6E 73 *........p....ns
070 : 32 C0 2A C0 19 00 02 00 01 00 00 70 80 00 13 03 2.*........p....
080 : 6E 73 33 09 63 61 62 6C 65 69 6E 65 74 03 6E 65 ns3.cableinet.ne
090 : 74 00 C0 5C 00 01 00 01 00 00 70 80 00 04 C3 BC t..\......p.....
0a0 : 35 72 C0 6D 00 01 00 01 00 00 70 80 00 04 C3 BC 5r.m......p.....
0b0 : 35 71 C0 7F 00 01 00 01 00 00 FC AB 00 04 C2 75 5q............u
0c0 : 98 55 00 00 29 10 00 00 00 00 00 00 00 .U..)........
Let me know what else you need.
|
|
Posted by BruceBriggs on April 05, 2005 11:36:09
OK, here you go.
I have 4 already.
Output from BASE 1.1:
Source IP Addr: 195.188.53.113 ns2.blueyonder.co.uk
Dest IP addr: 141.254.1.11 ns.suny.edu
Source Port 53 UDP
Dest port 53 UDP
Payload:
length = 205
000 : F2 83 84 90 00 01 00 01 00 03 00 04 0C 38 32 2D .............82-
010 : 33 36 2D 31 36 34 2D 36 36 05 63 61 62 6C 65 05 36-164-66.cable.
020 : 75 62 72 30 35 04 70 65 72 72 0A 62 6C 75 65 79 ubr05.perr.bluey
030 : 6F 6E 64 65 72 02 63 6F 02 75 6B 00 00 01 00 01 onder.co.uk.....
040 : C0 0C 00 01 00 01 00 00 70 80 00 04 52 24 A4 42 ........p...R$.B
050 : C0 19 00 02 00 01 00 00 70 80 00 05 02 6E 73 C0 ........p....ns.
060 : 2A C0 19 00 02 00 01 00 00 70 80 00 06 03 6E 73 *........p....ns
070 : 32 C0 2A C0 19 00 02 00 01 00 00 70 80 00 13 03 2.*........p....
080 : 6E 73 33 09 63 61 62 6C 65 69 6E 65 74 03 6E 65 ns3.cableinet.ne
090 : 74 00 C0 5C 00 01 00 01 00 00 70 80 00 04 C3 BC t..\......p.....
0a0 : 35 72 C0 6D 00 01 00 01 00 00 70 80 00 04 C3 BC 5r.m......p.....
0b0 : 35 71 C0 7F 00 01 00 01 00 00 FC AB 00 04 C2 75 5q............u
0c0 : 98 55 00 00 29 10 00 00 00 00 00 00 00 .U..)........
Let me know what else you need.
|
|
Posted by mwatchinski on April 06, 2005 12:16:17
Forums probably isn't the best place for packet data.
Do you mind sending a quick write up and pcap to "vrt [at] sourcefire.com"
and we'll get someone looking at it.
Thanks |
|
Posted by adam on December 11, 2006 11:44:47
I've also noticied many false positives with this rule, but I've had some time to decode the payloads. What I've found is that the snort signature has been matching on the TTL value of the resource records. The TTL field is 4 octets and it is not uncommon (in my experience) for it to begin with '00 00 FC'.
RFC 1035 says that the QTYPE field is followed by the QCLASS field. Both fields are two octets. As far as I can tell only the second octet of the QCLASS field will ever be used, so it may be possible to modify the signature to match some or all of the QCLASS field as well to reduce the false positives.
I think we could get by with '00 00 FC 00'. Otherwise a match of '00 00 FC 00 01' or '00 00 FC 00 FF', which would capture Internet class queries and the all classes' wildcard value.
|
|
|
|
|
|
