[Dshield] Help: DNS (53)
Tod D. Ihde
toon at warmerbythelake.com
Fri Jan 2 18:41:27 GMT 2004
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
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?
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 126.96.36.199 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
>>Again, doesn't look like load balancing. I suggest you read up a
>> 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
>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
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
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
>>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
>> 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
>X-Mailer: Internet Mail Service (5.5.2653.19)
>x-mimeole: Produced By Microsoft Exchange V6.0.6375.0
>I am out of the office until the new year.
>If it is an emergency, please contact Lenny Lasiewski.
Leslie, you're an idiot.
More information about the list