>> Although this seems to be the first bit mistake in over two years, does
>> that make the practice unacceptable as another tool to respond to Bots?
>
> The practice of blocking public EFnet servers?
As I've said multiple times, sometimes mistakes happen and the wrong
things end up on a list. I doubt that was the intent.
Many people have suggested blocking C&C servers used by bots over the
years.
There's a difference between blocking actual C&C servers and blocking
general IRC servers that are incidentally being used as C&C servers.
> Yes, when there are better solutions to the problem at hand.
Please enlighten me.
Intercept and inspect IRC packets. If they join a botnet channel, turn on
a flag in the user's account. Place them in a garden (no IRC, no nothing,
except McAfee or your favorite AV/patch set).
Wow, I didn't even have to strain myself.
... JG
Wow, you are recommending ISPs wiretap their subscribers.
I suspect some privacy advocates will be upset with ISPs doing that.
> > Yes, when there are better solutions to the problem at hand.
>
> Please enlighten me.
Intercept and inspect IRC packets. If they join a botnet channel, turn on
a flag in the user's account. Place them in a garden (no IRC, no nothing,
except McAfee or your favorite AV/patch set).
Pleaes do this at 1Gbps, really 2Gbps today and 20gbps shortly, in a cost
effective manner. Please also do this on encrypted control channels or
channels not 'irc', also please stay 'cost effective'. Additionally,
please do NOT require in-line placement unless you can do complete
end-to-end telco-level testing (loops, bit pattern testing, etc), also
it'd be a good idea to have a sensible management interface for these
devices (serial port 9600 8n1 at least along with a scriptable
ssh/telnet/text-ish cli).
Looking at DPI (which is required for your solution to work) you are still
talking about paying about 500k/edge-device for a carrier-grade DPI
solution that can reliably do +2gbps line-rate inspection and actions.
This quickly becomes non-cost-effective if your network is more than 1
edge device and less than 500k customers... Adding cost (operational cost
you can only recover via increased user fees) is going to make this not
deployable in any real network.
Wow, I didn't even have to strain myself.
sarcasim aside, this isn't a simple problem and at scale the solutions
trim down quickly away from anything that seems 'great' 
using DNS
and/or routing tricks to circumvent known bad behaviours are the only
solutions that seem to fall out. Yes they aren't subscriber specific, but
you can't get to subscriber specific capabilities without a fairly large
cost outlay.
-Chris
Right. However one consolation is that all this is edge filtering,
outbound. And some of it can be pushed off onto the CPE (e&oe
availability of patched CPE)
Outbound traffic volumes wont be as horrendously high as those
inbound, and should be a bit easier to categorize than inbound traffic
DNS and routing tricks are the silliest, to some - but well, they work
for a lot of low hanging fruit. And as you say, they are cost
effective.
srs
> Pleaes do this at 1Gbps, really 2Gbps today and 20gbps shortly, in a cost
> effective manner. Please also do this on encrypted control channels or
> channels not 'irc', also please stay 'cost effective'. Additionally,
Right. However one consolation is that all this is edge filtering,
outbound. And some of it can be pushed off onto the CPE (e&oe
availability of patched CPE)
I'd love to see CPE dsl/cable-modem providers integrate with a 'service'
that lists out 'bad' things. it'd be nice if the user could even tailor
that list (just C&C or C&C + child-porn or C&C older not than X
days/hours/minutes) ... I think it might even help, and be vendor agnostic
(from a provide and hardware) perspective.
Outbound traffic volumes wont be as horrendously high as those
inbound, and should be a bit easier to categorize than inbound traffic
DNS and routing tricks are the silliest, to some - but well, they work
for a lot of low hanging fruit. And as you say, they are cost
effective.
and they are at the control of the provider, which I think is also
somewhat important, people don't know or don't want to police themselves
(in general). Also, the false positive issue will still exist, regardless
of where this 'service' exists. So we'll have to learn to deal with it and
provide workarounds that grandma can do on her own without calling her
vendor (equipment or service).
-Chris
Suppose I add a firewall rule to my router to block traffic to a particular
port. Does my router thereby "wiretap" every packet passing through it
because it needs to find out its destination port in order to determine if
the rule applies or not?
It is sometimes a tricky issue when you filter through legitimate traffic to
stop illegitimate traffic. But a rule that this is always wiretapping of
anything subjected to the automated inspection leads to ridiculous results.
DS