• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

log queries to specific TLDs

Scheduled Pinned Locked Moved DHCP and DNS
7 Posts 3 Posters 675 Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N
    NogBadTheBad
    last edited by NogBadTheBad Dec 25, 2018, 10:13 AM Dec 25, 2018, 10:12 AM

    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.

    Andy

    1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

    B 1 Reply Last reply Dec 27, 2018, 12:16 AM Reply Quote 0
    • D
      devone
      last edited by Dec 26, 2018, 6:39 PM

      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.

      1 Reply Last reply Reply Quote 1
      • B
        bmeeks @NogBadTheBad
        last edited by bmeeks Dec 27, 2018, 3:41 PM Dec 27, 2018, 12:16 AM

        @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).

        1 Reply Last reply Reply Quote 1
        • N
          NogBadTheBad
          last edited by Dec 27, 2018, 8:33 AM

          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.

          Andy

          1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

          1 Reply Last reply Reply Quote 0
          • N
            NogBadTheBad
            last edited by Dec 27, 2018, 1:22 PM

            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
            

            Andy

            1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

            1 Reply Last reply Reply Quote 0
            • D
              devone
              last edited by Dec 27, 2018, 2:58 PM

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

              1 Reply Last reply Reply Quote 0
              • N
                NogBadTheBad
                last edited by Dec 27, 2018, 4:00 PM

                Just got a reply from the snort team:-

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

                Andy

                1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

                1 Reply Last reply Reply Quote 0
                1 out of 7
                • First post
                  1/7
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                  This community forum collects and processes your personal information.
                  consent.not_received