[Dshield] Help: DNS (53)

Tod D. Ihde toon at warmerbythelake.com
Fri Jan 2 18:41:27 GMT 2004


Caveat:
  It seems Mozilla (mail componant) doesn't deal well with digests. 
Since I get the DShield list as a digest, this reply is pieced together 
by hand. My apologies beforehand. :(

DavidHart at TQMcube.com wrote:

 >Thanks. Your reply is extremely helpful!

Cool! That's the best reply any reply could hope to get. :)

 >> Look into DJBDNS, your bandwidth, memory, diskspace, and response times
 >> will all improve. (I plug it when I can, I'm a big fan).
 >>

 >That's been a todo for awhile now. It's funny; The Kernel, Apache,
 >Postfix and other key apps are custom installed from source. When it
 >comes to DNS, I become an RPM-addicted nitwit because I don't know what
 >I don't know.

Actually, when it comes to a lot of packages; I was (and to a large 
degree still am) the same way. Only in the last few years have I started 
compiling full packages myself. It's OK; you do what you're comfortable 
with, when you're comfortable with it. I only suggest DJB because of my 
experience. This isn't the place for a DNS holy war, so I won't start 
one (And believe me, I want to. I'm a trouble maker at heart!)

 >>>You need to accept UDP to 53 from any in-bailiwick (
 >>> "authoritative") server. For example, f your server is looking up dns
 >>> info for dshield.org, it must accept UDP packets from dshield.org.
 >>>

OK. Then there is no applicable (IPTables) firewall rule other than
"Accept" DPT=53?
  >

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. Any packets 
which match your filters will get dropped|denied and need to be 
retransmitted (caching dns servers will do that themselves if no reply 
is recieved within an allowed timeframe, up to a maximum amount of 
tries). Eventually, a packet will (hopefully) not match one of your 
rulesets, & you'll get your reply. I know that sounds bleak, but in 
reality, it isn't very - your filtered incoming port ranges are likely 
to be used by many legitimate servers. My servers do not filter on 
imcoming ports (for DNS), but it is possible.

 >>> Allowing ALL incoming packets FROM udp port 53 means that ANY UDP
 >>> datagram can get through your firewall, as long as the source port is
 >>> 53. Probably not what you intended.
 >>

That makes abundant sense. Presumably then, I want to limit to DPT >
32000 and < ???? Any suggestions?

See above.

                                ---------
             Quality Management - A Commitment to Excellence

cbrenton at chrisbrenton.org wrote:
 >Still, so long as he's permitting outbound 53/UDP and letting back in
 >only replies, he'll be cool.

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

 >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. In that case, the log format 
is wrong. Probably for ease-of-use though... ;)

 >>Load balancing? Looks like a normal DNS packet to me, until I see an
 >>actual dump of the payload.

 >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 207.46.150.15 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. Perhaps in response to a normal DNS 
query from his caching nameserver. DNS replies need not come from the 
same IP address the query was sent to (it is up to the software to 
decide which IP to reply back on, on multiply-bound machines).

There is really no such thing as a "load balancer" for DNS (To my 
knowledge, which of course, may have a gaping hole in it somewhere near 
the barin stem. It's been known to happen).

 >Check the dshield database. I'm guessing there are probably a few >people
 >that have not yet figured out this IP is a load balancer and reported >it
 >as potentially hostile. You'll probably find lots of port UDP/53 target
 >traffic.

 >>Again, doesn't look like load balancing. I suggest you read up a 
 >>little
 >> on how DNS works (at the datagram level).

 >LOL! I've been working with Bind for about 10 years. I think I have a
 >handle on it. ;-)

Bind != DNS.. Bind _especially_ != DNS at the datagram level. I suggest 
you read up a little on how _DNS_ works, please. Not how Bind works. I 
know how Bind works. Thats why I switched to DJBDNS. Didn't take me 10 
years to figure that out either. (Took me 5).

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

 >Huh? Please explain how dropping load balancer traffic to a cache >server
 >is going to bring down the Internet and cause dogs and cats to start
 >sleeping together. It might delay the reply, and even cause him to be
 >sent to a non-optimal server (as mentioned above), but that's about it.

No such thing as a load balancer for DNS. Honest. But droping packets 
that match arbetrary rules is always a bad idea, unless you have a VERY 
god reason for it. Especially DNS packets (unless you refer to all web 
sites by IP address, which is doubtful). It at most, will cause the 
reply to not reach him, if all the reply packets happen to match 
drop|deny rulesets.

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".

If this statement is not true, please feel free to tear it apart. Please 
do NOT attempt to distract readers from it by stuffing words in my mouth.

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.

 >>Source port doesn't matter for filtering (for DNS)

 >Actually, they can be helpful. There are fingerprint and version
 >enumeration tools that use a fixed source port of 80. Limit the source
 >port to 53 and >1023 and you break these tools. So limiting source >ports
 >can be helpful, but IMHO in this case they are not really worth it as
 >we're talking a small number of tools.

Those tools use that source port if the default options are not used, 
and the tool is not run as root (and who can't run Knoppix these days?). 
So yes, you may save yourself some small bit of grief, but at the 
expense of (potentially) filtering legitimate traffic. In my experience, 
it really isn't worth it. At least we agree on the worthlessness of 
sorce port filtering as relates to DNS.

afrayer at frayernet.com writes:
 >Okay, I've been trying to follow this thread with some interest because
 >I've been getting hit with UDP 53 packets for the last month at one or
 >two of my IPs. The volume of these packets have been far exceeding my
 >normal noise level. There is no DNS server at these addresses, and I >was
 >trying to figure out why these packets have been appearing. For the >most
 >part, the source addresses have not been targeting multiple addresses,
 >so they slip past the Dshield Fightback rules. And they seem to slack
 >off during overnight or holiday hours, suggesting these are manned PCs
 >that get shut down at the end of a work day.

 >Are these packets actually harmless, and I've over-reacted to them? I
 >have port 53 blocked except for traffic intended specifically to our
 >designated external DNS servers.

Do you have packet dumps? can we see what any of these packets contain?

In addition, there is a (semi) new trojan that uses UDP/53 to 
communicate with other infected machines. You may be seeing infected 
machines try to see if you are also infected. Have you fingerprinted any 
of the machines trying to contact you?

On Thu, 2004-01-01 at 13:58, Jeff Kell wrote:

 >> Just to stir the fire a bit...
 >>
 >> If the DNS response doesn't fit into one packet, it will back off and
 >> make a TCP request.  You have to take TCP into account as well when you
 >> are dealing with DNS.

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.

cbrenton at chrisbrenton.org writes:
 >Sort of. The UDP reply packet will actually contain valid answers. It
 >will just chop the response to fit in the 512 byte packet size maximum
 >and set the truncation bit in the DNS header. The bit being set tells
 >the receiving system that if it wants a full answer, it needs to switch
 >over to TCP. Load balancers will ignore the truncation bit setting. >I've
 >seen this in the wild. I can't think of any normal name server
 >communications off the top of my head that will ignore it, so TCP is
 >inevitable.

Exactly correct! (Except the part about load balancers, which do not 
exist in DNS).

 >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 
nameserver.

 >>Scanners and recons may request a zone transfer via UDP, which is
 >> essentially a no-no.


 >Dig will let you do this as well. I think host does too, but I would
 >have to check. I'm not sure how much info they could retrieve this way
 >beyond your SOA, NS and MX records which they could get though specific
 >UDP queries anyway. Would be an interesting test

 >> For bind, you can specify
 >> the hosts that can request a zone transfer from you (should be a 
list of
 >> your authorized secondaries and cache servers).

 >Agreed. You can even limit which IPs can transfer each unique zone. For
 >the uber-paranoid, you can implement DNSSec which requires a shared
 >secret to be verified before the transfer is permitted as well. Defense
 >in-depth is a good thing. :)

Zone transfers are Bind-isms, not DNS-isms. You can operate DNS servers 
without zone transfers. In addition, they aren't related at all to a 
caching setup. Also, if you have an in-bailiwick server, people can just 
walk you in-addr.arpa instead of trying to transfer a zone. Almost as 
useful. Limiting transfers & implimenting DNSsec buy you nothing except 
a false sense of security.

 >Agreed, you really have to take "guidelines" as just that, especially
 >when you are talking about upper port numbers.

I second that!

afrayer at frayernet.com wrote:
 >Thank you for replying, Chris. The target IPs are ISP-provided public
 >IPs into private networks that are connected together through VPNs. >None
 >of the private networks hold a DNS, and the only names they've been
 >given are NetBIOS names (which I do not believe would apply here); they
 >all exist within a simple NT domain.

 >I would have to answer no to both questions, so I'm probably right in
 >rejecting the 53/UDP packets.

If any of these machines are Win2K or XP machines, they may be trying to 
register their names with a DNS server, which would account for some 
traffic. They'll retry periodicly.

Other than that, Chris is dead on, listen to him (except for load 
balancing, there's no such thing ;) ).

Ok, that's it, I'm going to unsubscribe the digest & resubscribe to the 
list. Mozilla is obnoxios. Thanks for putting up with my piecemeal, people.

Oh, one last thing:

 >From: Leslie_Ford at Dell.com>Subject: Out of Office AutoReply: [Dshield] 
 >Help: DNS (53)
 >Date: Thu, 1 Jan 2004 08:58:10 -0600
 >MIME-Version: 1.0
 >X-Mailer: Internet Mail Service (5.5.2653.19)
 >content-class: urn:content-classes:message
 >x-mimeole: Produced By Microsoft Exchange V6.0.6375.0
 >X-WSS-ID: 13EAEA02500806-01-01
 >Content-Type: text/plain;
 > charset=windows-1252
 >Content-Transfer-Encoding: 7bit
 >
 >I am out of the office until the new year.
 >
 >If it is an emergency, please contact Lenny Lasiewski.
 >
 >Thank you,
 >Leslie Ford

Leslie, you're an idiot.





More information about the list mailing list