CHAPTER

1
Introducing IDS and IPS

1. 1 Introducing IDS and IPS

Intrusion detection system (IDS) and intrusion prevention system (IPS) solutions form an integral part
of a robust network defence solution. Maintaining secure network services is a key requirement of a
profitable IP-based business. IDS and IPS work together to provide a network security solution. An
IDS captures packets in real time, processes them, and can respond to threats, but works on copies of
data traffic to detect suspicious activity by using signatures. This is called promiscuous mode. In the
process of detecting malicious traffic, an IDS allows some malicious traffic to pass before the IDS can
respond to protect the network. An IDS analyses a copy of the monitored traffic rather than the actual
forwarded packet. The advantage of operating on a copy of the traffic is that the IDS does not affect the
packet flow of the forwarded traffic. The disadvantage of operating on a copy of the traffic is that the
IDS cannot stop malicious traffic from single-packet attacks from reaching the target system before the
IDS can apply a response to stop the attack. An IDS often requires assistance from other networking
devices, such as routers and firewalls, to respond to an attack.
An IPS works inline in the data stream to provide protection from malicious attacks in real time. This
is called inline mode. Unlike an IDS, an IPS does not allow packets to enter the trusted side of the
network. An IPS monitors traffic at Layer 3 and Layer 4 to ensure that their headers, states, and so on
are those specified in the protocol suite. However, the IPS sensor analyses at Layer 2 to Layer 7 the
payload of the packets for more sophisticated embedded attacks that might include malicious data. This
deeper analysis lets the IPS identify, stop, and block attacks that would normally pass through a
traditional firewall device. When a packet comes in through an interface on an IPS, that packet is not
sent to the outbound or trusted interface until the packet has been determined to be clean.
The key to differentiating an IDS from an IPS is that an IPS responds immediately and does not allow
any malicious traffic to pass, whereas an IDS allows malicious traffic to pass before it can respond.

IDS:

Analyses copies of the traffic stream.

Does not slow network traffic.
Allows some malicious traffic into the network.
Shown in fig 1.1

IPS:
1|Page

Works inline in real time to monitor Layer 2 through Layer 7 traffic and content.
Needs to be able to handle network traffic.
Prevents malicious traffic from entering the network.
Shown in fig 1.2

Fig.1.1 Intrusion Detection System(IDS)

2|Page

Fig1.2- Intrusion Prevention System (IPS)

1.2 Common Characteristics

IDS and IPS technologies share several characteristics:
IDS and IPS technologies are deployed as sensors. An IDS or an IPS sensor can be any of the
following devices:
A router configured with Cisco IOS IPS Software.
An appliance specifically designed to provide dedicated IDS or IPS services.
A network module installed in an adaptive security appliance, switch, or router.
IDS and IPS technologies typically monitor for malicious activities in two spots:
Malicious activity is monitored at the network to detect attacks against a network, including
attacks against hosts and devices, using network IDS and network IPS.
Malicious activity is monitored on a host to detect attacks that are launched from or on target
mchines, using host intrusion prevention system (HIPS). Host-based attacks are detected by
3|Page

reading security event logs, checking for changes to critical system files, and checking system
registries for malicious entries.
IDS and IPS technologies generally use yes, signatures to detect patterns of misuse in network
traffic, although other technologies will be introduced later in this chapter A signature is a set of rules
that an IDS or IPS uses to detect typical intrusive activity. Signatures are usually chosen from a broad
cross section of intrusion detection signatures, and can detect severe breaches of security, common
network attacks, and information gathering.
IDS and IPS technologies look for the following general patterns of misuse:
Atomic pattern: In an atomic pattern, an attempt is made to access a specific port on a specific
host, and malicious content is contained in a single packet. An IDS is particularly vulnerable to
an atomic attack because until it finds the attack, malicious single packets are being allowed
into the network. An IPS prevents these packets from entering at all.
Composite pattern: A composite pattern is a sequence of operations distributed across
multiple hosts over an arbitrary period of time.

1.3 Steps Taken

The following are the steps that occur when an attack is launched in an environment monitored
by an IDS:
Step 1. An attack is launched on a network that has a sensor deployed in IDS mode.
Step 2. The switch sends copies of all packets to the IDS sensor (configured in promiscuous mode,
which is explained later in this section) to analyze the packets. At the same time, the target machine
experiences the malicious attack.
Step 3. The IDS sensor, using a signature, matches the malicious traffic to the signature.
Step 4. The IDS sensor sends the switch a command to deny access to the malicious traffic.
Step 5. The IDS sends an alarm to a management console for logging and other management purposes.
The following are the steps that occur when an attack is launched in an environment monitored
by an IPS:
Step 1. An attack is launched on a network that has a sensor deployed in IPS mode (configured in
inline mode, which is explained later in this section).

4|Page

Step 2. The IPS sensor analyzes the packets as soon as they come into the IPS sensor interface. The
IPS sensor, using signatures, matches the malicious traffic to the signature and the attack is stopped
immediately. Traffic in violation of policy can be dropped by an IPS sensor.
Step 3. The IPS sensor can send an alarm to a management console for logging and other management
purposes.
Management Console
A management console is a separate workstation equipped with software to configure, monitor, and
report on events.
Promiscuous Versus Inline Mode
A sensor can be deployed either in promiscuous mode or inline mode. In promiscuous mode, the sensor
receives a copy of the data for analysis, while the original traffic still makes its way to its ultimate
destination. By contrast, a sensor working inline analyzes the traffic live and therefore can actively
block the packets before they reach their destination

1.4 Advantages and Limitations

Table 1.1 Advantages and Limitations of Deploying an IDS in Promiscuous Mode

Advantage

Limitation

Deploying the IDS sensor does not

have any impact on the network (latency,
jitter, and so on).

IDS sensor response actions cannot stop the trigger

packet and are not guaranteed to stop a connection.
IDS response actions are typically better at
stopping
an attacker more than a specific attack itself.
IDS sensor response actions are less helpful in
stopping
email viruses and automated attackers such as
worms.
Users deploying IDS sensor response actions must
have a well thought-out security policy combined
with a good operational understanding of their IDS
deployments. Users must spend time to correctly
tune IDS sensors to achieve expected levels of
intrusion
detection.
Being out of band (OOB), IDS sensors are more
vulnerable
to network evasion techniques, which are the
process of totally concealing an attack.

The IDS sensor is not inline and,

therefore, a sensor failure cannot affect
network functionality
Overrunning the IDS sensor with data
does not affect network traffic; however,
it does affect the capability of
the IDS to analyze the data

5|Page

Table 1.2 Advantages and Limitations of Deploying an IPS in Inline Mode

Advantage

Limitation

You can configure an IPS sensor to perform a

packet drop that can stop the trigger packet, the
packets in a connection, or packets from a source
IP address.
Being inline, an IPS sensor can use stream
normalization techniques to reduce or eliminate
many of the network evasion capabilities that
exist.

An IPS sensor must be inline and, therefore, IPS

sensor errors or failure can have a negative effect
on network traffic.
Overrunning IPS sensor capabilities with too
much traffic does negatively affect the
performance of the network.
Users deploying IPS sensor response actions must
have a well thought-out security policy combined
with a good operational understanding of their IPS
deployments.
An IPS sensor will affect network timing because
of latency, jitter, and so on. An IPS sensor must be
appropriately sized and implemented so that timesensitive applications, such as VoIP, are not
negatively affected.

6|Page

CHAPTER

2
Host and Network IPS

IPS technology can be network based and host based. There are advantages and limitations to HIPS
compared with network-based IPS. In many cases, the technologies are thought to be complementary.

2.1 Host-Based IPS

HIPS audits host log files, host file systems, and resources. A significant advantage of HIPS is that it
can monitor operating system processes and protect critical system resources, including files that may
exist only on that specific host. HIPS can combine the best features of antivirus, behavioural analysis,
signature filters, network firewalls, and application firewalls in one package. A simple form of HIPS
enables system logging and log analysis on the host. However, this approach can be extremely labour
intensive.
For example, the Nimda and SQL Slammer worms did millions of dollars of damage to enterprises on
the first day of their appearance, before updates were even available; however, a network protected
with a CSA stopped these attacks without any updates by identifying their behaviour
as malicious. Host-based IPS operates by detecting attacks that occur on a host on which it is installed.
HIPS works by intercepting operating system and application calls, securing the operating system and
application configurations, validating incoming service requests, and analysing local log files for afterthe-fact suspicious activity.
More precisely, HIPS functions according to the following steps, as shown in Figure 2.1

Fig.2.1
Step 1. An application calls for system resources.
Step 2. HIPS checks the call against the policy.
7|Page

Step 3. Requests are allowed or denied.

HIPS uses rules that are based on a combination of known attack characteristics and a detailed
knowledge of the operating system and specific applications running on the host. These rules enable
HIPS to determine abnormal or out-of-bound activity and, therefore, prevent the host from executing
commands that do not fit the correct behavior of the operating system or application.
HIPS improves the security of hosts and servers by using rules that control operating system and
network stack behavior. Processor control limits activity such as buffer overflows, Registry updates,
writes to the system directory, and the launching of installation programs. Regulation of network traffic
can help ensure that the host does not participate in accepting or initiating FTP sessions, can rate-limit
when a denial-of-service (DoS) attack is detected, or can keep the network stack from participating in a
DoS attack.
The topology in Figure 2.2 shows a typical HIPS deployment.

Fig 2.2

HIPS deployment

2.1.1 The advantages and limitations of HIPS are as follows:

Advantages of HIPS: The success or failure of an attack can be readily determined. A network IPS
sends an alarm upon the presence of intrusive activity but cannot always ascertain the success or
failure of such an attack. HIPS does not have to worry about fragmentation attacks or variable Time to
Live (TTL) attacks because the host stack takes care of these issues. If the network traffic stream is
encrypted, HIPS has access to the traffic in unencrypted form.

8|Page

 Limitations of HIPS: There are two major drawbacks to HIPS:

HIPS does not provide a complete network picture: Because HIPS examines information
only at the local host level, HIPS has difficulty constructing an accurate network picture or
coordinating the events happening across the entire network.
HIPS has a requirement to support multiple operating systems: HIPS needs to run on every
system in the network. This requires verifying support for all the different operating systems
used in your network.

2.2 Network-Based IPS

Network IPS involves the deployment of monitoring devices, or sensors, throughout the network to
capture and analyze the traffic. Sensors detect malicious and unauthorized activity in real time and can
take action when required. Sensors are deployed at designated network points that enable security
managers to monitor network activity while it is occurring, regardless of the location of the attack
target. Network IPS sensors are usually tuned for intrusion prevention analysis. The underlying
operating system of the platform on which the IPS software is mounted is stripped of unnecessary
network services, and essential services are secured (that is, hardened). The hardware includes the
following components:
Network interface card (NIC): Network IPS must be able to connect to any network (Ethernet,
Fast Ethernet, Gigabit Ethernet).
Processor: Intrusion prevention requires CPU power to perform intrusion detection analysis and
pattern matching.
Memory: Intrusion detection analysis is memory intensive. Memory directly affects the capability of
a network IPS to efficiently and accurately detect an attack. Network IPS gives security managers realtime security insight into their networks regardless of network growth. Additional hosts can be added
to protected networks without needing more sensors. When new networks are added, additional sensors
are easy to deploy. Additional sensors are required only when their rated traffic capacity is exceeded,
when their performance does not meet current needs, or when a revision in security policy or network
design requires additional sensors to help enforce security boundaries. Figure 2.3 shows a typical
network IPS deployment. The key difference between this network IPS deployment example and the
previous HIPS deployment example is that there is no CSA software on the various platforms. In this
topology, the network IPS sensors are deployed at network entry points that protect critical network
segments. The network segments have internal and external corporate resources. The sensors report to
a central management and monitoring server that is located inside the corporate firewall.

2.2.1 The advantages and limitations of network IPS are as follows:

Advantages of network IPS: A network-based monitoring system has the benefit
of easily seeing attacks that are occurring across the entire network. Seeing the attacks
against the entire network gives a clear indication of the extent to which the
network is being attacked. Furthermore, because the monitoring system is examining only traffic from
the network, it does not have to support every type of operating
system that is used on the network.

9|Page

 Limitations of network IPS: Encryption of the network traffic stream can essentially blind network
IPS. Reconstructing fragmented traffic can also be a difficult problem to solve. Possibly the biggest
drawback to network-based monitoring is that
as networks become larger (with respect to
bandwidth), it becomes more difficult to place network IPS at a single location in the network and
successfully capture all the traffic. Eliminating this problem requires the use of more sensors
throughout the network. However, this solution increases costs.

Comparing HIPS and Network IPS

Table 2.1 compares the advantages and limitations of HIPS and network IPS.
HIPS

Advantages

Limitations

Is host specific

Operating system dependent

Protects host after decryption

Lower-level network events not

seen

Network
IPS

Provides application-level encryption

Protection

Host is visible to attackers

Cost-effective

Cannot

examine

encrypted

traffic
Not visible on the network

Does not know whether an attack

was successful

Operating system independent

Lower-level network events seen
Table 2.1Advantages and Limitations of Host-Based IPS and Network-Based IPS

10 | P a g e

A host-based monitoring system examines information at the local host or operating system. Networkbased monitoring systems examine packets that are traveling through the network for known signs of
intrusive activity. As you move down the feature list toward network IPS, the features describe
network-based monitoring features; application-level encryption protection is a HIPS feature, whereas
DoS prevention is a network IPS feature.

11 | P a g e

CHAPTER

3
Types of IDS and IPS Systems

Common Detection Methodologies

IDPS technologies use many methodologies to detect incidents. Sections 3.1 through 3.3 discuss the
primary classes of detection methodologies: signature-based, anomaly-based, and stateful protocol
analysis, respectively. Most IDPS technologies use multiple detection methodologies, either separately
or integrated, to provide more broad and accurate detection.

3.1 Signature-Based Detection

A signature is a pattern that corresponds to a known threat. Signature-based detection is the process of
comparing signatures against observed events to identify possible incidents.5 Examples of signatures
are as follows:

A telnet attempt with a username of root, which is a violation of an organizations security

policy

An e-mail with a subject of Free pictures! and an attachment filename of freepics.exe,

which are characteristics of a known form of malware

An operating system log entry with a status code value of 645, which indicates that the hosts
auditing has been disabled.

Signature-based detection is very effective at detecting known threats but largely ineffective at
detecting previously unknown threats, threats disguised by the use of evasion techniques, and many
variants of known threats. For example, if an attacker modified the malware in the previous example to
use a filename of freepics2.exe, a signature looking for freepics.exe would not match it.
Signature-based detection is the simplest detection method because it just compares the current unit of
activity, such as a packet or a log entry, to a list of signatures using string comparison operations.
Signature-based detection technologies have little understanding of many network or application
protocols and cannot track and understand the state of complex communications. For example, they
cannot pair a request with the corresponding response, such as knowing that a request to a Web server
for a particular page generated a response status code of 403, meaning that the server refused to fill the
request. They also lack the ability to remember previous requests when processing the current request.
This limitation prevents signature-based detection methods from detecting attacks that comprise
multiple events if none of the events contains a clear indication of an attack.

12 | P a g e

3.2 Anomaly-Based Detection

Anomaly-based detection is the process of comparing definitions of what activity is considered normal
against observed events to identify significant deviations. An IDPS using anomaly-based detection has
profiles that represent the normal behaviour of such things as users, hosts, network connections, or
applications. The profiles are developed by monitoring the characteristics of typical activity over a
period of time. For example, a profile for a network might show that Web activity comprises an
average of 13% of network bandwidth at the Internet border during typical workday hours. The IDPS
then uses statistical methods to compare the characteristics of current activity to thresholds related to
the profile, such as detecting when Web activity comprises significantly more bandwidth than expected
and alerting an administrator of the anomaly. Profiles can be developed for many behavioural
attributes, such as the number of e-mails sent by a user, the number of failed login attempts for a host,
and the level of processor usage for a host in a given period of time.
The major benefit of anomaly-based detection methods is that they can be very effective at detecting
previously unknown threats. For example, suppose that a computer becomes infected with a new type
of malware. The malware could consume the computers processing resources, send large numbers of
e-mails, initiate large numbers of network connections, and perform other behaviour that would be
significantly different from the established profiles for the computer.
An initial profile is generated over a period of time (typically days, sometimes weeks) sometimes
called a training period. Profiles for anomaly-based detection can either be static or dynamic. Once
generated, a static profile is unchanged unless the IDPS is specifically directed to generate a new
profile. A dynamic profile is adjusted constantly as additional events are observed. Because systems
and networks change over time, the corresponding measures of normal behaviour also change; a static
profile will eventually become inaccurate, so it needs to be regenerated periodically. Dynamic profiles
do not have this problem, but they are susceptible to evasion attempts from attackers. For example, an
attacker can perform small amounts of malicious activity occasionally, then slowly increase the
frequency and quantity of activity. If the rate of change is sufficiently slow, the IDPS might think the
malicious activity is normal behaviour and include it in its profile. Malicious activity might also be
observed by an IDPS while it builds its initial profiles.
Inadvertently including malicious activity as part of a profile is a common problem with anomalybased IDPS products. (In some cases, administrators can modify the profile to exclude activity in the
profile that is known to be malicious.) Another problem with building profiles is that it can be very
challenging in some cases to make them accurate, because computing activity can be so complex. For
example, if a particular maintenance activity that performs large file transfers occurs only once a
month, it might not be observed during the training period; when the maintenance occurs, it is likely to
be considered a significant deviation from the profile and trigger an alert. Anomaly-based IDPS
products often produce many false positives because of benign activity that deviates significantly from
profiles, especially in more diverse or dynamic environments. Another noteworthy problem with the
use of anomaly-based detection techniques is that it is often difficult for analysts to determine why a
13 | P a g e

particular alert was generated and to validate that an alert is accurate and not a false positive, because
of the complexity of events and number of events that may have caused the alert to be generated.

3.3 Stateful Protocol Analysis

Stateful protocol analysis is the process of comparing predetermined profiles of generally accepted
definitions of benign protocol activity for each protocol state against observed events to identify
deviations.6 Unlike anomaly-based detection, which uses host or network-specific profiles, stateful
protocol analysis relies on vendor-developed universal profiles that specify how particular protocols
should and should not be used. The stateful in stateful protocol analysis means that the IDPS is
capable of understanding and tracking the state of network, transport, and application protocols that
have a notion of state. For example, when a user starts a File Transfer Protocol (FTP) session, the
session is initially in the unauthenticated state. Unauthenticated users should only perform a few
commands in this state, such as viewing help information or providing usernames and passwords. An
important part of understanding state is pairing requests with responses, so when an FTP authentication
attempt occurs, the IDPS can determine if it was successful by finding the status code in the
corresponding response. Once the user has authenticated successfully, the session is in the
authenticated state, and users are expected to perform any of several dozen commands. Performing
most of these commands while in the unauthenticated state would be considered suspicious, but in the
authenticated state performing most of them is considered benign.
Stateful protocol analysis can identify unexpected sequences of commands, such as issuing the same
command repeatedly or issuing a command without first issuing a command upon which it is
dependent. Another state tracking feature of stateful protocol analysis is that for protocols that perform
authentication, the IDPS can keep track of the authenticator used for each session, and record the
authenticator used for suspicious activity. This is helpful when investigating an incident. Some IDPSs
can also use the authenticator information to define acceptable activity differently for multiple classes
of users or specific users.
The protocol analysis performed by stateful protocol analysis methods usually includes
reasonableness checks for individual commands, such as minimum and maximum lengths for
arguments. If a command typically has a username argument, and usernames have a maximum length
of 20 characters, then an argument with a length of 1000 characters is suspicious. If the large argument
contains binary data, then it is even more suspicious.
Stateful protocol analysis methods use protocol models, which are typically based primarily on
protocol standards from software vendors and standards bodies (e.g., Internet Engineering Task Force
[IETF] Request for Comments [RFC]). The protocol models also typically take into account variances
in each protocols implementation. Many standards are not exhaustively complete in explaining the
details of the protocol, which causes variations among implementations. Also, many vendors either
violate standards or add proprietary features, some of which may replace features from the standards.
For proprietary protocols, complete details about the protocols are often not available, making it
difficult for IDPS technologies to perform comprehensive, accurate analysis. As protocols are revised
and vendors alter their protocol implementations, IDPS protocol models need to be updated to reflect
those changes.
14 | P a g e

The primary drawback to stateful protocol analysis methods is that they are very resource-intensive
because of the complexity of the analysis and the overhead involved in performing state tracking for
many simultaneous sessions. Another serious problem is that stateful protocol analysis methods cannot
detect attacks that do not violate the characteristics of generally acceptable protocol behavior, such as
performing many benign actions in a short period of time to cause a denial of service. Yet another
problem is that the protocol model used by an IDPS might conflict with the way the protocol is
implemented in particular versions of specific applications and operating systems, or how different
client and server implementations of the protocol interact.

15 | P a g e

CHAPTER

4
Snort

4.1 What is SNORT?

Snort is an open source, cross-platform, software-based lightweight Network Intrusion Detection
System (NIDS) developed by Martin Roesch of Sourcefire. Snort is capable of performing real-time
traffic analysis and packet logging on IP networks. It can perform protocol analysis, pattern matching
and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans,
CGI attacks, SMB probes and OS fingerprinting attempts. Snort uses a flexible rules language to
describe traffic that it should collect or pass, and includes a detection engine utilizing a modular plugin architecture. Snort has real-time alerting capability as well, incorporating alerting mechanisms for
Syslog, user- specified files, a UNIX socket, or Win Popup messages to Windows clients using
Samba's smb client Suitable Plug-ins allows the detection and reporting subsystems to be extended.
Available plug-ins includes statistical anomaly detection, database logging, small fragment detection,
port scan detection, and HTTP URI normalization.
Snort can be configured to run in three modes. These are
Packet Sniffer
Snort's packet sniffing mode allows it to capture and display all network traffic to the administrator. It
provides you with the flexibility to display either the entire packet or only certain header information.
Packet Logger
Snort's packet logging mode performs the same functionality as the packet sniffing mode but creates a
traffic data file.
Network Intrusion Detection system
When ran in this mode, Snort is capable of detecting potential network intrusions using a rule-based
intrusion-detection mechanism.

4.2 Introduction to Snort Rules

16 | P a g e

Snort uses a simple, lightweight rules description language that is flexible and quite powerful.
There are a number of simple guidelines to remember when developing Snort rules that will
help safeguard your sanity. Most Snort rules are written in a single line. This was required in
versions prior to 1.8. In current versions of Snort, rules may span multiple lines by adding a
backslash \ to the end of the line.

Snort rules are divided into two logical sections, the rule header and the rule options. The rule header
contains the rules action, protocol, source and destination IP addresses and netmasks, and the source
and destination ports information. The rule option section contains alert messages and information on
which parts of the packet should be inspected to determine if the rule action should be taken.

alert tcp any any -> 192.168.1.0/24 111 \

(content:"|00 01 86 a5|"; msg:"mountd access";)
Figure 3.1: Sample Snort Rule

The text up to the first parenthesis is the rule header and the section enclosed in parenthesis contains
the rule options. The words before the colons in the rule options section are called option keywords.
All of the elements in that make up a rule must be true for the indicated rule action to be taken. When
taken together, the elements can be considered to form a logical AND statement. At the same time, the
various rules in a Snort rules library file can be considered to form a large logical OR statement.

17 | P a g e

Conclusion
There are many technologies in the market today to help companies fight the inevitable network and
system attack. Having IPS and IDS technologies are only two of many resources that can be deployed
to increase visibility and control within a corporate computing environment. IDS and IPS are to
provide a foundation of technology that meets the requirement of tracking, identifying network attacks
to which detect through logs of IDS systems and prevent an action through IPS systems. If the host is
with critical systems, confidential data and strict compliance regulations, then its a great to use IDS,
IPS or both in network environments. Intrusion types of systems are put in place to serve a business
needs for meeting an objective of network security. The IDS and IPS are to provide a foundation of
technology meets to tracking, identifying network attacks to which detect through logs of IDS systems
and prevent an action through IPS systems. If the host with critical systems, confidential data and strict
compliance regulations, then its a great to use of IDS, IPS or both in network environments. The basic
benefits of IDS and IPS systems are as:

Normal and intrusive malicious activities detected

Proactive protection of network security infrastructure
Operational efficiencies to reduced need to react to event logs for protection
Increased coverage against packet attacks and zeroday attacks

The deterministic intrusion detection or prevention is the next generation firewall with deep packet
inspection and sniffing in network. But it is not a silver bullet, to become a basic at the border and
deeper in the network for Defense in Depth.1

18 | P a g e

References
[1] J.P. Anderson, Computer Security Threat Monitoring and Surveillance, tech. report; James P.
Anderson Co., Fort Washington, Pa., 1980.
[2] D.E. Denning, An Intrusion Detection Model, IEEE Trans. Software Eng., Vol. SE- 13, No. 2,
Feb. 1987, pp. 222232.
[3] Jennifer Jabbusch , IDS vs. IPS: How to know when you need the technology, 22 November
2010
[4] Brian Smith, IPS vs. IDS.
[5] Robert Drum, IDS & IPS Placement for network protection , CISSP 26 March 2006.
[6] Pete Lindstrom, Intrusion prevention systems (IPS): Next generation firewalls , A Spire Research
Report March 2004 by, Spire Security.

19 | P a g e