snort 2.1 intrusion detection second edition phần 1 potx

One of the easiest and certainly the most popular methods for creating a cus­tomized Snort data interface is creating some type of database interface.The cur­rent relational database plu

the myPluginSetup function.This function’s purpose is to initialize any contextual

data (such as file references) necessary for it to function Second, it must then

provide Snort with some additional function pointers: a function for alerts and two shutdown functions.These pointers are provided by a call to

AddFuncToOutputList, AddFuncToCleanExitList, and AddFuncToRestartList

myPluginAlert (AlertW3C)

The myPluginAlert function is the actual function Snort calls when there is a new

alert to process.You should remember that Snort learns of this function by

myPluginInit’s call to AddFuncToOutputList

This function takes several parameters:

■ Packet The actual packet that caused the alert

■ Message Any message generated by the associated rule

■ Data An arbitrary DWORD value specified in the

AddFuncToOutputList function.This is typically a pointer to a structure,

allocated on the heap, containing file handles and other configuration information

■ EventData A structure containing information about the associated Snort rule

myPluginCleanExit (AlertW3CCleanExit)

The myPluginCleanExit function is called by Snort when the application is shut­ ting down Remember that Snort learns of this function by myPluginInit’s call to AddFuncToCleanExitList.This function’s purpose is typically to deallocate any

contextual information allocated by myPluginInit

have just learned.The goals in creating the W3C plug-in were to save alert data

to a log file in a W3C format.The plug-in operates as we have just learned, and

we will now explore how it is implemented Note that implementation and cre­

ation are two different beasts

The first step was to create two source files, spo_w3c.h and spo_w3c.c, and declare the structure of our plug-in with the following functions:

After creating the two source files, we need to modify Snort’s code base so that it knows about our plug-in.This step is critical because Snort was not cre­

ated to dynamically notice or identify new plug-in code just because it resides in

the same directory structure as the other plug-ins So, in Snort’s plugbase.h, we

added the following line at the top of the file:

Again, inside Snort’s plugbase.h file within the InitOutputPlugins function, we

added the following function call:

Those steps were necessary so that Snort could provide the ability to give our function a call when it starts

Snort calls our setup routine, AlertW3CSetup, when it starts So, from this

point, we need to give Snort some additional information about our plug-in

This is done by the following code snippet:

Now Snort knows that our plug-in is named alert_W3C, and it knows how

to activate it Snort decides whether to activate the plug-in by the presence of a

reference to it in the snort.conf file Such a reference should look like the fol­

lowing:

We are now getting close to the end of the process.The plug-in is activated

via the AlertW3CInit function.This function sets up some configuration infor­

mation and informs Snort about some additional entry points into our plug-in:

AlertW3C, AlertW3CCleanExit, and AlertW3CRestart

The configuration information is set up by calling the static routine

InitializeContext, which returns a pointer to a W3C_CONTEXT structure

Inside this structure exists only one member: a FILE handle to the opened log Should we need to add any more configuration information, we’d add it to this

structure and the InitializeContext function.The AlertW3CInit function makes

several calls to the Snort runtime to inform it about its additional entry points:

The real work of the plug-in is done inside the AlertW3C function Basically,

this function takes its several arguments and serializes them into a W3C log

string, which it appends to its log file.This is done in the following steps:

1 Call the static routine InitializeOutputParameters, which takes the same arguments of AlertW3C and serializes it into a data structure

OUTPUT_PARAMETERS

2 Take the OUTPUT_PARAMETERS structure and pass it to the func­ tion AllocLogEntryFromParameters, which transforms the structure into a

character array containing the log message

3 Write that character array to the log file using the fwrite function

Finally, when Snort shuts down, it will give our plug-in a call via the

AlertW3CCleanExit function.The purpose of this function is very simple: release

allocated data structures and system handles, such as our context structure and its

file handle.This is done by its internal call to ReleaseContext.You are now ready

to put the remaining pieces of the puzzle together by analyzing the source of the plug-in in hopes that you can use this guide and example to write your own

plug-in if you so desire

The header file is very straightforward, to the point that it prototypes a single function that takes and returns no information and is directly linked to Snort’s

code base:

// - Header file for spo_w3c.c, which is the output plugin for asserting

// alerts in w3c log format

//

The following code is the body of the plug-in for the new Snort W3C output format style.You will notice all the functions that we have already men­

tioned and detailed in addition to some of the structures that we have reimple­

mented to allow us to get the appropriate data parsed into the program It is

important to remember that this plug-in must be used in conjunction with Snort

and must be compiled with Snort.The location of the output file is in the con­

figuration file, so you do not need to modify this code to view your logs Inline

documentation is included in most of the file, but as always, if you have any

questions on this code, chapter, or book, you should feel free to drop the authors

a line at Syngress, or you may contact James C Foster directly at

jamesfoster@safe-mail.net

#define MESSAGE_MAX_SIZE

#define IP_MAX_SIZE

// structure are valid

// - IN Context - Context allocated by InitializeContext on plugin initialization

// - IN EventData - Data from the applicable snort rule

//

// - This function is called from AlertW3C and is used to serialize

// several data sources into one common data structure

//

//

//

//

//

//

//

// - AlertW3CSetup < Called from InitOutputPlugins() in plugbase.c

// - AlertW3CInit < Called from ParseOutputPlugin() in parser.c

// - AlertW3C < Call per each alert

Running and Testing the Snort W3C Output Plug-in

We have now completed the program, and there is only one last item to take

care of: We must test it! Assuming that there are numerous compilers, all of

which work differently in use but are similar in functionality, we’ve compiled our

version of Snort using Microsoft Visual Studio 6.The compilation went

smoothly, and after compiling we ran Snort with a few attacks, ICMP and Scan

attempts, to test our plug-in Sure enough, it worked as planned Figure 7.18 dis­

plays a sanitized log ascertained from our testing of the plug-in Notice how it is

prefaced with our timestamp, followed by the remaining appropriate fields

Figure 7.18 W3C Output Log Format Example

Dealing with Snort Output

Sometimes you might find that it is easier to work with what Snort gives you

instead of creating a new output plug-in Considering the current varying

options and formats, in most cases you might simply want to go the down the

path of least resistance and deal with post-Snort data modification

One of the easiest and certainly the most popular methods for creating a cus­tomized Snort data interface is creating some type of database interface.The cur­rent relational database plug-ins update the databases in real time when new

threats are identified, rules triggered, and data logged.The data accessed from the databases can still be considered real-time data.These databases provide an excel­lent medium for accessing up-to-the-minute data without having to “reinvent

the wheel.” As you now know, there are multiple database outputs you can select, ranging from the enterprise choice of Oracle to the freeware version of MySQL Perl with Tcl/Tk, Java, Visual Basic, PHP, and even Visual C++ are suitable languages to code Snort database interfaces.There are many others, but PHP and Perl are two of the most popular due to the easy language syntax, Web-based

nature, and rapid development characteristics.Table 7.4 details a few of the vital pros and cons that should be weighed in considering a database solution

Table 7.4 The Pros and Cons of Using Snort Database Information

Real-time information

Some data correlation can be

achieved inside the relational

Relational databases allow you to

create multiple tables and relations

to potentially access subsets of

data from multiple Snort sensors

Storing the data in the databases

might be a more flexible solution

going forward

In comparison to the other options, databases have the potential to be bandwidth-intense

Databases alone are enterprise applica­ tions in themselves, and as such might databases require maintenance in regard to user management, patching, and system configuration

Costs might be associated with imple­ menting the database option if a non freeware option is selected

For the most part, accessing the data

in a secure manner is left up to the user

Network databases are popular

“hacker targets.” Application security should not be an option; it should be mandatory

Heavy development time

Another option that is available if you do not want to use a database to store Snort logs is to go the flat-file route Using flat files poses an interesting situation

in that these files are usually stored on the Snort sensor Some of the more pop­

ular flat-file plug-ins are Alert_fast, Alert_full, Alert_CSV, and Log_TCPDump It

is possible to retrieve these files remotely, but the logistics and time delta

between the event and event notification might prove unacceptable Flat-file

analysis really hits its full value proposition when a single data element or type of

data element is desired It is a poor enterprise solution.Table 7.5 highlights a few

of the pros and cons of using a file-flat analysis schema

Table 7.5 The Pros and Cons of Using Snort Flat-File Information

Flat files must be parsed and inter­

preted before data modification can begin

Depending on the size of the file and the amount of available system memory, parsing the file might bring your system to a screeching halt (same with XML)

ment doesn’t seem to be hurting anything either XML has several of the same

issues as flat files do, since in most cases these files would be stored locally on the

sensors.The only notable advantage over a flat-file plug-in is that

XML-for-matted output is easier to extend and more flexible if it should be used in future

applications.Table 7.6 lists XML technology pros and cons in reference to Snort

sensor databases

Table 7.6 The Pros and Cons of Using Snort XML-Formatted Information

Immerging technologies that

support XML-formatted data feeds

To date, XML has been a relatively

secure technology

Storing the data in XML might be a

more flexible solution going forward

In general, XML files are stored on

the Snort sensors

XML files must be parsed and inter­

preted before data modification can begin

Depending on the size of the file and the amount of available system memory, parsing the file might bring your system to a screeching halt (same with flat files)

Post-real-time speeds

An excellent new feature in Snort is the ability to store unified or binary data

or to provide such data as an input stream to another program using such infor­mation Using binary data and unified data streams threads processes away from the Snort executable, thus allowing Snort to focus on the more critical processes such as data collection and storage Chapter 11 addresses all the intricacies of

unified data and processing such data.Table 7.7 lists the pros and cons of using spooling streams

Table 7.7 The Pros and Cons of Using Snort Unified and Binary Information

Unmatched speed

Unmatched Snort application and

sensor performance

Snort’s Barnyard application is

maintained by the Snort

development and is quickly

becoming an integral part of the

product

Flexible and scalable

All things considered, our recommendation is twofold If you are looking for

a quick fix to a problem or to merely create a “hack job” that gets the issue

resolved, by all means go with a script that pulls relevant information out of a

PCAP or header-infused alert file Such a solution would be adequate if your

goal was to determine what attacks were generated from a particular source

However, if the goal is to create an enterprise-grade or purely a more sustainable

application, the choice should be obvious: relational databases or unified data

streams Once the code to access and retrieve the data is flushed out, data selec­

tion and modification will seem trivial Moreover, using a Snort database might

prove beneficial down the road, when future NIDS projects arise

Tackling Common

Output Plug-In Problems

With Snort’s flexibility and scalability come various issues Of course, these issues

span a wide range of technical and user-instantiated problems

One of the most common issues that users have when trying to gather data from a database in which Snort has logged and stored data is reading—or should

we say de-obfuscating—IP addresses Why, you ask? Well, Snort saves all IP

addresses as binary integers, thereby saving space and permitting the IP addresses

to be searched by intricate queries involving network masks Snort’s database was

created and designed to store IP addresses in distinct fields, the iphdr.ip_src and

iphdr.ip_dst fields

It is true that the database stores these addresses in different formats, but it is not complicated to convert these integers back to period-delimited IPv4

addresses Depending on which backend database you are implementing, there

are multiple ways to conduct analysis on the addresses If you have implemented

a MySQL database, you are in luck because it comes with a native or built-in

function that does the conversion for you: inet_ntoa() This function will handle

all the algorithmic conversion for you such that 2130706433 would be easily

converted to the IP address representation of 127.0.0.1, also known as your

loop-back address.Yet if you wanted to run a direct SQL statement to ascertain this

value, you would simply need to type:

Unfortunately, it is not that easy for all you truly freeware users who have selected PostgreSQL storage databases because there is not a native function

However, converting the unsigned integer manually is not as difficult as you

might think.The following is a function created by Phil Mayers to convert the

integer to an IP address on the fly:

($1

ip_src

An extremely common database problem that we have recognized is spawned from a user error when upgrading Snort installations As with most database-

driven applications, or more appropriately, most database-reliant applications,

Snort changes its database schema on most major and even some minor releases This is because the database schema changes when new types of data are per­

mitted or stored via the Snort application If you receive a Snort error stating

that the database version you are using is old, you will probably have to reinstall a new Snort database and migrate the old dataset to the new format More risky but nonetheless an option, you can always try to update the database with the

new fields in the schema before trying a full reinstall.The following is the error message Snort throws when an outdated database schema is being used:

Summary

The Snort application has gone through many different architectural,

algorithm-specific, and implementation modifications With just about all these changes

have come direct, positive product and feature enhancements One of the most

beneficial features built into Snort with reference to reporting and data presenta­

tion is Snort’s ability to use output plug-ins.These plug-ins enable network and

security administrators, engineers, and managers alike to optimize the product for

their environments and to ensure that minimal resources are spent maintaining

the technology Minimizing resources will also have a direct impact on the mean­

time to data analysis, which defines how fast your company can react to any incident

Currently, you have several different options when you’re using output ins Various options allow data to be formatted in PCAP, straight text headers

plug-with packet destination and source information, along plug-with rule messages, XML

text databases, and multiple relational databases including MySQL, Oracle, and

MS SQL Along with the format of the data, Snort provides the ability to store

and transmit the formatted data in numerous ways Storing alerts and logs locally,

transmitting data to UNIX sockets, and pushing data to local and remote

databases are all potential methods It is not necessary to use plug-ins for every­

thing, given that complementing utilities are available Log parsers, graphical

interfaces, and correlation engines allow the user to further format data with

application wrappers and scripts Barnyard, Acid, and Cerebus are three of the

most popular complementary Snort applications

The existing output plug-ins are nice, but the real value-add comes with Snort’s ability to create customized plug-ins Because the Snort development

team has implemented an open API structure for the use of output plug-ins, both

private organizations and professional security teams can design in-house

plug-ins.These in-house plug-ins can be driven by technology or customers, but the

common goal should always remain: to minimize manual data compilation tasks

These plug-ins access a highly technical subset of functions and application calls

that reference configuration instructions and the corresponding parameters

defined during Snort runtime.The bulk of the plug-in resides in formatting the

input data while also handling the technologies used during the output phase

We found that just about any technological executive or manager freely voices the fact that data is useless unless it can be quickly analyzed and used to

make decisions Part of Snort’s answer to inherent technology issue is output

plug-ins Our recommendation: If freeware Snort is a valuable asset within your

organization, it is essential that you have an engineer or scientist who completely understands output plug-ins

Solutions Fast Track

What Is an Output Plug-In?

� Output plug-ins, also called output modules, were introduced in Snort

version 1.6 and are an excellent mechanism for storing information in a customizable formats and locations It was the first major movement into creating an open reporting API

Exploring Output Plug-in Options

� Currently, Snort has plug-ins that support multiple reporting formats to include straight text headers, PCAP, UNIX syslog, XML text databases, and numerous other types of relational databases

� Captured and defined data can be stored in local alert and packet logs and local and remote databases, in addition to blindly transmitting the data to a UNIX socket

� Additional programs such as Acid, Barnyard, and Cerebus are irreplace­able assets in analyzing and modifying data reports

Writing Your Own Output Plug-In

� Writing Snort output plug-ins is no easy task if you have little or no C programming experience It is much more complex than Snort rule authoring, since to date all the output plug-ins are written in C

� A potentially quicker alternative to writing an output plug-in is writing

a plug-in wrapper For example, if the goal is to format data instead of modifying real-time data formatting and storage, it might be faster and more economical to write a Perl script that automatically runs against the payload and outputs the desired information

� The output plug-ins have some common similarities, including global variable definitions and prototyping, keyword registration, argument and

preprocessor argument processing, plug-in and function cleanup and exiting, and data formatting and transmission

Creating a W3C Extended

Log Format Output Plug-In

� The five major components for our self-authored Snort W3C output

plug-in are myPluginSetup, myPluginInit, myPluginAlert,

myPluginCleanExit, and myPluginRestart, all of which are aptly named and

do as they imply via the naming convention

� For our custom Snort output plug-in to work, you must register the plug-in within the Snort source code tree and then recompile the tree

The following code will handle the registration process:

� The data buffer utilizes a single dimension character array that gets

written to the log file via C’s fwrite function

Tackling Common Output Plug-In Problems

� Snort stores IP addresses in databases in a single-integer format to save CPU resources and space when storing data in the database

� Database problems are common, so it is pertinent that you verify that you have the latest database schema installed when you upgrade your Snort installation Sometimes this will mean that you merely have to add

a couple empty tables or columns; however, you won’t always get this lucky

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts To have your questions about this chapter answered by the author, browse to

www.syngress.com/solutions and click on the “Ask the Author” form You will

also gain access to thousands of other FAQs at ITFAQnet.com

Q: Do you have any recommendation as to type of output module to use on a mobile workstation?

A: Let’s presuppose that for a traveling computer, security is an essential require­ment, CPU and memory are valuable commodities, and that it is being mon­itored and used the majority of the time It is probably in your best interest

to only use alerts with minimal information, since we can assume that if you were attacked, immediate action would be taken Packet headers and rule

content messages should suffice Specifically, fast alerts would be our UNIX recommendation, whereas the SMB client (a.k.a Windows PopUp) would be the choice for Windows users

Q: What kind of bandwidth hit will I take if I choose to log alerts to a remote database?

A: Bandwidth consumption is completely derived from two factors.The first is the amount of data that is transmitted across the sensor network, and the

second is the ruleset that is implemented on the sensor We recommend

keeping the primary log database on the Snort sensor to minimize network impact if you can afford the hardware, because running a database will impact system performance If you do not have this option and your network uses under 20 percent of its available bandwidth on a common workday, it is

probably okay to go ahead and use a remote database plug-in.To test and

prototype the options, you can monitor local logs and sizes to determine

whether the data load would be too great if imposed on the network

Q: Can I log to multiple databases, even if they are different types of databases?

A: The short answer is yes Now for the real answer, since there are multiple

ways to reach the end goal: Snort provides users with the ability to log to

multiple instantiations of the same database plug-in, log data to multiple

identical and different databases, and log data to miscellaneous other data types.The following are examples of output instructions that can be defined

in a configuration file

Example: Multiple formats including a database:

Example: Multiple databases:

Example: Multiple instances of the same database:

Q: Do you recommend that I keep forensic backup data from the Snort sensors?

If so, in what output format should I keep it?

A: We’d say yes; we would recommend that you implement some sort of

perimeter backup capability via your Snort sensors output selection With that said, it could prove extremely difficult to back up any amount of non-alert data or Snort-formatted data such as all the complete raw traffic

Network Associates has released a product that does this exact thing and has the capability to store up to 32 terabytes of network traffic before running a backup procedure Obviously, this would be overkill for most system net­

works and perimeter security policies; however, as a rule of thumb, 30 days of logs is a good amount to keep on file If you simply have too much traffic to possibly keep that much data, keep as much as you can Hopefully, you will notice attacks and intrusions when they are occurring and not a month or two later

Dealing with the Data

Solutions in this Chapter:

■ What is Intrusion Analysis?

■ Intrusion Analysis Tools

■ Analyzing Snort IDS Events

 Summary

 Solutions Fast Track

 Frequently Asked Questions

379

1892

Introduction

“You see, but you do not observe.”

—Sir Arthur Conan Doyle (quoting Sherlock Holmes), A Scandal in Bohemia,

See the traffic Feel the traffic Be the traffic.You have instrumented your net­

works with Snort, capturing attack traffic and sending alerts Millions of packets and thousands of alerts a day, and you have to make sense of it all

Snort, at its heart, is a very complex pattern matcher geared toward detecting patterns of network attack traffic On any given network, on any given day, Snort can fire thousands of alerts.Your task as an intrusion analyst is to sift through the data, extract events of interest, and separate the false positives from the actual

attacks But your job does not stop there Once you have pruned your data,

intrusion analysis begins

In this chapter, we cover methodology and the tools to help you manage the task of monitoring Snort sensors and analyzing intrusion data.The tools we will cover are:

What Is Intrusion Analysis?

Intrusion analysis is an investigation into a network incident.The incident in ques­

tion might be a compromised host, a denial of service attack, or a port scan.You must assess the risk to your organization as well as evaluate the impact of the

incident and take actions to mitigate the threat

Snort Alerts

In most incidents, the first piece of information that an analyst reviews is an

alert An alert is a message passed from a detection mechanism when it matches

an event to a known pattern.This message can take many forms: pager message,

syslog entry, ticket system entry Usually at the very core is a simple plaintext

message with a brief description of the event:

Example Full Alert Mode alerts:

Example of the same event Alerting in Fast mode:

We see here a vast difference in output coming from Snort.The first output format we are given, Full Alert mode, gives the analyst a brief (although verbose)

description of the event Fast Alert mode gives the analyst a cursory amount of

information about the event.This is a great mode to run Snort in because it

reduces the performance impact of the output stage, but it delivers less informa­

tion to the analyst

Let’s examine the Full Alert mode format:

[**] Snort Alert Message

[ Classification: ] [ Priority:

Time Stamp

It is interesting to note that at the beginning of the alert we see [1:1913:8]

This tells the analyst that the detection engine fired the event (1), the SID for

this signature is 1913, and it has been revised 8 times In the Full Alert mode

example, we find two external references: one to security focus, the other to

Mitre’s CVE database.These can be very helpful in gathering additional informa­tion about this attack If you can spare the cycles and the bandwidth, you might want to start off by receiving the alerts in Full mode because this will give you the most data without having to look through the packet logs that are stored

separately

Snort Packet Data

Snort can log packet data in three base formats: ASCII, Pcap binary format, and Unified binary format ASCII logs, although very easy to read using a text editor, are not as useful as the binary logs for analysis Pcap binary logs can be read and processed by hundreds of tools that have been designed with traffic analysis in

mind Some examples of tools that can read Pcap format files are tcpdump, ethe­real, ngrep, tcpreplay, logsorter, ethereape, and many, many more (For a compre­hensive list of Pcap-aware tools, visit Bill Stearns’s excellent site at

www.stearns.org/doc/pcap-apps.html.) Snort’s Unified binary format can be read

by only a few tools, namely Barnyard, Mudpit, and Cerebus

Providing the ability to view actual packet data is one of Snort’s strong

points In many commercial solutions, the ability to view the packets that caused the alerts to fire is not available As a result, you can’t tell why the IDS made a

mistake when it inevitably happens

OINK!

Just in case you have any doubt, it is essential to have the packets per­

form effective intrusion analysis Unless you trust your IDS to never ever produce false positives (and no matter what the vendors say, all IDSs produce false positives or negatives), you need to have the packets look

at when you’re trying to figure out, whether the alert you are seeing is really something horrible or whether it is just the IDS making a mistake Anyone who says you don’t need the packets hasn’t done intrusion analysis professionally or is a vendor trying to convince you that it’s okay that the vendor’s product is missing an essential feature

Examine the Rule

One of the most important changes that Snort brought to the intrusion detec­

tion community is the ability to examine the rule that triggered the alert.You

can now analyze the quality of the rule and take the rule into consideration

when analyzing packet data Using the rule, you can now view the packet from

Snort’s perspective

Take the rule that triggered the rpc statd alert:

The first thing we note is that this rule is looking for very specific content, and it does multiple content checks.This gives us the impression that this rule

might have a low rate of false positives.The next thing of interest is the revision

number.The fact that this rule has been revised eight times indicates that either

the vulnerability or the exploits are changing or that multiple attempts to tune

this rule have failed

Validate the Traffic

The first thing that you need to do to validate the traffic is to compare it to pro­

tocol specs.The first place to go for information about a specific protocol is the

Request for Comments (RFC) RFCs are hosted on many sites on the Internet,

including www.ietf.org/rfc.html, www.rfc-editor.org/, and our favorite,

www.networksorcery.com/enp/default0601.htm

When you’re identifying the target of the attacks, don’t stop at the IP address

Find out what that host is, what OS is it running, who is responsible for it, and

how critical is it to your organization

Identify the source of the attack Determine whether the address could be spoofed Is the attack a content-driven exploit that uses TCP as its transport

mechanism? If so, the probability of the address being spoofed is very low

Attack Mechanism

You need to find out how the attack works, what services it exploits, and

whether you are vulnerable to the attack Much of this legwork can be done

using everyone’s favorite tool, Google Check vulnerability information sites, such

as Security Focus and Cert.Then follow up with a quick look at Packet Storm and K-Otik to see if there are any public exploits for this attack If there are

easy-to-use, publicly available scripts and this is a high-priority incident, your

turnaround time for analysis and defensive recommendation must be very quick

If the attacker can successfully bypass your network countermeasures and attack critical machines, you must act quickly to mitigate the overall risk to your com­pany (and possibly your job)

Exploring the attack mechanism further, try to determine what telltale signs

we can use to differentiate between a successful attack and a failed one.This

information can also be used to tighten or tune the rules used to detect the

attack on the network

Intrusion Data Correlation

Intrusion data correlation is a subject shrouded in myth and protected by the high

priests of network security In reality, we can explore simple methods of correla­tion to achieve good data visibility and coverage without going to the extreme depths of data correlation

The principle concept of intrusion correlation is to find additional data

points connected to the incident you are currently investigating that allow you to increase your confidence that the incident is real or false (It doesn’t matter

which it turns out to be; correlation is about increasing your confidence in that conclusion.) This data can come from hundreds of potential sources and can be manipulated in hundreds if not thousands of ways

The main points of intrusion correlation are:

■ Time Were there any other successful and/or similar attacks within a threshold of time?

■ Source Was this the only event associated with this IP address? Can you find any additional hits with this source address in your firewall or Web server logs?

■ Target Was this the only target address to receive this event type over the last few hours or days?

■ Event type over threshold of time Have you noticed any rise or fall

in trends related to this particular event type that would suggest a mounting risk to your organization? Could this be a precursor to a new worm?

■ Ancillary logs Do any system, application, firewall, or router logs relate to this incident? Was the attacker scoping out your site for days, looking for a way in? Or is this just an automated attack?

Any supporting evidence will help the investigation of the incident

Remember, however, that analysis and investigations take time.Track the time it

takes to fully investigate an incident.This will help you if you ever decide to

prosecute the attacker, as well as helping you better manage your

incident-han-dling process Be aware that business managers will begin to analyze the time you

spend investigating events, and determine which incidents deserve attention

based on how much it will cost the organization

Following Up on the Analysis Results

Incident reports are filled out Abuse e-mails are sent, with copies to your opera­

tions group.You must now evaluate the overall risk to your organization as well

as make defensive recommendations so that this situation doesn’t reoccur

To estimate the impact of this incident on your organization, take into consid­

eration the criticality of the target to your organization Is it a core router, a main­

frame with all your proprietary research, a database with all your customer credit

card information? Or is the target a workstation or other low-priority devices?

Extrapolate the potential risk this incident could pose to your organization and if possible tack on a dollar amount Managers live in a world of dollars and

cents If we can show them that by dealing with the incident and mitigating

future risk to the organization, we will save the company thousands of dollars,

they just might listen

Perhaps the most important part of the analysis process is to provide defensive recommendations to mitigate the future risk to your organization.This is impor­tant from a security life-cycle perspective, as is taking a proactive stance in

defending your organization’s information assets

Intrusion Analysis Tools

“Water, water everywhere, nor any drop to drink.”This famous line from poet

Samuel Taylor Coleridge’s “The Rime of the Ancient Mariner” gives us the per­fect analogy for one of today’s network dilemmas: We have way too much data

We have instrumented the heck out of our networks—now how do we make

sense of it all?

Packet logs, system and application logs, IDS logs, and data correlation are all parts of this twisty little maze we call intrusion analysis Although a plethora of commercial tools is available, we will delve into many of the excellent free tools for applying our intrusion analysis skills.These free but powerful tools give

everyone the power to effectively analyze data in search of intrusions and misuse

Database Front Ends

Our foray into data analysis tools begins with database front ends.These intuitive graphical front ends to databases give the analyst the power and speed to comb through hundreds of thousands of records, if not more Smaller networks might enjoy the simplicity of “grepping” through their intrusion logs, but medium-sized and large enterprises need to rely on the structure of a well-maintained database ACID and SGUIL are the best of their breed when it comes to open source

analysis tools In the next sections we discuss installing, using, and maintaining

these powerful tools

Analysis Console for Intrusion Databases (ACID) is a tool for data browsing and analyzing ACID is basically a set of PHP scripts that provide the interface

between a Web browser and the database where Snort data is stored.This tool

has been in development for about three years at the time of this writing, but it

is still described as a beta release ACID has grown into a very powerful consoli­dation and analysis tool

ACID is maintained as part of a larger project called AirCERT

(www.cert.org/kb/aircert/) by its creator, Roman Danyliw At the time of

writing, the current version of ACID is 0.9.6b23 Originally designed solely for

processing Snort data, ACID is now independent of the Snort database structure

and can work with various data produced by various other engines (provided

that the data is imported into ACID database in some way)—for example, Linux

IP filter firewall or Cisco access list-related messages A script logsnorter is included

in the ACID distribution and is designed to import logs with alerts from these

engines into Snort databases, so this data becomes available to ACID, too

At this time, ACID provides the following features:

■ An interface for database searching and query building Searches can be performed by network-specific parameters such as attacker’s IP address,

by meta parameters such as time or date of an event, or by triggered rule

■ A packet browser that can decode and display Layer 3 and Layer 4 infor­

mation from logged packets

■ Data management capabilities, including grouping of alerts (so that it is possible to group all events related to an intrusion incident), alert dele­

tion, or archiving and exporting to e-mail messages

■ Generation of various graphical charts and statistics based on specified parameters

The rest of this section describes the installation of ACID and its prerequi­

sites, Snort configuration, and the ways in which ACID can be used for intrusion

detection and analysis.You can download ACID from www.cert.org/kb/acid or

install it from the accompanying CD-ROM

Installing ACID

The structure of ACID is multitiered and scalable.You can use it on just one

computer, or you can have an architecture of up to three tiers Figure 8.1 shows

logical parts of the system

OINK

ACID is included on the accompanying CD-ROM