Interoperability and Architecture

Trang 1

First Principles Continued

Hello, and welcome to the second half of the First Principles section In the previous hour, we went over a sample tool, Pepsi, the UDP flooder, that attackers may be using to attack our networks We discussed the role of firewalls in intrusion detection Now, we will move on to discuss several efforts

to promote interoperability among intrusion detection systems, and examine various methods of processing alerts and reacting to suspicious events

Trang 2

Intrusion Detection Interoperability

(CVE, CIDF, IDWG)

Let us begin by introducing several acronyms that will be used in the next few slides:

Common Vulnerabilities and Exposures (CVE), a thesaurus for vulnerabilities

Common Intrusion Detection Framework (CIDF) is a proposed standard to allow interoperability between intrusion detection components

Intrusion Detection Working Group (IDWG) is the Internet Engineering Task Force (IETF) Security working group for intrusion detection

Since we draw information from the RFC the copyright is shown below

it may be copied and furnished to others, and derivative works that comment on or otherwise explain

it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works However, this document itself may not be

modified in any way, such as by removing the copyright notice or references to the Internet Society

or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed,

or as required to translate it into languages other than English The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.”

Trang 3

AusCERT Auto Extract

These trailers are designed to facilitate

automated extraction of information by

Date: 30th Jan 2000 at 22:01 (UTC)

The trace above is most likely a probe for portmap, (TCP port 111) This is one of the most common and successful attacks on the Internet Its format gives us all the basic information we need from a trouble ticket standpoint By this I mean it is great for a site that is reporting well known attacks to a CIRT

If we needed to do analysis or provide answers , however, this simply would not do In that case we would need access to more information

This is a working system is very useful for statistical analysis and understanding trends You will see the format many times on GIAC In AusCert’s own words, “these trailers are designed to facilitate automated extraction of information by AusCert.” They represent a method of adding information to the AusCERT database without manual human intervention

Trang 4

Griffin List

A simple data exchange format similar to the AusCERT format

will allow sites to create a Griffin list, or watch list, of the IP

addresses that have been used to attack and probe and also the

In the same way that you might want to compare all traffic that comes to your site to a list of proxy servers, you might also want to run a Griffin list against your traffic It serves as an indicator to investigate certain traffic more closely, and it can help you find things you might otherwise miss, or dismiss

If you are willing to submit a list of the IP addresses that attacked your site to GIAC or another CIRT, but sure to send it to only ONE SITE that constructs a Griffin list or you’ll risk introducing serious errors into the routines that evaluate how many times an attacker has been seen

Trang 5

INTERNET

Single system, single site - the only interoperability needed

is between the event generator, analysis console, database

and response In this scenario, an attempted penetration of

the firewall is detected; the response system (firewall) drops

the connection.

S A

M R

What is a possible IDS architecture that would facilitate automated response to an incident? Take a look at the diagram on this slide The “S” represents the sensor The “A” represents the analysis box The “R” represents the response system, and the “M” represents the management station of the system In this case, if a penetration attempt is detected, the response system (firewall) drops the connection

Some people put both sensors and analysis boxes on the same computer, but this might not be a wise architecture Intrusion detection systems outside the firewall are in a hostile location and should know as little about the internal security architecture as possible If an intrusion detection system is compromised, the attacker may learn too much about the site from its rule set So, be sure to keep a close eye on an IDS that is placed in front of a firewall!

The paradigm on this slide’s diagram is that using auto-response, we could get reports to CIRTs within 10 to sixty seconds of the actual detect This turnaround time might allow them to do a traceback

This slide represents one of the primary choices in auto response, such as blocking the perceived attacker from your network If you want to implement auto response, then be sure that your system has a capability for putting your friends and business partners on a “slo blo” system Otherwise, an attacker can disrupt your operations by spoofing your partner’s IP and attacking you, which in turn sets off the defense system that would render your partner unable to do business with you

Trang 6

INTERNET

In an attack situation, multi-homed sites or partners may need

to exchange response information To do this they need a

common thesaurus, transport, and data model.

S

S S

Currently, each approach has its strengths CVE’s is its thesaurus; IDWG’s is its transport and data exchange CIDF, though all but obsolete at this point, is most useful as a conceptual framework However, don’t let the slide fool you into believing in the interoperability of CIDF/CVE/IDWG In the end, the most likely winner will be the IDWG

Trang 7

The problem of Babel

Because there is no standard taxonomy for

the checks these scanners perform, directly

comparing the comprehensiveness of their

databases is difficult We found that

Internet Scanner and CyberCop name

the same vulnerabilities differently …

InfoWorld, Feb 1999

CVE is a common thesaurus, not a taxonomy

CVE grew out of MITRE’s internal work David Mann and Steven Christey were working on a vulnerability database They sought to map tool results for system information to alerts or fix information Then, they hit the naming problem

For instance, the CGI phf program allows remote command execution through shell meta characters

We have all seen this attack from the classic exploit attempts that cat the /etc/passwd file CERIAS calls this httpd_escshellcmd and CERT calls this CA-96-06.CGI_Example_code, and on it goes So how do you know each of these is the same attack?

They did a web literature search on vulnerability taxonomies, which led them to the work at

CERIAS They found out that everybody had the same problem they did

In November 1998, Dave and Steve started looking at how other scientific disciplines handle

naming This led to a paper entitled ‘Towards a Shareable Vulnerability Database’, which was presented at the 1999 CERIAS Workshop on Vulnerability Databases They developed the concept

of a common language for vulnerabilities Since everyone suffered from the same problem, this idea resonated with the attendees

Note that taxonomy is the science of classification CVE is a common thesaurus, not a taxonomy CVE endeavored to name the attacks, as opposed to formally classifying them

Trang 8

Overlaps and holes

C V E

N a m e

T o o l A

T o o l B

D B 1

D B 2

Trang 9

• Tool or database can be configured

to produce CVE names as output.

Say you have completed GIAC LevelTwo vulnerability assessment training You would then know the common vulnerabilities that were most often used in attacking systems This is an example of the use of CVE as output Next you would want to scan your organization for these common

vulnerabilities, say with ISS Security Scanner, a CVE compliant tool You could feed the scanner this list of vulnerabilities as input and scan for these particular holes

If your choice of a vulnerability scanner is not CVE compatible then you would have to manually decide if these were the correct ones since there are multiple names for vulnerabilities It can be hard

to be sure that the vulnerabilities found are, in fact, the common vulnerabilities that you were scanning for

Trang 10

Summary – CVE facilitates

• Incident response teams

We have discussed a number of aspects of CVE, but if we could characterize it in a single sound bite, CVE is a tool that facilitates data sharing among diverse components Data sharing is necessary among computer-based components such as: intrusion detection systems, assessment tools, and vulnerability databases, as well as human participants in the security field – researchers, incident response teams, and intrusion analysts

Now, let’s move on to the next piece of the interoperability puzzle You next slide is titled “CIDF as

a Language.”

Trang 11

CIDF as a Language

- Raw event information, (e.g., audit trail

records and network traffic)

- Analysis results, (e.g., descriptions of

system anomalies and detected attacks)

- Response prescriptions, (e.g., halt

particular activities or modify component

security parameters)

The language is written in S-expressions

This slide is the heart of why you should be familiar with CIDF The researchers sat down and asked: what is the heart of interoperability; what do we have to be able to do? Their answer is shown

on this slide The simple AusCERT format we looked at earlier is not sufficient for interoperability;

it does not meet any of the criteria on the slide

According to the CIDF Web site at http://www.isi.edu/gost/cidf:

“The Common Intrusion Detection Framework (CIDF) is an effort to develop protocols and

application programming interfaces so that intrusion detection research projects can share

information and resources and so that intrusion detection components can be reused in other

Trang 12

Intro to S-Expression

(Hostname ’www.sans.org') This S-expression groups two terms, Hostname and ’www.sans.org' It should be noted there isn’t a binding relationship between Hostname and a host name (www.sans.org).

Hostname is an S-Expression atom and so is ‘www.sans.org’ There is no requirement for the hostname argument to be bound to www.sans.org That is, you could just as well say (Hostname

‘888-555-1212’) This isn’t a problem as long as people write intelligent programs, but we all know the dangers of untyped programming languages

It’s as if Hostname is the variable to reference hostname for all components in CIDF, and the value bound to that changes to reference the exact hostname we need to specify

The next slide offers an example of a slightly more complicated S-expression

Trang 13

This S-expression is a complete sentence asserting that the user with username ’lp’ deleted the file

'/etc/passwd' from the host 'first.example.com' at 16:40:32 on Jun 14 1998 This example highlights special kinds of Semantic Identifiers, or SIDs, such as verb SIDs, (in this case delete), that show what happened It also shows role SIDs (e.g., Context, Initiator, and Source), that portray

"whodunit", what it was done to, where it was done, and so forth Other SIDs give details (such as the time) about these various components of the event

Trang 14

Example Atomic SID

Name: Severity

Code: 00000007

Type: octet

Description: The severity of an event, as measured by

the observer A value of 0 means that the event is

believed to represent no risk to the system, (again, this

shouldn't be used very often) A value of 255 expresses

maximum severity What represents maximum severity

will clearly vary from system to system In other words,

caveat receptor

Obviously, this is a simplistic view of severity as the slide warns If we wanted to have an

S-expression similar to the one on the previous slide that incorporated the SID Severity, we would take what we had before:

Trang 15

CIDF Summary

• Potentially provides the building

blocks for full court ID

• Provides a common vocabulary to

discuss ID issues

• Overtaken by IDWG?

Primary CIDF site: http://www.isi.edu/gost/cidf/

To summarize, CIDF attempts to provide a common language and vocabulary for components of intrusion detection systems to “discuss” ID issues While CVE limits itself to names of

vulnerabilities, CIDF attempts to describe a much wider range of ID aspects, such as event information, analysis results, and response procedures

The current status of CIDF is unclear, though some of its efforts may have been overtaken by the Intrusion Detection Working Group (IDWG), which we will discuss next

Trang 16

IDWG

• Intrusion Detection Working Group

• Draft RFCs approaching

implementation quality

• IAP Intrusion Alert Protocol

• Data Model based on XML

According to the IDWG charter, located at http://www.ietf.org/html.charters/idwg-charter.html:

“The purpose of the Intrusion Detection Working Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them.”

Things are starting to pick up here and there are going to be a lot of significant changes Currently, a number of groups are attempting to develop prototype implementations and are learning a lot from the attempts The best thing to do is check on the progress of the IDWG via the Web once a month

or so One of the IDWG sites is: http://www.silicondefense.com/idwg The Internet Engineering Task Force is also a good place to start, (http://www.ietf.org), or even more dynamic, the following URL,(http://www.semper.org/idwg-public/)

Trang 17

Intrusion Alert Protocol

• Based on TCP/IP

• Sensor/Analyzer reports to a Manager

• There may be addition intermediaries

such as proxies and gateways

The idea is that the Sensor/Analyzer (S/A) producer sends alert data over IAP to the Manager (M) There may be additional intermediaries in this communication, such as proxies (P) and gateways (G)

A Proxy does not have an IAP identity It acts as a relay of messages without understanding their content It MAY do some rewriting of the content, but in a manner that does not impact the security properties of alerts

Trang 18

IDMEF

Intrusion Detection Message Exchange Format

The IDWG has selected an

eXtensible Markup Language (XML)

based solution for message

exchange XML is an html_like

language for describing languages.

The IDWG defined a format for message exchange between ID components, called the Intrusion Detection Message Exchange Format (IDMEF) According to IDWG, the IDMEF “is intended to be

a standard data format that automated intrusion detection systems can use to report alerts about events that they have deemed suspicious The development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal implementation.”

The IDWG decided that an XML-based solution was best at fulfilling the IDMEF requirements, and defined the IDMEF data model by creating an XML Document Type Definition (DTD) XML, for those who are not familiar with the term, is an HTML-like language for describing other languages Those interested in the details of the IDMEF data model should take a look at the draft of its

specifications at http://www.silicondefense.com/idwg/draft-ietf-idwg-idmef-xml-02.txt

Trang 19

• CVE defines names for vulnerabilities

• CIDF defines language for ID

Trang 20

Signatures,time and detect flow

In the final part of the “First Principles” discussion, we will introduce the notion of attack signatures

We will discuss the flow and process of detecting and reacting to intrusions

Trang 21

INTERNET IDS

Most Intrusion Detection Systems avoid the issue

of knowing the firewall policy and simply look for

indicators of known attacks called signatures.

This is OK until we look at issues related to response.

Most Intrusion Detection Systems avoid the issue of knowing the firewall policy and simply look for indicators of known attacks called signatures

The intrusion detection system developers have spent a lot of time building software that allows them

to factor your site’s policy into their system I was talking with an IDS development group recently, and they were really frustrated because nobody ever bothers to use the capability This leaves a sophisticated intrusion detection system with the functionality of low end virus detection software (Virus software may check for more than 15,000 signatures; intrusion detection software is currently

in the 200K range)

Signatures certainly have a prominent place in intrusion detection The next slide shows an example

of a typical signature

Trang 22

Signatures come in two flavors and can be combined:

- Traffic or Header Based

- Content Based

There are a series of attacks against web servers that run cgi-bin programs This particular one is against the servers that run search engines based on aglimpse If the intrusion detection systems sees

aglimpse and IFS (Internal Field Separator) then it can say it matches the signature for attack.

A much more general signature that matches most cgi-bin attacks is cgi-bin and /etc/passwd, since most of the attacks are designed to extract the password file to crack it off line Here is just another reason to move to Unix systems with shadow password files, if you can

Trang 23

Traffic or Header Analysis

Traffic analysis of data collected by ID sensors, firewalls, system logs and other sources of information is focused on the fact that a message was passed, not the content Correlation and profiling are two of the most powerful TA tools.

This slide, and the one that follows contrast Traffic Analysis (TA), also referred to as header analysis, against the primary technique in play, content analysis and string matching Either technique can be done in “real time” or at least near real time and “post mortem” or retrospective analysis

Traffic analysis of data collected by ID sensors, firewalls, system logs and other sources of information is focused on the fact that a message was passed, not the content Correlation and profiling are two of the most powerful TA tools

Trang 24

Content Analysis

Content analysis of data collected by ID

sensors, firewalls, system logs and other

sources of information is focused on the

contents of the packet Most burglar alarms are

primarily content based tools.

Content analysis of data collected by ID sensors, firewalls, system logs and other sources of

information is focused on the contents of the packet Most burglar alarms are primarily content based tools

As we go over some attack signatures in the next slides, keep in mind the distinctions between traffic and content analysis You next slide is titled “Signatures Example”

Trang 25

Signature Examples

• TCP 139 and Out of Band

• SYN and FIN flag set

• GET cgi-bin /etc/passwd

– above general filter will pick up phf,

php and aglimpse common exploit

Very similar to anti virus products

This slide lists several signatures that an IDS could use to detect attacks For instance, if an IDS finds

a TCP/IP packet with the destination port 139 and with the Out of Band flag set, it might infer that the packet was launched by WinNuke or a similar attack program

Another common signature of an attack relies on both the SYN and the FIN flag being set at the same time The SYN flag is used to start a connection and the FIN is used to tear one down They shouldn’t both be set A surprising number of hacker programs do set them both, possibly to avoid loggers or filters that check for SYN only Those interested in learning more about this pattern might enjoy reading through the note at the very bottom of this slide

The two signatures above only concern themselves with packet header information, and fall under traffic or header analysis qualification On the other hand, if an IDS was configured to look for the presence of an expression such as “GET cgi-bin /etc/passwd” it would be looking at contents of the (presumably) HTTP packet In this case, the system would be performing content analysis.Note that presence of “cgi” and “/etc/passwd” in the HTTP steam generally indicates common exploits such of phf, php, and aglimpse, since it results from attackers attempting to exploit a CGI program to access the passwd file Your next slide talks a bit more about this pattern

Here is a note from http://www.l0pht.com/NFR regarding SYN|FIN packets:

external networks watcher - This backend watches for external IP addresses initiating connections

across your local wire Suppose you have an internal network setup where you allow people to initiate connections to the outside world but do not allow externally initiated connections to terminate

on internal machines (ESTABLISHED in cisco lingo, or maybe some stateful filter like FW1, or fil) Seeing TCP connections from external networks destined to internal machines with the SYN flag set in these situations would indicate a break in perimeter security In addition, packets with SYN and any other tcp flags set except for RST are flagged as well This is due to end systems handling them in different ways - to wit: Microsoft NT treats a SYN|FIN as a raw SYN and happily returns a SYN|ACK This should alert you of more sophisticated attempts to circumvent filters

Tiêu đề	Interoperability And Architecture
Trường học	SANS Institute
Chuyên ngành	Cybersecurity
Thể loại	Bài luận
Năm xuất bản	2001
Thành phố	Not specified

Định dạng
Số trang	50
Dung lượng	833,84 KB