[Dshield] Help: DNS (53)
cbrenton at chrisbrenton.org
Fri Jan 2 22:52:52 GMT 2004
On Fri, 2004-01-02 at 13:41, Tod D. Ihde wrote:
> Well, here's where things get sticky. People will tell you you can
> filter port ranges & get away with it. They are incorrectly correct.
> What I mean by this is that yes, you can. yes, it will still work. It
> will impose a bandwidth, cpu cycle, and time penalty though.
Huh? So you're saying "firewalls introduce latency and burn up CPU
cycles". This is kind of firewalling 101 and the whole reason you use a
decent box for the task. If you do, the performance gate is typically
going to be the WAN, not the box, so the performance hit is going to be
minimal. Heck, any device along the link is going to introduce latency
(like all the routers), should we pitch them too?
> Any packets
> which match your filters will get dropped|denied and need to be
You are correct. A firewall's job is to drop the traffic you don't want
to let by. This is actually a "feature". If you do not configure your
rules correctly, then yes you could end up blocking something
legitimate. The correct action is to fix the rules, not pitch the
> My servers do not filter on
> imcoming ports (for DNS), but it is possible.
Dude, if you have down a risk analysis of your network and decided that
it does not make sense to filter ports, that's cool. That does not mean
its a good idea for everyone else.
> The problem is, replies need not come from the same IP address as the
> query was sent to (please don't ask me to look up the RFC, but it's
> there, I swear. I'll look it up if you ask, and curse myself for getting
> involved the entire time!)
Just because its in the RFC does not mean its actually being used in the
wild. They are "request for comments", not "laws of the Internet". I'll
give you another example, the FTP RFC still permits data port
negotiations with a different server. The problem is that any FTP server
that implements this part of the RFC is going to be vulnerable to FTP
bounce attacks. So its still there in writing but people have stopped
supporting it because its a bad idea. The same would be true for
responding from a different name server as most/all stateful and proxy
based firewalls would not accept the traffic. That would severely limit
the usefulness of the implementation.
> >He's using iptables (that was the log format he submitted). The
> >"ESTABLISHED" case sensitive keyword (which is why I had it all in >caps,
> >I was not yelling ;) is used to let in replies regardless of whether >its
> >TCP, UDP, ICMP, etc.
> Sorry, I hadn't meant to imply that you were yelling, only that you
> can't have an "established" UDP connection.
I never said you could, I was giving him a hand with creating his rules.
> In that case, the log format
> is wrong. Probably for ease-of-use though... ;)
I'm guessing you've never used iptables before as the ESTABLISHED
keyword has nothing to do with logging (I said I know he was using
iptables as a firewall because I recognized the log format he posted).
Perhaps its time to do some reading before you post?
> >The clue is he specified this is a _caching server_ only. Caching only
> >implies no public NS record entry, which means people will not be >making
> >legitimate queries to this system from the Internet. So the choices are
> >"port scanning" or "load balancer". Since its just this one host and >one
> >target port, port scanning is unlikely. That and 220.127.116.11 is known
> >to be one of MS's load balancers.
> I stand by my statement. This is a single entry, with no payload. Until
> I see a payload or can watch the traffic, or see a traffic capture, this
> appears to be a normal DNS packet.
Its a known load balancer that is generating traffic that is
characteristic of that device. You are certainly welcome to think its
what ever you want.
> There is really no such thing as a "load balancer" for DNS
Wow, you really are out of the loop. :(
It _is not_ a DNS load balancer. When your name server attempts to look
up the remote IP of a host (say www.microsoft.com), the load balancer on
the remote end sends a "probe" to the requesting name server's IP from
one or more sources. In the past I've seen this "probe" take the form
*a zone transfer attempt
*a version.bind request
*UDP probe to 37852
as well as many others. This particular version just does a simple PTR
on the source IP. If the first probe gets a response, you will see other
requests come in from numerous other IPs (for MS I believe there is 3
Now, each of these remote IPs are close to a server that resolves to
www.microsoft.com. Depending on which query gets the best response time,
you get back a different IP address as an answer to your query.
I am not saying the above is a good idea or even that it works. Just
that the devices are out there. For more info see:
> Bind != DNS.. Bind _especially_ != DNS at the datagram level. I suggest
> you read up a little on how _DNS_ works, please.
OK, please point out where I have been wrong in how DNS works and I'll
gladly spend some time doing the research on the topic.
> Thats why I switched to DJBDNS. Didn't take me 10
> years to figure that out either. (Took me 5).
Nice dig! :-)
> No such thing as a load balancer for DNS. Honest.
Again, see above and do some reading.
> But droping packets
> that match arbetrary rules is always a bad idea, unless you have a VERY
> god reason for it.
Huh? How did we go from "only let in valid replies to outbound queries"
to "let's create arbitrary rules"?
> Please note, that my previous reply had nothing to do with bringing down
> the internet, not did it mention anything about dogs or cats. Please,
> don't read more into what I write than what I write. I wrote, "The only
> thing you're doing is causing your DNS server to work harder, use more
> bandwidth, and place more of a load on external DNS servers if you're
> dropping DNS packets".
I stated it the way I did because you are talking like Chicken Little.
You are claiming that if he filters out traffic from this load balancer
its going to cause a number of negative things to occur. You do not
explain why blocking a load balancer is going to cause anything bad to
happen beyond what I already told him.
> His DNS server will work harder because it will need to send out
> multiple queries if the original queries are filtered at his firewall,
> causing redundant traffic, and causing the external DNS servers to
> re-answer queries they have just answered, which places more of a load
> on them. Therefore, unless you can find flaw with my previous statement,
> I believe I was correct.
I think the problem is you really don't understand what is happening on
the wire. He _is not_ filtering out his queries. He is filtering out
MS's attempt to figure out which IP to give him back on the currently
pending query. He _will not_ have to make multiple attempts because if a
reply is not received the device will round robin. Granted this might
not be the optimal server for him to connect to, but its better than
opening up UDP/53 access just to permit a few external sites to load
> Incorrect. It _may_ perform TCP, but only after sending a valid UDP
> packet, and only after the querant has asked for the full payload. TCP
> is never required. You do not need to take TCP into account, if you are
> set up as a caching nameserver. Pinky swear.
Again, huh? So you are saying TCP may be required but don't worry about
it? So what if I request a full answer from the cache server? He should
block this traffic?
> Exactly correct! (Except the part about load balancers, which do not
> exist in DNS).
Dude, you *really* need to do your homework before posting to a public
> >BTW this is why I included TCP/53 in my rules to Tod. ;-)
> And is not required for normal TCP operation, especially for a caching
Again, so if an internal system needs a full answer you are telling him
to just drop this request on the floor? Why?
> Zone transfers are Bind-isms, not DNS-isms.
LOL! dude, you need to chill a bit. Bind and MS DNS make up a good chunk
of the name serrvers on the Internet whether you like it or not. This is
the terminology used by both products.
> You can operate DNS servers without zone transfers.
Who said you have to have zone transfers to have a name server?
> In addition, they aren't related at all to a
> caching setup.
Who said they were? The second thread you responded to was about
transferring zones info via UDP.
> Also, if you have an in-bailiwick server, people can just
> walk you in-addr.arpa instead of trying to transfer a zone.
If you have it, no one says you do. I leave my ARPA resolving to my
upstream so its a whole lot harder to reverse engineer the address
space. Good luck finding co-lo servers that way as well.
Also, its a lot more work to PTR a large network than it is to just
transfer the zone. Most kiddies will not bother. Its not perfect but its
a valid layer in a defense in-depth posture. Why make an attacker life
any easier than you have to?
> Limiting transfers & implimenting DNSsec buy you nothing except
> a false sense of security.
Dude, if you want absolute security hit your "off" button. Beyond that,
*nothing* is perfect. This is why SANS pushes defense in-depth so hard.
Layers are always better than relying on a single solution or "not
bothering" to harden your security posture because the cure is not
perfect. If there is a valid business need for not doing something, then
life is cool provided you've examined the risks and chosen to accept
them. As I teach my students in track 2, "Here are your options, its
your job to figure out which ones are the best fit for your
environment". For many organizations limiting zone transfers or using
DNSSec is a viable option as one of the layers in their posture.
More information about the list