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

[Roeland Meyer <rmeyer@mhsc.com>]

[sorry, I wasn't finished, accidently hit send]

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

[sorry, I wasn't finished, accidently hit send]

In order to intercept queries,or any other packets, one must be in logical
line of transit. That is, ALL packets have to go through Joe Evildoer's
host/router. This is a classic man-in-the-middle attack scenario. It is
amazingly difficult to do. Usually, only your upstream can even think about
it and ONLY if you aren't multi-homed, or running some sort of dynamic
routing protocol, like BGP4, or not using a VPN. In all cases, this scenario
is not so difficult to detect. In fact, SSH based VPNs will detect this
immediately.

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

I'm sorry, but it has been standard practice, at MHSC, to outfit an
ecommerce site with it's own DNS cluster, including root-zone authority and
internal TLDs. We charge about $12K for four DNS appliances (2 RFC2870 zone
servers and 2 stub-resolvers) and to configure them (it takes 10 IP
addresses). Anyone doing eCommerce will have their own subnet, or at least a
/27, simply because they are not going to bet the whole farm on a single
host. In fact, for various production operations reasons, you are going to
have at least eight (8) multi-homed hosts (including routers and switches,
each with mutiple IP addresses per NIC), mounted in a colo farm, like
AboveNet. Or have a minimum of a DS1, in your office complex, along with the
rest of your office LAN, also a subnet. Anything less, begs for trouble.

Given that, plus what I stated above that, It is physically difficult to
subvert that site's DNS subsystem or any other part of that site. This is
basic network architecture (see http://www.mhsc.com/roles.htm), along with
multi-tiered LAN architectures (RDBMS hosts shouldn't even be physically
visible to the Internet.  It goes without saying that none of this should be
NAT'd. Those who don't do this, or something like it, will feel (have felt)
the Darwin-Effect.

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

No security risk can be reduced to absolute zero. But, one can reach a
cost-effective mitigation point. Personally, I feel that every packet should
use strong encryption and every session should use reasonably strong
authentication.

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

There are infrastructure problems, usually involving NAT, for both IPSEC and
DNSSEC. Most of it due to the lack of PKI standards and systems.

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

Many of us have just about given up on the IETF producing anything useful
and non-political these days. Short-sighted geeks clash with business
requirements (and often disregard the latter). Besides, running DNS, inside
of a VPN, obliviates the need for DNSSEC.

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

Yes, that is my fear as well. But, I run a CA too<g>.

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

It's still out of primary scope for ICANN. ICANN needs to secure its own
systems, that is all.

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

No it doesn't. Or, in a more politically correct phrase ... I disagree.


--
R O E L A N D  M J  M E Y E R
Managing Director
Morgan Hill Software Company
tel: +1 925 373 3954
cel: +1 925 352 3615
fax: +1 925 373 9781 
http://www.mhsc.com
--
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