Tài liệu Intrusion Detection The Big Picture – Part II pdf

Trang 1

Trang 2

Introduction

• Introductory Example - Mitnick Attack

• Is There A Business Case For Intrusion

Detection?

• What We Will Cover in This Course

OK, after that brief message to Your Sponsors, let’s look at what we plan to cover in the rest of the

course

Trang 3

Intrusion Detection Roadmap

What are the pieces and how they play together

• Host-Based Intrusion Detection

– Unix

– WinNT, Win95, Win98

• Network-Based Intrusion Detection

– Shadow

– ISS RealSecure

– Cisco NetRanger

Before we can understand how intrusion detection fits into the Big Picture, we need to examine it in

more detail We’ll look at the differences between host-based and network-based intrusion detection

systems, and note their respective strengths and weaknesses Then we’ll see how popular examples

of both free and commercial ID implement these concepts

Trang 4

Intrusion Detection Roadmap (2)

• Honeypots

• Firewalls

– Proxy, State Aware, Filtering Routers

After we’ve examined the active defences of intrusion detection, we’ll look back at more passive

measures, namely firewalls and honeypots

(They can be called active defences because if you aren’t active in monitoring it’s output, it’s no

defense.) ;)

We’ll look at how intrusion detection systems interact with the different types of firewalls, and how

honeypots and ID play together

Trang 5

• Vulnerability Scanners

• Response, automated and manual

– Manual Response

• Emergency Action Plan, 7 Deadly Sins

• Evidence preservation - Chain of Custody

• Threat Briefing - Know your enemy

– Ankle Biters

– Journeyman Hackers/ Espionage

– Cyberwar Scenario

We’ll look at vulnerability scanners, and how you can scan your network before the bad guys do it

for you, and get a handle on specific risks

Then we’ll get into the exciting world of incident response, covering what to do when your intrusion

detection systems detect an attack in progress, or already completed (Incident response may be

exciting, but it’s seldom fun when it’s for real.)

And to round off the section, we’ll look at the different types of attacker you might find assailing

your network, and finish with a full-blown cyber-wargame

Trang 6

Using What We Have Learned

• Risk Assessment and Auditing

• Introduction to Risk Management

• Knowledge-Based Risk Assessment

• Online Auditing Tools

• Business Case for Intrusion Detection

– How All These Capabilities Work Together

• Future Directions

– Intrusion Detection in the Network

– Program-Based Intrusion Detection

In our last section, we’ll look at risk assessment, and then combine everything we’ve learned into a

revised business case Finally, we’ll glance at some of the trends in intrusion detection, and what the

playing field might look in 6 months or so (We won’t be brave enough to guess further than that)

Trang 7

In this course we’re going to examine the various types of security tools and look at particular

examples of them in some detail We obviously can’t cover all the products out there, as the security

industry is growing rapidly, but we will try to cover the best-known and most popular in each

category

There is no one product or product suite that solves every problem, so your organization will benefit

from your understanding of how these different components work together, and how to mix and

match them to provide the level of risk reduction you need

We’ll cover both free and commercial tools and we’ll show you where to get hold of them

(evaluation versions of the commercial tools are normally available) so you can try them yourselves

Trang 8

Processes

• 7 Steps to Security

• 5 Deadly Management Mistakes

• 6 Steps to Incident Handling

• Chain of Custody

• Knowledge-Based Risk Assessment

After that list of products, to remind you that security is a process, not a product, here are some of the

processes we’ll cover

Trang 9

The Hard Questions

(Why I wrote this overview course)

• What are the components of a full court

intrusion detection strategy?

– What do the various components do?

• Many IDS web sites never state what the infernal things do!

– How do we implement them?

• Where do the components fit in the “big

picture”?

To summarize the course in a single slide ☺, these are the questions we are trying to answer today

Trang 10

Introduction

• Introductory Example - Mitnick Attack

• Is There a Business Case for Intrusion

Trang 11

Host- and Network-Based Intrusion Detection

• Host-Based Intrusion Detection

In the second and largest section of the course, we’ll examine intrusion detection in greater depth

We’ll examine and compare host-based and network-based intrusion detection and their relative pros

and cons

Vendors of host-based intrusion detection will tell you host-based is the only way to go to handle

high traffic and insider threats, while network-based vendors will claim network-based intrusion

detection is more cost effective Many vendors’ products now include both host- and network-based

components, and those vendors of course say you need both

Trang 12

Host-Based Intrusion

Detection

Host-based intrusion detection could also be called host-specific intrusion detection, in that its

primary purpose is to detect suspicious activity or known attack patterns on the specific host it is

installed on

Some host-based intrusion detection systems (HIDS) have a number of host detectors reporting to a

central management console that can flag alerts, centralize logs, and update the host detectors’

policies Other HIDS are stand alone

The boundaries between HIDS, anti-virus packages, and personal firewalls are blurring

Trang 13

Need for Host-Based ID

• Very fast networks

• Switched networks

• Back doors in local network

• Insider on network

• Network-based IDS may miss attack

• Don’t trust corporate security that much

Speed and the visibility limitation of switched and encrypted networks are network intrusion

detection systems’ biggest limitations We’ll examine them in a bit more depth in the next two slides

Host-based intrusion detection can be very valuable in detecting back doors into your network, such

as unsecured modems or links from other organization units or business partners It’s no good relying

on your network sensors that watch your front door if the back door is wide open

Another aspect of host-based intrusion detection is that it can catch insider attacks that don’t cross

the network or don’t pass through the instrumented perimeter Network-based systems can miss

some sophisticated attacks - for example, fragrouter – that HIDS will detect

Finally, HIDS have a lower cost of entry down to the level of protecting a single person or home PC

for $50, versus the $10,000 or so for commercial network intrusion detection systems (NIDS) They

also do not require a dedicated machine

Trang 14

Very Fast Networks

• The current limits for network-based

IDS boxes are about 80 MB/sec fully

loaded

• A 200 MHz Pentium bus would only

partially increase this

• Bandwidth at large sites will probably

always exceed network detection and

processing speed

There will always be a finite limit to the speed a network-based intrusion detection system can

operate, and it will always be possible to engineer a network that confounds network-based intrusion

detection technology Therefore, host-based ID will be an important player for the long haul

High bandwidth is a major challenge for NIDS Be wary of taking that 80Mbps as a solid number,

since it is based on assumptions of packet size and the number and complexity of the filters Once a

sensor’s bandwidth limit is exceeded, it’s performance tends to degrade rapidly, not just discarding

excess packets, but thrashing from resource exhaustion Graceful degradation into “statistical

sampling” is desirable

A response to the bandwidth limits of network sensors is to move the sensors upstream towards the

leaf nodes of your network, trading multiple sensors for less bandwidth per sensor One can view

HIDS as this trend taken to its logical conclusion but beware that you have traded your bandwidth

problem for a deployment problem

Trang 15

Switched Networks

• Network-based intrusion detection

systems rely on promiscuous mode for

their NICs; this is not possible with

switched networks

• Intrusion detection in the switch is the

future direction, not really here yet

• Host-based is one reasonable solution

Promiscuous mode allows the network interface adapter to collect all the packets, not just the ones

addressed to the machine Until switched networks, this was a very efficient way to collect packets

While switched networks are seen as a win for security in terms of reducing the sniffer threat, they

do greatly reduce the potential for “white hat” sniffing, that is, network intrusion detection Be aware

that switched networks do not entirely remove the sniffer threat, since there are techniques to kick a

switch into broadcast mode or reroute data streams past the sniffer, for example dsniff’s arpredirect

tool

Trang 16

Switched Network

In a switched network, a virtual circuit is created between two

peers across the switch fabric Each port on the switch only

supports the circuits to that host

Because of the virtual circuit, a network-based IDS with a promiscuous interface will not detect

much

Similar to switched networks in terms of the problems they cause for network intrusion detection are

VPNs and other encrypted channels In this case, the only possible place to put a sensor is at one end

of the encrypted channel, that is a host-based solution (attackers use encrypted channels for precisely

this reason, that is, to hide from network intrusion detection)

Trang 17

The are many problems with spanning port as a solution to support network-based IDS One major

vendor’s switch will only span a single VLAN at a time Spanning also may affect the performance

of the switch

The other problem with using a spanning port is that frequent network changes can often disrupt

spanning port settings This would typically be caused by a network engineer being unaware of the

spanning port’s purpose or the intrusion detection sensor’s presence Of course, the first you know of

the problem is when you notice that the sensor isn’t reporting any detects This is a problem with

many current intrusion detection systems, namely that they don’t see “no traffic” as an error

condition worth reporting, but merely fail silently unless connectivity to the management station is

lost

Switch vendors are becoming more aware of the requirements of intrusion detection and in some

cases are building network intrusion detection capabilities into the switch itself

Trang 18

Host-Based Intrusion Detection Methodology

• Host systems monitor their network

connections and file system status For this

to work, we have to acquire the aggregate

logs of ALL critical systems at a minimum

• Local processing/alerting may be done, but

data is generally sent to a central location for

Your core servers, perimeter servers, firewalls, web servers, DNS servers, and mail servers are the

obvious first choice for deployment While it would be desirable to roll out host intrusion detection to

all systems throughout the organization, the costs are usually prohibitive for commercial intrusion

detection systems Typical costs range from $50 to $500 per host This makes the tradeoff ratio

around 20 to 200 host intrusion detection systems for the cost of a single network sensor

The other issue influencing the deployment decision is that the more frequently a host is

reconfigured, the more false positives the intrusion detection system will generate Unless

configuration management is one of your tasks, you generally only want to monitor stable servers,

not test or development systems that change frequently

Trang 19

Host-Based Intrusion Detection Methodology

A connects

to B

B logs connection and informs Logserver

Logserver records

A -> B connection, checks ruleset, A-> B

is OK, waits.

It is a Good Idea™ to write (or copy) the logs on a different computer than the system creating

them This way, if that system falls, it is harder for the attacker to cover his tracks In fact, this

attribute of network intrusion detection is often cited as a selling point This makes it harder for the

attacker to tamper with the evidence of the attack (of course, Unix σψσλογhas been doing this for

years)

Central secure log servers and remote consoles are important features allowing widespread

deployment while retaining central management capability A sophisticated attack on a server

defended by HIDS would involve a denial of service attack on the log server, so it’s worth

considering having additional measures - such as a single network intrusion detection sensor

watching your log server or having your security management servers behind an internal firewall

Trang 20

Unix Host-Based Intrusion Detection

• TCP Wrappers

• Syslog

• Tripwire

• CMDS

OK, enough theory, let’s look at some of the popular host-based intrusion detection tools We first

look at Unix tools, before doing Windows

Trang 21

With this package you can monitor and filter incoming requests for the SYSTAT, FINGER, FTP,

TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other network services The package provides

tiny daemon wrapper programs that can be installed without any changes to existing software or to

existing configuration files The wrappers report the name of the client host and of the requested

service; the wrappers do not exchange information with the client or server applications, and impose

no overhead on the actual conversation between the client and server applications

Wietse Venema’s TCP Wrappers, now in version 7.6, is a first line of defense It is free and often

included as part of more recent UNIX and Linux versions

Without TCP Wrappers, all incoming TCP requests are serviced without question TCP Wrappers

allows your system to be more selective about who connects to it and adds a very valuable logging

service Many personal firewalls currently on the market have identical functionality, merely ported

to Windows

Trang 22

Check ACL Call Inetd

In this example, an FTP request (which is TCP port 21) comes to our system with host-based

logging TCP Wrappers first prepares to log that the packet arrived with a time stamp and the

destination host Then it checks its Access Control List, (ACL pronounced ACK ull), to see if it will

allow the connection If so, it wakes up the FTP daemon and lets it process the request If the ACL

doesn’t allow the connection (based on source IP), the connection is dropped and the event is logged

Trang 23

Host Deny

• ALL : ALL

• # Deny everything, add back with

/etc/hosts.allow

This is TCP Wrappers’ default setting in the /etc/hosts.deny file, a suitably paranoid “deny

everything not expressly permitted” (this is always a good starting point for a security policy) You

specifically permit allowed services and trusted sources in the /etc/hosts.allow file

Trang 24

In this example, we are saying for ALL services, let nnnn.abc.org, 192.168.2, and

friend.somewhere.edu have access For the secure shell, we list a specific host that we trust

Notice that the hosts.allow file takes precedence over the hosts.deny If hosts.deny has a deny

everything policy, and hosts.allow has an allow everything policy, the system is wide open Many

security rule sets have these sort of counterintuitive “gotchas” Remember, configuration errors are a

leading cause of security breaches

Trang 25

The default for wrappers is to do both a forward and reverse lookup and if they do not match, not to

allow the connection We are often playing games with DNS and get burned by this several times a

year, so it certainly works ☺

This will pick up DNS transient attacks, like cache poisoning, but won’t detect a social engineering

attack on a registrar who doesn’t correctly authenticate domain changes

Trang 26

Paranoid mode

• Default for TCP Wrappers

– Checks both forward and reverse lookup

– Both answers must match or connection is

dropped – Adds a layer of security against spoofing

This certainly works because we play tricks with DNS in certain aspects of Shadow and we get

burned by this all too often Paranoid mode DNS checking is strongly recommended - although this

will block sites that aren’t in the DNS, for example corporate firewalls, so YMMV*

*Your Mileage May Vary

Trang 27

A

In this example, the attacker does not match an ALLOW (and everything matches DENY ALL

:ALL), so the connection is dropped and the attempt logged

The TCP Wrappers ACL can have different allowed and denied addresses for each service (FTP,

Telnet, etc.) or it can have generic permissions for all services

Trang 28

Psionic Port Sentry

(TCP Wrappers with an attitude)

http://www.psionic.com/abacus/portsentry

· Runs on TCP and UDP

· Stealth scan detection for Linux

· SYN/half-open, FIN, NULL, X-MAS and oddball packet

stealth scans

· PortSentry will react to a port scan attempt by blocking

the host in real-time

· Will remember hosts that connected previously

From the SANS Securing Linux Step by Step consensus project:

[Bill Lavalette] “ *** Psionic Port Sentry : is by far one of the best intrusion detection mechanisms

Port sentry automatically detects all types of port scans, from basic to stealth, dumping the hostile

host into host deny It can also redirect the host to limbo, a bogus route is added and if your using a

linux firewall actively add firewall rules regarding the hostile host Gentlepeople, I swear by three

things: tcp wrappers, portsentry, and common sense We have had a Linux 5.2 box with everything

from a "nukes, land teardrop, boink, etc to nmap scans to exploits” Basically, as soon as an

unauthorized host tries anything, it is automatically put into host deny, I am mailed with the event,

and log entry is generated This is a very simple program to install; when combined with the above

precautions, it would be extremely hard to beat.”

Xmas scans are scans by packets with six TCP flags set, that is URG, ACK, TSH, RST, SYN and

FIN Null packets have no flags set All of these odd packets attempt to be stealthy by being rejected

by the TCP/IP stack instead of being logged Even if they are dropped, they will cause ICMP port or

service unavailable messages

Trang 29

Psionic Port Sentry

Jul 3 11:30:20 shepherd portsentry[418]:

attackalert: SYN/Normal scan from host:

node10453.a2000.nl/24.132.4.83 to TCP port: 143

attackalert: Host 24.132.4.83 has been blocked via

wrappers with string: "ALL: 24.132.4.83"

attackalert: Host 24.132.4.83 has been blocked via

dropped route using command: "/sbin/route add –host

24.132.4.83 gw 333.444.555.666"

Psionic Port Sentry combines host intrusion detection with automated response The first log entry

shows Port Sentry detecting an IMAP scan; the second entry shows it adding a “deny all” rule for all

traffic from that address; in the last log entry, it “blackholes” that address by insuring the system has

no route back to the offending address by setting a bogus route This won’t stop incoming packets

from the offending address, but it will prevent any replies ever getting back

These sorts of automated responses should be used with care to prevent an attacker tricking the

system into a self-inflicted denial of service on important connections An attacker could do this by

spoofing the source addresses of hostile probes to match the addresses of trusted partner sites

Trang 30

Syslog

• TCP Wrappers logs to syslog by default

• Unix system logger can be on local

system or other system

• Swatch or other tools can monitor

syslog and raise alerts

Syslog is the original distributed logging system found on all Unixes By itself it can detect a lot of

suspicious behaviour if correctly configured There are lots of tools to help monitor logs and fire off

alerts when selected events occur or thresholds are exceeded

Unfortunately, the completeness of the logs can be suspect, as attackers’ rootkits have specific tools

to selectively clear them, or trojan versions of syslog that turn a blind eye to the attacker’s activity

This is a major reason for logging to a different machine Even if all logs are suspect after the rootkit

install, the remote logserver should hold the original logs of the intrusion, at least until the attacker

comes after your logserver

Trang 31

Syslog Example

Nov 13 01:28:36 ns1 named[22988]:

unapproved AXFR from [192.168.1.2].3209 for

abc.nnnn.org

Nov 13 01:28:36 ns2 named[89]: unapproved

AXFR from [192.168.1.2].3250 for

abc.nnnn.org

These are just the form of log entry one finds in syslog sent by TCP Wrappers You can configure

wrappers to write in a different log facility, but syslog works just fine

The above trace is an example of syslog trying to be helpful Instead of just logging a tcp connection

to port 53, it uses it’s partial understanding of DNS to give a more informative log message, here a

DNZ zone transfer (AXFR)

This could be annoying if you’d just wanted to grep (search) the log for a set of high-threat ports, e.g

21, 23, 25, 53, 143, 151…

Trang 32

Syslog example (2)

pathname too long:

This trace was sent to the SANS mailing list by an alert system administrator during November 1999

Have you encountered attacks or attempted attacks of the Buffer Overflow type on automount

processes with the name "Privet ADMcrew" ?

This was the first time I ever saw this particular trace, but there are a number of “ADM” exploits If

you have a trace to share, please send email to intrusion@sans.org

Trang 33

TCP Wrappers Threatlist

"Outsider attack from network

• Outsider attack from telephone

"Insider attack from local network

• Insider attack from local system

• Attack from malicious code

Of our five example attack vectors, these are the ones that TCP wrappers would be effective against

Tiêu đề	Intrusion detection the big picture – part ii
Tác giả	Stephen Northcutt
Trường học	SANS Institute
Chuyên ngành	Intrusion Detection
Thể loại	Bài giảng
Năm xuất bản	2001
Thành phố	Not specified

Định dạng
Số trang	66
Dung lượng	1,52 MB