log queries to specific TLDs

NogBadTheBad

Is there any way to be able to log queries to specific TLDs rather than everything in DNS Resolver?

I'm getting the following in Snort and trying to figure out what is causing Snort to trigger.

WAN
Dec 25 09:02:45
MY WAN IP:29559
95.100.168.130:53
INDICATOR-COMPROMISE DNS suspicious .o dns query

It's either comming from the Parent VLAN my subnets sit on, IPsec VPN Clients or the router itself.

I don't run Snort on the parent interface.

devone

I just ran into this alert as well, and Google led me to this post. Here is what I found out about it in my case. I am using a standalone Snort sensor, not PFSense.

The alert:

12/24-15:59:44.235672  [**] [1:48668:1] INDICATOR-COMPROMISE DNS suspicious .o dns query [**] [Classification: Misc activity] [Priority: 3] {UDP} 10.64.10.18:40297 -> 216.239.34.107:53
12/24-18:40:57.628357  [**] [1:48668:1] INDICATOR-COMPROMISE DNS suspicious .o dns query [**] [Classification: Misc activity] [Priority: 3] {UDP} 10.64.10.18:17376 -> 37.209.192.2:53

Full packet captures:

15:59:44.235672 IP (tos 0x0, ttl 63, id 13859, offset 0, flags [none], proto UDP (17), length 77)
    10.64.10.18.40297 > 216.239.34.107.domain: [udp sum ok] 335% [1au] A? b.ptr.ns.telmany.com. ar: . OPT UDPsize=4096 DO (49)
	0x0000:  4500 004d 3623 0000 3f11 35d1 0a40 0a12  E..M6#..?.5..@..
	0x0010:  d8ef 226b 9d69 0035 0039 accf 014f 0010  .."k.i.5.9...O..
	0x0020:  0001 0000 0000 0001 0162 0370 7472 026e  .........b.ptr.n
	0x0030:  7307 7465 6c6d 616e 7903 636f 6d00 0001  s.telmany.com...
	0x0040:  0001 0000 2910 0000 0080 0000 00         ....)........
18:40:57.628357 IP (tos 0x0, ttl 63, id 51421, offset 0, flags [none], proto UDP (17), length 80)
    10.64.10.18.17376 > 37.209.192.2.domain: [udp sum ok] 335% [1au] AAAA? ari.alpha.aridns.net.au. ar: . OPT UDPsize=4096 DO (52)
	0x0000:  4500 0050 c8dd 0000 3f11 b89a 0a40 0a12  E..P....?....@..
	0x0010:  25d1 c002 43e0 0035 003c 2e9a 014f 0010  %...C..5.<...O..
	0x0020:  0001 0000 0000 0001 0361 7269 0561 6c70  .........ari.alp
	0x0030:  6861 0661 7269 646e 7303 6e65 7402 6175  ha.aridns.net.au
	0x0040:  0000 1c00 0100 0029 1000 0000 8000 0000  .......)........

The signature from snort:

alert udp $HOME_NET any -> any 53 (msg:"INDICATOR-COMPROMISE DNS suspicious .o dns query"; flow:to_server; byte_test:1,!&,0xF8,2; content:"|01|o|00|"; fast_pattern:only; metadata:policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, service dns; classtype:misc-activity; sid:48668; rev:1;)

As far as the signature goes:

It first looks for anything going to a server, which in this case is a DNS server. Next, the "byte_test" part checks if this is a DNS query, not a response. Finally, it checks for the pattern 0x01 'o' 0x00. But it doesn't restrict the content to the resource records in the packet. Instead, it is looking for "anywhere in the payload". In my case, I had the transaction id "0x014f" (0x4f = "O") followed by the flag byte (the first byte is 0). So this leads to a false positive. A better signature would probably add an offset of 11 to skip over the DNS header and only match the resource records. Let me see if Snort/Sourcefire take feedback somehow. But this signature will trigger on all DNS queries with a queryid of 0x014f or 0x016f.

bmeeks

@nogbadthebad said in log queries to specific TLDs:

Is there any way to be able to log queries to specific TLDs rather than everything in DNS Resolver?

I'm getting the following in Snort and trying to figure out what is causing Snort to trigger.

WAN
Dec 25 09:02:45
MY WAN IP:29559
95.100.168.130:53
INDICATOR-COMPROMISE DNS suspicious .o dns query

It's either comming from the Parent VLAN my subnets sit on, IPsec VPN Clients or the router itself.

I don't run Snort on the parent interface.

When you run Snort on just the WAN, this is the situation you will commonly face when trying to find the source of alerts. All of your internal networks will show up in alerts on the WAN side after NAT has been applied, so the local IP address will always be your WAN IP. As you have seen, this is not very helpful for tracking down the true source of the alert. Run Snort instead on the LAN side of your firewall. That way local IP addresses will show up with their real values instead of their NAT value. It will make finding the source of alerts much easier. And in the majority of cases, since the default WAN rules drop unsolicited incoming packets anyway, there is not really any extra security gained by running the IDS/IPS on the WAN interface. It can still protect all of your internal hosts from the LAN-side interface or interfaces.

As for the actual alert itself, @devone has given a good explanation. This one is likely a false positive for you due to a poorly written rule (not your fault, but the fault of the Snort rule author).

NogBadTheBad

Thanks @devone & @bmeeks.

I have 6 different VLANS sat on the same parent interface, I like to have different rules and don't run Snort on the VOIP VLAN as the firewall rules are tied down, so i have Snort running on the VLANS rather than the parent.

I was more interested on seeing what device was causing the hit, funny enough after disabling Snort on the VLANS and adding it to the parent interface I have yet to see the error again.

NogBadTheBad

Yup its a false positive, no .o TLD.

(Event)
	sensor id: 0	event id: 3572891650	event second: 1545908236	event microsecond: 151443
	sig id: 48668	gen id: 1	revision: 1	 classification: 13
	priority: 3	ip source: x.x.x.x	ip destination: 205.251.199.196
	src port: 22304	dest port: 53	protocol: 17	impact_flag: 0	blocked: 0
	mpls label: 0	vland id: 0	policy id: 0	appid: DNS

Packet
	sensor id: 0	event id: 3572891650	event second: 1545908236
	packet second: 1545908236	packet microsecond: 151443
	linktype: 0	packet_length: 82
[    0] 02 00 00 00 45 00 00 4E FE 10 00 00 40 11 85 21  ....E..N....@..!
[   16] 52 45 0F 68 CD FB C7 C4 57 20 00 35 00 3A 6E C4  RE.h....W .5.:n.
[   32] 01 6F 00 10 00 01 00 00 00 00 00 01 0C 75 6E 69  .o...........uni
[   48] 66 69 2D 72 65 70 6F 72 74 04 75 62 6E 74 03 63  fi-report.ubnt.c
[   64] 6F 6D 00 00 01 00 01 00 00 29 10 00 00 00 80 00  om.......)......
[   80] 00 00

devone

Looks like you got the second case, a Query ID of 0x16f, so this gets you |01|o|00| .

NogBadTheBad

Just got a reply from the snort team:-

“This rule will be updated in the next release as the match currently can false positive.”