Basic Outline to Paper



What About Scan Data?

Analyzing scan data as part of a defense in depth solution to the high bandwidth intrusion detection problem

[pic]

i. Abstract

-- Guarding a large, bandwidth environment from attackers is very difficult

-- Analyzing scan data to help determine what alarms are worth looking at reduces the workload for the analyst

-- These ideas have been modeled at a university setting and initial indications are positive

I. Introduction

A. Difficulty of operating a NIDS in a large scale environment

1. Amount of data vs. small # of qualified people

(a) large number of hosts on a class A or class B network space

or even in a CIDR block

(b) amount of data that can pass through an OC3 or several T3’s

in a day. (analogy to relate amount of data passing to something

comprehensible)

(c) Types of organizations that have large pipes, what they could

loose if their networks aren’t protected

(d) qualified security people in general, even smaller number of

network intrusion detection people. (analogy of small # of

policemen in a city the size of Baltimore and the number of

crimes that are committed)

2. Ancillary data like P2P traffic, chat traffic, etc. (difficult key words)

(a) network bandwidth is eaten up by non- mission related traffic

even more grey for the ISP’s where really everything is mission

related

(b) difficult to sort the traffic in a high speed manner, esp when

you have to re-assemble the TCP sessions before you can

figure out what’s inside them

(c) people are always trying to get around local security policy

by changing the default ports for their applications

3. In general poor tools designed for small networks

(a) IDS’s are really the only way to analyze the incoming

traffic at the packet level

(b) merely examining the header information (5 tuple/CISCO

NETFLOW) is not enough to determine malicious intent

(c) firewalls that auto-respond to block traffic aren’t sufficient

Firwalls that maintain state can barely keep up with the kind

of bandwidth that a large installation may control

(d) most of the IDS solutions deployed today are designed for

small networks. Rated to process data at the T1-T3 rate

(list bandwidth capabilities of snort, dragon, netranger,

real-secure, & )

(e) tying a bunch together causes correlation problems

B. Break problem down with a defense in depth strategy.

1. Router ACLs -> Firewalls -> NIDS -> Host based stuff

(a) Defense in depth is the only way to handle the high-bandwidth

problem. Don’t put all eggs in one basket

(b) Routers can control network flow based on a very granular

filtering mechanism at the port, protocol, or IP level

(c) constant fight between those trying to secure the network

and those trying to provide services to the customers of

the network

(d) compromise is usually the firewall. Basically another filtering

device that often can provide some form of state maintenance

(e) NIDS is usually the next step. A NIDS can do anomaly or

signature based detection. Sigs and anomaly can be tricked

flooded with false alarms, DoS’d, hacked (mention SNORT

bugs) Full time job of an alarm analyst to keep up with the

constant new threats arriving. False positives are the greatest

problem with NIDS. They can generate tons of useless data.

NIDS is good because it looks at all (err.. most) traffic as it’s

on its way to doing something nefarious. A quick analyst could

take action based on a NIDS alert/alarm and possibly prevent

excessive damage from occurring against his/her system

(f) Host based strategies like log analysis, i.e. tripwire etc are old-

fashioned. They only catch things that the stupid hackers forget

to clear out of the logs before they leave. Easier to thwart, or

fool. Similar NIDS in a way is that logs can contain reams of

benign data, making it difficult for the tools and the analyst to

sort through looking for the useful problems

C. Target the NIDS part and try to make it better by focusing on the most

important alerts

1. Best part about NIDS is that it can be completely hidden (passive) to the

intruder It can have the most likely chance at success, in some respects, for catching a bad-guy because he won’t know it’s there until he gets caught

2. NIDS analyst doesn’t have to fight with network dorks

3. Biggest problem with NIDS is false alarms

4. Use Scans to predict what alerts to watch for

5. Scans can be easily discovered for the most part. everything except low-

and slow is easy to pick out and figure out who the perp is and who the

victim is. Also a good IDS should be able to check for responses from

the victim hosts allowing the NIDS analyst to see exactly what the perp

sees as the result of his/her scanning.

D. Explain Hacker methodology – all attacking takes the following form even

DoS

1. Scan – can’t rob a house until you know where it is

2. Initial compromise – need to find an intial access to the house i.e. break

a window

3. Privilege escalation – need to find a way to get into the room where the

the safe is.

4. Nefarious activity – break open the safe and start to carry the stock

certificates away

5. Attack relay – look out the window at other houses on the street or look

through the address book found in the kitchen drawer for other people

to rob. Or impersonate the house owners to trick the neighbors into

letting you into their house

E. Signpost for rest of paper

1. Statement of problem – the problem I’m trying to solve is to reduce the

workload of the NIDS analyst and possibly provide some predictive

element as to what could be attacked, and what it could be a victim

of, and possibly a categorization of the skill of the attacker

2. Abbreviated, innovative solution – Solution is to capture as much

data about scanning as possible to allow a determination to be made

as laid out above

(a) UMBC network used as an example. – SNORT logs were

analyzed and patterns were noticed that alert the analyst

of impending doom.

(b) perl scripts were used to analyze data and were graphed

to give the analyst a picture of what might happen soon

II. Previous related work – brief summary & why their papers fall short

A. Seminal papers

1. On a difficulty of Intrusion Detection – Stefan Axelsson

2. Computer Security Threat Monitoring and Surveillance – James

Anderson

3. Data mining for Network Intrusion Detection – Kumar, Lazarevic,

Srivastava

4. ??Teresa Hunt paper ??

5. ?? Dorothy Denning paper ??

B. Closely related papers

1. Analysis of Low & Slow Network Scans – Keith Scott

2. Analyzing the past… predicting the future – HoneyNet Project

3. Base-rate fallacy – Stefan Axelsson

III. Describe Scanning in depth

i. brief review attack methodology – i.e. just remind the 5 steps

ii. legal status of scanning

A. Brief Network tutorial explaining how TCP/IP lends itself to scanning from a

protocol level

1. All of the TCP/IP protocols are designed to transfer data between nodes

some of them are designed to do this reliably (TCP) some unreliably

(UDP, ICMP)

2. Even though there are standards and RFCs that clearly lay out what all

the actors are supposed to do in every case, individual vendors often

take quite a bit of liberalness with the way the respond to network

events allowing perp’s to do OS detection

(a). TCP – has the built in 3 way handshake. All computers

must respond to it or the reliable connection cannot be

established. This allows a perp, to initiate action that the

victim host must respond to if it is able.

(b). UDP – Even though UDP is a connection-less protocol it can

still be probed for responses because certain services respond

immediately when a packet is sent to them (echo/chargen etc.)

additionally ICMP is designed to report error messages,

attackers to do sort of an inverse scan

(c). ICMP – many of ICMP messages are auto responded to.

Classic example of course is the ping message

B. Types of Scans – explain how scan is perpetrated (i.e. what part of the TCP/IP

protocol is being abused to allow scan to happen), give an example of the type

of information that the attacker is looking for with this scan, explain what can

be done with this type of information, point out how sophisticated the attacker

has to be to use this type of scan

1. Half – Open SYN scan

2. Null Host scan

3. OS fingerprint scan

4. Grim’s ping

5. etc…

C. Common tools used to scan

1. Commonality of all scanning tools – ease of use (availability, gui etc.)

2. Custom built tools, easy to write a quick perl script that can do some

scanning

2. Nessus, Satan, Queso, Nmap, etc.

IV. Making use of NIDS Scanning Alerts / Logs

A. How Alerts are generated in NIDS – 2 main types of NIDS signature vs.

anomaly. If a set of inputs matches a particular rule or doesn’t match a rule

depending on the context, then fire off an alert/alarm

1. Generic NIDS description

(a) Alert level – usually 1-5 allows the NIDS analyst to sort which

alerts he will pay attention to. Usually the lower level alerts get

totally ignored. Scan alerts are usually considered lower level

alerts

(b) False positives – are when an alert fires on a particular input

even though that input is not actually associated with malicious

activity. this is really one of the most annoying parts of

analyzing NIDS alerts. NIDS have lots of false positives

because unlike a human they don’t usually have any context

within which to judge a particular event

(c) False negatives – These are very dangerous to the network

being defended because these are malicious events that

don’t get alarmed on. Most frequently happens when a brand

new attack comes out that there is no signature for yet.

(d) Anomaly vs. Signature –

Anomaly is good for some things /bad for others

like finding large scans or DoS’s but it’s not very good for

finding virus or worm payloads coming across the wire, or

for activity that is malicious in nature, but not out of the

ordinary for a particular protocol or service. i.e. if someone

already knows what a password is for a particular server

then they won’t look out of the ordinary when they log in, not

until you look at exactly what they’re doing (like executing a

buffer overflow on the remote system or changing the logs) will

you realize that something bad is going on.

Signature is good for something /bad for others.

Signature is very good for finding things like virus’s or worms

coming across the wire. Very good for tracking down company

policy violators (like surfing for kiddie-porn). Great for

catching someone in the act of doing something bad before they

do something worse. Signature based systems are real bad when

There’s tons of traffic flying around. They’re also horrible for

new never-before-seen attacks.

2. SNORT specific description – SNORT is described here because that’s

what UMBC uses to protect their network

(a) SNORT has several preprocessors that look through the

incoming traffic and decide what is going on in the packets

to try to determine maliciousness. These preprocessors are

designated to look for things like TCP reassembly and

scanning. These preprocessors are then able to put out alarms

(b) SNORT has the scan preprocessor that creates alerts when

certain thresholds are reached. It then puts all of these alerts

in a particular file so that the analyst can look through them

later. Which he/she rarely does

(c) The rest of the SNORT engine can publish alerts/alarms to

a repository that is checked much more frequently by the

analyst. Especially when he/she is looking out for a particular

thing.

B. Parsing logs and Comparing scan logs to other ‘attack’ logs

1. Possible in Real time? – to be predictive one must be keeping track

of everything going on right now! (or as close to now as possible)

the problem is that, the more processing you do to a packet before

you decide whether it is malicious or not, really slows down your

ability to see it and react to it.

(a) what kind of delay is acceptable – manpower,

dollars, criticality of what you’re protecting

2. Tools for parsing – what you want to do with an IDS like SNORT (or

really any IDS that publishes scan and regular alert alerts ;) is look

through the scan alerts as fast as possible and try to figure out where

they match up to any incoming alerts right now. If you want to predict

what may or may not happen in the future you need to figure out who

the perps are and who the victims are as soon as possible so that you

know what to look out for in the coming days, weeks, or months

(a) Perl is a great language for parsing text cause it’s designed for

that.

(b) C is not as good for quick and text parsing applications, but it

is better for more robust applications.

(c) Mention something about logic languages like XSB??

(d) really the best solution is to tie all these tools together,

emphasizing their strengths and downplaying their weaknesses

C. Statistical analysis of Scanning logs – quick analysis of top 10 scanners and

victims can tell you a lot about who is coming at your network the soonest and

their victims are most likely to be. This is based on the idea that script kiddies

and worms don’t have a lot of patience or subtlety and will be on you quick. A

more thorough statistical analysis is required to pick out the low-and slow

attackers.

1. Software solution to tackle manual problem – obviously to do this sort

of analysis with any speed you need to use software to speed up the

process

2. Difficulty of using visual tools to break down the problem – just using

a viz tool is very difficult in this arena because of the massive number

of transactions/alerts etc. we’re dealing with. No tools can display

millions of records in the time it takes for an analyst to be able to make

an intelligent decision about a bit of traffic.

(a) Need to reduce data set somehow before trying to viz. – parse

the scan logs and look in the alerts for correlating IPs.

(b) Consequences for reducing data set – leaving out IPs makes it

easier to miss something that could be trying to happen under

your radar. This really can’t be helped though. The best way

to avoid this is to pick your priority devices to be protected

and watch those like a hawk.

V. Predictive analysis / attack forecasting – today’s fast passed modern internet is still

every much like a scene out of a western movie. or maybe like a scene out of a WWII

movie. Having the advantage by being able to predict when the bad guy is going to

come around the corner will protect the good guy every time. Unfortunately in the

digital world it’s not quite as easy as watching for the tanks coming over the hill.

None the less as we’ve seen all computer attackers have to follow a generic attack

plan if they want to be successful

A. Predictive techniques

1. Statistical relationships – most prediction techniques in the world today

are accomplished through looking at patterns of previous events in an

attempt to predict the future. The weatherman consults his almanac,

the stock picker consults his performance charts for the last 36 months,

the network defender should look at his scan alerts to see when an

attack could be coming and against what set of services?

2. Problem of maintaining long term state for low & slow – This is

particularly difficult for low & slow attacks. In small networks (like

less then 50 computers it might be possible to keep logs on everything

for an extended period of time. But if you have a huge network then

its nearly impossible to keep all the records you’d need to be able to

figure out who and what is doing the low & slow. Some summarization

or record of particularly weird traffic could help you track this, but it

would still be difficult, because on a large network the amount of

‘weird’ traffic is rather large.

B. Reducing false positives by focusing on alerts that are related to

previously discovered scans – really the core of my thesis is that we should be

able to predict when an attack is coming and the type it is by examining the

amount and type of scanning coming in. As mentioned before IDS analysts are

used to analyzing the highest priority alarms/alerts only. So why don’t we set up

an IDS that could automatically raise the level of any alert that had a previously

associated scan with it. This would produce a reduced set of alerts of a higher

likelihood of attack therefore rewarding the IDS analyst with less data to cover,

and a higher likelihood of catching a bad-guy.

VI. Description of Experiment

A. Stats on UMBC’s network

1. Network topology – # of user base, types of users

2. Equipment used – defense mechanismims

3. Bandwidth utilization? – OC3’s multiple T3’s etc.

B. Data Gathered – had access to a month’s (nov.) worth of SNORT output.

Separated into two files, one for scans and one for alerts. Based on the way

snort outputs such data as described earlier

1. General snort statistics:

(a) Average scan alarms per day for a month

(b) Average alerts per day for a month

(c) Total month’s worth of alarms

(d) Total month’s worth of scans

(e) biggest attacker, biggest victim

2. Analysis was to look at scans and look for either source IPs that

contributed to alerts later in the month or on that day. Also looked

victims that were in alerts later in the month.

(a) show a couple of graphs and charts that show rise in scanning

from a particular source IP and then any other spikes later in the

month showing up in the alert logs

(b) show a graph or chart that shows any of the victims of scans

previously in the month and how they were victimized by other

attackers or the same later in the month

C. Software I developed to solve problem

1. Language chosen (Perl) and why – as stated before perl was a quick and

easy way to build hash tables to analyze the data. It was good for

parsing the logs easily making analysis easier. Debugging was also

quicker in Perl then would have been in C.

D. Results of analysis

1. Success of technique applied to second month’s worth of data – tried

the same techniques on a different month’s worth of data and I got

similar results.

(a) Average scan alarms per day for a month

(b) Average alerts per day for a month

(c) Total month’s worth of alarms

(d) Total month’s worth of scans

(e) biggest attacker, biggest victim

2. Graphs / Charts – that show the spikes of the scanning and the related

attacking.

VII. Conclusion

A. My analysis techniques would have made it easier for an IDS analyst or

network defender to button up his network. I reduced the number of alerts for

the month from the total sent to the amount that might actually have to be

looked at and dealt with. This saved all kinds of time and could result in better

analysis and more saved computers

B. Difficulties encountered – finding a lot of research on my topic that had

already been done to provide background was difficult. There just isn’t much

out there. Writing some of the software took a little while. More time would

have allowed me to integrate more of my solutions into a plug-in for snort.

getting data to do research on and to draw conclusions from was a little

difficult.

C. Open problems – providing a stronger statistical background for prediction

would be good. i’m not good with stats so I didn’t spend a lot of time working

on this. discovering ways to locate low & slow attacks in a large trough of data

would be a great accomplishment. Especially since this would clue the

defender in to the most dangerous types of attacking. Storing the massive

amounts of scan and alert data that are generated by the NIDS is a problem.

Finding a way to continue to eliminate false alarms and only have the alarms

that an analyst is really going to look at would help this.

VIII. Bibliography

Appendix A. Code Attachment

1. Perl Code

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download