<<

. 6
( 19)



>>

120 CCNA Security Course Booklet, Version 1.0




the traffic requirements for those zones. For example, multiple zones might be indirectly attached
to a single interface of a firewall, resulting in a device-specific interzone policy.
Common ZPF designs are LAN-to-Internet firewall, a firewall with public servers, redundant fire-
walls, and complex firewalls.


4.4.2 Zone-Based Policy Firewall Operation
The Cisco IOS zone-based policy firewall can take three possible actions when configured using
Cisco SDM:

Inspect - Configures Cisco IOS stateful packet inspection. This action is equivalent to the


CBAC ip inspect command. It automatically allows for return traffic and potential ICMP
messages. For protocols requiring multiple parallel signaling and data sessions (for example,
FTP or H.323), the inspect action also handles the proper establishment of data sessions.
Drop - Analogous to a deny statement in an ACL. A log option is available to log the rejected


packets.
Pass - Analogous to a permit statement in an ACL. The pass action does not track the state of


connections or sessions within the traffic. Pass allows the traffic only in one direction. A
corresponding policy must be applied to allow return traffic to pass in the opposite direction.
To apply rate limits to the traffic of a specified class, the police option can be used in conjunction
with the inspect or pass command.
The membership of the router network interfaces in zones is subject to several rules governing in-
terface behavior, as is the traffic moving between zone member interfaces:

A zone must be configured before an administrator can assign interfaces to the zone.



If traffic is to flow between all interfaces in a router, each interface must be a member of a


zone.
An administrator can assign an interface to only one security zone.



Traffic is implicitly allowed to flow by default among interfaces that are members of the same


zone.
To permit traffic to and from a zone member interface, a policy allowing or inspecting traffic


must be configured between that zone and any other zone.
Traffic cannot flow between a zone member interface and any interface that is not a zone


member. An administrator can apply pass, inspect, and drop actions only between two zones.
Interfaces that have not been assigned to a zone function can still use a CBAC stateful packet


inspection configuration.
If an administrator does not want an interface on the router to be part of the zone-based


firewall policy, it might still be necessary to put that interface in a zone and configure a pass-
all policy (also known as a dummy policy) between that zone and any other zone to which
traffic flow is desired.
The rules for a zone-based policy firewall are different when the router is involved in the traffic
flow. In addition, the rules depend on whether the router is the source or the destination of the traf-
fic.
When an interface is configured to be a zone member, the hosts that are connected to the interface
are included in the zone, but traffic flowing to and from the interfaces of the router is not con-
trolled by the zone policies. Instead, all the IP interfaces on the router are automatically made part
Chapter 4: Implementing Firewall Technologies 121




of the self zone. To limit IP traffic moving to the IP addresses of the router from the various zones
on a router, policies must be applied. The policies can be set to block, allow, or inspect traffic be-
tween the zone and the self zone of the router, and vice versa. If there are no policies between a
zone and the self zone, all traffic is permitted to the interfaces of the router without being in-
spected.
A policy can be defined using the self zone as either the source or the destination zone. The self
zone is a system-defined zone. It does not require any interfaces to be configured as members. A
zone-pair that includes the self zone, along with the associated policy, applies to traffic that is di-
rected to the router or traffic that the router generates. It does not apply to traffic traversing the
router.
When the router is involved in the traffic flow, additional rules for zone-based policy firewalls gov-
ern interface behavior:

All traffic to and from a given interface is implicitly blocked when the interface is assigned to


a zone, except traffic to or from other interfaces in the same zone and traffic to any interface
on the router.
All the IP interfaces on the router are automatically made part of the self zone when ZPF is


configured. The self zone is the only exception to the default deny all policy. All traffic to any
router interface is allowed until traffic is explicitly denied.

The only exception to the deny-by-default approach is the traffic to and from the router itself. This
traffic is permitted by default. An explicit policy can be configured to restrict such traffic.


4.4.3 Configuring a Zone-Based Policy Firewall with CLI
There are several steps for configuring ZPF with the CLI:
Step 1. Create the zones for the firewall with the zone command.
security

Step 2. Define traffic classes with the class-map command.
type inspect

Step 3. Specify firewall policies with the policy-map command.
type inspect

Step 4. Apply firewall policies to pairs of source and destination zones using the zone-pair se-
curity command.

Step 5. Assign router interfaces to zones using the zone-member interface command.
security

When configuring ZPF with the CLI, there are several factors to consider:

Only policy maps defined with type can be used in the zone-pair
– inspect security
command.
Only class maps defined with type can be used in policy maps with type
– inspect inspect.

There can be no name overlap with other types of class maps or policy maps. There cannot be


a quality-of-service class map and an inspect class map with the same name.
A zone must be configured with the zone security global command before it can be used in


the zone-member security interface configuration command.
An interface cannot belong to multiple zones. To create a union of security zones, specify a


new zone and appropriate policy map and zone pairs.
The zone-based policy firewall feature is a replacement for CBAC. Remove the ip inspect


interface configuration command before applying the zone-member security command.
122 CCNA Security Course Booklet, Version 1.0




The zone-based policy firewall can coexist with CBAC. The ip command can still
– inspect
be used on interfaces that are not members of security zones.
Traffic can never flow between an interface assigned to a zone and an interface without a zone


assignment. Applying the zone-member configuration command always results in temporary
interruption of service.
The default interzone policy is to drop all traffic unless specified otherwise in the zone-pair


configuration command.
The router never filters the traffic between interfaces in the same zone.



The zone-member command does not protect the router itself (traffic to and from the router is


not affected) unless the zone pairs are configured using the predefined self zone.
CBAC dynamically creates entries in ACLs attached to interfaces on which the ip inspect com-
mand is configured. ZPF does not change ACLs. Review ACL usage before entering the zone-
member command.

Create the Zones
The administrator creates the zones for the firewall with the zone command. An op-
security
tional description is recommended.
Router(config)# zone security zone-name
Router(config-sec-zone)# description line-of-description
Think about what should constitute the zones. The general guideline is to group together interfaces
that are similar when viewed from a security perspective. In other words, interfaces that have simi-
lar security needs should be placed into a zone.
Define Traffic Classes
ZPF traffic classes enable the network security professional to define traffic flows in as granular a
fashion as desired.
This is the syntax for creating ZPF traffic classes.
Router(config)# class-map type inspect [match-any | match-all] class-map-name
For Layer 3 and Layer 4, top-level class maps, the match-any option is the default behavior.
Router(config)# class-map type inspect protocol-name [match-any | match-all]
class-map-name
For Layer 7, application-specific class maps, see www.cisco.com for construction details.
The syntax for referencing access lists from within the class map is:
Router(config-cmap)# match access-group {access-group | name access-group-name}
Protocols are matched from within the class map with the syntax:
Router(config-cmap)# match protocol protocol-name
Nested class maps can be configured as well using the syntax:
Router(config-cmap)# match class-map class-map-name
The ability to create a hierarchy of classes and policies by nesting is one of the reasons that ZPF is
such a powerful approach to creating Cisco IOS firewalls.
Specify Firewall Policies
Similar to other modular CLI constructs with Cisco IOS software, the administrator has to specify
what to do with the traffic matching the desired traffic class. The options are pass, inspect, drop,
and police.
This is the syntax for creating ZPF policy maps.
Chapter 4: Implementing Firewall Technologies 123




Router(config)# policy-map type inspect policy-map-name
Traffic classes on which an action must be performed are specified within the policy map.
Router(config-pmap)# class type inspect class-name
The default class (matching all remaining traffic) is specified using this command.
Router(config-pmap)# class class-default
Finally, the action to take on the traffic is specified.
Router(config-pmap-c)# pass | inspect | drop [log] | police
Apply Firewall Policies
After the firewall policy has been configured, the administrator applies it to traffic between a pair
of zones using the zone-pair security command. To apply a policy, a zone pair must first be
created. Specify the source zone, the destination zone, and the policy for handling the traffic be-
tween them.
Router(config)# zone-pair security zone-pair-name [source source-zone-name |
self] destination [self | destination-zone-name]
Use the service-policy type inspect policy-map-name command to attach a policy-map and
its associated actions to a zone-pair. Enter the command after entering the zone-pair security
command.
Deep-packet inspection (attaching a Layer 7 policy map to a top-level policy map) can also be
configured. This is the syntax used with Cisco IOS Release 12.4(20)T.
Router(config-pmap-c)# service-policy {h323 | http | im | imap | p2p | pop3 | sip
| smtp | sunrpc | urlfilter} policy-map
The policy map is the name of the Layer 7 policy map being applied to the top-level Layer 3 or
Layer 4 policy map.
Assign Interfaces
Finally, the administrator must assign interfaces to the appropriate security zones using the zone-
member interface command.

Router(config-if)# zone-member security zone-name
The zone-member security command puts an interface into a security zone. When an interface is
in a security zone, all traffic to and from that interface (except traffic going to the router or initi-
ated by the router) is dropped by default. To permit traffic through an interface that is a zone mem-
ber, the zone must be part of a zone pair to which a policy is applied. If the policy permits traffic
(via inspect or pass actions), traffic can flow through the interface.
ZPF configuration with the CLI might appear a little intimidating at first. The good news is that
there are two ways to configure ZPF - with the Cisco IOS CLI or with Cisco SDM.


4.4.4 Configuring Zone-Based Policy Firewall with
Manual SDM
Zone-Based Policy Firewall configuration is much easier with Cisco Router and Security Device
Manager (SDM).
There are four steps to configure ZPF with SDM:
Step 1. Define zones.
Step 2. Configure class maps to describe traffic between zones.
Step 3. Create policy maps to apply actions to the traffic of the class maps.
Step 4. Define zone pairs and assign policy maps to the zone pairs.
124 CCNA Security Course Booklet, Version 1.0




Unlike the CLI configuration, with SDM, the interfaces are associated with zones in Step 1.
A similar, newer Cisco GUI called Cisco Configuration Professional (CCP) can be used to config-
ure ZPF. See www.cisco.com/go/ciscocp. CCP adds the feature of communities, which are groups
of devices, to improve network management. Some technologies, such as SIP protocol inspection
under the self zone, are supported on SDM but not on CCP. Cisco IOS 12.4(9)T or later is required
for CCP. CCP will eventually replace SDM.
Define Zones
The first step in configuring a Cisco IOS zone-based policy firewall with SDM is to define zones.
A zone, or security zone, is a group of interfaces to which a security policy can be applied. The in-
terfaces in a zone share common functions or features. For example, an administrator might place
two interfaces that connect to the local LAN in one security zone, and the interfaces that connect
to the Internet into another security zone.
For traffic to flow among all interfaces in a router, all interfaces must be a member of a security
zone. However, it is not required that all router interfaces be members of security zones.
These are the steps for creating a zone using SDM:
Step 1. Choose Configure > Additional Tasks > Zones.
Step 2. From the Zone panel, click Add to create a new zone.
Step 3. The Add a Zone window appears. Enter a zone name in the Zone Name field.
Step 4. Choose the interfaces for this zone by checking the check box in front of the interface
name. Because physical interfaces can be placed in only one zone, they do not appear in the list if
they have already been assigned to a zone. You can place virtual interfaces, such as Dialer inter-
faces or Virtual Template interfaces, in multiple zones, so these interfaces always appear in the list.
As you assign interfaces to zones, keep in mind the zone-based policy firewall rules that govern in-
terface behavior.
Step 5. Click OK to create the zone, and click OK in the Commands Delivery Status window.
After a zone has been created, the interfaces that are associated with the zone can be changed, but
the name of the zone cannot be changed. Click Edit in the Zone panel to choose different inter-
faces for an existing zone. Click Delete in the Zone panel to remove a zone. A zone that is a mem-
ber of a zone pair cannot be deleted.
Configure Class Maps
The next step in configuring ZPF with SDM is to configure class maps. Class maps identify traffic
and traffic parameters for policy application.
Layer 3 and 4 class maps sort the traffic based on specific criteria:

Access group - A standard, extended, or named ACL can filter traffic based on source and


destination IP addresses and source and destination ports.
Protocol - The class map can identify Layer 4 protocols, such as TCP, UDP, and ICMP, and


application services such as HTTP, SMTP, and DNS. Any well-known or user-defined service
known to Port-to-Application Mapping (PAM) can be specified.
Class map - A subordinate class map that provides additional match criteria can be nested


inside another class map.

Class maps can apply match-any or match-all operators to determine how to apply the match crite-
ria. If match-any is specified, traffic must meet just one of the match criteria in the class map. If
Chapter 4: Implementing Firewall Technologies 125




match-all is specified, traffic must match all of the class map criteria to belong to that particular
class.
These are the steps to create a class map using SDM:
Step 1. Choose Configure > Additional Tasks > C3PL > Class Map > Inspection.
Step 2. From the Inspection Class Maps, click Add.
Step 3. Enter a class map name in the Class Map field and optionally add a description in the
Description field. Select the desired protocols from the list and click Add>> to add them to the
inspection list for this class map.
Class maps can be reviewed, created, and edited in the Inspect Class Map window. The Class Map
Name area of the window lists the configured class maps, and the lower portion of the window dis-
plays the details of the selected class map. If it is necessary to edit a class map or see more details,
choose the class map from the list and click Edit.
Create Policy Maps
Now that the class maps are created, it is time to create policy maps. Class maps are applied within
policy maps. Policy maps specify the actions to be taken when traffic matches the criteria. A pol-
icy map associates traffic classes with actions.
Inspection policy maps specify the action the router is to take for traffic that matches the criteria in
the associated class maps. These are the actions that a policy map supports:

Pass - Traffic is allowed to pass from one zone to another only in one direction. The router


does not monitor the state of connections or session.
Drop - The router drops unwanted traffic and can optionally log the event.



Inspect - The router maintains state-based session and connection information so that the


router permits traffic returning from a destination zone to a source zone.
These are the steps to create a policy map using SDM:
Step 1. Choose Configure > Additional Tasks > C3PL > Policy Map > Protocol Inspection.
Step 2. From the Protocol Inspection Policy Maps, click Add.
Step 3. Enter a policy name in the Policy Name field and optionally add a description in the
Description field. The name and description that you enter will be visible in the Protocol Inspect
Policy Maps window.
Step 4. The Class Map and Action columns display the class maps that are associated with this
policy map, and the action that the router takes for the traffic that the class map describes. Click
Add to add a new class map to the list and configure the action.
Step 5. The Associate Class map window appears. In the Class Name field, enter the name of the
class map to apply. If the class map name is unknown, or a new class map is to be created, click
the down arrow to the right of the Class Name field. A pop-up menu appears for adding a class
map, choosing a class map, or choosing the class default.
Step 6. After selecting the class map, define the action that the policy map takes for traffic that
matches this class map. From the Action section, choose Pass, Drop, or Inspect, based on the par-
ticular needs for this class map.
Step 7. Click OK.
Step 8. To add another class map to the policy, click Add. To modify the actions of an existing
class map, choose the class map from the Class Map list and click Edit. To delete a class map,
126 CCNA Security Course Booklet, Version 1.0




choose the class map from the Class Map list and click Delete. Use the Move Up and Move Down
buttons to change the order in which the class maps are evaluated.
Step 9. Click OK. In the Command Delivery Status window, click OK.
Define Zone Pairs
A zone-pair allows a unidirectional firewall policy between two security zones to be specified. The
direction of the traffic is determined by specifying a source and destination security zone. The
same zone cannot be defined as both the source and the destination.
If the intent is for traffic to flow in both directions between two zones, a zone pair must be created
for each direction. If the intent is for traffic to flow freely among all interfaces, each interface must
be configured in a zone.
These are the steps for configuring a new zone pair using SDM:
Step 1. Choose Configure > Additional Tasks > Zone Pairs.
Step 2. In the Zone Pairs panel, click Add. The Add a Zone Pair window appears.
Step 3. In the Zone Pair field, enter a name for the zone pair. Choose a source zone from which
traffic originates, a destination zone to which traffic is sent, and the policy that determines which
traffic can be sent across the zones.
The source zone and destination zone lists contain the zones that are configured on the router and
the self zone. The self zone can be used when configuring zone pairs for traffic originating from
the router itself, or destined for the router itself, such as a zone pair that is configured for SNMP
traffic. The Policy list contains the name of each policy map that is configured on the router.
Step 4. Click OK in the Add a Zone Pair window, and click OK in the Command Delivery Status
window.
Step 5. To edit a zone pair, in the Zone Pairs panel choose the zone pair to edit and click Edit. If
editing a zone pair, the policy map can be changed, but the name or the source or destination zones
cannot be changed.



4.4.5 Configuring Zone-Based Policy Firewall with SDM
Wizard
The Basic Firewall wizard of Cisco SDM helps implement a firewall. The wizard goes through the
creation of the firewall by asking for information about the interfaces on the router, as well as
whether the intent is to configure a DMZ network, and what rules to use in the firewall.
These are the steps for accessing the Basic Firewall Configuration wizard using SDM:
Step 1. From Cisco SDM, choose Configuration > Firewall and ACL.
Step 2. In the Create Firewall tab, click the Basic Firewall option and click Launch the Selected
Task button.
Step 3. The Basic Firewall Configuration Wizard window appears. Click Next to begin the config-
uration.
If there is no CBAC configured on the router, a zone-based policy firewall is created by the Basic
or Advanced Firewall wizards.
The first task to configure a basic firewall is to define inside (trusted) and outside (untrusted) inter-
faces. An outside (untrusted) interface is typically the router interface that is connected to the In-
Chapter 4: Implementing Firewall Technologies 127




ternet or to a WAN. An inside (trusted) interface is typically a physical or logical interface that
connects to the LAN. It is possible to select multiple inside and outside interfaces.
These are the steps for configuring a firewall using the Basic Firewall Configuration wizard:
Step 1. From the Basic Firewall Interface Configuration window, check the outside (untrusted)
check box and the inside (trusted) check box to identify each interface as an outside or an inside
interface. Outside interfaces connect to an organization™s WAN or to the Internet. Inside interfaces
connect to the LAN. More than one of each can be chosen.
Step 2. (Optional) Check the Allow Secure Cisco SDM Access From Outside Interfaces check
box if the intent is to allow users outside the firewall access to the router using Cisco SDM.
Choosing this option permits secure HTTP access to the outside (untrusted) interface. Because it is
a secure Cisco SDM connection to the firewall, it is not possible to browse the outside (untrusted)
interface via HTTP after the firewall wizard completes the configuration. After clicking Next, the
wizard displays a screen that allows the administrator to specify a host IP address or a network ad-
dress. The firewall is modified to allow access to the address specified.
Step 3. Click Next. If the Allow Secure SDM Access From the Outside Interfaces check box is
checked, the Configuring Firewall for Remote Access window appears.
Step 4. Specify the source host or network from which Cisco SDM is allowed to remotely manage
the router. Choose Network address, Host IP address, or any from the Type drop-down list, and
then fill in the IP address and Subnet Mask as appropriate.
After interface configuration, the Basic Firewall Security Configuration window appears. Cisco
SDM provides preconfigured application security policies that can be used to protect the network.
Use the slider bar to select the security level desired and to view a description of the security it
provides.
In the Basic Firewall Security Configuration window, click the Preview Commands button to
view the Cisco IOS commands that make up the selected policy. The router must be configured
with the IP address of at least one DNS server for application security to work.
The Firewall Configuration Summary window displays the policy name chosen, SDM_HIGH,
SDM_MEDIUM, or SDM_LOW, and the configuration statements in the policy.
Click Finish to complete the configuration. The commands executed by the Basic Firewall wizard
are often quite lengthy. The configurations created by wizards tend to be much more exhaustive
than those created by a manual CLI or SDM configuration.



4.4.6 Troubleshooting Zone-Based Policy Firewall
After creating the zone-based policy firewall, examine it in SDM by choosing Configure > Fire-
wall and ACL and clicking the Edit Firewall Policy tab. A graphical view of the firewall displays
in the context of the router interfaces. It is also possible to modify the firewall from this window.
The CLI ZPF commands generated by a two-interface firewall with default inspection parameters
are not that lengthy. Typically, protocols such as HTTP, SMTP, and FTP are inspected in this type
of scenario. A policy map applies stateful inspection to these protocols listed in a class map. Two
zones, such as private and Internet, are created. The inside interface is made a member of the pri-
vate zone, and the WAN interface is a member of the Internet zone. Lastly, a zone pair, such as
priv-to-internet, is created. This pair has a source zone of private, a destination zone of Internet,
and the policy map is applied to it.
128 CCNA Security Course Booklet, Version 1.0




If the router runs a Cisco IOS image that supports ZPF, SDM can be used to display the status of
the firewall activity for each zone pair that is configured on the router. To display the firewall sta-
tus information, choose Monitor > Firewall Status.
The firewall policy list area displays the policy name, source zone, and destination zone for each
zone pair. Choose one of the following options to specify how data should be collected:

Real-time data every 10 sec - Data is reported every 10 seconds. Each tick mark on the


horizontal axis of the Dropped Packets and Allowed Packets graph represents 10 seconds.
60 minutes of data polled every 1 minute - Data is reported every 1 minute. Each tick mark


on the horizontal axis of the Dropped Packets and Allowed Packets graph represents 1 minute.
12 hours of data polled every 12 minutes - Data is reported every 12 minutes. Each tick mark


on the horizontal axis of the Dropped Packets and Allowed Packets graph represents 12
minutes.
Use the show policy-map type inspect zone-pair session command to examine the active
connections in the ZPF state table. The following output shows active connections from 10.0.2.12
to 172.26.26.51 port 80.
Router# show policy-map type inspect zone-pair session
Zone-pair: CNS-PAIR
Service-policy inspect : HTTP-Policy
Class-map: HTTP-Class (match-all)
Match: access-group 110
Match: protocol http
Inspect
Established Sessions
Session 643BCF88 (10.0.2.12:3364)=>(172.26.26.51:80) http SIS_OPEN
Created 00:00:10, Last heard 00:00:00
Bytes sent (initiator:responder) [1268:64324]
Session 643BB9C8 (10.0.2.12:3361)=>(172.26.26.51:80) http SIS_OPEN
Created 00:00:16, Last heard 00:00:06
Bytes sent (initiator:responder) [2734:38447]
Session 643BD240 (10.0.2.12:3362)=>(172.26.26.51:80) http SIS_OPEN
Created 00:00:14, Last heard 00:00:07
Bytes sent (initiator:responder) [2219:39813]
Session 643BBF38 (10.0.2.12:3363)=>(172.26.26.51:80) http SIS_OPEN
Created 00:00:14, Last heard 00:00:06
Bytes sent (initiator:responder) [2106:19895]
Class-map: class-default (match-any)
Match: any
Drop (default action)
58 packets, 2104 bytes

Cisco IOS Zone-Based Policy Firewall provides state-of-the-art firewall design and configuration.
What began with TCP established in 1995 has evolved into a rich set of technologies for secur-
ing networks.
But firewalls alone can never provide a complete security solution. Other technologies are required
to build a secure infrastructure. Network intrusion prevention is another security technology that is
required to support the network firewall. Intrusion prevention goes a long way toward closing any
security gaps in a modern network.
Chapter 4: Implementing Firewall Technologies 129




Chapter Summary
Refer to Packet Refer to
Tracer Activity Lab Activity
for this chapter for this chapter




Your Chapter Notes
130 CCNA Security Course Booklet, Version 1.0
CHAPTER 5

Implementing Intrusion Prevention




Chapter Introduction
The security challenges that face today™s network administrators cannot be successfully managed
by any single application. Although implementing device hardening, AAA access control, and fire-
wall features are all part of a properly secured network, these features still cannot defend the net-
work against fast-moving Internet worms and viruses. A network must be able to instantly
recognize and mitigate worm and virus threats.
It is also no longer possible to contain intrusions at a few points in the network. Intrusion preven-
tion is required throughout the entire network to detect and stop an attack at every inbound and
outbound point.
A networking architecture paradigm shift is required to defend against fast-moving and evolving
attacks. This must include cost-effective detection and prevention systems, such as intrusion detec-
tion systems (IDS) or, the more scalable, intrusion prevention systems (IPS). The network archi-
tecture integrates these solutions into the entry and exit points of the network.
When implementing IDS and/or IPS, it is important to be familiar with the types of systems avail-
able, host-based and network-based approaches, the placement these systems, the role of signature
categories, and possible actions that a Cisco IOS router can take when an attack is detected.
In a comprehensive hands-on lab for the chapter, Configuring an Intrusion Prevention System
Using the CLI and SDM, learners configure IPS using the CLI, modify IPS signatures, verify IPS
functionality, and log IPS messages to a syslog server. Next, learners configure IPS using SDM,
modify signatures, use a scanning tool to simulate an attack, and use SDM Monitor to verify IPS
functionality. The lab is found in the lab manual on Academy Connection at cisco.netacad.net.
A Packet Tracer activity, Configure IOS Intrusion Prevention System Using CLI, provides learners
additional practice implementing the technologies introduced in this chapter. Learners configure
IPS using CLI, modify IPS signatures, and verify IPS functionality.
Packet Tracer activities for CCNA Security are found on Academy Connection at cisco.netacad.net.



5.1 IPS Technologies
5.1.1 IDS and IPS Characteristics
Internet worms and viruses can spread across the world in a matter of minutes. A network must in-
stantly recognize and mitigate worm and virus threats. Firewalls can only do so much and cannot
protect against malware and zero-day attacks.
A zero-day attack, sometimes referred to as a zero-day threat, is a computer attack that tries to ex-
ploit software vulnerabilities that are unknown or undisclosed by the software vendor. The term
zero-hour describes the moment when the exploit is discovered. During the time it takes the soft-
ware vendor to develop and release a patch, the network is vulnerable to these exploits. To defend
against these fast-moving attacks requires security professionals to expand how they view network
architecture. It is no longer possible to contain intrusions at a few points in the network.
132 CCNA Security Course Booklet, Version 1.0




One approach to prevent worms and viruses from entering a network is for an administrator to
continuously monitor the network and analyze the log files generated by the network devices. This
solution is not very scalable. Manually analyzing log file information is a time-consuming task and
provides a limited view of the attacks being launched against a network. By the time that the logs
are analyzed, the attack has already begun.
Intrusion Detection Systems (IDSs) were implemented to passively monitor the traffic on a net-
work. An IDS-enabled device copies the traffic stream, and analyzes the monitored traffic rather
than the actual forwarded packets. It compares the captured traffic stream with known malicious
signatures in an offline manner similar to software that checks for viruses. This offline IDS imple-
mentation is referred to as promiscuous mode.
The advantage of operating with a copy of the traffic is that the IDS does not negatively affect the
actual 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 it 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.
It is better to implement a solution that detects and immediately addresses a network problem as
required.
An Intrusion Prevention System (IPS) builds upon IDS technology. Unlike IDS, an IPS device is
implemented in inline mode. This means that all ingress and egress traffic must flow through it for
processing. An IPS does not allow packets to enter the trusted side of the network without first
being analyzed. It can detect and immediately address a network problem as required.
An IPS monitors Layer 3 and Layer 4 traffic and analyzes the contents and the payload of the
packets for more sophisticated embedded attacks that might include malicious data at Layers 2
through 7. Cisco IPS platforms use a blend of detection technologies, including signature-based,
profile-based, and protocol analysis intrusion detection. 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 analyzed.
The advantage of operating in an inline manner is that the IPS can stop single-packet attacks from
reaching the target system. The disadvantage is that a poorly configured IPS or an inappropriate
IPS solution can negatively affect the packet flow of the forwarded traffic.
The biggest difference between IDS and IPS is that an IPS responds immediately and does not
allow any malicious traffic to pass, whereas an IDS might allow malicious traffic to pass before re-
sponding.
IDS and IPS technologies do share several characteristics. IDS and IPS technologies are both de-
ployed as sensors. An IDS or IPS sensor can be any of the following devices:

Router configured with Cisco IOS IPS software



Appliance specifically designed to provide dedicated IDS or IPS services



Network module installed in an adaptive security appliance, switch, or router


IDS and IPS technologies use signatures to detect patterns of misuse in network traffic. A signa-
ture is a set of rules that an IDS or IPS uses to detect typical intrusive activity. Signatures can be
used to detect severe breaches of security, common network attacks, and information gathering.
IDS and IPS technologies can detect atomic signature patterns (single-packet) or composite signa-
ture patterns (multipacket).
Does an IPS sensor completely replace an IDS sensor?
Chapter 5: Implementing Intrusion Prevention 133




IDS Advantages and Disadvantages
One main advantage of an IDS platform is that it is deployed in promiscuous mode. Because the
IDS sensor is not inline, it has no impact on network performance. It does not introduce latency,
jitter, or other traffic flow issues. In addition, if a sensor fails, it does not affect network functional-
ity. It only affects the ability of the IDS to analyze the data.
But there are many disadvantages of deploying an IDS platform in promiscuous mode. IDS sensor
response actions cannot stop the trigger packet and are not guaranteed to stop a connection. They
are also less helpful in stopping email viruses and automated attacks such as worms.
Users deploying IDS sensor response actions must have a well thought-out security policy, com-
bined with a good operational understanding of their IDS deployments. Users must spend time
tuning IDS sensors to achieve expected levels of intrusion detection.
Finally, because IDS sensors are not inline, an IDS implementation is more vulnerable to network
evasion techniques used by various network threats.
IPS Advantages and Disadvantages
Deploying an IPS platform in inline mode also has advantages and disadvantages.
One advantage over IDS is that an IPS sensor can be configured to perform a packet drop that can
stop the trigger packet, the packets in a connection, or packets from a source IP address. Addition-
ally, being inline, an IPS sensor can use stream normalization techniques to reduce or eliminate
many of the network evasion capabilities that exist.
A disadvantage of IPS is that errors, failure, and overrunning the IPS sensor with too much traffic
can have a negative effect on network performance. This is because IPS must be deployed inline,
and traffic must be able to pass through it. An IPS sensor can affect network performance by intro-
ducing latency and jitter. An IPS sensor must be appropriately sized and implemented so that time-
sensitive applications, such as VoIP, are not negatively effected.
Deployment Considerations
Using one of these technologies does not mean that an administrator should not use the other. In
fact, IDS and IPS technologies can complement each other. For example, an IDS can be imple-
mented to validate IPS operation, because IDS can be configured for deeper packet inspection of-
fline. This allows the IPS to focus on fewer but more critical traffic patterns inline.
Deciding which implementation to use is based on the security goals of the organization as stated
in the network security policy.


5.1.2 Host-Based IPS Implementations
The protection against viruses and threats requires an end-to-end solution. For this reason, IDS and
IPS technologies are typically deployed using two implementations: network-based and host-
based.
Network-based IPS Implementations
Network-based IPS implementations analyze network-wide activity looking for malicious activity.
Network devices such as ISR routers, ASA firewall appliances, Catalyst 6500 network modules, or
dedicated IPS appliances are configured to monitor known signatures. They can also detect abnor-
mal traffic patterns.
Host-based IPS Implementations
Host-based implementations are installed on individual computers using host intrusion prevention
system (HIPS) software such as Cisco Security Agent (CSA). HIPS audits host log files, host file
134 CCNA Security Course Booklet, Version 1.0




systems, and resources. A simple form of HIPS enables system logging and log analysis on the
host, which is an extremely labor-intensive approach. CSA software helps manage HIPS and
proactively secures hosts. 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. It combines behavioral analysis and signature filters with the best features of anti-virus soft-
ware, network firewalls, and application firewalls in one package.
CSA provides host security to enterprises by deploying agents that defend against the proliferation
of attacks across networks. These agents operate using a set of policies that are selectively as-
signed to each system node on the network by the network administrator.
CSA contains two components:

Management Center - Installed on a central server and is managed by a network


administrator.
Security Agent - Installed and runs on a host system. It displays the agent flag icon (small red


flag) in the system tray.

CSA continuously examines processes, security event logs, critical system files, and system reg-
istries looking for malicious entries. It can be installed on publicly accessible servers, corporate
mail servers, application servers, and user desktops. It reports events to a central management con-
sole server that is located inside the corporate firewall.
When installed on a host, CSA controls system operations, protecting systems using policies that
network administrators configure and deploy to agents. These policies allow or deny specific sys-
tem actions. The agents must check whether an action is allowed or denied before any system re-
sources are accessed and acted upon. This process occurs transparently and does not hinder overall
system performance. Unless an errant and unexpected system operation occurs, the agent does not
interfere with daily operations.
CSA provides proactive security by controlling access to system resources. CSA can stop attacks,
without any updates, by identifying malicious behavior and responding in real time. This approach
avoids the race to update defenses to keep up with the latest exploit and protects hosts, even on day
zero, from new attacks. 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 available. Net-
works that were protected with CSA, however, stopped these attacks by identifying their behavior
as malicious.
CSA prompts the user for an action whenever a problem is detected. The user must either allow or
deny the action, or terminate the process when it attempts to access resources on a user™s system.
Typically, a pop-up box appears prompting the user to select from three possible radio buttons
when a rule in question is triggered:

Yes - Allows the application access to the resource in question.



No - Denies the application access to the resource in question.



No, terminate this application - Denies the application access to the resource in question and


also attempts to terminate the application process. The name of the application in question is
displayed with the terminate option.

For example, if CSA recognizes that a software update is being installed, it requires an action. If
the user is installing a legitimate software update, the user must allow the operation to continue.
However, if the user is unaware of the installation and the request appears without any valid rea-
son, the user should most likely deny the action.
Chapter 5: Implementing Intrusion Prevention 135




Depending on the version of Cisco CSA installed, a small orange flag or red flag icon appears in
the Windows system tray. When CSA denies a system action, a message informing the user of this
event is logged. To draw attention to the user, the small orange flag fades in and out or the red flag
waves. The user can also view the CSA log file containing all security events that have occurred on
the system.
There are many advantages of using HIPS. With 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 can-
not always ascertain the success or failure of such an attack. HIPS also does not have to worry
about fragmentation attacks or variable Time to Live (TTL) attacks because the host stack takes
care of these issues. HIPS has access to the traffic after it has been unencrypted.
There are two major drawbacks to HIPS. HIPS does not provide a complete network picture. Be-
cause HIPS examines information only at the local host level, it has difficulty constructing an ac-
curate network picture or coordinating the events happening across the entire network.
Additionally, HIPS needs to run on every system in the network. This requires verifying support
for all the different operating systems that are used in the network.
Host-based and network-based IPS implementations complement one another by securing the mul-
tiple ingress and egress locations of the network.


5.1.3 Network-Based IPS Implementations
A network IPS can be implemented using a dedicated IPS appliance, such as the IPS 4200 series,
or can be added to an ISR router, an ASA firewall appliance or Catalyst 6500 switch.
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 net-
work activity while it is occurring, regardless of the location of the attack target.
Sensors can be implemented in several ways. They can be added to an ISR router using an IPS Ad-
vanced Integration Module (AIM) or a Network Module Enhanced (IPS NME), or added to an
ASA firewall appliance using an Inspection and Prevention Security Services Module (ASA AIP-
SSM). They can also be added to a Catalyst 6500 switch using an Intrusion Detection System Ser-
vices Module (IDSM-2).
Network IPS sensors are usually tuned for intrusion prevention analysis. The underlying operating
system of the platform on which the IPS module is mounted is stripped of unnecessary network
services, and essential services are secured. This is know as hardening. The hardware includes
three components.

Network interface card (NIC) - The 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


ability of a network IPS to efficiently and accurately detect an attack.

Network IPS gives security managers real-time security insight into their networks regardless of
growth. Additional hosts can be added to protected networks without requiring more sensors. Ad-
ditional sensors are only required when their rated traffic capacity is exceeded, when their per-
formance does not meet current needs, or when a revision in security policy or network design
136 CCNA Security Course Booklet, Version 1.0




requires additional sensors to help enforce security boundaries. When new networks are added, ad-
ditional sensors are easy to deploy.
Cisco 1841, 2800, and 3800 ISRs can be configured (using CLI or SDM) to support IPS features
using Cisco IOS IPS, which is part of the Cisco IOS Firewall feature set. This does not require the
installation of an IPS module but does require downloading signature files and adequate memory
to load the signatures. However, this deployment should be limited to a small organization with
limited traffic patterns.
For larger volumes of traffic, Cisco IPS sensors can be implemented using standalone appliances
or as modules added to network devices.
In addition to Cisco IOS IPS, Cisco offers a variety of modular and appliance-based IPS solutions:

Cisco IPS Advanced Integration Module (AIM) and Network Module Enhanced (IPS


NME) - Integrates IPS onto a Cisco ISR used for small and medium-sized business (SMB)
and branch office environments. It provides advanced, enterprise-class IPS functions and
meets the ever-increasing security needs of branch offices. It can also scale in performance to
match branch office WAN bandwidth requirements, while keeping the solution cost low for
businesses of all sizes. Not all Cisco IOS images support IPS features. Administrators must
check the Cisco IOS software and hardware to ensure compatibility. Cisco IOS IPS and Cisco
IPS AIM / IPS NME cannot be used together. Cisco IOS IPS must be disabled when the Cisco
AIM IPS is installed.
Cisco Adaptive Security Appliance Advanced Inspection and Prevention Security Services


Module (ASA AIP-SSM) - Uses advanced inspection and prevention technology to provide
high-performance security services such as intrusion prevention services and advanced anti-X
services. The Cisco ASA AIP-SSM products include a Cisco ASA AIP-SSM-10 module with
1GB of memory, a Cisco ASAAIP-SSM-20 module with 2GB of memory, and a Cisco ASA
AIP-SSM-40 module with 4GB of memory.
Cisco IPS 4200 Series Sensors - Combines inline intrusion prevention services with


innovative technologies that improve accuracy in detecting, classifying, and stopping threats
including worms, spyware and adware, and network viruses. As a result, more threats can be
stopped without the risk of dropping legitimate network traffic. Cisco IPS Sensor Software
Version 5.1 includes enhanced detection capabilities and improved scalability, resiliency, and
performance features.
Cisco Catalyst 6500 Series Intrusion Detection System Services Module (IDSM-2) - As part


of the Cisco IPS solution, it works in combination with the other components to efficiently
protect the data infrastructure.
With the increased complexity of security threats, achieving efficient network intrusion security
solutions is critical to maintaining a high level of protection. Vigilant protection ensures business
continuity and minimizes the effect of costly intrusions.
The choice of a sensor varies depending on the requirements of the organization. Several factors
impact the IPS sensor selection and deployment.

Amount of network traffic



Network topology



Security budget



Available security staff to manage IPS

Chapter 5: Implementing Intrusion Prevention 137




Small implementations such as branch offices might only require a Cisco IOS IPS-enabled ISR
router. As traffic patterns increase, the ISR can be configured to offload IPS functions using an
NME IPS or AIM IPS.
Larger installations could be deployed using their existing ASA 5500 appliance with an ASA AIP.
Enterprises and service providers might require dedicated IPS appliances or a Catalyst 6500 using
an IDSM-2 network module.
Network IPS has several advantages and disadvantages. One advantage is that a network-based
monitoring system can easily see attacks that are occurring across the entire network. This pro-
vides a clear indication of the extent to which the network is being attacked. In addition, because
the monitoring system is examining traffic only from the network, it does not have to support
every type of operating system that is used on the network.
There are also disadvantages of network IPS. If network data is encrypted this can essentially
blind network IPS, allowing attacks to go undetected. Another problem is that IPS has a difficult
time reconstructing fragmented traffic for monitoring purposes. Finally, as networks become larger
in terms of bandwidth, it becomes more difficult to place network IPS at a single location and suc-
cessfully capture all traffic. Eliminating this problem requires using more sensors throughout the
network, which increases costs.
Recall that HIPS examines information at the local host or operating system level while network
IPS examines packets that are traveling through the network for known signs of intrusive activity.
They are not competing technologies but complementing technologies and should both be de-
ployed to provide an end-to-end secure network.



5.2 IPS Signatures
5.2.1 IPS Signature Characteristics
To stop incoming malicious traffic, the network must first be able to identify it. Fortunately, mali-
cious traffic displays distinct characteristics or “signatures.” A signature is a set of rules that an
IDS and an IPS use to detect typical intrusive activity, such as DoS attacks. These signatures
uniquely identify specific worms, viruses, protocol anomalies, or malicious traffic. IPS sensors are
tuned to look for matching signatures or abnormal traffic patterns. IPS signatures are conceptually
similar to the virus.dat file used by virus scanners.
As sensors scan network packets, they use signatures to detect known attacks and respond with
predefined actions. A malicious packet flow has a specific type of activity and signature. An IDS
or IPS sensor examines the data flow using many different signatures. When a sensor matches a
signature with a data flow, it takes action, such as logging the event or sending an alarm to IDS or
IPS management software.
Signatures have three distinctive attributes:

Type



Trigger (alarm)



Action



Signature Types
Signature types are generally categorized as atomic or composite.
138 CCNA Security Course Booklet, Version 1.0




Atomic
An atomic signature is the simplest form. It consists of a single packet, activity, or event that is exam-
ined to determine if it matches a configured signature. If it does, an alarm is triggered, and a signa-
ture action is performed. Because these signatures can be matched on a single event, they do not
require an intrusion system to maintain state information. State refers to situations in which multiple
packets of information are required that are not necessarily received at the same time. For example, if
there was a requirement to maintain state, it would be necessary for the IDS or IPS to track the three-
way handshake of established TCP connections. With atomic signatures, the entire inspection can be
accomplished in an atomic operation that does not require any knowledge of past or future activities.
Detecting atomic signatures consumes minimal resources (such as memory) on the IPS or IDS de-
vice. These signatures are easy to identify and understand because they are compared against a
specific event or packet. Traffic analysis for these atomic signatures can usually be performed very
quickly and efficiently. For example, a LAND attack is an atomic signature because it sends a
spoofed TCP SYN packet (connection initiation) with the IP address of the target host and an open
port as both source and destination. The reason a LAND attack works is because it causes the ma-
chine to reply to itself continuously. One packet is required to identify this type of attack. An IDS
is particularly vulnerable to an atomic attack because, until it finds the attack, malicious single
packets are allowed into the network. An IPS, on the other hand, prevents these packets from en-
tering the network altogether.
Composite
A composite signature is also called a stateful signature. This type of signature identifies a se-
quence of operations distributed across multiple hosts over an arbitrary period of time. Unlike
atomic signatures, the stateful properties of composite signatures usually require several pieces of
data to match an attack signature, and an IPS device must maintain state. The length of time that
the signatures must maintain state is known as the event horizon.
The length of an event horizon varies from one signature to another. An IPS cannot maintain state infor-
mation indefinitely without eventually running out of resources. Therefore, an IPS uses a configured
event horizon to determine how long it looks for a specific attack signature when an initial signature
component is detected. Configuring the length of the event horizon is a tradeoff between consuming
system resources and being able to detect an attack that occurs over an extended period of time.
Network security threats are occurring more frequently and spreading more quickly. As new
threats are identified, new signatures must be created and uploaded to an IPS. To make this process
easier, all signatures are contained in a signature file and uploaded to an IPS on a regular basis.
The signature file contains a package of network signatures intended as an update to the signature
database resident in a Cisco product with IPS or IDS functions. This signature database is used by
the IPS or IDS solution to compare network traffic against data patterns within the signature-file li-
brary. The IPS or IDS uses this comparison to detect suspected malicious network traffic behavior.
For example, the LAND attack is identified in the Impossible IP Packet signature (signature
1102.0). A signature file contains that signature and many more. Networks deploying the latest
signature files are better protected against network intrusions.
To make the scanning of signatures more efficient, Cisco IOS software relies on signature micro-
engines (SME), which categorize common signatures in groups. Cisco IOS software can then scan
for multiple signatures based on group characteristics, instead of one at a time.
When IDS or IPS is enabled, an SME is loaded or built on the router. When an SME is built, the
router might need to compile the regular expression found in a signature. A regular expression is a
systematic way to specify a search for a pattern in a series of bytes.
Chapter 5: Implementing Intrusion Prevention 139




The SME then looks for malicious activity in a specific protocol. Each engine defines a set of legal
parameters with allowable ranges or sets of values for the protocols and the fields the engine in-
spects. Atomic and composite packets are scanned by the micro-engines that recognize the proto-
cols contained in the packets. Signatures can be defined using the parameters offered by the SME.
Each SME extracts values from the packet and passes portions of the packet to the regular expres-
sion engine. The regular expression engine can search for multiple patterns at the same time.
The available SMEs vary depending on the platform, Cisco IOS version, and version of the signa-
ture file. Cisco IOS Release 12.4(6)T defines five micro-engines:

Atomic - Signatures that examine simple packets, such as ICMP and UDP.



Service - Signatures that examine the many services that are attacked.



String - Signatures that use regular expression-based patterns to detect intrusions.



Multi-string - Supports flexible pattern matching and Trend Labs signatures.



Other - Internal engine that handles miscellaneous signatures.



SMEs are constantly being updated. For example, before Release 12.4(11T), the Cisco IPS signa-
ture format used version 4.x. Since IOS 12.4(11)T, Cisco introduced version 5.x, an improved IPS
signature format. The new version supports encrypted signature parameters and other features such
as signature risk rating, which rates the signature on security risk.
There are a few factors to consider when determining router requirements for maintaining signa-
tures. First, compiling a regular expression requires more memory than the final storage of the reg-
ular expression. Determine the final memory requirements of the finished signature before loading
and merging signatures. Assess how many signatures the various router platforms can actually sup-
port. The number of signatures and engines that can adequately be supported depends only on the
memory available. For this reason, configure Cisco IOS IPS-enabled routers with the maximum
amount of memory possible.
Cisco investigates and creates signatures for new threats and malicious behavior as they are dis-
covered and publishes them regularly. Typically, lower priority IPS signature files are published bi-
weekly. If the threat is severe, Cisco publishes signature files within hours of identification.
To protect a network, the signature file must be updated regularly. Each update includes new sig-
natures and all the signatures in the previous version. For example, signature file IOS-S361-
CLI.pkg includes all signatures in file IOS-S360-CLI.pkg plus signatures created for threats
discovered subsequently.
Just as virus checkers must constantly update their virus database, network administrators must be
vigilant and regularly update the IPS signature file. New signatures are available from Cisco.com.
A CCO login is required to retrieve signatures.


5.2.2 IPS Signature Alarms
Signature Alarm
The heart of any IPS signature is the signature alarm, often referred to as the signature trigger.
Consider a home security system. The triggering mechanism for a burglar alarm could be a motion
detector that detects the movement of an individual entering a room protected with an alarm.
The signature trigger for an IPS sensor could be anything that can reliably signal an intrusion or
security policy violation. A network IPS might trigger a signature action if it detects a packet with
140 CCNA Security Course Booklet, Version 1.0




a payload containing a specific string going to a specific port. A host-based IPS might trigger a
signature action when a specific function call is invoked. Anything that can reliably signal an in-
trusion or security policy violation can be used as a triggering mechanism.
The Cisco IDS and IPS sensors (Cisco IPS 4200 Series Sensors and Cisco Catalyst 6500 - IDSM)
can use four types of signature triggers:

Pattern-based detection



Anomaly-based detection



Policy-based detection



Honey pot-based detection



These triggering mechanisms can be applied to both atomic and composite signatures. The trigger-
ing mechanisms can be simple or complex. Every IPS incorporates signatures that use one or more
of these basic triggering mechanisms to trigger signature actions.
Another common triggering mechanism is called protocol decodes. Instead of simply looking for a
pattern anywhere in a packet, protocol decodes break down a packet into the fields of a protocol
and then search for specific patterns in a specific protocol field or some other malformed aspect of
the protocol fields. The advantage of protocol decodes is that it enables a more granular inspection
of traffic and reduces the number of false positives (traffic that generates an alert but is not a threat
to the network).
Pattern-Based Detection
Pattern-based detection, also known as signature-based detection, is the simplest triggering mecha-
nism because it searches for a specific, pre-defined pattern. A signature-based IDS or IPS sensor
compares the network traffic to a database of known attacks and triggers an alarm or prevents
communication if a match is found.
The signature trigger might be textual, binary, or even a series of function calls. It can be detected
in a single packet (atomic) or in a sequence of packets (composite). In most cases, the pattern is
matched to the signature only if the suspect packet is associated with a particular service or des-
tined to and from a particular port. This matching technique helps to lessen the amount of inspec-
tion done on every packet. However, it makes it more difficult for systems to deal with protocols
and attacks that do not utilize well-defined ports, such as Trojan Horses and their associated traf-
fic, which can move at will.
At the initial stage of incorporating pattern-based IDS or IPS, before the signatures are tuned,
there can be many false positives. After the system is tuned and adjusted to the specific network
parameters, there are fewer false positives than with a policy-based approach.
Anomaly-based Detection
Anomaly-based detection, also known as profile-based detection, involves first defining a profile
of what is considered normal for the network or host. This normal profile can be learned by moni-
toring activity on the network or specific applications on the host over a period of time. It can also
be based on a defined specification, such as an RFC. After defining normal activity, the signature
triggers an action if excessive activity occurs beyond a specified threshold that is not included in
the normal profile.
The advantage of anomaly-based detection is that new and previously unpublished attacks can be
detected. Instead of having to define a large number of signatures for various attack scenarios, the
administrator simply defines a profile for normal activity. Any activity that deviates from this pro-
file is then abnormal and triggers a signature action.
Chapter 5: Implementing Intrusion Prevention 141




Despite this obvious advantage, several disadvantages can make anomaly-based signatures hard to
use. For example, an alert from an anomaly signature does not necessarily indicate an attack. It in-
dicates only a deviation from the defined normal activity, which can sometimes occur from valid
user traffic. As the network evolves, the definition of normal usually changes, so the definition of
normal must be redefined.
Another consideration is that the administrator must guarantee that the network is free of attack
traffic during the learning phase. Otherwise, the attack activity will be considered normal traffic.
Precautions should be taken to ensure that the network is free of attacks while establishing normal
activity. However, it can be difficult to define normal traffic because most networks consist of a
heterogeneous mixture of systems, devices, and applications that continually change.
When a signature does generate an alert, it might be difficult to correlate that alert back to a spe-
cific attack, because the alert indicates only that non-normal traffic has been detected. More analy-
sis is required to determine whether the traffic represents an actual attack and what the attack
actually accomplished. In addition, if the attack traffic happens to be similar to normal traffic, the
attack might go undetected altogether.
Policy-based Detection
Policy-based detection, also known as behavior-based detection, is similar to pattern-based detec-
tion, but instead of trying to define specific patterns, the administrator defines behaviors that are
suspicious based on historical analysis.
The use of behaviors enables a single signature to cover an entire class of activities without having
to specify each individual situation. For example, having a signature that triggers an action when
an email client invokes cmd.exe enables the administrator to apply the signature to any application
whose behavior mimics the basic characteristics of an email client without having to apply the sig-
nature to each email client application individually. Therefore, if a user installs a new email appli-
cation, the signature still applies.
Honey pot-based Detection
Honey pot-based detection uses a dummy server to attract attacks. The purpose of the honey pot
approach is to distract attacks away from real network devices. By staging different types of vul-
nerabilities in the honey pot server, administrators can analyze incoming types of attacks and mali-
cious traffic patterns. They can then use this analysis to tune their sensor signatures to detect new
types of malicious network traffic. Honey pot systems are rarely used in production environments.
Anti-virus and other security vendors tend to use them for research.
Cisco has implemented IPS functions into its Cisco IOS software. Cisco IOS IPS uses technology
from Cisco IDS and IPS sensor product lines, including Cisco IPS 4200 Series Sensors and Cisco
Catalyst 6500 Series Intrusion Detection System Services Module (IDSM).
There are many benefits to using the Cisco IOS IPS solution:

It uses the underlying routing infrastructure to provide an additional layer of security.



Because Cisco IOS IPS is inline and is supported on a broad range of routing platforms,


attacks can be effectively mitigated to deny malicious traffic from both inside and outside the
network.
When used in combination with Cisco IDS, Cisco IOS Firewall, virtual private network


(VPN), and Network Admission Control (NAC) solutions, Cisco IOS IPS provides threat
protection at all entry points to the network.
It is supported by easy and effective management tools, such as Cisco SDM, Cisco Security


Monitoring, Analysis, and Response System (MARS), and Cisco Security Manager.
142 CCNA Security Course Booklet, Version 1.0




It supports approximately 2,000 attack signatures from the same signature database that is


available for Cisco IPS appliances. The amount varies depending on the amount of memory in
the router.


5.2.3 Tuning IPS Signature Alarms
Triggering False Alarms
Triggering mechanisms can generate alarms that are false positives or false negatives. These
alarms must be addressed when implementing an IPS sensor.
A false positive alarm is an expected but undesired result. A false positive alarm occurs when an
intrusion system generates an alarm after processing normal user traffic that should not have re-
sulted in the alarm. Analyzing false positives limits the time that a security analyst has to examine
actual intrusive activity on a network. If this occurs, the administrator must be sure to tune the IPS
to change these alarm types to true negatives. A true negative describes a situation in which normal
network traffic does not generate an alarm.
A false negative is when an intrusion system fails to generate an alarm after processing attack traf-
fic that the intrusion system is configured to detect. It is imperative that the intrusion system does
not generate false negatives, because it means that known attacks are not being detected. The goal
is to render these alarm types as true positive. A true positive describes a situation in which an in-
trusion system generates an alarm in response to known attack traffic.
Alarms trigger when specific parameters are met. An administrator must balance the number of in-
correct alarms that can be tolerated with the ability of the signature to detect actual intrusions. If
there are too few alarms, suspect packets might be allowed into the network, but network traffic
flows more quickly. But if IPS systems use untuned signatures, they produce many false positive
alarms.
A signature is tuned to one of four levels (listed alphabetically), based on the perceived severity of
the signature:

High - Attacks used to gain access or cause a DoS attack are detected, and an immediate


threat is extremely likely.
Informational - Activity that triggers the signature is not considered an immediate threat, but


the information provided is useful information.
Low - Abnormal network activity is detected that could be perceived as malicious, but an


immediate threat is not likely.
Medium - Abnormal network activity is detected that could be perceived as malicious, and an


immediate threat is likely.

There are several factors to consider when implementing the alarms that a signature uses:

The level assigned to the signature determines the alarm severity level.



When tuning a signature alarm, the severity level of the signature should be the same as the


severity level of the alarm.
To minimize false positives, the administrator must study the existing network traffic patterns


and then tune the signatures to recognize intrusion patterns that are atypical (out of character).
Signature tuning should be based on the actual network traffic patterns.
Chapter 5: Implementing Intrusion Prevention 143




5.2.4 IPS Signature Actions
Whenever a signature detects the activity for which it is configured, the signature triggers one or
more actions. Several actions can be performed:

Generate an alert.



Log the activity.



Drop or prevent the activity.



Reset a TCP connection.



Block future activity.



Allow the activity.


The available actions depend on the signature type and the platform.
Generating an Alert
Monitoring the alerts generated by network-based and host-based IPS systems is vital to under-
standing the attacks being launched against the network. If an attacker causes a flood of bogus
alerts, examining these alerts can overload the security analysts. Both network- and host-based IPS
solutions incorporate two types of alerts to enable an administrator to efficiently monitor the oper-
ation of the network: atomic alerts and summary alerts. Understanding these types of alerts is criti-
cal to providing the most effective protection for a network.
Atomic Alerts
Atomic alerts are generated every time a signature triggers. In some situations, this behavior is
useful and indicates all occurrences of a specific attack. However, an attacker might be able to
flood the monitor console with alerts by generating thousands of bogus alerts against the IPS de-
vice or applications.
Summary Alerts
Instead of generating alerts for each instance of a signature, some IPS solutions enable the admin-
istrator to generate summary alerts. A summary alert is a single alert that indicates multiple occur-
rences of the same signature from the same source address or port. Alarm summary modes limit
the number of alerts generated and make it difficult for an attacker to consume resources on the
sensor.
With the summarization modes, the administrator also receives information on the number of
times that the activity that matches a signature™s characteristics was observed during a specific pe-
riod of time. When using alarm summarization, the first instance of intrusive activity usually trig-
gers a normal alert. Then, other instances of the same activity (duplicate alarms) are counted until
the end of the signature™s summary interval. When the length of time specified by the summary in-
terval has elapsed, a summary alarm is sent, indicating the number of alarms that occurred during
the time interval.
Some IPS solutions also enable automatic summarization even though the default behavior is to
generate atomic alerts. In this situation, if the number of atomic alerts exceeds a configured thresh-
old in a specified amount of time, the signature automatically switches to generating summary
alerts instead of atomic alerts. After a defined period of time, the signature reverts to its original
configuration. Automatic summarization enables the administrator to automatically regulate the
number of alerts being generated.
As a hybrid between atomic alerts and summary alerts, some IPS solutions also enable the genera-
tion of a single atomic alert and then disable alerts for that signature and source address for a spe-
144 CCNA Security Course Booklet, Version 1.0




cific period of time. This prevents an administrator from getting overwhelmed with alerts while
still indicating that a specific system shows suspicious activity.
Logging the Activity
In some situations, an administrator does not necessarily have enough information to stop an activ-
ity. Therefore, logging the actions or packets that are seen so that they can be analyzed later in
more detail is very important. By performing a detailed analysis, an administrator can identify ex-
actly what is taking place and make a decision as to whether it should be allowed or denied in the
future.
For example, if an administrator configures a signature to look for the string /etc/password and to
log the action with the attacker™s IP address whenever the signature triggers, the IPS device begins
logging the traffic from the attacker™s IP address for a specified period of time or number of bytes.
This log information is usually stored on the IPS device in a specific file. Because the signature
also generates an alert, the administrator can observe the alert on the management console. Then
the log data can be retrieved from the IPS device, and the activity that the attacker performed on
the network after triggering the initial alarm can be analyzed.
Dropping or Preventing the Activity
One of the most powerful actions for an IPS device is to drop packets or prevent an activity from
occurring. This action enables the device to stop an attack before it has the chance to perform ma-
licious activity. Unlike a traditional IDS device, the IPS device actively forwards packets across
two of its interfaces. The analysis engine determines which packets should be forwarded and
which packets should be dropped.
Besides dropping individual packets, the drop action can be expanded to drop all packets for a spe-
cific session or even all packets from a specific host for a certain amount of time. By dropping
traffic for a connection or host, the IPS conserves resources without having to analyze each packet
separately.
Resetting a TCP Connection
The TCP Reset Signature Action is a basic action that can be used to terminate TCP connections
by generating a packet for the connection with the TCP RST flag set. Many IPS devices use the
TCP reset action to abruptly end a TCP connection that is performing unwanted operations. The
reset TCP connection action can be used in conjunction with deny packet and deny connection ac-
tions. Deny packet and deny flow actions do not automatically cause TCP reset actions to occur.
Blocking Future Activity
Most IPS devices have the capability to block future traffic by having the IPS device update the ac-
cess control lists (ACLs) on one of the infrastructure devices. The ACL stops traffic from an at-
tacking system without requiring the IPS to consume resources analyzing the traffic. After a
configured period of time, the IPS device removes the ACL. Network IPS devices usually provide
this blocking functionality along with other actions such as dropping unwanted packets. One ad-
vantage of the blocking action is that a single IPS device can stop traffic at multiple locations
throughout the network, regardless of the location of the IPS device. For example, an IPS device
located deep within the network can apply ACLs at the perimeter router or firewall.
Allowing the Activity
The final action is the Allow Signature action. It might seem a little confusing, because most IPS
devices are designed to stop or prevent unwanted traffic on a network. The allow action is neces-
sary so that an administrator can define exceptions to configured signatures. By dropping traffic
for a connection or host, the IPS conserves resources without having to analyze each packet sepa-
Chapter 5: Implementing Intrusion Prevention 145




rately. Configuring exceptions enables administrators to take a more restrictive approach to secu-
rity because they can first deny everything and then allow only the activities that are needed.
For example, suppose that the IT department routinely scans its network using a common vulnera-
bility scanner. This scanning causes the IPS to trigger various alerts. These are the same alerts that
the IPS generates if an attacker scans the network. By allowing the alerts from the approved IT
scanning host, an administrator can protect the network from intrusive scans while eliminating the
false positives generated by the routine IT-approved scanning.
Some IPS devices provide the allow action indirectly through other mechanisms, such as signature
filters. If an IPS does not provide the allow action directly through an action such as permit or
allow, the administrator needs to search the product documentation to find the mechanism used to
enable exceptions to signatures.


5.2.5 Managing and Monitoring IPS
Monitoring the security-related events on a network is also a crucial aspect of protecting a network
from attack. Although an IPS can prevent numerous attacks against a network, understanding
which attacks are being launched against the network enables an administrator to assess how
strong the current protections are and what enhancements may be required as the network grows.
Only by monitoring the security events on a network can an administrator accurately identify the
attacks and security policy violations that are occurring.
Management Method
IPS sensors can be managed individually or centrally. Configuring each IPS device individually is
the easiest process if there are only a couple of sensors. For example, a network deploying Cisco
IOS IPS on a few routers could be managed using SDM. Managing many IPS routers and IPS sen-
sors individually becomes difficult and time-consuming.
In a larger network, a centralized management system that allows the administrator to configure
and manage all IPS devices from a single central system should be deployed. Using a centralized
management approach for large sensor deployments reduces time and staffing requirements and
enables greater visibility to all events occurring on a network.
Event correlation

<<

. 6
( 19)



>>