Ourmon and Network Monitoring Performance Jim Binkley jrb@cs. pdx. edu Bart Massey bart@cs. pdx. edu Portland State University Computer Science
ourmon introduction q q ourmon is an open-source statistic gathering network monitoring system with some similarities/differences to § traditional SNMP RMON II • name is a take off on this (ourmon is not RMON) § Linux ntop is somewhat similar, Cisco netflow, features different q we deployed it in the PSU DMZ a number of years ago (2001) § first emphasis on network stats • how many packets, how much TCP vs UDP, etc. • what the heck is going on out there? § recent emphasis on detection of network anomalies • post SQL slammer, Welchia worm, botnets 2
ourmon architectural overview q a simple 2 -system distributed architecture § front-end probe computer – gather stats § back-end graphics/report engine q front-end depends on Ethernet switch portmirroring § like Snort q q does NOT use ASN. 1/SNMP summarizes/condenses data for back-end § intermediate data is ASCII q cp summary file via out of band technique § micro_httpd/wget, or scp, or rsync, or whatever 3
the Tao of ourmon q q more information less data summarization in probe OR back-end 2. 5 G packets (more later) means you need to summarize no standards please other than § probe talks to back-end graphics/report makers in a shared language § probe and back-end always released together q we can change our intermediate data for the next release § new tuples of interest at any time 4
ourmon architectural breakdown pkts from NIC/kernel BPF buffer probe box/Free. BSD mon. lite report file tcpworm. txt etc. ourmon. config file runtime: 1. N BPF expressions 2. + topn (hash table) of flows and other things (tuples or lists) 3. some hardwired C filters (scalars of interest) graphics box/BSD or linux outputs: 1. RRDTOOL strip charts 2. histogram graphs 3. various ASCII reports, hourly summaries or report period filters: BPF expressions, lists, some hardwired C filters 5
features q N concurrent BPFs grouped into RRDTOOL graphs (about 80 expressions in DMZ now) § say 3 -6 related BPF expressions per RRD graph q top-N tuples of various sorts: § traditional flows including flow counts, key is flow ID § top ports, key is TCP/UDP port (surprise) § TCP syn tuple: key is IP src • scanners/worms/P 2 P/IRC users, port report, tworm § ICMP/UDP error tuple: key is IP src § new IRC tuples (channels, per host stats) § IP and port scanning 6
BPF filter set: - TCP control pkts question: does your network syn curve match your fin curve? 7
tworm filter - DDOS/botnet-related attack ip src: flags work 24. 205. *. * (20) WOR 100 sa/s 0 dst/s 30/30 dst port/% [30108, 100] 8
UDP error filter - attack on single PSU media server err… attack is so large suppressed all other bars to < 1 pixel 9
test setup for ourmon/bpf measurement ixia 1600 g. E packet generator ixia 1. min-sized pkts. 2 max-sized pkts ixia sends/recvs packets Packet Engines line-speed gigabit ethernet switch port-mirror of IXIA send port UNIX pc 1. 7 ghz AMD 2000 UNIX/Free. BSD 64 -bit PCI/syskonnect + ourmon/packet tap 10
ixia vs ourmon test summary q q q 1. 64 byte min packets bad; max large packets good on ~2 Ghz PIV, with no real work start losing min pkts at 80 mbits. if you have real work (imagine snort with 1000’s of signatures) you may be 10 mbits 2. big packets need bigger kernel buffers, say 8 megabytes, not 4 k bytes 3. actually dual box with NO software work is somewhat better 11
more ourmon information q q ourmon. cat. pdx. edu/ourmon - PSU stats and download page ourmon. cat. pdx. edu/ourmon/info. html - how it works (2 pages, 1 for current release and one for next release) current release is 2. 4 next release will have more anomaly detection features including an automated trigger mechanism for pkt capture during “interesting” events (large attacks, UDP anomalies) 12
Скачать презентацию Ourmon and Network Monitoring Performance Jim Binkley jrb cs
b0dc893ad448ebd99936579b365f4d5d.ppt