Tuesday, July 22, 2008

Do not scramble to fix the DNS problem

Haven't solved your DNS problems yet?  It is OK, I have a few suggestions-

If you have mainstream systems with patches already released- just patch them.  Don't take my word for it, ask Google or your favorite info sources for known issues with these patches and deal with it.

Maybe you have some older or specialty systems, and patches aren't available yet (or maybe won't ever be available).  In this case, do not rush to come up with permanent solutions or move your DNS to a new platform; rush to mitigate the problem, then when the immediate exposure is addressed you can take your time and either wait for a patch or deploy your own long-term solution.  Rolling out a new DNS infrastructure in a hurry could make you do something stupid.  Remember, you are trying to solve a problem, not create a new one.



Monday, July 21, 2008

If you can't update DNS without breaking your network~

I was going to skip commenting on the whole DNS thing, everyone knows about it and many folks have covered it.

But, there seem to be quite a few admins who don't want to patch a vulnerability without all of the gory details. While I respect that skepticism, I think they are wrong this time. A couple of reasons:

  • It is DNS and it is Dan Kaminsky.
    • DNS and Dan Kaminsky is a redundant statement
  • Gazillions (OK, dozens) of vendors cooperated for the first time in Internet history to
    • work together for months
    • keep quiet until the appointed date
    • synchronize patch release for the same date
  • The folks who have seen the details say patch now

Some admins have even said they don't want to "break their network" for an unknown vulnerability. News flash- if updating DNS "breaks your network" your network is already broken. This also ignores the fact that there are relatively simple mitigation techniques available, from pointing your vulnerable systems to safe, external DNS servers such as OpenDNS to building and deploying updated servers internally between vulnerable systems and the Internet.

Go ahead, patch. I'll wait here.

[Yes, I know- from the time I started writing this earlier today until the time I hit "post", the details leaked. Those who paid attention to this issue have already patched, those who didn't are (or should be) scrambling.]


Wednesday, July 9, 2008

BlackHat and DefCon, or Preaching to the Choir (Updated)

I'm headed to BlackHat and DefCon in a few weeks. And undoubtedly I will once again point out the disconnect between "real" security types and much of the real world.

So if these events are just a bunch of security geeks and hackers getting together, where's the relevance? Isn't it really just preaching to the choir? What's the point in that when the people who need to get the message aren't there or listening? Why go through the torment and degradation that defines modern air travel just to stress-test your liver?

Oops, posted with a paragraph missing (and a completely different meaning)- here's what should have been included:

There is one very good reason to go to these kinds of events- because as "the choir" it is our responsibility to spread the word to the rest of the world. If we need to hang out with a few thousand other security and hacker types and sacrifice some brain and liver cells to keep up with the latest news so that we can spread the word- I am willing to make that sacrifice for the good of the world.


Tuesday, July 1, 2008

You don't really think the floor mats were free, do you?

Have you ever purchased a car and during the negotiations the salesman offered to throw in free floormats (or some other accessory) to "sweeten the deal"?

News flash #1: If you drop tens of thousands of dollars on this sled, those floor mats are *not* free.

News flash #2: The "free" floor mats may not be the best ones for your needs.

The same applies to "free" features in your IT infrastructure, for example:

  • Built-in VPN clients and protocols are frequently not very robust or secure.
    • PPtP, anyone?
  • Built-in remote access mechanisms are also often not very robust or secure.
    • MS RDP?
  • Manufacturer- or vendor-specific tools don't always "play nice" in mixed environments.
  • Free- if you have enough licenses and excess server capacity.
    • Like WSUS- Windows Software Update Services
      • Only runs on Windows Server OSes
      • Only checks Microsoft products

Don't get me wrong, I like free stuff. And some things included in packages/suites make sense, work well together, and are the best choice (says the UTM engineer).

I just don't believe that free is always the best, or even cheapest, way to go. Sometimes, free is too much to pay.

By the way, Microsoft isn't the only company that does such things, they are just an easy target.