2.0.6 against 3.0 scan data

	I think I finally have something that works on 2.0.6 and 3.0 looking
at the same data. It isn't easy, as 3.0 is getting things much righter that
2.0.6 did. In the end there are two rules:

1) If the src port is <1024 and the dst port is >1023 assume its backwards 
   and invert source and destination (as noted this still occurs on 3.0). 

2) if neither port is < 1024 then increment a counter for "src_ip src_port"
   and "dst_ip dst_port" in two associative arrays and save the data in a 
   third array til we have seen the entire hours data.
	Then if the "src_ip src_port" count is > than "dst_ip dst_port" assume
   its backwards and invert it. That seems to bring the 2.0.6 data mostly in
   to line with the 2.0.6 data (and in any case is more correct for scan 
   detection as the common target port is dst as it should be). There are 
   still minor differences but some of that is traffic in one stream that isn't
   in the other (probably to do with cron switchs on two different machines 
   not being in sync) but a lot better than the initial one. 

	I'm about to make the change in our production 2.0.6 setup and let it
run for a few days to see how the two match over time and then I should be 
finally ready to update the traffic scripts one last time for 3.0. I don't 
think this is going to make any large difference either way since the old code
manages to agree pretty much completely with DSCC about what hosts are scanning
and should be whacked, so the old method was getting scanning right enough for
government work, just not right enough when being compared with a 3.0 ra 
looking at the same data. 

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

ICMP Flow

Re: ICMP Flow