unit 6 - intrusion detection & prevention systems trojans ...40001507/csn11111/unit6.pdf · the...

Network Security Intrusion Detection & Prevention Systems - Rich Macfarlane 1

Unit 6 - Intrusion Detection & Prevention Systems Rich Macfarlane

This unit introduces Intrusion Detection and Intrusion Prevention systems. This includes fundamental concepts, Intrusion Detection techniques, the active responses which Intrusion Prevention can add, Network-based and host-based systems, and centralised monitoring and management of these systems.

6.1 Introduction

Threats to an organisation traditionally came from untrusted external networks, but a large percentage of intrusions are now sourced from inside the organisation, as illustrated in Figure 1. Security, implemented with Perimeter Firewalls and VPNs can only mitigate threats originating in external networks. If threats come from inside the trusted network, then supplementary defences must be put in place in order to assist the system administrator identify these malicious activities. Intrusion Detection and Prevention Systems (IDPS) are examples of these detection security controls. Network firewalls typically only inspect traffic up to Layer 5, and sometimes to some extent Layer 7 – the application layer. They generally do not deeply inspect the application layer data however, and so struggle to defend against application layer threats such as malicious software. The firewall sees the traffic as valid traffic and may not detect the malicious application data content.

Users

Systems

Data

Data &

Identity Theft

Denial-of-Service

(DoS)

Destructive

Attacks

Malicious S/W:

Worms, Viruses,

Trojans, Rootkits

Hacktivists/

Terrorists?

Fraud &

Extortion

Corporate access

Email access

Network/Organisational

perimeter

Malicious

Employees

Ex-employees

Web access

Assets

Data Theft

Access

Abuse

Sabotage

Cyber Espionage/

Warfare

IDPS

IDPS Valid Traffic

Figure 1 Threats to the Organsisation

Intrusions

Intrusions, can be defined as activities, or events, which are malicious in nature, trying to upset normal operations, or gain unauthorised entry to systems. These events are deliberately trying to cause harm to a system. In the context of IDPS, these intrusions include both attacks on systems, which are successful, as well as unsuccessful attacks. Attacks which do not succeed in causing harm to the system are still important to the system administrator, to develop a comprehensive understanding of activities in the network.

Intrusions in the context of IDPS, can also describe misuse and abuse from inside users, including malicious activities and organisational policy breaches. Policy breaches could be as simple as unauthorised web use,


such as downloading music or the use of Instant Messenger (IM) applications from within the organisations network. Intrusion Detection Systems (IDS)

Intrusion Detection Systems (IDS) can help a system administrator keep track of the state of the trusted network, by monitoring events in a host system or network, and analysing them for signs of intrusions. Various IDS sensors can be placed around the network to monitor the network traffic and host systems, and look out for malicious activities. These, act a bit like the sensors of a burglar alarm system, when one is activated it sets off an alarm. This can indicate where the intrusion is in the building, but does not actually stop the burglars from making off with the loot. Similarly, the sensors of an IDS system raise an alarm, sometimes called an alert, when an intrusion is detected. Importantly, although the sensor raises an alarm it does not stop the attack or policy breach from proceeding. These alerts can be configured, by the system administrator, to do different things for different levels of intrusion. For example, log an alert locally – on the sensor, log to a central IDPS server or console, or even email/page the system administrator directly.

IDS is like a

Burglar Alarm

Intrusion

Detection

IPS is like a

Guard Dog

Intrusion

Prevention

Figure 2 IDS & IPS

Intrusion Prevention Systems (IPS)

An extension to the IDS is the Intrusion Prevention System (IPS), which also detects an intrusion in the same manner that IDS do. The main difference being, that an IPS can also generate an active response to the attack, stopping it before it succeeds in harming the system. For example, the IPS may automatically drop the offending packet, and terminate and the connection to the attackers machine. This can be compared to having an alarm system and a guard dog on the premises. The alarm sensors would detect the intrusion and raise the alarm, and the guard dog would attempt to prevent the burglars from stealing anything.

Another possible IPS response would be to change or clean the intrusion data, such as altering the offending network packets so they cannot do any harm; perhaps removing an email attachment to prevent a known piece of malware propagating. The IPS could also request changes to the security implemented in the network or host system, to prevent the attack in future, for example requesting the reconfiguration of a perimeter screening router, or changing a host’s firewall policy.


The term Intrusion Detection and Prevention Systems (IDPS) will be used throughout the chapter, to describe the combined technologies, and common functionalities.

History of Intrusion Detection and Prevention Systems

Intrusion Prevention is a fairly new technology which is still evolving, where Intrusion Detection has been around since the 1980’s and has evolved significantly over this time. In the early 1980’s it was identified, in a paper by James Anderson – Computer Security Threat Monitoring and Surveillance, that malicious events could be identified by analysing systems audit logs. This introduced the first ever host-based IDS, and the concept of an IDS for the very first time. In the mid-1980’s, Dr. Dorothy Denning at SRI International, created the first IDS system which analysed audit trails on mainframe computers – the Intrusion Detection Expert System (IDES). She published the seminal paper on IDS, ‘An Intrusion Detection Model’ in 1986, which laid the foundations for almost all of the work on IDS which has followed. At the same time the Haystack system, which compared audit data with pre-defined patterns, was being developed. The Haystack name came from the comparison of the task of audit data analysis, to looking for a needle in a haystack. The first Network Intrusion Detection System was developed by Todd Herberlein in 1990. It was called Network Security Monitor (NSM) and was deployed at government installations in the USA. It was different from the IDES and Haystack, as it analysed network traffic rather than system logs. NSM, along with the Haystack system, were the first commercial IDS products.

IDPS

IDPS

200019901980

Cisco

Purchase

Wheel Group

and

NetRanger

Security

Device

His

tory

Internet

< 1000

systems

Internet

> 100,000

systems

Internet

> 400 million

systems

Commercialisation

of the Internet

The Morris

Worm

1st Internet

Attack

Haystack

System

Lawrence

Livermore

Labs

‘Computer

Security Threat

Monitoring’

Paper

James

Anderson

Intrusion

Detection

Expert System

(IDES)

Dr. Dorothy

Denning – SRI

International

Network

Security

Monitor

(NSM) 1st

Network IDS

Todd

Heberlein

NetRanger

1st

Commercial

IDS Device

WheelGroup

RealSecure

Network

IDS Device

ISS

Network Flight

Recorder

(NFR)

Marcus

Ranum

Cisco

Purchase

Okena

Systems

StormWatch

IPS

Snort

Network

IDS

Martin

Roesch/

Sourcefire

Cisco

Purchase

Sourcefire

IPS

Figure 3 Intrusion Detection & Prevention System History

In the early 1990’s, the Automated Security Measurement System (ASIM) was developed to monitor network traffic on the US Air Force’s network. The development team responsible for this formed a company, The WheelGroup, and their product NetRanger, was the first commercial Network Intrusion Detection hardware device. Around the same time, Marcus Ranum, who developed the first commercial


firewall, created a commercial IDS called the Network Flight Recorder (NFR). By the late 1990’s popularity, and so revenues, started to increase for IDS. In 1997, the security market leader, Internet Security Systems (ISS) released RealSecure, a Network IDS, with limited IPS functionality, being able to stop some network traffic based on matching signatures. The following year Cisco, realising the importance of the growing IDS market, purchased the WheelGroup and rebranded their NetRanger product. Cisco also incorporated IDS functionality into the software on some of their routers. During this time some of the Haystack development team had created the Centrax Corporation company, and released the eNTrax host-Based IDS for Windows. The open source Network IDS Snort arrived in 1999, developed by Martin Roesch, and has become the one of the most widely deployed IDS worldwide. He also created the Sourcefire company which provides a commercial version of Snort and several highly rated IDPS appliances running software based on Snort. In 1999, Okena Systems created one of the first IPS’s called StormWatch. This was acquired by Cisco in 2003, and lead to the creation of the Cisco 4200 series IDPS network devices. Cisco have gone on to incorporate IDPS into their PIX/ASA security devices, and more recently were early adopters of IDPS running on switches. Over the last ten years several of the large security companies have made failed bids for Sourcefire and its Snort-based IDPS offerings. In July of 2013, Cisco succeeded, reportedly paying over $2.5 for the company. From a press release it seems that Cisco will attempt to integrate the Snort engine into their IPS offerings including built in ASA appliance IPS provision “Cisco intends to utilize the Snort engine and signature set as part of the ASA integrated IPS offers. This is in-line with the architectural evolution that was already planned as part of the Cisco platform evolution and is consistent with Cisco's commitment to growing the Snort open source community and Snort usage across the industry”.

Reasons for Intrusion Detection and Prevention Systems

Intrusion Detection and Prevention Systems are primarily used to detect malicious activities on a system, such as when an intruder has compromised a public facing web server in a company DMZ, or reconnaissance activities on a part of the trusted network, from a remote attacker on the Internet. The IDPS can then report these activities to the system administrator, who can possibly take actions to prevent the incident happening again. This reporting may be directly from the sensors to administrators, but more common is logging to a central system, with security event monitoring and analysis of the logs after the event. If an IPS is being used the intrusion could also be blocked automatically as well as being logged, for later analysis. IDPS monitoring can also act as a deterrent to employees, who might otherwise be tempted to violate aspects of the organisational security policy. For example, by running peer to peer file sharing software, or Instant Messaging (IM) applications. Internal and external users are also less likely to attempt to access unauthorised systems, or perform network scans if they know the organisation is using IDPS, the same way a burglar may be put off trying to break into a house if there is known to be an alarm installed. IDPS can also provide a measure of quality control on the security measures in place around an organisation. It could identify short comings with the current security policy, or its implementation. For example, a worm may be detected scanning the network from an end user machine which has been compromised because its virus software is not up to date. Or a network-based IDPS could identify an


intrusion which the firewall allowed through, due to a badly configured firewall policy. This is part of the auditing phase of the security life cycle.

6.2 IDPS Detection Intrusion Detection is the process of monitoring, analysing and auditing activities on computer systems or networks, to identify malicious events, or policy breaches. This was historically the job of the IDS, but all IDPS perform Intrusion Detection. IPS technologies are an extension of the functionality of IDSs. In addition to detection and reporting of suspicious events, IPS can attempt to respond directly to attacks or misuse. All IDPS log information relating to suspicious activities which they detect. The logs are written locally on the sensor itself, and possibly also to a central logging server (e.g. syslog server), or centralised security management system. These logs can be used to investigate the events in question, validating the intrusions, and also to correlate the events reported by this sensor and from others in the organisation.

·

Intrusion Detection

Prevention System

IDPS

IDPS

System or Network

Activities

Logs Alerts

IDPS Monitoring/

Management

Console

IDPS Logging

Server

Logs

Alerts/Events

System

Administrator

EmailRules &

Policies

Query

IDPS Sensor

Mobile SMS, Email Figure 4 IDPS Common Intrusion Detection Functions

IDPS can also inform system administrators directly about important detected security events. Detected activities can also be sent to a centralised monitoring console, to alert the system in real time. Alerting the system administrator can be done through various methods, including: the user interface of the IDPS itself, by email, SMS, by pager, through Simple Network Management Protocol (SNMP) messages, or syslog messages. Typically, the alert itself would not contain all the information concerning the activity in question. The system administrator may need to investigate further, and possibly react to the alert. The administrator may have to query the IDPS sensor, and pull details from the sensors logs to get the full information.


Reports can also be generated by the IDPS system, or a central monitoring and management system. These typically summarise the important, detected, activities, possibly highlighting potentially dangerous events. Typically systems now come with a range of predefined reports which can be created with minimal configuration.

Detection Alert Types

The ability of the IDPS Sensors to correctly detect malicious activities is crucial to the effectiveness of the

IDPS system as a whole. Table 1 defines the fours alert types which is the terminology typically used in the

description of events generated by IDPS. Describing the alert types in this way can be confusing, but to

simplify it can be thought of as: Positive/Negative means the alert has been raised/not raised, and

TRUE/FALSE if this was correctly/incorrectly generated.

A FALSE Positive can be defined as an alert which has been incorrectly raised, as there was in fact no

intrusion or malicious activity. This could be due to an IDS detection signature, which is too general in its

definition, or to some abnormal network traffic, which does not match an expected profile. A real world

example of a false positive would be the neighbours burglar alarm going off during the night due to the

wind, or a university fire alarm being set off by the dust produced by some workmen.

Table 1 IDPS Alert Types

Alert was Generated - Positive Alert was not Generated- Negative

Attack TRUE Positive. Attack occurs, and correctly alarm is raised/attack stopped.

FALSE Negative. Attack occurs, but incorrectly, no alarm is raised.

Not an Attack FALSE Positive. No Attack occurs, and alarm is raised in error.

TRUE Negative. No Attack occurs, and correctly no alarm is raised.

The accuracy of detection can be measured using the two sets of alerts generated; using the ratio of TRUE Positives vs FALSE Positives. The types of event detected and the accuracy of the alerts vary between systems. Some systems can use a variety of detection methods and correlate the alerts at a central point in the network, which can lead to more accurate detection of intrusions, but this comes with more complicated setup and tuning which can be expensive. However, IDPS will always need tuning to create an acceptable detection accuracy, i.e. keep the number of TRUE Positives high, and the number of FALSE Positives as low as possible. If more false positives are being generated than the security monitoring team can deal with important events may be missed. More important assets may have to take priority, and some events may have to be ignored. Other tuning and customisation, concerning usability and effectiveness, can also be done. Systems can have their detection and prevention actions tailored to different types or individual threats. For example, if a worm was detected, propagating itself via the network, the traffic could be blocked immediately, but for the detection of an employee breaking the organisations usage policy, by chatting to friends using an Instant Messenger application, logging the event may be all that is necessary.

Intrusion Detection Methods

Each sensor uses a specific method of performing the Intrusion Detection process. Sensors can be categorised by the method of intrusion detection they use. The main types of detection method are:

· Signature-Based Detection


· Anomaly-Based Detection

· Policy-Based Detection

Signature-Based Detection

Signature-based, also known as Misuse-based, or Knowledge-based is the most commonly used method of intrusion detection. A signature is a pattern which can be matched against activities which the IDPS is monitoring. Signature-based detection is the simplest type, as it compares a list of known signatures against an activity happening on the network or host system. For example, in a network IDPS a list of string signatures would be compared with the content of the packets flowing through the Sensor. If a signature matches the content of a packet, an alert would be generated. Signature-based detection is very effective at identifying known attacks, but has real problems detecting new threats. Its signature database has to be updated regularly, or these new attacks will not be detected. This updating of signatures is similar to the regular antivirus updates that are done on computers connected to the Internet, to keep the antivirus application up to date. Another issue is malicious activities over multiple events. An intruder could create a version of a known intrusion, but one which spreads itself out over time. The only way for the IDPS to identify this attack would be to cache session information and analyse it all together. Examples of signatures could be:

· The transferring of files via Instant Messenger File Transfer, which is a breach of the organisations Security Policy. Hex strings known to identify malware propagating on the network (shown in Figure 5).

Intrusion Detection

Prevention Sensor

IDPS

IDPS

System or Network

Activities

77 8E 4A BA 68

Logs Alerts

Detection Signatures

48 BA 5A E0 56

48 BA 5A E0 56

49 BA 5A E0 56

64 BA 5A E0 56

89 B3 DA 67 3E

77 8E 4A BA 68

Figure 5 Signature-Based Detection IDPD Sensor

Anomaly-Based Detection

This method, sometimes known as Behaviour-based, detects an intrusion based on abnormal activities on a system, or on the network. The sensor compares the activities currently occurring, against what is thought to be normal. A normal, or baseline profile is created by monitoring the behaviour of elements, over a period of time. This is known as a learning or ‘training’ period. The types of behaviour used to create profiles could be:


· User behaviour

· System CPU usage

· Type and number of system processes

· Number of network connections

· Network traffic types For example, in a user access network segment, the percentage of web traffic might be, on average, between 22% and 28% on weekday mornings. The IDPS Sensor can use statistical methods, to compare the actual percentage of web traffic with the baseline profile. If the percentage of web traffic is not within the bounds of the profile, an alert would be generated. This network-based profile example is illustrated in Figure 6. The main benefit of this anomaly-based system is that it can be effective at detecting new attacks. There are thousands of attacks, which are constantly being enhanced, as well as completely new attacks being created daily to exploit newly discovered vulnerabilities. For example a host system within the network is infected with a new type of Virus, and it starts to send emails to every person in the users address book. An anomaly-based sensor on the host might pick up the abnormal increase in CPU usage and an anomaly-based sensor on the network segment would pick up the sudden increase in email traffic, which would be different to the normal profile.

Intrusion Detection

Prevention Sensor

IDPS

IDPS

System or Network

Activities

DNS DNS DNS DNS DNS

Logs Alerts

Network Traffic Profile

We

b T

raffic

22

-28%

DNS DNS Web Email

Em

ail

4-9

%

AR

P 8

-12%

DN

S 3

-6%

Figure 6 Anomaly-Based Detection IDPS Sensor

There are problems with anomaly-based systems which have led to their limited use. It is difficult to create certain types of profiles accurately. For example, periodic activities such as weekly or monthly backups may not be included in the profiles. This would then lead to a very high rate of FALSE Positives being generated when these events occur. Anomaly-based systems typically generate a lot more FALSE Positives, and are generally significantly harder to tune than signature-based systems, especially in environments which have volatile network activity or host systems. For example, general use student network segments on a university campus. When the initial profiles are defined, it is done over a number of days, or even weeks. During this time intrusions may be inadvertently included in the profiles, which would lead to these attacks not being


detected when the system was up and running. Administrators would have to remove these manually from the profiles. Systems also have to recreate these profiles periodically, to keep them current, and this type of profile is known as a static profile. Another way of stopping the profiles from becoming inaccurate over time, is to use dynamic profiles. These change gradually with changing patterns of activities, over time. These are at risk from a clever attacker who could drip-feed malicious activities into the system, and increase the amount gradually, which would be incorporated into the dynamic profiles. Anomaly-based detection is an example of a closed security model, in that it allows only behaviour that is classed as normal, and raises an alarm if it doesn’t recognise activities. This is the opposite of the signature-based system, were all activities are implicitly allowed, except the known ‘bad activities’. Signature-based detection is an example of an open security model, which is generally regarded as a poor substitute for a closed model. Unfortunately, due to the number of FALSE Positives generated, they are less common than signature-based detection systems.

Signature-Based Detection

(Misuse Detection) This

attempts to model attacks on

a system as specific

patterns, and then monitors

for occurrences of these. Its

main disadvantage is that it

struggles to detect new

attacks.

IDPS Sensor

Anomaly-Based Detection

This assumes that abnormal

behaviour by a user can be

correlated with an intrusion.

Its advantage is that it can

typically react to new

attacks, but can often

struggle to detect variants of

known attacks, and can

generate a lot of FALSE

Positives. Another problem

is that the intruder can

evade detection by

mimicking the behaviour of

the user.

External hack

(scripted)

Data

TheftDenial-of-Service

Known

Viruses/Worms

External hack

(human)Fraud

IDPS

IDPS

IDPS

IDPS

IDPS

IDPS

New

Viruses/Worms

Figure 7 IDPS Detection & Attacks Mitigated

Stateful Protocol Analysis-Based Detection

Stateful Protocol Analysis Detection is sometimes included in the definition of Signature-Based Detection, but it is separated here to explain the detail. This type of detection is based around the standards for Protocols, as defined by the Protocol Vendors, or by accepted definitions of the protocols. The techniques used are similar to those in Stateful firewalls, which have Application Protocol Inspection functionality. This consists of, the tracking of connections, checking that protocols are being used in the standard way. Checking only the allowed commands are being used, and in the correct order, based on the protocols current state. The IDPS can perform a similar task, comparing current Application, Transport and Network layer protocol activity on the network, or system, with standard behaviour profiles for the protocols, supplied by their vendors. For example, if a protocol command was issued twice and the standard behaviour did not allow this, an alert would be generated (a sign of a possible DoS attack). Individual commands and parameters can also be validated, checking for type, and bounds checking values, to identify protocol misuse such as in buffer overflow attacks.


The problem with protocol analysis-based detection is the amount of resources needed to do the complex analysis, and to keep track of all the connections and their states. This is similar to Application Inspection Firewalls, in that the more inspection that is done, the slower the process is. Also, these systems cannot detect attacks if the intrusions are within the bounds of the protocol standard definitions.

Policy-Based Detection

Policy-based systems compare the activities being monitored with network security policy rules. If the activities being monitored are outside the rules of the policy, an alert can be generated. The security policy rules have to be created before the IDPS sensor can be implemented. This may require detailed research and investigation into the organisation and their network, and can be a difficult and time consuming task. This type of Detection is normally implemented using a hybrid system of signature and anomaly-based techniques, such as the Policy-based detection available in some Cisco IPS Sensors. IDPS can combine detection methods, to provide broad detection capabilities. Combining signature-based detection with stateful protocol analysis is common in many IDPS sensors. In Network IDPS it is now common to also incorporate some anomaly-based detection to analyse network protocols. For example, a stateful engine may parse traffic for connections, which are then analysed for anomalies as well as compared against signatures.

IDPS Prevention

Intrusion Preventions Systems (IPS) have grown out of IDS, and include all the characteristics of IDS, but take things a step further by including Intrusion Prevention. They can be distinguished from IDS by one important feature: they attempt to respond to the intrusion and stop the attack happening, rather than just monitoring and reporting the attack. An IPS is regarded as an IDS, allowing the monitoring for possible attacks, but with additional capabilities to respond to the attack while it is occurring; preventing its success.

Intrusion Response

In the event of malicious or unauthorised activity being detected, actions may be taken to correct or block the offending events. These counter-measures are known as an intrusion response. A response from an IDPS can be passive, active or a hybrid of the two. An active response takes action on the intrusion directly, hopefully stopping the malicious event which has been detected. A passive response logs the details of the possible intrusion and can also report this to an administrator (same as IDS response). A hybrid response would stop the intrusion, and also log and possibly notify an administrator. Responses for different types of IDPS are detailed in the next section.

6.3 Intrusion Detection & Prevention System Types

IDPS are categorised as either, Host-Based Intrusion Detection Systems (HIDS), Network-Based Intrusion Detection Systems (NIDS) or a Hybrid of the two systems. This is based on the source of the activities being monitored and audited.

Both Host-based, and Network-based, IDS and IPS are shown in Figure 8 below. Network-based systems monitor network traffic on network segments for malicious network activity. Examples are shown in Figure 8, on the DMZ, and both outside and inside the perimeter firewall.

Host-based IDPS monitor a single host for suspicious events on that host only, typically via audit data from the host OS. For example, running on user host machines, or on DMZ servers; as illustrated on the figure.


Untrusted

Internet

Email

server

Web

server

FTP

server

Bob

·

·

Trusted Internal

Network

DMZ

Intrusion

Detection

Network-Based

Intrusion Detection

System (NIDS)

Network-Based

Intrusion Detection

System (NIDS)HIDS

HIDS

Host-based

Intrusion Detection

System (HIDS)

Network-Based

Intrusion Prevention

System (NIPS)

Intrusion

Detection

Intrusion

Detection

Intrusion

Prevention

Host-Based


System (HIPS)

Eve

Intrusion

Prevention

Figure 8 Host-based and Network-based IDS

Network-based Intrusion Detection is a bit like keeping and analysing data about unusual post and parcels passing through the postal system, and reporting to the authorities about suspicious post to certain addresses. If someone receives malicious mail, the data can be searched to analyse the problem mail, and try to prevent it being delivered to the customer again. Network-based Intrusion Prevention is more like x-raying parcels at a sorting office; looking for malicious packages. If any are found, they can be opened and the problem object can be removed, or the parcel can be destroyed. A lot like the x-ray machines at airports scanning luggage for problem items, such as sharp objects, which can then be removed.


Host-based Intrusion Detection is like someone, vetting your mail for you at your office, and reporting possible misue of the organisations mail system, or non work related mail. Host-based Intrusion Prevention would be like somebody opening and vetting your mail, checking for malicious content, so the bad mail never reaches you.

Intrusion

Detection

Intrusion

Prevention

·

Untrusted

Internet

Email

server

Web

server

FTP

server

Bob ·

Trusted Internal

Network

DMZ

Intrusion

Detection

Network-Based

Intrusion Detection

System (NIDS)

Network-Based

Intrusion Detection

System (NIDS)HIDS

HIDS

Host-based

Intrusion Detection

System (HIDS)

Network-Based


System (NIPS)

Intrusion

Detection

Intrusion

Detection

Intrusion

Prevention

Host-Based


System (HIPS)

Eve

Intrusion

Prevention

NIDPS Monitors

Subnet

HIDPS Monitors

Host Only

Figure 9 Host-Based & Network-Based IDPS Coverage

As shown in the figure, network-based systems can monitor network traffic on entire network segments for malicious network activity, and host-based systems are restricted to the scope of a single system.

6.4 Network-Based IDPS Systems (NIDPS)

Components

Network-Based IDPS monitor and react to intrusions on a network segment, monitoring traffic to and from all hosts on that network segment. The components of a NIDPS system typically include network-based Sensors, and a central Monitoring and Management System. The Sensors are normally implemented as standalone IDPS network appliances, as IDPS hardware add-ons to another network devices (such as firewalls or routers), or as IDPS software installed on network devices or hardened host systems. The network appliance IDPS sensor would be composed of specialised hardware and software, optimised for IDPS processes. The IDPS software could be installed on hosts which met the specifications of the software.


These Sensors then send information about suspicious events, or intrusions, back to a central management server/database, and monitoring console(s). This centralised system can be used by system administrators to monitor and analyse this data. Responses can be taken, to mitigate the threats based on the type of malicious or unauthorised activity. Various types of IDPS Sensors and the central monitoring system can be seen in Figure 10. An example of an IDPS network appliance would be a Cisco IPS 4200 series sensor (1) or a Sourcefire FirePOWER IDPS device. An example of a hardware module for a network firewall, similar to the one illustrated in Figure 10 at the network perimeter, could be a Cisco ASA with Advanced Inspection and Prevention Security Services Modules (ASA SIP SSM). An example of IDPS software implemented on a host could be the open source Snort application software (2), running on a hardened Linux box. Components of a Network IDPS system:

· Network Sensors These monitor the different subnets around the network, and report the detected events.

· Central Monitoring/Management Console In an organisation there would typically be a central Monitoring Console, where the detected events can be sent, and administrators can monitor and correlate events from all over the network. The communication between the sensor and monitoring console or server is almost always encrypted. Sometimes only monitoring is performed, but management would be incorporated in larger implementations, possibly with one or more management consoles. Monitoring and management consoles can analyse the events and logging information coming from the sensors, and can provide correlation functionality. Correlation of events involves matching events from more than one sensor, such as suspicious activities logged from two different sensors from the same source IP Address. IDPS events can typically also be correlated with security events from other sources, such as firewall logging.

· Central IDPS Database Server A repository providing storage space for sensors and/or the management console to log to.

Untrusted

Internet

Email

server

Web

server

FTP

server

Bob

Trusted Internal

Network

DMZ

Intrusion

Detection

Network-Based

Intrusion Detection

System (NIDS)

Intrusion

Detection

Eve

Intrusion

Prevention

IDPS Monitoring/

Management

Console

IDPS Sensor

IDPS Sensor

IDPS Sensor

System

Administrator

Network-Based

Intrusion Detection

System (NIDS)

Network-Based


System (NIPS)

Figure 10 Network-Based IDPS Components


Sensor Deployment

The IDPS Sensors can be used to monitor network traffic at various places around the network. Five recommended places are:

· Outside the perimeter firewall (or as part of the screening router or perimeter firewall) Sensor can monitor and log all attacks coming from the external Internet.

· Directly behind perimeter firewalls Can monitor attacks from external Internet, which have breached the perimeter defences, possibly to problems with the perimeter firewall policy.

· On DMZ networks Sensors can protect the forward facing public servers, such as the e-commerce servers, and their applications.

· On backbone network Can monitor large amounts of network traffic crossing the internal network, and can detect attacks or policy breaches carried out by internal users.

· On critical network segments Sensor can monitor critical services, such as server farms, and by doing so concentrate the security efforts on the most important areas of the network.

Each sensor, although implemented on a single device, can monitor all the traffic entering or leaving the network segment. If a suite of sensors were to be used around the network, between them they should be able to monitor, and inspect all communications within the network. This is a more scalable solution than using host-based IDPS, as new hosts, servers, and network devices can be added to the network without the need for any extra IDPS Sensors to be installed. The NIDPS device, or host with software, can be stripped of any unnecessary services, hardening it against direct attacks. In some situations it can be deployed without a network address, in stealth mode, making it even more difficult for an intruder to find and compromise. Examples of network-based IDPS are Snort (2) Real Secure from ISS (3), CyberCop (4), Junipers IDP Series IDPS devices, and Cisco IDPS such as the IPS 4200 series hardware appliances, IPS hardware modules for routers and firewalls, and Cisco IPS Software running on Cisco Routers (1). Once the appropriate networks to monitor have been chosen, which type of sensor to deploy on each network segment should then be decided on. There are two main types of network-based sensor: Out-of-Line IDS Sensors, or In-line IPS Sensors.

Out-of-Line IDS Sensors

An out-of-line Intrusion Detection System Sensor, which is sometimes also called a Passive Sensor, works on copies of the network traffic. The sensor is said to work in Promiscuous Mode, as it monitors all the network traffic passed to its network interface, traffic to and from all hosts, not just the traffic addressed to the sensor itself. They work in real time, and can respond to attacks, but cannot stop the attack from proceeding. Figure 11 shows an attack from Eve, such as a spear phishing email from the Internet, aimed at infecting Bobs host machine within the trusted network. The attack has successfully evaded detection by the firewall and proceeds towards Bobs host system. A copy of the traffic is sent to the out-of-line IDS Sensor from the switch inside the trusted network. The passive IDS recognises the traffic as an attack and raises the alarm to the system administrator, who can respond to the attack. In this case the firewall policy could be reconfigured to stop future attacks of this type. Meanwhile, the attack has succeeded in reaching Bobs machine, and Bob experiences the attack.


Untrusted

Internet

Bob

Trusted Internal

Network

Network-Based

Intrusion Detection

System (NIDS)

Intrusion

Detection

Eve

IDPS Monitoring/

Management

Console

System

Administrator

3. Alert

1. Attack

4. Reconfigure

Firewall

2. Copy of

Trafiic

2. Attack Succeeds

Figure 11 Out-of-Line IDS Sensor

The out-of–line sensor can be connected to the network it is to monitor in several ways. The most popular are via a switch’s Mirroring/Spanning Port, or using a Network Tap. A spanning port is a port on a switch which can see all the network traffic crossing the switch. If a dedicated spanning port does not exist, a switch port can usually be configured to receive copies of all the other ports traffic. A network tap is a connection to the network cable itself, which would have to be installed. Deploying Passive Sensors, out-of-line, means there is little or no affect on the throughput of that part of the network. The reason for this is that the Sensor works on copies of the traffic, so it doesn’t affect the actual packet flow. Also, if the sensor fails, there would also be no affect on the network. The disadvantage to this offline IDS, is that the out-of-line Sensor monitoring copies of the traffic cannot take any immediate action, so the packets in this attack cannot be stopped. The sensor can respond by alerting a system administrator, or even directly requesting a configuration change to another security device, but this will not stop the attack which is already in progress. This may prevent that particular attacker or this attack in future, but not the current attack.

In-Line IPS Sensors

An In-line IPS Sensor, which is sometimes also called an Active Sensor, works on the actual network traffic. It is deployed so the traffic flows through the sensor, like a router or firewall. Many firewall devices can now contain IPS sensors, combining the two technologies. IPS In-Line Sensors can respond to attacks immediately, and stop the attack from proceeding any further in the network. This is done by dropping the packets found to contain malicious traffic, or cleaning the packets – removing the malicious part – before sending them on to their destination. IPS sensors are deployed, much like where firewalls would be deployed, at perimeters of networks or subnets; at the network choke points. Typically, they are positioned between internal networks, or at the network perimeter with the external Internet. An example of a Network IPS, deployed in-line would be an appliance based IPS product. These are deployed in-line with the network flow and so would have to process the appropriate amount of network traffic. Care is needed when selecting and tuning IPS sensors and has to be based on the maximum throughput needs of the network.


Untrusted

Internet

Bob

Trusted Internal

Network

Eve

IDPS Monitoring/

Management

Console

System

Administrator

3. Alert

1. Attack

Intrusion

Prevention

Network-Based


System (NIPS)

2. Packets

Dropped

Figure 12 In-Line IPS Sensor

In Figure 12 an attack is again launched from Eve, but this time an in-line IPS Sensor is in place. The IPS recognises the traffic as an attack and the active IPS can stop the attack getting any further, as it is in-line it drops the malicious packets, and it does not forward them to Bobs host machine. It then also raises the alarm to the system administrator for further analysis, and any manual response needed. Deploying Active Sensors, in-line, means there can be a negative effect on throughput of that part of the network (5). The sensor is in-line with the flow of traffic, as shown in Figure 11, and could be overrun with very high traffic loads. (attackers sometimes do this so they can sneak things past the sensor) If the sensor fails, there would also be an effect on the network, as opposed to the out-of-line solution. This means care has to be taken in the choice of IPS device size and capabilities, so they can cope with the traffic loads in the networks they are to be deployed in. With the Sensor being in-line, the big advantage is the ability to take immediate action, so packets of that specific attack could be stopped, the connection to the attacker could be blocked, or all traffic from the attacker could be blocked. The sensor can also respond by alerting a system administrator. This combination of responses can prevent the current attack, possibly that particular attacker, and possibly this attack/attacker in future. Table 2 In-Line vs Out-of-Line Sensors

Out-of-Line IDS In-Line IPS

Cannot stop the current attack, can only log details, and raise alarm, which may stop future attacks.

Can stop the current attack before it does any harm.

No performance impact on the network, as works on copies of the traffic.

Can have performance impact on the network, as traffic flows through the sensor.

No performance impact if the sensor fails. Can have performance impact if the sensor fails, would have to consider redundancy for this type of sensor.


Network-Based Detection Capabilities

Examples of Malicious Activities and Intrusions detected by Network-Based IDPS are list below, and are grouped by TCP/IP layers.

Application Layer

Application protocols can be monitored by network-based IDPS, remote access attacks, client side attacks using payloads such as buffer overflows, password cracking attacks, and malware propagation. Application protocols that typically would be monitored and analysed include: HTTP, DNS, FTP, DHCP, IRC, POP, SMTP, SNMP, SQL database protocols, and various peer to peer protocols.

Transport Layer

At the transport layer, the TCP and UDP protocols are monitored for reconnaissance attacks, access attacks, and DoS attacks. Examples include TCP or UDP port scans, TCP packet fragmentation attacks, and TCP SYN and ICMP flood attacks.

Network Layer

Typically, the IP and ICMP protocols are analysed at this layer, for attacks such as reconnaissance attacks, such as ICMP ping sweeps.

Network-Based Prevention Capabilities

Network-Based IDPS sensors can provide Prevention Responses to detected attacks. IDS can provide some responses, but not to stop the attack which triggered the response as they are out-of-line. IPS can provide immediate responses, and can stop the attack from progressing, as they are deployed in-line. Possible responses from IDPS sensors are listed below:

· End the current communication session with a potential attacker A passive or active IDPS Network-Based sensor can attempt to end the TCP session with the attacker, by sending TCP Reset (RST) packets to both client and server involved in the session. The idea is to kill the session before the attack has succeeded, but generally this is not as successful as dropping packets in-line.

· Reconfigure Other Network Security Devices A passive or active IDPS sensor can request changes to the configuration of security settings on other network devices, such as switches, routers, or firewalls. An example would be, reconfiguring a perimeter firewall to block all traffic from the attacker’s machine or subnet, or creating a quarantine VLAN for a compromised host machine, so it cannot infect other hosts on its subnet. (A VLAN is a virtual subnet to separate traffic, which can be configured on a switch)

· In-Line Firewalling In-Line IPS Sensors can block suspicious network traffic, at various levels. Drop all traffic from an attacker or their subnet. If the malicious activity is limited to certain application protocols only these could be blocked. Or if just the one communication session for a certain service was suspicious, then only this might be blocked.

· Clean Malicious Content An In-Line sensor can alter packets which contain malicious content. For example, a sensor could detect a suspicious email attachment, a SQL Injection attack, or a buffer overflow, and remove it from the network traffic. Typically Application Layer data might be sanitised in this way.

· Throttling Bandwidth In-Line IPS sensors can reduce the amount of bandwidth available to certain protocols if suspicious activities are detected. The sensor could limit the percentage of the bandwidth certain protocols could use. This could be used to mitigate DoS attacks, worm propagation (if worm generated traffic was saturating the network), and policy breaches, such as peer-to-peer applications.


Note that blocking attackers based on IP Source Address is not always successful, as an attacker can easily spoof different addresses. Similarly blocking services based on TCP/UDP port numbers can also be evaded easily by using alternative ports or different protocols.

6.5 Host-based IDPS Systems (HIDPS) Host-Based IDPS sensors reside on a single end user host or server, and monitor for malicious activities on that system only. They typically would be used to monitor critical servers as well as end user host machines. They can monitor activities in much greater detail than a network based system, identifying the files and processes involved in the malicious events on the actual hosts. Examples of activities monitored are network traffic for that host only, system logs, processes running on the host, system settings, and file accesses.

Components

Host–based IDPS sensors are normally implemented as software running on the protected hosts, and are often referred to as Agents. Each agent monitors a single host system for suspicious activities. In an enterprise environment, the sensors would send logging and event data to a central monitoring and management system when suspicious activities are detected, much like the network-based IDPS model. In a home, or small office situation they could be installed on stand alone systems. A network with host-based IDPS system sensors is shown in Figure 13.

Author: Rich Macfarlane

Untrusted

Internet

Email

server

Web

server

FTP

server

Bob

Trusted Internal

Network

DMZ

HIDS

HIDS

Host-based

Intrusion Detection

System (HIDPS)Intrusion Detection Intrusion

Prevention

Host-Based


System (HIPS)

Eve

HIDPS Agent

HIDPS Agent

HIPS

HIPS

IDPS Monitoring/

Management

Console

System

Administrator

Intrusion Detection

HIDPS Agent

Host-based

Intrusion Detection

System

Figure 13 Host-Based IDPS Components

Components of a Host-based IDPS system:

· Software Sensors (or agents) These monitor hosts around the network, analyse the detected events, logging and raising events to the central monitoring system.


· Central Monitoring/Management Console In an organisation there would typically be a central Monitoring Machine, where the detected events can be sent, and administrators can monitor and correlate events from different end user hosts and servers.

· Central IDPS Database Server A repository for sensors and/or the management console to log to.

Sensor Deployment

Host-Based IDPS can be deployed on:

· Servers Public facing servers in the DMZ segment, such as web servers or DNS servers, as well as internal servers, such as Database servers, could be protected with HIDPS software.

· End User Hosts HIDPS sensor software can help protect end users from attacks related to the host OS or applications like email and web browsers.

Host-based Sensors are normally deployed on public facing servers, and servers or hosts storing sensitive data, but are available to run on most Operating Systems, so could be installed on every host machine if necessary. Where and how many sensors are deployed would be based on many factors, such as: how important the data on the host is, the different OS’s installed on the hosts involved, and the cost of deploying, monitoring and maintaining the sensors. Host-based intrusion detection is better suited to combat internal threats because of its ability to monitor and respond to specific user actions and file accesses on the host machines. Many security computer threats come from within organizations, from many different sources, such as disgruntled employees, downloaded malware, advanced targeted attacks. They also have an advantage over network-based systems, in that they can analyse encrypted data, as the data is decrypted by the time it reaches the host. Attacks can often be hidden from network-based monitoring by encrypting the communications between attack and target systems, such as is often now the case with remote access malware communications.

Host-Based Detection Capabilities

Sensors can be split into three main types. Those which monitor network traffic, those which monitor host activities after the events have happened through analysis of changes to files and system resources, and those which alter the host architecture and can monitor the activities as they happen. Network traffic Analysis sensors are similar to the network-based sensors, except they would only monitor traffic for the host they are running on, via the hosts NIC rather than the entire subnet. For example, Snort can be set up as a host-based sensor, setting promiscuous mode off, which means only monitoring traffic addressed to and from the host it is running on. Figure 14 shows the two types of HIDPS which monitor files and system configurations changes after the event. System Integrity Verifiers (SIV), and Log File Monitors (LFM). A SIV creates signatures for important files periodically, so it can check for changes to the files. Typically hash values are created for each file, and then compared to the stored hash value, to check if files have changes. This could detect a Trojan or Rootkit being installed, on a host, in place of an important OS file. A good example would be the Tripwire (6), a file integrity checker system, which analyses file systems. Trip wire is shown in Figure 15; the rear window shows Tripwire Nodes view - showing the sensors on various devices, and the front window shows some of the rules used to monitor a specific server.


29/05/2008 19:57 603 zhp1020.log04/08/2007 12:00 337,920 zipfldr.dll21/07/2008 03:00 102,400 ZLhp1020.dll13/03/2008 15:46 53,248 zlib.dll21/07/2008 03:00 28,672 zlm.dll

Log file monitors (LFM)

System Integrity Verifier

These monitor log files

which are generated by

network services, and look

for key patterns of change.

Swatch is a good

example.

These monitor system

files to determine if an

intruder has changed them

(a rootkit or trojan). A good

example of this is

Tripwire. It can also watch

other key system

components, such as the

Windows registry and root/

administrator level

privileges for changes.

IDPS

IDPS

IDPS

IDPS

Figure 14 Host-Based IDPS - File Modification & Log File Analysis

Host-Based IDPS Sensor

Figure 15 Tripwire


Other file system monitoring can be done on attributes of files, for characteristics like ownership, file size, and file accesses. Log file analysis can be done by sensors, analysing the information on system events, such as services starting or ending, or the shutting down or restarting of the host machine. Audit logs can be analysed for signs of malicious activity, such as user authentication access attempts, and application configuration changes. The other type of Host-based IDPS agent monitors activities as they happen. Analysis of executing code is

one method which can stop attacks as they occur. Code could be run in a virtual environment before it is run

on the live system, to check it does not perform any malicious activities (a virtual sandbox). Signatures can

be used to detect attacks like buffer overflows or other access attacks, before the code is run. The sensor

can have profiles, which specify which applications can call other applications or have access to system calls.

This type of system is implemented using a shim; a layer of code installed to intercept executing code, and

decide whether it should be allowed to run or not. Figure 16 shows this architecture.

Cisco Security Agent (CSA ) host-based IDPS software can police a policy by allowing or rejecting access to

applications and system process calls in this way.

Alter Host Internal

Architecture

These use a Shim, a layer

of code installed between

other layers of code, to

analyse the data passed

between the layers of

code. An example of this

would be Cisco CSA.

Application

ApplicationsHost-Based

IDPS

Shim

Host-based

Intrusion Detection

System

IDPS

IDPS

File System

Resources

Operating

System

Resources

Network

Resources


Blocked

Request

Successful

Request

Rules &

Policies

Figure 16 Host-Based IDPS - Alter Host Internal Structure

A disadvantage of host-based IDPS is that it can be easier for an attacker to find and disable than a Network-based system. Network-based systems can be made to be invisible on the network, were as host-based sensor software is running on every host, and can be attacked directly, or affected if the OS is attacked. They can also be a drain on the performance of the system being monitored, and are limited to the host computers logging and auditing capabilities. HIDS are generally more expensive to deploy and maintain, as they have to be installed, monitored and managed on every host in a network, compared to a single NIDS per network.


Host-Base IDPS Prevention Capabilities

Responses to malicious activities by host-based IDPS Systems:

· Stop Code Executing Code Analysis techniques can stop malicious code from running, stopping attacks like malicious software or unauthorised applications which breach the organisations security policy.

· Block Network Traffic If a network analysis system is installed, the same prevention capabilities as network-based IPS can be used.

· Stop File System Activities If a code analysis or file system monitoring sensor is being used, files can be protected from inappropriate file accesses.

· Kill/Restart Suspicious Process Table 3 is a summary of the differences between Network-based systems and Host-based systems. Table 3 Network-Based IDPS vs Host-Based IDPS

Network-Based IDPS Host-Based IDPS

Can monitor an entire network segment, analysing traffic to and from all hosts (broad scope).

Monitors a single host (narrow scope).

More scalable, and cheaper to implement, due to single sensor monitoring many hosts.

Less scalable, and more expensive to implement, as one sensor per host needed.

Easier to implement. More complex to implement.

Better at detecting external attacks. Better at detecting internal attacks.

Operating System independent. Operating System dependent.

Cannot examine contents of encrypted traffic. Encrypted traffic is decrypted on host, so HIDPS can monitor it.

Cannot assess whether an attack is successful or not.

Can monitor, or stop, attacks on the host as they take effect.

6.6 Hybrid Systems Hybrid intrusion detection and prevention systems offer management, and alert notification from both network and host-based intrusion detection sensors. A Hybrid system might be used in an enterprise solution, and would provide the best from both types of system. Using a mix of vendors and network and host-based sensor agents can provide a comprehensive solution, with the host-based agents providing another chance to catch an intrusion if the network based sensors miss an event. A hybrid solution is shown below.



Untrusted

Internet

Email

server

Web

server

FTP

serverBob

Trusted Internal

Network

DMZ

Intrusion

Detection

Network-Based

Intrusion Detection

System

Network-Based

Intrusion Detection

System

HIDS

HIDS

Host-based

Intrusion Detection

System

Host-based

Intrusion Detection

System

Intrusion

Detection

Network-Based


System

Network-Based


System

Intrusion

Prevention

Intrusion

Detection

Intrusion

Detection

Intrusion

Prevention

Intrusion

Prevention

Host-Based


System

Eve

IDPS Monitoring/

Management

Console

System

Administrator

Figure 17 Hybrid IDPS System

6.7 IDPS Alert Monitoring and Event Management Alerts and logging data can be sent to a central IDPS server, and/or console, where the system administrator can monitor, validate, analyse and respond to the intrusion alerts raised. Events can be monitored in real time, by an administrator via a monitoring console(s), and a range of associated data would also typically be logged and used later to validate the security events, for deeper analysis, and to produce reports.

·

Intrusion Detection

Prevention System

IDPS

IDPS

System or Network

Activities

Logs Alerts

IDPS Monitoring/

Management

Consoles

IDPS Logging

Servers

Logs

Alerts/Events

System

Administrator

Rules &

Policies

IDPS Sensor

Archived Data

Reports

IDPS data can be sent to the central servers or console in-band, over the production network, or in larger organisations a separate security out-of-band (OOB) management network may be used. A less expensive


solution that a separate network is to use the existing network, but creating a virtual LAN (VLAN) to segregate security traffic. Depending on the number of sensors in use around the network, more than one central server and console may well be needed. For example, Cisco recommends 25 or less sensors per management console, but the numbers will depend on how many alerts the sensors are producing. If they are badly tuned, they could be producing a lot of unnecessary false positives, which would tend to consume more resources than necessary.

Untrusted

InternetEve

Email

server

Web

server

FTP

server

Bob

DMZ

Intrusion

Detection

Network-based

Intrusion Detection

System

Intrusion Detection

SystemHIDS

HIDS

Host-based

Intrusion Detection System (HIDS)

Host-based

Intrusion Detection System (HIDS)

Intrusion

Detection

System Admin

IDPS Server &

Monitoring

Console

System

Administrator

Intrusion

Detection

Figure 18 Central IDSP Monitoring System

Some sensors may also produce a large amount of alerts due to their location, such as the out-of-line IDS sensor in front of the firewall shown in Figure 18, and may need a separate monitoring console of their own. The reduction of FALSE Positives, by analysing the logs to help tune sensors, is another way the system administrator would use the monitoring and analysis system. Parsing and analysing the IDPS logs can be done with command line tools such as the Unix/Linux grep tool (7), which is fantastic for parsing text files, using pattern matching regular expressions. Many utilities with easy to use GUI front end can also be used to analyse the logs, such as general purpose tools like Splunk (8) or products created specifically for analysing IDPS sensor data, such as Cisco MARS, or ACID which can be used as a monitoring and analysis console for a variety of IDS Sensors. An example of a fully functional central monitoring system is the Cisco Monitoring, Analysis and Response System (MARS) (9). This is a network appliance based system which can receive security events from a variety of devices and hosts, from various vendors. It can then correlate events to isolate attacks, and suggest response actions.


System

Administrator

Figure 19 Cisco MARS

Cisco MARS also has an extensive range of reporting capabilities, including the following standard reports. A report is shown in the front window in Figure 19.

· 24 Hour Alarm Metrics

· 30 Day Alarm Metrics

· 30 Day Details: Alarm Destinations

· 30 Day Details: Alarm Source/Destination pairs

· 30 Day Details: Alarm Sources

· 30 Day Details: Alarms

· 30 Day Details: Alarms by Hour/Day

· 30 Day Details: Top 50 Alarms

· 30 Day Details: Top 50 Alarm Destinations

· 30 Day Details: Top 50 Alarm Source/Destination pairs

· 30 Day Details: Top 50 Alarm Sources

· 30 Day Alarm Summary

· Detailed Alarms By Sensor

A central monitoring and analysis server can easily be set up for open source sensors such as Snort, using a variety of products. An easy and cost effective solution is using a mySQL database, and a free console application such as Analysis Console for Intrusion

Databases (ACID) (10) or Basic Analysis and Security Engine (BASE). These are free to download, web-based front end monitoring


and analysis systems. The system administrator can then easily query the data and generate reports from the console system, as

shown in Author: Rich Macfarlane

System

Administrator

IDPS Sensor

Alerts/Events

Figure 20.



System

Administrator

IDPS Sensor

Alerts/Events

Figure 20 Snort Monitoring Console – BASE

6.8 References

1. Cisco. Cisco IPS. Cisco Web Site. [Online] Cisco.

http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/.

2. Snort. Snort. [Online] 2009. http://www.iss.net/.

3. ISS. ISS. [Online] http://www.iss.net/.

4. Cybercop Home Page. Cybercop. [Online] http://www.cybercop.co.uk/.

5. Performance Analysis of Network Based Forensic Systems for In-line and Out-ofLine Detection and Logging.

J. Graves, W.J. Buchanan, L. Saliou. 2006, Vol. 5th European Conference on Informational Warfare and

Security (ECIW).

6. Michael E. Whitman, Herbert J. Mattord. Principles of Information Security. 2007.

7. Grep for Windows. GNU. [Online] http://gnuwin32.sourceforge.net/packages/grep.htm.


8. Splunk. Splunk. [Online] http://www.splunk.com/.

9. Cisco . Cisco MARS. Cisco Web Site. [Online] Cisco.

http://www.cisco.com/en/US/products/ps6241/index.html.

10. CERT. ACID for Snort. ACID. [Online] CERT.

http://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html.

11. Carl F. Endorf, Eugene Schultz, Jim Mellander. Intrusion Detection & Prevention. s.l. : McGraw Hill, 2003.

12. Paquet, Catherine. Implementing Cisco IOS Network Security (IINS): Authorized Self-study Guide: CCNA.

s.l. : Cisco Press, 2009.

13. Tripwire. Tripwire. [Online] http://www.tripwire.com/.

14. A Taxonomy of Intrusion Response Systems. N. Stakhanova, S. Basu, J. Wong. 2007.

15. Active Response to Computer Intrusions. David Dittrich, Kenneth Himma. 2005.

16. Schneier, Bruce. Secrets and Lies - Digital Security in a Networked World. s.l. : Wiley, 2000.

17. —. Crypto-Gram Newsletter - May 15, 2000. Bruce Schneier. [Online] http://www.schneier.com/crypto-

gram-0005.html.

18. IETF. RFC 4890. IETF. [Online] http://www.ietf.org/rfc/rfc4890.txt.

19. Stuart McClure, Joel Scambray, George Kurtz. Hacking Exposed 6. s.l. : McGraw Hill, 2009.

unit 6 - intrusion detection & prevention systems trojans ...40001507/csn11111/unit6.pdf · the...

Documents