[ 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<
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
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
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.)
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
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