Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

[ Create a new account ]

Patch DNS Servers Faster

Posted by kdawson on Friday July 25, @10:41AM
from the hard-times-coming dept.
51mon writes "Austrian CERT used data from one of their authoritative DNS server to measure the rate at which the latest DNS patch (source port randomization) is being rolled out to larger recursive name servers. While about half the traffic (PDF) they receive is now using source port randomization, their data suggest that this is due to ISPs who roll out such fixes immediately. The rate of patching has fallen to disappointingly low levels since. If your ISP isn't patched, perhaps it is time to switch." After details of the DNS vulnerability leaked, researchers |)ruid and HD Moore released attack code; ZDNet's security blog has an analysis.

Related Stories

[+] Massive, Coordinated Patch To the DNS Released 315 comments
tkrabec alerts us to a CERT advisory announcing a massive, multi-vendor DNS patch released today. Early this year, researcher Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients. Kaminsky has been working in secret with a large group of vendors on a coordinated patch. Eighty-one vendors are listed in the CERT advisory (DOC). Here is the executive overview (PDF) to the CERT advisory — text reproduced at the link above. There's a podcast interview with Dan Kaminsky too. His site has a DNS checker tool on the top page. "The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not [immediately] reveal the vulnerability and reverse engineering isn't directly possible."
[+] Kaminsky's DNS Attack Disclosed, Then Pulled 281 comments
An anonymous reader writes "Reverse engineering expert Halver Flake has recently mused on Dan Kaminsky's DNS vulnerability. Apparently his musings were close enough to the mark to cause one of the Matasano team, who apparently already knew of the attack, to publish the details on the Matasano blog in a post entitled 'Reliable DNS Forgery in 2008.' The blog post has since been pulled, but evidence of it exists on Google and elsewhere. It appears only a matter of time now before the full details leak." Reader Time out contributes a link to coverage on ZDNet as well.
[+] Attack Code Published For DNS Vulnerability 205 comments
get_Rootin writes "That didn't take long. ZDNet is reporting that HD Moore has released exploit code for Dan Kaminsky's DNS cache poisioning vulnerability into the point-and-click Metasploit attack tool. From the article: 'This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the cache.' Here's our previous Slashdot coverage."
[+] Apple Still Has Not Patched the DNS Hole 285 comments
Steve Shockley notes an article up at TidBITS on Apple's unexplained failure to patch the DNS vulnerability that we have been discussing for a few weeks now. "Apple uses the popular Internet Systems Consortium BIND DNS server, which was one of the first tools patched, but Apple has yet to include the fixed version in Mac OS X Server, despite being notified of vulnerability details early in the process and being informed of the coordinated patch release date."
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by masdog (794316) <masdog@NoSpAm.gmail.com> on Friday July 25, @10:43AM (#24335001)
    You don't need to switch to a new ISP if they haven't patched yet - just switch to a new DNS server such as OpenDNS.
    • by A beautiful mind (821714) on Friday July 25, @10:55AM (#24335231)
      I digress. If an ISP didn't patch yet, it means they are incompetent. When the Debian SSL vulnerability was discovered, I sent two emails out, one to my server hosting company and one to my phone company. The server hosting company replaced their ssl cert within a day, the phone company took 4 months, meanwhile their online user gateway was open to sniffing.

      I ditched the phone company when my email didn't get a reply in a week.
    • Here in Belgium, I use Scarlet as my ISP.

      It seems that dns queries have become much slower. With opera I can see what urls are being requested (main page, images/flash or ads).I can see that for every new page the first thing opera does is doing the dns queries for all the urls. And this has become very slow from time to time.

      I've read somewhere that the randomization really slows down bind, but that the team is working on a patch to solve that.
      (I also don't understand why opera need to execute dns queri
      • Re: (Score:3, Interesting)

        If it has become slower, they are probably using bind9, because it's quick fix. After they've known for 6 months, all they could release was a quick fix. Even though the author/organsation that created/maintainces bind knew about possible problems somewhere in the preview century. I'm sorry, but I've stopped using their software as much as possible.

    • by Woy (606550) on Friday July 25, @11:23AM (#24335731)

      I used OpenDNS and gave it up because it replaced firefox's feature to search google with what you type on the address bar with its own crappy search.

    • by Ciarang (967337) on Friday July 25, @11:25AM (#24335773)
      It always surprises me how much love there seems to be for OpenDNS on /.

      A DNS server returns you a result, or tells you that it can't resolve the domain. Instead of doing the latter, OpenDNS redirects you somewhere you didn't intend to go and attempts to hit you with some advertising. That seems more like typosquatting to me, although admittedly it's with your permission.
      • Re: (Score:3, Informative)

        It'll either be a setting on your router, or if your directly connected to the modem, you'll need to change it on the network settings on your computer.

      • You can change this in your DHCP or IP configuration settings on your home router or PC. On my home network, for instance, my DD-WRT router isn't running a DNS server on it, and the DHCP static DNS settings are set for my Server 2008 box and the two OpenDNS resolvers. My Server 2008 box also has its forwarders set to OpenDNS.

        That's probably more complicated than it needs to be, but better safe than sorry.

        On Windows XP, 2000, and I think Vista, you can tell Windows to ignore the DNS server settings provided by DHCP by going into the IP properties for the connection and hard coding in the IP addresses under Local Area Connection Properties > Internet Protocol Properties > Use the Following DNS Server Addresses.

        This can also be done under linux, but I don't know the particular commands for it.

        • by Anonymous Coward on Friday July 25, @11:09AM (#24335519)

          I had been using OpenDNS. I stopped when I realized they were monitoring my traffic. When I go to Google, they were returning their own Google-like page, to which my browser would submit the query, and then redirect me to Google.

          I stopped using them after that discovery.

          • Re: (Score:3, Informative)

            In Ubuntu, the network icon in the upper-right corner of your screen will take you to your network settings. You can change the DNS servers there.

            I put OpenDNS right in my router configuration so it applies to my whole house. The other big benefit is that I block doubleclick whose ads always seem to make pages so slow to load. You also get some scam and phishing protection.
  • Monopoly (Score:5, Insightful)

    by Anonymous Coward on Friday July 25, @10:48AM (#24335095)

    If your ISP isn't patched, perhaps it is time to switch.

    My ISP has a monopoly over internet services in my area you insensitive clod.

  • time to switch? (Score:4, Insightful)

    by Dunbal (464142) on Friday July 25, @10:58AM (#24335309)

    If your ISP isn't patched, perhaps it is time to switch.

          Thanks to the "free market economy" in my capitalist country I can't switch, you insensitive clod!

  • by BDaniels (13031) on Friday July 25, @10:59AM (#24335331) Homepage

    We use AT&T (formerly Bellsouth) and their servers are not fixed according to the 'dig +short porttest.dns-oarc.net TXT' test.
    I contacted their NOC about the problem yesterday and got the following reply:

    "Patching for these servers are scheduled to begin next week."

    So, major vulnerability, two weeks advance notice, exploit code released - we'll get around to it later.

  • Oops. (Score:5, Funny)

    by Chameleon Man (1304729) on Friday July 25, @11:19AM (#24335679)
    I tried to RTFA, but upon clicking the link I was directed to a porn site.
  • by foo fighter (151863) on Friday July 25, @11:22AM (#24335715) Homepage

    These kind of systems are really hard for security guys to get changed.

    It's like updating switch and routing firmware. Most network engineers who know what they're doing and that have been around for awhile have been burned by "simple" or "easy" patches and config changes going tits up.

    When your core network infrastructure goes tits up your phone tends to light up like a christmas tree. (Granted, when your web presence is redirected to porn or a copy that hides an iframe exploiting customers with unpatched browsers, well, you'll maybe get some phone calls.)

    This DNS patch is a case-in-point: Microsoft's fix is rather ham-fisted and broke stuff; the BIND-Users list is full of people troubleshooting ISC's patch.

    Also, many organizations (like mine) are taking this as an opportunity to reengineer their DNS architecture. This is the perfect time to reevaluate using TSIG and DNSSEC if you don't already.

    It has only been just over two weeks since the initial "announcement". The progress so far is really amazing when you consider how big a ship the Internet is.

  • by Coolhand2120 (1001761) on Friday July 25, @11:29AM (#24335833)
    Maybe if the patch didn't require that open up all incoming and outgoing UDP ports [securitytracker.com] on the DNS interface I could implement it faster. Seeing how most people use firewalls it makes it really quite a bit more difficult than just "apply the patch".

    NOTE WELL: This update causes BIND to choose a new, random UDP port for each new query; this may cause problems for some network configurations, particularly if firewall(s) block incoming UDP packets on particular ports.

    I'll get this patch applied as soon as I reconfigure my entire network topology.

    • by billcopc (196330) <vrillco@yahoo.com> on Friday July 25, @11:48AM (#24336149) Homepage

      You can restrict it to a port range... even giving it access to 2048 ports gives you 2^11 randomness, which is still better than 2^0.

      The issue I'm facing, which I find terribly frustrating, is in upgrading older distros. I'm now looking at completely reinstalling a bunch of older BSD servers just to get this idiotic vulnerability resolved, because the maintainers aren't backporting the patch and upgrading BIND itself would be a royal pain. Given how DNS servers tend to run unattended for eons, I suspect this near-sightedness is respnosible to a large degree for the slow patching. It's not that I don't want to patch my servers, it's that I now have to waste a day at the colo doing physical reinstalls. If it weren't for that hitch, I'd be done already!

    • by molo (94384) on Friday July 25, @12:10PM (#24336489) Journal

      Maybe if the patch didn't require that open up all incoming and outgoing UDP ports [securitytracker.com] on the DNS interface I could implement it faster.

      That is not the case at all. First off, on outbound requests, the destination port is still 53. The _source_ port is what gets randomized. On inbound replies to the randomized port, your stateful firewall will see this as an ESTABLISHED connection and you can safely let it in without blindly opening up the entire UDP port space.

      You _are_ running a stateful firewall, right? Its not 1998 anymore.

      -molo