[c-nsp] Log analyzer/ACL advice

[Anton Kapela]

> For something which watches syslog, search for 'System Event 
> Correlator'.

SEC, as Roland mentions, is an excellent tool. I also make use of
'swatch' (google: swatch), and would recommend you investigate it's
functionality.

Returning to your overall goals for a bit, I've been told by others (and
agree) that it's best to watch both:

1) un-announced IP space (I mean unannounced in a IGP sense so as not to
further encourage or promote those who deagg to /24's for no apparent
reason) at various points of ingress and egress within your network.
That is, keep on nailin' your appropriate routes towards null0, but then
set statics up pointing out at some directly attached sampling or
analysis system.

That is, on ibgp/ebgp peering routers, you'd have:

3.4.64.0/20 -> null0 distance 254 (normal, standard, etc)

Then to forward more specifics of this /20 which are not in use (and
assuming you don't give a customer a /21 directly), you'd setup:

3.4.64.0/21 -> 10.0.0.2 distance 254 (which lands you out some fe/ge
port, or whatever)
3.4.72.0/21 -> 10.0.0.2 distance 254 (ditto)

Setup a port with 10.0.0/30 on it, give your collector .2, router .1,
and you're set. This would generally be catching anything arriving 'at'
your network versus anything you're emitting given most worm scanning
behaviors.

2) The first /24 of the nearest /16 supernetwork of whatever prefix you
happen to be announcing via EGP to upstreams. 

It seems that naive/uninformed worms/virii/etc assume the world routes
on /16's. Many that exist tend to start scanning on /16 boundaries
around the subnet they 'see' themselves on. So, if a machine within
3.4.64.0/20 got infected, it'd try to infect/scan up it's nearest /16
first. We don't want to blackhole, screw with filters, etc. too much, so
lets take the first /24 of the /16 supernet of our .20 and point that at
our collector too:

3.4.0.0/24 -> 10.0.0.2 distance 254

The point of this is to catch your networks hosts scanning activity
early on (assuming this naive behavior will be used by miscreants in
future worms). There's really no better way I'm aware of to both reduce
false positives than watching 'specific' dark space. This will likely
hold true until worm behavior changes or they start doing 'sh ip bgp'
queries through some coordinated IRC <-> route-views proxy. 

Lastly, I'd recommend you google a bit for papers and research projects
concerning the 'economics of infection.' You're bound uncover some
useful data which would assist you in your planning of how to monitor
and detect this sort of nefarious activity. Knowing more about the
actions of the worms that miscreants are writing and using can't hurt
your effort!

-Tk