Somewhat related to operational issues... It was interesting to read the "daily handler" log at the ISC which related their experiences with detecting (and disabling/disinfecting) a machine/network infected with several IRCbot drone computers. As someone who has had to deal with with this issue on several customer networks, it is sometimes intriguing at the length at which some of the developers of these damned things go through to accomplish their feats. :-) http://isc.sans.org/diary.php?date=2005-03-10 - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net
On Sat, 12 Mar 2005, Fergie (Paul Ferguson) wrote:
Somewhat related to operational issues...
It was interesting to read the "daily handler" log at the ISC which related their experiences with detecting (and disabling/disinfecting) a machine/network infected with several IRCbot drone computers. As someone who has had to deal with with this issue on several customer networks, it is sometimes intriguing at the length at which some of the developers of these damned things go through to accomplish their feats. :-)
A fun solution to mitigating this problem: NAT or PBR to funnel all standard outbound IRC traffic to an internal ircd of your choice. When that doesn't work anymore, throw Snort on egress SPAN segments doing protocol inspection for irc protocol 'CONNECT' and similiar, hitched up to a syslog analyzer to catch outbound connections in real-time. The right tools in the right place would let you hitch the alarm to trigger execution of a utility capable of injecting packets into the stream to send RST in both directions. False positives might be a problem. I officially declare them to be 'yours.' ;) - billn
participants (2)
-
Bill Nash -
Fergie (Paul Ferguson)