Full Disclosure mailing list archives
Re: FW: Question for DNS pros
From: John Hall <j.hall () f5 com>
Date: Tue, 03 Aug 2004 18:38:51 -0700
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 anopen 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 recommendthat 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
Current thread:
- Re: FW: Question for DNS pros, (continued)
- Re: FW: Question for DNS pros Ron DuFresne (Aug 03)
- Re: FW: Question for DNS pros Frank Knobbe (Aug 03)
- Re: FW: Question for DNS pros Mark (Aug 03)
- Re: FW: Question for DNS pros Frank Knobbe (Aug 03)
- Re: FW: Question for DNS pros Frank Knobbe (Aug 03)
- Re: FW: Question for DNS pros Paul Schmehl (Aug 03)
- Re: FW: Question for DNS pros Frank Knobbe (Aug 03)
- Re: FW: Question for DNS pros grutz (Aug 03)
- Re: FW: Question for DNS pros John Hall (Aug 03)
- Re: FW: Question for DNS pros Frank Knobbe (Aug 03)
- Re: FW: Question for DNS pros John Hall (Aug 03)
- Re: FW: Question for DNS pros Frank Knobbe (Aug 03)
- Re: FW: Question for DNS pros Ron DuFresne (Aug 03)
- Re: FW: Question for DNS pros John Hall (Aug 04)
- Re: FW: Question for DNS pros John Hall (Aug 04)
- Re: FW: Question for DNS pros Nils Ketelsen (Aug 04)
- Re: FW: Question for DNS pros John Hall (Aug 05)
- Re: FW: Question for DNS pros Mark (Aug 03)
- Re: FW: Question for DNS pros John Hall (Aug 04)
- Re: FW: Question for DNS pros Gary E. Miller (Aug 04)
- Re: FW: Question for DNS pros John Hall (Aug 05)