Re: IRC bots and SOPs regarding
Hi, Thank you to everyone who responded. I always avoid asking for help on NANOG because it leads to a flood! However, that is a great thing when you really need something fast :) Eric On 1-May-07, at 9:49 AM, Eric Frazier wrote: Hi, Is there someone who can contact me off list, who might be looking for some billable consulting hours? Thanks, Eric
Re: IRC bots...
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[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe 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
Re: IRC bots...
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
Re: IRC bots...
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
Re: IRC bots...
* 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.)
Re: IRC bots...
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
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. 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
RE: IRC bots...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
RE: IRC bots...
No duh. This is particulary _why_ I posted. It is an operational problem if I've ver seen one. - ferg -- Hannigan, Martin [EMAIL PROTECTED] wrote: This problem turned into the spam problem faster than the spam problem did. -M -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
RE: IRC bots...
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
RE: IRC bots...
-Original Message- From: Bill Nash [mailto:[EMAIL PROTECTED] Sent: Saturday, March 12, 2005 8:09 PM To: Hannigan, Martin Cc: Fergie (Paul Ferguson); nanog@merit.edu Subject: RE: IRC bots... 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. The botnet problem is in Internet policy land, FWIW. It's operational. For now. I think it's controllable at the 'security policy' level for corporations. My point regarding it being the same as spam is that many people are already not interested in it for the same reasons as spam. YMMV. [ SNIP ] -M
Re: IRC bots...
On Sat, 12 Mar 2005 17:09:17 -0800 (PST) Bill Nash [EMAIL PROTECTED] 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
