# Presentation: 266168

## NetState

**A Network Version Tracking System**
**FREENIX ‘05**
**April 14, 2005**
**Jamie Van Randwyk**
**Sandia National Laboratories**
**Nancy Durgin****	****	****Yuqing Mai**
**Sandia National Laboratories**

- Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company,for the United States Department of Energy’s National Nuclear Security Administration under contract DE-AC04-94AL85000.

**Notes:**
Netstate logo??

## What is NetState?
Architecture
OS version detection
Application version detection (FTP example)
GUI and CLI screenshots
Performance tests
Legal issues
Future plans
Where to find NetState

**Architecture**
**OS version detection**
**Application version detection (FTP example)**
**GUI and CLI screenshots**
**Performance tests**
**Legal issues**
**Future plans**
**Where to find NetState**

**Outline**

## What is NetState?

**Develop a picture of the “State of the Network”**
**Identifies open ports and service versions on networked hosts**
**Identifies operating systems on networked hosts**
**Identifies client version strings (****SSH**** and ****HTTP**** only)**
**Are there any Web servers running on my network on ports other than 80?**
- mysql> select ip_addr_dot, port, description, version from version where description = 'HTTP-S' and port != 80 and ip_addr_dot like '129.%';

## What is NetState?

**Passively monitors the network (Ethernet and FDDI)**
**Detects services running on multi-boot and infrequently powered-on machines**
**Enumerates services running on non-standard port (e.g. ****ssh**** on 2222)**
**Supplements (and possibly eliminates) the need for constant active scanning**
**Stores information in SQL database**
**Accessible from Web GUI & SQL API**
**Component used by other internally-developed security systems**

## NetState Architecture

## OS Version Detection

**Looks at first packet (SYN packet) on a connection**
**Detects OS of originating host only**
**Uses code & fingerprinting techniques from *****p0f***
**Detects attributes of IP stack**
**MTU, Sequence Number, IP Options, etc.**
**Database Entry**
**IP Address**
**Version string (OS type and version)**
**Time first seen**
**Time most recently seen**

## Application Version Detection (1)

**Search for “magic string”**
***‘******GET’, ‘HTTP’, ‘220’, ‘SSH’***
**Looks at first few data packets in a connection**
**Number of packets examined per connection depends on magic string seen **
**Usually no more than ~3 data packets **
**Finds Client and Server versions for ****SSH****, ****HTTP**
**Finds service on any port**
**Doesn’t assume HTTP is only on port 80, etc.**

**Notes:**
Look at first few data packets – We are looking for versions strings that are at the beginning of the data part of a session, but sometimes this isn’t actually in the first packet.  Example: some FTP servers send a banner first, and the version string later.  In this case the version string might be in a lower packet, but we can tell from the “magic string” (a 202 that appears on each line) that there is likely to be a version string there, and it’s worth continuing to look for a few packets before giving up.  The limit of how far we look into the data stream is pretty small (on the order of 3) and varies according to which magic string is detected.

Data packets usually arrive in order, and reconstructing the data stream to re-order them is quite a bit of overhead.  We estimate it is probably 98% correct without this feature, and fixing it would probably effect performance

## Application Version Detection (2)

**Support: ****FTP****, ****SMTP****, ****IMAP****, ****POP3****, ****NNTP****, ****SSH****, ****HTTP****,**** ****chat protocols (Yahoo Messenger, AOL Instant Messenger, ICQ,  MSN Messenger, IRC)**
**Database Entry**
**IP Address**
**Destination Port **
**Service name**
**Version string**
**Time first seen**
**Time most recently seen**

## Example: FTP Version Detection

**FTP version strings are not standardized**
**Always ****‘220’**** server reply code at beginning of first line(s) of session**
**but SMTP sessions also start with ****‘220’**** **
**Rule: Look for a line (newline terminated) as follows:**
**starts with ****‘220’**
**contains string ****‘FTP’**** somewhere later on the line**
**Usually this will be in the first data packet**
**Sometimes it is in a later packet**
**look at up to 3 packets if we see ****‘220’**** at start of line**

## Examples: Version string in first packet

- % ftp ftp.apple.com
- Connected to ftp.apple.com.
**220 ProFTPD 1.2.9 Server (Apple Anonymous FTP Server) [ftp02.apple.com]**
- 500 AUTH not understood
- 500 AUTH not understood
- KERBEROS_V4 rejected as an authentication type
- Name (ftp.apple.com:user):

- % ftp wuarchive.wustl.edu
- Connected to wuarchive.wustl.edu.
**220 (vsFTPd 2.0.1)**
- 530 Please login with USER and PASS.
- 530 Please login with USER and PASS.
- KERBEROS_V4 rejected as an authentication type
- Name (wuarchive.wustl.edu:user):

## Example: Version string in later packet

**Sometimes long banner before the login prompt, so version string isn’t in first packet**

- % ftp ftp.myhost.com
- Connected to ftp.myhost.com.
- 220 *****************************************************************
- 220 *                                                               *
- 220 *                                                               *
- 220 *           WELCOME TO MY FILESERVER!                           *
- 220 *                                                               *
- 220 *           Please login as 'anonymous' to access our files     *
- 220 *                                                               *
- 220 *****************************************************************
**220 (vsFTPd 1.2.2)**
- 530 Please login with USER and PASS.
- 530 Please login with USER and PASS.
- KERBEROS_V4 rejected as an authentication type
- Name (ftp.myhost.com:user):

## Version Detection - Limitations

**Does not handle out-of-order packets**
**“****Mostly” correct without this capability**
**Would cause additional overhead to reconstruct all active session streams**
**Not worth it?**
**Built for LAN use**
**Good chance of future sessions initiating “in order”**
**TCP Versions only**** ****(so far)**
**UDP sessions less well-defined**
**Might have to examine every packet**

## Web GUI

## Web GUI

## Web GUI

## Web GUI

## Web GUI

## SQL CLI

- mysql> select ip_addr_dot, port, description, version from version where description = 'HTTP-S' and port != 80 and ip_addr_dot like '129.%';
- +-----------------+------+-------------+------------------------------------------+
- | ip_addr_dot     | port | description | version                                  |
- +-----------------+------+-------------+------------------------------------------+
- | 129.10.120.112  | 8090 | HTTP-S      | server: Apache/2.0.40 (Red Hat Linux)    |
- | 129.105.44.81   | 8090 | HTTP-S      | server: Apache/1.3.33 (Unix) PHP/4.3.10  |
- | 129.132.57.4    | 8808 | HTTP-S      | Server: Apache/2.1.3                     |
- | 129.170.214.191 | 8090 | HTTP-S      | server: Apache/2.0.53 (Unix) mod_ssl/2.0.53 OpenSSL/0.9.7e PHP/4.3.10 |
- | 129.170.214.192 | 8090 | HTTP-S      | server: Apache/2.0.40 (Red Hat Linux)    |
- | 129.22.150.90   | 8090 | HTTP-S      | server: Apache/2.0.40 (Red Hat Linux)    |
- | 129.22.150.90   | 8090 | HTTP-S      | server: Apache/1.3.33 (Unix) PHP/4.3.10  |
- | 129.240.14.10   | 9003 | HTTP-S      | Server: Apache/1.3.29 (Unix)             |
- | 129.252.124.240 |   85 | HTTP-S      | Server: Microsoft-IIS/4.0                |
- | 129.59.1.28     | 8765 | HTTP-S      | Server: Ultraseek 5.1.1                  |
- +-----------------+------+-------------+------------------------------------------+
- 10 rows in set (0.02 sec)

## Performance Testing Methodology

**Used Tcpreplay* to generate network traffic at varying bandwidths**
**Used data sources from the 1999 DARPA Intrusion Detection Evaluation - week 3** (350MB - 550MB)**
**Each data source used provides different results, but the overlying trends remain reasonably consistent.**
**Used single data files in some tests, used chained data files for larger tests**
**Replay box <==> Sniffer <==> Server - back-to-back crossover connections**
*** ****http://tcpreplay.sourceforge.net/**
**** ****http://www.ll.mit.edu/IST/ideval/data/1999/training/week3/index.html**

## Performance Testing Hardware

**NetState Server**
**AMD XP3200+ 2.2GHz, 1GB RAM, Netgear FA311 NICs**
**Fedora Core 2, 2.6.5-1 kernel**
**NetState Sniffer**
**Intel P4 1.5GHz, 640MB RAM, Netgear FA311 NICs**
**FreeBSD 5.3, GENERIC kernel**
**Replay box**
**VIA C3 800MHz, 512MB RAM, Intel Pro/100 NICs**
**FreeBSD 4.11, GENERIC kernel**

- Note: Not exactly “state of the art” hardware!

## Packet Loss at Varying Bandwidth(Cumulative Data)

## Performance Testing Results

**Packet loss increases as bandwidth increases ****(not surprising!)**
**Packet loss of ~5% at 10Mbps isn’t very good**
**Some packet loss is not a problem when profiling**
**Actual performance on our internal network**
**Uses state-of-the-art hardware**
**Typical packet loss of ~1% in ~5-10Mbps network **
**Performance tests replay data at sustained bandwidths**
**Real networks tend to be more bursty**

**Notes:**
Maybe replace some of this with our conclusions from the graphs

## Performance Testing - Caching

**Sniffer cache delays updates to Server by updating the most recent time locally (for version strings that don’t change) and delaying updates to the server**
**With cache, version info in the database may be slightly stale, but shouldn’t be enough to matter**
**Caching version info in Sniffer helps performance**
**e.g. OS versions are seen on every SYN packet but rarely change**

## Effects of OS Version & Caching (5Mbps)(Single Data File)

## Effects of OS Version & Caching (20Mbps)(Single Data File)

**Effects of OS Version & Caching (20Mbps)****(Single Data File)**

## Legal Issues

**I am not an attorney (and I don’t play one on TV)**
**Can I capture traffic promiscuously and record details about what I see in that traffic?**
**US Code Title 18, Part I, Chapter 119, §2511**
**Legally, corporations, ISPs, and universities can monitor networks for this type of information.**
***Essentially, they are doing so in the name of protecting their networks and are protected by the law as such.***

## Future Work

**Detect more network services**
**Handle packets arriving out of order **
**Regular expression-based signatures**
**Active Nmap probing for SSL-enabled services**
**Scoring system for OS versions**

**Notes:**
Slide needs pizazz

## How to get NetState

**The Department of Energy’s open source licensing process is complicated and lengthy**
**Most likely will be released under the LGPL**
**We’re working on it!!**
**http://netstate.ca.sandia.gov**

**Notes:**
Graphic?

## NetState Team

**Nancy Durgin - PI**
**Jamie Van Randwyk**
**Eric Thomas**
**Tim Toole**
**Center for Cyber Defenders (CCD) student interns: Yuqing Mai, Kami Vaniea, Tristan Weir, Archer Batcheller**
**Very special thanks go to Randy McClelland-Bane for installing NetState in our production environment and running performance tests.**