On Jul 9, 14:21, Curtis Villamizar <curtis@ans.net> wrote:
The NSS routers allow us to do statistical sampling continuously and the occurance of a source address at an entry point where it does not usually enter can be detected and has in the past been used to followup these sort of attacks after the fact. Other routers are not capable of doing this but if the offense is repeated, successive monitoring can be set up until the source is isolated.
We have requested the same sort of statistical sampling from Cisco and Bay (and BNR/NSC). It is a long ways back on the development schedule
Maybe I'm missing something, but flow switching stats from Ciscos should do exactly this:
SrcIf SrcIPaddress DstIf DstIPaddress Pr DstP SrcP Pkts B/Pk Active Se1/0 194.130.16.17 Se1/6 130.144.65.1 11 0035 0035 2 69 0.0 Et0/2 193.122.198.1 Se1/1 128.218.14.87 06 0050 0FA3 2 40 0.0 Se1/5 130.144.65.1 Se1/0 194.130.16.17 11 0035 0035 2 69 0.0 Se1/1 153.36.40.52 Et0/1 193.74.242.1 06 0413 0050 4 44 9.6 Se1/5 194.178.24.22 Se1/7 146.228.10.11 06 0407 0050 124 40 207.6 Se1/7 146.228.10.11 Se1/6 194.178.24.22 06 0050 0405 648 550 673.4 Se1/5 194.165.95.69 Se1/0 205.216.146.69 06 0430 0050 5 164 6.2
etc, etc. Dump, then grep.
The sampling Curtis mentioned on the NSS routers is a bit different. For one, it doesn't really impact forwarding performance (and hopefully, if/when implemented on the Bay, will not impact forwarding performance). Secondly, there's a lot more information available if you need it (packet headers or even payload). But what we're specifically looking for in terms of continuous sampling (such as that we do on the NSS routers) is a net matrix... if you changed the Cisco flow switching stuff to use network numbers (and mask), you'd have something very much like what we're looking for in terms of continuous sampling. From there we build AS matrices, etc. The other thing about the flow-switching data that's different than the NSS (and probably what we'll get from Bay) is that there aren't really any nice ways of retrieving/storing the data automatically. As Curtis pointed out, the data is mostly used for capacity planning and other network architecture issues. I have not receieved a request to track down a cracker with this type of data in a very long time. Maybe I've just been lucky. :-) Daniel ~~~~~~
On Jul 9, 17:57, "Daniel W. McRobb" <dwm@ans.net> wrote:
The sampling Curtis mentioned on the NSS routers is a bit different. For one, it doesn't really impact forwarding performance (and hopefully, if/when implemented on the Bay, will not impact forwarding performance).
Not to pick nits, but what I quoted was a cache snapshot; caches don't impact performance under normal circumstances, though their construction may do so.
But what we're specifically looking for in terms of continuous sampling (such as that we do on the NSS routers) is a net matrix... if you changed the Cisco flow switching stuff to use network numbers (and mask), you'd have something very much like what we're looking for in terms of continuous sampling. From there we build AS matrices, etc.
Yes ... but you shouldn't need anything special for that. We have been doing the same for a long time, using regular IP accounting on the edge routers, which is then summarised over a full routing table. The only discrepancies that occur are if changes in routing occur between the time of accounting and processing, but this tends not to be a problem.
The other thing about the flow-switching data that's different than the NSS (and probably what we'll get from Bay) is that there aren't really any nice ways of retrieving/storing the data automatically.
This used to be true, but "probably" isn't true any longer. -- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 6233803, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net e-mail: bilse@EU.net
In message <199607092355.AA00621@jotun.EU.net>, Per Gregers Bilse writes:
Yes ... but you shouldn't need anything special for that. We have been doing the same for a long time, using regular IP accounting on the edge routers, which is then summarised over a full routing table. The only discrepancies that occur are if changes in routing occur between the time of accounting and processing, but this tends not to be a problem.
What if the edge router is sitting at MaeEast or some other very busy edge of your network. Knowing traffic patterns to/from the interconnects is very useful for traffic engineering and neccesary if the "attack" you want to trace back goes through an interconnect. I may be wrong, but I was under the impression that flow switching wasn't up for this and regular IP accounting is completely useless in this particular case. Curtis
participants (3)
-
Curtis Villamizar -
Daniel W. McRobb -
Per Gregers Bilse