IPS Opera on and Implementa on

IPS Signatures
12.1.1 IPS Signature A ributes

The network must be able to iden fy incoming malicious traffic in order to stop it. Fortunately,
malicious traffic displays dis nct characteris cs or “signatures”.

Conceptually similar to the virus.dat file used by virus scanners, a signature is a set of rules that an
IDS and an IPS use to detect typical intrusion ac vity. Signatures uniquely iden fy specific viruses,
worms, protocol anomalies, and malicious traffic (e.g., a DoS a acks).

A malicious packet flow has a specific type of ac vity and signature. IPS sensors must be tuned to
look for matching signatures or abnormal traffic pa erns. As sensors scan network packets, they use
signatures to detect known a acks and respond with predefined ac ons. An IDS or IPS sensor
examines the data flow using many different signatures. A sensor takes ac on when it matches a
signature with a data flow, such as logging the event or sending an alarm to the IDS or IPS
management so ware.

Signatures also have three dis nc ve a ributes:

 Type - Atomic or Composite

 Trigger - Also called the alarm

 Ac on - What the IPS will do

12.1.2 Types of Signatures

Some threats can be iden fied in one packet while other threats may require many packets and their
state informa on (i.e., IP addresses, port numbers, and more) to iden fy a threat.

There are two types of signatures:

 Atomic Signature - This is the simplest type of signature because a single packet, ac vity, or
event iden fies an a ack. The IPS does not need to maintain state informa on and traffic
analysis can usually be performed very quickly and efficiently.

 Composite Signature - Also called a stateful signature because the IPS requires several pieces
of data to match an a ack signature. The IPS must also maintain state informa on, which is
referred to as the event horizon. The length of an event horizon varies from one signature to
the next.

12.1.3 IPS Signature Alarms

The heart of any IPS signature is the signature alarm, which is o en referred to as the signature
trigger. The signature alarm (i.e., trigger) for an IPS sensor could be anything that can reliably signal
an intrusion or security policy viola on. A network-based IPS might trigger a signature ac on if it
detects a packet with a payload containing a specific string that is going to a specific TCP port, for
example.
The IPS signature alarm is analogous to the alarm in a home security system. The triggering
mechanism for a burglar alarm could be a mo on detector. When the burgler alarm is enabled, the
movement of an individual entering a room is detected. This triggers the alarm.

These triggering mechanisms can be applied to atomic and composite signatures. The triggering
mechanisms can be simple or complex. Every IPS incorporates signatures that use one or more of
these basic triggering mechanisms to trigger signature ac ons.

There are four general IPS signature trigger categories as listed in the table.

Detec on Type Advantages

 Also known as signature-based detec on.

 Simplest triggering mechanism as it searches for a specific and pre-defined

Pa ern-Based Detec on atomic or composite pa ern.

 A IPS sensor compares the network traffic to a database of known a acks, and
triggers an alarm or prevents communica on if a match is found.

 Also known as profile-based detec on.

 Involves first defining a profile of what is considered normal network or host

ac vity.
Anomaly-Based
Detec on  This normal profile is usually defined by monitoring traffic and establishing a
baseline.

 Once defined, any ac vity beyond a specified threshold in the normal profile
will generate a signature trigger and ac on.

 Also known as behavior-based detec on.

 Although similar to pa ern-based detec on, an administrator manually

Policy-Based Detec on defines behaviors that are suspicious based on historical analysis.

 The use of behaviors enables a single signature to cover an en re class of

ac vi es without having to specify each individual situa on.

 Honey pot-based detec on uses a server as a decoy server to a ract a acks.

Honey Pot-Based  The purpose of a decoy server is to lure a acks away from produc on devices.
Detec on
 Allows administrators me to analyze incoming a acks and malicious traffic
pa erns to tune their sensor signatures.

12.1.4 IPS Signature Ac ons

When a signature detects the ac vity for which it is configured, the signature triggers one or more
ac ons.

Depending on the IPS sensor, various ac ons can be enabled. The table lists some ac ons that an IPS
sensor may provide.
Note: The available ac ons depend on the signature type and the pla orm.

Alert Category Specific Ac on Descrip on

Produce alert The IPS sends events as alerts.

Generate an alert
Produce verbose alert The IPS sends a detailed event alert.

Log a acker packets Logs packets from the a acker IP address and sends an alert.

Log the ac vity Logs packets from the vic m and a acker IP addresses and
Log pair packets
sends an alert.

Log vic m packets Logs packets from the vic m IP address and sends an alert.

Deny packet inline Terminates the packet.

Terminates the current packet and future packets on this TCP

Deny the ac vity Deny connec on inline
flow.

Terminates the current packet and future packets from this

Deny a acker inline
a acker address for a specified period of me.

Reset the TCP

Reset TCP connec on Sends TCP resets to hijack and terminate the TCP flow.
connec on

Request block connec on Sends a request to a blocking device to block this connec on.

Block future Sends a request to a blocking device to block this a acker

Request block host
ac vity host.

Sends a request to the no fica on applica on component of

Request SNMP trap
the sensor to perform SNMP no fica on.

12.1.5 Evalua ng Alerts

Triggering mechanisms can generate alarms that are false posi ves or false nega ves. These alarms
must be addressed when implemen ng an IPS sensor. True posi ves and true nega ves are desirable
and indicate the IPS is func oning properly. False posi ves and false nega ves are undesirable and
must be inves gated.

The table summarizes the following four types of alarms:

 Alarm
Network Ac vity IPS Ac vity Outcome
Type

True
A ack traffic Alarm generated Ideal se ng
posi ve

True
Normal user traffic No alarm generated Ideal se ng
nega ve

False
Normal user traffic Alarm generated Tune alarm
posi ve

False
A ack traffic No alarm generated Tune alarm
nega ve

Alerts can be classified as follows:

 True posi ve - (Desirable) This is used when the IPS generates an alarm because it detected
known a ack traffic. The alert has been verified to be an actual security incident and also
indicates that the IPS rule worked correctly.

 True nega ve - (Desirable) This is used when the system is performing as expected. No alerts
are issued because the traffic that is passing through the system is clear of threats.

 False posi ve - (Undesirable) This is used when an IPS generates an alarm a er processing
normal user traffic that should not have triggered an alarm. The IPS must be tuned to change
these alarm types to true nega ves. The alert does not indicate an actual security incident.
Benign ac vity that results in a false posi ve is some mes referred to as a benign trigger.
False posi ves are costly because they must be inves gated.

 False nega ve - (Dangerous) This is used when an IPS fails to generate an alarm and known
a acks are not being detected. This means that exploits are not being detected by the
security systems that are in place. These incidents could go undetected for a long me, and
ongoing data loss and damage could result. The goal is for these alarm types to generate true
posi ve alarms.
Cisco Snort IPS
12.2.1 IPS Service Op ons

Intrusion preven on services were available on the first-genera on Integrated Services Routers (ISR
G1) using the Cisco IOS IPS. Cisco IOS IPS monitored and prevented intrusions by comparing traffic
against signatures of known threats and blocking the traffic when a threat was detected.

Note: Support for Cisco IOS IPS discon nued in 2018. Therefore, IOS IPS is no longer
recommended on branch routers.

Organiza ons now have three op ons available to provide intrusion preven on services.

 Cisco Firepower Next-Genera on IPS (NGIPS) - These are dedicated in-line threat preven on
appliances that provide industry leading effec veness against both known and unknown
threats.

 Cisco Snort IPS - This is an IPS service that can be enabled on a second genera on ISR (ISR
G2) (i.e., ISR 4000s). Note that Cisco 4000 ISRs no longer support Cisco IOS IPS.

 External Snort IPS Server - This is similar to the Cisco Snort IPS solu on but requires a
promiscuous port (i.e., a SPAN switch port) and an external Snort IDS/IPS.

All three IPS services use Snort and receive rule updates from Cisco Talos.

12.2.2 NGIPS

NGIPSs are dedicated IPS appliances. They are built on Snort's core open technology and use
vulnerability-focused IPS rules and embedded IP-, URL-, and DNS-based security intelligence provided
by Cisco Talos.

NGIPS features include the following:

 IPS rules that iden fy and block a ack traffic targeted at network vulnerabili es.

 Tightly integrated defense against advanced malware by incorpora ng advanced analysis of

network and endpoint ac vity.

 Sandboxing technology that uses hundreds of behavioral indicators to iden fy zero-day and
evasive a acks.

 Also includes Applica on Visibility and Control (AVC), Cisco Advanced Malware Protec on
(AMP) for Networks, and URL Filtering.

Note: Further discussion of NGIPS appliances is out of scope for this course.

12.2.3 Snort IPS

Snort is an open source network IPS that performs real- me traffic analysis and generates alerts
when threats are detected on IP networks. It can also perform protocol analysis, content searching or
matching, and detect a variety of a acks and probes (e.g., buffer overflows, stealth port scans, and
more). Snort was inducted into the InfoWorld Open Source Hall of Fame as one greatest pieces of
open source so ware ever.

The Snort engine can now run as a virtual container service on Cisco 4000 ISRs and Cisco Cloud
Services Router 1000v Series. It is ideal for smaller organiza ons looking for a cost-effec ve rou ng
and threat defense solu on. For instance, an ISR G2 can provide advanced rou ng capabili es and
integrated threat defense security using Snort IPS.

Snort IPS can be implemented with other security features integrated into the 4000 Series ISRs, such
as VPN, zone-based Cisco IOS firewalls, and Cisco Cloud Web Security. This enables the ISR to provide
comprehensive threat protec on in a small footprint. This is crucial for small branch loca ons that
need to address security for the local internet connec on. Snort IPS integrated in an ISR is a cost-
effec ve alterna ve for branch office loca ons because a separate firewall device is not required.

Snort IPS on the 4000 Series ISR provides the following func onali es:

 IDS and IPS mode - Configure threat detec on or preven on mode. In preven on mode,
a ack traffic will be dropped.

 Three signature levels - Snort provides three levels of signature protec on: connec vity
(least secure), balanced (middle op on), and security (most secure). The security level is the
most secure as it enables the highest number of signatures to be verified.

 An allowed list - This provides the ability to turn off certain signatures and helps to avoid
false posi ves such as legi mate traffic triggering an IPS ac on. Up to 1000 entries can be
supported in the allowed list.

 Snort health monitoring - Cisco IOS So ware keeps track of the health of the Snort engine
that is running in the service container.

 Fail open and close - In the event of IPS engine failure, the router can be configured to block
the traffic flow or to bypass IPS checking un l the Snort engine recovers.

 Signature update - Automa c and manual updates are supported. Snort IPS can download
the signature package directly from cisco.com or a local resource loca on over HTTP and
HTTPS.

 Event logging - IPS logs can be sent to an independent log collector or included along with
the router syslog stream. Sending IPS logs separately helps if the security event management
tool is different from the regular syslog server.

12.2.4 Snort Components and Rules

Snort IPS for 4000 Series ISRs consists of two components:

 Snort engine - This is the IPS detec on and enforcement engine that is included in the
Security (SEC) license for 4000 Series ISRs.

 Snort rule so ware subscrip ons for signature updates - Snort rule sets to keep current
with the latest threat protec on are term-based subscrip ons, available for one or three
years.

To address the rapidly evolving threat landscape, it is important to ensure that signatures are
as up-to-date as possible.

There are two types of term-based subscrip ons:

 Community Rule Set - Available for free, this subscrip on offers limited coverage against
threats. The community rule set focuses on reac ve response to security threats versus
proac ve research work. There is also a 30-day delayed access to updated signatures
 meaning that newest rule will be a minimum of 30 days old. In addi on, there is no Cisco
customer support available.

 Subscriber Rule Set - Available for a fee, this service provides the best protec on against
threats. It includes coverage of advance exploits by using the research work of the Cisco
Talos security experts. The Subscriber Rule Set also provides the fastest access to updated
signatures in response to a security incident or the proac ve discovery of a new threat. This
subscrip on is fully supported by Cisco.

Note: Contact Cisco Support to obtain the subscriber rule set license.

12.2.5 ISR Container Applica ons

Routers were ini ally packet processing devices. However, over the years, they have evolved to
perform many compu ng func ons. Routers have acquired so much processing power that server
applica ons can now be hosted inside the router using virtual machines called service containers.

Applica ons such as Snort IPS can be uploaded and hosted on these routers. Service containers are
supported on most IOS XE pla orms. IOS XE is based on the Linux architecture and supports virtual
machine hos ng.

The Snort engine runs as a Linux Service Container applica on on the ISR 4000 as shown in the
figure. This provides it with dedicated compu ng resources that run independently of the data plane
CPU load. It also makes it easier for the Snort engine to be regularly updated.

Specifically, the Snort engine on the 4000 Series ISR runs as a container applica on. The 4000 Series
ISR uses a mul -core CPU, and the Cisco IOS-XE has the ability to allocate these cores for control-
plane or data-plane func ons. Compu ng resources unused by control plane func ons can be used
for running other services. A Linux container infrastructure hosts these applica ons. Applica ons
running in this container infrastructure can have a ghter integra on with Cisco IOS So ware.

12.2.6 Snort IPS Rule Alarms

In Snort IPS, signatures are configured using “rules”. These rules serve as the signature alarms by
comparing incoming traffic to the Snort rules. Traffic matching a rule header generates an ac on.

A rule header is conceptually similar to an access control list (ACL) statement. It is a one line
statement that iden fies malicious traffic.

The basic rule header command syntax is:

[ac on] [protocol] [sourceIP] [sourceport] -> [destIP] [destport] ([Rule op ons])

Note: The Rule op ons contain addi onal rule informa on.

For example, the following sample header generates an alert whenever a TCP connec on for the
hosts/ports iden fied in the rule header variables are going to the iden fied des na on hosts/ports
variables:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any

Refer to the figure for a detailed explana on of this example.

12.2.7 Snort IPS Rule Ac ons

Snort can be enabled in IDS mode or in IPS mode.

Snort IDS mode can perform the following three ac ons:

 Alert - Generate an alert using the selected alert method.

 Log - Log the packet.

 Pass - Ignore the packet.

Snort IPS mode can perform all the IDS ac ons plus the following:

 Drop - Block and log the packet.

 Reject - Block the packet, log it, and then send a TCP reset if the protocol is TCP or an ICMP
port unreachable message if the protocol is UDP.

 Sdrop - Block the packet but do not log it.

12.2.8 Snort IPS Header Rule Op ons

A Snort rule header also contains rule op ons (fields) to provide addi onal informa on for the rule.
Op ons are separated by semicolons (;) and the rule op on keywords are separated from their
arguments using colons (:).
The figure displays sample rule op ons for the alert tcp $EXTERNAL_NET $HTTP_PORTS -
> $HOME_NET any rule header.

The table describes the common general rule and the detec on rule op ons in the sample rule
header.

Note: These are just a few of the different types of rule op ons. For more examples, search the
internet for "snort rule op ons"

Rule Op on Specific Ac on

This is a simple text string that provides a meaningful message to output when the rule
msg:
matches.

flow: Specifies the direc on of network traffic.

A detec on rule op on that allows the rule creator to set rules that search for specific
content: content in the packet payload and trigger response based on that data. This op on data
can contain mixed text and binary data

distance: / Detec on rule keywords that allow the rule creator to specify where to start searching
offset: rela ve to the beginning of the payload or the beginning of a content match.

Detec on rule keywords that allow the rule creator to specify how far forward to search
within: / depth: rela ve to the end of a previous content match and, once that content match is found,
how far to search for it.
 Rule Op on Specific Ac on

A detec on rule keyword that allows rules to be wri en using “perl compa ble regular
pcre
expressions” which allows for more complex matches.

A detec on rule keyword that allows a rule to test a number of bytes against a specific
byte_test
value in binary.

metadata: Allows a rule creator to embed addi onal informa on about the rule.

reference: Allows rules to include references to external sources of informa on.

classtype: Iden fies the poten al effect of what a successful a ack would be.

The signature ID (sid) is a unique iden fier for each rule making them easy to iden fy. It
sid / rev should be used with the rev (revision) keyword to indicate the current version of the
rule.

12.2.9 Snort IPS Opera on

Packets arriving on Snort enabled interfaces are inspected as follows:

1. Cisco IOS So ware forwards the packets to be inspected to the Snort IPS engine using an
internal virtual port group (VPG) interface.

2. Snort IPS inspects the traffic and takes necessary ac on.

3. Snort drops the packets associated with bad flows (IPS mode). Good flow packets are
returned back to the router for further processing.

Packet exchange between the container applica ons and the IOS data plane is done using VPG
interfaces. These routed interfaces are connected through the router back plane. The corresponding
interface on the container side will appear as virtual Ethernet ports.

Snort IPS requires two VPG interfaces:

 Management interface - This is the interface that is used to source logs to the log collector
and for retrieving signature updates from Cisco.com. For this reason, this interface requires a
routable IP address.

 Data interface - This is the interface that is used to send user traffic between the Snort
virtual container service and the router forwarding plane.

In the figure, VPG0 is used for Snort management traffic while VPG1 is used for user traffic to be
inspected. User traffic to be inspected is forwarded to the Snort engine using VPG1 as shown. Traffic
is then inspected and either rejected (dropped) or forwarded back to the router as shown.
Configure Snort IPS
12.3.1 Snort IPS Configura on Steps

To deploy Snort IPS on supported devices, perform the following steps:

Step 1. Download the Snort OVA file.

Step 2. Install the OVA file.
Step 3. Configure Virtual Port Group interfaces.
Step 4. Ac vate the virtual services.
Step 5. Configure Snort specifics.
Step 6. Enable IPS globally or on desired interfaces.
Step 7. Verify Snort IPS.

Note: The Snort IPS func onality is available only in security K9-licensed IOS XE version. The security
license s required to enable the service. This feature is available in Cisco IOS XE Release 3.16.1S,
3.17S, and later releases.

12.3.2 Step 1. Download the Snort OVA File

An Open Virtualiza on Archive (OVA) is a file that contains a compressed, installable version of a
virtual machine. The Snort service OVA file is not bundled with the Cisco IOS XE Release images
installed on the router. However, if the OVA file is be preinstalled in the flash of the router, it is
recommended that the latest OVA file be downloaded from Cisco.com.

For example, in the figure, the user is downloading the OVA file for an ISR 4321 router using IOS Fuji-
16.9.6.
Note: CCO access is required to download files from Cisco.com.

12.3.3 Step 2. Install the Snort OVA File

The OVA file must be downloaded and saved in a file loca on available to the ISR router (e.g., Flash).

To install the OVA file, use the virtual-service install name virtual-service-name package file-
url media file-system privilege EXEC command. The length of the name is 20 characters and the
complete path to the OVA file must be specified.

An example configura on is shown below.

During the OVA file installa on, the security license is checked and an error is reported if the license
is not present. Therefore, the Cisco IOS XE image must be enabled with the security license. In the
output, you can see that the OVA is Cisco signed.

Use the show virtual-service list command to display the status of the installa on of all applica ons
installed on the virtual service container.
12.3.4 Step 3. Configure Virtual Port Group Interfaces

Two VirtualPortGroup (VPG) interfaces must then be configured along with their guest IP addresses.

In our example, the VPG interfaces will be configured as follows:

 VGP0 - This is for management traffic to exchange informa on with IPS servers. The guest IP
address needs to be routable to connect to the signature update server and external log
server. It is also used to log traffic to log collectors.

 VPG1 - This is for user traffic marked for inspec ons. This should not be routable and
therefore use a non-routable private IP address.

Note: Be sure to provide proper NAT and rou ng to enable the management VPG to reach the log
server as well as cisco.com to retrieve signature update files.

The following is a sample configura on of VPG0 and VPG1.

12.3.5 Step 4. Ac vate Virtual Services

The next step is to configure guest IPs on the same subnet for the container side and ac vate the
virtual service as shown in the output.

The virtual-service virtual-service-name command configures the logical name, MYIPS in the
example, that is used to iden fy the virtual container service.

The vnic gateway VirtualPortGroup interface-number command creates a virtual network interface
card (vNIC) gateway interface for the virtual container service. It also maps the vNIC gateway
interface to the virtual port group, and enters the virtual-service vNIC configura on mode.
The guest ip address ip-address command configures a guest vNIC address for the vNIC gateway
interface.

Finally, the ac vate command ac vates the applica on installed in a virtual container service.

12.3.6 Step 5. Configure Snort Specifics

Next is to configure how Snort is to be deployed (i.e. IPS or IDS mode), where the Snort logs should
be sent, the policy and profile to configure for Snort, and more.

Refer to the sample command output.

The utd engine standard command configures the UTD standard engine and enters UTD standard
engine configura on mode.

The logging host and logging syslog commands enable the logging of emergency messages to a
server.

The threat-inspec on command configures threat inspec on for the Snort engine. From here you
can specify which mode Snort will be in:

 threat protec on - Snort will be in IPS mode.

 threat detec on - Snort will be in IDS mode.

The policy command specifies three security policies used by Snort and provided by Cisco Talos, as
shown in the following help facility example.

The three policy se ngs in order from least protec on to most protec on are:

 connec vity - This provides the least protec on as it priori zes connec vity over security.
Approximately 1,000 rules are pre-loaded using this policy.
  balanced - This is the default policy. It is recommended for ini al deployments. This policy
a empts to balance security needs and performance characteris cs of the network.
Approximately 8,000 rules are pre-loaded using this policy.

 security - This provides the most protec on. It is designed for organiza ons that are
excep onally concerned about security. Customers deploy this policy in protected networks,
that have a lower bandwidth requirements, but much higher security requirements.
Approximately 12,000 rules are pre-loaded using this policy.

Note: IPS system performance is nega vely affected as more rules are enabled.

The signature update command configures the signature update interval parameters. In our sample
output, Snort will update its signatures every night at midnight.

The signature update server command configures the signature update server parameters. You must
specify the signature update parameters with the server details. If you use Cisco.com for signature
updates, you must provide the username and password. If you use local server for signature updates,
based on the server se ngs you can provide the username and password. In our sample output,
Snort updates its signature file from cisco.com using the username Bob and password class.

Finally the logging level command specifies the types of syslog messages that will be generated.

12.3.7 Step 6. Enable IPS Globally or on Desired Interfaces

Based on the organiza onal requirements, Snort can be enabled globally (i.e., on all the interfaces)
or on selected interfaces.

The example in the output enables UTD globally on all interfaces and defines what to do if the Snort
engine fails.

The all-interfaces op on configures unified threat defense (UTD) on all Layer 3 interfaces of the
device.

The engine standard command configures the Snort-based UTD engine and enters standard engine
configura on mode. From this mode, we can specify how Snort will behave if there is a UTD engine
failure.

Specifically, Snort can be configured to:

 fail-open (default) - When there is a UTD engine failure, this op on allows all of the IPS/IDS
traffic through without being inspected.

 fail-close - If enabled, this op on drops all the IPS/IDS traffic when there is an UTD engine
failure. Therefore, no traffic will be allowed to leave.

Alterna vely, Snort could be enabled only on select interfaces as shown.

Note: An error message will be displayed if the global configura on was first configured.

You can also enable the UTD allowed list feature. This enables you to iden fy IPS signature IDs to be
suppressed (not used).

For example, when an IPS is incorrectly iden fying normal user traffic as a threat (i.e., a false
posi ve), we can add those signatures to an allowed list. The IPS will not use signatures in the
allowlist.

To do so, enter UTD allowed list configura on mode and iden fy signature IDs to be excluded from
inspec on. A er the allowed list signature ID is configured, Snort will allow the flow to pass through
the device without any alerts and drops.

For example, assume that the IPS has incorrectly iden fied user traffic from Branch1 as malicious
and assigned it id 21555. This signature can be added to an allowed list, as shown.

12.3.8 Step 7. Verify Snort IPS

A er Snort IPS is implemented, it is necessary to verify the configura on to ensure correct opera on.

There are several show commands that can be used to verify the Snort IPS configura on and
opera on.

 show virtual-service list - The command displays an overview of resources that are u lized
by the applica ons.

 show virtual-service detail - The command displays a list of resources that are commi ed to
a specified applica on, including a ached devices.

 show utd engine standard config - The command displays the UTD configura on.

 show utd engine standard status - The command displays the status of the UTD engine.

 show pla orm hardware qfp ac ve feature utd stats - The command checks the data plane.
It verifies increments for encap, decap, redirect, and reinject and displays a health of
"Green".

12.3.9 Syntax Checker - Configure Snort IPS

In this Syntax Checker ac vity, you will complete Steps 2 - 6 to configure snort IPS:

Step 2. Install the Snort OVA file.

Step 3. Configure Virtual Port Group interfaces.
Step 4. Ac vate the virtual services.
Step 5. Configure Snort specifics.
Step 6. Enable IPS globally or on desired interfaces.

Step 1 is to download to Snort OVA file from cisco.com.

Step 2: Install the OVA file iosxe-utd.16.09.06.1.0.10_SV29130_XE_16_9.ova in flash. Use the virtual
service name MYIPS.

R1#virtual-service install name MYIPS package flash:iosxe-

utd.16.09.06.1.0.10_SV29130_XE_16_9.ova

Installing package 'boo lash:/iosxe-utd.16.09.06.1.0.10_SV29130_XE_16_9.ova' for virtual-service

'MYIPS'. Once the install has finished, the VM may be ac vated. Use 'show virtual-service list' for
progress.

R1#

*Oct 5 08:07:45.953: %VMAN-5-PACKAGE_SIGNING_LEVEL_ON_INSTALL: R0/0: vman: Package

'iosxe-utd.16.09.06.1.0.10_SV29130_XE_16_9.ova' for service container 'MYIPS' is 'Cisco signed',
signing level cached on original install is 'Cisco signed'

Step 3: Configure Virtual Port Group interfaces using the following specifica ons:

 Enter global configura on mode and then interface configura on mode

for VirtualPortGroup0.

 Describe the interface as Management interface.

 Assign the IP address 209.165.201.1 255.255.255.252.

 Exit interface configura on mode.

R1#configure terminal

R1(config)#interface VirtualPortGroup0

R1(config-if)#descrip on Management interface

R1(config-if)#ip address 209.165.201.1 255.255.255.252

R1(config-if)#exit

R1(config)#

*Oct 5 08:13:10.970: %LINEPROTO-5-UPDOWN: Line protocol on Interface VirtualPortGroup0,

changed state to up

 Enter interface configura on mode for VirtualPortGroup1.

 Describe the interface as Data interface.

 Assign the IP address 192.168.0.1 255.255.255.252.

 Exit interface configura on mode.

R1(config)#interface VirtualPortGroup1
R1(config-if)#descrip on Data interface

R1(config-if)#ip address 192.168.0.1 255.255.255.252

R1(config-if)#exit

R1(config)#

*Oct 5 08:13:12.921: %LINEPROTO-5-UPDOWN: Line protocol on Interface VirtualPortGroup1,

changed state to up

Step 4: Ac vate the virtual services using the following specifica ons:

 Name the virtual service MYIPS

 Create a vNIC for VirtualPortGroup0.

 Assign the vNIC the guest IP address 209.165.201.2.

 Exit vNIC configura on mode.

 Create a vNIC for VirtualPortGroup1.

 Assign the vNIC the guest IP address 192.168.0.2.

 Exit vNIC configura on mode.

 Ac vate the virtual service.

 Exit virtual service configura on mode.

R1(config)#virtual-service MYIPS

R1(config-virt-serv)#vnic gateway VirtualPortGroup0

R1(config-virt-serv-vnic)#guest ip address 209.165.201.2

R1(config-virt-serv-vnic)#exit

R1(config-virt-serv)#vnic gateway VirtualPortGroup1

R1(config-virt-serv-vnic)#guest ip address 192.168.0.2

R1(config-virt-serv-vnic)#exit

R1(config-virt-serv)#ac vate

R1(config-virt-serv)#exit

Step 5. Configure snort specifics using the following specifica ons:

 Enter configura on mode for the UTD engine.

 Log traffic from host 10.10.10.254 using syslog.

 Enter threat inspec on mode.

 Set the inspec on to protec on with a balanced policy.

 Configure the signature update for daily at 0 0.

  Configure the username Bob and password class for the signature update server.

 Enter exit twice to return to global configura on mode.

R1(config)#utd engine standard

R1(config-utd-eng-std)#logging host 10.10.10.254

R1(config-utd-eng-std)#logging syslog

R1(config-utd-eng-std)#threat-inspec on

R1(config-utd-engstd-insp)#threat protec on

R1(config-utd-engstd-insp)#policy balanced

R1(config-utd-engstd-insp)#signature update occur-at daily 0 0

R1(config-utd-engstd-insp)#signature update server cisco username Bob password class

R1(config-utd-engstd-insp)#logging level warning

R1(config-utd-engstd-insp)#exit

R1(config-utd-eng-std)#exit

Step 6. Enable IPS globally or on desired interfaces using the following specifica ons:

 Enter configura on mode for UTD interfaces.

 Configure all interfaces as UTD interfaces.

 Set the engine to standard.

 If the UTD engine fails, all traffic should be dropped.

 Enter exit twice to return to global configura on mode.

 Enable UTD on G0/0/0 and G0/0/1 exi ng interface configura on mode each me.

R1(config)#utd

R1(config-utd)#all-interfaces

R1(config-utd)#engine standard

R1(config-engine-std)#fail close

R1(config-engine-std)#exit

R1(config-utd)#exit

R1(config)#interface G0/0/0

R1(config-if)#utd enable

R1(config-if)#exit

R1(config)#interface G0/0/1

R1(config-if)#utd enable
R1(config-if)#exit

Alterna vely, you can enable Snort on specific interfaces. Enable Snort on
the G0/0/0 and G0/0/1 interfaces. Exit interface configura on mode a er configuring each interface.

R1(config)#interface G0/0/0

R1(config-if)#utd enable

R1(config-if)#exit

R1(config)#interface G0/0/1

R1(config-if)#utd enable

R1(config-if)#exit

**Step 7** is to verify your Snort configura on which is beyond the scope of this ac vity. You
successfully configured Snort IPS.

IPS Opera on and Implementa on Summary

12.4.1 What Did I Learn in this Module?

IPS Signatures
IPS signatures have three a ributes: type, trigger, and ac on. The signature type can be atomic or
composite. The signature alarms can use pa ern-based detec on, anomaly-based detec on, policy-
based detec on, or honey pot-based detec on. The IPS signature ac ons include generate an alert,
log the ac vity, deny the ac vity, reset the TCP connec on, and block future ac vity. Triggering
mechanisms can generate results such as true posi ve, true posi ve, false nega ves, and false
nega ves.

Cisco Snort IPS

Intrusion protec on is provided in modern Cisco networks using either dedicated NGIPS Firepower
enabled devices, Snort IPS on ISR 4000 routers, or using an external Snort IPS server. Snort IPS on ISR
device can provide both IDS or IPS services. It has predefined security levels (i.e., connec vity,
balanced, and security). It can refer to a allowed list, provide feedback on the health of the Snort
engine, offer fail-open and fail-close failover, and automated signature updates and logging. Snort IPS
consists of a Snort engine and Snort rule set. There are community rules available for free and
subscriber rules available for a fee. Snort IPS runs in a Linux service container VM supported by ISR
4000 routers. Snort IPS uses rules consis ng of rule headers and rule op ons to iden fy malicious
traffic.

Configure Snort IPS

To configure Snort IPS on an ISR 4000 device, you must download the latest OVA file, install it on the
router, configure VPG interfaces, ac vate the virtual services, configure Snort IPS specifics, and
enable UTD. A er Snort is configured and ac vated, show commands allow verifica on of its
opera on.