Re: stopping bots from phoning home

[Kevin <kkadow () gmail com>]

On 8/31/05, mason () schmitt ca <mason () schmitt ca> wrote:
> It seems that the majority of bots connect to an IRC server in order to
> get their instructions and some spyware is starting to do the same.  So if
> the avenue for abuse of an infected machine is via connection to IRC
> networks, why not block all outbound IRC traffic (we have a Packeteer
> packet shaper that I think can classify IRC traffic regardless of the port
> it runs on) and implement a proxy that legitimate users of IRC have to log
> into in order to gain access to IRC servers outside our network?

Sounds like a good plan, even without bots in the picture.

There are a few open source IRC proxies, including bnc, JBouncer, etc.


> This way an infected PC can't phone home, legitimate use of IRC is
> still possible with only a slight hurdle, and I can log all traffic that
> hits my block so that I can investigate those PCs.

We take this a step further -- let all traffic that hits the blocks talk
to a "sandbox" minimal IRCd, and if the traffic looks like bot chatter,
quarantine the source host.

If enough sites start doing this, the Zombie Masters will find a
new C&C channel for their 'bots, perhaps SSL web sites on TCP/443...


>  However, I'm not talking about our company LAN or the servers that I
> manage.  The network that takes the majority of my time is our customer
> network.

I'm not sure that an explicit proxy solution will fly in a public ISP,
customers just are not going to be comfortable with having to jump
through hoops when they're used to just being able to click on the
"live chat" button on their brokerage or Invader Zim webboard and go
right into a conversation.  Most of the time the user doesn't even know
they are using IRC!


> I've posted before, but not often.  I'm a sysadmin for a small cable ISP.
> I  frequently struggle with the seemingly unworkable position of being
> transparent to our customers while simultaneously protecting them from
> themselves and the "big bad net".  As you can well imagine, I can't make a
> default deny stance work in this environment, so I am left with exactly
> what I don't want to be doing which is watching for problems and trying to
> stop them before they make a real mess...  Needless to say, this sucks.

I don't know that the situation can be made to suck any less for a
public ISP.  I've been in that boat, am glad to be back on dry land.

Kevin Kadow
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards