North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: DNS Hijacking by Cox

  • From: James Hess
  • Date: Mon Jul 23 01:53:51 2007
  • Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kXcvIxsAHe8MOTMqKrFI1zUXipQmfnhGQ1/mkfOt8R6SlBTb+PqrPJmZDqCQLKQqaU+KREGFxDZ8sBI5GW2bfQYu8NPHKFSYK69eafd7uCHyg+iJTdA/u57uQbiUZkleDdA725rFj5Sfjv034D4eCwGiAROBVqbudjRASHUhMrA=
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M6YgMNtqqxk4w2K0I77tFHMd0utbIJ6FY8dsrR4Xuo65X5ciQtFcbqPDd1ILrcUdSirbayfq4HhiSH6tIksjltSNA8HuYiH65dSYqPdrOqcxw8+oesTvpMgA7aBQPwbT8fY7PxMUH0AmCKH3YtU5EPBd74IhTrKRKpapUxH/t5Q=

On 7/22/07, Steven M. Bellovin <[email protected]> wrote:

I would suggest not underestimating the ingenuity and persistence of
the bad guys
to escalate the neverending war, when a new weapon is invented to use
against them.  If there's a way around it, history has shown, the new
weapon quickly becomes  worthless, you get to use it maybe for a month or two.


Maybe that's enough, if you can be assured of constantly coming up with new
improvements.  It's really tiresome stuff, and if ISPs do it, they'll
find themselves
having to get more and more invasive for each "new and improved"
anti-bot weapon.


Much more likely than not the bad guys even read the list (if not the other
few security lists where the events of reported DNS mangling by Cox have been
mentioned) and now know how to proceed to minimize the disruption to their
annoying botnets.

Hint: the "common ways to try to remove a bot" are not hard for bots to detect;
kiddies often scripted the things to not allow removal, anyways.


End result:  Legitimate IRC users get blocked, script kids quickly adapt,
and get their well-hidden botnets back into place and "patched"
against DNS-based
hacks in the future.

Conclusion: Everybody loses (ISP and legit IRC users), except the
script kiddies
now have more robust junk (and another victory).


So -- I think that DNSSEC, if deployed, will protect users who care,
even against their ISP.  It won't protect the clueless; I'm not sure


I would suggest the "protection" you get with DNSSEC is not so solid, even
for the non-clueless.  I see DNSSEC alone as no protection by itself,
even with the additional assumptions.

An ISP can possibly instead of "changing" the DNS, "redirect" traffic
destined for the actual target IP address (from their own users), or
push traffic through transparent proxies that accomplish the same end..


In fact, it will be less visible to the user what is occuring (at least with DNS
manipulations, the user can _SEE_ that what happened, if they are not
among the clueless, and maybe get around DNS mangling, by skipping
DNS and going to the _right_ IP)


IRC traffic is much like SMTP in certain respects -- it is not
encrypted, there is no
digital certificate that can be used to verify the peer legitimately
uses the ip address
(or dns name) you think it does when you connect.

And spammers are a problem (Unauthorized bot nets logging on to IRC networks are
really just a very bad type of spammer, a type that is often very
difficult for IRC networks
to detect and eliminate; and IRC networks risk all their IRC servers
being DDoSed
later in retaliation, just for trying to kill off a botnet -- the d***
things may
just autoconnect to the next network, and switch secret channels, from
a list with God
knows how many entries....).


-
I am doubting most of the world sees DNSSEC implementations as the
ideal solution to any current problem -- compared to the current DNS, it seems
like overkill to digitally sign everything..


Considering the excessive bloat and overhead of DNSSEC implementations,
when there is a bigger hole in the security of the  underlying
protocol (TCP/IP itself)


The canonball-sized hole (Your ISP can pretend to be any IP address they want)
should have priority to be be plugged, it should be "way ahead" on the list of
the pinhole (Your ISP can pretend that a given name is associated with any IP
address they want instead of the correct one).

OTOH, universally deployed IPSEC seems even farther off.

If it is even a workable plan for a netizen (to distrust the ISP),
considering the
ISP can always, after all,  block instead of redirect.


--
-J