Message-ID: <1091582221.525.269.camel@localhost>
From: frank at knobbe.us (Frank Knobbe)
Subject: FW: Question for DNS pros

On Tue, 2004-08-03 at 19:46, John Hall wrote:
> It is possible some of the traffic you are seeing is the result of a site
> using our 3-DNS global load balancing product. A clear indicator that
> 3-DNS is responsible would be that the probes ID fields start at 1 and
> increase by one for each packet in a set of probes. 3-DNS sends its probes
> only in response to DNS queries and uses them to measure round trip time
> and reachability from each data-center under 3-DNS's control to the client's
> local DNS server. The data collected is used to direct other requests 
> using that local DNS server to the "best" data-center. You should 
> generally see
> no more than 9 packets per hour per site using 3-DNS, although one of our
> customers may have configured more aggressive probing (which we discourage).
> 3-DNS does maintain a "do-not-probe" list to which you can be added, if
> the 3-DNS's probe traffic is too obnoxious for you.

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? 

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040803/b1c07b57/attachment.bin

Powered by blists - more mailing lists