The revised DNS.EXE that was released in response to MS08-037
W
pre-allocates at startup 2500 UDP ports. Can someone explain to me what
these ports are being used for?
Our domain controllers are protected by firewalls, and we have glued all of
the domain controller services (after a lot of painful research and
experiment) to fixed TCP and UDP ports. I'm really concerned if the DNS
server is allocating 2500 random UDP server ports and expecting clients to
come in on those random ports, because I'm fairly certain everything except
TCP and UDP 53 will be blocked for incoming connections.
I would like to understand what it is these ports are being used for, and
how I should go about estimating the number of such ports that need to be
made available to applications on the network.
Is there any way I can force the DNS server to use a specific range of ports
and reduce the number from 2500?
--
W
W
news:jZ-dnTJkl9OTHpbX...@giganews.com...
Further reading suggests the 2500 UDP server ports that the DNS server is
setting up is a pool used only for *client* requests from the DNS server out
to other DNS servers. Is it correct?
Why would Microsoft need to pre-allocate UDP server ports in order to do UDP
client UDP requests?
--
W
Ace Fekay [Microsoft Certified Trainer]
>
> Further reading suggests the 2500 UDP server ports that the DNS server is
> setting up is a pool used only for *client* requests from the DNS server out
> to other DNS servers. Is it correct?
>
> Why would Microsoft need to pre-allocate UDP server ports in order to do UDP
> client UDP requests?
>
> --
> W
>
It is a security update to prevent spoofing. Attackers know that normally, without the update, a random ephemeral response ports (service ports), which is normally UDP 1024 and above. They are the response ports used by all Windows communications (not just DNS). An attacker may guess/randomize a port attack at DNS attempting to gain access to create records by injecting their own commands. By reserving the port, or creating this socket pool, it reduces the chance of a randomization attack, which attackers are using against Windows DNS.
Here's more info about it, how to test and see what memory is being used, and ways to disable or reduce the pool, if you feel it is interfering with other services.
======================================================================================================
======================================================================================================
The DNS patch
The DNS patch released in July, 2008, reserves 2500 ephemeral UDP ports.
When you run a netstat -ab, it will display the 2500 UDP ports that have been reserved, but not necessarily in use. This is part of the increased memory consumption that you may see. I've noticed the following (your mileage may vary):
dns.exe Before After
Mem usage 9758K 36,232K
Peak Mem 10,208K 36,584K
Paged Pool 71K 798K
NP Pool 17K 4,833K
Handles 238 5,217
Threads 20 20
MS08-037: Description of the security update for DNS in Windows Server 2003,
in Windows XP, and in Windows 2000 Server (client side): July 8, 2008:
http://support.microsoft.com/?id=951748
MS08-037: Vulnerabilities in DNS could allow spoofing
http://support.microsoft.com/default.aspx/kb/953230
How to reserve a range of ephemeral ports on a computer that is running Windows Server 2003 or Windows 2000 Server
http://support.microsoft.com/kb/812873
You experience issues with UDP-dependent network services after you install DNS Server service security update 953230 (MS08-037)
http://support.microsoft.com/default.aspx/kb/956188
Some Services May Fail to Start or May Not Work Properly After Installing MS08-037 (951746 and 951748)
http://blogs.technet.com/sbs/archive/2008/07/17/some-services-may-fail-to-start-or-may-not-work-properly-after-installing-ms08-037-951746-and-951748.aspx
SBS Services failing after MS08-037 - KB951746 and 951748
http://msmvps.com/blogs/thenakedmvp/archive/2008/07/18/sbs-services-failing-after-ms08-037-kb951746-and-951748.aspx
======================================================================================================
======================================================================================================
--
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
ace...@mvps.RemoveThisPart.org
For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.
"Efficiency is doing things right; effectiveness is doing the right things." - Peter F. Drucker
http://twitter.com/acefekay
W
First, are these ports being reserved for client UDP requests made by the
DNS Server outbound to other DNS servers? It's not clear on why you would
need a pool of server ports reserved for that purpose.
If the concern is for inbound traffic to the DNS server, I'm again perplexed
why DNS Server would need to run any ports above 1024. Aren't all the
incoming requests to DNS server on ports 53 UDP and TCP? What specific
services and request types is DNS Server running on ephemeral ports? The
fact is we block all of those ports to incoming connections, and we haven't
seen any side effect from that yet.
The link to the description of the security update doesn't actually explain
what the update does; that linked article is focusing on peripheral issues
like which files are affected and how to determine if the update causes
problems.
I really need to see the bigger picture here and I don't understand who is
the client and who is the server, and how the attack against the DNS server
is proceeding and how the MS08-037 fix addresses that.
--
W
"Ace Fekay [Microsoft Certified Trainer]" <ace...@mvps.RemoveThisPart.org>
wrote in message news:erDp1fE1...@TK2MSFTNGP03.phx.gbl...
Ace Fekay [Microsoft Certified Trainer]
"W" <persis...@spamarrest.com> wrote in message news:G9udnak9q7e0U5bX...@giganews.com...
>I still don't get it, sorry.
>
> First, are these ports being reserved for client UDP requests made by the
> DNS Server outbound to other DNS servers? It's not clear on why you would
> need a pool of server ports reserved for that purpose.
It's to protect against DNS Cache poisoning based on a DNS vulnerability that was discovered last summer. It affects all DNS servers, and NOT just WIndows. It affects BIND and others. I mentioned some of this in my previous post.
Here's a link with all DNS vendor products that it affects:
Vulnerability Note VU#800113 - Multiple DNS implementations vulnerable to cache poisoning:
http://www.kb.cert.org/vuls/id/800113
>
> If the concern is for inbound traffic to the DNS server, I'm again perplexed
> why DNS Server would need to run any ports above 1024. Aren't all the
> incoming requests to DNS server on ports 53 UDP and TCP? What specific
> services and request types is DNS Server running on ephemeral ports? The
> fact is we block all of those ports to incoming connections, and we haven't
> seen any side effect from that yet.
Yes, this is true about the ports, however, if a crafty attacker can bypass a direct connection to DNS, from the operating system itself, then he can form his attack. There are many articles that describe the exact parameters down to the byte level of how it all works, if you like me to find and post them.
>
> The link to the description of the security update doesn't actually explain
> what the update does; that linked article is focusing on peripheral issues
> like which files are affected and how to determine if the update causes
> problems.
>
> I really need to see the bigger picture here and I don't understand who is
> the client and who is the server, and how the attack against the DNS server
> is proceeding and how the MS08-037 fix addresses that.
Here is the actual exploit code, if you are familiar with this sort of thing. You can also check with Metasploit.org for more information.
http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
>
> --
> W
You can choose not to install it, but I would if I were you. It's your company's system. If an attacker were to find an unpatched system, they will have a little fun with it.
Here are some other links to read up on:
beezari DNS bug leaks by matasano: (good explanation in laymen's terms)
http://beezari.livejournal.com/141796.html
Enterprise Systems DNS Flaw Ignites Controversy:
http://esj.com/security/article.aspx?EditorialsID=3244
Microsoft's Domain Name Server system fix may not be working: (how it may affect Exchange servers)
http://www.gcn.com/online/vol1_no1/46704-1.html
Redmond News DNS Problem Is 'Important' To Patch, Microsoft Says:
http://redmondmag.com/news/article.asp?EditorialsID=10080
Let me know what you think.
Ace
Dave Warren
<persis...@spamarrest.com> was claimed to have wrote:
>First, are these ports being reserved for client UDP requests made by the
>DNS Server outbound to other DNS servers?
Yes.
>It's not clear on why you would
>need a pool of server ports reserved for that purpose.
Poor implementation. A better implementation would only reserve ports
as needed, and would then release them once they're no longer being
used.
>If the concern is for inbound traffic to the DNS server, I'm again perplexed
>why DNS Server would need to run any ports above 1024.
This is TCP/IP 101.
For two IP connected hosts to interact, you need a method to uniquely
identify the request (a stateful connection in TCP, or stateless in
UDP), in most cases this is done by building unique
srcIP:srcPORT:dstIP:dstPORT sets.
Any client making an outbound connection needs a unique port number on
the local host (or at least unique enough that no other connection to
the same dstIP:dstPORT has been active recently), by convention ports
above 1024 are used.
>Aren't all the
>incoming requests to DNS server on ports 53 UDP and TCP? What specific
>services and request types is DNS Server running on ephemeral ports?
None. No services are provided at all, but rather, your local DNS
server is listening for responses.
>The
>fact is we block all of those ports to incoming connections, and we haven't
>seen any side effect from that yet.
>
>The link to the description of the security update doesn't actually explain
>what the update does; that linked article is focusing on peripheral issues
>like which files are affected and how to determine if the update causes
>problems.
>
>I really need to see the bigger picture here and I don't understand who is
>the client and who is the server, and how the attack against the DNS server
>is proceeding and how the MS08-037 fix addresses that.
This is the place to start. When your desktop asks your local DNS
server to resolve www.microsoft.com, your desktop is the client and your
DNS server is the server. If your DNS server doesn't know the answer,
then it asks another DNS server (an upstream resolver, if so configured,
or any along the chain of root / .com / microsoft.com servers
otherwise), in this capacity your DNS server is the client.
If you host your own internet facing DNS for your company example.com,
when someone out in the world asks for example.com, you're the server.
In other words, think if it like this, when you're asking a question
you're the client, when you're answering, you're the server. When your
DNS server doesn't know the answer, it has to ask someone else, so it's
acting as a client at that point.
When acting as a server (listening for requests from clients) requests
come in to your port 53 (UDP or TCP), you send the response back to the
same IP:port that asked the question. This only requires a hole or two
in your firewall, 53 (UDP and TCP)
When acting as a client, your DNS server sends an outbound request to
microsoft.com:53, but it sends that request from a randomly assigned
port on your side, in modern versions these requests come from the large
range of ports DNS assigns.
The vulnerability is that previously it was possible to guess the
complete srcIP:srcPORT:dstIP:dstPORT set which allowed an attacker to
spoof responses, and with enough spoofed responses timed when a real
query was likely to be asked, the victim would end up accepting a
spoofed response.
If your DNS server is an authoritative server and doesn't do any
recursive lookups of it's own, you don't need this wide port range to be
open. However, if you're doing recursive lookups, you do need this
range open in your firewall -- However, since there is always an
outbound packet first and the remote server is answering your request,
if your firewall is stateful and allows outbound traffic, you don't
specifically need to open the inbound return path.
Ace Fekay [Microsoft Certified Trainer]
Dave,
Excellent explanation!
Ace