How should ISPs notify customers about Bots (Was Re: DNS Hijacking

Tue Jul 24 19:29:21 UTC 2007

On Jul 24, 2007, at 11:01 AM, Joe Greco wrote:

> Since what I'm talking about is mainly IDS-style inspection of  
> packets,
> combined with optional redirection of candidate hosts to a local
> "cleanser" IRCD, the only real problem is dumping outbound packets
> somewhere where the /32 routing loop would be avoided.

On a large network, particularly a network which hasn't already  
deployed a sinkhole/re-injection system which covers all the relevant  
portions of this topology, that's a lot of work.  Transit networks  
are probably more likely than broadband access networks to've done  
so, IMHO (I've no knowledge of whether any of the relevant SPs have  
or haven't done so, that's just a general observation).

>   Presumably it
> isn't a substantial challenge for a network engineer to implement a
> policy route for packets from that box to the closest transit (even
> if it isn't an optimal path).  It's only IRC, after all.  ;-)

But we're talking about multiple destination points, and the static  
nature of [Cisco, at least] PBR doesn't always lend itself well to  
that kind of model.  Multipoint GRE potentially does, but again,  
that's more infrastructure to plan and deploy.

> Similar in complexity, just without the networking angle.

In much the same way that flying an airplane is similar to driving a  
car, just without the 35,000-feet-in-the-air angle.

;>

> I don't see how what I suggest could be anything other than a benefit
> to the Internet community, when considering this situation.

I think sinkholing and re-injection is a very useful technique, and  
constantly exhort operators who haven't done so to implement it.  My  
point was that if one hasn't implemented it, there's a substantial  
effort involved, one that's more complex than implementing DNS  
poisoning.

>   If your
> network is generating a gigabit of traffic towards an IRC server, and
> is forced to run it through an IDS that only has 100Mbps ports, then
> you've decreased the attack by 90%.

And one may've backhauled a gig of traffic across a portion of one's  
topology which can ill-afford it, causing collateral damage.  Always  
a concern with any kind of redirection technology, it's important to  
monitor.

>   Your local clients break, because
> they're suddenly seeing 90% packet loss to the IRC server, and you now
> have a better incentive to fix the attack sources.

There are other incentives which are less traumatic, one hopes.

;>

>
> Am I missing some angle there?  I haven't spent a lot of time  
> considering
> it.

See above.

;>

>> Yes, there is some truth there, especially in networks made up of
> independent autonomous systems.  DNS redirection to a host would
> favor port redirection, so an undesirable side effect would be that
> all Cox customers connecting to irc.vel.net would have appeared to
> be coming from the same host.  It is less effort, but more invasive.

Yes - sometimes more invasive methods are necessary, depending upon  
one's goal.

>   The point is that there are other ways to conduct such an  
> exercise.  In particular, I firmly believe that any time there
> is a decision to break legitimate services on the net, that we have an
> obligation to seriously consider the alternatives and the  
> consequences.

Yes, but it's also very easy to second-guess what others are doing  
when not in full possession of the facts.  None of us are, so it's  
probably a bit premature to speculate about someone else's chain of  
reasoning and then attack his logic, in the absence of any concrete  
information regarding same.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at cisco.com> // 408.527.6376 voice

	Culture eats strategy for breakfast.

            -- Ford Motor Company