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 _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
