If you are a fan of www.incidents.org like I am you've been wondering if you should be worried about all this DNS cache poisoning aka Pharming that's been going one. As they state in today's entry:
http://isc.sans.org/diary.php?date=2005-04-07
(Note: Windows systems are not protected even with their magic registry entry IF they trust an upstream dns system that doesn't clear additional dns records from the answer to the query and site the article. - upgrade to the right SP on W2K
- not forward to vulnerable windows DNS caches
- not forward to pre-BIND9 bind DNS caches
If you know anything at all about how SBS is set up in our default wizardized mode, we set up DNS forwarders. Okay, so I know I have my DNS set up to Pacbell's DNS forwarders:
So of course the first question I am asking myself is ...okay..what version of either Microsoft DNS or BIND does Pacbell run? I “AM” an SBSer that forwards to their DNS. I emailed their tech support last night... [okay yeah that's a vain hope that I'll get an authoritative answer..still waiting on an answer]. So in asking the real gurus like Andrea “ObiWan“ Zenobi, Microsoft MVP in Windows Server and Networking, he did a check on a server at Pacbell and found that the server at 206.13.28.11 is running BIND 8 not BIND 9.
dig pacbell.net NS
;; QUESTION SECTION:
;pacbell.net. IN NS
;; ANSWER SECTION:
pacbell.net. 69218 IN NS ns1.pbi.net.
pacbell.net. 69218 IN NS ns2.pbi.net.
;; ADDITIONAL SECTION:
ns1.pbi.net. 84814 IN A 206.13.28.11
ns2.pbi.net. 69218 IN A 206.13.29.11
using http://www.rfc.se/fpdns/ to fingerprint the two nameservers above
fpdns.pl 206.13.28.11
fingerprint (206.13.28.11, 206.13.28.11): BIND 8.2.2-P3 -- 8.3.0-T2A
fpdns.pl 206.13.29.11
fingerprint (206.13.29.11, 206.13.29.11): BIND 8.3.0-RC1 -- 8.4.4
Hmmmm, that sure looks like a pre BIND9 to me, doesn't it to you? Okay so now that I know that I'm forwarding to a ISP that uses probably a BIND version that does not automatically protect me by scrubbing it's DNS before it transfers them back down to me, [unlike the default configuration of Microsoft DNS servers after Windows 2000 SP3], not knowing if PacBell's computer tech team is as wacko on patching as I am, I'm starting to do a bit more investigation.
Note If a DNS server has been configured to forward resolution requests to another server, establishing a child-parent relationship, the child DNS server could still be vulnerable to DNS cache pollution attacks performed against a parent DNS server if that server is not performing DNS cache pollution protection. By default, Microsoft DNS servers, using Windows 2000 Service Pack 3 or later, acting as a parent in a child-parent relationship will fully perform cache pollution protection. Therefore, make sure that all DNS servers in an organization have DNS cache pollution protection enabled.
The reality is... I'm a “child server” here dependent on the “parent”, in this case, my ISP, to be this scrubber. I don't know about you, but if I can't vouch for the patch status of 'those servers' like I can my own, we're going to be making changes in how DNS is set up in my SBS box.
The IT-ISAC paper on DNS Cache poisoning that I just got today says the problem was multi pronged [with my comments added].
“There were four broad categories of affected systems:
- Unpatched Symantec Firewalls - Classic DNS cache poisoning through use of appended bogus answer records in unsolicited DNS replies. Solution: Patch
- Older versions of DNS servers running Windows NT or Windows 2000 prior to SP3 [hello people again PATCH]. KB 316786 has details on how to protect older systems.
- Unix and Windows systems simply compromised... remember class how we clean a compromised system? Remember why we patch?
- Up to date Windows DNS servers were poisoned in spite of having the latest patches - this final category [they said in the sheet] was the most troubling since there was no known mechanism for the poisoning.
One of the incidents research that fit into category four revealed that the DNS server was configured with a “forwarder“ (a designated system to which DNS requests are forwarded). This is a normal practice in tightening down adn marshalling DNS in larger enterprises where all DNS is channeled through larger DNS servers for caching and traffic control. In this case, the designated target forwarder was an unpatched Symantec firewall.“
Remember also that's “our“ default recommended way in SBSland is to do forwarders.
First off, remember that you do not need those entries in there in the first place. They were used at a time when we had slow connections and needed to rely on such things, now we can just let root hints take their place. So the first thing you can do if you are a paranoid Chicken Little like I am and don't trust your Telephone company's operating systems, is to rerun the Connect to Internet Wizard and remove those forwarders.
There's one more step I'm planning on doing [first on the test server at home before doing it here] Obiwan also has a suggestion to move from Roothints to Slave-Root mode. Stay tuned for Part 2 of “DNS, Poisoning, pharming attacks and SBS impact“ coming to a blog near you.
RFC 2136 and RFC 2870 talk about DNS along with a bunch of RFCs here. Along with - Windows DNS http://support.microsoft.com/?kbid=323380 and
- BIND DNS http://www.cymru.com/Documents/secure-bind-template.html and an oldie but goodie here: http://www.securityfocus.com/guest/17905