2.0.6 against 3.0 scan data
Peter Van Epp
vanepp at sfu.ca
Thu Oct 2 15:55:53 EDT 2008
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
More information about the argus