[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: [Full-Disclosure] Question for DNS pros


Responses in-line...

Frank Knobbe wrote:

Hello John,

glad to see you guys are keeping up with all the current stuff going on
in lists ;)

I had sent a dump earlier. It is attached again below. The TCP SYN
packets do indeed start with IPID 1 and move up to 3. However, these all
come from the same IP address. Also, there doesn't appear to be anything
in regards to "round-trip". I mean, your devices send the SYN's but
nothing is coming back. Are you expecting DNS querying device to have an
open DNS port on TCP and are expecting a SYN-ACK? 

No, but most DNS servers *will* respond with a RST which is just as
valuable for reachability and RTT measurements.  We accept either
response.

That I can understand. But what the heck is the purpose of performing
two DNS queries against the host that is querying a 3DNS balanced
server? Seems a bit invasive to me for measuring trip time... :)


In general, most sites use local forwarding DNS servers that do the
recursive lookups for all the clients at that site, so our probes
measure the RTT from each datacenter to that forwarding DNS server
and maintain that data so we can make intelligent decisions the next
time a client from that site (via that local forwarder) makes a request.

In any case. I'm glad to see that there is a normal explanation for
this, and this does not appear to be an attack mounted by China.

Thanks for the info. Now we just need to find a decent IDS signature
that allows your 3DNS probes to be ignored, but not render the IDS
silent for related traffic (although I really would like to know when
someone is probing my server for the "." zone.... Perhaps you guys could
move to fixed IPID for those UDP queries or something?)

Thanks again,
Frank


tcpdump:

21:16:15.434753 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  51621
NS? . (17) (ttl 44, id 51622, len 45)
21:16:16.194129 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  51622
NS? . (17) (ttl 44, id 51623, len 45)
21:16:16.932505 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  51623
NS? . (17) (ttl 44, id 51624, len 45)

21:16:18.431546 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  9949
PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9950, len 73)
21:16:19.186279 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  9950
PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9951, len 73)
21:16:19.939409 218.75.110.194.3847 > x.x.x.x.53: [udp sum ok]  9951
PTR? x.x.x.x.in-addr.arpa. (45) (ttl 44, id 9952, len 73)

21:16:21.433511 218.75.110.194.53 > x.x.x.x.33434: [udp sum ok]  10344
FormErr [0q] 0/0/0 (36) (ttl 44, id 10344, len 64)
21:16:22.196164 218.75.110.194.53 > x.x.x.x.33434: [udp sum ok]  10345
FormErr [0q] 0/0/0 (36) (ttl 44, id 10345, len 64)
21:16:22.995559 218.75.110.194.53 > x.x.x.x.33434: [udp sum ok]  10346
FormErr [0q] 0/0/0 (36) (ttl 44, id 10346, len 64)

21:16:24.448425 218.75.110.194.1758 > x.x.x.x.53: S [tcp sum ok]
3939495989:3939496013(24) win 2048 0 [0q] (22) (ttl 44, id 1, len 64)
21:16:25.208289 218.75.110.194.1794 > x.x.x.x.53: S [tcp sum ok]
3774103031:3774103055(24) win 2048 0 [0q] (22) (ttl 44, id 2, len 64)
21:16:26.005612 218.75.110.194.1821 > x.x.x.x.53: S [tcp sum ok]
992083552:992083576(24) win 2048 0 [0q] (22) (ttl 44, id 3, len 64)

21:16:27.441872 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id
32512, len 64)
21:16:28.191483 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id
32747, len 64)
21:16:28.949630 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id
32997, len 64)
21:16:41.758970 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id
36248, len 64)
21:16:42.166118 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id
36448, len 64)
21:16:42.898505 218.75.110.194 > x.x.x.x: icmp: echo request (ttl 44, id
36627, len 64)


That does look like a full set of 3-DNS probes. We generally recommend
that our customers only configure two probe methods. Looks like this guy has all of the probe methods configured. Since your firewall doesn't
respond at all, it's trying each method in turn. The traffic does look
like it's pretty low volume, so I guess your major concern is being
woken up at 4am with IDS alerts (at previous jobs I was a network
manager at an ISP and a fortune 500 company, so I know how you feel).
Currently, I don't know of any specific signature other than the ID
field that would help identify our "." probes. I'll ask around.

JMH

--
John Hall              Test Manager - Switch Team             F5 Networks, Inc.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html