Inside ntop: An Open Source Network Monitoring Tool

Transcription

1 Inside ntop: An Open Source Network Monitoring Tool Luca Deri 1

2 Agenda 1. Project history 2. What can ntop do for me? 3. ntop and network security 4. Integration with commercial protocols 5. Embedding ntop 6. Work in progress 2

3 1. Project History 3

4 Project History [1/3] Fall 1997: L.Deri started coding a pcap/curses based application for analyzing traffic in the core network segment of unipi. Spring 1998: First public release (0.4) of ntop (network top). S.Suin joined the project. Winter : added web interface, ports to Solaris/AIX. Released v

5 Project History [2/3] : registered, mailing lists created. FreeBSD 4.x port, integration into Suse 7.x R.Carbone joined the project and split ntop into ntop+intop (now ntcsh/hsh) B.Strauss joined the project: added XML support, customer care Added support for commercial monitoring protocols and non-ethernet media 5

6 2003: Project History [3/3] More than 600 mailing list subscribers Part of the mainstream distributions It runs on Unix (Linux, BSD, MacOS X) and Win Commercial ntop support Stable release is 2.2. Release 2.3 on the pipe (expected summer/fall 2003) 6

7 Who s Behind ntop? Luca Deri <deri@>: core developer Rocco Carbone <rocco@>: hsh developer Stefano Suin <stefano@>: the thinking man Burton Strauss <burton@ntopsupport.com>: developer, users support Yuri Francalacci <yuri@>: (stress) tester 7

8 2. What can ntop do for me? 8

9 Some Project Goals ntop has been created to solve a real monitoring problem (no planning, case studies, market analysis). By the time it has been extended to satisfy user s requirements. Portable and platform neutral: deploy it where you want. Minimal requirements to leverage its use 9

10 Network Management: Some Goals (No) Connectivity. Performance. Availability (Failure Detection). Responsiveness to Change and Growth. Inventory. Security. 10

11 What are the ntop Requirements? Traffic measurement. Traffic characterisation and monitoring. Detection of network security violations. Network optimisation and planning. 11

12 What are the ntop Goals? Fit end-user needs (no programming required). Easy to use and customize. Standard Interface (Web, SNMP). Open and Portable. Good performance and minimal resource requirements. 12

13 What s available on the Internet? Tcpdump, NeTraMet and RMON should be used by experts and are really not suitable for security problems. Management Platforms (HP-OV, Sun NetManager, Tivoli, CA) are difficult to deploy, not truly portable, expensive. 13

14 What s ntop? ntop is a simple, open source (GPL), portable traffic measurement and monitoring tool, which supports various management activities, including network optimization and planning, and detection of network security violations. 14

15 Welcome to ntop 15

16 ntop Architecture HTTP/HTTPS RRD Cisco NetFlow InMon sflow 16

17 ntop Internals: Packet Capture [1/3] ntop sniffer kernel TCP,UDP Pkt filter Pkt filter BPF driver Packet Copy IP,ICMP Ethernet Device driver 17

18 ntop Internals: Data Structures [2/3] Host Hash Sessions Hash 18

19 ntop Internals: Threads [3/3] 1. Packet capture and queue (pcap_dispatch) 2. Packet dequeue and processing 3. Address resolution (numeric to symbolic) 4. Idle host/session scanner 5. Local traffic loop (via lsof calls) 19

20 Side Note: How to Mirror Traffic Hardware: Hub (Copper Ethernet, Token Ring) Optical Splitter (Optical Fibers) Software: Switch Port Mirror (1:1, 1:N) Switch VLAN Mirror (N:1) Switch Traffic Filter/Mirroring (Juniper) 20

21 ntop for WAP: Architecture 21

22 ntop for WAP 22

23 Traffic Measurement Data sent/received: Volume and packets, classified according to network/ip protocol. Multicast Traffic. TCP Session History. Bandwidth Measurement and Analysis. 23

24 Traffic Characterisation and Monitoring Network Flows Protocol utilisation (# req, peaks/storms, positive/negative repl.) and distribution. Network Traffic Matrix. ARP, ICMP Monitoring. 24

25 Network Optimisation and Planning Passive network mapping: identification of Routers and Internet Servers (DNS, Proxy). Traffic Distribution (Local vs. Remote). Service Mapping: service usage (DNS, Routing). 25

26 Network Inventory [1/2] Identification of routers and internet servers (DNS, NFS, Proxy). Resource (Hw Manufacturer), services and OS inventory. 26

27 Network Inventory [2/2] The fingerprint database has the following structure: WWWW:MSS:TTL:WS:S:N:D:T:F:LEN:OS WWWW: 4 digit hex field indicating the TCP Window Size MSS : 4 digit hex field indicating the TCP Option Maximum Segment Size if omitted in the packet or unknown it is "_MSS" TTL : 2 digit hex field indicating the IP Time To Live WS : 2 digit hex field indicating the TCP Option Window Scale if omitted in the packet or unknown it is "WS" S : 1 digit field indicating if the TCP Option SACK permitted is true N : 1 digit field indicating if the TCP Options contain a NOP D : 1 digit field indicating if the IP Don't Fragment flag is set T F : 1 digit field indicating if the TCP Timestamp is present : 1 digit ascii field indicating the flag of the packet S = SYN A = SYN + ACK LEN : 2 digit hex field indicating the length of the packet if irrilevant or unknown it is "LT" OS : an ascii string representing the OS Courtesy of 27

28 3. ntop and Network Security 28

29 Goal of This Work In every network there are some global variables that can be profitably used for detecting network anomalies, regardless of the type of network users and equipment. As most of the relations among these variables are fixed, it is possible to define generic network rules for automatically detecting selected network anomalies. 29

30 How N-IDS Systems Work [1/2] Signature detection systems use patterns of well-known attacks or weak spots of the system to match and identify known intrusions. Advantage: known attacks are detected efficiently. Disadvantage: lack of the ability to detect new attacks 30

31 How N-IDS Systems Work [2/2] Anomaly detection systems flag observed activities that deviate significantly from the established normal usage profiles as anomalies: something that is abnormal is probably suspicious. Advantage: it does not require prior knowledge of the intrusion so it can detect new intrusions. Disadvantage: no clear definition of an attacks hence it can have high false positive rate. 31

32 Defining a new Type of Anomaly Detection System [1/3] Various experiments performed on different networks confirmed the presence of some similarities on traffic. 32

33 Defining a new Type of Anomaly Detection System [2/3] Simple bytes/packets curves are not very reliable for detecting networks problems, as they can present some peaks caused by various reasons (e.g. a multicast transmission). 33

34 Defining a new Type of Anomaly Detection System [3/3] The authors (Luca and Stefano) decided to investigate whether it was possible to: Identify some selected traffic parameters that can be profitably used to model network traffic behaviour. Define traffic rules so that when such rules are violated there is necessarily a network anomaly (e.g. an abnormal network activity). 34

35 What is an Anomaly? The deviation from the network's expected behaviour that is defined by considering two kinds of knowledge: IP protocol specifications contained in RFCs, that needs to be satisfied by every host and network (static knowledge). Statistical traffic analysis that varies according to network characteristics and type of users (dynamic knowledge). 35

36 Building Static Knowledge Classification of effects on the network of known network security violations. IP protocol dissection (RFCs). Network traffic monitoring parameters used by monitoring applications (e.g. RMON) Experience: survery of parameters checked by network administrators 36

37 Building Dynamic Knowledge Produce a traffic model for each monitored asset that includes: List of provided network services. Thresholds for some specific traffic (e.g. SYN pkt ratio, # concurrent outgoing connections). A security index that idenfies how safe is an host. 37

38 Some Common Traffic Parameters ICMP ECHO request/response ratio ICMP Destination/Port Unreachable # SYN Pkts vs. # Active TCP Connections Suspicious packets (e.g. out of sequence) Fragments percentage Traffic from/to diagnostic ports (e.g. ident) TCP connections with no data exchanged 38

39 ntop Requirements: Security Ability to automatically (i.e. no configuration) detect common network problems. Track ongoing attacks and identify potential security holes. 39

40 ntop: Some Security Features TCP/IP Stack Verification. Application Misuse. Intrusion Detection. 40

41 TCP/IP Stack Verification Network mapping: improper TCP three way handshaking (e.g. queso/nmap OS Detection). Portscan: stealth scanning, unexpected packets (e.g. SYN/FIN). DOS: synflood, invalid packets (ping of death, WinNuke), smurfing. IDS/Firewall elusion: overlapping fragments, unexpected SYN/ACK (sequence guessing). Intruders: peak of RST packets. 41

42 Application Misuse Unauthorized Application Usage (e.g. P2P, ICQ). Misconfigured Applications (e.g. peak of DNS, NTP requests towards non existing servers). 42

43 Intrusion Detection Trojan Horses (e.g. traffic at know ports BO2K). Spoofing: Local (more MAC addresses match the same IP address) and Remote (TTL ). Network discovery (via ICMP, ARP). # host contacts in the last 5 minutes (warning: in this respect P2P apps behave as viruses/ trojans!) 43

44 Validation Playground [1/2] Extension to ntop for accounting selected traffic parameters and calculating security thresholds. Test on the Unipi backbone ATM Backbone Internet Link Juniper ntop 44

45 Validation Playground [2/2] 45

46 Evaluation [1/3] Anomaly detection based on expected behaviour and the study of RFCs, guarantees a better longevity with respect to detection mechanisms based on pattern matching and signature detection. The ADS is effective in many situations where a firewall or an intrusion detection system fail (e.g. a cracker gain host access by means of a buffer overflow). Attacks, when classified in terms of anomaly categories, are very few with respect to the large number of signatures and patterns that similar solutions need to handle. 46

47 Evaluation [2/3] # of knowledge rules you use: ~50 rules per host ~20 global rules (applied to the whole net) Rate of false positives < 10% on known hosts unknown hosts : investigation needed (informational) What is normal behaviour? Thresholds for servers/workstations/p2p s 47

48 Evaluation [3/3] The study of the results produced by the ADS can be very well used for: Network bandwidth optimisation. Detection of network bandwidth killers. Avoidance of unwanted protocols. Network misconfiguration. Unwanted server activity detection. TCP/IP stack tuning based on the distribution of TCP connection number, flags (e.g. RST, SYN), and latency. 48

49 4. Integration with Commercial Network Monitoring Protocols 49

50 Cisco NetFlow [1/2] Open standard for network traffic measurement defined by Cisco Systems Together with RMON (Remote MONitoring) is the industrial protocol for traffic measurement. Probes (usually on routers) send traffic flows (coded in NetFlow format) to collectors over UDP. 50

51 Cisco NetFlow [2/2] Collectors perform various aggregations: AS, ports, protocols, src/dst-prefix. Collectors aggregate data and produce reports (accounting, billing, etc.) 51

52 InMon sflow Similar to NetFlow: probes send traffic flows to collectors over UDP in sflow format (RFC 3176). A sflow probe is basically a sniffer that captures packets at X rate (1:400 is default) and sends them coded in sflow format. The more flows are captured, the more precise are the statistics. Tuning sample rate allows probes to capture at Gb speeds and above. 52

53 Why shall ntop support commercial network monitoring protocols? It is not always possible to capture traffic in the place we want (e.g. border gateway) Traffic reports used in industry are often trusted only if they are based on commercial products/protocols/probes Solution: let ntop be a NetFlow/sFlow probe and collector to ease its acceptance in the industry. 53

54 ntop: NetFlow and sflow Currently ntop is able to collect/emit both NetFlow and sflow flows. Due to ntop s original design, ntop is mostly a collector rather than a probe. Flows are very simple whereas ntop provides very complex statistics. Drawback: at highspeeds ntop looses packets due to all the calculations it has to perform. Solution: let an external probe feed ntop. 54

55 NetFlow Traffic Monitoring Cisco NetFlow is a commercial standard for network monitoring and accounting Many companies (e.g. Cisco, Juniper, Extreme) ship appliances with embedded NetFlow probes. Most commercial probes perform very poorly (~ pkt/sec) 55

56 NetFlow: State of the Art [1/2] Several collectors available (both commercial and Open Source). Very little offering in the probe side. NetFlow monitoring cannot cope with Gbit speeds and above hence new mechanisms (e.g. sampled NetFlow) have been used to overcome this problem. sflow, if more popular, could become a good alternative for high speeds and backbone monitoring. 56

57 NetFlow: State of the Art [2/2] NetFlow is supported only on high-end routers (no support or inability to use it on mid/low-end routers. Most people still rely on SNMP MIB II interface counters (no fine grained measurement at all). RMON is relatively used and difficult to both instrument and use. 57

58 Solution: nprobe+ntop [1/2] The community needed an open source probe able to bring NetFlow both into small and large networks. Ability to run at wire speed (at least until 1 Gb) with no need to sample traffic. Complete open source solution for both flow generation (nprobe) and collection (ntop) 58

59 Solution: nprobe+ntop [2/2] Internet Border Gateway Traffic Mirror nprobe NetFlow Local Network ntop 59

60 nprobe: Main Features Ability to keep up with Gbit speeds on Ethernet networks handling thousand of packets per second without packet sampling on commodity hardware. Support for major OS including Unix, Windows and MacOS X. Resource (both CPU and memory) savvy, efficient, designed for environments with limited resources. Source code available under GNU GPL. 60

61 nprobe: Internals One thread captures packets, classifies, and stores them into a hash table A second thread periodically walks the table and emits expired flows. Static hash (dynamic hashes may loose packets during resize) No dynamic memory: everything is allocated at startup (no need to call malloc/free hence better performance). 61

62 nprobe: BGP Support NetFlow packets include information about ASs (Autonomous System) origin/peer. nprobe has no access to the BGP table (it is not running on a router). AS information is read from file. AS file can be produced reading the BGP table (e.g. via SNMP) from the local router or downloading it from public sites on the Internet. 62

63 nprobe: Performance [1/2] Tests performed using a traffic generator (Agilent RouterTester 900). nprobe run on a Dual Athlon, Intel Pro 1000 Gbit Ethernet card, GNU/Linux Debian 3.0, standard setup, no kernel tuning, Intel drivers (publicly available) 63

64 nprobe: Performance [2/2] Packet Size Network Load nprobe Performance Mbit packet/sec (random) Mbit packet /sec 64

65 5. Embedding ntop 65

66 Why embedding ntop? In some cases it is easier to ship a simple appliance ready to use rather than provide a software application to install, configure, run. Modern embedded systems are based on OSs such as Linux, making easy the transition to them (no need to use proprietary/costly/ limited OSs such) Several manufacturers are selling cheap boxes suitable for this task. 66

67 What to embed? ntop is a collector that needs disk space to save statistics (e.g. RRD) and memory for tracking hosts. nprobe makes more sense: easier to embed (weak requirements) distributed traffic capture vs. centralized collection less sw requirements -> less hw requirements -> cheap appliance -> small appliance 67

68 Based on Cyclades TS/100 Appliance It runs nprobe 1.x nbox [1/2] Suitable for networks up to 10 Mbit of speed (e.g. xdsl, Frame Relay) 68

69 Easy configuration via the embedded web interface. Based on Linux/PPC nbox [2/2] Ability to export flows in NetFlow V5 Ability to drive an LCD display 69

70 6. Work in Progress 70

71 nbox 3 Embedded appliance based on a Lex box with 3 Ethernet (1 GE+2x10/100 or 3x10/100) Ability to work in pass-through mode (bridge) Availability: late summer

72 Beyond NetFlow: nflow nflow ( Proposed to IETF as flow protocol for IPFIX Based on NetFlow V9 Security (non repudiation) Flow compression (gzip) MPLS/VLAN/IPv6 information Payload information Application/network performance. 72

73 Kernel-based nprobe Kernel traffic collector for improving performance (1 Gbit at full speed with 64 bytes packets and commodity hardware) Status: it currently runs on Linux 2.4. Plans: port to FreeBSD based on NetGraph. Availability: summer

74 ntop Availability Home Page: Platforms: Win32 and Unix. License: Gnu Public License (GPL). Distributions: Linux (Debian, Suse, RedHat, Caldera, Slackware), BSD (MacOS X, OpenBSD, FreeBSD). 74