[no subject]

[Abe Getchell <agetchel () KDE STATE KY US>]

Hey Mike,
        After thinking about this a little further, something here doesn't
seem quite right.  If all of Mirror Image's sites are 'sending out an RTT
packet' to our DNS servers after it receives a name resolution request,
wouldn't we be seeing one connection coming from multiple IP addresses
instead of multiple connections from one IP address?  I would assume that
'all of their sites' would show up from different source IP addresses...
unless they are doing some sort of NAT on a firewall of their own of
course...
        Assuming what they are saying is true, I think you hit the nail on
the head; not only is it a poorly designed piece of software, but it's
ridiculous to assume that all clients which made a request would be
reachable at all on an arbitrary port.  Also, why would you assume that a
client's DNS server is anywhere _near_ the client itself?  Heck, I could be
using a DNS server on a sister ISP's network across the country which could
have a much lower response time to a site then too the client itself.  But
that's a different discussion for a different day. =)
        It'll be interesting to see what some of the other ISP's say.

Thanks,
Abe

PS-Come to think of it, I wonder why Cisco's Distributed Director would
assume that a client wouldn't be behind a Cisco PIX firewall that would be
dropping this type of traffic? =)


Abe L. Getchell - Security Engineer
Division of System Support Services
Kentucky Department of Education
Voice   502-564-2020x225
E-mail  agetchel () kde state ky us
Web     http://www.kde.state.ky.us/



> -----Original Message-----
> From: Mike Lewinski [mailto:mike () rockynet com]
> Sent: Thursday, October 26, 2000 10:39 AM
> To: agetchel () kde state ky us
> Cc: incidents () securityfocus com
> Subject: Re:
>
>
> Abe,
>
> Thanks for the update.
>
> > The activity you describe is a result of our global load
> balancer. When a
> > client behind your DNS server makes a request to one of our
> customer's
> > sites, our load balancer has all of our sites send out an
> rtt packet to
>
> ^^
>
> I count a total of  20 packets from that site alone in just
> 10 seconds,
> without even looking hard through my logs for a period of density.
>
> I'm curious to know how this is going to work with people who
> are dropping
> 1024. Our DNS server has a "deny unless permitted" confguration. If my
> action is to drop the packet silently, to them it must look
> like we're not
> even on the map.
>
> Believe it or not someone recently gave me a similiar
> response as to why
> they were querying us for "version.bind". I think that they must have
> stopped that- I haven't seen it in a while, and I'm sure it
> generated lots
> of inquiries/complaints.
>
> If this is what they claim it is, I'd say it's poorly written
> to be hitting
> us so often, and to be assuming that their packets will make it even
> through... I notice that one of the features listed at
> Cisco's web site is
> as follows:
>
> "Enhanced Server Verification with Multiple Port Connect Test
>  Prior to this enhancement, DistributedDirector could
> evaluate server status
> by performing a TCP connect test to a single port. The Enhanced Server
> Verification with Multiple Port Connect Test feature allows
> multiple connect
> ports to be specified. If any one of the connect tests fail,
> the server is
> considered down."
>
> It's not clear to me if this test is going to the requested
> web host, or to
> our DNS servers or both. It does seem dumb that a client who
> just sent a
> request would be considered "down", but I can also see how
> many firewalls
> will always be in conflict with a system like this. A good
> configuration
> will drop virtually anything sent from the remote server that's not a
> response to the original query, and since it's UDP there's
> nothing for the
> remote "load balancer" to measure latency against. If they
> ping or send tcp
> packets they'll trigger IDS/firewall rules. And they can't
> assume that the
> client is really a server, because incoming DNS requests
> could be similarly
> blackholed.
>
> Heh, this thing wants to portscan us, plus check that the
> webserver it's
> sending the client to is actually up. Probably DNS resolution
> takes so long
> that the "client" is sitting there repeatedly hitting the
> refresh button and
> bitching at their ISP (who's servers are being packet flooded by load
> balancers at the moment....)
>
> Mike