-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Bill Nash Sent: Saturday, March 12, 2005 4:40 PM To: Fergie (Paul Ferguson) Cc: nanog@merit.edu Subject: Re: IRC bots...
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.
[ SNIP ] Who's got time for all that? Chase the controller, shut down the user until they buy some AV software. We've gone beyond "I didn't know" for endusers in most regions. This problem turned into the spam problem faster than the spam problem did. -M<
On Sat, 12 Mar 2005, Hannigan, Martin wrote:
[ SNIP ]
Who's got time for all that? Chase the controller, shut down the user until they buy some AV software. We've gone beyond "I didn't know" for endusers in most regions.
Enterprise IT staff running from whip-cracking security staff, that's who has time for it. Unless, however, you have no security requirements surrounding your accounting records, network inventory, provisioning tools, and credit card processing services. Other reasons: .. if you're providing a premium service to business grade customers who can sum up their connectivity requirements as '80, 443, 25, 53, period.' ..if you're running honeynets. ..if you're providing structured services with explicit controls on what goes on (ala AOL, some .edu networks, etc.) ..you've been singled out by your peers because a significant portion of large DDoS attacks are originating from your network. ..you've been singled out by accounting because of the traffic costs involved with sourcing DDoS attacks. As popular as instant messenger, and increasingly, voip toys, have become, actual IRC usages represents a diminishing percentage of inter-user chatter. Even something as simple as carving irc usage out of your netflow records and tagging specific endpoints as potential sources is a piece of automation that will save you some time down the road. A decent network inventory would facilitate this. - billn
On Sat, 12 Mar 2005 17:09:17 -0800 (PST) Bill Nash <billn@billn.net> wrote:
As popular as instant messenger, and increasingly, voip toys, have become, actual IRC usages represents a diminishing percentage of inter-user chatter. Even something as simple as carving irc usage out of your netflow records and tagging specific endpoints as potential sources is a piece of automation that will save you some time down the road. A decent network inventory would facilitate this.
While most IRC traffic, even much of the so called 'bad' IRC traffic uses TCP 6667, IRC traffic that doesn't is not easily discerned through traffic flows except for perhaps with a pre-defined list of addresses and ports to seed monitoring with. Tallying then just the TCP 6667 traffic, perhaps eliminating very short lived or small flows, should be a good indicator of IRC traffic usage, but tagging those as potential sources for problems may be difficult. Perhaps in environments where IRC as an application is strictly forbidden or blocked this will work well, but on more open and larger network this may waste time, not save it. Since in the latter case, figuring out what is legit and what is not will likely be a lot of leg work. You can automate some of this further, by building white lists or black lists of IRC server addresses. A white list doesn't tend to scale very well. A black list scales better, but you have to get those black listed addresses and doing that part is harder. There are some people/groups who spend time finding black list hosts so leveraging their data can be very useful and time saving. John
On Sat, 12 Mar 2005, John Kristoff wrote:
Tallying then just the TCP 6667 traffic, perhaps eliminating very short lived or small flows, should be a good indicator of IRC traffic usage, but tagging those as potential sources for problems may be
Yes and no, in my experience. Depending on the drone, some connect to a server and stay connected. You could say the inverse is true, and look for long connections, but that will likely snare you legitimate traffic from the screen-running nerd set.
difficult. Perhaps in environments where IRC as an application is strictly forbidden or blocked this will work well, but on more open and larger network this may waste time, not save it. Since in the latter case, figuring out what is legit and what is not will likely be a lot of leg work.
This is why I suggested a snort filter, to actually inspect the packet traffic. Watching IRC traffic is only valid so long as the standard ports are being honored. What about bounces, and non-standard traffic? You need to go after the single common property, the protocol itself. Even so, you're still in an arms race.
You can automate some of this further, by building white lists or black lists of IRC server addresses. A white list doesn't tend to scale very well. A black list scales better, but you have to get those black listed addresses and doing that part is harder. There are some people/groups who spend time finding black list hosts so leveraging their data can be very useful and time saving.
This will backfire, in my opinion. Many drone nets hide in plain sight, connecting to public IRC networks where they can't reliably be traced to an authoritative user. You'll bejuggling access to public resources, and that's a waste of energy, I think. - billn
* Martin Hannigan:
Who's got time for all that? Chase the controller, shut down the user until they buy some AV software.
That should read "AV software from at least three vendors, with direct contacts to research staff of at least one of them", or something like that. While it's very likely that there is at least one vendor which ships signatures that already recognizes the malware you are experiencing, it's far less likely that the single scanner/signature combination you've chosen for desktop installation catches it. Standard, out-of-the-box AV software (with signature updates, of course) is no longer an option for fixing infected machines, at least not without qualified support and independent verification of the results. It's long been said that you shouldn't rely on AV software for recovering from infections (and curiously enough, this was never the way people dealt with UNIX breakins). We are now at a point where the automated tools actually fail, and not just for some philosophical reason (e.g. the bot has got a download component and you just can't know what further malware has been downloaded). (And there's the problem that the users can't get online updates without the Internet connection you've taken away, and AV vendors do not permit mirrors of signature definitions on your network.)
On Sun, 2005-03-20 at 14:25, Florian Weimer wrote:
* Martin Hannigan:
Who's got time for all that? Chase the controller, shut down the user until they buy some AV software.
That should read "AV software from at least three vendors, with direct
Am I the only one who is getting mailbombed by dozens of these duplicate messages? -Alan
On Mon, 21 Mar 2005, Alan Sparks wrote:
On Sun, 2005-03-20 at 14:25, Florian Weimer wrote:
* Martin Hannigan:
Who's got time for all that? Chase the controller, shut down the user until they buy some AV software.
That should read "AV software from at least three vendors, with direct
Am I the only one who is getting mailbombed by dozens of these duplicate messages? -Alan
Could have something to do with folks not trimming conversation participants from the TO: fields. - billn
On Mon, Mar 21, 2005 at 09:31:35AM -0800, Bill Nash wrote:
On Mon, 21 Mar 2005, Alan Sparks wrote:
Am I the only one who is getting mailbombed by dozens of these duplicate messages?
Could have something to do with folks not trimming conversation participants from the TO: fields.
Or, more closely, with people whose mailers don't support "reply to list" (or it's first cousin: "reply to recipient"), and therefore have to use 'G'roup reply to answer list mail. Cheers, -- jr "let us take the obligatory munging thread off-list, 'k?" a -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system adminstrator. Or two. --me
participants (6)
-
Alan Sparks -
Bill Nash -
Florian Weimer -
Hannigan, Martin -
Jay R. Ashworth -
John Kristoff