On Tue, 10 Aug 1999, Dave Gillett wrote:
> Date: Tue, 10 Aug 1999 16:32:05 -0700
> From: Dave Gillett <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Port 7 connections
>
> On 10 Aug 99, at 15:06, Mike Bost wrote:
>
> > DoubleClick Information Security Department
> > <snip>
> > This latency measurement is done by making a connection to the client DNS
> > server on TCP port 7 and then dropping the connection. After the latency
> > measurement has been done, the latency values are cached, and the IP of the
> > most responsive POP is returned to the requesting machine.
>
> Dare I suggest that this is a wee bit under-thought-out?
>
> 1. How does DoubleClick identify the "client DNS server"?
>
the "client DNS server" is the machine making the DNs request to
DoubleClick
> 2. How reasonable is it to assume that latencies to the target so identified
> correlate to actual latencies to the client machine?
>
It is a fudge, a (reasonable) guess that the latencies will be similar to
the client machine and the machine the client is using as their DNS server
> 3. DNS servers seem to be a popular target for exploits and attack scripts.
> The should have non-essential services disabled and/or blocked, and be
> monitored for abuse. Why pick on them?
>
> 4. The echo port is subject to some fairly obvious kinds of abuse. It
> should be disabled and/or blocked, and monitored. Why pick on it?
>
> 5. A properly-functioning DNS server has to accept TCP connections on port
> 53, even if zone transfers are disallowed. Why not use that mechanism?
>
it is an option in the software (the option I am picking in setting up the
Resonate software at my company), but it is not nessasary for the client's
DNS server to allow connections from the internet. In my case the DNS
server that internal desktops use does not accept connections from the
internet. It can request info from the internet but will only respond to
local IP addresses.
>
> One gets the feeling that DoubleClick should be getting tired of explaining
> to security admins what their systems are trying (an, in these cases where
> the echo port is blocked and monitored, FAILING) to do. [Presumably, setting
> off my pager wasn't one of their design requirements....]
>
>
>
>
> David G
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
