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

Mailman List Mirror (Read Only)
1

> But, hey, it can be done, and with an amount of effort that isn't
> substantially different from the
> amount of work Cox would have had to do to accomplish what they did.

Actually, it's requires a bit more planning and effort, especially if
one gets into sinkholing and then reinjecting, which necessitates
breaking out of the /32 routing loop post-analysis/-proxy.

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

It can
and is done, but performing DNS poisoning with an irchoneyd setup is
quite a bit easier.

Similar in complexity, just without the networking angle.

And in terms of the amount of traffic headed
towards the IRC servers in question - the miscreants DDoS one
another's C&C servers all the time, so it pays to be careful what one
sinkholes, backhauls, and re-injects not only in terms of current
traffic, but likely traffic.

I don't see how what I suggest could be anything other than a benefit
to the Internet community, when considering this situation. 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%. 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.

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

In large networks, scale is also a barrier to deployment. Leveraging
DNS can provide a pretty large footprint over the entire topology for
less effort, IMHO.

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.

Also, it appears (I've no firsthand knowledge of this, only the same
public discussions everyone else has seen) that the goal wasn't just
to classify possibly-botted hosts, but to issue self-destruct
commands for several bot variations which support this functionality.

The road to hell is paved with good intentions. The realities of the
consumer broadband scene make it necessary to take certain steps to
protect the network. I think everyone here realized what the goal of
the exercise was. 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.

[Note: This is not intended as commentary as to whether or not the
DNS poisoning in question was a Good or Bad Idea, just on the delta
of effort and other operational considerations of DNS poisoning vs.
sinkholing/re-injection.]

Public reports that both Cox and Time-Warner performed this activity
nearly simultaneously; was it a coordinated effort? Was this a one-
time, short-term measure to try and de-bot some hosts? Does anyone
have any insight as to whether this exercise has resulted in less
undesirable activity on the networks in question?

That's a very interesting question. I would have expected the bots in
question to be idle and abandoned, but perhaps that is not the case.

... JG

2

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

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.

;>