argus-clients informal survey

[Russell Fulton]

On Thu, 21 Jun 2001 19:43:35 -0300 Chris Newton <newton at unb.ca> wrote:

> Yes, this is the sort of solution I was imagining, however, I have seen cases 
> where the single direction concept (drop remote side, keep locals) wouldn't be 
> enough. 
> We have had a couple cases where a trojan got installed in some unix 
> lab run by a department that is less interested in security then mine is (the 
> main computing center).  That lab was on a student network, with a netmask of 
> 255.255.240.0.  The intersting thing about this trojan, is that it used this 
> netmask it found on the machines as a guide to determine the range of possible 
> addresses it could spoof on this network, and have them all be valid.  So, 
> boom, an outgoing attack from 'thousands' of machines on our student network, 
> aimed at some poor soul out there in the big merky internet, which our routers 
> gladly sent on their merry way, since they were all valid IP addresses, 
> routes, TTLs, ...

Ouch! we have been spared that so for.  Mind you with just a few Mbps 
of external bandwidth we are not a tempting target for this sort of 
thing.  There are some advantages to being at the far end of the earth 
;-)

> 
>   So, I think the highwater mark would need to work both ways...  maybe if a 
> count was added to each IP address that argus was tracking...
> 
>   So, if 131.202.160.212 local is being attacked, each new flow you create, 
> that is associated with that IP, increment the counter.   Reset that counter 
> each time you print a MAR record.  If in that interval of time of the MAR 
> records, the IP has more then xxx records associated with it... start adding 
> all info to a single flow record.  And, maybe in this record, keep a count of 
> the number of unique remote IP addresses you are including in this 
> aggregation.  Do this logic with both sides (remote, local), and I think argus 
> would be stable at these high packet count levels.

This sounds like a sensible approach.  Long term it would be nice to 
have this stuff configurable in the flow model file.

eg.
if source_flowcount > xxxx use model yyy
if dest_flowcount > zzzz use model aaa



Russell Fulton, Computer and Network Security Officer
The University of Auckland,  New Zealand