DNS domain blocking using UDP payload

Hi Mohamed,

Generally, "matchclass" is deprecated I believe for 10 and 11.x. It would be class match, but that is specific to datagroups. You are not using datagroups correct?

So your statement "matchclass $payload contains "google" wouldnt really make sense, that just looks like a standard string "if" statement with no datagroup.

Secondly, the CLIENT_ACCEPTED event is only the beginning of the layer 4 session. If you want to process the actual data of the layer 4 session and since this is UDP versus TCP/HTTP you would probably want to use the CLIENT_DATA event to try to process and string match the UDP payload data. There may be some portion of the data available to parse in CLIENT_ACCEPTED but you should really process the data portion of the payload in the CLIENT_DATA event unless someone knows better or there is an exception with UDP versus TCP/HTTP

I ran into the same issue. Here is something that might work.

It was taken from

https://devcentral.f5.com/wiki/iRules.fast_DNS.ashx

when CLIENT_ACCEPTED {
    binary scan [UDP::payload] H4@12A*@12H* id dname question
     set dname [string tolower [getfield $dname \x00 1 ] ]
    switch -glob $dname {
       "\x03www\x06google\x03com" {
          log local0. "This matches www.google.com"
          drop
       }
   }   
}

I hope this helps

-=Bhattman=-

just for reference.

if we write down $payload contains "www.google.com"]} it is not working, neither for google, nor for google.com we tried to check the payload itself (logging it) and it shows something like blablablawwwgooglecomblablabla, without the dot between google and com any idea?

QNAME is the name the query is about. The format is one octet indicating the length of a label, followed by the label, terminated by a label with 0 length.

how can i decipher dns messages?

Good reference. It's a shame that this was necessary when DNS license could make this easier.

-=Bhattman=-

I tried using this, but it doesn't seem to be matching all requests with the given domain. Any idea why this might be?

Hi, MIke can you please explain a litle bit more the behaviour you are experienced? is the irule not matching www.google.com for isntance?

THANKS IN ADVANCE

when RULE_INIT {
    }
    when CLIENT_ACCEPTED  {

            if { [class match [IP::client_addr] equals bad_dns_users] }{

                binary scan [UDP::payload] H4@12A*@12H* id dname question
                set dname [string tolower [getfield $dname \x00 1 ] ]

                if {[matchclass $dname contains blackhole_domain]} {
                    drop
                }

                pool DoS_pool
            }
    }

As you can see, I changed the iRule a little bit. The goal was to "move" known offending clients to another pool where we could do a bit more ratelimiting and also to mitigate the affects of blackholing a domain to only clients that were already causing problems. Additionally, it means that we're only doing deeper inspection on a subset of our traffic. Finally, we have strict qps ratelimits on the hosts in the DoS_Pool.

Only clients on our network can access our resolvers and we have policies in place to prevent source ip address spoofing by customers.

The behavior I'm seeing is that even with the entry below in blackhole_domain, we're still seeing queries for that domain hit the DoS_pool. I think I'm missing something obvious...

\x08doohotok\x03com

07:58:55.640458 IP cl.ie.nt.ip.filenet-tms > po.ol.mem.ber.domain: 58824+ A? cmz.www.doohotok.com. (38)
    0x0000:  4500 0042 cd04 4000 ff11 ffff 0000 0000  E..B..@......9\`
    0x0010:  0000 0000 8000 0035 002e 59d4 e5c8 0100  .......5..Y.....
    0x0020:  0001 0000 0000 0000 0363 6d7a 0377 7777  .........cmz.www
    0x0030:  0864 6f6f 686f 746f 6b03 636f 6d00 0001  .doohotok.com...
    0x0040:  0001                                     .. 

I can confirm that I still see traffic to a blackhole_domain entry hitting a DoS_pool pool member after changing the profile.

one thing, can you try "return" after drop command?

  if {[matchclass $dname contains blackhole_domain]} {
    drop
    return
  }

I can confirm that I still see traffic to a blackhole_domain entry hitting a DoS_pool pool member after changing the profile.

one thing, can you try "return" after drop command?

  if {[matchclass $dname contains blackhole_domain]} {
    drop
    return
  }

are you using double back slashes in data group?

this is mine.

 config

root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual bar
ltm virtual bar {
    destination 172.28.24.10:53
    ip-protocol udp
    mask 255.255.255.255
    pool foo
    profiles {
        udp_gtm_dns { }
    }
    rules {
        qux
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    vs-index 58
}
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm rule qux
ltm rule qux {
    when CLIENT_ACCEPTED  {
  binary scan [UDP::payload] H4@12A*@12H* id dname question
  set dname [string tolower [getfield $dname \x00 1]]
  if {[class match -- $dname contains blackhole_domain]} {
    log local0. "drop"
    drop
    return
  }
  log local0. "not drop"
}
}
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm data-group internal blackhole_domain
ltm data-group internal blackhole_domain {
    records {
        \\x08doohotok\\x03com { }
    }
    type string
}

 trace

[root@ve11a:Active:In Sync] tmp  tcpdump -nni 0.0 -s0 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 65535 bytes
07:38:00.143874 IP 172.28.24.1.44967 > 172.28.24.10.53:  62524+ A? cmz.www.doohotok.com. (38) in slot1/tmm0 lis=

 /var/log/ltm

[root@ve11a:Active:In Sync] tmp  cat /var/log/ltm
Jul  8 07:38:00 ve11a info tmm[29362]: Rule /Common/qux : drop