Statistical Opportunities in Network Security David J. Marchette - - PowerPoint PPT Presentation

< > - +

Statistical Opportunities in Network Security

David J. Marchette

marchettedj@nswc.navy.mil

Naval Surface Warfare Center Code B10

Interface 2003 – p.1/36

< > - +

Outline

Intro to Network Data Monitoring Denial of Service Attacks Passive Fingerprinting User Profiling I am just going to give a very brief introduction to these topics.

Interface 2003 – p.2/36

< > - +

Network Data

Data is in the form of packets collected off a network (with tcpdump). Each session (web page, telnet, etc.) consists of (many) packets. Each packet contains: Header information used for transmission and control. Data. We will be concerned with only the header information.

Interface 2003 – p.3/36

< > - +

Network Loads

An example of the kind of volume we are looking at: A network of around 10,000 computers connected to the Internet. On January 31, 2002, during the hour from noon to 1pm there were: 7,614,419 IP packets. 150,000 sessions. Network data are large and complex.

Interface 2003 – p.4/36

< > - +

What’s in a Header?

Source and Destination IP addresses. Protocol of the packet. Information on the application (port numbers). Transmission control flags. Error states and information (ICMP). Fragmentation information. Various values for routing and control.

Interface 2003 – p.5/36

< > - +

A Few Areas for Statistics

Estimating the number of attacks on the Internet. Determining the operating system of the machine that sent a packet. Profiling users and detecting masqueraders.

Interface 2003 – p.6/36

< > - +

Denial of Service Attacks on the Internet

Denial of Service attacks seek to deny access to servers (web servers, etc). Many of these attacks operate by flooding the victim computer with a large number of packets or connection requests. Traditionally, in order to determine the number of attacks during any period, we needed to rely on self-reporting. This is particularly bad in computer security, where there is an incentive to under-report.

Interface 2003 – p.7/36

< > - +

Another Approach

A class of denial of service attacks allow detection via passive monitoring. These attacks result in the victim sending out packets (responses) to random hosts on the Internet. By monitoring these unsolicited packets, we can estimate the number of attacks.

Interface 2003 – p.8/36

< > - +

Backscatter Cartoon

Victim Attacker(s) The Internet Typical Denial of Service Attack: Syn Flood. Attacker floods the victim with connection requests.

Interface 2003 – p.9/36

< > - +

Backscatter Cartoon

Victim Attacker(s) The Internet Attackers send spoofed SYN packets

Interface 2003 – p.9/36

< > - +

Backscatter Cartoon

Victim Attacker(s) The Internet Victim responds with SYN/ACK packets

Interface 2003 – p.9/36

< > - +

Backscatter Cartoon

Victim Attacker(s) The Internet Sensors at the spoofed addresses see the response packets us

Interface 2003 – p.9/36

< > - +

Some Observations

We observe a subset of the response packets. Estimation requires that we understand the model. Perusal of attack software indicates that random (uniform) selection of (spoofed) IP addresses is common. Unsolicited response packets may also be an attack against the monitored network. We’d also like to estimate the effect of the attack. The attacks evolve, and this approach may need modification or be invalid in the future.

Interface 2003 – p.10/36

< > - +

Assumptions

We assume (and perusal of some attack code bears this out) that the spoofed IP addresses are selected at random (independently, identically distributed, uniformly from all possible addresses). Given this, we can estimate the size of the attack, the number of attacks we are likely to miss, etc. Are these assumptions valid? We will look at a few examples using the “looks random” test.

Interface 2003 – p.11/36

< > - +

A Victim

Interface 2003 – p.12/36

< > - +

Another Victim

Interface 2003 – p.13/36

< > - +

Another Victim

0.00 0.05 0.10 0.15 10000 20000 30000 40000 50000 60000 Time (hours) Spoofed IP

Interface 2003 – p.14/36

< > - +

Modeling and Classification

We need good models of the spoofing process(es). These can help classify the attacks (identify the attack code). Given these models, we can estimate the size of the attack. These models are also necessary to estimate the number of attacks that are not observed at the sensor(s).

Interface 2003 – p.15/36

< > - +

Number of Attacks Observed

5 10 15 10 20 30 40 Sept 1 −− 17 Days number of attacks 20 25 30 35 40 45 10 20 30 40 Sept 19 −− Oct 15 Days number of attacks

Interface 2003 – p.16/36

< > - +

Number of Attacks Observed

10 20 30 40 50 60 10 20 30 40 Oct 28 −− Dec 12 Days number of attacks 5 10 15 20 25 30 10 20 30 40 Jan 1 −− 31 Days number of attacks

Interface 2003 – p.17/36

< > - +

Comments

Something happened to change the volume of attacks in mid September. These are only “big” attacks (those where the sensor sees more than 10 packets). These are only attacks against web servers. At the peak, there were more than 30 victims, over a period of a month. By January, things were back to “normal”.

Interface 2003 – p.18/36

< > - +

Passive Fingerprinting

The protocols specify what a host must do in response to a packet

• r when constructing a packet.

These specifications are not complete: there are several choices that a computer is free to make. These choices are made differently (to some extent) by different

• perating systems.

By monitoring these, one can guess the operating system. The idea is to examine packets coming to the monitored network, and determining the operating system of the sending machine.

Interface 2003 – p.19/36

< > - +

Time To Live

One such choice is the time to live (TTL) value. This is a byte (value 0–255) set when the packet is constructed. Each router decrements the TTL. If the TTL is 0, the router drops it, and sends an error message. Different operating systems choose different default values for TTL. We never observe the original TTL: we observe the TTL minus a random number (corresponding to the number of routers in the route it took).

Interface 2003 – p.20/36

< > - +

Why Do We Care?

It’s fun. Passive validation of the accreditation database. A machine that appears to change it’s operating system may be evidence of an attack (specially crafted packets). The operating system of an attacker can indicate the likely attack software. In very rare scenarios this could be used to craft a response.

Interface 2003 – p.21/36

< > - +

The Experiment

Data collected on 3806 machines over a period of about 6 months. Features such as: mean TTL, mean type-of-service, window size, IP ID and sequence number increment, min/max source port, number of IP options, which options, whether DF flag set. Data split into a training and a test set evenly (split so that each OS had the same number in training and test). Operating system classed as: Generic DOS, Irix, Generic Apple, Mac, Solaris, Windows. OS designation comes from an accreditation database (unknown amount of inaccuracy). Ran k-nearest neighbor classifiers on training data, best was k = 3.

Interface 2003 – p.22/36

< > - +

Some Data

x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 0.0 0.2 0.4 0.6 0.8 1.0

Interface 2003 – p.23/36

< > - +

Some Results 3-NN classifier

dos irix linux apple mac solaris windows dos 2 32 irix 16 1 linux 25 apple 3 3 mac 31 solaris 27 windows 1 6 3 1753 Bottom line error: 0.027. Worst case error: 0.074.

Interface 2003 – p.24/36

< > - +

Reduced Classes 3-NN

dos → windows apple → mac. windows irix linux mac solarisw windows 1786 6 5 irix 1 16 linux 25 mac 3 34 solaris 27 Bottom line error: 0.008. Worst case error: 0.056.

Interface 2003 – p.25/36

< > - +

Summary

Very simple classifier works quite well. Windows dominates. Better data collection is necessary. The sub-classes are available (Windows NT vs 98 vs 2000...). Active fingerprinting can determine these quite well. Passive fingerprinting is undetectable and adds nothing to the load on the network.

Interface 2003 – p.26/36

< > - +

Network User Profiling

Tracking users by their network activity can provide an indication

• f suspicious or dangerous behavior.

Network activity involves: Applications used (web, ftp, telnet, ssh, etc.). Servers accessed. Amount of data transfered. Temporal information. I do not consider (but could) web pages visited, etc.

Interface 2003 – p.27/36

< > - +

Web Servers Visited

I construct an intersection graph according to the web servers visited by each user. The vertices of the graph are the users. There is an edge between two users if they visit the same web server (during the period under consideration). This is computed over the full time period over which the data were collected (3 months).

Interface 2003 – p.28/36

< > - +

Web Server Intersection Graph

Web

PC JG2 JM BC GM JR NB JR3 PM2 PM3 JR5 JR6 RB MA2 JR7 K26 JGBB KW TC JZ CH KC DJ DT DM JG3 AB PC2 JM2 JR2 MF DV PM TH JS EP NT MA JR4 LG RG

Interface 2003 – p.29/36

< > - +

Is This Unusual?

Do users tend to select the same web servers as other users? First answer: yes. If we consider selecting web pages from the entire Web, what is the chance of observing the amount of overlap we see. Very small. What if we fix the universe as those web servers we observe? Then how likely is it that we’d see this amount of overlap? This is a kind of (dependent) multivariate hypergeometric distribution.

Interface 2003 – p.30/36

< > - +

Assessing Significance

To assess significance of having 26 users where each pair has a web server in common (a clique of size 26): For each user, draw at random nu from N objects, where nu is the number of servers visited by user u, and N is the total number of servers. Determine the clique number for the resulting intersection graph. Count the number that are at least 26. There were 62/100 in the simulation greater than or equal to 26 (49/100 were exactly 26, with a minimum clique number of 24 and a maximum of 27). At this level of granularity (and under this model), we can’t say that users aren’t selecting web servers at random.

Interface 2003 – p.31/36

< > - +

Secure Web Server Intersection Graph

Web

JG PC TC CH JG2 KC DJ DT DM JM BC JG3 GM PC2 JM2 JR MF TH NB EP JR3 JR4 PM2 PM3 RG JR5 JR6 RB MA2 JR7 K11 BB KW JZ AB JR2 DV PM JS NT MA LG

Interface 2003 – p.32/36

< > - +

Is This Unusual?

Same experiment. There were 0/100 in the simulation with clique number greater or equal to 11. The maximum was 9, minimum was 6. This supports that hypothesis that there is some dependence in the selection of secure web servers (users in an organization tend to visit the same ones), while this might not be true for normal web activity.

Interface 2003 – p.33/36

< > - +

Weekly Clique Numbers

2 4 6 8 10 2 4 6 8 10 12 14 Week Clique Number

Interface 2003 – p.34/36

< > - +

What Next?

Look at the temporal aspects of the data. Pattern of application usage. Pattern of servers visited. Dynamic intersection graphs defined on short time periods. Is the volume of the data transfers best predicted by the server visited, or the user?

Interface 2003 – p.35/36

< > - +

Summary

I have tried to illustrate some areas for statistical analysis that are a little different from the standard things one might think of. Network data is quite complex, and is full of very interesting problems. There is a whole range of interesting areas I have not discussed: Network tomography. Arrival time modeling, router queuing, etc. Detecting attacks against the network or hosts. Modeling attack propagation. Attack code authorship. Host based security. There are no end of interesting problems. The problems are all non-stationary.

Interface 2003 – p.36/36