Turn off RPC management of DNS on all DCs

By now you have probably seen:

http://www.microsoft.com/technet/security/advisory/935964.mspx

 

Microsoft recommends you mitigate the problem by disabling RPC management on DNS. They give the switch to do that, but no script to do it on a large number of DCs or DNS servers.

 

Here is how you do it on scale:

  1. Generate a list of all your DCs or DNS servers. Put it in a file called DCList.txt. You can generate this list by right-clicking the Domain Controllers OU and selecting "Export List..." If you have a more complicated list write a query to get them. Below I show how to do that.
  2. Log on as an Enterprise Admin (or a domain admin if you only have one domain)
  3. Run this command in the directory where you put the DCList.txt file
    for /f %i in (DCList.txt) do reg add \\%i\HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters /v RpcProtocol /t REG_DWORD /d 4

That's will change the setting. To set it back to the original you would run this command instead:

for /f %i in (DCList.txt) do reg delete \\%i\HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters /v RpcProtocol /f

 

Both changes require you to stop and restart the DNS service. You can use these commands for that:

for /f %i in (DCList.txt) do sc \\%i stop DNS
for /f %i in (DCList.txt) do sc \\%i start DNS

 

 

 To generate a list of DCs, you can use the Saved Queries feature of Active Directory Users and Computers. Here is how:

  1. Open Active Directory Users and Computers
  2. Right-click Saved Queries and select "New Query"
  3. Name the query "Domain Controllers" and click "Define Query"
  4. In the "Find" dropdown select "Computers"
  5. In the "Role:" dropdown select "Domain Controller"
  6. Click OK Twice
  7. Select the query. You should now see all your DCs in the right-hand pane.
  8. Right-click the query and select "Export list..."
  9. Save it somewhere as DCs.txt.
  10. Alternatively, run "netdom query dc > DCs.txt" on a command line. In that case you need to delete the last line of the file before you run the rest of the command though. Otherwise it will try to set this value on the computer "The".
  11. Navigate to that directory. Because the file is tab-delimited you need to modify the command in the for loop slightly to make it work. The following command will parse the file properly and disable RPC management on DNS on all DCs.
    for /f "skip=1 tokens=1" %i in (DCs.txt) do reg add \\%i\HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters /v RpcProtocol /t REG_DWORD /d 4

Using this file the commands to stop and restart the DNS service need to be slightly modified:

for /f "skip=1 tokens=1" %i in (DCs.txt) do sc \\%i stop DNS
for /f "skip=1 tokens=1" %i in (DCs.txt) do sc \\%i start DNS 

 

Hopefully this will help people mitigate this problem a bit faster than having to do manual registry changes everywhere.

Published Fri, Apr 13 2007 9:51 AM by jesper
Filed under:

Comments

# Roger said on 13 April, 2007 01:16 PM

Am I missing where you're restarting the service?   The KB says that is necessary as well.

# jesper said on 13 April, 2007 01:25 PM

Aah, yes. I did forget to put that in. It is fixed now.

# Corrine said on 13 April, 2007 02:18 PM

Thanks for the instructions!

Pingback:  http://securitygarden.blogspot.com/2007/04/microsoft-security-advisory-935964.html

# Alun Jones said on 13 April, 2007 04:05 PM

Got any services that depend on the DNS server service?

I can't think of any off-hand, but anyone doing this - particularly on a large scale - should be aware that any time you stop and restart a service, you automatically stop, and don't restart, services that depend on the service you're cycling.

Obvious to some, but worth pointing out.

# jesper said on 13 April, 2007 04:09 PM

I did not see any that did on my test box. There may be something, but I can't think what it would be.

# andy said on 13 April, 2007 09:48 PM

Am I missing something? If RPC is generally open to the internet, isn't your system pretty much owned already?

The KB specifically says that port 53 isn't an attack vector, and that's all that should be exposed to the outside world.

# jesper said on 14 April, 2007 01:02 AM

Andy: yes, you definitely have to wonder about leaving RPC open to the Internet in that way. It is a bit much to say the system is owned already, but it definitely has a far larger attack surface than necessary.

# Michael Knightley said on 14 April, 2007 11:04 AM

Say you've got a windows 2003 SBS running with interfaces configured using RFC1918 space placed behind a firewall (a completely open one, but with no portforwarding enabled but a one-to-one https and smtp to a particular machine), you should be somewhat on the same side of the line as the ones who block the recommended port range, correct? Naturally you still have the internal part of your network to worry about, but not the terrible outside?

Kind regards

# brian said on 14 April, 2007 07:16 PM

Faster list of just DNS servers:

dsquery * -filter "(servicePrincipalName=DNS*)" -attr dNSHostName -l > dclist.txt

# jesper said on 14 April, 2007 07:37 PM

Brian: Excellent query. Thanks, I was going to see if I could find that.

Michael: Yes, you would have exposure only to systems on the inside.

# Michael Knightley said on 15 April, 2007 12:09 AM

Jesper:

I thought so. Thank you for the confirmation, and for the great tip provided above.

Kind regards

# Dennis Lundtoft Thomsen said on 15 April, 2007 07:05 AM

You could also use "dnscmd ServerName /config /RPCProtocol 0" to disable RPC on DNS Servers (And combine it with the output from the dsquery command showed earlier)

# Angeldmx said on 15 April, 2007 07:12 AM

Good tip! ... Thanks very much!  

But, I Would like your opinion on the "Symantec Rapid Release" features ...  

Do you think that it could help protecting efficiently against this vulnerability ?

>>How to:

http://entkb.symantec.com/security/output/n2002103012571948.html

>>Self-extracting EXE file or VDB/XDB files:

ftp://ftp.symantec.com/AVDEFS/norton_antivirus/rapidrelease

# Dennis Lundtoft Thomsen said on 15 April, 2007 07:48 AM

Sorry thereøs a typo - it's of course "dnscmd ServerName /config /RPCProtocol 4"

# criticaljoe said on 16 April, 2007 03:28 AM

List of all DNS servers in the forest (handy if you're an Enterprise admin):

dsquery * forestroot -filter "(servicePrincipalName=DNS*)" -attr DNSHostName -l  -scope subtree > dnslist.txt

# DrewNamingServer said on 16 April, 2007 10:24 AM

Hysteria!! If an internal user is an accomplished coder who can manipulate RPC then why is shutting off the DNS remote mgmt server going to keep them from doing harm. Have you enumerated the RPC servers available on a domain controller? There is a large surface for attack.

If you have external DNS servers that dont have port 135 protected then you get whats coming to ya!

# Jay Andrews said on 21 April, 2007 04:18 PM
We implemented the workaround above on two of our AD domain controllers (i.e. DNS), and found that in doing so we lost connectivity to a secondary zone replicating from another division (a seperate trusted AD domain - therefore dynamic dns). After removing the patch on one of the servers, the zone connectivity was restored (for that DC). I'd appreciate any thoughts on this - we were told (by msft) that this shouldn't be affected by the patch, but it clearly is. (I don't have the exact error, but it's something like "secondary Zone could not connect to master" or the like) on the site: http://msinfluentials.com/blogs/jesper/archive/2007/04/13/turn-off-rpc-management-of-dns-on-all-dcs.aspx It suggests that dynamic dns updates are dependent on RPC. could this be the link?
# jesper said on 23 April, 2007 11:50 AM

Microsoft has published an official KB article with this workaround. Here is what they have to say about it:

blogs.technet.com/.../new-kb-article-to-help-deploy-dns-remote-rpc-block-workaround-throughout-enterprise.aspx

# herman said on 25 April, 2007 11:09 AM
What do you do if you suspect your server has been hit with the worm that is taking advantage of this flaw? I am getting a lot of cannot contact dns server in the mmc since yesterday. I
# jesper said on 25 April, 2007 12:24 PM

Herman, here is what I had to say on your question a few years back:

www.microsoft.com/.../sm0704.mspx

If you truly have been hit, the advice still stands.

# Susan said on 26 April, 2007 08:27 PM
Herman? Call 1-866-pcsafety and ask for PSS Security. If you have been hit with this worm, Microsoft needs to know this. They can help you, and it helps to let them know if folks are getting impacted. This in turn impacts their actions.
# Gene said on 27 April, 2007 03:38 PM

Is there any other way to get MMC to work when this workaround is put in place?  

# jesper said on 28 April, 2007 10:59 AM

Gene, not remotely. That's what the workaround prevents. You can use RDP though.

# Press Digital said on 14 November, 2008 11:52 PM

Is there any other way to get MMC to work when this workaround is put in place?

# Matt said on 26 November, 2008 01:13 PM

Once you've installed the hotfix from MS07-029 (support.microsoft.com/.../935966,) you should be able to remove the reg key and get remote management working again.