RE: [ga] Net security's a losing battle

[Roeland Meyer <rmeyer@mhsc.com>]

|> From: Sandy Harris [mailto:sandy@storm.ca]
|> Sent: Friday, September 28, 2001 8:13 AM

[snip:// many really good references to security]

|> Yes, but there are things that would have a positive impact. 
|> Notably, the
|> IETF has been at work for some years on protocols for a 
|> secure DNS. See:
|> 
|> http://www.toad.com/dnssec/index.html
|> http://www.ietf.org/html.charters/dnsext-charter.html
|> 
|> Currently, DNS is almost completely insecure. All the 
|> servers just accept
|> whatever another server tells them as gospel.

Excuse me. After all that good work, I must object to this. The current
system is actually quite good and it's all IP-based, not by name. Iff you
build to run a RFC2870 compliant server, which all zone server operators
should at least consider. You primary zone servers become non-recursive
vaults. You should have at least two and those two should be the ONLY ones
in the name server registration at the InternNIC and in the root zone file.
Your DNS resolvers should be at another IP address and should be the only
ones referenced in your zone files. Updates should only be allowed from
known IP addresses. TCP Wrappers should protect ALL systems from connecting
to strangers, via hosts.allow and BIND access control lists (ACL). Do not
take zone updates except from known systems and do not allow zone transfers,
except to known systems. Allow queries from anyone. Only use BIND, under
*nix, for public facing DNS servers. Even MS-DNS, as implemented under Win2K
Active Directory, allows this level of control (although I would never use
it to implement a zone server). Most routers are secured similarly.

Now, as to the threat of sniffing, Most modern networks are almost pure
switched, sniffers (including SNORT) don't work very well here or anywhere
else. The perp would have to actually get on the WAN port(s), for a
man-in-the-middle attack. co-opting a insecure host, doesn't buy you much
these days, especially on another switched subnet (you don't even see the
broadcast packets).

|> Currently, if an EvilDoer can intercept DNS queries or 
|> subvert a server,
|> then he or she can do almost anything. Tell you 
|> bigcompany.com does not
|> exist, send anyone who asks for that company to big_company_sucks.org
|> instead, or send everyone to Pornographic Priscilla's 
|> Punishment Pagoda.
|> Or, by subverting the DNS an e-commerce site relies on, send all that
|> site's customers to a bogus bank for their credit card transactions.
|> Or ...
|> 
|> If critical infrastuture relies on the net and therefore on DNS, then
|> clever variants of DNS attacks can do enormous damage. Other measures
|> -- such as PGP-signing any important email and widespread 
|> use of secure
|> IPsec tunnels -- can vastly reduce the risks here, but it is far from
|> certain they can reduce it to zero. 
|> 
|> The obvious fix is to build authentication into the DNS software so
|> that servers can tell what information they can trust. Most of the
|> work of specifying appropriate protocols for this has been done.
|> See the IETF site above. 
|> 
|> I'm not certain what state the implementations are in. Certainly some
|> work has been done, e.g. in BIND 9 (www.isc.org), but I don't know
|> how complete that is, or how widely deployed, or whether other DNS
|> servers have DNSsec support yet.
|> 
|> Once there are viable implementations, questions arise of how to get
|> zone records (especially the root zones) signed, and more generally
|> how to run a secure DNS. These will largely be decided in the IETF 
|> DNS Operations working group:
|> 
|> http://www.ietf.org/html.charters/dnsop-charter.html
|> 
|> However, methinks ICANN might have a role to play in ensuring that
|> the registrars actually act on this in a timely fashion, and that
|> Verisign or others do not attempt to hijack the process into becoming
|> a marketing scheme for proprietary signature technologies.
|> 
|> I raised these questions about a year ago and got responses 
|> indicating
|> that some knowledgable folk considered this out of scope for 
|> ICANN and
|> that, in any case, the IETF work was not finished so the 
|> questions did
|> not arise yet.
|> 
|> That was then, this is now.
|> 
|> If the focus of the next ICANN meeting is to be security, methinks
|> the question of what ICANN needs to do about DNSsec depolyment goes
|> right at the top of the agenda.
|> --
|> This message was passed to you via the ga@dnso.org list.
|> Send mail to majordomo@dnso.org to unsubscribe
|> ("unsubscribe ga" in the body of the message).
|> Archives at http://www.dnso.org/archives.html
|> 
--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html