Re: IRC, IM Proxy Implementations

[Richard Gadsden <gadsden () MUSC EDU>]

On Sun, 5 Sep 2004, Mike Porter wrote:

> > This kind of retrospective analysis is useful enough for forensic/recovery
> > purposes to make it a routine part of incident response, and it can even
> > be used to reveal other compromised machines before they start overtly
> > misbehaving (if they are found to be engaging in "IRC-like" communication
> > with the same remote "IRC-like" server that a known-compromised host was
> > observed to communicate with shortly before it began misbehaving).
>
> How do you handle machines seen using "IRC-like" behavior.

If we have sufficient evidence that a machine has been compromised then
the first step in our response is to remove it from the network.

> I encounter a great deal of resistance to any sort of "guessing".
> Generally, I have to "prove" a problem before turning off ports.

Formal mathematics aside, the only real difference between a guess and a
proof is in the overall quality and quantity of the evidence supporting
the conclusion: guilt, innocence, or indeterminate.

> To be fair - it is a lot of work for someone to go over the machine
> and clean it up - particularly if there isn't anything actually
> wrong.

Sounds like a very strong incentive to get it right, i.e. to be
conservative... most edu's having a very low tolerance for false positive
rates greater than zero :-)

> Complicating matters: we do not have a policy prohibiting p-2-p.
> p-2-p and irc behavior are pretty easy to spot.  Telling the
> difference between the two seems harder, particularly when dealing
> with non-standard ports.

That may be true, but suppose internal client A engages a
never-before-seen external server X in conversation on a given (standard
or non-standard) port, and 5 minutes later A starts misbehaving in a very
obvious and threatening way. Then internal client B engages the very same
unfamiliar external server X in a strikingly similar conversation on the
very same port, and surely enough, 5 minutes later B starts misbehaving in
the very same way that A did.

Then internal client C engages X in the very same type of conversation on
the very same port that A and B did.

At this point, I think any reasonable person would consider this to be
sufficient "proof" to justify pulling C off the network without waiting
the 5 minutes for C to start misbehaving.

You're right, just looking at the A<->X flows by themselves, or the B<->X
flows, or the C<->X flows, you may not know whether it's irc or p2p or
something else entirely, but -sometimes- you can still draw actionable
conclusions -- if the overall traffic patterns are sufficiently
distinctive to "prove" that a machine has been compromised using the same
mechanism by which other machines are known to have been compromised.

> The only tool I have for network monitoring is Netflow.

We use argus here.

-Richard

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/cg/.