[BBLISA] maximizing DNS security

Tom Metro tmetro+bblisa at vl.com
Sat Apr 3 01:37:19 EDT 2010


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. No encryption. No 
authentication. Uses easily spoofed UDP. Is subject to cache poisoning, 
interception, etc.

As I recall there have been security problems with domain transfers as well.


> Outsourced DNS protocol is no more or less secure than in-house DNS
> protocol.

As far as the above issues I mention are concerned, you are correct. 
We're still stuck with the same protocol.

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


>> ...I'm wondering about how outsourced DNS, which leaves you open to
>> social engineering attacks, compares to in-house management.
>
> Outsourced DNS registration or DNS operation shouldn't be vulnerable to
> social engineering attack without some elaborate efforts at identity
> theft. (ie "Hello, please change my MX record to ...")...

Have you read the transcripts in my BLU thread?

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.)

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

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.


> 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.


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.

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

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/



More information about the bblisa mailing list