[BBLISA] maximizing DNS security

[Dean Anderson]

On Sat, 3 Apr 2010, Tom Metro wrote:

> Dean Anderson wrote:
> > Tom Metro wrote:
> >> Plain DNS has plenty of security problems...
> > 
> > I'm not sure what you mean. That DNS protocol is insecure or DNS
> > Registrars are insecure? 
> 
> DNS. Nothing to do with registrars.
> 
> DNS itself has a track record of problems. 

Yes. And that the leaders at the IETF are crooked, doesn't help. 

> No encryption. No authentication. Uses easily spoofed UDP. Is subject
> to cache poisoning, interception, etc.

Actually, spoofing UDP is not as easy as many think. Using port
randomization (done since the late 1990s) it takes (eg ordinary DJBDNS
configuration) 26 million packets to successfully spoof UDP, unless the
attacker can intercept queries to obtain both the port and the QID.
After years of suppressing criticism of BIND, Bind has finally begun to 
use port randomization in 2009.

TCP DNS is impossible to spoof unless you can intercept packets.

And DNSSEC is still subject to cache poisoning. You should read my NTIA 
comments.  http://www.ntia.doc.gov/dns/comments/comment027.pdf

Its pretty much impossible to "secure" DNS in any practical way.
DNSCurve is a possibility.  But I point out that if you have an attacker
in the path, one has much bigger problems than DNS spoofing. If the
attacker is not in the path, DNS is practically invulnerable.  The
effort to "secure" DNS is probably misplaced effort.

> But there are differences in how secure the management of your zone is
> in the outsourced vs. in-house scenario.

Not really. In either case you have to authenticate and change resource
records. Whether you do that via ssh or web app makes little difference.

The social engineering aspect may or may not be different.  While its
probably hard to fool your direct coworkers with a social engineering
scam; but in a large company, the people who change passwords may not
actually know you, and so can be fooled if they don't insist on proof of
identity.


> Have you read the transcripts in my BLU thread?

No. I'll have to look at that. 


> If an attacker is persistent, all it takes is one employee that
> doesn't strictly adhere to security policies - say the new guy that
> thinks he's being extra helpful to this poor customer that can't get
> "windowz" to work right - to give away the keys to your account. (In
> my case, my attacker was lucky enough to find 4 or 5 employees, plus
> some newly introduced chat software that employees put way more trust
> in than they should have.)

Not getting windowz to work right is no excuse for lack of proof of
identity.  That's a training/procedure problem. There are no technical
solutions to that.

> If there are people involved, you're vulnerable to social engineering.  
> The degree just depends on how good the training is at your provider.

Agreed.

> In fact, I'd recommend anyone that uses outsourced services
> periodically test their provider using social engineering techniques
> to gain information or access to your own account.

Better operations ought to do this themselves. But like someone pointed
out, for $8k any yahoo can be a registrar. There is no requirement that
they be well trained. You don't get what you don't pay for.  I use
NetSol, because they are big, have the training, and they've been
through it.

> > Social engineering attacks require a deception to occur, and there
> > is no reason that the outsourcing company should easily accept
> > deception, any more than your ISP or bank should accept deception.
> 
> Yet it seems to happen with some regularity.

Yes. But that's what defines reputation.

> So the objective I'm trying to achieve is having a system where those
> services that are outsourced, are as much as possible out of the
> control of the vendor's employees to modify.

That's impossible.  The vendor's employees' _have_ to be able to modify
your account authenticator. And with that change, goes everything else
you can modify.  The attackers aren't slipping in somehow. They
_ARE_YOU_, at least, so far as anyone knows. They can do whatever YOU
can do.  You have to be able to do certain things, like change a
password, alter configuration.  You can't limit those things without
shooting yourself in the foot, too.

> Outsourcing secondaries only, and not zone management, seems like a
> step in this direction.

This is probably a good idea, as it free's you from the tedium (and
bugs) of your vendor web app for changing RR records.  But it doesn't
eliminate the problem. If someone gets the password to the vendor, then
they can change primary, and still alter RR records.

And if the registrar is fooled, then the authority servers can be
changed.  Use a reputable registar.

		--Dean
-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494