Cyber Security Notes Unit 4 for Engineering

lOMoAR cPSD|5407349
UNIT IV INTRUSION DETECTION
Host -Based Intrusion Detection – Network -Based Intrusion Detection – Distributed
or Hybrid Intrusion Detection – Intrusion Detection Exchange Format – Honeypots –
Example System Snort.
Host -Based Intrusion Detection
Host-based IDSs (HIDSs) add a specialized layer of security software to vulnerable
or sensitive systems; such as database servers and administrative systems. The HIDS
monitors activity on the system in a variety of ways to detect suspicious behaviour. Its
main purpose is to detect intrusions, log suspicious events, and send alerts.
The primary benefit of a HIDS is that it can detect both external and internal
intrusions, something that is not possible either with network-based IDSs or firewalls. As
we discuss in the previous section, host-based IDSs can use either anomaly or signature
and heuristic approaches to detect unauthorized behaviour on the monitored host. We
now review some common data sources and sensors used in HIDS, and then continue
with a discussion of how the anomaly, signature and heuristic approaches
are used in HIDS, and then consider distributed HIDS.
Data Sources and Sensors
A fundamental component of intrusion detection is the sensor that collects data.
Some record of ongoing activity by users must be provided as input to the analysis
component of the IDS.
Common data sources include:
 System call traces: A record of the sequence of systems calls by processes on a
system, is widely acknowledged as the preferred data source for HIDS since the
pioneering work of Forrest [CREE13]. While these work well on Unix and Linux
systems, they are problematic on Windows systems due to the extensive use of
DLLs that obscure which processes use specific system calls.

lOMoAR cPSD|5407349
 Audit (log file) records1 Most modern operating systems include accounting
software that collects information on user activity. The advantage of using this
information is that no additional collection software is needed. The disadvantages
are that the audit records may not contain the needed information or may not
contain it in a convenient form, and that intruders may attempt to manipulate these
records to hide their actions.
File integrity checksums:
A common approach to detecting intruder activity on a system is to periodically
scan critical files for changes from the desired baseline, by comparing a current
cryptographic checksums for these files, with a record of known good values.
Disadvantages include the need to generate and protect the checksums using known good
files, and the difficulty monitoring changing files. Tripwire is a well-known system using
this approach.
Registry access:
An approach used on Windows systems is to monitor access to the registry, given
the amount of information and access to it used by programs on these systems. However
this source is very Windows specific, and has recorded limited success.
The sensor gathers data from the chosen source, filters the gathered data to remove
any unwanted information and to standardize the information format, and forwards the
result to the IDS analyzer, which may be local or remote.
1. Anomaly HIDS
2. Signature or Heuristic HIDS
3. Distributed HIDS
Three main components:
1. Host agent module
2. LAN monitor agent module
3. Central manager module

lOMoAR cPSD|5407349
The LAN monitor agent also supplies information to the central manager. The LAN
monitor agent audits host-host connections, services used, and volume of traffic. It
searches for significant events, such as sudden changes in network load, the use of
security-related services, and suspicious network activities.
The architecture depicted in Figures 8.2 and 8.3 is quite general and flexible. It
offers a foundation for a machine-independent approach that can expand from stand-alone
intrusion detection to a system that is able to correlate activity from a number of sites and
networks to detect suspicious activity that would otherwise remain undetected.
_____________________________________________________________________

lOMoAR cPSD|5407349
Network -Based Intrusion Detection:
A network-based IDS (NIDS) monitors traffic at selected points on a network or
interconnected set of networks. The NIDS examines the traffic packet by packet in real
time, or close to real time, to attempt to detect intrusion patterns. The NIDS may
examine network-, transport-, and/or application-level protocol activity.
Types of Network Sensors
1. An inline sensor
2. A passive sensor
A common location for a NIDS sensor is just inside the external firewall (location 1 in the
figure).
This position has a number of advantages:
 Sees attacks, originating from the outside world, that penetrate the network’s
perimeter defenses (external firewall).
 Highlights problems with the network firewall policy or performance.
 Sees attacks that might target the Web server or ftp server.
 Even if the incoming attack is not recognized, the IDS can sometimes recognize the
outgoing traffic that results from the compromised server.

lOMoAR cPSD|5407349
NIDS Sensor Deployment
Consider an organization with multiple sites, each of which has one or more LANs,
with all of the networks interconnected via the Internet or some other WAN technology.
For a comprehensive NIDS strategy, one or more sensors are needed at each site. Within a
single site, a key decision for the security administrator is the placement of the sensors.
The advantages of this approach are as follows:
 Documents number of attacks originating on the Internet that target the network.
 Documents types of attacks originating on the Internet that target the network. A
sensor used in this latter fashion provides the following benefits:
 Detects attacks targeting critical systems and resources.
 Allows focusing of limited resources to the network assets considered of Greatest
value.

lOMoAR cPSD|5407349
Intrusion Detection Techniques
As with host-based intrusion detection, network-based intrusion detection makes
use of signature detection and anomaly detection.
Signature Detection
1. Application layer reconnaissance and attacks
2. Transport layer reconnaissance and attacks
3. Network layer reconnaissance and attacks
4. Unexpected application services
5. Policy violation
Anomaly Detection Techniques
1. Denial-of-service (DoS) attacks
2. Scanning
3. Worms
NIDS sensor includes the following:
 Timestamp (usually date and time)
 Connection or session ID (typically a consecutive or unique number assigned to
each TCP connection or to like groups of packets for connectionless protocols)
 Event or alert type
 Rating (e.g., priority, severity, impact, confidence)
 Network, transport, and application layer protocols
 Source and destination IP addresses
 Source and destination TCP or UDP ports, or ICMP types and codes
 Number of bytes transmitted over the connection
 Decoded payload data, such as application requests and responses
 State-related information (e.g., authenticated username)
____________________________________________________________________________________

lOMoAR cPSD|5407349
Distributed or Hybrid Intrusion Detection
In recent years, the concept of communicating IDSs has evolved to schemes involve
distributed systems that cooperate to identify intrusions and to adapt to changing attack
profiles. These combine in a central IDS, the complementary information sources used
by HIDS with host-based process and data details, and NIDS with network events and
data, to manage and coordinate intrusion detection and response in an organization’s
IT infrastructure. Two key problems have always confronted systems such as IDSs,
firewalls, virus and worm detectors, and so on. First, these tools may not recognize new
threats or radical modifications of existing threats. And second, it is difficult to update
schemes rapidly enough to dealwith quickly spreading attacks.

lOMoAR cPSD|5407349
This approach does not rely solely on perimeter defense mechanisms, such as
firewalls, or on individual host-based defenses. Instead, each end host and each network
device (e.g., routers) is considered to be a potential sensor and may have the sensor
software module installed. The sensors in this distributed configuration can
exchange information to corroborate the state of the network (i.e., whether an attack is
under way)
The Intel designers provide the following motivation for this approach:
1. IDSs deployed selectively may miss a network-based attack or may be slow to
recognize that an attack is under way. The use of multiple IDSs that share
information has been shown to provide greater coverage and more rapid response
to attacks, especially slowly growing attacks (e.g., [BAIL05], [RAJA05]).
2. Analysis of network traffic at the host level provides an environment in which
there is much less network traffic than found at a network device such as a router.
Thus, attack patterns will stand out more, providing in effect a higher signal-to-
noise ratio.
3. Host-based detectors can make use of a richer set of data, possibly using
Application data from the host as input into the local classifier
Three types of input guide the actions of the central system:
 Summary events: Events from various sources are collected by intermediate
collection points such as firewalls, IDSs, or servers that serve a specific
segment of the enterprise network. These events are summarized for delivery to
the central policy system.
 DDI events: Distributed detection and inference (DDI) events are alerts that
are generated when the gossip traffic enables a platform to conclude that an
attack is under way.
 PEP events: Policy enforcement points (PEPs) reside on trusted, self-
defending platforms and intelligent IDSs. These systems correlate distributed
information, local decisions, and individual device actions to detect intrusions
that may not be evident at the host level.
____________________________________________________________________________________________

lOMoAR cPSD|5407349
Intrusion Detection Exchange Format:
To facilitate the development of distributed IDSs that can function across a wide
range of platforms and environments, standards are needed to support interoperability.
Such standards are the focus of the IETF Intrusion Detection Working Group. The
purpose of the working group is to define data formats and exchange procedures for
sharing information of interest to intrusion detection and response systems and to
management systems that may need to interact with them.
The working group issued the following RFCs in 2007:
 Intrusion Detection Message Exchange Requirements (RFC 4766)
 The Intrusion Detection Message Exchange Format (RFC 4765)
 The Intrusion Detection Exchange Protocol (RFC 4767)
Figure 8.7 illustrates the key elements of the model on which the intrusion detection
message exchange approach is based. This model does not correspond to any particular
product or implementation, but its functional components are the key elements of any
IDS

lOMoAR cPSD|5407349
The functional components are as follows:
 Data source
 Sensor
 Analyzer
 Administrator
 Manager
 Operator
______________________________________________________________________

lOMoAR cPSD|5407349
Honeypots
A further component of intrusion detection technology is the honeypot. Honeypots are
decoy systems that are designed to lure a potential attacker away from critical systems.
Honeypots are designed to:
 Divert an attacker from accessing critical systems.
 Collect information about the attacker’s activity.
 Encourage the attacker to stay on the system long enough for
administrators to respond.
The honeypot is a resource that has no production value. There is no legitimate
reason for anyone outside the network to interact with a honeypot. Thus, any attempt to
communicate with the system is most likely a probe, scan, or attack. Conversely, if a
honeypot initiates outbound communication, the system has probably been compromised
Honeypots are typically classified as being either low or high interaction.
 Low interaction honeypot: Consists of a software package that emulates particular
IT services or systems well enough to provide a realistic initial interaction, but does
not execute a full version of those services or systems.
 High interaction honeypot: Is a real system, with a full operating system, services
and applications, which are instrumented and deployed where they can be accessed
by attackers.
“The Honeynet Project” provides a range of resources and packages for such
systems. . Once hackers are within the network, administrators can observe their behavior
in detail and figure out defenses. Honeypots can be deployed in a variety of locations.
Figure 8.8 illustrates some possibilities. The location depends on a number of factors,
such as the type of information the organization is interested in gathering and the level of
risk that organizations can tolerate to obtain the maximum amount of data.

lOMoAR cPSD|5407349
The network of externally available services, such as Web and mail, often called the
DMZ (demilitarized zone), is another candidate for locating a honeypot (location 2). The
security administrator must assure that the other systems in the DMZ are secure
against any activity generated by the honeypot. A disadvantage of this location is that a
typical DMZ is not fully accessible, and the firewall typically blocks traffic to the DMZ
the attempts to access unneeded services. Thus, the firewall either has to open up the
traffic beyond what is permissible, which is risky, or limit the effectiveness of the
honeypot.
_______________________________________________________________________

lOMoAR cPSD|5407349
Example System Snort
Snort is an open source, highly configurable and portable host-based or network-based
IDS. Snort is referred to as a lightweight IDS, which has the following characteristics:
 Easily deployed on most nodes (host, server, router) of a network.
 Efficient operation that uses small amount of memory and processor time.
 Easily configured by system administrators who need to implement a specific
security solution in a short amount of time.
Snort can perform real-time packet capture, protocol analysis, and content searching and
matching. Snort is mainly designed to analyze TCP, UDP, and ICMP network protocols,
though it can be extended with plugins for other protocols. Snort can detect a variety of
attacks and probes, based on a set of rules configured by a system administrator.
Snort Architecture:
A Snort installation consists of four logical components (Figure 8.9):
 Packet decoder
 Detection engine
 Logger
 Alerter
A Snort implementation can be configured as a passive sensor, which monitors
traffic but is not in the main transmission path of the traffic, or an inline sensor, through
which all packet traffic must pass. In the latter case, Snort can perform intrusion
prevention as well as intrusion detection.

lOMoAR cPSD|5407349
Snort Rules:
Snort uses a simple, flexible rule definition language that generates the rules used by the
detection engine. Although the rules are simple and straight forward to write they are
powerful enough to detect a wide variety of hostile or suspicious traffic.
Each rule consists of a fixed header and zero or more options (Figure 8.10).
The header has the following elements:
1. Action
2. Protocol
3. Source IP address
4. Source port
5. Direction
6. Destination IP address
7. Destination port
There are four major categories of rule options:
 Meta-data: Provide information about the rule but do not have any affect dur- ing detection.
 Payload: Look for data inside the packet payload and can be interrelated.
 Non-payload: Look for non-payload data.
 Post-detection: Rule-specific triggers that happen after a rule has matched a packet.
________________________________________________________________________

Cyber Security Notes Unit 4 for Engineering

More Related Content

Similar to Cyber Security Notes Unit 4 for Engineering (20)

Recently uploaded (20)

Cyber Security Notes Unit 4 for Engineering