CISCO IDS Student Guide PDF

CSIDS
Cisco Secure Intrusion

Detection System
Version 2.1
Student Guide
Text Part Number: 67-0002-01
Cisco Systems, Inc.

170 W Tasman Drive
San Jose, CA 95134-1706 USA
The products and specifications, configurations, and other technical information regarding the products in this
manual are subject to change without notice. All statements, technical information, and recommendations in this
manual are believed to be accurate but are presented without warranty of any kind, express or implied. You must
take full responsibility for their application of any products specified in this manual.
LICENSE
PLEASE READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THE MANUAL,
DOCUMENTATION, AND/OR SOFTWARE (MATERIALS). BY USING THE MATERIALS YOU AGREE
TO BE BOUND BY THE TERMS AND CONDITIONS OF THIS LICENSE. IF YOU DO NOT AGREE WITH
THE TERMS OF THIS LICENSE, PROMPTLY RETURN THE UNUSED MATERIALS (WITH PROOF OF
PAYMENT) TO THE PLACE OF PURCHASE FOR A FULL REFUND.
Cisco Systems, Inc. (Cisco) and its suppliers grant to you (You) a nonexclusive and nontransferable license
to use the Cisco Materials solely for Your own personal use. If the Materials include Cisco software (Software),
Cisco grants to You a nonexclusive and nontransferable license to use the Software in object code form solely on
a single central processing unit owned or leased by You or otherwise embedded in equipment provided by Cisco.
You may make one (1) archival copy of the Software provided. You affix to such copy all copyright,
confidentiality, and proprietary notices that appear on the original. EXCEPT AS EXPRESSLY AUTHORIZED
ABOVE, YOU SHALL NOT: COPY, IN WHOLE OR IN PART, MATERIALS; MODIFY THE SOFTWARE;
REVERSE COMPILE OR REVERSE ASSEMBLE ALL OR ANY PORTION OF THE SOFTWARE; OR
RENT, LEASE, DISTRIBUTE, SELL, OR CREATE DERIVATIVE WORKS OF THE MATERIALS.
You agree that aspects of the licensed Materials, including the specific design and structure of individual
programs, constitute trade secrets and/or copyrighted material of Cisco. You agree not to disclose, provide, or
otherwise make available such trade secrets or copyrighted material in any form to any third party without the
prior written consent of Cisco. You agree to implement reasonable security measures to protect such trade secrets
and copyrighted Material. Title to the Materials shall remain solely with Cisco.
This License is effective until terminated. You may terminate this License at any time by destroying all copies of
the Materials. This License will terminate immediately without notice from Cisco if You fail to comply with any
provision of this License. Upon termination, You must destroy all copies of the Materials.
Software, including technical data, is subject to U.S. export control laws, including the U.S. Export
Administration Act and its associated regulations, and may be subject to export or import regulations in other
countries. You agree to comply strictly with all such regulations and acknowledge that it has the responsibility to
obtain licenses to export, re-export, or import Software.
This License shall be governed by and construed in accordance with the laws of the State of California, United
States of America, as if performed wholly within the state and without giving effect to the principles of conflict
of law. If any portion hereof is found to be void or unenforceable, the remaining provisions of this License shall
remain in full force and effect. This License constitutes the entire License between the parties with respect to the
use of the Materials
Restricted Rights - Ciscos software is provided to non-DOD agencies with RESTRICTED RIGHTS and its
supporting documentation is provided with LIMITED RIGHTS. Use, duplication, or disclosure by the U.S.
Government is subject to the restrictions as set forth in subparagraph C of the Commercial Computer Software
- Restricted Rights clause at FAR 52.227-19. In the event the sale is to a DOD agency, the U.S. Governments
rights in software, supporting documentation, and technical data are governed by the restrictions in the Technical
Data Commercial Items clause at DFARS 252.227-7015 and DFARS 227.7202.
DISCLAIMER OF WARRANTY. ALL MATERIALS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO
AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING,
WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE
PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL,
CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS
OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL,
EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES. In no event shall Ciscos or its suppliers liability to You, whether in contract, tort (including
negligence), or otherwise, exceed the price paid by You. The foregoing limitations shall apply even if the abovestated warranty fails of its essential purpose.
The following information is for FCC compliance of Class A devices: This equipment has been tested and found
to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are
designed to provide reasonable protection against harmful interference when the equipment is operated in a
commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not
installed and used in accordance with the instruction manual, may cause harmful interference to radio
communications. Operation of this equipment in a residential area is likely to cause harmful interference, in
which case users will be required to correct the interference at their own expense.
The following information is for FCC compliance of Class B devices: The equipment described in this manual
generates and may radiate radio-frequency energy. If it is not installed in accordance with Ciscos installation
instructions, it may cause interference with radio and television reception. This equipment has been tested and
found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the
FCC rules. These specifications are designed to provide reasonable protection against such interference in a
residential installation. However, there is no guarantee that interference will not occur in a particular installation.
Modifying the equipment without Ciscos written authorization may result in the equipment no longer complying
with FCC requirements for Class A or Class B digital devices. In that event, your right to use the equipment may
be limited by FCC regulations, and you may be required to correct any interference to radio or television
communications at your own expense.
You can determine whether your equipment is causing interference by turning it off. If the interference stops, it
was probably caused by the Cisco equipment or one of its peripheral devices. If the equipment causes
interference to radio or television reception, try to correct the interference by using one or more of the following
measures:
Turn the television or radio antenna until the interference stops.
Move the equipment to one side or the other of the television or radio.
Move the equipment farther away from the television or radio.
Plug the equipment into an outlet that is on a different circuit from the television or radio. (That is, make
certain the equipment and the television or radio are on circuits controlled by different circuit breakers or fuses.)
Modifications to this product not authorized by Cisco Systems, Inc. could void the FCC approval and negate
your authority to operate the product.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University
of California, Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights
reserved. Copyright 1981, Regents of the University of California.
AccessPath, Any to Any, AtmDirector, the CCIE logo, CD-PAC, Centri, the CiscoCapital logo, CiscoLink, the
Cisco NetWorks logo, the Cisco Powered Network logo, the Cisco Press logo, ClickStart, ControlStream,
DAGAZ, Fast Step, FireRunner, IGX, IOS, JumpStart, Kernel Proxy, LoopRunner, MGX, Natural Network
Viewer, Cisco Secure IDS, NetSonar, Packet, PIX, Point and Click Internetworking, Policy Builder,
RouteStream, Secure Script, SMARTnet, SpeedRunner, Stratm, StreamView, TheCell, TrafficDirector,
TransPath, VirtualStream, VlanDirector, Workgroup Director, and Workgroup Stack are trademarks; Changing
the Way We Work, Live, Play, and Learn and Empowering the Internet Generation are service marks; and BPX,
Catalyst, Cisco, CiscoIOS, the CiscoIOS logo, CiscoSystems, the CiscoSystems logo, Enterprise/Solver,
EtherChannel, FastHub, ForeSight, FragmentFree, IP/TV, IPX, LightStream, MICA, Phase/IP, StrataSphere,
StrataView Plus, and SwitchProbe are registered trademarks of CiscoSystems,Inc. in the U.S. and certain other
countries. All other trademarks mentioned in this document are the property of their respective owners.
Cisco Secure Intrusion Detection System: Student Guide
Copyright 2001, Cisco Systems, Inc.
All rights reserved. Printed in USA.
Course Introduction
Overview
This chapter includes the following topics:
Course objectives
Course agenda
Participant responsibilities
General administration
Graphic symbols
Participant introductions
Lab topology
Course Objectives
This section introduces the course and the course objectives.
Course Objectives
Upon completion of this course, you will be
able to perform the following tasks:
Install and configure CSPM and the CIDS Sensor in
multiple network configurations.
Use CSPM to centrally manage and configure
multiple Sensors.
Configure the CIDS Sensor to detect, respond to,
and report intrusion activity.
Use CSPM to translate intrusion data into intuitive
and effective graphical displays.
Use the CIDS NSDB to view signature and

networksecurity vulnerability information.
2001, Cisco Systems, Inc.
1-2
Cisco Secure Intrusion Detection System 2.1
www.cisco.com
CSIDS 2.11-3
Course Objectives (cont.)

Develop and implement customized intrusion
detection signatures.
Configure the CIDS Sensor in device management
mode to interface with a Cisco IOS router to stop
network attacks.
Configure the Catalyst 6000 IDS Module for the
Catalyst 6000 family of switches to perform
intrusion detection in multiple VLANs.
Understand the CIDS architecture and the
relationship between configuration files and
tokens.
Configure Event Notification in CSPM and
generate Alarm Reports
www.cisco.com
CSIDS 2.11-4
Course Agenda
Chapter 1Course Introduction
Chapter 2Introduction to Network Security
Chapter 3Intrusion Detection and the Cisco
IDS Environment
Chapter 4Cisco Secure Policy Manager
Installation
Chapter 5Cisco IDS Sensor Installation
Chapter 6Alarm Management
Chapter 7Cisco IDS Signatures
www.cisco.com
CSIDS 2.11-5
Course Introduction
1-3
Course Agenda (cont.)

Chapter 8Sensor Configuration
Chapter 9Signature and Intrusion
Detection Configuration
Chapter 10IP Blocking Configuration
Chapter 11Catalyst 6000 IDS Module
Configuration
Chapter 12Cisco IDS Architecture
Chapter 13Event Notification and Alarm
Reporting
www.cisco.com
CSIDS 2.11-6
Participant Responsibilities
Student Responsibilities
Complete prerequisites
Participate in lab exercises
Ask questions
Provide feedback
1-4
www.cisco.com
CSIDS 2.11-7
General Administration
Class-related
Facilities-related
Sign-in sheet
Participant materials
Length and times
Site emergency
procedures
Break and lunch room

locations
Attire
Restrooms
Telephones/faxes
www.cisco.com
CSIDS 2.11-8
Graphic Symbols
Router
PIX
Firewall
CSPM
CIDS Director
Internet
Ethernet link
CIDS Sensor
Server
www.cisco.com
IDS Switch Module
Student
workstation/server
CSIDS 2.11-9
Course Introduction
1-5
Participant Introductions
Your name
Your company
Pre-req skills
Brief history
Objective
1-6
www.cisco.com
CSIDS 2.11-10
Lab Topology
This section explains the lab topology that is used in this course.
Lab Visual Objective

Pod P
Your Pod
Pod Q
Peer Pod
172.30.1.0 /24
e0/1 .10P
sensorP
e0/0 .1
.4
idsmP
sensorQ
e0/0 .1
.4
rQ
rP
.6
10.0.P.0 /24
CSPM
.6
idsmQ
10.0.Q.0 /24
10.0.P.3
CSPM
Host ID = 3, Org ID = P
Host Name = cspmP, Org Name = podP
e0/1 .10Q
10.0.Q.3
Host ID = 3, Org ID = Q
Host Name = cspmQ, Org Name = podQ
www.cisco.com
CSIDS 2.11-12
Each pair of students will be assigned a pod. The P in a command indicates your
pod number. The Q in a command indicates the pod number of your peer.
Course Introduction
1-7
Network Security and

Cisco Intrusion
Detection
Overview
This chapter covers information on network security, what network security is,
and why you need network security. In addition, this chapter discusses the need
for continuous network security and how the Cisco Intrusion Detection System
(CIDS) helps achieve this.
Objectives
Need for network security
Attack types and methods
The Cisco Security Wheel
Cisco AVVID and SAFE
Summary
Objectives
This section lists the chapters objectives.
Objectives
Upon completion of this chapter, you will
be able to perform the following tasks:
Describe the need for network security.
Describe the four types of security threats.
Describe attack methods and techniques used
by hackers.
Describe the purpose of the Cisco Security
Wheel and how it illustrates security as a
continuous process.
2-2 Cisco Secure Intrusion Detection System 2.1
www.cisco.com
CSIDS 2.12-2
Objectives (cont.)
Name methods and devices for securing
networks.
Identify the phase of the Security Wheel in
which CIDS is designed to function.
Describe the purpose for testing security
policies once they are applied to the network.
Describe the Cisco AVVID architecture.
Describe the SAFE framework.
www.cisco.com
CSIDS 2.12-3
Network Security and Cisco Intrusion Detection 2-3
Need for Network Security

This section explains why network security is needed.
Security Incidents on the Rise
The Internet has made

networked computers
accessible and
vulnerable to anyone
in the world.
www.cisco.com
CSIDS 2.12-5
Network security is necessary because the Internet has made networked computers
accessible from and vulnerable to any other computer in the world. As companies
become more Internet-reliant, new threats arise from persons who no longer
require physical access to a companys computer assets.
Four Basic Types of Threats

There are four primary network security
threats:
Unstructured threats
Structured threats
External threats
Internal threats
www.cisco.com
CSIDS 2.12-6
There are four primary threats to network security:
Unstructured threats
Structured threats
External threats
Internal threats
Unstructured threats consist of mostly inexperienced individuals using easily

available hacking tools such as shell scripts and password crackers.
Some of the hackers in this category are motivated by malicious intent, but most
are motivated by the intellectual challenge and fun of it and are known as script
kiddies. Script kiddies are not the most experienced or knowledgeable hackers.
They download these easily executable scripts from numerous hacker Web sites
for free. The script kiddys reasoning is: Why battle monsters in the latest
computer game when you can test your battle skills against real targets?
Even unstructured threats that are only executed with the intent of testing and
challenging a script kiddys skills can still do a lot of damage to a company. For
example, if your companys external Web site is hacked, your companys integrity
is damaged. Even if your external Web site is separate from your internal
information that sits behind a protective firewall, the public does not know that.
All they know is that if your Web site was hacked, your Web site obviously is not
safe enough to do business in.
Structured threats come from hackers who are more highly motivated and
technically competent. They know vulnerabilities, and can understand and develop
exploit-code and scripts. Typically hackers act alone or in small groups. They
understand, develop, and use sophisticated hacking techniques to penetrate
unsuspecting businesses. These groups are often involved with the major fraud
and theft cases reported to law enforcement agencies. Occasionally, these hackers
are hired by organized crime, industry competitors, or state-sponsored intelligence

organizations.
External threats are individuals or organizations working from outside of your
company. They do not have authorized access to your computer systems or
network. They work their way into a network mainly from the Internet or dialup
access servers. These are the type of threats that people spend the most time and
money protecting themselves against.
Internal threats occur when someone has authorized access to the network with
either an account on a server or physical access to the wire. They are typically
disgruntled former or current employees or contractors. According to the FBI,
internal access and misuse account for between 60 to 80 percent of reported
incidents.
The only perfectly secure computer is one that is unplugged and in a locked vault.
All computer systems and network devices must be protected.
Attack Types and Methods

This section describes the three types of attacks that intruders use to break into
networks:
Reconnaissance
Access
Denial of service
Reconnaissance
Unauthorized
discovery and
mapping of systems,
services, or
vulnerabilities
www.cisco.com
CSIDS 2.12-8
Reconnaissance is the unauthorized discovery and mapping of systems, services,

or vulnerabilities. It is also known as information gathering and, in most cases,
precedes an actual access or denial of service attack. The malicious intruder
typically ping sweeps the target network first to determine what IP addresses are
alive. After this is accomplished, the intruder determines what network services or
ports are active on the live IP addresses. From this information the intruder queries
the ports to determine the application type and version as well as the type and
version of operating system running on the target host. Based on this information,
the intruder can determine if a possible vulnerability exists that can be exploited.
Reconnaissance is somewhat analogous to a thief scoping out a neighborhood for
vulnerable homes to break into, such as an unoccupied residence, an easy-to-open
door or window, and so on. In many cases the intruders go as far as rattling the
door handle, not to go in immediately if open, but to discover vulnerable services
that they can exploit at a later time when no one is looking.
Access
Unauthorized data
manipulation, system
access, or privilege
escalation
www.cisco.com
CSIDS 2.12-9
Access is an all-encompassing term that refers to unauthorized data manipulation,

system access, or privileged escalation. Unauthorized data retrieval is simply
reading, writing, copying, or moving files that are not intended to be accessible to
the intruder. Sometimes this is as easy as finding shared folders in Windows 9x or
NT, or NFS exported directories in UNIX systems with read or read and write
access to everyone. The intruder will have no problems getting to the files and,
more often than not, the accessible information is highly confidential and
completely unprotected from prying eyes, especially if the attacker is already an
internal user.
System access is the ability for an unauthorized intruder to gain access to a device
for which the intruder does not have an account or password. Entering or
accessing systems to which one does not have access usually involves running a
hack, script, or tool that exploits a known vulnerability of the system or
application being attacked.
Another form of access attacks involves privileged escalation. Privilege escalation
occurs when a user obtains privileges or rights to objects that were not assigned to
the user by an administrator. Objects can be files, commands, or other components
on a network device. The intent is to gain access to information or execute
procedures for which they are not authorized at their current level of access. In
many cases this involves gaining administrative privileges to a system or device to
install sniffers, create backdoor accounts, or delete log files.
In some cases intruders want to gain access without necessarily wanting to steal
informationespecially when the motive is intellectual challenge, curiosity, or
ignorance.
Denial of Service
Disable or corrupt
networks, systems, or
services
www.cisco.com
CSIDS 2.12-10
Denial of service (DoS) is when an attacker disables or corrupts networks,

systems, or services with the intent to deny the service to intended users. It usually
involves either crashing the system or slowing it down to the point that it is
unusable. But DoS can also be as simple as wiping out or corrupting information
necessary for business. In most cases, performing the attack simply involves
running a hack, script, or tool, and the attacker does not need prior access to the
target because all that is usually required is a way to get to it. For these reasons
and because of the great damaging potential, DoS attacks are the most feared
especially by e-commerce web site operators.
Reconnaissance Methods
Common commands or administrative utilities

Examples: nslookup, ping, netcat, telnet,
finger, rpcinfo, File Explorer, srvinfo,
dumpacl
Hacker tools
Examples: SATAN, NMAP, Nessus, custom
scripts
www.cisco.com
CSIDS 2.12-11
Performing reconnaissance involves the use of common commands or utilities

available in all operating systems. For instance, using the nslookup and whois
utilities, the attacker can easily determine the IP address space assigned to a given
corporation or entity. And the ping command tells the attacker what IP addresses
are alive. Hacker tools are also used to perform reconnaissance. These tools make
it easy for the less knowledgeable attackers to do reconnaissance because they
automate the process and provide a user-friendly interface that anyone can use.
Access Methods
Exploit easily guessed passwords
Default
Brute force
Exploit mis-administered services
IP services
Trust relationships
File sharing
www.cisco.com
CSIDS 2.12-12
Access methods are varied and run the entire gamut between simple commandline hacks to sophisticated tools with nice user interfaces. Usually, the first line of
defense when it comes to access attacks is strong authentication. In many cases
user passwords are too easily guessed by attempting to enter default passwords or
brute force attacks. These attacks involve attempting to logon to a host with a
common user name and then trying different password combinations that are
commonly used. This technique is especially effective if the attacker has some
prior knowledge about the user being targeted.
Exploiting misadministered services is simply taking advantage of services that
are poorly installed and administered by novice or unknowing administrators. One
of the easiest services to exploit is file sharing. Too often users share their files by
creating a shared folder or directory with full access to everyone, and sometimes a
user does not realize that others can access the folder. This can be prevented with
password-protected shares, or sharing only with intended users. Other common
misadministered services are anonymous FTP and TFTP servers, SNMP,
Windows registry access, and trust relationships.
Access Methods (cont.)

Exploit application holes
Mishandled input data
Access outside application domain, buffer
overflows, race conditions
Protocol weaknesses
Fragmentation, TCP session hijack
Trojan horses
Programs that introduce an inconspicuous
backdoor into a host
www.cisco.com
CSIDS 2.12-13
Application security holes have been around since the first piece of software was
written. These holes are usually a result of unanticipated behavior of software
code or unexpected inputs. An example of this is a program that breaks out into a
root shell when receiving an out-of-band input. Protocol weaknesses are also types
of application holes. An example of this is IP fragmentation and TCP session
hijack. The attacker is taking advantage of protocol design deficiencies that the
original designers did not anticipate. Finally Trojan horses are used to gain
unauthorized access by tricking a legitimate user to run trojanized programs that
install or open back doors for attackers to secretly break in. Then the attackers,
circumventing in many cases any authentication procedures, come in through the
back door.
Denial of Service Methods

Resource Overload
Disk space, bandwidth, buffers
Ping floods, SYN flood, UDP bombs
Unsolicited Commercial E-mail (UCE)
Fragmentation or Impossible Packets
Large ICMP packets
IP fragment overlay
Same Source and Destination IP packet
www.cisco.com
CSIDS 2.12-14
DOS attack methods include everything from simple one-line commands to

sophisticated programs, written by knowledgeable hackers.
Common resource overload attacks include ping floods (smurf), TCP SYN floods
(neptune), and packet storms (UDP bomb and fraggle). Unsolicited Commercial
E-mail (UCE), often referred to as SPAM, attempts to overload mail servers.
Some attacks to generate fragmented or impossible packets are ping of death,
winnuke, and landteardrop. One infamous hack tool, targa, combines seven attacks
in one: bonk, winnuke, teardrop, land, jolt, nestea, newtear, and syndrop.
The Cisco Security Wheel

This section describes why network security should be a continuous process based
on the Security Wheel.
Network Security as a
Continuous Process
Network security is a
continuous process
built around a security
policy.
Secure
Improve
Step 1: Secure
Security
Policy
Monitor
Step 2: Monitor
Step 3: Test
Test
Step 4: Improve
www.cisco.com
CSIDS 2.12-16
Most security incidents occur because system administrators do not implement

available countermeasures, and hackers or disgruntled employees exploit the
oversight. Therefore, the issue is not just one of confirming that a technical
vulnerability exists and finding a countermeasure that works; it is also critical to
verify that the countermeasure is in place and working properly.
This is where the Security Wheela continuous security processis effective.
The Security Wheel not only promotes applying security measures to your
network, but most importantly, it promotes retesting and reapplying updated
security measures on a continuous basis.
To begin this continuous process known as the Security Wheel, you need to create
a security policy that enables the application of security measures. A security
policy needs to accomplish the following tasks:
Identify the organizations security objectives
Document the resources to be protected
Identify the network infrastructure with current maps and inventories
Identify the critical resources that need to be protected (such as research and
development, finance, and human resources)
After the security policy is developed, it becomes the hub upon which the next
four steps of the Security Wheel is based:
Step 1
Secure the system. This involves implementing security devicesfirewalls,

identification authentication systems, Virtual Private Networks (VPNs), and so
onwith the intent to prevent unauthorized access to network systems.
Step 2
Monitor the network for violations and attacks against the corporate security
policy. Violations can occur within the secured perimeter of the network from a
disgruntled employee or from a hacker outside the network. Monitoring the
network with a real-time intrusion detection system such as CIDS can ensure that
the security devices in Step 1 have been configured properly.
Step 3
Test the effectiveness of the security safeguards in place. You can use Cisco
Secure Scanner to identify the security posture of the network with respect to the
security procedures that form the hub of the Security Wheel.
Step 4
Improve corporate security. Collect and analyze information from the monitoring
and testing phases to make security improvements.
All four stepssecure, monitor, test, and improveshould be repeated on a
continuous basis and should be incorporated into updated versions of the corporate
security policy.
Secure the Network

Implement security
solutions
Secure
Authentication
firewalls
Improve
Security
Policy
Monitor
VPNs
patching
Stop or prevent
unauthorized access
and activities.
Test
www.cisco.com
CSIDS 2.12-17
Secure the network by applying the security policy and implementing the
following security solutions:
AuthenticationGive access to authorized users only (for example, using

one-time passwords).
FirewallsFilter network traffic to allow only valid traffic and services.
Virtual private networks (VPNs)Hide traffic contents to prevent unwanted

disclosure to unauthorized or malicious individuals.
Vulnerability patchingApply fixes or measures to stop the exploitation of

known vulnerabilities. This includes turning off services that are not needed
on every system. The fewer services that are enabled, the harder it is for
hackers to gain access.
Monitor Security
Secure
Detect violations to the

security policy
System auditing
Improve
real-time intrusion
detection
Validate the security
implementation in step
one
Security
Policy
Monitor
Test
www.cisco.com
CSIDS 2.12-18
Monitoring security involves both active and passive methods of detecting

security violations. The most commonly used active method is to audit host-level
log files. Most operating systems include auditing functionality. System
administrators for every host on the network must turn these on and take the time
to check and interpret the log file entries.
Passive methods include using CIDS to automatically detect intrusion. This
method requires only a small number of network security administrators for
monitoring. CIDS can detect security violations in real time and can be configured
to automatically respond before an intruder does any damage.
An added benefit of network monitoring is the verification that the security
devices implemented in Step 1of the Security Wheel have been configured and are
working properly.
Test Security
Secure
Validate effectiveness of
security policy
implementation through Improve
system auditing and
vulnerability scanning
Security
Policy
Monitor
Test
www.cisco.com
CSIDS 2.12-19
In the testing phase of the Security Wheel, you proactively test the security of your
network. Specifically, make sure that the security solutions you implemented in
Step 1 and the system auditing and intrusion detection methods you implemented
in Step 2, are functioning properly.
Use the Cisco Secure Scanner vulnerability scanning tool to periodically test the
network security measures. This testing not only promotes applying security
measures to your network, but most importantly it promotes the continuous
updating of security measures.
Improve Security
Secure
Use information from the

monitor and test phases,
make improvements to
Improve
the security
implementation
Adjust the security
policy as security
vulnerabilities and risks
are identified
Security
Policy
Monitor
Test
www.cisco.com
CSIDS 2.12-20
The improvement phase of the Security Wheel involves analyzing the data
collected during the monitoring and testing phases, and developing and
implementing improvement mechanisms that feed into your security policy and
the securing phase in Step 1. If you want to keep your network as secure as
possible, you must keep repeating the cycle of the Security Wheel, because new
network vulnerabilities and risks are created every day.
With the information collected from the monitoring and testing phases, you can
use CIDS to implement improvements to the security. You can also adjust the
security policy as you uncover new security vulnerabilities and risks.
Cisco AVVID and SAFE

This section discusses Cisco Architecture for Voice, Video, and Integrated Data
(AVVID) and SAFE.
Cisco AVVID Architecture

Supply
Chain
Customer
Care
Internet
Commerce
E-Learning
Workforce
Optimization
Internet
Business
Integrators
Messaging
Internet
Middleware
Layer
Collaboration
Contact Center
Multimedia
Video on Demand
Personal Productivity
Voice Call Processing
Policy Management
Security
Content Distribution
SLA Management
Address Management
Intelligent Network Classification

Accounting
Management
Caching
Real Time
Services
DNS
Services
Load
Balancing
Multicast
Security
QoS
Intelligent
Network
Services
Network
Platforms
Clients
www.cisco.com
CSIDS 2.12-22
Cisco AVVID can be viewed as a framework to describe a network optimized for

the support of Internet business solutions and as a best practice or roadmap for
network implementation. This section discusses the various layers of the Cisco
AVVID framework. The following are the different parts of the Cisco AVVID
architecture:
ClientsThe wide variety of devices that can be used to access the Internet
business solutions through the network. These might include phones, PCs,
PDAs, and so on. One key difference from traditional proprietary
architectures is that the Cisco AVVID standards-based solution enables a
wide variety of devices to be connected, even some not yet in broad use.
Unlike traditional telephony and video solutions, proprietary access devices
are not necessary. Instead, functionality is added through the intelligent
network services provided in the infrastructure.
Network PlatformsThe network infrastructure provides the physical and

logical connection for devices, bringing them into the network. Network
platforms are the LAN switches, routers, gateways, and other equipment that
interconnect users and servers. Cisco network platforms are competitive for
features, performance, and price, but their key capabilities are the integration
and interaction with other elements of the Cisco AVVID framework. This
layer of Cisco AVVID is the foundation for all applications that will be
integrated to solve business problems.
Intelligent Network ServicesThe intelligent network services, provided

through software that operates on network platforms, are a major benefit of
an end-to-end architecture for deploying Internet business solutions. From
quality of service (QoS) (prioritization) through security, accounting, and
management, intelligent network services reflect the enterprises business
rules and policies in network performance. A consistent set of the services
end-to-end through the network is vital if the infrastructure is to be relied
upon as a network utility. These consistent services enable new Internet
business applications and e-business initiatives to rollout very quickly
without a major re-engineering of the network each time. By contrast,
networks built on best-of-breed strategies may promise higher performance in
a specific device, but cannot be counted on to deliver these sophisticated
features end-to-end in a multivendor environment. Cisco AVVID supports
standards to provide for migration and the incorporation of Internet business
integrators, but the added intelligent network services offered by an end-toend Cisco AVVID solution go far beyond what can be achieved in a best of
breed environment.
Internet middleware layerThe next section, including service control and

communication services, is a key part of any networking architecture,
providing the software and tools to break down the barriers of complexity
arising from new technology. These combined layers provide the tools for
integrators and customers to tailor their network infrastructure and customize
intelligent network services to meet application needs. These layers manage
access, call setup and teardown, perimeter security, prioritization and
bandwidth allocation, and user privileges. Software, such as distributed
customer contact suites, messaging solutions, and multimedia and
collaboration provide capabilities and a communication foundation that
enable interaction between users and a variety of application platforms. In a
best-of-breed strategy, many of these capabilities must be individually
configured or managed. In traditional proprietary schemes, vendors dictated
these layers, limiting innovation and responsiveness.
Rapid deployment of Internet business solutions depends on consistent
service control and communication services capabilities throughout the
network. These capabilities are often delivered by Cisco from servers
distributed throughout the network. The service control and communication
services layers are the glue that joins the Internet technology layers of the
Cisco AVVID framework with the Internet business solutions, in effect
tuning the network infrastructure and intelligent network services to the needs
of the Internet business solutions. In turn, the Internet business solutions are
adapted for the best performance and availability on the network
infrastructure by exploiting the end-to-end services available through the
Cisco AVVID framework.
Internet business integratorsAs part of the open ecosystem, it is imperative

to enable partners with Cisco AVVID. Cisco realizes the crucial requirement
to team with integrators, strategic partners, and customers to deliver complete
Internet business. Cisco AVVID offers a guide for these interactions by
describing a consistent set of services and capabilities that form a basis for
many types of partner relationships.
Internet business solutionsEnterprise customers are deploying Internet business

solutions to re-engineer their organizations. The applications associated with
Internet business solutions are not provided by Cisco, but are enabled, accelerated,
and delivered through Cisco AVVID. The ability for companies to move their
traditional business models to Internet business models and to deploy Internet
business solutions is key to their survival. Cisco AVVID is the architecture upon
which e-businesses build Internet business solutions that can be easily deployed
and managed. Ultimately, the more Internet business solutions that are delivered,
the more efficiently and effectively companies will increase productivity and
added value.
Cisco AVVID Overview
Cisco AVVID is the one enterprise architecture that

provides the intelligent network infrastructure for
todays Internet business solutions.
As the industrys only enterprise-wide, standardsbased network architecture, Cisco AVVID provides
the roadmap for combining Cisco customers
business and technology strategies into one
cohesive model.
www.cisco.com
CSIDS 2.12-23
The Internet is creating tremendous business opportunities for Cisco and Cisco
customers. Internet business solutions such as e-commerce, supply chain
management, e-learning, and customer care are dramatically increasing
productivity and efficiency.
Cisco AVVID is the one enterprise architecture that provides the intelligent
network infrastructure for todays Internet business solutions. As the industrys
only enterprise-wide, standards-based network architecture, Cisco AVVID
provides the roadmap for combining customers business and technology
strategies into one cohesive model.
Cisco AVVID Benefits

IntegrationBy leveraging the Cisco AVVID
architecture and applying the network intelligence
inherent in IP, companies can develop
comprehensive tools to improve productivity.
IntelligenceTraffic prioritization and intelligent
networking services maximize network efficiency for
optimized application performance.
InnovationCustomers have the ability to adapt
quickly in a changing business environment.
InteroperabilityStandards-based APIs enable
open-integration with third-party developers,
providing customers with choice and flexibility.
www.cisco.com
CSIDS 2.12-24
With Cisco AVVID, customers have a comprehensive roadmap for enabling

Internet business solutions and creating a competitive advantage. There are four
Cisco AVVID benefits:
IntegrationBy leveraging the Cisco AVVID architecture and applying the

network intelligence inherent in IP, companies can develop comprehensive
tools to improve productivity.
IntelligenceTraffic prioritization and intelligent networking services

maximize network efficiency for optimized application performance.
InnovationCustomers have the ability to adapt quickly in a changing

business environment.
InteroperabilityStandards-based application programming interfaces (APIs)

enable open-integration with third-party developers, providing customers
with choice and flexibility.
Combining the network infrastructure and services with new-world applications,

Cisco AVVID accelerates the integration of technology strategy with business
vision.
SAFE Blueprint Overview

Building on Cisco AVVID, the SAFE framework
provides a secure migration path for companies to
implement converged voice, video, and data
networks.
SAFE is a flexible framework that empowers
companies to securely, reliably, and cost-effectively
take advantage of the Internet economy.
SAFE integrates scalable, high performance security
services throughout the e-business infrastructure.
SAFE is enhanced by a rich ecosystem of products,
partners, and services that enable companies to
implement secure e-business infrastructures today.
www.cisco.com
CSIDS 2.12-25
SAFE is a flexible, dynamic security blueprint for networks, which is based on

Cisco AVVID. SAFE enables businesses to securely and successfully take
advantage of e-business economies and compete in the Internet economy.
As the leader in networking for the Internet, Cisco is ideally positioned to help
companies secure their networks. The SAFE blueprint, in conjunction with an
ecosystem of best-of-breed, complementary products, partners, and services,
ensures that businesses can deploy robust, secure networks in the Internet age.
SAFE Benefits
Provides a proven, detailed blueprint to
securely compete in the Internet economy
Provides the foundation for migrating to
secure, cost-effective, converged networks
Enables organizations to stay within their
budgets by deploying a modular, scalable
security framework in stages
Delivers protection at every access point to
the network through best-in-class security
products and services
www.cisco.com
CSIDS 2.12-26
There are several major benefits in implementing the SAFE blueprint for secure
e-business:
Provides the foundation for migrating to secure, affordable, converged

networks
Enables companies to cost-effectively deploy a modular, scalable security

framework in stages
Delivers integrated network protection via high-level security products and

services
SAFE Modular Blueprint

Enterprise campus
Enterprise edge
Service
provider
edge
E-commerce
ISP B
Corporate
Internet
ISP A
VPN and
remote access
PSTN
WAN
Frame
or
ATM
Building
Building
distribution
Edge
distribution
Management
Core
Server
www.cisco.com
CSIDS 2.12-27
The SAFE Blueprint provides a robust security blueprint that builds on Cisco
AVVID. SAFE layers are incorporated throughout the Cisco AVVID
infrastructure:
Infrastructure layerIntelligent, scalable security services in Cisco platforms, such as routers, switches, firewalls, intrusion detection systems, and
other devices
Appliances layerIncorporation of key security functionality in mobile

hand-held devices and remote PC clients
Service control layerCritical security protocols and APIs that enable

security solutions to work together cohesively
Applications layerHost- and application-based security elements that

ensure the integrity of critical e-business applications
To facilitate rapidly deployable, consistent security throughout the enterprise,

SAFE consists of modules that address the distinct requirements of each network
area. By adopting a SAFE blueprint, security managers do not need to redesign the
entire security architecture each time a new service is added to the network. With
modular templates, it is easier and more cost-effective to secure each new service
as it is needed and to integrate it with the overall security architecture.
One of the unique characteristics of the SAFE blueprint is that it is the first
industry blueprint that recommends exactly which security solutions should be
included in which sections of the network, and why they should be deployed. Each
module in the SAFE blueprint is designed specifically to provide maximum
performance for e-business, while at the same time enabling enterprises to
maintain security and integrity.
SAFE Blueprint and

Ecosystem
Secure
e-commerce
Secure supply chain

management
Solutions
Secure intranet for
workforce optimization
Ecosystem
Integration partners
Security Associate solutions
Cisco programs and services
Directory
Directory
Operations
Operations
Applications
Applications
Service control
control
Service
Infrastructure
Infrastructure
Appliances or
or clients
clients
Appliances
www.cisco.com
Cisco AVVID
system
architecture
CSIDS 2.12-28
Cisco has opened its Cisco AVVID architecture and SAFE blueprint to key thirdparty vendors to create a security solutions ecosystem to spur development of
best-in-class multiservice applications and products. The Cisco AVVID
architecture and SAFE blueprint provide interoperability for third-party hardware
and software using standards-based media interfaces, APIs, and protocols. This
ecosystem is offered through the Security and Virtual Private Network (VPN)
Associate Program, an interoperability solutions program that provides Cisco
customers with tested and certified, complementary products for securing their
businesses. The ecosystem enables businesses to design and roll out secure
networks that best fit their business model and enable maximum agility.
Cisco AVVID Partner Program

Security and VPN Products
SECURE CONNECTIVITY
APPLICATION SECURITY
Wired and Wireless VPNs
Host and Server Protection
PERIMETER
SECURITY
IDENTITY
Strong
Authentication, PKI
Interoperability
and
Content Filtering;
Personal Firewall
CoCo-existence
with
Cisco Security and VPN

Products
SECURITY MANAGEMENT and MONITORING

Event logging,
Reporting, and Analysis
www.cisco.com
CSIDS 2.12-29
The Security and VPN Solutions Set within the Cisco AVVID Partner Program is
an interoperability solutions program developed to deliver comprehensive security
and VPN solutions for Cisco networks to Cisco customers.
This program is a key component of the SAFE strategy in that it provides a rich
ecosystem of products, partners, and services that empowers companies to
securely, reliably, and cost-effectively take advantage of the Internet Economy.
The program provides the assurance that security solutions making up Partner
products have been tested and verified to be interoperable with Cisco security
products, and add distinct value to Cisco networks. The goal is to enable Cisco
customers to securely take advantage of the expanding e-business marketplace.
The security and VPN solutions created through this interoperability program are
focused on critical business applications such as e-commerce, secure remote
access, intranets, extranets, and supply-chain integration and management. As a
result, the solutions categories currently targeted in the program include those that
customers continue to request and deploy in their networks:
n Identity solutions-Include authentication, authorization, and Public Key
Infrastructure (PKI) solutions such as smart cards, hard and soft tokens,
authentication servers, and Certificate Authority (CA) servers
n Application security solutions-Include products such as server and host
protection applications
n Perimeter security solutions-Include products such as URL filtering applications,
e-mail, and virus scanning applications
n Security management and monitoring solutions-Include products that support
Syslog reporting, event analysis, reporting, and secure remote administration
n Secure connectivity solutions-Include products such as VPN client software and
wireless VPN products

Security and VPN Services
APPLICATION and CODE REVIEW
POLICY and PROCEDURE
Security Services
Compatible
with
Cisco Security
Solution
OUTSOURCE MONITORING
and MANAGEMENT
INCIDENT RESPONSE
www.cisco.com
CSIDS 2.12-30
The security services offered through the AVVID Partner Program are focused on
specific areas of security services available in the industry. As a result, the
services categories currently targeted include those that customers continue to
request and deploy in their organizations:
Application and code reviewExamines and analyzes security structure and

vulnerabilities of hardware and software systems
Outsourced monitoring and managementProvides third-party management,

monitoring of security infrastructure with incident notification, or both
Policy and proceduresProvides assistance with reviewing and building

robust and effective security policies and practices
Incident responseResponds to and mitigates attacks on systems and

networks

Security and VPN Services (cont.)
BUSINESS IMPACT and
RISK ASSESSMENT
COMPETITIVE
COUNTER-INTELLIGENCE
Security Services
Compatible
with
Cisco Security
Solution
VULNERABILITY ASSESSMENT
DESIGN and IMPLEMENTATION

www.cisco.com
CSIDS 2.12-31
Business impact and risk assessmentCorrelates the security state of the

network to impact on broad business processes
Vulnerability assessmentProvides proactive audit and analysis of the

current security state of a system or network
Competitive counter-intelligenceAssesses the vulnerability to compromise

from knowledge-based attacks
Design and implementationProvides assistance with the architecture,

design, and implementation of security products and technologies
CCO Links
www.cisco.com/go/avvid
www.cisco.com/go/safe
www.cisco.com/go/avvidpartners
www.cisco.com/warp/public/779/largeent/
partner/esap/secvpn.html
www.cisco.com
CSIDS 2.12-32
Summary
This section summarizes what you learned in this chapter.
Summary
Network security is necessary because the
proliferation of the Internet has made
information systems easily accessible and
vulnerable to attacks.
The four basic threats to network security are:
unstructured, structured, external, and internal.
The three basic attack types are:
reconnaissance, access, and denial of service.
Some access methods used by hackers are:
application holes, passwords, and poorly
administered services.
www.cisco.com
CSIDS 2.12-34
Summary (cont.)
Network security is a continuous process built
around a security policy.
Cisco IDS is part of the monitor phase of the
security wheel.
Cisco AVVID is a standards-based enterprise
architecture that accelerates the integration of
business and technology strategies.
Cisco SAFE, which is based on Cisco AVVID, is
a flexible, dynamic, security blueprint for
networks.
www.cisco.com
CSIDS 2.12-35
Intrusion Detection and

the Cisco Intrusion
Detection System
Environment
Overview
This chapter explains what the Cisco Intrusion Detection System (CIDS) is and
what its major components are.
Objectives
Intrusion detection basics
CIDS overview
CIDS Sensor platforms
CIDS Director platforms
CIDS PostOffice
Summary
Objectives
Objectives

Define what is intrusion detection.
Name the differences between profile-,
signature-, host-, and network-based intrusion
detection.
Describe the CIDS functions and features.
www.cisco.com
CSIDS 2.13-2
Objectives (cont.)
Name all CIDS Sensor platform models and
describe their features.
Name all CIDS Director platforms and describe
their features.
List the functions and features of the
PostOffice protocol.
Name and define the two parts of the
PostOffice protocol addressing scheme.
www.cisco.com
CSIDS 2.13-3
Intrusion Detection and the Cisco Intrusion Detection System Environment 3-3
Intrusion Detection Basics

This section discusses basic intrusion detection concepts and terminology.
Intrusion Detection
Ability to detect attacks

against networks
Three types of network
attacks
Reconnaissance
Access
Denial of service
www.cisco.com
CSIDS 2.13-5
Intrusion detection is the ability to detect attacks against your network. There are
three types of network attacks:
Reconnaissance attacksAn intruder is attempting to discover and map

systems, services, or vulnerabilities.
Access attacksAn intruder attacks networks or systems to retrieve data, gain

access, or escalate their access privilege.
Denial of service (DoS) attacksAn intruder attacks your network in such a

way that damages or corrupts your computer system, or denies you and others
access to your networks, systems, or services.
Profile-Based Intrusion
Detection
Also known as Anomaly Detection
Activity deviates from profile of normal
activity
Requires creation of statistical user profiles
Prone to high number of false positives
Difficult to define normal activity
www.cisco.com
CSIDS 2.13-6
Profile-based intrusion detection generates an alarm when activity on the network

goes outside of the profile. By collecting examples of user and network activity,
you can build a profile of normal activity. For instance, a web server farm would
typically generate web (HTTP) traffic. A profile could be created to monitor web
traffic. Another example is a network segment where the users are help desk
technicians. The help desk technicians primary job function is to monitor e-mail
requests. A profile could be created to monitor mail (SMTP) traffic.
The problem with this method of intrusion detection is that users do not feel a
responsibility to follow a profile. Humans do not consistently keep to a normal
pattern; consequently, what may be defined as normal activity today might not be
normal activity tomorrow. Simply put: there is too much variation in the way users
act on the network for this type of detection to be effective. For instance, some
help desk technicians may access the web or telnet to systems in order to
troubleshoot problems. Based on the profile created, this type of network activity
would trigger alarms although the alarms are likely to be benign.
Signature-Based Intrusion
Detection
Also known as Misuse Detection
Matches pattern of malicious activity
Requires creation of misuse signatures
Less prone to false positives
Based on the signatures ability to match
malicious activity
www.cisco.com
CSIDS 2.13-7
Signature-based intrusion detection is less prone to false positives when detecting

unauthorized activity. A signature is a set of rules pertaining to typical intrusion
activity. Highly skilled network engineers research known attacks and
vulnerabilities and can develop signatures to detect these attacks and
vulnerabilities.
CIDS implements signatures that can look at every packet going through the
network and generate alarms when necessary. CIDS generates alarms when a
specific pattern or signature occurs. You can configure CIDS to exclude signatures
and modify signature parameters to work optimally in your network environment.
Host-Based Intrusion
Detection
Corporate
network
Agent
Agent
Firewall
Agent
Agent
Agent
Agent
Agent
WWW server
Untrusted
network
www.cisco.com
Agent
DNS server
CSIDS 2.13-8
Host-based intrusion detection is the auditing of local and host log files. An
advantage of host-based intrusion detection is that it can monitor operating system
processes and protect critical system resources including files that may only exist
on that specific host. A simple form of host-based intrusion detection is enabling
system logging on the host. However, it can become manpower intensive to
recover and analyze these logs. Host-based intrusion detection software requires
agent software be installed on each host to monitor activity performed on and
against the host. The agent software performs the intrusion detection analysis and
protection of the host. Less manpower is required when using software than the
simple form, but it can still be overwhelming to manage in a large enterprise
network.
Although physical access to any computer systems practically guarantees access to
the system information, physical protection of all critical servers and network
devices is paramount to ensure information security.
Network-Based Intrusion
Detection
Corporate
network
Sensor
Sensor
Firewall
Untrusted
network
CSPM
www.cisco.com
WWW
server
DNS
server
CSIDS 2.13-9
Network-based intrusion detection involves the deployment of probing devices or

sensors throughout the network, which analyze the traffic as it moves by.
Sensors detect unauthorized activity in real time and can take action when
required.
CIDS is a network-based intrusion detection product designed for deployment
throughout the enterprise. Sensors can be deployed at designated network points
that enable security managers to see network activity while it is occurring no
matter where the target of the attack is located.
CIDS gives security managers real-time insight into their network no matter how
the network may grow. Network growth can either occur by adding additional
hosts or new networks. Additional hosts added to existing protected networks
would be covered without any new Sensors. Sensors can easily be deployed to
protect the new network.
CIDS Overview
This section describes the CIDS functions and features: intrusion detection, alarm
display, alarm logging, intrusion response, and remote Sensor configuration.
CIDS
CSPM
Sensor
Command
and Control
Monitoring
Untrusted
network
Targets
Operator
Hacker
www.cisco.com
CSIDS 2.13-11
CIDS involves the real-time monitoring of network packets. Sensors have two
interfaces: monitoring and command and control. The monitoring port captures the
network packets for intrusion detection analysis. The command and control port
sends alarms and commands to the Director platform. The Director platform is the
management software used to configure, log, and display alarms generated by
Sensors.
The following steps describe the basic CIDS intrusion detection process:
Step 1
Sensors capture network packets through its monitoring interface.
Step 2
Packets are reassembled, if required, and compared against a rule set indicating
typical intrusion activity.
Step 3
The Sensor logs and notifies the Director platform if an attack is detected through
the command and control interface.
Step 4
The Director platform alarms, logs, and takes action if an attack is detected.
When CIDS analyzes network data, it looks for patterns of attacks. Patterns can be
as simple as an attempt to access a specific port on a specific host, or as complex
as sequences of operations directed at multiple hosts over an arbitrary period of
time.
CIDS Capabilities
Display and log alarms

Respond to intrusion attempts
Terminate sessions
Block the attacking host
Create an IP session log
Configure Sensors remotely
www.cisco.com
CSIDS 2.13-12
The CIDS has the following capabilities:
Displays and logs alarms
Responds to intrusion attempts
Terminates sessions
Blocks the attacking host
Creates an IP log
Configures Sensors remotely
Alarm Display and Logging

Alarm Display
Alarms are
displayed in
CSPM.
Alarm Logging
Alarms can be
logged on the
Sensor and on
CSPM.
Log File
www.cisco.com
Database
CSIDS 2.13-13
After a Sensor detects an attack, it can respond in the following user-configurable

ways:
Alarms are generated by the Sensor and are sent to one or more remote
Director platforms where they are displayed on a graphical user interface. The
alarms are color-coded based on the defined severity. This provides you with
a quick visual representation of the alarms triggered.
Alarm information can also be saved in text log files on both the Sensor and
the Director platform. Logging allows you to easily archive the data, write
custom scripts to extract alarm data specific to your site, and monitor attacks
via a command-line tool such as the UNIX command tail.
Intrusion Response
TCP Reset
Automatic kill of
offending
session
Kill the
session
Blocking
Auto or manual block
of offending IP
address
Deny
Block
attacker
www.cisco.com
CSIDS 2.13-14
The Sensor can be configured to respond automatically to specific signatures in

the following three ways:
TCP ResetThe Sensor can reset individual TCP connections upon detection
of an attack and eliminate the threat.
IP BlockingThe Sensor can work in conjunction with a Cisco IOS router to

deny a specific host or network entry into the protected network.
Note
Blocking requires careful review before it is deployed, whether as an automatic

response or through operational guidelines for the staff. To implement blocking, the
Sensor dynamically reconfigures and reloads a Cisco IOS routers access control
list. This type of automated response by the Sensor should only be configured for
attack signatures with a low probability of false positive detection. In case of any
suspicious activity that does not trigger automatic blocking, you can use the
Director platform to block manually. CIDS can be configured to never block specific
hosts or networks. This safety mechanism prevents denial of service attacks using
the CIDS infrastructure.
Intrusion Response (cont.)
IP Logging
Session log
Session log
Automatic capture
of suspicious host
or network traffic
www.cisco.com
CSIDS 2.13-15
IP LoggingIP session logs are used to gather information about

unauthorized use. When specific signatures are triggered, the Sensor can be
configured to write every incoming and outgoing packet to an IP session log
for a predefined period of time.
Remote Sensor Configuration
www.cisco.com
CSIDS 2.13-16
CIDS allows for remote Sensor configuration through the Director platforms. For
instance, using Cisco Secure Policy Manager (CSPM) you can manage the
configuration of all Sensors. CSPM also enables you to create different signature
templates to be saved and applied as needed. This enables you to maintain
multiple versions of signature settings for each Sensor or group of Sensors. For
example, you could have one configuration for normal working hours and another
for after-hours. Either can be enabled or disabled as needed from CSPM. You can
also experiment with different settings and revert to a previous version if there are
problems.
CIDS Sensor Platforms

This section names all CIDS Sensor platform models and describes their features.
Sensor Platform Features

Intrusion Detection
Packet monitoring
Signature matching
Fragment/Packet reassembly
Intrusion response
Alarm or log
Auto or manual response
Hardware appliance design
Tuned for ID performance
Security hardened
Ease of maintenance
www.cisco.com
CSIDS 2.13-18
Two main components make up CIDS: the Sensor and the Director platform. The
Sensor is the most critical component because it detects, responds to, and reports
unauthorized activity to a Director platform. It uses a rules-based engine to distill
large volumes of IP network traffic into meaningful security events. It detects
unauthorized activity by sniffing or capturing raw traffic from the network and
then analyzing it for intrusion detection signatures in real-time. The Sensor, if
configured to do so, re-assembles packets before the signature analysis is
performed, thus avoiding a potential intrusion detection defeating technique.
When signatures are triggered, the Sensor logs the event and sends an alarm
notification to a Director platform. It can automatically terminate the TCP session
that triggered the signature, block the IP address by dynamically creating an
access control list (ACL) in a managed Cisco IOS router, or both. Sensors can also
log an IP session that triggers a signature. An operator may manually block host or
network IP addresses that generated alarms.
All Sensor platforms are hardware appliances that are tuned for performance, have
been security hardened, and are designed for ease of maintenance. The hardware,
including CPU and memory, for each appliance was selected for optimal
performance of intrusion detection analysis. The appliances host operating system
was also configured securely to protect against possible attacks.
4200 Series Sensors
IDS-4230
IDS-4210
ID Performance: 100 Mbps
ID Performance: 45 Mbps
Processor: Dual Pentium III 600 MHz
Processor: Single Celeron 566 MHz
Memory: 512 MB
Memory: 256 MB
Monitoring NIC: FE/SFDDI/DFDDI
Monitoring NIC: Ethernet only
www.cisco.com
CSIDS 2.13-19
Cisco offers a complete line of dedicated intrusion detection appliances. The 4200
Series Sensors come in three versions: the IDS-4230, and IDS-4210. The
following table shows the differences between the Sensors:
IDS-4230
IDS-4210
Intrusion detection
performance
100 Mbps
45 Mbps
Processor
Dual Pentium III 600

MHz
Single Celeron 566

MHZ
Memory
512 MB
256 MB
Monitoring
network interface
cards
10/100 Ethernet
Single attached
FDDI
Dual attached
FDDI
Chassis
4U
10/100 Ethernet
1U
Catalyst 6000 IDS Module

Fully integrated line card
Multi-VLAN visibility
Full signature set
Common configuration
and monitoring
ID Performance: 100
Mbps
No switching
performance impact
www.cisco.com
CSIDS 2.13-20
The IDS Module (IDSM) for the Catalyst 6000 Family of switches is designed
specifically to address switched environments by integrating the IDS functionality
directly into the switch and taking traffic right off the switch back-plane, thus
bringing both switching and security functionality into the same chassis.
Similar to how the CIDS Sensors operate, IDSM detects unauthorized activity
traversing the network, such as attacks by hackers, and sends alarms to a Director
platform with details of the detected event. You specify the network traffic that
must be inspected by the IDS module using the Catalyst operating system Switch
Port Analyzer (SPAN) functionality or virtual LAN (VLAN) access control list
(ACL) capture feature. VLAN ACLs allow for very granular traffic monitoring by
providing you the ability to filter interesting traffic based on the IP address and
network service.
In addition, IDSM can be managed and monitored by the same Director platform
as the Sensors, allowing customers to deploy both appliance Sensors and IDSM to
monitor critical subnets throughout their enterprise network.
The IDSM can analyze 100 Mbps of traffic for intrusion detection. It does not
impact switch performance, because it is a passive monitoring module that
inspects copies of packets and is not in the switch-forwarding path.
CIDS Director Platforms

This section names all CIDS Director platforms and describes their features.
Cisco Secure Policy Manager
Software
application
Windows NT 4.0
platform
Remote Sensor
configuration and
control
Alarm notification
and management
www.cisco.com
CSIDS 2.13-22
The Director platform is the management software used to configure, log, and
display alarms generated by Sensors. The Director platforms are Cisco Secure
Policy Manager (CSPM) and CIDS Director for UNIX.
CSPM is a Windows NT 4.0-based application that provides scalable,
comprehensive security policy management for Cisco Secure PIX Firewalls, Cisco
IOS routers with the IOS Firewall feature or the Cisco Secure Integrated Virtual
Private Network (VPN) Software, and IDS Sensors. This course covers only the
use of CSPM as a Director platform. As such, CSPM provides a centralized GUI
for the management of intrusion detection across a distributed network.
CSPM enables you to remotely control all Sensor configurations. You use the Add
Sensor wizard to define Sensors in the Network Topology Tree (NTT) and you
can use the panels on each Sensor node to configure device-specific settings. In
addition, you can define Sensor signature templates and apply those templates to
one or more sensors defined in the NTT.
The Event Viewer in CSPM provides a mechanism to view alarms generated by
CIDS components in real time. The Event Viewer presents the alarms in a
configurable grid to enable multiple views and instances.
CIDS Director for UNIX
Software application
HP OpenView on Solaris
or HPUX platform
Remote Sensor
configuration and
control
Alarm notification and
management
www.cisco.com
CSIDS 2.13-23
CIDS Director for UNIX is an HP OpenView application that runs on Solaris or

HPUX, which, like CSPM, provides a centralized GUI for the management of
intrusion detection across a distributed network.
It enables you to centrally manage the configuration of all the Sensors reporting to
it. The CIDS Configuration Management Utility (nrConfigure) also allows
different configurations to be saved and applied as needed. This enables you to
maintain multiple versions of configurations for each device.
The Director for UNIX provides a GUI to view real-time alarms as they are
generated by CIDS components on an HP OpenView submap.
Feature Comparison
CSPM
Director for UNIX
Severities
Low-Medium-High 1 through 5
Signatures Templates
Yes
No
Configuration Versioning
No
Yes
Local Logging
Database
Text File
Alarm Forwarding
Yes
Yes
Generate SNMP Traps
Yes
Yes
www.cisco.com
CSIDS 2.13-24
CSPM and the Director for UNIX differ in many ways other than just the
operating system that they run on. Severities in CSPM are assigned Low, Medium,
or High levels, whereas in the Director for UNIX a number between 1 through 5 is
assigned, where 1 is the lowest severity and 5 is the highest.
CSPM enables you to create signature templates that can be shared between
Sensors, so that if you change a template it is automatically applied to all Sensors
referencing it. The Director for UNIX enables you to save multiple complete
configuration versions for the Sensors that can be applied as needed.
The logged alarms in CSPM are saved in a database, and as text files in the
Director for UNIX. Alarm forwarding, the ability of the Director to send alarms to
another Director, is available in the Director for UNIX but not on CSPM.
CSPM and the UNIX Director both have alarm forwarding and SNMP trap
capability. In CSPM, the SNMP traps are possible via custom script execution.
You must create a custom script that generates a SNMP trap to be sent to a
Network Management station.
Note
Refer to the Event Notification and Alarm Reporting chapter for more details on
configuring CSPM for script execution.
CIDS PostOffice
This section describes the functions and features of the PostOffice protocol.
PostOffice Protocol
Command and control
communications
UDP 45000
Internet
Network
monitoring
Message Types
IP log
Command
Error
Redirect
Command log Heartbeat
Alarm
www.cisco.com
CSIDS 2.13-26
CIDS services and hosts communicate with one another using the PostOffice
protocol. The services are the IDS software daemons that exist on the Sensors and
Director platforms.
PostOffice uses the UDP transport on port 45000. The following are the types of
messages that are sent using the PostOffice protocol:
Command messages
Error messages
Command log messages
Alarm messages
IP log messages:
Redirect messages
Heartbeat messages
Note
The PostOffice port number is configurable; however, it is recommended to accept

the default to avoid potential configuration problems
PostOffice Features
Alarm received
ReliabilityAcknowledges
every message sent
Alarm sent
Redundancy Can send

alarms to up to 255
destinations
Fault tolerance
Up to 255 IP addresses
to a single destination
When primary address
fails, switches to
secondary address
Primary communication down;

switch to secondary IP address
www.cisco.com
CSIDS 2.13-27
The PostOffice protocol is designed to guarantee the transmission of messages to

the intended recipient; therefore, it expects acknowledgement for every message
sent from the receiver. If no acknowledgement is received within a predetermined
length of time, the message is resent until the acknowledgement is received.
The PostOffice protocol enables Sensors to propagate messages to up to 255
destinations. This feature allows for redundant alarm notifications, which ensure
that the appropriate personnel are notified when an alarm is received.
With the PostOffice protocol you can have up to 255 alternate IP addresses to a
single host. The alternate routing protocol automatically switches to the next IP
address whenever the current connection fails. It also uses a system watchdog to
detect when a connection to the preferred IP address is reestablished, and at which
time reverts back to the primary address.
PostOffice Host Addressing

Numeric
Host ID = 10
Host Name = director
Host ID
Organization ID
Org ID = 200
Org Name = acme-noc
Alpha
Host Name
Organization Name
Combination of host ID
and Org ID must be
unique
Host, Organization,
and Application ID are
used together to route
PostOffice traffic
Host ID = 10
Host Name = director
Host ID = 30
Host ID = 20
Host Name = sensor2 Host Name = sensor3
Org ID = 100
Org Name = cisco
Org ID = 100
Org Name = cisco
www.cisco.com
Org ID = 100
Org Name = cisco
CSIDS 2.13-28
You must assign each CIDS device a unique numeric identifier. This unique
numeric identifier is a combination of a host identification and an organization
identification. With every host identification and organization identification
combination, there is an associated alphanumeric identifier consisting of a host
name and an organization name. The following are descriptions of the individual
identifiers:
Host IDA numeric identifier greater than zero for each CIDS device.
Organization IDA numeric identifier greater than zero for a collection of

CIDS devices. It can be used to group a number of CIDS devices together
under the same number for easy identification purposes.
Host NameAn alphanumeric identifier for each CIDS device. The name
chosen here is typically one that contains the word sensor or director so
you can easily identify the device type.
Organization NameAn alphanumeric identifier for a group of CIDS

devices. The name chosen here is typically one that describes the name of the
company where the device is installed or the name of the department within
the company where the device is installed.
The host and organization identifications make up two-thirds of the three-part

PostOffice proprietary addressing scheme. The third part of the addressing scheme
is a unique application identifier. PostOffice uses these unique identifiers to route
all command and control communications.
Summary
Summary
Intrusion detection is the ability to detect
attacks against a network, including the
following: reconnaissance, access, and denial
of service.
CIDS uses signature and network-based
intrusion detection.
The Sensor and Director platforms are the
main components of the CIDS.
www.cisco.com
CSIDS 2.13-30
Summary (cont.)
The CIDS Sensor is a performance-tuned hardware
appliance that detects intrusion attempts.
The following are CIDS Sensor hardware
appliances:
CIDS-4230 and 4210
CIDS Sensors notify the Director platform when
signatures are triggered, and logs alarm activity.
CIDS Sensors can automatically respond to
attacks by resetting the connection, blocking the
offending IP address, or logging the session.
www.cisco.com
CSIDS 2.13-31
Summary (cont.)
CIDS has two Director platforms: CSPM and
Director for UNIX.
The following are the Director platforms features:
Displays and logs alarms received by one or
many Sensors.
Allows the user to manage and respond to
alarms from a GUI.
Allows the user to configure and control one or
many Sensors.
Ciscos proprietary communications protocol used
to send messages between Sensors and the
Director platform is the PostOffice protocol.
www.cisco.com
CSIDS 2.13-32
Summary (cont.)
The following are the PostOffice protocol features
and benefits:
A reliable protocol that requires acknowledgement of all
messages sent, and resends messages as needed
A redundant protocol that can be configured to send
messages up to 255 destinations
A fault-tolerant protocol that can be configured to send
messages using 255 alternate IP addresses when a
primary path is down
Must have a unique host and organization identifier for
each CIDS device
Can be protected with IPSec between Sensors and the
Director platform
www.cisco.com
CSIDS 2.13-33
Cisco Secure
Policy Manager
Installation
Overview
This chapter explains the requirements for installing the Cisco Secure Policy
Manager (CSPM). It also explains in detail how to install CSPM and the
PostOffice protocol package delivered with it.
Objectives
CSPM requirements
CSPM installation
Starting CSPM
Summary
Objectives
Objectives
List the software and hardware requirements
for installing CSPM.
Describe the licensing options for CSPM.
Describe the CSPM installation options.
Install CSPM and PostOffice.
Start CSPM.
Start the CSPM Getting Started Videos.
4-2
www.cisco.com
CSIDS 2.14-2
CSPM Requirements
This section describes the Director software, hardware, and configuration
requirements.
Software Requirements
Operating System
Windows NT 4.0
Service Pack 6a
NTFS disk partition
TCP/IP protocol stack
DHCP disabled (recommended)
Internet Explorer 5.x
CVPN Client (optional)
www.cisco.com
CSIDS 2.14-4
The CSPM software package requires the following:
Operating System:
Windows NT 4.0
Service Pack 6a
NTFS disk partition
TCP/IP protocol stack
DHCP disabled (recommended)
Internet Explorer 5.x
CVPN Client (optional)
Cisco Secure Policy Manager Installation
4-3
Recommended Hardware
600 MHz Pentium
processor
CD-ROM drive
Sound card with external
speakers (optional for
videos)
256 MB of RAM
8 GB free hard drive
space
Mouse
Properly configured
network adapter cards
SVGA color monitor
1024 x 768 video adapter

card capable of at least
64 K color
www.cisco.com
CSIDS 2.14-5
To ensure optimal performance, it is recommended that you install CSPM on hosts

that exceed the minimum hardware requirements. For example, the Policy Server
is a multi-threaded application that would benefit from multiple CPUs and
available memory on a single host, whereas enhancing the Policy Administrator
host would not necessarily optimize GUI client performance.
The following table identifies the minimum hardware requirements:
4-4
Standalone and Server Installations
Client Installations
600 MHz Pentium III Processor
400 MHz Pentium II Processor
256 MB of RAM memory
96 MB of RAM memory
8 GB free hard drive space
2 GB free hard drive space
10 Mbps network interface card
10 Mbps network interface card
1024 x 768 video adapter card capable of at

least 256K color
1024 x 768 video adapter card capable

of at least 256 K color
Sound card with external speakers (for

tutorial videos)
Sound card with external speakers (for

tutorial videos)
CD-ROM drive (preferably Autorun-enabled)
CD-ROM drive (preferably Autorunenabled)
Mouse
Mouse
SVGA color monitor
SVGA color monitor
Licensing Options
Customer Order
Part Number
Description
SEC-POL-MGR-LITE
Three devices
SEC-POL-MGR-2.0
Unlimited devices
www.cisco.com
CSIDS 2.14-6
CSPM uses a licensing scheme that allows you to align your purchasing goals with
the size of your operation. In turn, the license you purchase determines the number
of supported devices you can manage. Currently, CSPM supports management of
Cisco PIX Firewalls, Cisco IOS Routers, and Cisco Intrusion Detection System
(CIDS) Sensors.
The following table lists the available permanent product licenses. Each
permanent license affords the same features and functionality.
Customer Order Part
Number
Description
SEC-POL-MGR-LITE
This license supports management of three devices and is

a light version of the unlimited license. Though this license
restricts the number of managed devices to three, it does
not restrict which three devicesany combination of three
supported devices is valid for this license.
SEC-POL-MGR-2.0
This license supports management of an unlimited number

of devices. With this license, you are not restricted to the
number or types of supported devices you manage.
4-5
Installation Options
Standalone CSPM
Client-server CSPM
Policy server
Policy administrator
Distributed CSPM (not supported)
www.cisco.com
CSIDS 2.14-7
You should install CSPM as a standalone or client-server system. The distributed

installation of CSPM does not support the management of CIDS Sensors.
The standalone Cisco Secure Policy Manager system incorporates all of the
feature sets operating on a single computer. This computer carries out all database,
monitoring, reporting, and policy distribution functionality. Also, the Policy
Administrator, which is the graphical user interface, is installed with the
standalone system.
The Client-Server installation option enables you to have client systems perform
management, monitoring, and maintenance of the CSPM server remotely. The
following are the two feature sets in a CSPM client-server installation:
4-6
Policy ServerThe Policy server feature set includes a central database that
stores all system configuration data and summary audit records, as well as the
subsystem responsible for generating on-demand or scheduled system reports.
It also includes the Policy Server feature set that is responsible for compiling
the global policy down into device specific rules. In addition, it adjusts the
addresses for intermediate network address translation. When distributing the
system, you must always install the Policy Server feature set first, because the
database key is necessary to install all other feature sets. You must install this
feature set on a computer running Windows NT version 4.0. The Policy
Administrator feature set is also included when you install the Policy Server.
Policy AdministratorThe Policy Administrator feature set is included when

you install any of the other feature sets, but you can install it separately on
any Windows 95, Windows 98, or Windows NT system to facilitate remote
administration of the system. If you are managing IDS Sensors, Windows NT
is the only supported client.
CSPM Installation
This section describes how to install CSPM.
Start Installation
Continue
Continue ifif the
the
VPN
VPN Client
Client is
is
not
not wanted
wanted
Select
Select
Install
Install Product
Product
www.cisco.com
CSIDS 2.14-9
This section describes how to install CSPM as a standalone server. To start

installation of CSPM, complete the following steps:
Step 1
Log in as user administrator on the host in which you are installing CSPM.
Step 2
Insert the CSPM CD-ROM into the drive on the target host, to initiate the
Autostart program. If you have not installed CVPN Client on this host, the CVPN
Client window opens; otherwise, the Cisco Secure Policy Manager Installation
window opens.
Note
If you have not installed CVPN Client on this host and want to do so, you should
now exit the CSPM installation and insert the CVPN Client CD-ROM. Otherwise,
continue with the installation procedures for Cisco Secure Policy Manager.
Step 3
Select Install Product in the Options group box, and then click Next. The License
Agreement window opens.
Step 4
Review all conditions of the license agreement using the scroll bar on the right
side of the window. To accept the license agreement and continue with the
installation process, select I accept the agreement.
Step 5
To proceed to the next window, click Next. The License Disk window opens.
4-7
License
License
License file
file
location
location
License
License
password
password
4-8
www.cisco.com
CSIDS 2.14-10
Step 6
To specify the location of the CSPM license disk, enter the directory path in the
Location field, or click Browse to find the correct path.
Step 7
Enter the corresponding password in the Password field.
Step 8
Click Next to proceed to the next window. The Installation Options window
opens.
Installation Option
Select
Select
Standalone
Standalone
CSPM
CSPM
Step 9
www.cisco.com
CSIDS 2.14-11
Click Standalone CSPM to select the type of system to install. A brief text
description of the standalone system appears in the Installation Option field.
Step 10 To specify where to install CSPM, enter the directory path to the installation
folder in the Installation Folder field, or click Browse to find the correct path.
Step 11 Click Next to proceed to the next window.
Step 12 If the folder that you specified in the directory path does not exist, the setup
program offers to create a default folder (Program Files\Cisco Systems\Cisco

Secure Policy Manager) for you. In the pop-up window, click Yes to create the
folder and proceed with the setup program. The Account Information window
opens.
Note
If you click No, which does not create a folder, you return to the Installation Options
window.
4-9
Account Information
Enter
Enter the
the
password
password for
for the
the
administrator
administrator
account
account
www.cisco.com
CSIDS 2.14-12
Step 13 To submit the corresponding password for the Windows NT username detected by
the setup program, enter the password in the Password field.

Step 14 Reenter the password in the Confirm Password field to confirm the password.
Step 15 Click Next to proceed to the next panel. The Settings window opens.
4-10
Settings
Leave
Leave the
the
default
default settings
settings
www.cisco.com
CSIDS 2.14-13
Step 16 From the Local IP Address drop-down menu, select one of the IP addresses
configured on the target host for all inbound and outbound CSPM
communications. Only one IP address is shown in the drop-down menu unless
multiple network interface cards (NICs) are installed in the host or multiple IP
addresses are configured on a NIC.
Step 17 You must ensure that the Policy Database listens on the proper port for
communication requests. The IANA-assigned port number for database

communications is 2567. To change the port number, delete the existing one in the
Primary Policy Database field, and then enter the desired unused port number.
Note
This step has no effect on IDS communications or operations. Keep the default
settings only when installing for IDS use.
Step 18 Select Export this key to export the database key.

Step 19 In the File Destination field, enter the path of the location where you want the key
stored
Step 20 Click Next to proceed to the next window. The database key is written to the
location that you specified and the Verify Install Settings window opens.
Note
Exporting the database key has no effect on IDS communications or operations.

The database key is used for client-server installations.
4-11
Verify Installation Settings
Verify
Verify the
the
settings
settings and
and
click
click Copy
Copy Files
Files
to
to proceed.
proceed.
www.cisco.com
CSIDS 2.14-14
Step 21 To copy all files to your disk, verify the settings that you chose, and then click
Copy Files. The TechSmith Screen Capture Codec Installation window opens.
Note
4-12
If you find an incorrect setting, click Back until you arrive at the proper window.
Make the necessary changes, and then click Next until you return to the Verify
Install Settings window.
TechSmith Screen Capture

Codec Installation
Install
Install to
to see
see
the
the included
included
training
training videos
videos
www.cisco.com
CSIDS 2.14-15
Step 22 To install the compression software (TechSmith Screen Capture Codec) required
for viewing the videos, click Install in the TechSmith Screen Capture Codec
Installation window.
If you have not installed Cisco Secure PostOffice, the installation program begins
to unpack the required files and initiates a separate installation for Cisco Secure
PostOffice. If Cisco Secure PostOffice is already installed on this host, skip to
Step 30.
Note
TechSmith's Camtasia was used to create the Getting Started Videos. Camtasia
uses a proprietary AVI compression codec called TechSmith Compression Codec
(TSCC). Before you can view the videos, you must have TSCC installed on your
computer.
4-13
PostOffice Installation
Verify
Verify installation
installation
folder
folder and
and click
click
Next
Next to
to proceed
proceed
www.cisco.com
CSIDS 2.14-16
Step 23 Click Next in the Welcome window to continue with the Cisco Secure PostOffice
installation. The Software License Agreement window opens.

Step 24 Click Yes to accept the License Agreement. The User Information window opens.
Step 25 To submit your user information, enter your name and your company name in the
appropriate fields and click Next. The Choose Destination Location window
opens.
Step 26 To install PostOffice in the destination folder, click Next. The PostOffice
installation program copies the appropriate files to the selected destination folder
and the Configure Communication Properties window opens.
4-14
PostOffice Settings
Enter
Enter the
the
host
host identification
identification
Enter
Enter the
the
organization
organization
identification
identification
Verify
Verify the
the
IP
IP address
address
Enter
Enter the
the
hostname
hostname
Enter
Enter the
the
organization
organization name
name
www.cisco.com
CSIDS 2.14-17
Step 27 Submit the PostOffice parameters for CSPM. The properties you define in this
window are used to define the PostOffice identification for this host.
PostOffice Setting
Parameters
Description
Host ID
(165535)
Numeric identifier identifying CSPM.
Organization ID
(165535)
Numeric identifier that furthers identifies

CSPM. It can be used to group a number of
CIDS devices together under the same
number for easy identification purposes.
IP Address
<IP address>
IP address of the CSPM host.
Host Name
<hostname>
Alphanumeric identifier for each Director

(for example, director0). The name chosen
here is typically one that contains the word
director so you can easily identify that it is
a Director.
Organization Name
<organization
name>
Alpha identifier that furthers identifies

CSPM (for example, pod0). It can be used
to group a number of CIDS devices
together under the same name for easy
identification purposes.
Step 28 Click Next to start copying the PostOffice installation files. After the files are
copied, the Setup Complete window opens.
4-15
Finalize Installation Programs

Click
Click Finish
Finish to
to finalize
finalize the
the
PostOffice
PostOffice installation.
installation.
Click
Click Finish
Finish to
to finalize
finalize the
the
CSPM
CSPM installation.
installation.
www.cisco.com
CSIDS 2.14-18
Step 29 PostOffice is now installed on the host. Click Finish to finalize the PostOffice
installation. The installation program for CSPM continues and the setup program
copies all files to the specified installation folder and creates the necessary
Registry keys. Then the Setup is complete window opens.
Step 30 CSPM is now installed on the host. Click Finish to finalize the CSPM installation
Note
4-16
CSPM installs two Windows NT services: Cisco Controlled Host Component

(CHC) and Cisco Secure PostOffice. The CHC service is configured to startup
automatically as the user account that you used to install CSPM. The Cisco Secure
PostOffice service is configured to startup automatically as a system account.
Starting CSPM
This section covers how to start CSPM after it is already installed. It also covers
how to configure and view the Getting Started Videos.
Start and Log into CSPM
Enter
Enter the
the
username
username
Enter
Enter the
the
password
password
www.cisco.com
CSIDS 2.14-20
To start CSPM, choose Start>Programs>Cisco Systems>Cisco Secure Policy

Manager>Cisco Secure Policy Manager. The Log on to Cisco Secure Policy
Manager window opens. In this window enter the username and password in the
respective fields within the Authorization group box. Click Connect to enter
CSPM.
Note
The Local or Remote Server options within the Policy Database Server group box
are dependent on the type of CSPM installation that was chosen. The Local option
is associated with a standalone installation. The Remote server option is
associated with a client-server installation.
4-17
Getting Started Videos
Select
Select the
the folder
folder
that
that contains
contains the
the
video
video files
files
Choose
Choose the
the
video
video you
you
want
want to
to watch
watch
www.cisco.com
CSIDS 2.14-21
In addition to reading through the online help and printed documentation, you can
learn important concepts about CSPM by viewing the Getting Started Videos.
These videos consist of a series of lessons that introduce you to the high-level
tasks you must perform in CSPM.
The Getting Started Videos are included with on CSPM CD-ROM. If you
downloaded the software, you will have to run the videoex.exe program, located
in the directory where you downloaded CSPM.
Note
TechSmith's Camtasia was used to create the Getting Started Videos. Camtasia
uses a proprietary AVI compression codec called TechSmith Compression Codec
(TSCC). Before you can view the videos, you must have installed TSCC on your
computer. If you downloaded the software, TSCC is installed when you run the
videoex.exe file.
To install the Getting Started Videos, right after you log on to CSPM the Locate
Installation CD-ROM Image popup window opens. From this window select the
folder where the video files are located. By default it looks in the CD-ROM drive
for the installation CD-ROM.
To view a Getting Started lesson select that lesson from the drop-down list and
click View. Your default AVI player (commonly, Windows Media Player) will
open and play the video.
4-18
Summary
Summary
The software and hardware requirements for

installing CSPM.
What are the licensing requirements for CSPM.
How to install CSPM and PostOffice.
How to start CSPM.
How to start the CSPM Getting Started Videos.
www.cisco.com
CSIDS 2.14-23
4-19
Lab ExerciseInstalling and Initializing

CSPM
Complete the following lab exercise to practice what you learned in this chapter.
Objectives
In this lab exercise you will complete the following tasks:
Install the CSPM software.
Start CSPM.
Visual Objective
The following figure displays the lab topology you will use to complete this lab
exercise.

Pod P
Your Pod
Pod Q
Peer Pod
172.30.1.0 /24
e0/1 .10P
sensorP
e0/0 .1
.4
idsmP
e0/1 .10Q
sensorQ
e0/0 .1
.4
rQ
rP
.6
10.0.P.0 /24
idsmQ
10.0.Q.0 /24
CSPM
10.0.P.3
CSPM
.6
10.0.Q.3
www.cisco.com
CSIDS 2.14-25
A pair of students has been assigned to a pod. Each pod has a complete set of
equipment to complete the lab exercise.
Note
4-20
The P in an IP address, name, or command indicates your pod number. Make sure
to replace it with your pod number. The Q in an IP address, name, or command
indicates the pod number of a peer pod assigned by the instructor. Make sure to
replace it with your peers pod number.
CIDS Parameters
Lab Settings
Student Laptop Login User
administrator
Student Laptop Login Password
attack
CSPM Login User
administrator
CSPM Login Password
attack
Student Laptop IP Address
10.0.P.3 (where P = pod number)
CSPM PostOffice Host ID
CSPM PostOffice Organization ID
P (where P = pod number)
CSPM PostOffice Host Name
directorP (where P = pod number)
CSPM PostOffice Organization Name
podP (where P = pod number)
Installation format
Ask your instructor
License disk location
Ask your instructor
Task 1Install Cisco Secure Policy Manager

Perform the following steps to install Cisco Secure Policy Manager on your
Windows NT 4.0:
Step 1
Log in as user administrator on your laptop using the password attack.
Step 2
Start the installation of CSPM on your laptop from the CSPM CD-ROM or from
the files on your hard drive, as indicated by the instructor.
When installing from the CD-ROM, Windows NT will automatically start the
autorun.exe program in the CSPM CD-ROM.
When installing from files on your hard drive, complete the following:
Open the folder where the installation files are located.
Double-click the setup.exe program to start installation.

or
Choose Start>Run.
Enter z:\setup.exe to start the installation.

(where z = CD-ROM drive letter)
Step 3
Click Continue in the CVPN Client Not Installed on Host window.
Step 4
Select Install Product in the Options group box.
Step 5
Click Next. The License Agreement window opens.
Step 6
Review all conditions of the license agreement using the scroll bar on the right
side of the window. To accept the license agreement and continue with the
installation process, select I accept the agreement.
Step 7
To proceed to the next window, click Next. The License Disk window opens.
Step 8
Click Browse.
Step 9
Choose Desktop from the Look in drop-down menu.
4-21
Step 10 Double-click the cspm folder in the browse window.

Step 11 Double-click the license.dsk file in the browse window.
Step 12 Enter cisco in the Password field.
Step 13 Click Next to proceed to the next window. The Installation Options window
opens.
Step 14 Click Standalone CSPM to select the type of system to install. A brief text
description of the standalone system appears in the Installation Option field.

Step 15 Do not change the default path in the Installation Folder group box. Click Next to
proceed to the next window.

Step 16 The setup program offers to create the folder C:\Program Files\Cisco
Systems\Cisco Secure Policy Manager for you. Click Yes to create the folder and
proceed with the setup program. The Account Information window opens.
Step 17 Enter and confirm attack as the Administrator password in the Password and
Confirm Password fields.

Step 18 Click Next to proceed to the next window.
Step 19 Click OK in the Information window to acknowledge the message and continue
installation. The Settings window opens.

Step 20 Do not change the information in the Local IP Address, Service Port, or Primary
Policy Database Key group boxes in the Settings window. Click Next to proceed
to the next window. The Verify Install Settings window opens.
Step 21 Click Copy Files to proceed to the PostOffice installation. The TechSmith Screen
Capture Codec Installation window opens.

Note
If you find an incorrect setting, click Back until you arrive at the proper window.
Make the necessary changes, and then click Next until you return to the Verify
Install Settings window.
Step 22 Click Install in the TechSmith Screen Capture Codec Installation window.
Step 23 Click OK in the TSCC Installation Complete window to acknowledge the
message and continue with the PostOffice installation. The PostOffice installation
Welcome window opens.
Step 24 Click Next in the Welcome window. The Software License Agreement window
opens.
Step 25 Click Yes to accept the License Agreement. The User Information window opens.
Step 26 Click Next to accept the information displayed in the Name and Company fields.
The Choose Destination Location window opens.

Step 27 Click Next to install PostOffice in the default destination folder. The PostOffice
installation program copies the appropriate files to the selected destination folder
and the Configure Communication Properties window opens.
Step 28 Submit the PostOffice parameters for this host in accordance with the following
table. The properties you define in this window are used to define the PostOffice
identification for this host.
4-22
CSPM PostOffice Settings
Value
Host ID
Organization ID
IP Address
Pre-selected, do not change
Host Name
Organization Name
Step 29 Click Next to start copying the PostOffice installation files. After the files are
copied, the Setup Complete window opens.

Step 30 PostOffice is now installed on the host. To complete the PostOffice installation,
click Finish. The installation program for CSPM continues and the setup program
copies all files to the specified installation folder and creates the necessary
Registry keys. Then, the Setup is complete window opens.
Step 31 CSPM is now installed on the host. To complete the CSPM installation, click
Finish.
Task 2Start CSPM

Complete the following steps to start CSPM:
Step 1
To start CSPM choose Start>Programs>Cisco Systems>Cisco Secure Policy

Manager>Cisco Secure Policy Manager. The Log on to Cisco Secure Policy
Manager window opens.
Step 2
Enter the username Administrator and the password attack into the appropriate
fields.
Step 3
Click Connect to enter CSPM.
Step 4
Click Cancel on the Locate Installation CD-ROM Image window. The CSPM
main window opens.
Step 5
Click OK in the Getting Started window to enter CSPM.

Note
You have just completed this lab exercise. Please inform the instructor that you are
finished.
4-23
Cisco Intrusion
Detection System
Sensor Installation
Overview
This chapter discusses Sensor deployment considerations, explains the parameters
that must be set to configure the Cisco Intrusion Detection System (CIDS) Sensor,
and how to add the Sensor to the CIDS Director after the Sensor is installed.
Objectives
Deploying CIDS
The Sensor appliances
Sensor bootstrap configuration
Adding a Sensor in CSPM
Summary
Lab exercise
Objectives
Objectives
Describe the most common Sensor
deployment options.
Define the terms device management and
firewall sandwich.
Describe the functional differences between
the Command and Control interface and the
Monitoring interface on the Sensor.
www.cisco.com
CSIDS 2.15-2
Objectives (cont.)
Obtain management access on the Sensor.

Initialize the Sensor.
Add a Sensor object in CSPM.
Push the initial configuration files from CSPM
to the Sensor.
Describe how to check for errors when adding
a Sensor in CSPM.
www.cisco.com
CSIDS 2.15-3
Cisco Intrusion Detection System Sensor Installation 5-3
Deploying CIDS
This section describes the considerations you should make before deploying
Sensors across your network.
Basic Installation
Untrusted
network
Out-of-band
Out-of-band
network
network
Command and
control network
Monitoring
interface
Protected
network
...
www.cisco.com
CSIDS 2.15-5
In a basic installation, the Monitoring interface on the Sensor is connected to the

network segment to be protected. The most secure way to connect the Command
and Control interface is on an out-of-band network, where only the Sensor and
CSPM reside. In this environment, the Sensor monitors traffic and forwards
alarms to the CSPM. The Sensor may be configured to respond to alarms with a
TCP reset or an IP session log. In this type of installation, the Sensor does not
communicate with the router; therefore, the routers access control lists (ACLs)
cannot be changed to block an attacker.
Installation with
Device Management
Untrusted
network
Dedicated
Dedicated
router
router interface
interface
Command and
control network
Monitoring
interface
Protected
network
...
www.cisco.com
CSIDS 2.15-6
Device management refers to the Sensors ability to dynamically reconfigure

ACLs on a Cisco router to block an attacker. The Sensor must be able to
communicate with the managed router. For the Sensor to defend a network using a
Cisco IOS router for blocking, you must do the following tasks:
Enable Telnet services on the router
Add the router to the Sensors device management list
Ensure the Sensor has access to the managed router.
This configuration allows on-the-fly reconfiguration of your network policy. You

can also use manual commands to reconfigure the routers ACLs.
Firewall Sandwich Installation

Untrusted
network
Monitoring
interface
Firewall
Protected
network
Command and
control network
...
www.cisco.com
CSIDS 2.15-7
The Sensor may be used in combination with a firewall in what is called a

firewall sandwich configuration. In a firewall sandwich configuration, the
Sensors monitoring interface is connected to the network outside the firewall and
the Sensors command and control interface is connected to the network inside the
firewall.
To implement a firewall sandwich IDS with device management , you must do the
following tasks:
Enable Telnet services on the router.
Add the router to the Sensors device management list.
Configure the firewall to allow for traffic that travels via Telnet from the
Sensors Command and Control interface to the router.
With this configuration, the firewall implements traffic filtering, and the Sensor
captures packets between the router and firewall. The Sensor can then update the
routers ACL to deny unauthorized activity.
Note
Device management is not required for a firewall sandwich installation.
Remote Sensor Installation

Untrusted
network
Remote
network
Protected
network
IPSec
tunnel
Director
Sensor
www.cisco.com
CSIDS 2.15-8
When a Sensor is deployed at a remote site from the Director, the traffic across the
untrusted network must be protected with encryption. This can be achieved with
an IPSec encryption from Cisco router to Cisco router (site-to-site VPN).
To implement a remote IDS sensor configuration with device management, you
must do the following tasks:
Enable Telnet services on the router from the Sensor.
Add the router to the Sensors device management list.
Configure the firewall to allow the following traffic:
Note
Telnet from the Sensors Command and Control interface to the router
UDP port 45000 traffic traveling through the firewalls and the routers
between the Director and the Sensor
Configure the routers for IPSec encryption (site-to-site VPN)

Device management is not required for a remote sensor installation.
Sensor Placement
Considerations
Protected
network
Untrusted
network
Payroll
Web
server
Dial-up
access
DNS
server
Partner
network
www.cisco.com
CSIDS 2.15-9
Installing CIDS on your network requires some planning and forethought. Prior to
CIDS deployment you should examine the following aspects of your network:
Size and complexity
Number of nodes
Number of network segments
Media typeEthernet, FDDI, ATM, etc.
Connections between your network and other networks
Entry and exit points into the networkISP, dialup, partners, etc.
Amount and type of network traffic
Bandwidth requirements10Mbps, 100Mbps, 1000Mbps, etc
Amount of IP traffic
Amount of TCP trafficFTP, HTTP, SMTP, etc.
Amount of UDP trafficSNMP, TFTP, DNS
Encrypted trafficVPN connections
With this information, now consider the information you want to protect.
Determine which segments should be monitored and which Sensor to deploy
based on bandwidth requirements
Placing the Sensors on the perimeter enables you to see who is attempting to gain
access to the protected network and which vulnerability exploits are being used.
Placing the Sensors within the protected network enables the Sensors to monitor
activities across selected internal network segments. The Sensors in the protected
network only examine traffic that has successfully entered through the firewall or
is generated internally.
The Sensor Appliances

This section describes what the Sensor appliance looks like and the different types
of network connections that Sensors have.
4230 Sensor Front Panel

Power
Power LED
LED
Power
Power
switch
switch
Hard
Hard drive
drive
LED
LED
Reset
Reset
switch
switch
Floppy
Floppy disk
disk
drive
drive
www.cisco.com
CD-ROM
CD-ROM
drive
drive
CSIDS 2.15-11
The 4230 Sensor is a 4 RU, rack-mountable device. The lockable front access
panel protects the Sensor from unauthorized tampering. A floppy drive and CDROM drive are provided.
4230 Sensor Back Panel
Power
Power
supply
supply
switch
switch
Video
Video
monitor
monitor
Keyboard
Keyboard
Command
Command
and
and control
control
interface
interface
Console
Console
port
port
Monitoring
Monitoring
interface
interface
www.cisco.com
CSIDS 2.15-12
The model of the Sensor is based on the type of network that uses it. The location
of the monitoring (sniffing) connection depends on the model of Sensorwhether
it is an Ethernet, a Fast Ethernet, Token Ring, and so on. Following is a list of the
types of network connections and the corresponding, monitoring interface, and
device names.
Network Connections
Device Name
Ethernet
/dev/spwr0
Fast Ethernet
/dev/spwr0
Token Ring
/dev/mtok0
Single FDDI
/dev/ptpci
Dual FDDI
/dev/ptpci
Regardless of model, some connections are common to all Sensors such as the
keyboard, monitor, and Command and Control network interface connection. For
initial configuration there are connections for a keyboard and monitor. Be sure to
read and understand all safety requirements listed in the CIDS User Guide.
4210 Sensor Front Panel

Console
Console
port
port
www.cisco.com
CSIDS 2.15-13
The 4210 Sensor is a 1 RU, rack-mountable device. A removable front cover

allows access to the floppy and CD-ROM drives.
4210 Sensor Back Panel

Keyboard
Keyboard
Command
Command
and
and control
control
interface
interface
Console
Console
access
access
Video
Video
monitor
monitor
Monitoring
Monitoring
interface
interface
www.cisco.com
CSIDS 2.15-14
The back of the 4210 Sensor has two Ethernet interfaces. The top interface is the
Command and Control interface, and the bottom interface is the Monitoring
interface. Following is a list of the types of network connections and the
corresponding, monitoring interface, and device names.
Network Connection
Device Name
Ethernet
/dev/iprb0
In addition to the interfaces, the 4210 Sensors give you access to the keyboard
port, the console access port, and the video monitor port.
Be sure to read and understand all safety requirements listed in the CIDS User
Guide.
Management Access
Console port (cable provided)

Monitor and keyboard
Telnet
www.cisco.com
CSIDS 2.15-15
There are three ways you may access a Sensor to manage it:
Accessing the console port using an RS-232 cable provided with the Sensor
and a terminal emulation program such as Hyperterm.
Connecting a monitor and a keyboard directly on the Sensor.
Using Telnet after the Sensor has been assigned an IP address.
Login Accounts
netrangr
root
CIDS-level access
Operating systemlevel access
Use for all other CIDS

commands
Use only for

Bootstrapping
(sysconfig-sensor)
Solaris operating
system-level
commands
Installing signature
updates and service
packs
www.cisco.com
CSIDS 2.15-16
The following are the two management accounts and their characteristics used to
log in to the Sensor:
Username: root
Default password: attack
Used when bootstrapping the Sensor (i.e., executing sysconfig-sensor)
Used when performing Solaris operating system-level tasks (e.g., running

the snoop command)
Used when installing signature updates or service packs.
Username: netrangr
Default password: attack
Used for all CIDS commands except sysconfig-sensor
Sensor Bootstrap Configuration

This section describes the parameters that must be set using sysconfig-sensor after
the Sensor is installed.
sysconfig-sensor
www.cisco.com
CSIDS 2.15-18
During the initial configuration, you enter the minimal set of parameters for the
identification of the Sensor and the Director that will manage it. You must be
logged on to the Sensor as user root to run sysconfig-sensor, CIDS menu-driven
configuration script. At the command prompt on the Sensor, enter sysconfigsensor and press Enter. The IDS Sensor Initial Configuration Utility menu
appears.
Note
The sysconfig-sensor script should be used when Sensor network and PostOffice
configuration modifications are needed.
IP Configuration
Option 1IP Address
Option 2IP Netmask
Option 3IP Hostname
UNIX hostname (independent of PostOffice)
Option 4Default route
Enter a default route if access to or from the
Sensor from or to another network is
required
www.cisco.com
CSIDS 2.15-19
Options 1 through 4 enable you to enter IP communications settings for the

Sensor. This includes the Sensors IP address and netmask as well as the UNIX
hostname. A default route can also be set with option 4 only if it is required by the
installation (for example, routing is required for the Sensor to communicate with
the Director or other devices).
To see the setting in each option, enter the number that corresponds to the
parameter you want to see and press Enter. Data for the option you entered opens.
To keep the data, which is in the brackets, press Enter. To change the data in the
brackets, enter the new information at the prompt and press Enter. Enter y when
prompted to write any added or changed data to the disk. The following table
contains the values you need to enter and a description of each.
CIDS Settings
Parameters
Description
Option 1IP
Address
<IP Address>
The IP address of the Sensor (for

example, 10.10.10.3).
Option 2IP
Netmask
<Netmask>
The netmask for the Sensor (for

example, 255.255.255.0).
Option 3IP
Hostname
<Hostname>
Alphanumeric identifier for each

Sensor. The name chosen here is
typically one that contains the word
sensor so you can easily identify
that it is a Sensor (for example,
sensor1).
Option 4Default
Route
<Default Route>
The Sensors default route for proper

routing purposes (if needed). (For
example, 10.10.10.1.)
Network Access Control
Option 5List of IP addresses allowed to

telnet, ftp, or tftp to the Sensor
Examples
192.168.0.34 (specific IP)
10. (anyone with IP starting with 10.)
10. is set by default and should be removed
www.cisco.com
CSIDS 2.15-20
Option 5 enables you to set any number of IP addresseseither by host or

networkwhich are allowed to telnet, ftp, or tftp to a Sensor. In most cases,
access to the Sensor in this manner should be limited to a single trusted host
typically the Director. This allows the single trusted host to telnet to the Sensor to
help in troubleshooting, or to ftp files when new signatures and product updates
are released. The UNIX file that has these entries is /etc/hosts.allow.
Note
In the classroom, Option 5Network Access Control, may have been set to include
entire networks such as the 10. and 192. networks, or the word ALL may be listed
allowing any host. This is not recommended in real world installations and is used
only for this learning environment.
Configuring Communication
Parameters
Option
Option 6
www.cisco.com
CSIDS 2.15-21
Option 6, the CIDS Communications Infrastructure Configuration menu, enables

you to input the data necessary for communications between the Sensor and
Director. The following table contains the parameters you need to enter and a
description of each.
CIDS Settings
Parameters
Description
Sensor Host ID
1-65535
Numeric identifier for the Sensor.
Sensor Organization ID
1-65535
Numeric identifier for a collection of CIDS

Components.
Sensor Host Name
<Host
Name>
Alphanumeric identifier for the Sensor

(e.g., sensor1).
Sensor Organization
Name
<Org Name>
Alphanumeric identifier for a group of

CIDS components (e.g., securitynoc).
Sensor IP Address
<IP
Address>
The IP address of the Sensor.
IDS Manager Host ID
1-65535
Numeric identifier for the CIDS Director.
IDS Manager
Organization ID
1-65535

components.
IDS Manager Host Name
<Hostname>
Alphanumeric identifier for the Director

(e.g. , director1)
IDS Manager
Organization Name
<Org Name>
Alphanumeric identifier for a group of

CIDS components (e.g., securitynoc).
IDS Manager IP Address
<IP
Address>
The IP address of the Director.
Note
The information you use to identify the Sensor is needed when you add the Sensor
to the Director platform.
Creating Initial Configuration

Files
www.cisco.com
CSIDS 2.15-22
Exercise extreme caution not to confuse the Sensor information for the Director
information, and vice versa. The information you enter is included in each packet
that travels between the Sensor and Director and must be error-free. If you make
an error while entering the information, enter n and press Enter when prompted.
Then select the parameter number again and enter the correct information.
After you have entered all of the information for the CIDS Communications
Infrastructure Configuration, you are prompted to create these files. If the
information is correct, enter y and press Enter.
The Sensor creates the configuration files, which are displayed on the window.
When all files have been successfully created, you are prompted to continue. Press
Enter.
The next window is a CIDS notes page. Read the information presented and then
press Enter to continue.
Configuring the System Date,

Time, and Timezone
Option
Option 7
www.cisco.com
CSIDS 2.15-23
Option 7, the System Date, Time, and Timezone menu, enables you user to enter
the date, time, and timezone for the Sensor appliance. You can also synchronize
the date and time with a time service enabled host.
The following table contains the values you need to enter and a description of each
when configuring the system date, time, and time zone.
CIDS Settings
Parameters
Description
Option 1
Synchronize the
date and time with
another host
<Hostname>
Enables you to synchronize the Sensors

date and time with a reachable host, with
the time the service is running. The date
and time is set to that of the remote host.
(This uses the UNIX rdate command.)
Option 2Enter
the date and time
manually
<Year>,
<Month>, <Day>,
<Hour>,
<Minutes>
Enables you to set or change any date or

time setting manually.
Option 3Change
timezone
<Timezone>
Enables you to select the Sensors time

zone setting from a list of choices.
Option xExit to
main menu
Enables you to exit the System Date, Time,

and Timezone menu, and return to the
sysconfig-sensor menu.
Changing Passwords
Option
Option 8
www.cisco.com
CSIDS 2.15-24
Option 8, Passwords, enables you to change the password for any account on the
Sensor (for example, netrangr or root). You must enter the account name to
change the password. After you do this, you need to reenter the password for
verification purposes. When the password is changed, the old password is
discarded.
Exiting sysconfig-sensor
Option xExiting sysconfig-sensor
Options 1 through 5 require the Sensor to
rebootSystem prompts you to reboot when
parameters change: enter y at the prompt
Options 6 through 8 do not require the
Sensor to reboot
Director communications are ready
Proceed to add the Sensor to the Director
and enable intrusion detection
www.cisco.com
CSIDS 2.15-25
Option x, Exit, enables you to exit from the sysconfig-sensor. If options 1 through
5 (the IP settings) are modified, you are prompted to reboot the system. Enter y at
the prompt to reboot the Sensor. For options 6 and 8 the system is not required to
reboot, so you are returned to the prompt. For option 7 you are not required to
reboot except if the Timezone setting is change. CIDS communications are now
ready for the Director to establish a connection and enable intrusion detection.
Adding a Sensor in CSPM

This section describes how to add the Sensor to the Cisco Secure Policy Manager
(CSPM) after the Sensor has been bootstrapped.
Start Add Sensor Wizard
Select
Select
Add
Add Sensor
Sensor
www.cisco.com
CSIDS 2.15-27
To add a Sensor in the Network Topology Tree (NTT), use the Add Sensor
wizard. The Add Sensor Wizard helps you create a Sensor object and gives you
the option of extracting and saving a Sensors configuration information in a
signature template.
To add a Sensor in CSPM, perform the following steps:
Step 1
Choose Wizards>Add Sensor to start the Add Sensor wizard. The Add Sensor
wizard opens, displaying the Sensor Identification window.
Note
A sensor can also be added by right-clicking a network object and choosing

New>Gateways>Sensor. It is recommended to use the Add Sensor wizard.
Enter Sensors PostOffice

Identification Settings
Enter
Enter the
the
Host
Host Name
Name
Enter
Enter
the
the Host
Host ID
ID
Enter
Enter the
the
Org
Org Name
Name
Enter
Enter the
the
Org
Org ID
ID
Enter
Enter the
the
IP
IP Address
Address
Leave
Leave Cisco
Cisco
PostOffice
PostOffice in
in
the
the field
field
Verify
Verify the
the
Sensors
Sensors
address
address
Enter
Enter
comments
comments
For
For prepreconfigured
configured
Sensors
Sensors
www.cisco.com
Step 2
Submit the identification parameters for the Sensor in accordance with the
following table.
CIDS Settings
Parameters
Description
Sensor Name
<Host Name>
Alphanumeric identifier for the Sensor (e.g.,

sensor1).
Organization
Name
<Org Name>
Alphanumeric identifier for a group of CIDS

components (e.g., securitynoc).
IP address
<IP Address>
The IP address of the Sensor.
Host ID
1-65535
Numeric identifier for the Sensor.
Organization ID
1-65535

Components.
Associated
Network Service
Step 3
CSIDS 2.15-28
Leave as Cisco PostOffice.
PostOffice
Heartbeat Interval
1-65535
Specifies how often the Sensors

PostOffice queries the CSPM host.
Comments
<Comments>
Alphanumeric field to enter any user

comments about the Sensor.
Click Next to continue. The Default Gateway Address window opens.
Enter Default Gateway

Address
Enter
Enter
IP
IP address
address
Enter
Enter
Network
Network
Mask
Mask
Step 4
CSIDS 2.15-29
Enter the IP address and netmask for the default gateway.
Note
Step 5
www.cisco.com
The IP address is for the default gateway of the sensors network. This information
is required to build a network tree within CSPM. It does not effect the sensors
configuration.
Click Next to continue. The Sensor Configuration window opens.
Select Distribution Host,

Version, and Template
Choose
Choose
Distribution
Distribution
Host
Host
Choose
Choose the
the
version
version
Choose
Choose the
the
template
template
www.cisco.com
CSIDS 2.15-30
Step 6
Choose the Distribution host from the Host drop-down menu to specify the CSPM
host that will manage the Sensor.
Step 7
Choose a value from the Sensor Version drop-down menu to specify the version
on this Sensor.
Step 8
Choose the signature template currently applied to this Sensor from the Signature
Template drop-down menu.
Step 9
Click Next to continue. The Ready to Proceed window opens.
Sensor Added in Network

Topology
The
The Sensor
Sensor
is
is added
added
Click
Click Finish
Finish
www.cisco.com
CSIDS 2.15-31
Step 10 Click Finish to accept your changes and continue. The appropriate objects are
added to the NTT and any saved templates are added to the Tools and Services
tree.
Add the CSPM Host to the

Topology
Right-click Network
and
and choose
choose
New>Host.
Click Yes to
to add
add the
the
CSPM
host
itself
to
CSPM
the
topology.
the
Note
www.cisco.com
CSIDS 2.15-32
If you already have an existing CSPM installation, steps 10 and 11 can be omitted.
Step 11 To add the CSPM host itself to the topology, right-click the network object under
which it is going to be created and choose New>Host.
Note
The network where the CSPM host resides must exist in the Network Topology
Tree (NTT). If it does not, the network must be created in the NTT prior to the
aforementioned step.
Step 12 CSPM automatically detects itself and asks you if wish to create the detected
object in the NTT. Click Yes to accept.
Select the PDP

Select
Select the
the
Sensor
Sensor
Select
Select the
the
Control
Control
tab
tab
Choose
Choose
your
your host
host
as
as PDP
PDP
Click
Click OK
OK
www.cisco.com
CSIDS 2.15-33
Step 13 You must configure the Policy Distribution Point (PDP) for the Sensor object. To
do this, select the Sensor object from the NTT , then select the Control tab.
Step 14 Within the Control tab, select the CSPM host itself from the Policy Distribution
Point drop-down menu.

Step 15 Click OK to accept this change.
Note
The PDP host is assigned during the Add Sensor Wizard process. These steps are
not necessary if the Sensor was added using the Add Sensor Wizard.
Save and Update the

Configuration
Saves
Saves the
the
configuration
configuration
in
in CSPM
CSPM
Saves
Saves and
and updates
updates
the
the Sensor
Sensor
configuration
configuration files
files
www.cisco.com
Check
Check for
for
errors
errors
CSIDS 2.15-34
The Save and Update buttons on the toolbar are responsible for generating the
configuration files that can be pushed to the Sensor. After you successfully do this,
you can view the generated command set, using the Command tab on Sensor.
When you are managing devices other than Sensors, the Save and Update
operation generates commands for each device identified in the NTT. In addition,
it includes all the routing and mapping rules that are either derived by CSPM or
manually entered by you as part of these rule sets.
Push the Configuration Files

to the Sensor
Select
Select the
the
Command
Command
tab
tab
Select
Select the
the
Sensor
Sensor
Check
Check for
for
errors
errors
Click
Click Approve
Approve
Now
Now
www.cisco.com
CSIDS 2.15-35
After you generate and view the commands using the Save and Update buttons,
and the Command tab on the Sensor, you can push them to the Sensor by
manually approving them, which is the default publishing method. You can
configure CSPM to automatically publish the command sets to all the Policy
Enforcement Points (PEPs) that you are administering each time you click Save
and Update on the File menu. The following steps are performed to apply a
signature template to a Sensor in CSPM:
Step 16 Select the Sensor from the NTT.
Step 17 Select the Command tab in the Sensor view panel.
Step 18 Click the Approve Now button in the Command Approval section. Wait for the
configuration files to be downloaded to the Sensor.
Note
CSPM has two approval methods: manual and automatic. The default approval
method is manual. To change to automatic, Choose Tools>Options.
The configuration files generated by CSPM are stored in the following directory
structure:
Install Directory\Cisco Secure PostOffice\tmp\sensorca\hostname
Install Directory
Location of the CSPM installation.
hostname
Sensors PostOffice hostname (hostname.organizationname)
The following is an example location for sensor0s configuration files.

c:\Program Files\Cisco Systems PostOffice\tmp\sensorca\sensor0.pod0
Check for Errors

Select
Select the
the
Command
Command
tab
tab
Select
Select the
the
Sensor
Sensor
Check
Check for
for
errors
errors
www.cisco.com
CSIDS 2.15-36
You can check for errors by looking at the Status group box under the Commands
tab. After an update, you can select Distribution Status under Command
Review/Edit to see any errors that might have been generated.
Consistency Check
Select
Select
Consistency
Consistency
Check
Check
Check
Check for
for
errors
errors
www.cisco.com
CSIDS 2.15-37
The Consistency Check tool locates system inconsistencies within your CSPM
configurations. These system inconsistencies include invalid port numbers, invalid
IP addresses, and naming conflicts.
The following steps are performed to check system inconsistencies in CSPM:
Step 1
Choose Tools>Consistency Check from the main menu. The System

Inconsistencies Window opens in the right View pane.
Step 2
Check the items icons and descriptions for any errors.
Summary
This section summarizes the concepts you learned to complete this chapter.
Summary
The Sensor can be deployed in a standalone
installation, a firewall sandwich, and a remote
installation.
The Sensors Command and Control interface
is used for communication with the Director.
The Sensors Monitoring interface captures
packets for intrusion analysis.
You can gain access to a Sensor for
management by connecting a keyboard and a
monitor, attaching a console cable, or via the
network.
www.cisco.com
CSIDS 2.15-39
Summary (cont.)
The Sensor is bootstrapped using the
sysconfig-sensor utility.
The Add Sensor wizard is used to add a
Sensor object in CSPM.
The Command Approval function of CSPM
enables you to push the configuration files
from CSPM to the Sensor.
The Command Status and Command/Message
windows displays any errors when adding a
Sensor in CSPM.
www.cisco.com
CSIDS 2.15-40
Lab ExerciseSensor Configuration

Objectives
Bootstrap a Sensor.
Add a Sensor to CSPM.
Push configuration files from CSPM to a Sensor.
Visual Objective
The following figure displays the lab topology you will use to complete this lab
exercise.

Pod P
Your Pod
Pod Q
Peer Pod
172.30.1.0 /24
e0/1 .10P
idsmP
sensorP
e0/0 .1
.4
.6
10.0.P.0 /24
CSPM
sensorQ
e0/0 .1
.4
.6
idsmQ
10.0.Q.0 /24
10.0.P.3
CSPM
e0/1 .10Q
rQ
rP
10.0.Q.3
www.cisco.com
CSIDS 2.15-42
equipment to perform the lab.
Note
The P in an IP address, name, or command indicates your pod number. Make sure
to replace it with your pod number. The Q in an IP address, name, or command
indicates the pod number of a peer pod assigned by the instructor. Make sure to
replace it with your peers pod number.
Task 1Bootstrap the Sensor

Perform the following steps to bootstrap a Sensor:
Step 1
From the Windows NT command prompt, telnet to the Sensor and log on as user
root, password attack:
C:\> telnet 10.0.P.4
Trying...
Connected to sensor.
Escape character is '^}'.
login: root
Password: attack
#
Step 2
Run the sysconfig-sensor utility on the Sensor: The IDS Sensor Initial
Configuration Utility menu appears.
# sysconfig-sensor
Step 3
Step 4
Step 5
For options 1 through 5, confirm the following settings:

CIDS Parameters
Lab Settings
IP Address
IP Netmask
255.255.255.0
IP HostName
sensorP (where P = pod number)
Default route
Network Access Control
ALL
Select option 6 and follow the prompts to enter the CIDS Communications
Infrastructure parameters:
CIDS Parameters
Lab Settings
Sensor Host ID
Sensor Host Name
sensorP (where P = pod number)
Sensor Organization Name
Sensor IP Address
IDS Manager Host ID
IDS Manager Organization ID
IDS Manager Organization Name
After entering and reviewing all communication parameters, enter y when

prompted to create the CIDS configuration files.
Note
If you made any mistakes, enter n, and then enter y if you want to re-enter your
values.
Step 6
After the configuration files are created, press Enter when prompted to continue.
Step 7
Read the displayed information and press Enter to continue.
Step 8
Do not change settings associated with options 7, 8, and 9.
Step 9
Select option x to exit sysconfig-sensor.
Step 10 If prompted to, enter y to reboot. If you are not prompted to reboot, manually
reboot the Sensor by entering init 6 or reboot at the root prompt. Wait a few
seconds for the Sensor to reboot.
Note
The Telnet session will be disconnected when the Sensor starts rebooting.
Task 2Add a Sensor to CSPM

Perform the following steps to add a Sensor to CSPM:
Step 1
Choose Wizards>Add Sensor from the main menu to start the Add Sensor
wizard. The Add Sensor wizard opens, displaying the Sensor Identification
window.
Step 2
Submit the CIDS identification parameters for the Sensor in accordance with the
following table:
Sensor Settings
Value
Host Name
sensorP (where P = pod

number)
Organization Name
IP Address
10.0.P.4 (where P = pod

number)
Host ID
Organization ID
Associated Network Service
Leave as Cisco PostOffice
PostOffice Heartbeat Interval
Accept the default (5)
Comments
Leave blank
Step 3
Click Next to proceed. The Default Gateway Address window opens.
Step 4
Enter the IP address and netmask for the default gateway in accordance with the
following table.
Step 5
Default Gateway Settings
Value
IP Address
10.0.P.1 (P = pod number)
Netmasks
255.255.255.0
Step 6
Choose the Sensor Version from the drop-down menu as assigned by the
instructor.
CIDS Parameter
Value
sensor version
Step 7
Click Next to accept your changes and continue. The New Network Topology
Object window opens.
Step 8
Select the Dont show this message again checkbox.
Step 9
Click OK to continue.
Step 10 To add the CSPM host to the topology, right-click Net - 10.0.P.0 under Network
Topology Tree in the left pane and choose New>Host.

(where P = pod number)
Step 11 CSPM automatically detects itself and asks if you wish to create the detected
object in the Network Topology Tree. Click Yes to accept.

Step 12 Select sensorP from the Network Topology Tree (NTT). (where P = pod number).
Step 13 Select the Sensing tab in the Sensor view panel.
Step 14 Choose the Packet Capture Device from the drop-down menu. Ask your instructor
for the name of Packet Capture Device for the Sensor being used.
CIDS Parameter
Value
Packet Capture Device
Step 15 Click OK to accept this change.

Step 16 Click the Save button on the CSPM toolbar. The Cisco Secure Policy Manager
window opens.
Step 17 Select the Dont show this message again checkbox.
Step 18 Click the Update button on the CSPM toolbar.
Step 19 Click OK to continue.
Step 20 Select sensorP from the Network Topology Tree (NTT). (where P = pod number)
Step 22 Click the Approve Now button in the Command Approval section.
Step 23 Monitor the progress in the Status group box. Wait for the configuration files to be
downloaded to the Sensor.
Note
finished.
Alarm Management
Overview
Objectives
Managing alarms
Customizing the event viewer
Preference settings
Sensor status reporting
Summary
Lab exercise
Objectives
Objectives
Respond to and manage the alarms displayed
on the Event Viewer in CSPM.
Customize the Event Viewer display options
and preferences.
Determine the Sensors communication status,
service versions, service status, and statistics.
www.cisco.com
CSIDS 2.16-2
Managing Alarms
This section discusses how by using the CSPM Event Viewer you can view,
interpret, and dispose of alarms.
Opening the Event Viewer

Choose
Choose
Tools>View
Tools>View Sensor
Sensor Events
Events
>Database
>Database
Choose
Choose
Event
Event Type
Type
Choose
Choose
Start
Start Time
Time
Choose
Choose
Stop
Stop Time
Time
www.cisco.com
CSIDS 2.16-4
Intrusion alarms generated by Sensors are sent to the CSPM host, which displays
these events in the Event Viewer window. To open the Event Viewer, choose
Tools>View Sensor Events>Database from the top menu in the CSPM window.
The View Database Events window appears. Choose the Event Type and the Start
and Stop times. The following describes the View Database Event selection
parameters:
TypeIDS alarm types. CSIDS Alarms is the only selection.
TimeStart and Stop times of alarms to display in the Event Viewer
An option to view archived IDS events is also available. To open the Event
Viewer to view IDS archived events, choose Tools>View Sensor Events>Log
Files from the main menu in the CSPM window. The instance of the Event Viewer
that is viewing Sensor events from log files will not display new alarms received
by CSPM. CSPM stores new alarms in the database.
Many Event Viewer windows may be opened this way. Once an Event Viewer
window is opened, its display characteristics can be modified independently of all
other Event Viewer windows opened. This way you can customize each window
to display events based on different criteria as required by you environment.
Alarm Management 6-3
Alarm Fields
Count
Count
Name
Name
Destination
Destination
Port
Port
Source
Source
Address
Address
Source
Source
Port
Port
Destination
Destination
Address
Address
Details
Details
www.cisco.com
CSIDS 2.16-5
Each alarm in the Event Viewer is represented as an entry in a table. The

explanation for the fields shown in the above figure is as follows:
Field
Description
Count
When rows are consolidated this

represents the number of alarms that are
consolidated.
Name
The name of the alarm.
Source Address
The source IP address associated with the

alarm.
Destination Address
The destination IP address associated with

the alarm.
Destination Port
The destination TCP or UDP port

associated with the alarm.
Source Port
The source TCP or UDP port associated

with the alarm.
Details
Details contains information unique to a

signature that was triggered (for example,
the string that triggered the alarm).
Alarms Fields (cont.)
Source
Source
Location
Location
Local
Local Time
Time
Destination
Destination
Location
Location
Local
Local Date
Date
Signature
Signature
ID
ID
Application
Application
Name
Name
SubSig
SubSig ID
ID
Sensor
Sensor
Name
Name
Severity
Severity
Org
Org Name
Name
Level
Level
www.cisco.com
CSIDS 2.16-6
Field
Description
Source Location
IN indicates that the destination IP address is in

the network defined by the user as internal.
OUT indicates that the destination IP address is
not in the network defined by the user as
internal.
Destination Location
IN indicates that the destination IP address is in

the network defined by the user as internal.
OUT indicates that the destination IP address is
not in the network defined by the user as
internal.
Signature ID (Sig ID)
The numeric identifier assigned to the signature

that triggered the alarm.
Sub-Signature ID
The numeric identifier assigned to the subsignature that triggered the alarm. Some
signatures have a sub-signature ID but others do
not.
Severity
The severity assigned to the signature that

triggered the alarm. The severity is low, medium,
or high.
Level
A number in the range of 1 through 5. This is the

numeric severity from which the severity
classification is assigned. By default, Low is 1 or
2, Medium is 3 or 4, and High is 4 or 5.
Organization Name
The organization name of the Sensor that

generated the alarm.
Sensor Name
The name of the Sensor that generated the

alarm.
Application Name
The name of the Sensor service that generated

the alarm. All intrusion alarms are generated by
packetd.
Local Date
The date that the alarm was generated as

reported by the Sensor. The date is based on
the local time setting on the Sensor.
Local Time
The time that the alarm was generated as

reported by the Sensor. The date is based on
the local time setting on the Sensor.
Resolving Hostnames
Right-click
Right-click and
and
choose
choose
Resolve
Resolve Hostnames
Hostnames
www.cisco.com
CSIDS 2.16-7
From the Event Viewer you can quickly and easily identify the name of the host
that triggered the alarm, and the host that was the target of the attack. To do this,
right-click the alarm you wish to examine, then choose Resolve Hostnames from
the drop-down menu. A window is displayed showing the source and destination
IP addresses and their respectively resolved hostnames. If either hostname cannot
be resolved, the message Cannot be resolved is displayed for the unresolvable
host.
Note
For IP addresses to be resolved, the CSPM host must have a local host table entry,
have been configured to access a DNS server, or both.
Other ways to open the Hostname Resolution window are as follows:
Select the alarm to examine and choose Tools>Resolve Hostnames from the
top menu bar.
Select the alarm to examine and click the Resolve Hostname (H) button on
the top toolbar.
Viewing the Context Buffer
Right-click
Right-click and
and
choose
choose
Context
Context Buffer
Buffer
www.cisco.com
CSIDS 2.16-8
For TCP-based signatures, the Sensor captures up to 256 characters of the TCP
stream, which can be examined from the Event Viewer. This is called the context
buffer and it contains keystrokes, data, or both in the connection stream around the
string of characters that triggered the signature. This feature can be used to
determine if the triggered alarm was from a deliberate attack or if it is an
accidental set of keystrokes.
To view the captured context buffer, right-click the alarm you wish to examine,
then choose Context Buffer from the drop-down menu. A window is displayed
showing the context buffer data. When the context buffer is not available, the
Context Buffer option in the drop-down menu will be grayed-out.
Other ways to open the Context Buffer window are as follows:
Select the alarm to examine and choose View>Context Buffer from the top
menu bar.
Select the alarm to examine and click the Show Context Buffer button on the
top toolbar.
Opening the NSDB
Right-click
Right-click and
and choose
choose
Network
Network Security
Security Database
Database
www.cisco.com
CSIDS 2.16-9
The Network Security Database (NSDB) is Ciscos HTML-based encyclopedia of

network vulnerability information. You can examine the NSDB for a specific
alarm. To do this, right-click the alarm you wish to examine, then choose
Network Security Database from the drop-down menu.
Other ways to open the NSDB window are as follows:
Select the alarm to examine and then choose Tools>NSDB from the top menu
bar.
Select the alarm to examine and click the Network Security Database button
on the top toolbar.
Exploit Signature Information
www.cisco.com
CSIDS 2.16-10
A typical NSDB Exploit Signature page contains the following information about
the signature that triggered the alarm:
Signature NameThe name of the signature.
IDA unique identification number for the signature.
Sub IDA unique sub-identification number for the sub-signature.
Recommended Alarm LevelThe alarm severity level recommended by

Ciscos Security Technology Assessment Team (STAT).
Signature TypeIndicates the alarm was detected on the NETWORK.
Signature StructureIndicates if the signature structure is either ATOMIC or

COMPOSITE.
ImplementationIndicates if the signature implementation is either

CONTENT or CONTEXT.
Signature DescriptionA concise explanation of the signature and what

exploits it detects.
Benign Trigger(s)An explanation of any false positives that may appear to

be an exploit but are actually normal network activity.
Related VulnerabilityEach vulnerability information page provides

background on the vulnerability and a link to any available countermeasures.
User NotesLink to a page with information unique to this installation and

implementation.
Related Vulnerability
Information
www.cisco.com
CSIDS 2.16-11
A typical NSDB Related Vulnerability page contains the following information

about the vulnerability associated with the signature that triggered the alarm:
Vulnerability NameThe name of the vulnerability being exploited.
AliasAny other names used to refer to this vulnerability or exploit.
IDA unique identification number for the vulnerability. (It is unrelated to

the signature ID.)
Severity LevelA severity level associated with the vulnerability, which

may or may not match the recommended alarm level.
Vulnerability TypeIndicates that this is a network vulnerability.
Exploit TypeIndicates the type of exploit, such as Info, Recon, Access, or

Denial.
Affected System(s)List of operating systems and their versions affected by

this vulnerability.
Affected Program(s)List of applications and their versions affected by this

vulnerability.
Vulnerability DescriptionA concise explanation of the vulnerability and

ways to exploit it.
Consequence(s)What damage is done by exploiting this vulnerability.
Countermeasures(s)Description of things that can be done to protect

systems from this vulnerability.
Advisory/Related Info Link(s)Links to sites on the Web that contain

additional information about the vulnerability or exploit.
Fix/Upgrade/Patch Link(s)Links to sites on the Web that contain fixes,

upgrades, or patches for the vulnerability.
Exploit Link(s)Links to sites on the Web where exploits for the

vulnerability may be found.
User NotesLink to a page with information unique to this installation and

implementation.
User Notes
www.cisco.com
CSIDS 2.16-12
The User Notes page is an empty template in which the user can fill in information
unique to their installation and implementation. You can use any text or HTML
editor to enter information. The user notes are located in the CSPM report
directory (e.g., C:\Program Files\Cisco Systems\Cisco Secure Policy
Manager\Report\nsdb\html).
Suspending and Resuming

Alarm Display
Choose
Choose
Suspend
Suspend New
New Events
Events or
or
Resume
Resume New
New Events
Events
www.cisco.com
CSIDS 2.16-13
You may suspend the Event Viewer from displaying new alarms. To suspend the
Event Viewer, choose Edit>Suspend New Events on the top menu bar. To resume
alarms, choose Edit>Resume New Events on the top menu bar.
Other ways to suspend or resume the Event Viewer are as follows:
To suspend an alarm, click the Pause Live Feed button on the top toolbar.
To resume an alarm, click the Resume Live Feed button on the top toolbar.
The Suspend feature is best used to analyze current alarms being displayed.
Suspending alarms prevents new alarms from being displayed and shuffling the
current alarms. The Suspend feature is also beneficial when deleting alarms.
Deleting Alarms
Right-click
Right-click and
and choose
choose
Delete
Delete Rows>From
Rows>From This
This Grid,
Grid,
Delete
Delete Rows>From
Rows>From All
All Grids,
Grids, or
or
Delete
Delete Rows>From
Rows>From Database
Database
www.cisco.com
CSIDS 2.16-14
When an alarm has been acknowledged, dealt with, or both, you may want to
remove it from the Event Viewer grid or from database all together. To do this,
right-click the alarm you wish to delete, then choose Delete Row(s)>From This
Grid, Delete Row(s)>From All Grids, or Delete Row(s)>From Database from
the drop-down menu. The differences between the three options are as follows:
From This GridDeletes alarms from the grid where this action is being
performed. It will not delete alarms from other grids or the CSPM database.
From All Grids Deletes alarms from all grids including other grids that
may be opened. It will not delete alarms from the CSPM database.
From Database Deletes alarms from all the grids and the CSPM database.
If you use this option the alarm is completely gone and you may not display it
on the Event Viewer again, even if you open another Event Viewer.
Note
None of the delete options affect alarms that are logged in the Sensor log files.
WARNING If the Count cell of the top row of the Event Viewer is selected when using
any of the delete options, all rows will be deleted from the Event Viewer.
Other ways to delete alarms are as follows:
Select the alarm to delete and choose Edit>Delete Row(s)>From This Grid,
Edit>Delete Row(s)>From All Grids, or Edit>Delete Row(s)>From
Database from the top menu bar.
Select the alarm to delete and click the Deletes the selected rows from the
current grid only button on the top toolbar.
Customizing the Event Viewer

This section discusses the different options that allow you to customize the Event
Viewer to meet your environment.
Expanding the Row One

Column to the Right
Click
Click the
the
Expand
Expand This
This Branch
Branch One
One
Column
Column to
to the
the Right
Right
button
button
www.cisco.com
CSIDS 2.16-16
By default, the Event Viewer consolidates or collapses alarms based on the first
two field columns. To view the details of collapsed alarms, you must expand the
columns until the fields that you are interested in are shown. To do this, select the
row that you want to expand and then click the Expand This Branch One
Column to the Right button on the top toolbar.
Other ways to expand alarms one column to the right are as follows:
Select the row to expand and choose Edit>Expand>One Column on the top
menu.
Double-click the row you want to expand.
Note
This is not a persistent change. This means that closing the Event Viewer and reopening it will bring back the default expansion boundary.
Expanding the Row All the

Way to the Right
Click
Click the
the
Expand
Expand This
This Branch
Branch all
all
the
the way
way to
to the
the Right
Right
button
button
www.cisco.com
CSIDS 2.16-17
In one click you can expand the row all the way to the right. To do this, select the
row that you want to expand and then click the Expand This Branch all the way
to the Right button on the top toolbar.
Another way to expand alarms all the way to the right is to select the row to
expand and choose Edit>Expand>All Columns from the top menu.
Note
This is not a persistent change. This means that closing the Event Viewer and reopening it will bring back the default expansion boundary.
Collapsing the Row One

Column to the Left
Click
Click the
the
Collapse
Collapse This
This Branch
Branch One
One
Column
Column to
to the
the Left
Left button
button
www.cisco.com
CSIDS 2.16-18
To consolidate alarm details, you must collapse the columns until the fields that
you are interested in are consolidated. To do this, select the row that you want to
consolidate and then click the Collapse This Branch One Column to the Left
button on the top toolbar.
Another way to collapse alarms one column to the left is to select the row to
expand, and then choose Edit>Collapse>One Column from the top menu.
Note
This is not a persistent change. Changes only affect the current Event Viewer.
New Event Viewers launched will have the default expansion boundary.
Collapsing the Row to the

Currently Selected Column
Click
Click the
the
Collapse
Collapse This
This Branch
Branch to
to
the
the Currently
Currently Selected
Selected
Column
Column button
button
www.cisco.com
CSIDS 2.16-19
In one click you can collapse the row all the way to the column currently selected.
To do this, select the column you want to collapse to in the row that you want to
collapse, and then click the Collapse This Branch to the Currently Selected
Column button on the top toolbar.
Another way to collapse alarms all the way to the column currently selected is to
select the column you want to collapse to in the row you want to collapse and
choose Edit>Collapse>All Columns on the top menu.
Note
Changing the Alarm

Expansion Boundary
Right-click
Right-click and
and choose
choose
Set
Set Event
Event Expansion
Expansion Boundary
Boundary
www.cisco.com
CSIDS 2.16-20
By default, the Event Viewer expands the first two columns of the grid. You can
change the expansion boundary for new alarms that come in. To do this, rightclick the column that you want to expand to, and choose Set Event Expansion
Boundary. From this point forward any new alarms that come in will be expanded
up to the column that has been set to be the new expansion boundary.
Other ways to set the new expansion boundary are as follows:
Select the column that you want to expand to, and choose Edit>Set Event
Expansion Boundary from the top menu.
Select the column that you want to expand to, and click the Set Event
Expansion Boundary button on the top toolbar.
Note
Moving Columns
Click
Click and
and drag
drag the
the header
header of
of
the
the column
column to
to be
be moved
moved
www.cisco.com
CSIDS 2.16-21
Columns can be moved to any position in the Event Viewer grid. To do this, clickand-drag the column header of the column to be moved, and move it to the new
position.
Note
New Event Viewers launched will have the default column order.
Deleting Columns from the

Event Viewer
Choose
Choose
Delete
Delete Column
Column
www.cisco.com
CSIDS 2.16-22
You can delete columns from the Event Viewer. To do this, right-click the column
to be deleted, and then choose Delete Column from the drop-down menu.
Another way to delete columns from the Event Viewer is to check anywhere on
the column that you want to delete, then choose Edit>Delete Column on the top
menu.
Note
Deleting columns this way does not permanently remove the columns. Closing the
Event Viewer and re-opening it brings any deleted columns back.
WARNING Removing columns will affect CIDS features. The columns must exist in the
Event Viewer to enable the feature affected.
The following table describes the Event Viewer columns that affect CIDS
features.
Column
Feature Affected
Source Address
Block, Remove Block (except All)
Sensor Name
View Block List, View Connection Status, View Network

Device, View Services, View Statistics, Block, Remove
Block, Reset Statistics, Enable Future Blocks, Disable
Future Blocks
Org Name

Future Blocks
App Name
View Statistics, Reset Statistics
Selecting Columns to Be
Displayed
Choose
Choose or
or
Select
Select or
or deselect
deselect
Click
Click Up
Up
or
or Down
Down
Click
Click
Recommended
Recommended
Choose
Choose
Edit>Insert/Modify
Edit>Insert/Modify Column(s)
Column(s)
Click
Click OK
OK
www.cisco.com
CSIDS 2.16-23
You can customize what field columns are displayed in the Event Viewer. To do
this, choose Edit>Insert/Modify Column(s) on the top menu. This opens the
Insert/Modify Columns window.
The Insert/Modify Columns window shows all the available fields. To select or
deselect a field to be displayed, click the selection box in the Show column for
that field.
WARNING Removing columns will affect CIDS features. The columns must exist in the
Event Viewer to enable the feature affected.
The following table describes the Event Viewer columns that affect CIDS
features.
Column
Feature Affected
Source Address
Block, Remove Block (except All)
Sensor Name

Future Blocks
Org Name

Future Blocks
App Name
View Statistics, Reset Statistics
To choose the default sort order choose (ascending) or (descending) in the

Sort column for that field by clicking the sort field and toggling between or .
To change the order in which the fields are displayed, you may use the Up or
Down buttons to move the field location up or down.
If you click the Recommended button, the field settings are reverted back to their
default.
Once you have customized the view settings for the fields, you must click OK to
accept your changes. To ignore your changes, click Cancel, where you will go
back to the Event Viewer.
Note
This is a persistent change. Changes will affect newly launched Event Viewers.
Preference Settings
This section describes the different preference settings that can be customized in
the Event Viewer.
Changing the Preference

Settings
Choose
Choose
Edit>Preferences
Edit>Preferences
www.cisco.com
CSIDS 2.16-25
In the Preferences window, you can customize a number of parameters for your
environment. To do this, choose Edit>Preferences from the top menu. This opens
the Preferences window.
Actions
Command Timeout
How long CSPM waits
for a response from a
Sensor
Time to Block
How long a Sensor
blocks a host when a
manual block is issued
Subnet Mask
The subnet mask used
when manually blocking
a network
Note
www.cisco.com
CSIDS 2.16-26
The settings in the Preferences window apply to all Event Viewers that are opened
from CSPM. If you have more than one instance open when you make a change in
the preference window, you must close and open those event viewer instances in
which you did not specifically make the changes.
The Actions group box in the Preferences window allows you to set the following
values:
Command Timeout (seconds)Determines how long, in seconds, the Event

Viewer will wait for a response from the Sensor before concluding that it
cannot communicate with the sensor. In most cases, it is not necessary to
modify this value. If you find that Command Timeout is often reached, you
might consider increasing it or diagnosing the slow response.
The Command Timeout value applies to all functions that require
communication through the PostOffice infrastructure. For example, functions
such as retrieving Sensor statistics, viewing Sensor block lists, and requesting
that the Sensor blocks a particular IP address all use the Command Timeout.
This timeout value is not used for non-PostOffice functions, such as DNS
queries. The default value is 10 seconds. The allowable range is 1 to 3,600
seconds (one hour).
Time to Block (minutes)Specifies how long the Sensor blocks traffic from
the specified source when you issue a Block command from the Event
Viewer. The block duration value that can be specified for the Sensor in the
Network Topology Tree (NTT) applies only to blocks that are generated
automatically by that Sensor. The Time to Block value in the Preferences
dialog box applies only to manually generated blocks from the Event Viewer.
The default value is 1440 minutes (one day). The allowable range is 1 to
525,600 minutes (one year).
Subnet MaskUsed to mask the source address value that you wish to block
to determine the range of the blocking rule that is published to the blocking
devices by the Sensor. This subnet mask applies only to the Block>Network
and Remove Block>Network options from the Event Viewer. The default
value is 255.255.255.0.
Cells
Blank Left Cells to the

left of the default
boundary with similar
values with be blanked.
Blank Right Cells to
the right of the default
boundary with similar
values with be collapsed.
www.cisco.com
CSIDS 2.16-27
The Cells preferences option enables you to determine if cell values will be
displayed or collapsed.
Cells (cont.)
Blank
Blank left
left
selected
selected
Blank
Blank right
right
deselected
deselected
Blank
Blank left
left
deselected
deselected
Blank
Blank right
right
selected
selected
www.cisco.com
CSIDS 2.16-28
The Blank Left and Blank Right check boxes in the Cells section of the Preference
window enable you to specify that cells be blank or filled:
Blank Left This check box determines whether values that are suggested by
a cell above are filled in. For example, consider the following alarms
triggered by the same source IP address of 172.30.1.88: WWW perl
interpreter attack, WWW IIS view source attack, and WWW IIS newdsn
attack. If the Blank Left box is selected, the grid appears as follows:
172.30.1.88
WWW perl interpreter attack
<blank>
WWW IIS view source attack
<blank>
WWW IIS newdsn attack
If the Blank Left box is not selected, the grid appears as follows:
172.30.1.88
WWW perl interpreter attack
172.30.1.88
WWW IIS view source attack
172.30.188
Blank RightWhen cells are collapsed their background color is gray and if
the collapse values are different a + sign is displayed. When Blank Right is
not selected (the default) and if a cell is collapsed but the value in the cell is
the same in all the collapse cells, then the actual value is displayed. By
selecting Blank Right, a + sign will be placed in a collapsed cell regardless
if the value is the same in all the collapsed cells or not.
Status Events
Show Status Events in

Grid Status events are
reported as an event in
the Event Viewer Grid.
Display Popup Window
Popup Window with the
status event description
is displayed.
www.cisco.com
CSIDS 2.16-29
The Show Status Events in Grid and Display Popup Window options in the Status
Events group box of the Preference window enable you to specify where status
events are displayed in the Event Viewer. The following are the two options for
displaying status events:
Show Status Events in GridThis is the default setting. Displays status

events in the grid of the Event Viewer when selected. If you do not want
these status events to appear in the grid, clear this checkbox. The following
are the three possible status events:
PostOffice Initial NotificationWhen a Sensors PostOffice service is

started, it sends a notification indicating the service was started.
Route Down!This indicates that a device has lost communications with
another device.
Route UpThis indicates that a device has recovered communications
with another device.
Display Popup WindowA popup window is displayed only when a Route

Down! message is received.
Status Events (cont.)
Show
Show the
the status
status
of
of events
events in
in the
the
grid
grid selected
selected
Display
Display the
the
popup
popup window
window
Selected
Selected
www.cisco.com
CSIDS 2.16-30
The previous figure shows examples of what windows open when you select ether
Show Status Events in Grid or Display Popup Window from the Status Events
group box.
Event Severity Indicator
Event Severity
Indicator Events can
either be represented by
an icon or a color.
www.cisco.com
CSIDS 2.16-31
The Event Severity Indicator group box enables you to choose how events are
represented. There are two Severity Indicator options that you must select from:
ColorThis is the default setting. The severity is indicated by a color:
High = Red
Medium = Yellow
Low = Green
IconThe severity is indicated by icons:
High = Red exclamation point
Medium = Yellow flag
Low = No icon
Event Severity Indicator

(cont.)
Color
Color
Selected
Selected
Icon
Icon
Selected
Selected
www.cisco.com
CSIDS 2.16-32
The previous figure shows examples of the two different ways events can be
graphically represented.
Boundaries
Default Expansion
BoundaryDefault
number of expanded
columns.
Maximum Events Per
GridHow many alarms
can be displayed in a
single Event Viewer.
Event Batching
TimeoutHow often the
Event Viewer is updated
during an alarm flood.
www.cisco.com
CSIDS 2.16-33
The Boundaries group box in the Preferences window enables you to set the
following values:
Default Expansion BoundarySpecifies the default number of columns in

which the cells of a new event are expanded if the event does not match an
existing event group. The cells in an event are expanded as long as the event
matches an existing event group. After there are no matches, a new row is
created for the event, and the cells in the new event are expanded until the
Event Expansion Boundary is reached.
Maximum Events Per GridThe maximum number of alarms that can be

displayed in a single Event Viewer. When the maximum value is reached, a
message is displayed. The default value is 250,000 alarms. The allowable
range is 1 to 4,000,000,000 alarms.
Note
Setting this field to its maximum value may cause the capacity of the CSPM
database to be exceeded.
Event Batching Timeout (seconds)Specifies how often the Event Viewer is

updated during an alarm flood. The default value is 0 seconds.
Severity Mapping
Low
Fixed to 1
Default range is 12
Medium
Must be greater than or
equal to Low
Default setting is 3
High
Must be greater than or
equal to Medium
Default setting is 4
www.cisco.com
CSIDS 2.16-34
The values under the Severity Mapping group box of the Preferences window,
map a range of an alarm's severity level (a number that usually ranges from 1 to 5)
to a severity (Low, Medium, or High).
By default, events at levels 1 and 2 are Low, level 3 is Medium, and levels 4 and
higher are High. By changing the starting level value for any option, you can
change the associated range of severities. This changes the associated color and
icon to the events that fall within that range within the Event Viewer grids.
There are a few constraints on the numbers you can specify. The Medium level
must be greater than or equal to the Low level, and the High level must be greater
than or equal to the Medium level. The start value for the Low level range is fixed
at 1. Also, all values must be between 1 and 255. If they are not, you will be
notified, and the values will be adjusted for you.
Sensor Status Reporting

This section discusses the Sensor status reporting options in the Event Viewer.
Connection Status Pane
Choose
Choose
View>Connection
View>Connection
Status
Status Pane
Pane
www.cisco.com
CSIDS 2.16-36
You can choose to display the Connection Status Pane in the Event Viewer. The
Connection Status Pane displays icons for all the Sensors reporting to CSPM and
provides options to get status information from the Sensors. To view the
Connection Status Pane, choose View>Connection Status Pane from the top
menu. This displays the Connection Status Pane on the left side of the Event
Viewer.
Connection Status
Right-click
Right-click and
and
choose
choose
Connection
Connection Status
Status
www.cisco.com
CSIDS 2.16-37
From the Connection Status Pane you can get information on the status of the
connection between CSPM and the Sensors reporting to it. To do this, right-click
the Sensor you want connection status information about on the Connection Status
Pane and choose Connection Status. This opens the Connection Status window,
which indicates the status of the connection for the selected Sensor.
In the Connection Status window, you will see one of these two possible
connection status messages:
Connection is Established:
The connection status of host "sensor0" is:

director0.pod0 Connection 1: 10.0.0.3
sto:0002 with Version 1
45000 1 [Established]
Connection Has Not Been Established:
The connection status of host "sensor0" is:

Error timeout waiting for response
Other ways to open the Connection Status windows are as follows:
Select the Sensor you want connection status information about from the
Connection Status Pane and choose View>Connection Status from the top
menu.
Select a row in the Event Viewer and choose View>Connection Status from
the top menu. You will get connection status information for the Sensor that
reported the alarm you selected in the Event Viewer. If the row has
consolidated alarms from multiple Sensors, the connection status of all
Sensors is reported.
Service Status
Right-click
Right-click and
and
choose
choose
Service
Service Status
Status
www.cisco.com
CSIDS 2.16-38
From the Connection Status Pane you can get information on the status of the
services running on the Sensors reporting to your CSPM host. To do this, rightclick the Sensor you want service status information about on the Connection
Status Pane and choose Service Status. This opens the Daemon Status window,
which indicates the status of the services running on the selected Sensor.
In the Daemon Status window, you will see the status of the services running in
the following format:
The status of the enabled applications on host "sensor0" is as follows:
fileXferd
Running
loggerd
Running
sapd
Running
configd
Running
packetd
Running
END
Other ways to open the Daemon Status window are as follows:
Select the Sensor you want service status information about on the
Connection Status Pane, and choose View>Services>Status from the top
menu.
Select a row in the Event Viewer and choose View>Services>Status from

the top menu. You will get service status information for the service that
generated the selected alarm only, typically packetd. If the App Name column
is not being displayed in the Event Viewer, View>Services>Status will be

grayed out, indicating the option is not available.
Service Versions
Right-click
Right-click and
and
choose
choose
Service
Service Versions
Versions
www.cisco.com
CSIDS 2.16-39
From the Connection Status Pane you can get the version information of the
services running on the Sensors reporting to your CSPM host. To do this, rightclick the Sensor you want service version information about on the Connection
Status Pane and choose Service Versions. This opens the Daemon Versions
window, which indicates the versions of the services running on the selected
Sensor.
In the Daemon Versions window, you will see the version of the services running
in the following format:
The version of postofficed on host "sensor0" is:
postofficed v2.2.1 (release) 99/07/19-22:30
The version of fileXferd on host "sensor0" is:
fileXfer v2.2.1 (release) 99/07/19-22:36
The version of sapd on host "sensor0" is:
sapd v2.2.1 (release) 99/07/19-22:31
The version of configd on host "sensor0" is:
configd v2.2.1 (release) 99/07/19-22:29
The version of packetd on host "sensor0" is:
packetd v2.2.1.5 (release) 00/08/15-12:22
Other ways to open the Daemon Versions window are as follows:
Select the Sensor you want service version information about from the
Connection Status Pane and choose View>Services>Version on the top
menu.
Select a row in the Event Viewer and choose View>Services>Version from

the top menu. You will get service version information for the service that
generated the selected alarm only, typically packetd. If the App Name column
is not being displayed in the Event Viewer, View>Services>Version will be
grayed out, indicating the option is not available.
Statistics
Choose
Choose
View>Statistics
View>Statistics
www.cisco.com
CSIDS 2.16-40
The Sensor keeps track of statistics regarding the processing of network packets,
such as the number of packets viewed since the Sensor's services were last started.
To view the statistics for a Sensor, select the Sensor you want statistics
information about on the Connection Status Pane and choose View>Statistics
from the top menu. This opens the Sensor Statistics window.
In the Sensor Statistics window, you will see the statistics for the selected Sensor
in the following format:
IP statistics for host "sensor0":
Statistics from: 12/07/2000 20:39:11
Number of seconds: 73395
IP Packets: 33696
Filtered Packets: 0
ICMP Packets: 19476
TCP Packets: 349
UDP Packets: 13871
Other Packets: 0
Bad IP Packets: 0
Bad ICMP Packets: 0
Bad TCP Packets: 0
Bad UDP Packets: 0
Objects: 128
Number Of Src Objects: 16
Number Of Dst Objects: 7
Number Of Dual Objects: 16
Number Of Quad Objects: 0
Number Of TCP Streams: 0
Stats: 0 84 84 0.00 38485 1
Packet socket statistics for host "sensor0":
Statistics from: 12/07/2000 20:39:11

Packets processed: 51946
Bytes processed: 4638695
Bad packets: 0
Bytes of bad packets: 0
IP v4 packets: 33698
Bytes of IP v4 packets: 2829839
Syslog socket statistics for host "sensor0":
Statistics from: 12/07/2000 20:39:11
Packets dropped: 0
Packets processed: 0
Bytes processed: 0
Bad packets: 0
Bytes of bad packets: 0
Filter name packets: 0
Bytes of filter packets: 0
Another way to open the Sensor Statistics window, is to select a row in the Event
Viewer and choose View>Statistics from the top menu. You will get statistic
information for the Sensor that generated the selected alarm. If the Sensor Name
column is not being displayed in the Event Viewer, View>Statistics will be grayed
out, indicating the option is not available.
Reset Statistics
Choose
Choose
Actions>Reset
Actions>Reset Statistics
Statistics
www.cisco.com
CSIDS 2.16-41
You can reset the counts back to zero for the statistics being kept for a Sensor. To
reset the statistic counts for a Sensor, select the Sensor you want to reset statistics
for on the Connection Status Pane and choose Actions>Reset Statistics from the
top menu. This resets the statistics for the selected Sensors and opens the
Resetting Statistics status window.
In the Resetting Statistics window, you will see the reset statistics status for the
selected Sensor in the following format:
The status of resetting IP statistics for host "sensor0" is:
Success
The status of resetting packet statistics for host "sensor0" is:
Success
The status of resetting syslog statistics for host "sensor0" is:
Success
Another way to reset the Sensor statistics is to select a row in the Event Viewer
and choose Actions>Reset Statistics on the top menu. You will reset the statistics
for the Sensor that generated the selected alarm. If the Sensor Name column is not
being displayed in the Event Viewer, Actions>Reset Statistics will be grayed out,
indicating the option is not available.
Summary
Summary
Use the Event Viewer in CSPM to respond to
and manage the alarms.
The Event Viewer provides many display
options and preferences to customize how
alarms are displayed.
Deleting columns from the Event Viewer can
disable functionality.
The Sensor status reporting functions are
used to view the status of communications
between Sensors and CSPM.
www.cisco.com
CSIDS 2.16-43
Lab ExerciseManaging Alarms

Objectives
Determine the attributes of an alarm.
Customize your Event Viewer.
Visual Objective
The following figure displays the lab topology you will use to complete this
exercise.

Pod P
Your Pod
Pod Q
Peer Pod
172.30.1.0 /24
e0/1 .P
idsmP
sensorP
e0/1 .10Q
sensorQ
e0/0 .1
.4
rQ
rP
e0/0 .1
.4
.6
10.0.P.0 /24
CSPM
.6
idsmQ
10.0.Q.0 /24
10.0.P.3
CSPM
10.0.Q.3
www.cisco.com
CSIDS 2.16-45
Task 1Managing Alarms

Perform the following steps to manage alarm icons:
Step 1
Choose Tools>View Sensor Events>Database from the CSPM main menu. The
View Database Events window appears.
Step 2
Click OK to accept the default values. The Event Viewer window opens.
Step 3
From your own CSPM host, open your web browser and attack your peers web
server by entering the following in the URL field:
http://10.0.Q.3/../..
(where Q = peers pod number)

Your peers Event Viewer displays the new alarm.
Step 4
After your peer attacked your web server, fill out this table and answer the
following questions about the alarm that was generated:
Name
Source Address
Destination Address
Details
Source Port
Destination Port
Source Location
Destination Location
Signature ID
Sub-Signature ID
Severity
Level
Organization Name
Sensor Name
Application Name
Local Date
Local Time
What string of characters triggered this alarm?

________________________________________________________
What Sensor service generated this alarm?
________________________________________________________
What is the signature structure of this alarm?
________________________________________________________
What systems are affected by this alarm?
________________________________________________________
What are the consequences of this attack if successful?
________________________________________________________
Task 2Customizing the Event Viewer

Perform the following steps to customize your Event Viewer:
Step 1
Choose Edit>Insert/Modify Column(s) from the Event Viewer. The

Insert/Modify Columns window opens.
Step 2
Enable the columns listed in the following table. Columns not listed should be
disabled:
Column Name
Enable
Name
Yes
Source Address
Yes
Dest Address
Yes
Details
Yes
Source Loc
Yes
Dest Loc
Yes
Sensor Name
Yes
Org Name
Yes
App Name
Yes
Local Date
Yes
Local Time
Yes
Step 3
Close the Event Viewer.
Step 4
Choose Tools>View Sensor Events>Database from the CSPM main menu to restart the Event Viewer. The View Database Events window appears.
Step 5
Click OK to accept the default values. The Event Viewer window opens.
Note
Your Event Viewer should only display the columns listed in the table.
Task 3Configure the Event Viewer to display the

Recommended Columns
Perform the following steps to configure your Event Viewer to display the
recommended Columns.
Step 6
Choose Edit>Insert/Modify Column(s) from the Event Viewer. The

Insert/Modify Columns window opens.
Step 7
Click the Recommended button.
Step 8
Click the OK button.
Step 9
Close the Event Viewer.
Step 10 Choose Tools>View Sensor Events>Database from the CSPM main menu to re-
start the Event Viewer. The View Database Events window appears.
Step 11 Click OK to accept the default values. The Event Viewer window opens.
Note
Your Event Viewer should display the recommended columns.
Task 4Deleting Alarms from the Event Viewer

Perform the following steps to delete the alarm with the most occurrences from the
Event Viewer.
Step 1
Click the Pause Live Feed (||) button on the toolbar.
Step 2
Choose the Alarm with the largest Count.
Step 3
Choose Edit>Delete Row(s)>From Database from the CSPM main menu. The
Event Viewer Delete Row window opens.
Step 4
Click the Yes button to confirm the delete operation.
Step 5
Click the Resume Live Feed (>) button on the toolbar.

Note
finished.
Cisco Intrusion
Detection System
Signatures
Overview
This chapter explains what a signature is and the many different signature series
that Cisco Intrusion Detection System (CIDS) uses.
Objectives
Understanding signatures
1000 SeriesIP signatures
2000 SeriesICMP signatures
3000 SeriesTCP signatures
4000 SeriesUDP signatures
5000 SeriesWeb signatures
6000 SeriesCross-protocol signatures
8000 SeriesString match signatures
10000 SeriesACL policy violation signatures
Summary
Objectives
Objectives
Upon completion of this chapter, you will be
Describe what is a signature.
Name and identify signature implementations,
structures, and classes.
Describe what are signature severities.
Name the attack probability and immediate threat
level for the default severities.
Name and identify all CIDS signature series and their
major categories.
7-2
www.cisco.com
CSIDS 2.17-2
Understanding Signatures
This section describes what a signature is; how they are implemented and
structured; their different classes, types, series, and categories; and their severities.
Signature Definition
A set of rules pertaining to typical

intrusion activity that, when matched,
generates a unique response.
www.cisco.com
CSIDS 2.17-4
A signature is a set of rules pertaining to typical intrusion activity, which is

compared against the network traffic. When this set of rules is matched to network
activity, a unique response is generated for the event.
Cisco Intrusion Detection System Signatures
7-3
Signature Implementations
and Structures
Signature implementation
ContextTrigger data contained in packet header
ContentTrigger data contained in packet
payload
Signature structure
AtomicTrigger contained in a single packet
CompositeTrigger contained in a series of
multiple packets
www.cisco.com
CSIDS 2.17-5
Signature implementations are context- or content-based. Context-based

signatures are triggered by the data contained in packet headers. Content-based
signatures are triggered by data contained in packet payloads. The following table
gives some examples of CIDS signature implementations:
Signature Name
Signature Implementation
ICMP Echo Request
Content
ICMP Net Sweep w/ Echo
Context
WWW IIS Unicode
Content
TFN Client Request
Content
Signature structures are atomic or composite. Atomic signatures are triggered by

single packets. Composite signatures are triggered by a series of multiple packets.
The following table gives some examples of CIDS signature structures:
Signature Name
7-4
Signature Structure
ICMP Echo Request
Atomic
ICMP Net Sweep with Echo
Composite
WWW IIS Unicode
Atomic
TFN Client Request
Composite
Signature Classes
ReconnaissanceTriggers on an activity
known to be, or that could lead to,
unauthorized discovery of systems, services,
or vulnerabilities.
AccessTriggers on an activity known to be,
or that could lead to, unauthorized data
retrieval, system access, or privileged
escalation.
www.cisco.com
CSIDS 2.17-6
Reconnaissance class signatures are signatures that are triggered by a network

activity that is known to be, or that could lead to, unauthorized discovery of
systems, services, or vulnerabilities. Examples of reconnaissance activities are as
follows:
Ping sweep
Port scan
DNS queries
Access class signatures are signatures that are triggered by a network activity that
is known to be, or that could lead to, unauthorized data retrieval, system access, or
privileged escalation. Examples of Access activities are as follows:
UNIX Tooltalk Database server attack
Internet Information Services (IIS) Unicode attack
Back Orifice or NetBus
7-5
Signature Classes (cont.)
DoSTriggers on activity known to be, or

that could lead to, the disablement of a
network, system, or service.
InformationTriggers on normal network
activity that in itself is not considered to be
malicious, but can be used to determine the
validity of an attack or for forensic purposes.
www.cisco.com
CSIDS 2.17-7
Denial of service (DoS) class signatures are signatures that are triggered by
network activity that is known to be, or that could lead to, the disablement or
disruption of a network, system, or service. Examples of DoS activities are as
follows:
Ping of Death
Tribe Flood Network (TFN) attacks
Trinoo attacks
Information class signatures are signatures that are triggered by normal network
activity that in itself is not considered to be malicious, but can be used to
determine the validity of an attack or for forensics purposes. Examples of
information activities are as follows:
7-6
ICMP echo requests
TCP connection requests
UDP connections
Signature Types
GeneralSignatures that detect IP, ICMP,
TCP, and UDP intrusion attempts.
ConnectionSignatures that detect TCP
connection requests and traffic to UDP ports.
StringSignatures that detect matches to
defined string patterns.
ACLSignatures that violate defined ACL
policies.
www.cisco.com
CSIDS 2.17-8
CIDS signature types are as follows:
GeneralDetect IP, ICMP, TCP, and UDP intrusion attempts. CIDS

signature series included are 1000, 2000, 3000, 4000, 5000, and 6000. The
3000 and 4000 connection request signatures are connection types. Some
examples of general signatures are IP fragments overlap, ICMP echo
requests, High Port Sweep, UDP bomb, DNS Zone Transfer Request, WWW
IIS Unicode Attack, and TFN Client request.
ConnectionDetect TCP connection requests or traffic to UDP ports. CIDS

signature ID is either a 3000 or 4000 associated with a sub-signature ID
specifying the port. For instance, a connection request to TCP port 21 would
alarm with signature 3000 and sub-signature ID 21.
StringDetect matches to defined string patterns. CIDS signature series is

8000. For example, you could define the string hack. IP Traffic with this
string would trigger an alarm.
ACLDetect violations that occur against defined Cisco IOS Access Control
Lists (ACLs). CIDS signature series is 10000.
7-7
Signature Series and

Categories
1000 SeriesIP
2000 SeriesICMP
3000 SeriesTCP (including Legacy Web)
4000 SeriesUDP
5000 SeriesHTTP (Web)
6000 SeriesCross Protocol
8000 SeriesString
10000 SeriesACL policy violation
www.cisco.com
CSIDS 2.17-9
CIDS organizes its signatures in series. Each series is a collection of related

signatures. There signature series are: 1000, 2000, 3000, 4000, 5000, 6000, 8000,
and 10000. The following is a list of the series and the signatures found within
each:
7-8
1000 SeriesIP signatures
IP Options
IP Fragmentation
Bad IP Packets
2000 SeriesICMP signatures
ICMP Traffic Records
Ping Sweeps
ICMP Attacks
3000 SeriesTCP signatures
TCP Traffic Records
TCP Port Scans
TCP Host Sweeps
Mail Attacks
FTP Attacks
Legacy CIDS Web Attacks (Signature IDs 3200-3233)
NetBIOS Attacks
SYN Flood and TCP Hijack Attacks
TCP Applications
4000 SeriesUDP signatures
UDP Traffic Records
UDP Port Scan
UDP Attacks
UDP Applications
5000 SeriesWeb (HTTP) signatures
6000 SeriesCross-Protocol signatures
DNS Attacks
RPC services Attacks
Authentication Failures
Loki Attacks
Distributed DoS Attacks
8000 SeriesString Match signatures
Custom String Matches
TCP Applications
10000 SeriesACL Policy Violation signatures
Web Attacks
Defined IOS ACL violations
7-9
Signature Severities
Description
Severity 1
Low
Severity 3
Medium
Severity 5
High
Signatures that detect network activity

considered to be benign but are
detected for informational purposes.
Signatures that detect abnormal
network activity, which could be
perceived as malicious.
Signatures that detect attacks often
used to gain access or cause a DoS.
Attack
Probability
Immediate
Threat
Very Low
No
Medium
Low
Very High
High
www.cisco.com
CSIDS 2.17-10
Severity levels are assigned to each CIDS signature. The severity of the signature
represents the probability that the signature is an attack and the immediate threat
to the network. The default severity levels are assigned by Cisco network security
engineers. The signature severity level settings are configurable to allow for
tuning to your network environment. There are three severity levels:
Note
7-10
Severity 1: LowThese signatures detect network activity considered benign

but for informational purposes. The following are examples of low severity
signatures:
Unknown IP protocol
FTP SITE command attempted
Severity 3: MediumThese are signatures that detect abnormal network

activity and could be perceived as malicious. Some of these signatures
include legacy vulnerabilities that are not often seen on todays networks. The
following are examples of medium severity signatures:
Net Sweep-echo
TCP SYN port sweep
Severity 5: HighThese signatures detect attacks used to gain access or

cause a denial of service (DoS). The following are examples of high severity
signatures:
BackOrifice BO2K TCP Non Stealth 1
WWW IIS Unicode
sadmind buffer overflow

CIDS has a severity 0, which signifies the alarm is disabled.
1000 SeriesIP Signatures

This section describes the different signatures that belong in the 1000 series.
1000 SeriesIP Signatures
Application
IP Options
IP Fragmentation
TCP
UDP
IP
Bad IP packets
Data Link
Physical
www.cisco.com
CSIDS 2.17-12
7-11
IP Options
Ver Len
H
E
A
D
E
R
IP Header
20 bytes
IP Options
Identification
Adds up to 40
additional bytes
TTL
Proto
Length
Flg Frag Offset
Checksum
Source IP
Destination IP
Options .. .. ..
Options
Only 8 valid options
Serv
P
A
Y
www.cisco.com
Data . . .
CSIDS 2.17-13
The IP datagram header is normally 20 bytes long. The IP protocol allows for up
to 40 additional bytes of optional fields. Only 8 options are considered valid in IP
version 4.
7-12
IP Options (cont.)
0
1 2
CP Class
3 4 5 6 7
0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7
1 2
3 4 5 6 7
Option #
Length (if used)
Parameters...
0 0
0 0 0 0 0
Copy:
Copy:
0Do
0Do not
not include
include options
options in
in packet
packet fragments
fragments
1Include
1Include options
options in
in packet
packet fragments
fragments
Class:
Class:
0Network
0Network Control
Control
2Debugging
2Debugging
Option:
Option: one
one of
of eight
eight valid
valid options
options
Length:
Length: number
number of
of bytes
bytes in
in option
option (if
(if used
used by
by option)
option)
Parameters:
Parameters: parameters
parameters passed
passed by
by the
the option
option
Last
Last option
option is
is always
always option
option 00
www.cisco.com
CSIDS 2.17-14
The following are IP options:
COPY (Bit 0)Specifies to routers if the option information should be

included in fragment headers.
CLASS (Bits 1-2)Specifies 1 of 2 valid option classes: Network Control,

Debugging
OPTION (Bits 3-7)Specifies one of eight valid IP options. Option zero

indicates the end of the list.
Option 0End of Options: self-explanatory.
Option 1No Operation: self-explanatory.
Option 2Security: this option is specific to the U.S. government. May carry
the following s-security clearance, c-compartment, h-handling codes, and tccuser group.
Option 3Loose Source Route: this is a list of router addresses to be visited

in transit, though other routers may be visited as well.
Option 4Timestamp: self-explanatory.
Option 7Record Route: applications may request the route a packet takes
be recorded.
Option 8Stream ID: self-explanatory.
Option 9Strict Source Route: this is a list of router addresses that must be
followed by the packet.
LENGTH (Bits 8-15)Specifies the total number of bytes in the option, if

used by the option.
PARAMETER (Bytes 3-40)The parameters passed by the specific option.
7-13
IP Option Signatures
1000Bad option list
Invalid option
Option #
0
1
1001Record packet
route
Option=7
1002Timestamp
Option=4
Option Name
End of Options
No Operation
2
3
Security
Loose Source Rte
4
7
Timestamp
Record Route
8
9
Stream ID
Strict Source Rte
1003Provide s, c, h, tcc
Option=2
www.cisco.com
CSIDS 2.17-15
The following are IP Option signatures:
7-14
1000Bad option list (severity 1, information): This signature is triggered by

receipt of an IP datagram where the list of IP options in the IP datagram
header is incomplete or malformed. No known exploits purposely incorporate
this option. This does not preclude the possibility that exploits do exist
outside of the realm of Cisco Systems knowledge domain or that poorly
written hacker code may produce malformed datagrams.
1001Record packet route (severity 1, information/reconnaissance): This

signature is triggered by receipt of an IP datagram where the IP option list for
the datagram includes option 7 (Record Packet Route). This alarm may
indicate a reconnaissance attack is in progress against your network.
1002Timestamp (severity 1, information): This signature is triggered by

receipt of an IP datagram where the IP option list for the datagram includes
option 4 (Timestamp). This alarm indicates that a reconnaissance attack may
be in progress against your network.
1003Provide s, c, h, and tcc (severity 1, information): This signature is

triggered by receipt of an IP datagram where the IP option list for the
datagram includes option 2 (Security options). No known exploit exists. This
does not preclude the possibility that exploits do exist outside of the realm of
Cisco Systems knowledge domain.
IP Option Signatures
(cont.)
1004Loose source route
Option=3
Option #
0
1
1005SATNET id
Option=8
1006Strict source route

Option=9
www.cisco.com
Option Name
End of Options
No Operation
2
3
Security
Loose Source Rte
4
7
Timestamp
Record Route
8
9
Stream ID
Strict Source Rte
CSIDS 2.17-16
1004Loose source route (severity 5, access): This signature is triggered by

option 3 (Loose Source Route). This option may be misused to defeat
authentication mechanisms that rely on IP addresses as their basis for trust
relationships.
1005SATNET id (severity 1, information): This signature is triggered by

option 8 (SATNET stream identifier). This signature is included for
completeness. No known exploit exists. This does not preclude the possibility
that exploits do exist outside of the realm of Cisco Systems knowledge
domain.
1006Strict source route (severity 5, access): This signature is triggered by

receipt of an IP datagram in which the IP option list for the datagram includes
option 2 (Strict Source Routing). This option may be misused to defeat
authentication mechanisms that rely on IP addresses as their basis for trust
relationships. The limited number of routes that may be stored in the options
field minimize the usefulness of this option as a mode of attack across large
Internets.
7-15
IP Fragmentation Signatures
1100IP Fragment Attack
Offset value too small
Indicates unusually small
packet
May bypass some packet
filter devices
Ver Len
Serv
Identification
TTL
1103IP Fragments
Overlap
Proto
Length
Flg Frag
Frag Offset
Offset
Checksum
Source IP
Destination IP
Options . . .
Data . . .
Offset value indicates

overlap
Teardrop attack
www.cisco.com
CSIDS 2.17-17
The following are IP Fragmentation signatures:
7-16
1100IP Fragment Attack (severity 3, access): This signature is triggered

when any IP datagram is received with a small offset indicated in the offset
field. This indicates that the first fragment was unusually small, and is most
likely an attempt to defeat packet filter security policies.
1103IP Fragments Overlap (severity 5, DoS): Some implementations of the

TCP/IP IP fragmentation re-assembly code do not properly handle
overlapping IP fragments. Teardrop is a widely available attack tool that
exploits this vulnerability.
Bad IP Packet Signatures

Ver Len
1101Unknown IP
Protocol
Identification
TTL
Proto=invalid or undefined
Length
Flg Frag Offset
Proto
Proto
Checksum
Source IP
Source
IP
1102=Impossible IP
Packet
Destination IP
Destination
IP
Options
Same source and

destination
Land attack
Serv
Data
www.cisco.com
CSIDS 2.17-18
The following are Bad IP Packet signatures:
1101Unknown IP Protocol (severity 1, information): This signature is

triggered when an IP datagram is received with the protocol field set to 101 or
greater. These protocol types are undefined or reserved and should not be
used. Use of undefined or reserved protocol types may indicate establishment
of a proprietary communication channel. No known exploits implement this
concept. This does not preclude the possibility that exploits do exist outside
of the realm of Cisco Systems knowledge domain.
1102Impossible IP Packet (severity 5, DoS): This is triggered when an IP

packet arrives with source equal to destination address. This signature will
catch the so-called Land Attack.
7-17
2000 SeriesICMP Signatures

2000 SeriesICMP Signatures
Application
ICMP Traffic Records

Ping Sweeps
ICMP Attacks
TCP
UDP
IP
Data Link
Physical
7-18
www.cisco.com
CSIDS 2.17-20
ICMP Query Message

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
H
E
A
D
E
R
Type
Code
Identifier
Checksum
Sequence #
Data . . .
Type:
Type:
0Echo
0Echo Reply
Reply
8Echo
8Echo Request
Request
13Timestamp
13Timestamp Request
Request
14Timestamp
14Timestamp Reply
Reply
15Information
15Information Request
Request
16Information
16Information Reply
Reply
17Address
17Address Mask
Mask Request
Request
18Address
18Address Mask
Mask Reply
Reply
Code:
Code: codes
codes associated
associated with
with each
each ICMP
ICMP type
Checksum:
Checksum: checksum
checksum value
value of header
header fields
fields (exc. checksum)
www.cisco.com
CSIDS 2.17-21
The following are ICMP Query messages:
Type (Bits 0-7): Specifies the type of message.
Type 0Echo Reply
Type 8Echo Request
Type 13Timestamp Request
Type 14Timestamp Reply
Type 15Information Request
Type 16Information Reply
Type 17Address Mask Request
Type 18Address Mask Reply
Code (bits 8-15): Specifies codes associated with each ICMP type.
Checksum (bits 16-31): Specifies the checksum value of the header fields,
excluding the checksum field.
7-19
ICMP Query Message

Signatures
2000Echo Reply
Length
I Ver Len Serv
P
Identification Flg Frag Offset
H
Proto
Checksum
ICMP
E TTL
A
Source IP
D
E
R
Destination IP
Type=0
2004Echo Request
Type=8
2007Timestamp
Request
Type
I Type
C
M
P
Type=13
Code
Checksum
2008Timestamp Reply
Type=14
www.cisco.com
CSIDS 2.17-22
The following are ICMP Query Message signatures:
7-20
2000Echo Reply (severity 1, information): This signature is triggered when

an IP datagram is received with the protocol field of the IP header set to 1
(ICMP) and the type field in the ICMP header set to 0 (Echo Reply). ICMP
Echo Replies have been used to bypass packet filter security policies as they
are rarely filtered in either incoming or outgoing traffic. May be used to
establish a communication channel or to perform DoS attacks.
2004Echo Request (severity 1, information): This signature is triggered

when an IP datagram is received with the protocol field of the IP header set
to 1 (ICMP) and the type field in the ICMP header set to 8 (Echo Request).
ICMP Echo Requests are commonly used to perform reconnaissance sweeps
of networks. These sweeps often are a prelude to attack. Additionally they
may be used to perform DoS attacks.
2007Timestamp Request (severity 1, reconnaissance/information): This

signature is triggered when an IP datagram is received with the protocol
field of the IP header set to 1 (ICMP) and the type field in the ICMP header
set to 13 (Timestamp Request). ICMP Timestamp Requests could be used to
perform reconnaissance sweeps of networks. These sweeps often are a
prelude to attack. Additionally they may be used to perform DoS attacks. No
known exploits incorporate this option. This does not preclude the possibility
domain.
2008Timestamp Reply (severity 1, information): This signature is triggered

to 1 (ICMP) and the type field in the ICMP header set to 14 (Timestamp
Reply). ICMP Timestamp Replies could be used to perform DoS attacks. No
domain.
ICMP Query Message

Signatures (cont.)
2009Information Request
Type=15
2010Information Reply
Type=16
2011Address Mask
Request
Type=17
2012Address Mask Reply
Length
I Ver Len Serv
P
H
Proto
Checksum
ICMP
E TTL
A
Source IP
D
E
R
Destination IP
Type
I Type
C
M
P
Code
Checksum
Type=18
www.cisco.com
CSIDS 2.17-23
2009Information Request (severity 1, information): This signature is

triggered when an IP datagram is received with the protocol field of the IP
header set to 1 (ICMP) and the type field in the ICMP header set to 15
(Information Request). This signature is included for completeness. No
known exploit exists. This does not preclude the possibility that exploits do
exist outside of the realm of Cisco Systems knowledge domain.
2010Information Reply (severity 1, information): This signature is

(ICMP Information Reply). This signature is included for completeness. No
known exploit exists. This does not preclude the possibility that exploits do
2011Address Mask Request (severity 1, reconnaissance/information): This

signature is triggered when an IP datagram is received with the protocol
field of the IP header set to 1 (ICMP) and the type field in the ICMP header
set to 17 (Address Mask Request). ICMP Address Mask Requests could be
used to perform reconnaissance sweeps of networks. These sweeps often are a
prelude to attack. Additionally they may be used to perform DoS attacks. No
domain.
2012Address Mask Reply (severity 1, information): This signature is

(Address Mask Reply). ICMP Timestamp Replies could be used to perform
DoS attacks. No known exploits incorporate this option. This does not
preclude the possibility that exploits do exist outside of the realm of Cisco
Systems knowledge domain.
7-21
ICMP Error Message

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
H
E
A
D
E
R
Type
Code
Checksum
Unused
IP Header
+
8 bytes of Original Datagram Data
Type:
Type:
3Destination
3Destination Unreachable
Unreachable
4Source
4Source Quench
Quench
5Redirect
5Redirect
11Time
11Time Exceeded
Exceeded
12Parameter
12Parameter Problem
Problem
Code:
Code: codes
codes associated
associated with
with each
each ICMP
ICMP type
type
Checksum:
Checksum: checksum
checksum value
value of
of header
header fields
fields (exc.
(exc. checksum)
checksum)
www.cisco.com
CSIDS 2.17-24
The following are ICMP Error messages:
7-22
Type (Bits 0-7): Specifies the type of message.
Type 3Destination Unreachable
Type 4Source Quench
Type 5Redirect
Type 11Time Exceeded
Type 12Parameter Problem
Code (bits 8-15): Specifies codes associated with each ICMP type.
Checksum (bits 16-31): Specifies the checksum value of the header fields,
excluding the checksum field.
ICMP Error Message

Signatures
2001Unreachable
Length
I Ver Len Serv
P
H
Proto
Checksum
ICMP
E TTL
A
Source IP
D
E
R
Destination IP
Type=3
2002Source Quench
Type=4
2003Redirect
Type=5
Type
I Type
C
M
P
2005Time Exceeded
Type=11
Code
Checksum
2006Parameter Problem
Type=12
www.cisco.com
CSIDS 2.17-25
The following are ICMP Error Message signatures:
2001Unreachable (severity 1, information): This signature is triggered

to 1 (ICMP) and the type field in the ICMP header set to 3 (Host
Unreachable). ICMP Host Unreachable datagrams may be used to bypass
packet filter security policies as they are rarely filtered in either incoming or
outgoing traffic. May be used to perform DoS attacks.
2002Source Quench (severity 1, DoS/information): This signature is

(Source Quench). ICMP Source Quench datagrams may be used to bypass
packet filter security policies as they are rarely filtered in either incoming or
outgoing traffic. May be used to perform DoS attacks. No known exploits
incorporate this option. This does not preclude the possibility that exploits do
2003Redirect (severity 1, information): This signature is triggered when a

IP datagram is received with the protocol field of the IP header set to 1
(ICMP) and the type field in the ICMP header set to 5 (Redirect). ICMP
Redirects may be used to facilitate system access attempts. No known
exploits incorporate this option. This does not preclude the possibility that
exploits do exist outside of the realm of Cisco Systems knowledge domain.
2005Time Exceeded (severity 1, DoS/information): This signature is

header set to 1 (ICMP) and the type field in the ICMP header set to
11(Time Exceeded for a Datagram). ICMP Time Exceeded datagrams may be
used to bypass packet filter security policies as they are rarely filtered in
either incoming or outgoing traffic. May be used to perform DoS attacks. No
7-23

domain.
7-24
2006Parameter Problem (severity 1, information): This signature is

(Parameter Problem on Datagram). ICMP Parameter Problem datagrams may
be used to bypass packet filter security policies as they are rarely filtered in
either incoming or outgoing traffic. May be used to perform DoS attacks. No
domain.
Ping Sweep Signatures

2100ICMP network sweep
with Echo
Length
I Ver Len Serv
P
H
Proto
Checksum
ICMP
E TTL
A
Source IP
D
E
R
Destination IP
Type=8
One host to multiple hosts

with Timestamp
Type=13
Type
I Type
C
M
P

with Address Mask
Code
Checksum
Type=17
www.cisco.com
CSIDS 2.17-26
The following are Ping Sweep signatures:
2100ICMP network sweep with Echo (severity 5, reconnaissance): This

signature is triggered when IP datagrams are received directed at multiple
hosts on the network with the protocol field of the IP header set to 1
(ICMP) and the type field in the ICMP header set to 8 (Echo Request). This
is indicative that a reconnaissance sweep of your network may be in progress.
This may be the prelude to a more serious attack.
2101ICMP network sweep with Timestamp (severity 5, reconnaissance):

This signature is triggered when IP datagrams are received directed at
multiple hosts on the network with the protocol field of the IP header set to
1 (ICMP) and the type field in the ICMP header set to 13 (Timestamp
Request). This is indicative that a reconnaissance sweep of your network may
be in progress. This may be the prelude to a more serious attack.
2102ICMP network sweep with Address Mask (severity 5,

reconnaissance): This signature is triggered when IP datagrams are received
directed at multiple hosts on the network with the protocol field of the IP
(Address Mask Request). This is indicative that a reconnaissance sweep of
your network may be in progress. This may be the prelude to a more serious
attack.
7-25
ICMP Attack Signatures

2150Fragmented ICMP
packet
Flag=more fragments or
Offset /= 0
2151Large ICMP packet

Length > 1024
2152ICMP Flood
Many ICMP packets
Length
Length
I Ver Len Serv
P
H
Proto
Checksum
ICMP
E TTL
A
Source IP
D
E
R
Destination IP
I
C
M
P
Type
Code
Checksum
To single host
www.cisco.com
CSIDS 2.17-27
The following are ICMP Attack signatures:
7-26
2150Fragmented ICMP packet (severity 5, access/DoS): This signature is

header set to 1 (ICMP) and either the more fragments flag is set to 1 (ICMP)
or there is an offset indicated in the offset field. The Boolean equation that
describes this as ICMP AND (MFFLAG OR OFFSET). Fragmented ICMP
traffic may indicate a DoS attempt.
2151Large ICMP packet (severity 5, DoS): This signature is triggered

when an IP datagram is received with the protocol field of the IP header set to
1(ICMP) and the IP length set to a value greater than 1024. A large ICMP
packet may indicate a DoS attack.
2152ICMP Flood (severity 5, DoS): This signature is triggered when

multiple IP datagrams are received directed at a single host on the network
with the protocol field of the IP header set to 1 (ICMP). This indicates that
a DoS attack may be in progress against your network.
ICMP Attack Signatures (cont.)
2153ICMP Smurf attack

Type=0 (echo reply)
Many packets
To single host
2154ICMP Ping Of Death

Flag=last fragment
Offset*8 + Length > 65535
Length
I Ver Len Serv
P
Identification Flg Frag
Frag Offset
Offset
H
Proto
Checksum
Proto
E TTL
A
Source IP
D
E
R
Destination IP
Type
I Type
C
M
P
www.cisco.com
Code
Checksum
CSIDS 2.17-28
The following are ICMP Attack signatures:
2153ICMP Smurf attack (severity 5, DoS): This signature is triggered

when a large number of ICMP Echo Replies is targeted at a machine. They
can be from one or many sources. This will catch the attack known as Smurf,
described in the related vulnerability page. Since this attack can come from
many sources, automatic shunning of individual hosts is not very effective. If
only one network is being used to broadcast the replies, the network can be
shunned.
2154ICMP Ping Of Death (severity 5, DoS): This signature is triggered

when an IP datagram is received with the protocol field of the IP header set to
1(ICMP), the Last Fragment bit is set, and (IP offset * 8 ) + ( IP data length)
> 65535 that is to say, the IP offset (which represents the starting position of
this fragment in the original packet, and which is in 8 byte units) plus the rest
of the packet is greater than the maximum size for an IP packet. This
indicates a DoS attack.
7-27
3000 SeriesTCP Signatures

3000 SeriesTCP Signatures

TCP Traffic Records
TCP Port Scans
Application
TCP Host Sweeps

Mail Attacks
FTP Attacks
TCP
IP
Legacy Web Attacks

NetBIOS Attacks
Data Link
SYN Flood & TCP Hijack

Attacks
TCP Applications
7-28
UDP
www.cisco.com
Physical
CSIDS 2.17-30
TCP Traffic Records

3000TCP Traffic Records
Triggers on all TCP connections
Sub-signature ID is port number
51 subsignatures50 predefined TCP ports + port 0
(catchall)
User-defined ports may be added
Mostly used for tracking or forensics
Subsignatures 512-exec, 513-rlogin, and 514-rsh are
severity 3
All other sub-signatures are severity 1
www.cisco.com
CSIDS 2.17-31
The following are TCP Traffic Records:
3000/0TCP default event levels (severity 1, information)
3000/1Connection requesttcpmux (severity 1, information)
3000/7Connection requestecho (severity 1, information)
3000/9Connection requestdiscard (severity 1, information)
3000/11Connection requestsystat (severity 1, information)
3000/13Connection requestdaytime (severity 1, information)
3000/15Connection requestnetstat (severity 1, information)
3000/19Connection requestChargen (severity 1, information)
3000/20Connection requestftp-data (severity 1, information)
3000/21Connection requestftp (severity 1, information)
3000/23Connection requesttelnet (severity 1, information)
3000/25Connection requestsmtp (severity 1, information)
3000/37Connection requesttime (severity 1, information)
3000/43Connection requestwhois (severity 1, information)
3000/53Connection requestdns (severity 1, information)
3000/70Connection requestgopher (severity 1, information)
3000/79Connection requestfinger (severity 1, information)
3000/80Connection requestwww (severity 1, information)
3000/87Connection requestlink (severity 1, information)
3000/88Connection requestkerberos-v5 (severity 1, information)
7-29
7-30
3000/95Connection requestsupdup (severity 1, information)
3000/101Connection requesthostnames (severity 1, information)
3000/102Connection requestiso-tsap (severity 1, information)
3000/103Connection requestx400 (severity 1, information)
3000/104Connection requestx400-snd (severity 1, information)
3000/105Connection requestCsnet-ns (severity 1, information)
3000/109Connection requestpop-2 (severity 1, information)
3000/110Connection requestpop3 (severity 1, information)
3000/111Connection requestsunrpc (severity 1, information)
3000/117Connection requestuucppath (severity 1, information)
3000/119Connection requestnntp (severity 1, information)
3000/123Connection requestntp (severity 1, information)
3000/137Connection requestnetbios (severity 1, information)
3000/143Connection requestimap2 (severity 1, information)
3000/144Connection requestNeWS (severity 1, information)
3000/177Connection requestxdmcp (severity 1, information)
3000/178Connection requestnextstep (severity 1, information)
3000/179Connection requestbgp (severity 1, information)
3000/194Connection requestirc (severity 1, information)
3000/220Connection requestimap3 (severity 1, information)
3000/372Connection requestulistserv (severity 1, information)
3000/512Connection requestexec (severity 3, access)
3000/513Connection requestlogin (severity 3, access)
3000/514Connection requestshell (severity 3, access)
3000/515Connection requestprinter (severity 1, information)
3000/530Connection requestCourier (severity 1, information)
3000/540Connection requestuucp (severity 1, information)
3000/600Connection requestpcserver (severity 1, information)
3000/750Connection requestkerberos-v4 (severity 1, information)
TCP Port Scans

A TCP Port Scan occurs
when one host searches
for multiple TCP
services on a single
host.
Common scans
Ver Len
I
P
Serv
Identification
TTL
TCP
Length
Flg Frag Offset
Checksum
Source IP
Destination IP
Source Port
Dest Port
Source Sequence Number
T
C Acknowledge Sequence Num
P Len Res Flags
Window
use normal TCP-SYN
Stealth scans
Checksum
Urgent Pointer
use FIN, SYN-FIN, null, or

PUSH
and/or fragmented packets
www.cisco.com
CSIDS 2.17-32
TCP Port Scans are detected when a single host is searching for multiple running
services on another single hostthe victim. They are common scans that use
normal TCP-SYN (connection request) to determine that a service is running.
They are stealth scans use FIN; SYN-FIN; null; or PUSH flags, and fragmented
packets, or both to determine that a service is running. The following is a TCP
Flags refresher:
SYNSynchronize sequence numbers to initiate a connection. Each time a

new connection is established the SYN flag is turned on.
FINWhen set, this flag implies that the sender has finished sending data.
ACKWhen the ACK field is on, the acknowledgment number in the

corresponding field is valid. The acknowledgment number contains the next
sequence number that the sender of the acknowledgment expects to receive.
RSTThis flag is used to reset the TCP connection.
URGThe urgent pointer is valid when this flag is set. This pointer is a
positive offset that must be added to the sequence number field of the
segment to yield the sequence number of the last byte of urgent data.
PSHIndicates that the receiver should pass this data to the application as
soon as possible.
7-31
TCP Port Scan Signatures

3005FIN port sweep
FINs to ports < 1024
3001Port Sweep
SYNs to ports < 1024
Triggers when type of sweep
cant be determine
3002SYN Port Sweep
3006Frag FIN port sweep

Fragmented FINs to ports
< 1024
3010High port sweep
SYNs to any ports
SYNs to ports > 1023
3003Frag SYN Port Sweep

Fragmented SYNs to many
ports
Triggers when type of sweep

cant be determined
3011FIN High port sweep

FINs to ports > 1023
www.cisco.com
CSIDS 2.17-33
The following are TCP Port Scan signatures:
7-32
3001Port Sweep (severity 5, reconnaissance): This signature is triggered

when a series of TCP connections to a number of different privileged ports
(having port number less than 1024) on a specific host have been initiated.
This is indicative that a reconnaissance sweep of your network may be in
progress. This may be the prelude to a more serious attack. This is a catchall
signature, which will fire if the specific type of TCP Port Sweep cannot be
determined.
3002SYN Port Sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP SYN packets have been sent to a number of
different destination ports on a specific host. This is indicative that a
reconnaissance sweep of your network may be in progress. This may be the
prelude to a more serious attack.
3003Frag SYN Port Sweep (severity 5, reconnaissance): This signature is

triggered when a series of fragmented TCP SYN packets are sent to a number
of different destination ports on a specific host. This is indicative that a
reconnaissance sweep of your network may be in progress. The fragmentation
indicates an attempt to conceal the sweep. This may be the prelude to a more
serious attack.
3005FIN port sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP FIN packets have been sent to a number of
different privileged ports (having port number less than 1024) ports on a
specific host. This is indicative that a reconnaissance sweep of your network
may be in progress. The use of FIN packets indicates an attempt to conceal
the sweep. This may be the prelude to a more serious attack.
3006Frag FIN port sweep (severity 5, reconnaissance): This signature is

triggered when a series of fragmented TCP FIN packets have been sent to a
number of different privileged ports (having port number less than 1024)
destination ports on a specific host. This is indicative that a reconnaissance

sweep of your network may be in progress. The use of fragmentation and of
FIN packets indicates an attempt to conceal the sweep. This may be the
3010High port sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP connections to a number of different highnumbered ports (having port number greater than 1023) on a specific host
have been initiated. This is indicative that a reconnaissance sweep of your
network may be in progress. This may be the prelude to a more serious attack.
This is a catchall signature that will fire if the specific type of TCP Port
Sweep cannot be determined.
3011FIN High port sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP FIN packets have been sent to a number of
different destination high-numbered ports (having port number greater than
1023) on a specific host. This is indicative that a reconnaissance sweep of
your network may be in progress. The use of FIN packets indicates an attempt
to conceal the sweep. This may be the prelude to a more serious attack.
7-33
TCP Port Scan Signatures

(cont.)
3012Frag High FIN port
sweep
Fragmented FINs to ports >
1023
3015Null port sweep

TCPs without SYN, FIN, ACK,
or RST to any ports
3016Frag Null port sweep
3020SYN FIN port sweep
SYN-FINs to any port
3021Frag SYN/FIN port

sweep
Fragmented SYN/FINs to any
ports
3045Queso sweep
FIN, SYN/FIN, and a PUSH
Fragmented TCPs without

SYN, FIN, ACK, or RST to any
ports
7-34
www.cisco.com
CSIDS 2.17-34
3012Frag High FIN port sweep (severity 5, reconnaissance): This signature

is triggered when a series of fragmented TCP FIN packets have been sent to a
number of different destination high-numbered ports (having port number
greater than 1023) on a specific host. This is indicative that a reconnaissance
sweep of your network may be in progress. The use of fragmentation and of
FIN packets indicates an attempt to conceal the sweep. This may be the
3015Null port sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP packets with none of the SYN, FIN, ACK, or
RST flags set have been sent to a number of different destination ports on a
may be in progress. The use of this type of packet indicates an attempt to
conceal the sweep. This may be the prelude to a more serious attack.
3016Frag Null port sweep (severity 5, reconnaissance): This signature is

triggered when a series of fragmented TCP packets with none of the SYN,
FIN, ACK, or RST flags set have been sent to a number of different
destination ports on a specific host. This is indicative that a reconnaissance
sweep of your network may be in progress. The use of this type of packet and
of fragmentation indicates an attempt to conceal the sweep. This may be the
3020SYN FIN port sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP packets with both the SYN and FIN flags set
have been sent to a number of different destination ports on a specific host.
This is indicative that a reconnaissance sweep of your network may be in
progress. The use of both the SYN and FIN flag is abnormal, and could
indicate an attempt to conceal the sweep. This may be the prelude to a more
serious attack.
3021Frag SYN/FIN port sweep (severity 5, reconnaissance): This signature

is triggered when a series of fragmented TCP packets with both the SYN and
FIN flags set have been sent to a number of different destination ports on a
may be in progress. The use of both the SYN and FIN flag is abnormal, as is
the use of fragmentation, and could indicate an attempt to conceal the sweep.
This may be the prelude to a more serious attack.
3045Queso sweep (severity 5, reconnaissance): This signature is triggered

after having detected a FIN, SYN-FIN, and a PUSH sent from a specific host
bound for a specific host.
7-35
TCP Host Sweeps

A TCP Host Sweep
occurs when one host
searches for a single
TCP service on multiple
hosts.
Common scans
use normal TCP-SYN
Ver Len
I
P
Serv
Identification
TTL
TCP
Length
Flg Frag Offset
Checksum
Source IP
Destination IP
Source Port
Dest Port
T
P Len Res Flags
Window
Checksum
Stealth scans
Urgent Pointer
use FIN, SYN-FIN, and null

and/or fragmented packets
www.cisco.com
CSIDS 2.17-35
TCP Host Sweeps are types of scans that are detected when a single host is
searching for a single running service on multiple hoststhe victims. Common
scans use normal TCP-SYN (connection request) to determine that a service is
running. Stealth scans use FIN, SYN-FIN, null, or PUSH flags and fragmented
packets to determine that a service is running. The following are different TCP
Flags:
7-36
SYNSynchronize sequence numbers to initiate a connection. Each time a

new connection is established the SYN flag is turned on.
FINWhen set, this flag implies that the sender has finished sending data.
ACKWhen the ACK field is on, the acknowledgment number in the

corresponding field is valid. The acknowledgment number contains the next
sequence number that the sender of the acknowledgment expects to receive.
RSTThis flag is used to reset the TCP connection.
URGThe urgent pointer is valid when this flag is set. This pointer is a
positive offset that must be added to the sequence number field of the
segment to yield the sequence number of the last byte of urgent data.
PSHIndicates that the receiver should pass this data to the application as
soon as possible.
TCP Host Sweep Signatures

3030SYN host sweep
3034NULL host sweep
SYNs to same port
TCPs without SYN, FIN, ACK, or RST

to same port
3031Frag SYN host sweep

Fragmented SYNs to same port
3035Frag NULL host sweep

Fragmented packets without SYN,
FIN, ACK, or RST to same port
3032FIN host sweep

FINs to same port
3036SYN/FIN host sweep
3033Frag FIN host sweep

Fragmented FINs to same port
SYN-FINs to same port
3037Frag SYN/FIN host sweep

SYN-FINs to same port
www.cisco.com
CSIDS 2.17-36
The following are TCP Host Sweeps Signatures:
3030SYN host sweep (severity 1, reconnaissance): This signature is

triggered when a series of TCP SYN packets have been sent to the same
destination port on a number of different hosts. This could, for example, be a
sweep of many hosts to find out which ones can receive mail or telnet
sessions. This is indicative that a reconnaissance sweep of your network may
3031Frag SYN host sweep (severity 5, reconnaissance): This signature is

triggered when a series of fragmented TCP SYN packets have been sent to
the same destination port on a number of different hosts. This could, for
example, be a sweep of many hosts to find out which ones can receive mail or
telnet sessions. This is indicative that a reconnaissance sweep of your
network may be in progress. This may be the prelude to a more serious attack.
The use of fragmentation is abnormal and could indicate an attempt to
conceal the sweep.
3032FIN host sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP FIN packets have been sent to the same
3033Frag FIN host sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP FIN packets have been sent to the same
be in progress. This may be the prelude to a more serious attack. The use of
fragmentation is abnormal and could indicate an attempt to conceal the
sweep.
7-37
7-38
3034NULL host sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP packets with none of the SYN, FIN, ACK, or
RST flags set have been sent to the same destination port on a number of
different hosts. This could, for example, be a sweep of many hosts to find out
which ones can receive mail or telnet sessions. This is indicative that a
reconnaissance sweep of your network may be in progress. This may be the
prelude to a more serious attack. The use of this packet is abnormal, and
could indicate an attempt to conceal the sweep.
3035Frag NULL host sweep (severity 5, reconnaissance): This signature is

triggered when a series of fragmented TCP packets with none of the SYN,
FIN, ACK, or RST flags set have been sent to the same destination port on a
number of different hosts. This could, for example, be a sweep of many hosts
to find out which ones can receive mail or telnet sessions. This is indicative
that a reconnaissance sweep of your network may be in progress. This may be
the prelude to a more serious attack. The use of this packet is abnormal, as is
the use of fragmentation, and could indicate an attempt to conceal the sweep.
3036SYN/FIN host sweep (severity 5, reconnaissance): This signature is

triggered when a series of TCP packets with both the SYN and FIN flags set
have been sent to the same destination port on a number of different hosts.
This could, for example, be a sweep of many hosts to find out which ones can
receive mail or telnet sessions. This is indicative that a reconnaissance sweep
of your network may be in progress. The use of both the SYN and FIN flag is
abnormal, and could indicate an attempt to conceal the sweep.
3037Frag SYN/FIN host sweep (severity 5, reconnaissance): This signature

is triggered when a series of TCP packets with both the SYN and FIN flags
set have been sent to the same destination port on a number of different hosts.
This could, for example, be a sweep of many hosts to find out which ones can
receive mail or telnet sessions. This is indicative that a reconnaissance sweep
of your network may be in progress. This may be the prelude to a more
serious attack. The use of both the SYN and FIN flag is abnormal, as is the
use of fragmentation, and could indicate an attempt to conceal the sweep.
Mail
Ver Len
I
P
TCP port 25
TTL
TCP
Length
Flg Frag Offset
Checksum
Source IP
Destination IP
Attacks include
Source Port
Reconnaissance
Access
DOS
Serv
Identification
Dest Port=25

T
P Len Res Flags
Window
Checksum
Urgent Pointer
Data . . .
www.cisco.com
CSIDS 2.17-37
7-39
Mail Attack Signatures

3100smail attack
3105sendmail decode alias
3101sendmail invalid recipient
3106sendmail SPAM
3102sendmail invalid sender
3107Majordomo exec bug
3103sendmail reconnaissance
3108MIME overflow bug
3104Archaic sendmail attacks
3109Qmail Length Crash
www.cisco.com
CSIDS 2.17-38
The following are Mail Attack Signatures:
7-40
3100smail attack (severity 5, access): This signature is triggered on the

very common smail attack against e-mail servers. This attack attempts to
cause e-mail servers to execute programs on the attacker's behalf. May result
in system compromise.
3101sendmail invalid recipient (severity 5, access): This signature is

triggered on any mail message with a pipe ( | ) symbol in the recipient field.
This attack attempts to cause e-mail servers to execute programs on the
attacker's behalf. May result in system compromise.
3102sendmail invalid sender (severity 5, access): This signature is

triggered by any mail message with a pipe ( | ) symbol in the From: field.
This attack attempts to cause e-mail servers to execute programs on the
attacker's behalf. May result in system compromise.
3103sendmail reconnaissance (severity 1, reconnaissance): This signature

is triggered when expn or vrfy commands are issued to the SMTP port.
This indicates that your network may be under reconnaissance.
3104Archaic sendmail attacks (severity 1, information): This signature is

triggered when wiz or debug commands are sent to the SMTP port. This
indicates that a student of computer security history has decided to make a
feeble attempt at compromising your system.
3105sendmail decode alias (severity 3, access): This signature is triggered

by any mail message with ': decode@' in the header. This may indicate an
attempt to illegally access system resources. System compromise is possible.
3106sendmail SPAM (severity 3, DoS): Counts number of Rcpt to: lines in

a single mail message and alarms after a user-definable maximum has been
exceeded (default is 250).
3107Majordomo exec bug (severity 5, access): A bug in the Majordomo

program will allow remote users to execute arbitrary commands at the
privilege level of the server.
3108MIME overflow bug (severity 5, access): Fires when an SMTP mail

message has a MIME Content- field that is excessively long. The token
MimeContentMaxLen defines the longest valid header length for MIME
Content-... Header tokens. It defaults to 200 and is settable to any value
greater or equal to 76.
3109Qmail Length Crash (severity 5, DoS): This signature is triggered

when an attempt is made to pass an overly long command string to a mail
server.
7-41
File Transfer Protocol (FTP)

Ver Len
I
P
TCP port 21
Attacks include
Serv
Identification
TTL
TCP
Length
Flg Frag Offset
Checksum
Source IP
Destination IP
Source Port
Reconnaissance
Access
Dest Port=21

T
P Len Res Flags
Window
Checksum
Urgent Pointer
Data . . .
7-42
www.cisco.com
CSIDS 2.17-39
FTP Attack Signatures
3150FTP SITE command attempted

3151FTP SYST command attempted
3152FTP CWD ~root
3153FTP Improper address specified
3154FTP Improper port specified
www.cisco.com
CSIDS 2.17-40
The following are FTP Attack Signatures:
3150FTP SITE command attempted (severity 1, reconnaissance): This

signature is triggered when someone tries to execute the FTP SITE command.
This may indicate an attempt to illegally access system resources.
3151FTP SYST command attempted (severity 1, information): The FTP

SYST command returns the type of operating system that the FTP server is
running. Authentication is not required to execute this command. SYST
provides information that may be used to refine attack methods. FTP from
Linux causes SYST signature to fire. Some proxies, such as the TIS Toolkit,
issue the SYST command as a matter of course. Running an FTP version with
SYST disabled.
3152FTP CWD ~root (severity 5, access): This signature is triggered when

someone tries to execute the CWD ~root command. This may indicate an
attempt to illegally access system resources.
3153FTP Improper address specified (severity 5, access): This signature is

triggered if a port command is issued with an address that is not the same as
the requesting host.
3154FTP Improper port specified (severity 5, access): This signature is

triggered if a port command is issued with a data port specified that is less
than 1024 or greater than 65535.
7-43
Web
Ver Len
TCP port 80
I
P
Informational
DoS
TTL
TCP
Length
Flg Frag Offset
Checksum
Source IP
Destination IP
Attacks include
Access
Serv
Identification
Source Port
Dest Port=80
T
P Len Res Flags
Window
Checksum
Urgent Pointer
Data . . .
7-44
www.cisco.com
CSIDS 2.17-41
Legacy Web Attack Signatures

3200phf attack
3209glimpse server attack
3201General cgi-bin attack
3210IIS View Source Bug
3202.url file requested
3211IIS Hex View Source Bug
3203.lnk file requested
3212NPH-TEST-CGI Bug
3204.bat file requested
3213TEST-CGI Bug
3205HTML file has .url link
3214IIS DOT DOT VIEW Bug
3206HTML file has .lnk link
3215IIS DOT DOT EXECUTE Bug
3207HTML file has .bat link
3216IIS DOT DOT DENIAL Bug
3208campas attack
www.cisco.com
CSIDS 2.17-42
The following are Web Attack signatures:
3200phf attack (severity 5, access): This signature is triggered when the

phf attack is detected. This may indicate an attempt to illegally access system
resources.
3201General cgi-bin attack (severity 5, access): This signature is triggered

when any cgi-bin script attempts to retrieve the file /etc/passwd. This may
indicate an attempt to illegally access system resources, in particular the
/etc/passwd file. This may be the prelude to a more serious attack.
3202.url file requested (severity 5, access): This signature is triggered

when a user attempts to get any .url file. A flaw in Microsoft Internet
Explorer may allow illegal access to system resources when files of type .url
are accessed via the HTTP GET command.
3203.lnk file requested (severity 5, access): This signature is triggered

when a user attempts to get any .lnk file. A flaw in Microsoft Internet
Explorer may allow illegal access to system resources when files of type .lnk
3204.bat file requested (severity 5, access): This signature is triggered

when a user attempts to get any .bat file. A flaw in Microsoft Internet
Explorer may allow illegal access to system resources when files of type .bat
3205HTML file has .url link (severity 1, access): This signature is

triggered when a file has a .url link. This signature will warn before a user has
a chance to click on the potentially damaging link. CIDS signature 3202 will
alarm on any attempt to click on the link, but it may do its damage before any
defensive action can be taken. A flaw in Microsoft Internet Explorer may
allow illegal access to system resources when files of type .url are accessed
via the HTTP GET command.
7-45
7-46
3206HTML file has .lnk link (severity 1, access): This signature is

triggered when a file has a .lnk link. This signature will warn before a user
has a chance to click on the potentially damaging link. CIDS signature 3203
will alarm on any attempt to click on the link, but it may do its damage before
any defensive action can be taken. A flaw in Microsoft Internet Explorer may
allow illegal access to system resources when files of type .lnk are accessed
3207HTML file has .bat link (severity 1, access): This signature is

triggered when a file has a .bat link. This signature will warn before a user
has a chance to click on the potentially damaging link. CIDS signature 3204
will alarm on any attempt to click on the link, but it may do its damage before
any defensive action can be taken. A flaw in Microsoft Internet Explorer may
allow illegal access to system resources when files of type .bat are accessed
3208campas attack (severity 5, access): This signature is triggered when an

attempt is made to pass commands to the CGI program campas. A problem in
the CGI program campas, that is included in the NCSA Web Server
distribution, allows an attacker to execute commands on the host machine.
These commands will execute at the privilege level of the HTTP server.
3209glimpse server attack (severity 5, access): This alarm is triggered

when an attempt is made to pass commands to the perl script GlimpseHTTP.
These could allow an attacker to execute commands on the host machine.
GlimpseHTTP is an interface to the Glimpse search tool.
3210IIS View Source Bug (severity 3, access): If a request to a Microsoft

Internet Information Server is formatted in a certain way, executable files are
read instead of being executed. This can reveal executable scripts and
sensitive database information including passwords. An attacker may be able
to analyze these scripts for vulnerabilities. This signature is triggered when a
request is made to an HTTP server attempting to view the source.
3211IIS Hex View Source Bug (severity 1, access): If a request to a

Microsoft IIS server is formatted in a certain way, executable files are read
instead of being executed. This can reveal executable scripts and sensitive
database information including passwords. An attacker may be able to
analyze these scripts for vulnerabilities. This signature is triggered when a
request is made to an HTTP server attempting to view the source.
3212NPH-TEST-CGI Bug (severity 3, access): This signature is triggered

when an attempt is made to view directory listings with the script nph-testcgi. Some HTTP servers include this script, which can be used to list
directories on a server. It is a test script and should be removed on an
operational server.
3213TEST-CGI Bug (severity 3, access): This signature is triggered when

an attempt is made to view directory listings with the script test-cgi. Some
HTTP servers contain this script, which can be used to list directories on a
server. It is a test script and should be removed on an operational server.
3214IIS DOT DOT VIEW Bug (severity 1, access): This signature is

triggered by any attempt to view files above the chrooted directory using
Microsoft's Internet Information Server. This can result in viewing files that
were not intended to be publicly accessible. The chroot directory is supposed
to be the topmost directory to which HTTP clients have access.
3215IIS DOT DOT EXECUTE Bug (severity 5, access): This signature is

triggered by any attempt to cause Microsoft's Internet Information Server to
execute commands.
3216IIS DOT DOT DENIAL Bug (severity 5, DoS): This signature is

triggered when an attempt is made to crash an IIS server by requesting a URL
beginning ../..
7-47
Legacy Web Attack Signatures

(cont.)
3217php view file Bug
3226Webdist Bug
3218SGI wrap bug
3227Htmlscript Bug
3219php buffer overflow
3228Performer Bug
3220IIS Long URL Crash
3229WebSite win-c-sample
buffer overflow
3221View Source GGI Bug

3222MLOG/MYLOG CGI Bug
3223Handler CGI Bug
3224Webgais Bug
3225WebSendmail Bug
7-48
3230WebSite uploader
3231Novell convert bug
3232finger attempt
3233Count Overflow
www.cisco.com
CSIDS 2.17-43
3217php view file Bug (severity 5, access): This signature is triggered

when someone attempts to use the PHP cgi-bin program to view a file. This
may indicate an attempt to illegally access system resources.
3218SGI wrap bug (severity 5, access): This signature is triggered by any

attempt to view or list files using the program called wrap. This was
distributed with the IRIX Web Server.
3219php buffer overflow (severity 5, access): This signature is triggered

when an oversized query is sent to the php cgi-bin program. This represents
an attempt to overflow a buffer and gain system access.
3220IIS Long URL Crash (severity 1, DoS): This signature is triggered

when a large URL has been passed to a web server in an attempt to crash the
system.
3221View Source CGI Bug (severity 3, access): This signature is triggered

when someone attempts to use the cgi-viewsource script to view files above
the http root directory.
3222MLOG/MYLOG CGI Bug (severity 3, access): This signature is

triggered when someone attempts to use the PHP scripts mlog or mylog to
view files on a machine.
3223Handler CGI Bug (severity 3, access): This signature is triggered

when someone attempts to use the cgi-handler script to execute commands.
3224Webgais Bug (severity 3, access): This signature is triggered when

someone attempts to use the webgais script to run arbitrary commands.
3225WebSendmail Bug (severity 3, access): This signature is triggered

when someone attempts to use the script websendmail to read the password
file on a machine.
3226Webdist Bug (severity 3, access): This signature is triggered when an

attempt is made to use the webdist program.
3227Htmlscript Bug (severity 3, access): This signature is triggered when

an attempt is made to view files above the html root directory.
3228Performer Bug (severity 3, access): This signature is triggered when

an attempt is made to view files above the html root directory.
3229WebSite win-c-sample buffer overflow (severity 5, access): This

signature is triggered when an attempt is made to access the win-c-sample
program distributed with WebSite servers.
3230WebSite uploader (severity 3, access): This signature is triggered

when an attempt is made to access the uploader program distributed with
WebSite servers.
3231Novell convert bug (severity 5, access): This signature is triggered

when a user has attempted to use the convert.bas program included with
Novell's web server to illegally view files.
3232finger attempt (severity 3, access): This signature is triggered when an

attempt is made to run the finger.pl program via the http server.
3233Count Overflow (severity 5, access): This signature is triggered when

an attempt is made to overflow a buffer in the cgi Count program.
7-49
NetBIOS
Ver Len
I
P
TCP Port 139
TTL
TCP
Length
Flg Frag Offset
Checksum
Source IP
Destination IP
Attacks include
Source Port
Reconnaissance
Access
DOS
Serv
Identification
Dest Port=139
T
P Len Res Flags
Window
Checksum
Urgent Pointer
Data . . .
7-50
www.cisco.com
CSIDS 2.17-44
NetBIOS Attack Signatures

3300NETBIOS OOB data
3301NETBIOS Stat
3302NETBIOS Session Setup Failure
3303Windows Guest login
3304Windows Null Account Name
3305Windows Password File Access
3306Windows Registry Access
3307Windows RedButton
www.cisco.com
CSIDS 2.17-45
The following are NetBIOS Attack signatures:
3300NETBIOS OOB data (severity 5, DoS): This signature is triggered

when an attempt to send Out Of Band data to port 139 is detected. This can
be used to crash Windows machines.
3301NETBIOS Stat (severity 1, information): This signature is triggered

when NBTSTAT is used. The Windows NT called NBTSTAT is used to
display protocol statistics and current TCP/IP connections using NetBIOS.
This application can be used to list a remote machines name table. This tool
allows an intruder to determine legitimate user names, the Windows Domain
or Workgroup name, and many other facts useful in attacking a Windows
network. There are UNIX tools available that perform the same function as
NBTSTAT.
3302NETBIOS Session Setup Failure (severity 1, information/access):

When a client connects to a SMB server (WinNT, Win95, Samba, and so on)
a TCP connection to port 139 is established. The client then provides the
server with its NetBIOS name and the NetBIOS name it wishes to connect to.
If the name does not exist on the server, the session setup attempt fails and an
error message is sent to the client. This could indicate an attack.
3303Windows Guest login (severity 1, access): When a client establishes

an connection to an SMB server (WinNT or Samba), it provides an account
name and password for authentication. If the server does not recognize the
account name, it may log the user in as a guest. This is optional behavior by
the server and guest privileges should be limited. As a general security
precaution, users should not be allowed access as guest.
3304Windows Null Account Name (severity 1, information): When a client

establishes an connection to an SMB server (WinNT or Samba), it provides
an account name and password for authentication. This signature is triggered
when a null account name is passed during session establishment. There are
7-51
some hacking tools available (Red Button and NAT) that use null account
names.
7-52
3305Windows Password File Access (severity 5, access): This alarm

occurs whenever a client attempts to access a .PWL file on the server.
These files contain user passwords on Windows 95 and other systems. This
represents an abnormal attempt to read or copy the .PWL file.
3306Windows Registry Access (severity 5, access): This signature is

triggered when a client attempts to access the registry on the Windows server.
Microsoft tools like REGEDIT provide the ability to access a servers
registry over the network. There are several hacking tools that also provide
similar capabilities. Every attempted access will cause an alarm to be sent. An
attacker can cause serious damage to a computer system by changing the
registry.
3307Windows RedButton (severity 5, access): This alarm occurs when the

RedButton tool is run against a server. The tool is designed to demonstrate
the security flaw in Windows NT 4.0 that allows remote registry access
without a valid user account. Although this flaw has been fixed with
Microsoft's NT Service Pack 3, the tool may still be run against servers. A
level five alarm shows the seriousness of this type of attack.
SYN Flood and TCP Hijack

Signatures
3050Half-Open SYN attack
DOS-SYN flood attack
Ports 21, 23, 25, and 80
3250TCP Hijacking
Access-attempt to take over a TCP session
3251TCP Hijacking Simplex Mode

One command followed by RST
www.cisco.com
CSIDS 2.17-46
The following are SYN Flood and TCP Hijack signatures:
3050Half-Open SYN attack (severity 5, DoS): This signature is triggered

when multiple TCP sessions have been improperly initiated on any of several
well-known service ports. Detection of this signature is currently limited to
FTP, Telnet, WWW, and E-mail servers (TCP ports 21, 23, 80 and 25
respectively). This is indicative that a DoS attack against your network may
be in progress.
3250TCP Hijacking (severity 5, access): This signature is triggered when

both streams of data within a TCP connection indicate that a TCP hijacking
may have occurred. The current implementation of this signature does not
detect all types of TCP hijacking and false positives may occur. Even when
hijacking is discovered, little information is available to the operator other
than the source and destination addresses and ports of the systems being
affected. TCP Hijacking may be used to gain illegal access to system
resources.
3251TCP Hijacking Simplex Mode (severity 5, access): This signature is

triggered when both streams of data within a TCP connection indicate that a
TCP hijacking may have occurred. The current implementation of this
signature does not detect all types of TCP hijacking and false positives may
occur. Even when hijacking is discovered, little information is available to the
operator other than the source and destination addresses and ports of the
systems being affected. TCP Hijacking may be used to gain illegal access to
system resources. Simplex mode means that only one command is sent,
followed by a connection RESET packet, which makes recognition of this
signature different from regular TCP Hijacking (sigID 3250).
7-53
Application Exploit Signatures

3400Sun Kill Telnet DOS
port 23
3450Finger Bomb
port 79
3500rlogin -froot
port 513
3525Imap Authenticate
Overflow
port 143
3526Imap Login
Overflow
port 143
3550Pop Overflow
port 110
www.cisco.com
CSIDS 2.17-47
The following are Application Exploit signatures:
7-54
3400Sun Kill Telnet DOS (severity 3, DoS): Fires when someone attempts
to cause the telnetd server to lock up. This will catch the program known as
sunkill.
3450Finger Bomb (severity 3, DoS): This signature is triggered when it

detects a finger bomb attack. This attack attempts to crash a finger server by
issuing a finger request that contains multiple @ symbols. If the finger server
allows forwarding, then the multiple @ symbols will cause the finger server
to recursively call itself and use up system resources.
3500rlogin -froot (severity 5, access): This signature is triggered when an

attempt to rlogin with the arguments -froot has been made. A flaw in some
rlogin processes allow unauthorized root access. Serious system compromise
is possible.
3525Imap Authenticate Overflow (severity 5, access): This signature is

triggered by receipt of packets bound for port 143 that are indicative of an
attempt to overflow a buffer in the IMAP daemon. This may be the precursor
to an attempt to gain unauthorized access to system resources.
3526Imap Login Overflow (severity 5, access): This signature is triggered

by receipt of packets bound for port 143 that are indicative of an attempt to
overflow the imapd login buffer. This may be the precursor to an attempt to
gain unauthorized access to system resources.
3550Pop Overflow (severity 5, access): This signature is triggered by

receipt of packets bound for port 110 that are indicative of an attempt to
overflow the POP daemon user buffer. This may be the precursor to an
attempt to gain unauthorized access to system resources.
Application Exploit Signatures

(cont.)
3575Inn Overflow
3601IOS Command
History Exploit
port 119
port 25
3576Inn Control
Message
3602Cisco IOS Identity
port 119
port 1999
3600IOS Telnet buffer

overflow
port 23
www.cisco.com
CSIDS 2.17-48
3575Inn Overflow (severity 5, access): This signature is triggered when an

attempt is made to overflow a buffer in the Internet News Server.
3576Inn Control Message (severity 5, access): This signature is triggered

when an attempt is made to execute arbitrary commands via the control
message.
3600IOS Telnet buffer overflow (severity 5, DoS): This signature is

triggered by receipt of packets bound for port 23 of a Cisco router that are
indicative of attempt to crash the router by overflowing an internal command
buffer. This may be the precursor to an attempt to gain unauthorized access to
system resources.
3601IOS Command History Exploit (severity 5, access): This signature is

triggered by an attempt to force a Cisco router to reveal prior users' command
history.
3602Cisco IOS Identity (severity 1, information): This signature is

triggered if someone attempts to connect to port 1999 on a Cisco router. This
port is not enabled for access.
7-55
4000 SeriesUDP Signatures

4000 SeriesUDP Signatures
Application
UDP Traffic Records

UDP Port Scan
UDP Attacks
UDP Applications
TCP
UDP
IP
Data Link
Physical
7-56
www.cisco.com
CSIDS 2.17-50
UDP Traffic Records

4000UDP Traffic Records
Triggers on all UDP service accesses
Subsignature ID is port number
25 subsignatures24 predefined UDP ports + port
0 (catchall)
User-defined ports may be added
Mostly used for tracking or forensics
Subsignature 69tftp is Severity 3
All other subsignatures are Severity 1
www.cisco.com
CSIDS 2.17-51
The following are UDP traffic records:
4000/0UDP default event levels
4000/7UDP trafficdecho
4000/9UDP trafficdiscard
4000/13UDP trafficdaytime
4000/19UDP trafficchargen
4000/37UDP traffictime
4000/53UDP trafficdns
4000/69UDP traffictftp
4000/70UDP trafficgopher
4000/80UDP trafficwww
4000/88UDP traffickerberos-v5
4000/111UDP trafficsunrpc
4000/123UDP trafficntp
4000/177UDP trafficxdmcp
4000/179UDP trafficbgp
4000/220UDP trafficimap3
4000/372UDP trafficUlistserv
4000/512UDP trafficbiff
4000/513UDP trafficwho
4000/514UDP trafficsyslog
7-57
7-58
4000/515UDP trafficprinter
4000/517UDP traffictalk
4000/518UDP trafficntalk
4000/520UDP trafficroute
4000/2049UDP trafficnfs
UDP Port Scan Signature

Ver Len
4001UDP port scan

One host searches for
multiple UDP services
on a single host.
I
P
U
D
P
www.cisco.com
Serv
Identification
TTL
UDP
Length
Flg Frag Offset
Checksum
Source IP
Destination IP
Source Port
Dest Port
Length
Checksum
Data . . .
CSIDS 2.17-52
The following is a UDP Port Scans Signature: 4001UDP port scan (severity 5,
reconnaissance): This signature is triggered when a series of UDP connections to a
number of different destination ports on a specific host have been initiated. This
indicates that a reconnaissance sweep of your network may be in progress. This
may be the prelude to a more serious attack.
7-59
UDP Attack Signatures

4002UDP flood
Ver Len
Many UDPs to same host

I
P
4050UDP Bomb
UDP length < IP length
TTL
Length
Serv
Identification
UDP
Flg Frag Offset

Checksum
Source IP
Destination IP
Source Port
Dest Port
U
Checksum
Length
4051Snork
Src=135, 7, or 19; Dest=135
D
P
Data . . .
4052Chargen DoS
Src=7 & Dest=19
www.cisco.com
CSIDS 2.17-53
The following are UDP Attacks Signatures
7-60
4002UDP flood (severity 1, DoS): This is triggered when a large number

of UDP packets are directed at a host. This will fire when the Pepsi attack is
launched across a protected boundary. This signature is also indicative of a
UDP port sweep.
4050UDP Bomb (severity 3, DoS): This signature is triggered when the

UDP length specified is less than the IP length specified. This malformed
packet type is associated with a DoS attempt.
4051Snork (severity 3, DoS): This signature is triggered when a UDP

packet is seen with a source port of either 135, 7, or 19 and a destination port
of 135 is detected.
4052Chargen DoS (severity 3, DoS): This signature is triggered when a

UDP packet is detected with a source port of 7 and a destination port of 19.
UDP Application Signatures

4053Back Orifice
Ver Len
port 31337
4100Tftp passwd file attempt
I
P
TTL
Ascend router exploit
UDP
Length
Flg Frag Offset
Checksum
Source IP
port 69
4150Ascend Kill
Serv
Identification
Destination IP
U
D
P
Source Port
Dest Port
Length
Checksum
Data . . .
4600IOS UDP bomb

port 514
www.cisco.com
CSIDS 2.17-54
The following are UDP application signatures:
4053Back Orifice (severity 5, access): This signature is triggered when

CIDS detects traffic coming from a Back Orifice server that is running on the
network. Back Orifice is a backdoor program that can be installed on a
Microsoft Windows 95 or Windows 98 system, allowing remote control of
the system.
4100Tftp passwd file attempt (severity 5, access): This signature is

triggered by an attempt to access the passwd file via TFTP. Indicative of an
4150Ascend Kill (severity 3, DoS): This signature is triggered when an

attempt has been made to send a maliciously malformed command to an
ascend router in an attempt to crash the router.
4600IOS UDP bomb (severity 5, DoS): This signature is triggered by

receipt of improperly formed SYSLOG transmissions bound for UDP port
514.
7-61
5000 SeriesWeb Signatures

5000 SeriesHTTP Signatures

Ver Len
TCP port 80
I
P
Informational
DoS
TTL
TCP
Length
Flg Frag Offset
Checksum
Source IP
Destination IP
Attacks include
Access
Serv
Identification
Source Port
Dest Port=80
T
P Len Res Flags
Window
Checksum
Urgent Pointer
Data . . .
7-62
www.cisco.com
CSIDS 2.17-56
HTTP Signatures
5034WWW IIS newdsn Attack
5051WWW Double Byte Code Page
5036WWW Windows Password

File Access Attempt
5052FrontPage Extensions PWD

Open Attempt
5038 WWW wwwsql file read bug
5053FrontPage _vti_bin Directory

List Attempt
5042WWW CGI Valid Shell Access

5043WWW Cold Fusion Attack
5055HTTP Basic Authentication

OverFlow
5047WWW Server Side Include

POST Attack
5070WWW msadcs.dll Access

5071WWW msadcs.dll Attack
5049 WWW IIS showcode.asp

Access
5075WWW IIS Virtualized UNC Bug

5078WWW Piranha passwd Attack
5050 WWW IIS .htr Overflow

Attack
www.cisco.com
CSIDS 2.17-57
The following are 5000 series signatures:
5034WWW IIS newdsn Attack (severity 5, access): This signature is

triggered when an attempt is made to run the newdsn.exe command via the
http server. The newdsn.exe sample application installed with Microsoft's
Internet Information Server (IIS) version 3.0 contains a vulnerability that
allows a remote attacker to create arbitrary Microsoft Access files (*.mdb) on
the web server under any arbitrary file name. A remote attacker can create
files on the hard disk of the webserver and eventually fill it up, thus causing
DoS. In addition, a well-known exploit will cause the web server to become
unresponsive (hang) or generate a General Protection Fault (GPF).
5036WWW Windows Password File Access Attempt (severity 5, access):

This alarm is triggered when an attempt is made to retrieve either the current
or backup copy of the Windows NT password file through the web server.
5038WWW wwwsql file read bug (severity 5, access): This alarm is

triggered when an attempt is made to read files in the cgi-bin directory by the
www-sql script. This could indicate that a remote attacker is trying to
download cgi-bin scripts and access otherwise protected directories under
DocumentRoot.
5042WWW CGI Valid Shell Access (severity 5, access): This signature is

triggered when an attempt is made to access a valid shell or interpreter on the
targeted system. These include the following: bash, tcsh, ash, bsh, csh, ksh,
jsh, zsh, sh, Java and Python interpreters. This may indicate an attempt to
illegally access system resources.
5043WWW Cold Fusion Attack (severity 5, access): This alarm is

triggered when an attempt is made to access example scripts shipped with
Cold Fusion Servers. Attempts to access the openfile.cfm or exprcalc.cfm
scripts could indicate an attacker is trying to upload files to the target host or
7-63
server. Attempts to access displayopenedfile.cfm could indicate that an

attacker is trying to access files on the target host or server.
7-64
5049WWW IIS showcode.asp Access (severity 3, access): This alarm is

triggered whenever an attempt is made to access the showcode.asp Active
Server Page. This script allows for arbitrary access to any file on the targets
file system.
5050WWW IIS .htr Overflow (severity 5, access): This signature is

triggered when an .htr buffer overrun attack is detected, indicating a possible
attempt to execute remote commands, or cause a DoS against the targeted
system.
5051WWW Double Byte Code Page (severity 3, access): The Internet

Information Server (IIS) contains a vulnerability that could allow a web site
visitor to view the source code for selected files on the server, if the servers
default language is set to Chinese, Japanese or Korean.
5052FrontPage Extensions PWD Open Attempt (severity 5, access): This

signature is triggered when an attempt was made to open a configuration file
on a Microsofts Personal Webserver (for Windows platforms) or FrontPage
extensions (for UNIX) web server.
5053FrontPage _vti_bin Directory List Attempt (severity 5, access): This

signature is triggered when an attempt was made to list the directory of
binaries from Microsofts Personal Webserver (for Windows platforms) or
FrontPage extensions (for UNIX) web server.
5055HTTP Basic Authentication Overflow (severity 5, access): A buffer

overflow can occur on vulnerable web servers if a very large username and
password combination is used with Basic Authentication.
5070WWW msadcs.dll Access (severity 5, reconnaissance): This signature

is triggered when an attempt has been made to access the msacds.dll CGI
program. This attempt may indicate a reconnaissance session for a later attack
to exploit the IIS RDS vulnerability. While no attempt to execute commands
or view files was detected, administrators are highly recommended to check
the systems affected to ensure that they have not been altered.
5071WWW msadcs.dll Attack (severity 5, access): This signature is

triggered when an attempt has been made to execute commands or view
secured filed, with privileged access. Administrators are highly recommended
to check the affected systems to ensure that they have not been illicitly
modified.
5075WWW IIS Virtualized UNC Bug (severity 3, access): This signature

is triggered when an attempt has been made to view the source of an ASP file.
A bug exists in certain versions of Microsofts IIS web server which allow an
attacker to view of the source of ASP, and other files if the IIS virtual
directory they reside in has been mapped to a UNC share.
5078WWW Piranha passwd Attack (severity 5, access): This signature is

triggered when an attempt has been made to access the vulnerable
piranha/secure/passwd.php3 cgi script using suspicious arguments.
HTTP Signatures (cont.)

5081WWW WinNT cmd.exe
5085WWW IIS Source Fragment
Access
5087WWW Sun Java Server
Access
5107WWW Mandrake Linux/perl

Access
5108WWW Netegrity SiteMinder
Access
5090WWW FrontPage
htimage.exe Access
5091WWW Cart32 Remote Admin
Access
5097WWW FrontPage MS-DOS
Device Attack
5103WWW Suse Apache CGI Source

Attack
5111WWW Solaris Answerbook 2

Access
5112WWW Solaris Answerbook 2
Attack
5114WWW IIS Unicode Attack
www.cisco.com
CSIDS 2.17-58
5081WWW WinNT cmd.exe (severity 5, access): This signature is

triggered when the use of the Windows NT cmd.exe is detected in a URL. A
malicious user could cause severe damage to the system hosting the web site.
Malicious users could add, change or delete data, run code already on the
server, or upload new code to the server and run it.
5085WWW IIS Source Fragment (severity 3, access): This signature is

triggered when a URL ending in +.htr is detected. A remote attacker could
view the contents of ASP, ASA, and other file types on the web server, which
may contain sensitive information such as usernames and passwords.
5087WWW Sun Java Server Access (severity 3, access): This signature is

triggered when an attempt to access URLs like http://server/pservlet.html or
http://server/servlet/sunexamples.RealmDumpServlet are detected. A remote
attacker can identify users and file permissions on the web server. This
knowledge could be used to perform additional probes or attacks to gain
further access to the web server.
5090WWW FrontPage htimage.exe Access (severity 3, reconnaissance):

This signature is triggered when the FrontPage CGI program is accessed with
a filename argument ending with 0,0. This file is associated with three
known vulnerabilities when it is on Windows servers. It will allow
identification of the web root path, possibly cause a DoS when run with a
very large argument, and allow access to files on the web server.
5091WWW Cart32 Remote Admin Access (severity 3,

reconnaissance/access): This signature is triggered when an attempt is made
to access the vulnerable cart32.exe cgi script with suspicious arguments:
/cart32.exe/cart32clientlist or /c32web.exe/changeadminpassword. A remote
user can change the administrative password without knowing the previous
password. The remote user could also obtain information such as username,
password, and credit card numbers.
7-65
7-66
5097WWW FrontPage MS-DOS Device Attack (severity 5, access): This

alarm is triggered when a URL is requested using the shtml.exe component of
FrontPage that includes an MS-DOS device name. A DoS can result from this
URL request.
5103WWW SuSE Apache CGI Source Attack (severity 3, recon): This

signature is triggered when an attempt to access the /cgi-bin-sdb directory of
a web server is detected. An attacker could view the contents of CGI scripts /
programs that may contain sensitive information, like database usernames and
passwords.
5107WWW Mandrake Linux/perl Access (severity 3, recon): This

signature is triggered when an attempt to access the URL path /perl directly
has been detected. The /perl directory is used by mod_perl to store Perl
scripts which can be executed by the web server. By accessing this directory,
a remote user is able to obtain a directory listing. The knowledge of a script's
presence may allow more sophisticated attacks to occur.
5108WWW Netegrity SiteMinder Access (severity 3, access): This

signature is triggered when an unauthorized attempt to access protected
content on a website managed by Netegrity Site Minder using an
authentication bypass method is detected. Looks for strings like
/$/somefile.ccc in a URL. A remote attacker can read and / or execute
protected content on the web site administered by Site Minder.
5111WWW Solaris Answerbook2 Access (severity 3, recon): This

signature is triggered when an attempt to add a user to the AnswerBook
interface is detected.
5112WWW Solaris Answerbook 2 Attack (severity 5, access): This

signature is triggered when attempt to execute an unauthorized command
using the access / error rotation feature of the administrative interface of
AnswerBook 2 is detected. A remote attacker can create an AnswerBook
administrator account without providing any authentication information
allowing the attacker to gain the ability to execute arbitrary commands with
the privileges of the web server.
5114WWW IIS Unicode Attack (severity 5, access): This signature is

triggered when an attempt to exploit the Unicode ../ directory traversal
vulnerability is detected. An attacker could add, change or delete data, run
code already on the server, or upload new code to the server and run it.
6000 SeriesCross-Protocol Signatures

6000 SeriesCross-Protocol
Signatures
SATAN Attacks
DNS Attacks
RPC Attacks
Ident Attacks
Application
TCP
IP
Authorization Failures
Loki Attack
DoS
UDP
Data Link
Physical
www.cisco.com
CSIDS 2.17-60
The 6000 series, Cross-protocol signatures detect attacks that are independent of
IP protocols. For instance, RPC related services could operate on both TCP and
UDP.
7-67
SATAN Attack Signatures

6001Normal SATAN probe
The Network
Vulnerability
Scanner is used
for scanning
services and
vulnerabilities.
Port sweep pattern produced

by SATAN running in normal
mode
6002Heavy SATAN probe

Port sweep pattern produced
by SATAN running in heavy
mode
6001 also triggers
www.cisco.com
CSIDS 2.17-61
The following are SATAN attack signatures:
7-68
6001Normal SATAN probe (severity 5, reconnaissance): This is a

supersignature that is triggered when a port sweep pattern produced by the
SATAN tool is detected. This signature is tuned to detect SATAN being run
in normal mode. Other types of attack activity similar to SATAN may also
cause this signature to be generated. This is indicative that a reconnaissance
sweep of your network may be in progress. This may be the prelude to a more
serious attack.
6002Heavy SATAN probe (severity 5, reconnaissance): This is a

supersignature that is triggered when a port sweep pattern produced by the
SATAN tool is detected. This signature is tuned to detect SATAN being run
in heavy mode. Other types of attack activity similar to SATAN may also
cause this signature to be generated. This is indicative that a reconnaissance
sweep of your network may be in progress. This may be the prelude to a more
serious attack
DNS Attack Signatures

6050DNS HINFO Request
UDP Port 53
attacks include
Reconnaissance
Denial of
Service
Access
6051DNS Zone Transfer Request

6052DNS Zone Transfer from other
port
6053DNS request for all records
6054DNS Version Request
6055DNS Inverse Query Buffer
Overflow
6056BIND NXT Buffer Overflow
6057BIND SIG Buffer Overflow
www.cisco.com
CSIDS 2.17-62
The following are DNS attack signatures:
6050DNS HINFO Request (severity 3, access): This signature is triggered

by an attempt to access HINFO records from a DNS server. The Domain
Name Service (DNS) includes an optional record type that allows for system
information to be recorded and retrieved. This information typically includes
the OS and hardware platform that the system is running on. There is very
little utility in including this record in the database, and it provides attackers
with valuable targeting information. It is suggested that this record not be
included in your DNS database for this reason. This is indicative that your
network may be under reconnaissance.
6051DNS Zone Transfer Request (severity 1, information): This signature

is triggered by normal DNS zone transfers, in which the source port is 53.
Zone transfers are the method by which secondary DNS servers update their
DNS records. All DNS records are transferred at once from the primary to
secondary server. This transfers records only for the zone specified. This is
indicative that your network may be under reconnaissance.
6052DNS Zone Transfer from other port (severity 5, reconnaissance): This

signature is triggered by an illegitimate DNS zone transfer, in which the
source port is not equal to 53. Zone transfers are the method by which
secondary DNS servers update their DNS records. All DNS records are
transferred at once from the primary to secondary server. This transfers
records only for the zone specified. Because of the access method this is
indicative that your network most probably is under reconnaissance. This
may be the prelude to more serious attacks.
6053DNS request for all records (severity 3, access): This signature is

triggered by a DNS request for all records. Similar to a zone transfer in that it
provides a method for transferring DNS records from a server to another
requesting host. The primary difference is that all DNS records are transferred
7-69
not just those specific to a particular zone. This is indicative that your
network may be under reconnaissance.
7-70
6054DNS Version Request (severity 3, informational): This alarm triggers

when a request for the version of a DNS server is detected. Numerous
versions of the popular BIND DNS server contain buffer overflow
vulnerabilities, and scanners have been written to detect the presence of
vulnerable DNS servers.
6055DNS Inverse Query Buffer Overflow (severity 5, access): This alarm

triggers when an IQUERY request arrives with a data section that is larger
than 255 characters
6056BIND NXT Buffer Overflow (severity 5, access): This alarm triggers

when a DNS server response arrives that has a long NXT resource where the
length of the resource data is greater than 2069 bytes OR the length of the
TCP stream containing the NXT resource is greater than 3000 bytes.
6057BIND SIG Buffer Overflow (severity 5, access): This alarm triggers

when a DNS server response arrives that has a long SIG resource where the
length of the resource data is greater than 2069 bytes OR the length of the
TCP stream containing the SIG resource is greater than 3000 bytes.
RPC Services
Applications do not use
well-known ports.
Use portmapper
Registers applications
TCP/UDP port 111
Client
Attacks include
2488
GET PORT #
2488 USE PORT # 2049
Reconnaissance
Access
2488
NFS REQUEST
111
Server
111
2049
DoS
www.cisco.com
CSIDS 2.17-63
7-71
RPC Attack Signatures

6100RPC port
registration
6102RPC dump
rpcinfo -p <host>
Remotely registering a
service that is not running
6101RPC port
unregistration
6103Proxied RPC
request
Bypasses RPC
authentication
Remotely unregistering a
running service
www.cisco.com
CSIDS 2.17-64
The following are RPC attack signatures:
7-72
6100RPC port registration (severity 5, access): This signature is triggered

when attempts are made to register new RPC services on a target host. Port
registration is the method used by new services to report to the portmapper
that they are present and to gain access to a port, this is then advertised by the
portmapper. This should not be allowed from a remote host. No known
exploit of this function exists. This does not preclude the possibility that
exploits do exist outside of the realm of Cisco Systems knowledge domain.
6101RPC port unregistration (severity 5, DoS): This signature is triggered

when attempts are made to unregister existing RPC services on a target host.
Port unregistration is the method used by services to report to the portmapper
that they are no longer present and to remove them from the active port map.
This should not be allowed from a remote host. No known exploit of this
function exists. This does not preclude the possibility that exploits do exist
outside of the realm of Cisco Systems knowledge domain.
6102RPC dump (severity 5, reconnaissance): This signature is triggered

when an RPC dump request is issued to a target host. This is a procedure that
may be used to determine the presence and port location of RPC services
being provided by a system. Indicative that your network may be under
reconnaissance.
6103Proxied RPC request (severity 1 access): This signature is triggered

when a proxied RPC request is sent to the portmapper of a target host. A
method for requesting RPC services by having the portmapper act as your
proxy. This may indicate an attempt to gain unauthorized access to system
resources and should not be allowed from hosts outside your network.
RPC Attack Signatures (cont.)

6110RSTATD
RPC Port Sweeps
6111RUSERSD
Request service on
many ports on same
host
6112NFS
6113MOUNTD
6114YPPASSWD
Stealth
reconnaissance
6115SELECTION SVC
6116REXD
6117STATUS
6118TTDB
www.cisco.com
CSIDS 2.17-65
6110RSTAT (severity 5, reconnaissance): This signature is triggered when

RPC requests are made to many ports for the RSTATD program.
6111RUSERS (severity 5, reconnaissance): This signature is triggered

when RPC requests are made to many ports for the RUSERSD program.
6112NFS (severity 5, reconnaissance): This signature is triggered when

RPC requests are made to many ports for the NFS program.
6113MOUNT (severity 5, reconnaissance): This signature is triggered

when RPC requests are made to many ports for the MOUNTD program.
6114YPPASSW (severity 5, reconnaissance): This signature is triggered

when RPC requests are made to many ports for the YPPASSWDD program.
6115SELECTION SV (severity 5, reconnaissance): This signature is

triggered when RPC requests are made to many ports for the
SELECTION_SVC program.
6116REX (severity 5, reconnaissance): This signature is triggered when

RPC requests are made to many ports for the REXD program.
6117STATU (severity 5, reconnaissance): This signature is triggered when

RPC requests are made to many ports for the STATUS program.
6118TTDB (severity 5, reconnaissance): This signature is triggered by an

attempt to access the tooltalk database daemon on multiple ports on a single
host.
7-73

6150ypserv
Portmapper Requests
Requests for services
known to be exploited
In most cases should not
be used
If needed, filter signatures
6151ypbind
6152yppasswd
6153ypupdated
6154ypxfrd
6155mountd
6175rexd
7-74
www.cisco.com
CSIDS 2.17-66
6150ypserv (severity 1 access): This signature is triggered when a request

is made to the portmapper for the YP server daemon (ypserv) port. The
ypserv daemon is responsible for looking up information maintained in NIS
maps. This may indicate an attempt to gain unauthorized access to system
resources.
6151ypbind (severity 1 access): This signature is triggered when a request

is made to the portmapper for the YP bind daemon (ypbind) port. The ypbind
daemon is responsible for maintaining the information needed for a client
process to communicate with a ypserv process. This may indicate an attempt
to gain unauthorized access to system resources.
6152yppasswd (severity 1 access): This signature is triggered when a

request is made to the portmapper for the YP password daemon (yppasswdd)
port. The YP password daemon allows users to remotely modify password
files. This may indicate an attempt to gain unauthorized access to system
resources.
6153ypupdated (severity 1 access): This signature is triggered when a

request is made to the portmapper for the YP update daemon (ypupdated)
port. The YP update daemon is responsible for updating local NIS maps. This
may indicate an attempt to gain unauthorized access to system resources.
6154ypxfrd (severity 1 access): This signature is triggered when a request

is made to the portmapper for the YP transfer daemon (ypxfrd) port. The YP
transfer daemon is responsible for transferring NIS information on behalf of
ypserv. This may indicate an attempt to gain unauthorized access to system
resources.
6155mountd (severity 1 access): This signature is triggered when a request

is made to the portmapper for the mount daemon (mountd) port. This is the
NFS daemon that is responsible for processing mount requests. This may
indicate an attempt to gain unauthorized access to system resources.
6175rexd (severity 3, access): This signature is triggered when a request is

made to the portmapper for the remote execution daemon (rexd) port. The
remote execution daemon is the server responsible for remote program
execution. This may indicate an attempt to gain unauthorized access to
system resources.
7-75

6180-rexd attempt
Accessing rexd
Allows remotely
running commands
RPC Services with

Buffer Overflow
Vulnerabilities:
Should not be allowed
6190statd
6191ttdb
Unknown by some
administrators
6192mountd
6193cmsd
6194sadmind
6195amd
7-76
www.cisco.com
CSIDS 2.17-67
6180rexd attempt (severity 5, access): This signature is triggered when a

call to the rexd program is made. The remote execution daemon is the server
responsible for remote program execution. This may indicate an attempt to
gain unauthorized access to system resources.
6190statd (severity 5, access): This signature is triggered when a large statd

request is sent. This could be an attempt to overflow a buffer and gain access
to system resources.
6191ttdb (severity 5, access): This signature is triggered when an attempt is

made to overflow an internal buffer in the tooltalk rpc program.
6192mountd (severity 5, access): This signature is triggered by an attempt

to overflow a buffer in the RPC mountd application. This may result in
unauthorized access to system resources.
6193cmsd (severity 5, access): This signature fires when an attempt is

made to overflow an internal buffer in the Calendar Manager Service
Daemon, rpc.cmsd. This vulnerability can allow a remote attacker to gain root
access.
6194sadmind (severity 5, access): This signature fires when a call to RPC

program number 100232 procedure 1 with a UDP packet length > 1024 bytes
is detected. This vulnerability can allow a remote attacker to gain root access.
6195amd (severity 5, access): he trigger for this signature is an RPC call to

the berkeley automounter daemons rpc program (300019) procedure 7 with a
UDP length > 1024 or a TCP stream length > 1024. The TCP stream length is
defined by the contents of the two bytes preceding the RPC header in a TCP
packet. This vulnerability can allow a remote attacker to gain root access.
Ident Attack Signatures

6200Ident buffer
overflow
Ident is a protocol to
prevent hostname,
address, and username
spoofing
IDENT reply too large
6201Ident newline
IDENT reply with newline
plus more data
TCP port 113

6202Ident improper
request
IDENT request too long or
non-existent ports
www.cisco.com
CSIDS 2.17-68
The following are Ident Attack signatures:
6200Ident buffer overflow (severity 5, access): This signature is triggered

when a server returns an IDENT reply that is too large. This may indicate an
6201Ident newline (severity 5, access): This signature is triggered when a

server returns an IDENT reply that includes a newline followed by more data.
This may indicate an attempt to gain unauthorized access to system resources.
6202Ident improper request (severity 5, access): This signature is triggered

when a clients IDENT request is too long or specifies non-existent ports.
This may indicate an attempt to gain unauthorized access to system resources.
7-77
Authorization Failure
Signatures
6250FTP
Three failed
attempts to log in
6251Telnet
6252Rlogin
6253POP3
6255SMB
www.cisco.com
CSIDS 2.17-69
The following are Authorization Failure signatures:
7-78
6250FTP (severity 1, information/access): This signature is triggered when

a user has failed to authenticate three times in a row, while trying to establish
an FTP session. This may indicate a brute force password-guessing attempt,
and may be viewed as an attempt to gain unauthorized access to system
resources.
6251Telnet (severity 1, information/access): This signature is triggered

when a user has failed to authenticate three times in a row, while trying to
establish a telnet session. This may indicate a brute force passwordguessing attempt, and may be viewed as an attempt to gain unauthorized
access to system resources.
6252Rlogin (severity 1 access): This signature is triggered when a user has

failed to authenticate three times in a row, while trying to establish an rlogin
session. This may indicate a brute force password-guessing attempt, and
may be viewed as an attempt to gain unauthorized access to system resources.
6253POP3 (severity 1, information/access): This signature is triggered

when a user has failed to authenticate three times in a row, while trying to
establish a POP3 session. This may indicate a brute force passwordguessing attempt, and may be viewed as an attempt to gain unauthorized
access to system resources.
6255SMB (severity 1, information/access): This alarm is triggered when a

client fails Windows NT's (or Sambas) user authentication three or more
consecutive times within a single SMB session. This indicates that the user
does not have a valid account name or password, the user has forgotten the
password, or a password guessing attack like NAT is being used against the
server. This alarm will also trigger on multiple failures to access a Windows
95 share. Share level access disregards the provided username and only uses
the provided password.
Loki Attack Signatures

6300Loki ICMP tunnel
Loki is a tool used
to hide hacker
traffic inside an
ICMP tunnel. It
requires root
access
Original Loki
Phrack Issue 51
6302Modified Loki
ICMP tunneling
Modified Loki version
www.cisco.com
CSIDS 2.17-70
The following are Loki attack signatures:
6300Loki ICMP tunnel (severity 5, access): Loki is a tool designed to run

an interactive session that is hidden within ICMP traffic. An attacker needs to
first gain root on a system, but can then set up a Loki server (lokid) as a
backdoor. This can provide future command line access hidden as ICMP
traffic, which can be encrypted. This signature will fire if the original Loki
that was distributed in Phrack Issue 51 is implemented.
6302Modified Loki ICMP tunneling (severity 5, access): Loki is a tool

designed to run an interactive session that is hidden within ICMP traffic. An
attacker needs to first gain root access on a system, but can then set up a Loki
server (lokid) as a backdoor. This can provide future command line access
hidden as ICMP traffic, which can be encrypted. This signature will trigger
on Loki even if certain user-configurable options have been modified.
7-79
DDoS Signatures
6501TFN client request
6502TFN Server reply
6503Stacheldraht client request
6504Stacheldraht Server reply
6505Trinoo client request
6506Trinoo server reply
6507TFN2K DDoS Control traffic
6508mstream DDoS Control traffic
www.cisco.com
CSIDS 2.17-71
A distributed denial of service (DDoS) attack is a form of a DoS attack where the
attack launched against a victim host or network is launched from multiple
attacking hosts. The attacking hosts are controlled from a master host. The
following are DDoS Attack signatures:
7-80
6501TFN Client request (severity 5, DoS): Tribe Flood Network (TFN) is a

distributed DoS tool. This signature looks for ICMP echo reply packets
containing potential TFN commands sent from a TFN CLIENT--TO-> a
SERVER. The ICMP reply will not have an associated ICMP echo request
packet. Other associated signatures: TFN Server Reply, detects server
sending packets to client. Loki ICMP tunneling, which can also detect TFN
traffic.
6502TFN Server reply (severity 5, DoS): Tribe Flood Network (TFN) is a

distributed DoS tool. This signature looks for ICMP echo reply packets
containing potential TFN commands sent from a TFN CLIENT>TO > a
SERVER. The ICMP reply will not have an associated ICMP echo request
packet. Other associated signatures: TFN Server Reply, detects server
sending packets to client. Loki ICMP tunneling, which can also detect TFN
traffic.
6503Stacheldraht Client request (severity 5, DoS): Stacheldraht clients and

servers by default, communicate using ICMP echo reply packets. This
signature looks for ICMP echo reply packets containing potential commands
sent from a Stacheldraht CLIENT > TO > SERVER. The ICMP reply will not
have an associated ICMP echo request packet. Other associated signatures:
Stacheldraht Server Reply, detects server sending packets to client. Loki
ICMP tunneling, which can also detect Stacheldraht traffic. Large ICMP
Traffic, detects a reported bug in the Stacheldraht code that sends out large
>1000 byte packets.
6504Stacheldraht Server reply(severity 5, DoS): Stacheldraht clients and

servers by default, communicate using ICMP echo reply packets. This
signature looks for ICMP echo reply packets containing potential commands
sent from a Stacheldraht CLIENT --TO--> SERVER. The ICMP reply will
not have an associated ICMP echo request packet. Other associated
signatures: Stacheldraht Server Reply, detects server sending packets to
client. Loki ICMP tunneling, which can also detect Stacheldraht traffic. Large
ICMP Traffic , detects a reported bug in the Stacheldraht code that sends out
large >1000 byte packets.
6505Trinoo Client request (severity 5, DoS): Trinoo clients communicate

by default on UDP port 27444 using a default command set. This signature
looks for UDP packets containing potential commands from a Trinoo
CLIENT >TO> SERVER.
6506 Trinoo Server reply (severity 5, DoS): Trinoo clients communicate by

default on UDP port 27444 using a default command set. This signature looks
for UDP packets containing potential commands from a Trinoo
CLIENT>TO> SERVER.
6507 TFN2K DDoS Control traffic (severity 5, DoS): TFN2K is a more

robust and flexible version of the original Tribe Flood Network. This
signature identifies the control traffic from the hackers client console and the
server (zombie) machine.
6508mstream DDoS Control traffic (severity 5, DoS): Mstream is a Unix

based distributed DoS tool similar to Trinoo, TFN and Stacheldraht. Mstream
uses the Stream (stream.c) DoS as its method of assault. This signature
identifies the control traffic between both the attacker <-> client (aka
handler), and between the client (aka handler) <-> server (aka agent or
daemon).
7-81
8000 SeriesString Match Signatures

8000 SeriesString Match

Signatures
Application
Custom string
matches
TCP applications
TCP
UDP
IP
Data Link
Physical
7-82
www.cisco.com
CSIDS 2.17-73
8000 SeriesString Matches

User-defined string matches for TCP
ports are used for
Custom attack signatures
Security policy enforcement
Definable options
Port
Direction
Number of occurrences
String
www.cisco.com
CSIDS 2.17-74
The 8000 seriesstring matchsignatures enable the network security

administrator to create custom TCP signatures to detect specific string patterns.
This flexibility provides the network security administrator the ability to
implement and deploy on-the-fly signatures. Custom signatures commonly are
used to do the following:
Act as a temporary signature for newly discovered vulnerabilities until an

official CIDS signature is released.
Detect misuse based on offending keywords.
Protect specific network applications that CIDS does not have current
signatures to detect possible attacks.
Custom signatures can be configured by specifying the following parameters:
TCP port number
Traffic direction (to or from port)
Number of occurrences
String
7-83
Custom String Match

Signatures
SubSignature ID identifies each specific

match and is assigned automatically
The string defined using regular expressions
Example string settings:
String
ID
Port
[/]etc[/]shadow 2302 23
www.cisco.com
Direction
Occur
To
CSIDS 2.17-75
String signatures use a regular expression intrusion detection system engine. You
may enter a UNIX-like regular expression as the string to match. The example
string signature will match attempts to grab a UNIX shadow password file.
7-84
TCP Application Signatures

Capture password file
2101FTP RETR passwd
loadmodule Attack
TCP application
signatures are attacks
against various TCP
applications. They are
implemented here as
an example of regular
expression formats.
2301Telnet IFS=/
51301Rlogin IFS=/"
Planting .rhosts
2303Telnet + +
51303Rlogin + +
Accessing shadow passwd

2302Telnet /etc/shadow
51302Rlogin /etc/shadow
www.cisco.com
CSIDS 2.17-76
The following are TCP application signatures:
Capture password file:
Attempt loadmodule Attack
51301Rlogin IFS=/ (severity 5, access): This signature is triggered

when an attempt to change the IFS to / is done during a rlogin session.
This may indicate an attempt to gain unauthorized access to system
resources.
2303Telnet + + (severity 1, access): This signature is triggered by
string + + issued during a telnet session.
51303Rlogin + + (severity 1, access): This signature is triggered by
string + + issued during a rlogin session.
Access UNIX shadow password file
2301Telnet IFS=/ (severity 5, access): This signature is triggered by

an attempt to change the IFS to / is done during a telnet session. This may
indicate an attempt to gain unauthorized access to system resources.
Enable unrestricted r-service access
2101FTP RETR passwd (severity 5, access): This signature is

triggered by a string passwd issued during an FTP session. May
indicate someone attempting to retrieve the password file from a machine
in order to crack it and gain unauthorized access to system resources.
2302Telnet /etc/shadow (severity 5, access): This signature is

triggered by a string /etc/shadow issued during a Telnet session. This
7-85
7-86
51302Rlogin /etc/shadow (severity 5, access): This signature is

triggered on a string /etc/shadow issued during a rlogin session. This
10000 SeriesACL Policy Violation

Signatures
10000 SeriesPolicy Violation

Signatures
ACL violation
records
Syslog
You can generate

alarms from Cisco
router ACL violations
Map E dit L cte Vie w P erf rm ace C o nf igr atn Fau lt S ecu rit y Mi sc
O pt ion s
H elp
M ap E d it L cte V iew Per fr ma ce C on fig ra tn F aul t S ecur ity Misc

O ptio ns
He lp
Repackages Syslog
messages from
routers
www.cisco.com
CSIDS 2.17-78
7-87
Summary
Summary
Each signature can generate a unique alarm
and response.
Context signatures are triggered by
information in the packet header.
Content signatures are triggered by
information in the packet payload.
Atomic signatures are triggered by
information in a single packet.
7-88
www.cisco.com
CSIDS 2.17-80
Summary (cont.)
Composite signatures are triggered by
information in multiple packets.
Reconnaissance signatures are triggered by
attempts to discover systems, services, or
vulnerabilities.
Access signatures are triggered by
unauthorized attempts to retrieve data,
access systems, or escalate privileges.
DoS signatures are triggered by attempts to
disable networks, systems, or services.
www.cisco.com
CSIDS 2.17-81
7-89
Summary (cont.)
Informational signatures collect information
to help determine the validity of an attack, or
for forensics.
Signature series generally group protocol
related signatures under a single category.
The default signature severities are:
Low (1) indicates informational activity
Medium (3) indicates marginal attack activity
High (5) indicates severe attack activity
7-90
www.cisco.com
CSIDS 2.17-82
Sensor Configuration
Overview
Objectives
Basic configuration
Log file configuration
Advanced setting configuration
Summary
Lab exercise
Objectives
Objectives
Upon completion of this chapter, you will be able to
perform the following tasks:
Configure the Sensors identification parameters, internal
network entries, and the packet capture device setting.
Enable the Sensor to generate log files and configure it to
automatically transfer the log files to an FTP server.
Enable and configure the IP fragment reassembly feature on
the Sensor.
Enable and configure the TCP Session reassembly feature
on the Sensor.
Configure advanced PostOffice settings.
Configure the Sensor to send alarms to additional
destinations.
8-2
www.cisco.com
CSIDS 2.18-2
Basic Configuration
This section discusses how to configure the following basic options for a Sensor:
identification settings, internal network definition, and the packet capture device.
Identification Settings
Select
Select the
the
Sensor
Sensor
Click
Click OK
OK
www.cisco.com
CSIDS 2.18-4
You can change the identification settings associated with a Sensor. These
settings were first defined when you created the Sensor object using the Add
Sensor Wizard. They include the basic identification settings for the PostOffice
communication service running on the Sensor, the Sensors IP address, and the
version of the IDS software that is running on the Sensor.
To change the identification settings for the Sensor, perform the following steps:
Step 1
Select the Sensor to be configured from the Network Topology folder.
Step 2
Select the Properties tab in the Sensor view panel.
Step 3
Select the Identification tab within the Properties tab.
Step 4
Enter the identification settings in their respective fields.
Step 5
Click OK in the Sensor view panel to accept your changes and close it.
Step 6
Click Update on the toolbar to save your changes and update the configuration
files.
Step 7
Select the Sensor you just modified from the Network Topology folder.
Step 8
Select the Command tab in the Sensor view panel.
Step 9
Click the Approve Now button in the Command Approval section. Wait for the
8-3
Note
Before changing the communications parameters for the Sensor in CSPM, you
must first change them on the Sensor itself using sysconfig-sensor. Failure to do
this will prevent PostOffice communication between the Sensor and CSPM.
The following are the descriptions of the different settings:
8-4
Field
Description
Host Name
Alphanumeric identifier for the Sensor. The

name chosen here is typically one that
contains the word sensor so you can
easily identify that it is a Sensor.
Organization Name
Alphanumeric identifier that furthers

identifies the Sensor. It can be used to
group a number of CIDS devices together
under the same name for easy
identification purposes.
Host ID
Numeric identifier identifying the Sensor.
Organization ID
Numeric identifier that furthers identifies

the Sensor. It can be used to group a
number of CIDS devices together under the
same number for easy identification
purposes.
Sensor Version
The IDS software version running on the

Sensor.
IP Address
IP address of the Sensors command and

control interface.
Comments
Alphanumeric field to enter any user

comments about the Sensor.
Internal Networks
Select
Select the
the
Internal
Internal
Networks
Networks
tab
tab
Select
Select the
the
Sensor
Sensor
Select
Select
Add
Add
Click
Click OK
OK
www.cisco.com
CSIDS 2.18-5
You can designate that specific network IP addresses be considered internal for
reporting and logging purposes by the Sensor. IP addresses that do not match the
internal network definitions are considered to be external IP address. When
alarms are generated by the Sensor, the location of the source and destination IP
addresses of the attack are logged as being either internal (IN) or external (OUT),
to help you easily identify the origin and destination of the attack.
Note
The internal network definition does not affect the intrusion detection capabilities of
the Sensor. If no internal network entries are added, the Sensor logs all alarms as
outside (OUT) to outside (OUT) attacks.
To add internal network definitions for the Sensor, perform the following steps:
Step 1
Step 2
Step 3
Select the Internal Networks tab within the Properties tab.
Step 4
Click Add in the Internal Networks tab to add an IP address line.
Step 5
Enter the network IP address and Subnet Mask in their respective fields.
Step 6
Step 7
files.
Step 8
Select the Sensor you just modified from the Network Topology folder.
Step 9
8-5

Select
Select the
the
Sensor
Sensor
Choose
Choose
Monitoring
Monitoring
Interface
Interface
Select
Select the
the
Sensing
Sensing
tab
tab
Click
Click OK
OK
www.cisco.com
CSIDS 2.18-6
The Packet Capture Device setting is the device name of the monitoring interface
of the Sensor. To change the device name do the following steps:
Step 1
Step 2
Select the Sensing tab in the Sensor view panel.
Step 3
Select the device name for your Sensor from the Packet Device Name drop-down
menu base on the following criteria:
Description
/dev/spwr0
Use with 4220-E and 4230-FE Sensors.
/dev/mtok
Use with 4220-TR Sensors with NICs not

labeled 100/16/4.
/dev/mtok36
Use with 4220-TR Sensors with NICs labeled

100/16/4.
/dev/ptpci0
Use with 4230-SFDDI and 4230-DFDDI

Sensors.
/dev/iprb0
Use with 4210 Sensors.
Note
8-6
A packet capture device does not need to be configured for Catalyst 6000 IDS
Modules within CSPM.
Step 4
Step 5
files.
Step 6
Select the Sensor you just modified from the Network Topology folder again.
Step 7
Step 8
8-7
Log File Configuration

This section discusses how to configure the Sensor to generate log files locally
and how to configure the Sensor to automatically transfer the log files to an FTP
server.
Enabling the Sensor to

Generate Log Files
Select
Select the
the
Sensor
Sensor
Select
Select the
the
Logging
Logging
tab
tab
Enable
Enable
Click
Click OK
OK
www.cisco.com
CSIDS 2.18-8
Sensors can be configured to generate a log file locally on the Sensor itself. By
default the Sensors are configured to send alarms of severity medium and higher
to CSPM. When logging to a local log file, the Sensors log alarms of all severities
generated by that Sensor.
The Sensor creates a new log file every time its services are restarted. This means
that every time a new configuration is pushed to the Sensor, a new configuration
file is created and the old log file is closed and transferred to a temporary
directory. A new log file is also created whenever the active one has been opened
for more than one hour or it has reached 1GB of data.
The followings are the properties of the log file:
Property
Setting
log.YYYYMMDDHHMM
where:
File Name
8-8
YYYY=four digit year
MM=2 digit month
DD=2 digit day
HH=2 digit hour
MM=2 digit minutes
Property
Setting
Active Log File Location
/usr/nr/var
Closed Log File Location
/usr/nr/var/new
To enable the Sensor to generate a local log file do the following:

Step 1
Select the Sensor to be configured from the Network Topology Tree (NTT).
Step 2
Select the Logging tab in the Sensor view panel.
Step 3
Check the Generate audit event log files option in the Logging tab.
Step 4
Step 5
files.
Step 6
Select the Sensor you just modified from the NTT.
Step 7
Step 8
8-9
Configuring Automatic Log

File Transfer
Select
Select the
the
Sensor
Sensor
Select
Select the
the
Logging
Logging
tab
tab
Enter
Enter FTP
FTP
parameters
parameters
Enable
Enable
Click
Click OK
OK
www.cisco.com
CSIDS 2.18-9
You can configure the Sensor to automatically do an FTP transfer of the closed
local log files to a designated FTP server. The FTP transfer is triggered when the
file is closed and moved the /usr/nr/var/new directory on the Sensor.
To configure the Sensor to automatically transfer local log files to an FTP server
do the following:
Step 1
Select the Sensor to be configured from the NTT.
Step 2
Step 3
Check the Generate audit event log files option in the Logging tab.
Step 4
Check the Copy archived event log files option in the Logging tab.
Step 5
Enter the following parameters in their respectively fields:
Target FTP ServerThe IP address of the FTP.
UsernameThe username to use for the FTP connection.
PasswordThe password to use for the FTP connection.
PathDirectory where the log files will be transferred.
Note
8-10
The user must have write access to the default FTP directory on the FTP server.
Step 6
Step 7
files.
Step 8
Step 9
8-11
Advanced Settings Configuration

This section discusses how to configure the following advanced configuration
options on the Sensor: IP fragment reassembly, TCP session reassembly,
advanced PostOffice settings, and additional alarm destinations.
IP Fragment Reassembly
Select
Select the
the
Sensor
Sensor
Select
Select the
the
Sensing
Sensing
tab
tab
Enable
Enable
Click
Click OK
OK
Note
www.cisco.com
CSIDS 2.18-11
IP fragment reassembly is currently available in the 2.2.1.5, 2.5(X), and 2.5(X)

IDSM software versions. This feature requires that at least 64 MB be installed on
the Sensor.
You can specify that the Sensor reassemble fragmented IP packets before they are
compared against intrusion signatures. In other words, you can specify the
boundaries that the Sensor uses to determine how complete a datagram can be in
terms of the reassembly of frames that are transmitted across the physical wire as
part of that datagram.
The ultimate goal for defining the reassembly settings is to ensure that the Sensor
does not allocate all its resources to datagrams that cannot be completely
reconstructed, either because some frame transmissions are missing or because an
attack has been launched that is based on generating random fragmented
datagrams.
Note
8-12
The reassembly settings work in conjunction with each other to ensure that the
Sensor has adequate system resources available to analyze network traffic.
Unless you understand your network traffic thoroughly, including the likelihood of
fragmented datagrams occurring over a specified period of time, we recommend
that you do not modify the default values provided for these settings.
To configure the Sensor to perform IP fragment re-assembly, do the following:

Step 1
Step 2
Step 3
Select the Reassemble Fragments option in the IP Fragment Reassembly section

of the Sensing tab.
Step 4

Parameter
Description
Maximum Partial Datagrams
Maximum number of partial datagrams that

the sensor can attempt to reconstruct at any
given time.
Maximum Fragments Per

Datagram
Maximum number of fragments that can be

accepted for a single datagram.
Maximum Total Fragments
Maximum number of total fragments per

exchange.
Fragmented Datagram
Timeout
Maximum number of seconds that can

transpire before the Sensor stops tracking a
particular exchange for which it is trying to
reassemble a datagram.
Use the following guidelines for determining Maximum Partial Datagrams (MPD)
and Maximum Fragments Per Datagram (MFPD) values:
For Catalyst 6000 IDS modules running the 2.5(X) IDSM software version:
MPD x MFPD 5,000
For Sensors running the 2.2.1.5 or 2.5(X) software versions:

MPD x MFPD 2,000,000
Step 5
Step 6
files.
Step 7
Step 8
Step 9
8-13
TCP Session Reassembly

Select
Select the
the
Sensor
Sensor
Select
Select the
the
Sensing
Sensing
tab
tab
Enter
Enter
Timeout
Timeout
Values
Values
Enable
Enable
Choose
Choose
Reassembly
Reassembly
Type
Type
Note
Click
Click OK
OK
www.cisco.com
CSIDS 2.18-12
TCP session reassembly is currently available in the 2.5(X) IDSM software version.
You can specify that the Sensor reassemble TCP data stream packets before they
are compared against intrusion signatures. Like the IP fragment reassembly
settings, these settings ensure that valuable system resources are not needlessly
reserved for sessions that are no longer active.
There are three options that can be chosen for TCP session reassembly:
No ReassemblyDo not perform TCP session reassembly. The Sensor

immediately processes all packets in a stream. This option is only
recommended in environments with high packet loss. The drawback of this
option is that it permits out of order processing, which can lead to false
positives and false negatives. A false negative means that an event occurs
that the Sensor fails to generate a notification for.
Loose ReasemblyThe Sensor permits sequence gaps when it attempts to

reassemble all packets into a composite session record. This option can lead
to false positives because the session record is incomplete. This option does
ensure that the packets are reassembled in order.
Strict ReassemblyThe Sensor does not process TCP sessions for which it
cannot track every packet in the session's sequence. In other words, if a single
packet of a stream is dropped, the Sensor does not analyze any packets
belonging to that session.
In addition to the above options, you can also configure the Sensor to only track
those sessions for which the three-way handshake is completed. Furthermore, the
TCP open established timeout and TCP embryonic timeout values can be
configured.
8-14
To configure the Sensor to perform TCP session reassembly do the following:

Step 1
Step 2
Step 3
Select the TCP Three Way Handshake box in the TCP Session Reassembly of
the Sensing tab if you want the Sensor to only track those sessions for which the
three-way handshake is completed.
Step 4
Select one of the following options from the TCP Strict Reassembly drop-down
menu: No Reassembly, Loose Reasembly, or Strict Reassembly.
Step 5

Option
Description
TCP Open Establish

Timeout
Specifies the number of seconds that can

transpire before the Sensor frees the
resources allocated to a fully established
TCP session. Default is 90 seconds. Range
is 1 to 120 seconds. (It is recommended that
this value not be set below 30 seconds.)
TCP Embryonic Timeout
Specifies the number of seconds that can

transpire before the Sensor frees the
resources allocated for an initiated, but not
fully established TCP session. Default is 15
seconds. Range is 0 to 15 seconds.
Step 6
Step 7
files.
Step 8
Select the Sensor you just modified from the Network Topology folder again.
Step 9
8-15
PostOffice Settings
Select
Select the
the
Sensor
Sensor
Select
Select the
the
Advanced
Advanced
tab
tab
Select
Select the
the
PostOffice
PostOffice
Settings
Settings tab
tab
Click
Click OK
OK
www.cisco.com
CSIDS 2.18-13
You can configure various advanced PostOffice features to help you customize
communications in your environment. The Watchdog feature in PostOffice
queries the services running on the local host, Sensor or Director, to ensure that
they are running. If Watchdog detects a service is not running, it will issue a
Daemon Down alarm and it will try to restart the service. After it tries to restart
the service a configurable number of times, it then issues a Daemon Unstartable
alarm.
The PostOffice Heartbeat feature queries other PostOffice services on remote
hosts, Sensor or Director, which it must have communication with. If PostOffice
does not get a response from a remote PostOffice service it then issues a Route
Down alarm.
The following are the configurable parameters for the advanced PostOffice
features:
Watchdog IntervalSpecifies how often Watchdog queries the local services

that should be running. Default is 30 seconds.
Watchdog TimeoutSpecifies how long Watchdog waits for a response

from a queried service. If this time is exceeded, a Daemon Down alarm is
issued and PostOffice will try to restart the service. This value must be at
least two times greater than the value specified in the Watchdog Interval box.
Default is 240 seconds.
Number of RestartsSpecifies the number of times that PostOffice will

attempt to restart a downed service. If this value is exceeded, a Daemon
Unstartable alarm is issued. Default is 3 restart for the 4200 series Sensors
and 0 for the IDSM.
Daemon Down Alarm LevelSpecifies the alarm level that PostOffice

generates when a queried service fails to respond to the Watchdog query.
You can specify one of the following values:
8-16
High. (Default)
Medium.
Low.
Daemon Unstartable Alarm LevelSpecifies the alarm level that PostOffice

generates when it fails to restart a downed service the number of times
identified in the Number of Restarts box. You can specify one of the
following values:
High. (Default)
Medium.
Low.
PostOffice Heartbeat IntervalSpecifies how often PostOffice queries a

remote PostOffice that it should be communicating with. If PostOffice does
not receive a response, it issues a Route Down alarm. Default is 5 seconds.
8-17
Additional Destinations
Select
Select the
the
Sensor
Sensor
Select
Select the
the
Advanced
Advanced
tab
tab
Select
Select the
the
Additional
Additional
Destinations
Destinations
tab
tab
Select
Select
Add
Add
Click
Click OK
OK
www.cisco.com
CSIDS 2.18-14
The Sensor can be configured to send its alarms to other locations other than the
main Director it is reporting to. These additional destinations can be services in
other Directors or Sensors, as well as services within the Sensor itself.
To configure the Sensor to send alarms to additional destinations do the
following:
Step 1
Step 2
Select the Advanced tab in the Sensor view panel.
Step 3
Select the Additional Destinations tab within the Advanced tab.
Step 4
Click on Add in the Additional Destinations tab to open a line where you can
enter the following in their respective fields:
Field
Description
Name.Organization
The PostOffice host name and organization

name of the additional destination host.
The format for this setting must be
Hostname.OrgName. Use a dot between the
host name and the organization name. For
example, director.training.
8-18
Host ID
The PostOffice host ID of the additional

destination host.
Organization ID
The PostOffice organization ID of the

additional destination host.
Field
Description
Service
Defines the additional destinations CIDS

service. You can specify one of the following
services to send the alarms to:
smid(Default.) Use this service when

you want to send the alarms to other
Directors to be displayed in the Event
Viewer.
eventdUse this service when you

want to execute user-defined scripts.
This service is only supported in
Directors for UNIX or the 4200 series
Sensors. Eventd itself is not
configurable from CSPM.
loggerdUse this service when you

want to log the alarms locally on the
host to where you are sending the
alarms.
Minimum Alarm Level
Defines the alarm severity level for CIDS

alarms that will be sent to the additional
destination. The severity levels are Low,
Medium, and High. The default value is
Medium.
IP Address
The IP address of the additional destination

host.
Heartbeat Timeout
Defines how often PostOffice queries a

remote PostOffice that it should be
communicating with in seconds. The default
value is 5.
Port
Defines the PostOffice protocol port to

communicate with the additional destination.
The default value is 45000.
8-19
Summary
Summary
The Sensors identification parameters are modified from the
Properties>Identification tabs in CSPM.
The internal network entries indicate to the Sensor what IP addresses are
to considered internal for logging purposes. All other IP addresses will be
considered external for logging purposes.
The packet capture device identifies the device driver for the monitoring
NIC on the Sensor.
Sensors can generate log files and be configured to automatically transfer
the log files to an FTP server.
Sensors can perform IP fragment reassembly to prevent IDS evasion.
Sensors can perform TCP Session reassembly to tune signature triggering
for the users environment.
Advanced PostOffice settings can be tuned to meet the needs of the user
environment.
Sensors can be configured to send alarms to additional destinations.
8-20
www.cisco.com
CSIDS 2.18-15
Lab ExerciseSensor Configuration

Complete the following laboratory exercises to practice what you learned in this
chapter.
Objectives
In this lab you will complete the following tasks:
Define and configure the internal network definition.
Enable the Sensor to generate log files.
Test the log file generation.
Visual Objective
This figure displays the information you will need to complete this laboratory
exercise.

Pod P
Your Pod
Pod Q
Peer Pod
172.30.1.0 /24
e0/1 .10P
sensorP
e0/0 .1
.4
idsmP
sensorQ
e0/0 .1
.4
rQ
rP
.6
10.0.P.0 /24
CSPM
.6
idsmQ
10.0.Q.0 /24
10.0.P.3
CSPM
e0/1 .10Q
10.0.Q.3
www.cisco.com
CSIDS 2.18-17
equipment to do the lab.
Task 1Configure the Sensors Internal Network Definition

Complete the following steps to define an internal network:
Step 1
Select sensorP (where P = pod number) from the Network Topology folder.
8-21
Step 2
Step 3
Select the Internal Networks tab within the Properties tab.
Step 4
Click Add to add a line in the Internal Networks section to enter the IP addresses
to be defined as internal for logging purposes by the Sensor.
Step 5
Enter the following parameters in their respective fields:

Setting
Value
IP Address
10.0.P.0 (where P = pod

number)
Subnet Mask
255.255.255.0
Step 6
Step 7
Click Save on the top toolbar to save your changes.
Task 2Enable the Sensor to Generate Log Files

Complete the following steps to enable the Sensor to generate local log files:
8-22
Step 1
Step 2
Step 3
Select the Generate audit event log files checkbox.
Step 4
Step 5
files.
Step 6
Step 7
Step 8
Step 9
After you get an Upload completed message in the Status section proceed to the
next task.
Task 3Test the Log File Generation

Complete the following steps to verify the Sensor is generating local log files:
Step 1
From your own CSPM host, telnet to your peers router, as assigned by the
instructor, and log on with password cisco. At the router prompt enter the
following:
r0> /etc/shadow
We are simulating an attack in which an attempt is made to retrieve a UNIX

shadowed password file. Your peers Event Viewer will display the new alarm.
Note
Step 2
The router will display an error message. This is expected behavior since the
router does not have an /etc/shadow command.
After your peer attacked your router, telnet to your Sensor as the netrangr user.
SunOS 5.8
login: netrangr
Password:
Last login: Tue Dec 5 11:51:59 from 10.0.0.3
Sun Microsystems Inc. SunOS 5.8
Generic August 2000
You have logged in from 10.0.0.3 using ansi
using DISPLAY=10.0.0.3:0
netrangr@sensor0:/usr/nr
>
Step 3
View your Sensors log files as follows:

netrangr@sensor0:/usr/nr
> cd var
netrangr@sensor0:/usr/nr/var
> ls l *
netrangr@sensor0:/usr/nr/var
> cat log*
2,1000000,2000/12/06,18:02:06,2000/12/06,12:02:06,10000,4,100,Network connect
using connection 1 to destination [3.100]
4,1000001,2000/12/06,18:02:06,2000/12/06,12:02:06,10000,4,100,OUT,OUT,1,996,0,TCP/
IP,0.0.0.0,0.0.0.0,0,0,0.0.0.0,3.100 route 1 up
4,1000002,2000/12/06,18:02:11,2000/12/06,12:02:11,10000,4,100,OUT,OUT,1,0,0,TCP/IP
,0.0.0.0,0.0.0.0,0,0,0.0.0.0,postofficed initial notification msg
4,1000003,2000/12/06,18:02:55,2000/12/06,12:02:55,10008,4,100,OUT,IN,5,8000,2302,T
CP/IP,172.30.1.88,10.0.0.1,1609,23,0.0.0.0,/etc/shadow,2F6574632F736168082F6574632
F736861646F2F6574632F73612F6574632F736861646F77ZZ2F6574632F7361680820082F6574632F7
36861646F
Note
The log file contains binary data and may cause your telnet session to become
unusable.
8-23
Answer the following questions:

Q 1) What is the filename of the most current log file and what time was the log file
created?
__________________________________________________________________
Q 2) What keyword in your log file was used to indicate the location of the source IP
address of the /etc/shadow attack?
__________________________________________________________________
Q 3) What keyword in your log file was used to indicate the location of the destination
IP address of the /etc/shadow attack?
__________________________________________________________________
8-24
Signature and Intrusion

Detection Configuration
Objective
Objectives
Basic signature configuration
Signature templates
Signature filtering
Advanced signature configuration
ACL Signatures configuration
Summary
Lab exercise
Objectives
Objectives
View Signature settings and configure their
severities and actions.
Enable or disable signatures.
Configure connection and string signatures.
Create signature templates and change which one
is used by a Sensor.
Configure the minimum alarm severity level a
Sensor sends to the Director.
9-2
www.cisco.com
CSIDS 2.19-2
Objectives (cont.)
Configure signature filtering to reduce false
positives and tune signature triggering in the user
environment.
Configure signature tuning parameters to
customize triggers for the user environment.
Configure signature port mapping to customize it
for the user environment.
Create ACL signatures that generate alarms when
ACL violations are detected in a Cisco IOS router.
www.cisco.com
CSIDS 2.19-3
Signature and Intrusion Detection Configuration
9-3
Basic Signature Configuration

This section discusses the basic configuration settings of CIDS signatures.
Viewing the Signature Settings
Select
Signature
Template
www.cisco.com
CSIDS 2.19-5
Signature settings can be viewed with CSPM. To view the signature settings
select the signature template under the Sensor Signatures from CSPMs Tools
and Services. The Default signature template includes the signatures detected by
all known CIDS versions. The Sensor Signatures screen has a General tab and a
Signatures tab.
The General tab displays the name and description of the template. The view
properties enable you to view the most current CIDS signatures or only those
signatures applicable to a specified CIDS version.
The Signatures tab displays the CIDS signatures based on the four types:
General
Connection
String
ACL
Note
9-4
Each signature type has its own settings and must be configured from within that
type. For instance to configure a connection signature, you must select the
Connection tab and make the appropriate setting modifications for that signature.
Signature Names and

Severities
www.cisco.com
CSIDS 2.19-6
Each CIDS signature has the following basic settings:
Severity
Enable
Action
Some CIDS signatures have more settings based on the signature type. For
instance, connection signatures have port and protocol type settings.
The default severity for each signature is predefined by Cisco Systems. The
severity can be assigned the following values from the Severity drop-down menu:
Severity Name
Severity Value
Low
Medium
High
The following steps are performed to set the signature severity level using CSPM:
Step 1
Select a Signature template.
Step 2
Select the Signatures tab.
Step 3
Select the signature type.
Step 4
Choose the severity level from the Severity drop-down menu.
Step 5
Click OK in the Sensor view panel.
Step 6
Click Update on the toolbar.
9-5
Enabling and Disabling

Signatures
Enable
Checkbox
Select
Signature
Template
www.cisco.com
CSIDS 2.19-7
Signatures can be enabled or disabled from CSPM. To do this, select or deselect

the Enable checkbox in CSPM to enable or disable the signature. The following
steps are performed to enable or disable a signature using CSPM:
9-6
Step 1
Step 2
Step 3
Step 4
Select the Enable checkbox to enable or deselect the Enable checkbox to disable
the signature.
Step 5
Step 6
Setting Signature Actions
www.cisco.com
CSIDS 2.19-8
Each signature has the ability to take an action when it is detected. CSPM enables
you to select the following signature actions:
Action
Description
None
No action is taken.
Block
Generates an IOS ACL to block traffic from the attacking

host(s).
TCP Reset
Sends a TCP reset to terminate the connection from the

attacking host.
IP Log
Creates a log session of IP traffic after the initial detection

occurs. IP log files are stored on the sensor in
/usr/nr/var/iplog directory.
The following steps are performed to set the signature actions with CSPM:
Step 1
Step 2
Step 3
Step 4
Double-click the signature.
Step 5
Select the actions to take.
Step 6
Click OK in the Signature Actions window.
Step 7
Step 8

Note
You can also change the settings by clicking on the Modify button. A combination
of the Block, TCP Reset, and IP Log actions can be selected.
9-7
Connection Signature Type

and Port Configuration
Select
Signature
Template
TCP or UDP
Port number
www.cisco.com
CSIDS 2.19-9
Connection signatures have the following additional settings:
TypeIP protocol type (TCP or UDP)
PortIANA port number associated with a network service
The following steps are performed to modify connection signature settings with
CSPM:
Step 1
Step 2
Step 3
Select the Connection Signatures tab.
Step 4
Double-click the signature.
Step 5
Choose the protocol type (TCP or UDP) of the port from the Type drop-down
menu.
Step 6
Select the port field and enter the numeric value of the port.
Step 7
Step 8

The same steps are performed to add a connection signature with CSPM except
for Step 4. Substitute the following step:
Step 4
9-8
Click the Add button. Enter a description in the Signature name textbox.
String Signatures
Configuration
Number of
Occurrences
Select
Signature
Template
String pattern
TCP Port
Traffic Direction
www.cisco.com
CSIDS 2.19-10
String signatures have the following additional settings:

Setting
Value
String
The specific characters CIDS is to detect. CIDS uses regular

expression
Port
The number of the TCP service where you want to search for the
string.
Direction
FromCIDS searches for the specific string when it leaves the

specified port. The port is the source.
To CIDS searches for the specific string when it enters the

specified port. The port is the destination.
To & FromCIDS searches for the specific string when it

enters or leaves the specific port.
Occurrences
This setting determines how many times the string has to appear
before an alarm is generated.
The following steps are performed to create a string sub-signature with CSPM:
Step 1
Step 2
Step 3
Select the String Signatures tab.
Step 4
Click Add. A new string sub-signature entry is created.
Step 5
Enter the string you want detected in the String textbox.
Step 6
Select the port field and enter the TCP port number. The default is 21.
Step 7
Choose the direction from the Direction drop-down menu. The default is To.
Step 8
Enter the number of occurrences the string has to appear. The default is 1.
9-9
Step 9
Choose the severity from the Severity drop-down menu. The default is High.
Step 10 Select the signature actions. The default is Block, TCP Reset, IP Log.
Step 11 Click OK in the Sensor view panel.
Step 12 Click Update on the toolbar.
9-10
Signature Templates
This section discusses signature templates in CSPM and how to create a signature
template to be assigned and applied to Sensors.
What is a Signature Template?
Sensor
Signatures
Templates
www.cisco.com
CSIDS 2.19-12
CSPM uses templates to enforce security policies on network devices. CSPM has
a default signature template that contains all known CIDS signatures and their
settings. Signature templates enable the network security administrator to easily
manage, assign, and apply signatures to Sensors. For instance, you could create a
signature template named Business Hours with signature settings that are
optimized for high peak network traffic that occurs during normal business hours.
You could also create a signature template named After Hours with signature
settings that are optimized for network traffic that occurs after 7:00 p.m. You
could easily assign and apply the Business Hours template to your sensors during
high peak hours. You could then easily assign and apply the After Hours template
to your sensors after 7:00 p.m.
9-11
Creating a New Signature

Template
Select
New>Sensor
Signature
Select and
Right Click
Sensor
Signatures
www.cisco.com
CSIDS 2.19-13
CSPM enables you to create signature templates to be assigned and applied to

your Sensors. The newly created template is a duplicate of the default template.
You can then modify the template, and then configure the signature settings for
your network environment. The following steps are performed to create a
signature template in CSPM:
Step 1
Right-click Sensor Signatures.
Step 2
Choose New>Sensor Signature.
Step 3
Check Save on the toolbar.

Note
9-12
CSPM defaults to naming the new template Sensor Signature 1. Rename the
template to reflect its purpose. For example, if a template is created for all Sensors
at the San Antonio site, it could be named San Antonio Texas USA Sensors.
Assigning the Signature

Template Used by the Sensor
www.cisco.com
CSIDS 2.19-14
Each Sensor must be assigned a signature template. CSPM initially assigns the
Default signature template to all Sensors. The following steps are performed to
assign a signature template to a Sensor in CSPM:
Step 1
Select the Sensor from the Network Topology Tree (NTT).
Step 2
Step 3
Choose the template from the Active Configuration drop-down menu.
Step 4
Step 5
9-13
Applying the Signature

Template to the Sensor
Select
Select the
the
Command
Command
tab
tab
Select
Select the
the
Sensor
Sensor
Check
Check for
for
errors
errors
Click
Click Approve
Approve
Now
Now
www.cisco.com
CSIDS 2.19-15
CIDS configuration files generated by CSPM are not pushed to a Sensor until they
are applied. The configuration files generated include Sensor settings and
signature settings associated with the Sensors assigned signature template. The
following steps are performed to apply a signature template to a Sensor in CSPM:
Step 1
Select the Sensor from the NTT.
Step 2
Step 3
Note
You must apply (push) the configuration files each time a configuration change is
made to either the Sensor settings or signature settings.
CSPM has an automatic command approval feature that will push the
configuration files to the Sensor each time an update is executed. The automatic
command approval is beneficial in a large Sensor deployment to avoid having to
manually approve the configurations for each Sensor. The default setting is
Manual. To change the default setting to Automatic, choose Tools>Options.
Select Automatic in the Policy Update Options section, and click OK.
9-14
Signature Filtering
This section discusses the filtering features and settings configurable through
CSPM.
Setting the Minimum Level to

Send to the Director
Select
Select the
the
Sensor
Sensor
Select
Select the
the
Filtering
Filtering
tab
tab
Minimum Event
Level
www.cisco.com
CSIDS 2.19-17
CSPM enables you to configure the minimum event level that will be sent from a
Sensor to the Director. This feature can help reduce the number of alarms CSPM
has to log and display. The following steps are performed to set the minimum
event level the Sensor sends to the Director:
Step 1
Select the sensor from the NTT.
Step 2
Select the Filtering tab in the Sensor view panel.
Step 3
Choose the severity level from the Minimum event level to be sent to the
management console drop-down menu.
Step 4
Step 5
9-15
Simple Signature Filtering
Select
Select the
the
Filtering
Filtering
tab
tab
Select
Select the
the
Sensor
Sensor
Select
Select the
the
Simple
Simple
Filtering
Filtering
tab
tab
www.cisco.com
CSIDS 2.19-18
CSPM enables you to perform simple and advanced signature filtering. Simple
signature filtering excludes a single signature based on a source or destination IP
address or network. The following steps are performed to create a simple
signature filter:
9-16
Step 1
Step 2
Select the Filtering tab in the Sensor view panel.
Step 3
Select the Simple Filtering tab.
Step 4
Click Add. The Create Filter window opens.
Create Simple Filter

Select
Sub-signature
Select Signature
Enter
IP address
and
netmask
Choose
Address
role
www.cisco.com
CSIDS 2.19-19
Step 5
Choose the signature to exclude from the Choose a signature to be excluded list
box.
Step 6
Choose the sub-signature to exclude from the Subsignature to be excluded list

box.
Step 7
Enter the IP address in the IP address field
Step 8
Enter the network mask in the Network Mask field.
Step 9
Select the address role from the Address Role drop-down menu. The address role
can be the source, destination, or both.
Step 10 Click OK in the Create Filter window.

Note
A sub-signature is required for each signature. Select All subsignatures when

selecting a signature that does not have a pre-defined sub-signature.
9-17
Advanced Signature Filtering
Select
Select the
the
Filtering
Filtering
tab
tab
Select
Select the
the
Advanced
Advanced
Filtering
Filtering
tab
tab
Select
Select the
the
Sensor
Sensor
www.cisco.com
CSIDS 2.19-20
The advanced signature filtering feature provides the network security

administrator greater flexibility when excluding signatures. Advanced signature
filtering can exclude signatures
From any IP address
From any internal or external IP address
From a single IP address
From a range of IP addresses
From a IP network
Note
To specify an internal or external IP address, an internal network must be defined.
The following steps are performed to create an advanced signature filter:
9-18
Step 1
Select the sensor from the Network Topology.
Step 2
Select the Filtering tab.
Step 3
Select the Advanced Filtering tab.
Step 4
Create Advanced Filter

Subsignature
Signature
Source
Address
Destination
Address
www.cisco.com
CSIDS 2.19-21
Step 5
Choose one or more to exclude from the Choose one or more signatures to be
excluded list box.
Step 6
Choose the sub-signature to exclude from the Subsignature to be excluded list

box.
Step 7
From the Create Filter window, select an exclude option from the Source Address
group box.
Step 8
From the Create Filter window, select an exclude option from the Destination
Address group box.
Step 9
Click OK from the Create Filter window.

Note
A sub-signature is required for each signature. Select All subsignatures when

selecting a signature that does not have a pre-defined sub-signature.
9-19
Advanced Signature Configuration

Advance signature settings are signature version dependent and are configured per
sensor. Signature tuning and signature port mapping are two advanced signature
setting features.
Signature Tuning
Select
Select the
the
Sensing
Sensing
tab
tab
Select
Select the
the
Sensor
Sensor
Parameter
values
Select
Select the
the
Signature
Signature
Tuning
Tuning
Parameters
Parameters
tab
tab
Parameter
names
Note
www.cisco.com
CSIDS 2.19-23
Signature tuning is currently available in the 2.5(X) IDSM software version.
The signature tuning feature enables you to assign values to the parameters for
common CIDS signatures. For instance, Net Sweep Echo has two configurable
parameters: Expiration and Threshold. The Expiration parameter is the duration in
which CIDS expects the next detection of the signature. The Threshold parameter
is the number of occurrences of the signature that must occur prior to the
expiration before triggering an alarm. You can configure these parameters
according to your network environment and security policy.
The following steps are performed to configure signature tuning:
9-20
Step 1
Select the sensor from the NTT.
Step 2
Select the Sensing tab.
Step 3
Select the Signature Tuning Parameters tab.
Step 4
Double-click the CIDS signature to modify.
Step 5
Modify the new parameter values.
Step 6
Click OK in the Signature Parameter Editor window.
Step 7
Step 8
Signature Port Mapping

Select
Select the
the
Port
Port
Mapping
Mapping
tab
tab
Select
Select the
the
Sensor
Sensor
Select
Select the
the
Sensing
Sensing
tab
tab
Click
Click OK
OK
Note
www.cisco.com
CSIDS 2.19-24
Signature port mapping is currently available in the 2.5(X) IDSM software version.
The signature port mapping feature enables you to assign different port numbers
to signatures that normally detect attacks only on pre-defined ports. For instance,
web signatures normally only analyze web traffic on port 80. The signature port
mapping feature provides you with a mechanism to analyze web traffic on other
ports such as 81, 8080, 8888, thus providing you with more complete coverage.
CIDS has four signature groupings that allow for port mapping:
TCP HIJACK
TCP SYNFLOOD
TCP TELNET
TCP HTTP
WARNING CIDS will not detect attacks launched against ports deleted from a specific
group of signatures.
The following steps are performed to configure signature port mapping:

Step 1
Step 2
Step 3
Select the Port Mapping tab.
Step 4
Add or remove port numbers from a signature group.
Step 5
Step 6
9-21
ACL Signatures Configuration

This section discusses creating and managing ACL signatures.
Creating ACL Signatures

Select
Select the
the
ACL
ACL
Signatures
Signatures
Tab
Tab
Select
Signature
Template
Click
Click OK
OK
Click
Click Add
Add
www.cisco.com
CSIDS 2.19-26
To create ACL signatures you need to
Add the ACL to monitor
Configure the Sensor to monitor syslog messages from the network device
Note
The router must be configured to send syslog messages to the Sensor, and the IP
extended ACL to monitor must be configured to generate syslog messages (e.g.,
access-list 100 deny udp any any log).
The following steps are performed to create the ACL to monitor:
9-22
Step 1
Select the Signature template.
Step 2
Step 3
Select the ACL Signatures tab.
Step 4
Click Add. A new ACL entry is created.
Step 5
Enter the ACL number.
Step 6
Step 7
Defining Syslog Sources

Select
Select the
the
Sensor
Sensor
Click
Click Add
Add
Select
Select the
the
Monitoring
Monitoring
Tab
Tab
Click
Click OK
OK
www.cisco.com
CSIDS 2.19-27
The following steps are performed to configure the Sensor to accept Syslog
messages from network devices:
Step 1
Step 2
Step 3
Select the Monitor tab.
Step 4
Click Add. A new Syslog source entry is created.
Step 5
Enter the IP address and network mask of the network device.
Step 6
Step 7
9-23
Summary
Summary
All signature severities and actions are modified in the signature template
in CSPM.
Signatures can be enabled or disabled.
Connection and string signatures are configured in the signature template
in CSPM.
Many signature templates can be created.
A given signature template is applied to one or many Sensors.
The minimum alarm severity level can be configured on a Sensor to limit
the alarms sent to the Director.
Signature filtering reduces false positives and other undesired alarms.
Signature parameter tuning is used to customize signature triggers in the
user environment.
Signature port mapping is used to customize port to signature settings in
the user environment.
ACL signatures generate alarms when ACL violations are detected in a
Cisco IOS router.
9-24
www.cisco.com
CSIDS 2.19-29
Lab ExerciseSignature Configuration

Objectives
Create a new signature template.
Assign and apply a signature template to the Sensors.
Create a string signature.
Modify signature settings.
Create simple and advanced signature filters.
Visual Objective
The following figure displays the lab topology you will use to complete this
exercise.

Pod P
Your Pod
Pod Q
Peer Pod
172.30.1.0 /24
e0/1 .10P
sensorP
e0/0 .1
.4
idsmP
.6
10.0.P.0 /24
CSPM
e0/0 .1
.4
.6
idsmQ
10.0.Q.0 /24
10.0.P.3
CSPM
sensorQ
rQ
rP
e0/1 .10Q
10.0.Q.3
www.cisco.com
CSIDS 2.19-31
9-25
Task 1Create a New Signature Template

Perform the following steps to create a signature template:
Step 1
Right-click Sensor Signatures and choose New>Sensor Signature.
Step 2
Rename the signature template to My Signatures.
Step 3
Click Save in the toolbar.
Task 2Assign a Signature Template to a Sensor

Perform the following steps to assign the signature template My Signatures to the
Sensor:
Step 1
Select sensorP from the NTT.

Step 2
Click the Sensing tab.
Step 3
Choose the My Signatures template from the Active Configuration drop-down

menu.
Step 4
Step 5
Click Save in the toolbar.
Task 3Apply a Signature Template to a Sensor

Perform the following steps to apply a signature template to the Sensor. You will
need to perform this task every time changes are made to a Sensor or signature
settings.
Step 1

Step 2
Click the Command tab in the Sensor view panel.
Step 3
Task 4Create a String Signature

Perform the following steps to create a custom string signature:
Step 1
Select your Pods signature template My Signatures under Sensor Signatures.
Step 2
Click the Signatures tab.
Step 3
Click the String Signatures tab.
Step 4
Click Add. A new string sub-signature entry is created.
Step 5
Enter the string resetP in the String field.

Step 6
9-26
Enter 23 in the Port field.
Step 7
Accept the default Direction (To), Occurrences (1), Severity (High), and
Action (Block, TCP Reset, IP Log).
Step 8
Click Ok in the Sensor view panel.
Step 9
Click Continue when prompted to save the template.
Step 10 Click Save in the toolbar.
Task 5Modify Signature Settings

Perform the following steps to modify the signature settings.
Signature Name
Signature Type
Severity
Enable
Action
ICMP Echo Request
General
Medium
Enable
None
Connection request - telnet
Connection
High
Enable
None
resetP (where P=pod number)
String
High
Enable
TCP Reset
IIS denial bug
General
High
Enable
IP Log
Step 1
Select your pods signature template, My Signatures.
Step 2
Click the Signatures tab in the right view pane.

Note
Repeat steps 38 for each of the signatures in the table.
Step 3
Click the tab based on the Signature Type.
Step 4
Select the signature.
Step 5
Choose the severity from the drop-down menu
Step 6
Select the Enable status.
Step 7
Double-click the signature Actions.
Step 8
Assign the signature action, and click OK when finished.
Step 9
Click OK from the Sensor view panel.
Step 10 Click Continue when prompted to save the template.

Step 11 Click Update in the toolbar.
Step 12 Apply the configuration files to your pods Sensor.
Step 13 Select sensorP from the NTT.

Step 14 Click the Command tab in the Sensor view panel.
9-27
Task 6Test Signature Settings

Conduct the following tests to confirm that the modifications to the signature
settings are working properly. Your instructor will assign a peer pods number
(Q). The test will be performed against your peers pod to simulate an actual
attack. The attacks should generate alarms on your pods Sensor.
Step 1
Launch the Event viewer.

Test 1: ICMP Echo Request
Step 2
Ping your peers router from your CSPM host.

c:> ping 10.0.Q.1
(where Q = peer pod number)

Q 1) What alarm was generated on your Sensor?
A)
Q 2) What IP address or addresses was the source and why?
A)
Test 2: Connection request - telnet
Step 3
Telnet to your peers router from your CSPM host.

c:> telnet 10.0.Q.1

A)
Test 3: resetP string signature
Step 4
Step 5
At the router prompt, enter the string resetQ.

rQ> resetQ

A)
Q 5) What action did you notice?
A)
Q 6) What triggered the action?
A)
Test 4: IIS .. denial bug
Step 6
9-28
Launch Internet Explorer from your CSPM host.
Step 7
Enter the following string in your web browser:

http://10.0.Q.3/../..

Step 8
Step 9
A)
At the router prompt, enter the string /etc/passwd. You will receive an error
message because this is not a valid router command.
r0> /etc/passwd
Step 10 Telnet to your Sensor and log in as netrangr with password attack.
c:> telnet 10.0.P.4

Step 11 Change directories to the IP log directory:
> cd /usr/nr/var/iplog
Step 12 Verify that an IP log file was created:

!
ls -l iplog.10.0.Q.3*

Q 8) When was the IP log file created?
A)
Q 9) What IP address caused the IP log to be created?
A)
Task 7Create a Simple Signature Filter

Perform the following steps to create a simple signature filter. The filter will
exclude the resetP string signature from your peer pods laptop. Your instructor
will assign a peers pod number (Q).
Step 1

Step 2
Click the Filtering tab in the Sensor view panel.
Step 3
Click the Simple Filtering tab.
Step 4
Step 5
Choose String Signatures from the list of signatures.
Step 6
Select resetP from the list of sub-signatures.

Step 7
Enter the IP address and network mask of your peer pods laptop: 10.0.Q.3.
Step 8
Choose Source Address from the Address Role drop-down menu.
9-29
Step 9
Click OK in the Create Filter window.

Step 11 Click Update in the toolbar.

Task 8Test the Simple Signature Filter

Perform the following steps to confirm that the simple signature filter created is
working properly. Your instructor will assign a peers pod number (Q). The test
will be performed against your peers pod to simulate an actual attack. The attacks
should not generate alarms on your pods Sensor.
Step 1
Launch the Event Viewer.
Step 2
Telnet to your peers router (10.0.Q.1) from your CSPM host.

Step 3
Enter the string resetQ at the router prompt.
Q 10) Was an alarm generated from your peer?

A)
Q 11) Was an action taken?
A)
Task 9Create an Advanced Signature Filter

Perform the following steps to create an advanced signature filter. The filter will
exclude all alarms generated from your peer pods laptop.
Step 1

9-30
Step 2
Click the Filtering tab in the Sensor view panel.
Step 3
Click the Advanced Filtering tab.
Step 4
Step 5
Choose all of the signatures to exclude from the Signature list. To choose all of
the signatures, choose the first signature, scroll down to the last signature, press
the Shift key, and choose the last signature.
Step 6
Choose All subsignatures from the Sub-signature list.
Step 7
Select Exclude alarms from a single IP address from the Source Address group
box. A field to enter an IP address appears. Enter the IP address of your peer
pods laptop, 10.0.Q.3, as assigned by your instructor.
Step 8
Select Exclude alarms to any IP address from the Destination Address group
box.
Step 9
Click OK in the Create Filter window.

Step 11 Click Update from the toolbar.

Task 10Test the Advanced Signature Filter

Perform the following steps to confirm that the advanced signature filter created is
working properly. Your instructor will assign a peers pod number (Q). The test
will be performed against your peers pod to simulate an actual attack. The attacks
should not generate alarms on your pods Sensor.
Step 1
Launch the Event Viewer.

Test 1: ICMP Echo Request
Step 2
Ping your peers router from your CSPM host.

c:> ping 10.0.Q.1

Test 2: Connection Request - Telnet
Step 3

c:> telnet 10.0.Q.1

Test 3: IIS .. denial bug
Step 4
Launch Internet Explorer from your CSPM host.
Step 5

http://10.0.Q.3/../..

Q 12) Were any alarms generated from your peer for Tests 1-3?
A)
9-31
10
IP Blocking
Configuration
Overview
This chapter describes how to configure the IP Blocking capability on a Sensor
and how IP blocking is used. In addition, it explains considerations you need to
make before you select the interface on which to apply the blocking access control
lists (ACLs).
Objectives
Introduction
ACL placement considerations
Configuring a Sensor for IP Blocking
Summary
Lab exercise
Objectives
Objectives
Describe the Device Management capability of the
Sensor and how it is used to perform IP blocking
with a Cisco IOS router.
Design IP blocking into an IDS solution including
the ACL placement considerations when deciding
where to apply Sensor generated ACLs.
Configure a Sensor with Device Management,
which enables the IP Blocking capability.
Configure a Sensor to perform IP blocking through
a Master Blocking Sensor.
10-2
www.cisco.com
CSIDS 2.110-2
Introduction
This section explains what Device Management is and how to use it.
Definitions
Device ManagementThe ability of a Sensor to

interact with Cisco IOS routers and
dynamically reconfigure the routers ACL to
stop an attack.
IP blockingDevice Management is used to
implement the IP blocking feature of the
Sensor.
www.cisco.com
CSIDS 2.110-4
Device management refers to the Sensors ability to dynamically reconfigure a

Cisco IOS routers Access Control Lists (ACLs) to block the source of an attack
in real time. The Sensor telnets to the router through its command and control
interface to manage its ACL. This is how the IP blocking capability is
implemented on the Sensor.
ACLs are part of the Cisco IOS architecture and tie a control list to physical
interfaces within the router. The ACLs permit or deny the passage of data packets
through those physical interface ports. Each numbered ACL contains permit and
deny conditions that apply to IP addresses.
The default IP extended ACL used by the Sensor is 199. When a new ACL needs
to be written, the Sensor builds a new IP extended ACL numbered 198. It then
replaces 199 with 198. The next time an ACL needs to be written, the Sensor then
replaces the 198 ACL with a 199 ACL, and so on. The new ACL is not applied to
the interface until the ACL has been written. Consequently, the previous ACL
applied by the Sensor remains active. This approach allows for a more protected
environment because it never leaves the network unprotected while an ACL is
being rewritten.
IP Blocking Configuration
10-3
Device Management
Requirements
Cisco IOS router series
1600, 2500, 2600, 3600, 4500, 4700, 7200, and
7500
Sensor must be able to communicate with the
router.
Router must be configured to allow telnet
access from the Sensor.
VTY access
Enable password set
www.cisco.com
CSIDS 2.110-5
The following is the list of routers that have been approved and tested to work
with the Sensors and Device Management:
1600
2500
2600
3600
4500
4700
7200
7500
The Sensor must be able to communicate with the router. The Sensor must have a
route to or exist on the same subnet as the managed router. For the Sensor to
effectively defend a network using a Cisco IOS router, you must enable Telnet on
the router so that the Sensor can access it by
10-4
Configuring the appropriate vty lines.
Setting the enable password.
IP Blocking Guidelines
Implement anti-spoofing mechanisms.
Identify hosts that are to be excluded from
blocking.
Identify network entry points that will
participate in blocking.
Block signatures that are deemed as an
immediate threat.
Determine the appropriate blocking duration.
www.cisco.com
CSIDS 2.110-6
The CIDS IP blocking feature is a powerful feature that must be used after well
thought-out planning. The IP blocking feature generates ACLs based solely on the
IP addresses of the hosts that generate the alarms. CIDS will not determine
whether or not the attacking host should be considered a friend or foe.
Consequently, it is quite possible that the IP blocking feature will block legitimate
network traffic. Some key points to remember when designing and implementing
IP blocking are the following:
Anti-spoofing mechanismsAttackers will forge packets with IP addresses

that are either private addresses (RFC 1918) or addresses of your internal
network. The attackers goal is to have CIDS block valid IP addresses thus
causing a denial of service. By implementing proper anti-spoofing
mechanism and network ingress filtering (RFC 2827), CIDS will not block
possible valid addresses.
Critical hostsEach network has critical hosts that should not be blocked. It
is important to identify these hosts to prevent possible network disruptions.
Entry pointsTodays networks have several entry points to provide for

reliability, redundancy, and resilience. These entry points are also different
avenues for the attacker to attack your network. It is important to identify all
of the entry points and decide if they should also participate in Blocking.
Signature selectionCIDS contains several hundred signatures that can be

configured to perform IP blocking. It is not feasible to perform blocking on
all signatures. Identify which CIDS signatures are best suited to perform IP
blocking. For example, if you were only allowing Web traffic to your server
farm, you would identify CIDS web related signatures specific to your Web
server software. From this list of signatures, you would then identify those
signatures whose severity is High and could potentially lead to access. These
signatures would be candidates to perform IP blocking.
Blocking durationBy default CIDS will perform automatic blocking for 30

minutes. Determine the appropriate time for your network environment.
10-5
IP Blocking at the Router

172.26.26.2
10.0.0.10
Deny
172.26.26.2
Protected
network
Attack
Untrusted
network
Write the ACL
Detect the attack
www.cisco.com
CSIDS 2.110-7
The following steps describe the IP blocking process:
10-6
Step 1
An attack starts when an attacker executes a hack to gain access to the protected
network.
Step 2
The Sensor detects the attack and sends an alarm to the Director.
Step 3
At the same time, the Sensor automatically writes a new ACL on the managed
router denying traffic from the attacking host. The managed router will then deny
any future traffic generated by the attacking host until the Block is manually
removed or the default Block time expires.
Master Blocking Sensors
Attacker
Provider
Y
Provider
X
Sensor
Sensor A
A
blocks
blocks
Sensor
Sensor B
B
blocks
blocks
Sensor B
Sensor A
...
Protected
network
Sensor
Sensor A
A
commands
commands
Sensor
Sensor B
B
to
to block
block
Victim
www.cisco.com
CSIDS 2.110-8
In some configurations it is necessary to have a proxy Sensor perform the IP

blocking action for another Sensor on your network. These proxy Sensors are
referred to as Master Blocking Sensors.
An example of the use of master blocking Sensors is illustrated in the preceding
figure. It represents a scenario where a network has two entry points from two
different providers: provider X and provider Y. Each of the entry points has a
Sensor configured for device management with the router or the provider on that
entry point. When an attempt to penetrate a host in the protected is detected by
Sensor A then Sensor A blocks the attack at the Provider X router. If Sensor A has
not been configured to use a Master Blocking Sensor, then the Provider Y access
would still be seen and the attacker could try to come into the protected network
through that route.
A savvy network security administrator can configure Sensor A to command
Sensor B to block the in Provider Xs router. In this scenario Sensor B becomes a
master blocking Sensor for Sensor A. For better security Sensor B should also be
configured to use Sensor A as a master blocking Sensor.
10-7
ACL Placement Considerations

This section describes the considerations you should make before applying ACLs.
Where to Apply ACLs

Untrusted
network
External
interfaces
Inbound
ACL
Internal
interfaces
Outbound
ACL
The Sensor has full

controlNo manually
entered ACLs allowed
External interface
Apply on inbound
direction
Internal interfaceApply
on outbound direction
Protected
network
www.cisco.com
CSIDS 2.110-10
You must decide which interface and in what direction to apply the ACL. The
ACL may be applied on either the external or internal interface of the router. It
can also be configured for inbound or outbound on either interface.
Also consider that the Sensor must have full control of the assigned interface
ACL. Manually entered ACLs are not allowed on this interface, but may be
applied to other interfaces.
10-8
Applying ACLs on the External

vs. Internal Interfaces
Applying external on the
interface
Applying the internal

interface
Denies host before it

enters the router
Provides the best
protection against an
attacker
The shun does not

apply to router itself
User-defined ACLs
applied to external
interface
User-defined ACLs
applied to internal
interface
Denies the host before

it enters the protected
network
www.cisco.com
CSIDS 2.110-11
Applying the ACL to the external interface in the inward direction denies a host
access before packets are processed by the router. Applying the ACL to the
internal interface in the outward direction denies a host access to the protected
network, but allows packets to be processed by the router. This scenario is less
desirable, but may be required if outside inward ACLs are already used.
You must decide, based on your unique network architecture, which configuration
will meet your needs for security and functionality.
10-9
Configuring a Sensor for IP Blocking

This section covers how to configure a Sensor to perform IP blocking.
Setting the Blocking

Properties
www.cisco.com
CSIDS 2.110-13
To specify the Sensors IP Blocking properties, perform the following steps:

Step 4
Select the Sensor to be configured from the Network Topology Tree (NTT).
Step 5
Select the Blocking tab in the Sensor view panel.
Step 6
Enter the block duration, which is the amount of time the block will remain active
before the ACL entry will be removed.
Step 7
Enter the Cisco extended ACL number that will be used by the Sensor when
writing an ACL. The default value is 199.
Note
10-10
Cisco IDS will switch between the Cisco ACL number and one less the defined
number. For instance, if the Cisco ACL number defined is 184, Cisco IDS will use
183 and 184 when writing ACLs.
Blocking Device
www.cisco.com
CSIDS 2.110-14
To specify the information about the Cisco IOS router that the Sensor will use to
block detected attacks, perform the following steps:
Step 1
Step 2
Step 3
Select the Blocking Devices tab within the Blocking tab.
Step 4
Click Add to open the Blocking Device Properties windows and configure the
properties for IP blocking.
10-11
Blocking Device Properties

Enter
Enter the
the
routers
routers Telnet
Telnet
IP
IP address
address
Enter
Enter the
the
routers
routers enable
enable
password
password
Enter
Enter the
the
routers
routers Telnet
Telnet
username
username
Enter
Enter the
the
routers
routers Telnet
Telnet
password
password
Choose
Choose the
the
Interface
Interface
Direction
Direction
Enter
Enter the
the
Interface
Interface Name
Name
Step 5
www.cisco.com
CSIDS 2.110-15
Telnet IP AddressThe routers IP address that the Sensor telnets to.
Telnet UsernameUsername the Sensor uses to telnet to the router. Leave

blank if no username is required by the router.
Telnet PasswordRouters password the Sensor uses to telnet to the router

or the Usernames password.
Enable PasswordThe password for the routers enable mode.
Step 6
Click Add to add a line in the Blocking Interfaces section, which adds the router
interface or interfaces where the ACLs will be applied.
Step 7
Note
Interface NameThe interface on the router that ACLs are to be applied to

(for example, Ethernet0, eth0, e0, serial0, s0, and so on).
Do not add a space between the interface name and the interface number.
Interface DirectionThe direction on the routers interface to which the

ACLs are to be applied (Inbound or Outbound).
Step 8
Click Add again in the Blocking Interfaces section to add another router interface
definition. If no more interfaces need to be defined, then go to the next step.
Step 9
Click OK in the Blocking Device Properties window to accept your.
Step 10 Click OK in the Sensor view panel to accept your changes.

Step 11 Click Save on the top toolbar to save your changes.
10-12
Setting Never Block

Addresses
www.cisco.com
CSIDS 2.110-16
CIDS enables you to set IP addresses of hosts or networks that will never be
blocked. The Sensor adds permit statements for these addresses in the ACL. To
specify IP addresses that the Sensor will never block, perform the following steps:
Step 1
Step 2
Step 3
Select the Never Block Addresses tab within the Blocking tab.
Step 4
Click Add to add a line in the Never Block Addresses window tab, which adds an
IP address.
Step 5
IP AddressThe IP address that will never be blocked.
Subnet MaskThe network mask for the IP address
Step 6
Click Add again in the Never Block Addresses tab to add another IP address to
never block. If no more IP addresses need to be defined, then go to the next step.
Step 7
Click OK in the Sensor view panel to accept your changes.
Step 8

Note
The IP address of the sensor will automatically be added as a Never Block

Address to the configuration files. The IDS software will not block the CSPM host.
You may also include IP addresses of critical hosts.
10-13
Blocking Through a Master

Blocking Sensor
www.cisco.com
CSIDS 2.110-17
To specify the information about the Master Blocking Sensor that the Sensor will
use to block detected attacks, perform the following steps:
Step 1
Step 2
Step 3
Select the Master Blocking Sensor tab within the Blocking tab.
Step 4
Click Add to open the Blocking Sensor Selection window and select the Master
Blocking Sensor.
Step 5
Select the Sensor name, which you want to make the Master Blocking Sensor,
from the list and click OK.
Step 6
Click OK in the Sensor view panel to accept your changes and.
Step 7

Note
10-14
The Master Blocking sensor must exist in the CSPM network topology and be
configured to perform IP blocking.
Event Viewer and IP Blocking

This section discusses how to use the Event Viewer to view blocked hosts and
networks and also perform a manual block.
Viewing the List of Blocked IP

Addresses
Choose
Choose
View>Block
View>Block List
List
Select
Select the
the
Sensor
Sensor
IP
IP address
address
Time
Time
remaining
remaining
or
or
Select
Select the
the
alarm
alarm
generated
generated by
by
the
the Sensor
Sensor
www.cisco.com
CSIDS 2.110-19
To view the list of IP addresses being blocked by a Sensor, as well as the time
remaining for that IP address on the block list, perform the following steps:
Step 1
On the Event Viewer select the Sensor on the Connection Status Pane or select an
alarm generated by that Sensor.
Step 2
Choose View>Block List from the Event Viewer menu. A window showing the
list of blocked IP addresses and the time remaining before they are removed from
the block list opens.
10-15
Viewing the Managed Network

Device
Choose
Choose
View>Network
View>Network
Device
Device
Current
Current
Time
Time
Select
Select the
the
Sensor
Sensor
or
or
Select
Select the
the
alarm
alarm
generated
generated by
by
the
the Sensor
Sensor
IP
IP address
address
Version
Version
www.cisco.com
Status
Status
Type
Type
CSIDS 2.110-20
To view the list of network devices managed by a Sensor and device information,
perform the following steps:
10-16
Step 1
Step 2
Choose View>Network Device from the Event Viewer menu. The Network
Device window opens displaying the managed device(s) and the devices current
time, status, type, and software version opens.
Manual Blocking a Host or

Network
Choose
Choose
Actions>Block>
Actions>Block>
Select
Select the
the
alarm
alarm
generated
generated by
by
the
the Sensor
Sensor
IP
IP address
address
Block
Block
Duration
Duration
www.cisco.com
CSIDS 2.110-21
To block a host or network manually, perform the following steps:

Step 1
On the Event Viewer select an alarm generated by that Sensor.
Step 2
Choose Actions>Block>Host or Actions>Block>Network from the Event

Viewer menu. The Shunning Hosts window opens displaying the status of the
block command.
10-17
Removing the Blocked Host

or Network
Choose
Choose
Actions>Remove
Actions>Remove
Block>
Block>
Select
Select the
the
Sensor
Sensor
or
or
Select
Select the
the
alarm
alarm
generated
generated by
by
the
the Sensor
Sensor
IP
IP address
address
www.cisco.com
CSIDS 2.110-22
To remove a host, network, or all devices being blocked by a Sensor perform the
following steps:
10-18
Step 1
Step 2
Choose Actions>Remove Block>Host, or Actions>Remove Block>Network, or

Actions>Remove Block>All from the Event Viewer menu. The Removing Shun
of Hosts window opens displaying the status of the remove block command.
Summary
Summary
Device management is the Sensors ability to
dynamically reconfigure a Cisco IOS routers
ACLs to block the source of an attack in real
time.
Guidelines for designing an IDS solution with
IP blocking includes the following:
Implement an anti-spoofing mechanism.
Identify critical hosts and network entry
points.
Select applicable signatures.
Determine blocking duration.
www.cisco.com
CSIDS 2.110-24
10-19
Summary (cont.)
CIDS Sensors can serve as a master blocking
server.
The ACLs may be applied on either the
external or internal interface of the router, and
can also be configured for inbound or
outbound on either interface.
The Sensor IP blocking feature is configured
from the Blocking tab in CSPM.
From CSPMs Event Viewer, you can view or
remove blocked hosts, and perform manual IP
blocking.
10-20
www.cisco.com
CSIDS 2.110-25
Lab ExerciseConfiguring IP Blocking

Objectives
Configure your Sensor to perform IP blocking.
Create a string match signature with action IP blocking.
Trigger the string match signature.
View a list of blocked hosts.
Remove blocked hosts and networks.
Visual Objective
This figure displays the information you will need to complete this lab exercise.

Pod P
Your Pod
Pod Q
Peer Pod
172.30.1.0 /24
e0/1 .10P
sensorP
e0/0 .1
.4
idsmP
sensorQ
e0/0 .1
.4
rQ
rP
.6
10.0.P.0 /24
CSPM
.6
idsmQ
10.0.Q.0 /24
10.0.P.3
CSPM
e0/1 .10Q
10.0.Q.3
www.cisco.com
CSIDS 2.110-27
equipment to complete the lab exercise.
Task 1Configure the Sensor to Perform IP Blocking

Complete the following steps to configure a sensor to perform IP blocking:
10-21
Step 1
Select sensorP from the Network Topology Tree (NTT).

Step 2
Step 3
Select the Blocking Devices tab within the Blocking tab.
Step 4
Click Add to open the Blocking Device Properties window and configure the
properties for IP blocking.
Step 5

Setting
Value
Telnet IP Address
Telnet Username
Leave blank
Telnet Password
cisco
Enable Password
cisco
Interface Name
Ethernet0/1
Interface Direction
Inbound
Note
Do not add a space between the interface name and the interface number.
Step 6
Click OK in the Blocking Device Properties window.
Step 7
Click OK in the Sensor view panel to accept your changes.
Step 8
Task 2Create a String Match Signature with IP Blocking

Response
Complete the following steps to create a string signature that when triggered will
respond with a block command:
10-22
Step 1
Select My Signatures from the Sensor Signatures folder.
Step 2
Select the Signatures tab in the Signatures view panel.
Step 3
Select the String Signatures tab within the Signatures tab.
Step 4
Click Add to create a string signature entry.
Step 5

Setting
Value
String
blockP (where P = pod number)
Port
23 (Telnet)
Direction
Keep the default of To
Occurrences
Keep the default of 1
Severity
Keep the default of High
Enable
Keep the default of checked
Setting
Value
Actions
Select Block only, and deselect TCP Reset

and IP Log
Comment
string match for block
Step 6
Click OK in the Signatures view panel to accept your changes.
Step 7
files.
Step 8
Click Continue in the Save Template window.
Step 9



Step 12 After you get an Upload completed message in the Status section, proceed to the
next task.
Task 3Trigger the String Match Signature

Complete the following steps to trigger the string signature:
Step 1
From your own CSPM host, telnet to your peers router as assigned by the
instructor and log on with the password cisco.
Step 2
At the router prompt enter the following:

r0> blockQ
(where Q = peers pod number)

Your peers Event Viewer displays the new alarm and your session is blocked.
Your session will hang and no input is allowed.
Note
The block may take a few seconds to occur.
Step 3
To get out of the hung connection, close your Telnet client.
Step 4
Attempt to telnet to your peers router to confirm the block was successful.
Task 4Perform a manual block

Complete the following steps to perform a manual block on a network as assigned
by the instructor.
Step 1
Choose Actions>Block >Network from the Event Viewer menu. The Shunning
of Hosts window opens showing the status of the block command.
Task 5View a List of Blocked Hosts

Complete the following steps to view a list of block hosts:
10-23
Step 1
After your peer triggers your string match signature go to your Event Viewer and
select the alarm that was triggered.
Step 2
Choose View>Block List from the Event Viewer menu. The Shun List window
opens.
Q 1) What are the IP addresses of the hosts or network address being blocked?
A)
Q 2) How much time is remaining before the block will be automatically removed for
each host or network?
A)
Step 3
Click OK to close the window.
Task 6Remove the block

Complete the following steps to remove the block on all hosts.
10-24
Step 1
Choose Actions>Remove Block >All from the Event Viewer menu. The
Removing Shun of Hosts window opens.
Step 2
Click OK to close the window.
11
Catalyst 6000 Intrusion

Detection System
Module Configuration
Overview
This chapter covers information on the Catalyst 6000 IDS Module (IDSM) and
how to configure it for intrusion detection.
Objectives
Catalyst 6000 IDSM introduction
Catalyst 6000 IDSM ports and traffic
Initializing the Catalyst 6000 IDSM
Configuring the switch for ID analysis
Verifying the configuration
Adding the Catalyst 6000 IDSM to CSPM
Updating IDSM components
Troubleshooting
Summary
Lab exercise
Objectives
Objectives
Describe the Catalyst 6000 IDS Module
features.
List the two methods of capturing network
traffic for analysis by the Catalyst 6000 IDS
Module.
Initialize a Catalyst 6000 IDS Module.
11-2
www.cisco.com
CSIDS 2.111-2
Objectives (cont.)
Configure Catalyst 6000 switch for ID analysis.

Verify the Catalyst 6000 switch and Catalyst
6000 IDSM configurations.
Add a Catalyst 6000 IDSM to CSPM.
Update Catalyst 6000 IDSM partition images,
service packs, and signatures.
www.cisco.com
CSIDS 2.111-3
Catalyst 6000 Intrusion Detection System Module Configuration
11-3
Catalyst 6000 IDSM Introduction

This section introduces the Catalyst 6000 IDS Module.

Product number
WS-X6381-IDS
Physical dimensions
Height: 3.0 cm
(1.2 inches)
Width: 35.6 cm
(14.4 inches)
Depth: 40.6 cm
(16 inches)
Weight 2.27 kg
(5 lbs.)
www.cisco.com
CSIDS 2.111-5
The Catalyst 6000 Intrusion Detection System Module (IDSM) is a switch line
card designed specifically to address switched environments by integrating the
IDS functionality directly into the switch and taking traffic right off the switch
backplane, thus bringing both switching and security functionality into the same
chassis.
11-4
IDSM Key Features

Brings switching and security into a single
chassis
Ability to monitor multiple VLANs
simultaneously
Does not impact switch performance
Attacks and signatures detected parallel the
4200 Appliance Sensor series
www.cisco.com
CSIDS 2.111-6
The Catalyst 6000 IDSM capabilities offers network and security administrators
the ability to overcome issues in switched environments. In switched network
environments, traffic must be copied to a monitoring port to capture traffic for
Intrusion Detection analysis. This SPAN feature is limited to the number of ports
and VLANs that can be captured. The Catalyst 6000 IDSM overcomes this
limitation by capturing traffic off the switch backplane using the Catalyst
Operation System (OS) VLAN ACL (VACL) feature. Performance is not affected
because the Catalyst 6000 IDSM is not in the switch-forwarding path.
The Catalyst 6000 IDSM is an integral part of the CIDS family of products. The
attacks and signatures detected parallels the 4200 appliance Sensor series.
11-5
Feature Comparison
IDSM Appliance
Multi-VLAN Traffic Capturing
Yes
No
IP Blocking
No
SwitchesNo
RoutersYes
IP Logging
No
Yes
String Matching
Yes
Yes
IPSec Secure Communications No
Yes
Signature Tuning Parameters
Yes
No
Yes
No
www.cisco.com
CSIDS 2.111-7
The Catalyst 6000 IDSM and traditional appliance Sensor feature comparisons are
as follows:
11-6
The monitoring port for the Catalyst 6000 IDSM is by default a trunking
port, thus allowing for visibility of traffic from multiple VLANs.
The Sensor appliance has the ability to create Cisco IOS router ACLs to
block malicious activity.
The Sensor appliance can capture associated network traffic from a specific
IP address after a predefined attack is detected.
Both the IDSM and appliance Sensor enable you to create custom string
signatures.
The Sensor appliance can be managed securely with IPSec.
Various Catalyst 6000 IDSM signature parameters can be configured to

enable the security administrator to tune signature triggers. For example, you
could set the number of ICMP echo requests to 10 before the ICMP Echo
Request alarm triggers.
The Catalyst 6000 IDSM has the flexibility of associating several ports with
signatures or a specific network service. This feature provides a broader
range of coverage to detect protocol specific attacks. For instance, HTTP
(Web) traffic occurs by default on port 80. Other HTTP ports often seen on
the Internet are 81, 82, 88, 8080, and 8888. By associating all these ports
with HTTP, HTTP attacks against these non-standard ports can be detected.
Catalyst 6000 Switch

Requirements
The Catalyst 6000 IDSM has the following
Catalyst 6000 Family switch requirements:
Catalyst OS 6.1(1) or higher
PFC required for VLAN ACL capture
functionality
Compatible with Supervisor 1A and
Supervisor 2 engines
Compatible with both MSFC and MSFC2 (not
required)
www.cisco.com
CSIDS 2.111-8
The Catalyst 6000 IDSM has the following Catalyst 6000 Family switch
requirements:
Catalyst OS 6.1(1) or higher. Cannot run CAT IOS on Supervisor module.
Policy Feature Card (PFC) for VACL capture feature functionality
Supervisor 1A or 2
Multi-layer Switch Feature Card (MSFC) and MSFC2 (optional)
11-7
Catalyst 6000 IDSM Ports and Traffic

This section discusses the ports on the Catalyst 6000 IDSM and how traffic is
captured for Intrusion Detection analysis.
IDSM Ports
IDSM contains the following two ports:
Monitoring port
Defined as port 1 on the module
Set as a trunking port
Assigned as the destination capture port
Command and control port
Defined as port 2 on the module
Communicates with CSPM
Assigned an IP address
www.cisco.com
CSIDS 2.111-10
The Catalyst 6000 IDSM has two ports:
Port 1 is for monitoring the network for attacks. By default Port 1 is a

trunking port and assigned as the destination capture port for VLAN ACLs.
Port 2 is the command and control port used to communicate with the
Director software. Port 2 is assigned an IP address during the initial IDSM
setup.
Note
11-8
The IDSM ports are not physically visible.
Capturing Traffic
IDSM can monitor ~100 Mbps of traffic

Traffic is captured off the switch backplane
There are two methods of capturing traffic
using the following switch features:
SPAN feature
VACLs feature
www.cisco.com
CSIDS 2.111-11
The Catalyst 6000 IDSM can monitor 100Mbps of network traffic. Network
traffic is captured off the switch backplane and analyzed by the IDSM. The two
methods of capturing traffic depend on the features on the Catalyst 6000 switch.
Switches with a Policy Feature Card (PFC) can use the VLAN ACL feature. All
switches can use the Switch Port Analyzer (SPAN) feature.
11-9
IDSM Traffic Flow

Cisco Catalyst 6000
Destination
traffic
Source traffic
Destination
traffic
Source traffic
Switch
backplane
Copied VACL or
SPAN traffic to
IDSM monitor port
IDSM
Alarms and configuration
through IDSM command
and control port
CSPM
www.cisco.com
CSIDS 2.111-12
The traffic flow is an important aspect of understanding how the IDSM captures
and analyzes network traffic. The Catalyst 6000 switch must first be configured to
capture traffic for Intrusion Detection analysis. If this is not done, IDSM will
never have visibility into the network traffic.
Traffic enters the Catalyst 6000 switch destined for a host or network. The traffic
is captured off the switch backplane and sent to the IDSM. The IDSM performs
Intrusion Detection analysis and performs the defined actions. These actions
include sending alarms and commands to Cisco Secure Policy Manager (CSPM).
11-10
Capturing Traffic
with SPAN Ports
SPAN mirrors traffic from one or more source
ports from any VLAN, or from one or more
VLANs to a destination port
SPAN limitations
Four transmit sessions (tx)
Two receive sessions (rx) or both (rx and tx)
Can only monitor Ethernet 10, 100, 1000
Mbps ports
www.cisco.com
CSIDS 2.111-13
The Switch Port Analyzer (SPAN) feature is one method of capturing network
traffic for Intrusion Detection analysis. SPAN mirrors traffic from one or more
source ports on any VLAN, or from one or more VLANs to a destination port for
analysis.
The following are three methods of deploying the SPAN feature:
Ingress SPAN copies network traffic received (rx) by the source ports for
analysis at the destination port.
Egress SPAN copies network traffic transmitted (tx) from the source ports for
analysis at the destination port.
VLAN-based SPAN (VSPAN) is analysis of the network traffic in one or

more VLANs. You can configure VSPAN as ingress SPAN, egress SPAN, or
both.
A SPAN session is an association of a destination port with a set of source ports,

configured with parameters that specify the monitored network traffic. The
number of SPAN sessions allowed is limited based on the method of SPAN
deployed, as represented by the following table. The table represents the SPAN
session limits on the Catalyst 6000 Family switches.
SPAN Session
Number of Sessions
rx or both
tx
The SPAN feature is also limited to the type of network traffic that can be
captured. It currently works with only Ethernet 10/100/1000 Mbps ports.
11-11
Capturing Traffic with VACLs

Requires PFC
Can capture only permitted traffic
Can permit traffic for intrusion detection
analysis by
Source and destination IP addresses
Source and destination ports
Combination of IP addresses and ports
Only one VACL can be mapped to a single
VLAN
A VACL can be mapped to multiple VLANs
www.cisco.com
CSIDS 2.111-14
VLAN ACL (VACL) access controls all packets on a Catalyst 6000 switch with a
PFC. VACLs are strictly for security packet filtering and redirecting traffic to
specific physical switch ports. Unlike IOS ACLs, VACLs are not defined by
direction (input or output).
VACLs have a capture option to specify that packets that match the specified
flows are switched normally but are also captured and transmitted out of capture
ports. Only permit traffic is sent to capture ports. The Catalyst 6000 IDSM uses
this feature to capture traffic for Intrusion Detection analysis.
VACLs allow for granular control of traffic for Intrusion Detection analysis by
permitting interesting traffic. Traffic can by permitting based on
Source or destination IP addresses.
Source or destination ports.
A combination of IP addresses and ports.
For instance, on a web farm port 80 (HTTP) and 443 (HTTPS) are the services
required for Internet users to access the web servers. Web server software exploits
are attempted against these ports. A VACL can be created to capture only traffic
destined to these ports, thus reducing the amount of traffic sent to the IDSM for
Intrusion Detection analysis.
Only one VACL per protocol can be applied to a single VLAN. CIDS only
examines IP traffic, so we are limited to one IP VACL per VLAN. The IP VACL
can be applied across multiple VLANS.
11-12
Configuration Tasks
Initialize the Catalyst 6000 IDSM.
Configure the switch for ID analysis
Assign the command and control port to the
proper VLAN.
Capture traffic for ID analysis.
Verify the configuration.
Add the Catalyst 6000 IDSM to CSPM.
www.cisco.com
CSIDS 2.111-15
To configure the Catalyst 6000 IDSM and have it report alarms to CSPM, perform
the following tasks:
Initialize the Catalyst 6000 IDSMThis includes setting the IDSM and
Director PostOffice parameters using the setup command facility.
Assign the command and control port to the VLAN that can communicate
with CPSMThis includes using the set vlan command.
Configure the Catalyst 6000 family switch settings to capture traffic for
Intrusion Detection analysisThis includes creating either SPAN sessions or
VACLs.
Verify the configurationThis includes using available show and

diagnostics commands.
Add the IDSM to CSPMThis includes using the CSPM Add Sensor wizard
to add the IDSM to a network topology.
11-13
Initializing the Catalyst 6000 IDSM

This section covers how to access and initialize the Catalyst 6000 IDSM to enable
communication with the Director platform.
Accessing the IDSM
Step 1Telnet or console into the switch.

Step 2Session into the IDSM.
Step 3Log in at the IDSM login prompt.
Step 4The username is always ciscoids, and
the default password is attack.
Step 5Initial configuration is done with the
setup command facility.
www.cisco.com
CSIDS 2.111-17
The Catalyst 6000 switch can be accessed either through a console management
session or telnet. After an interactive session has been established, you must
session into the IDSM. This is the only method to gain command-line access to
the IDSM. Login as the ciscoids user with the default password attack. You will
be logged in as a privileged user and can initialize the IDSM with the setup
command facility.
11-14
IDSM Setup
Session into IDSM.
Enter setup.
Press Enter
to continue.
www.cisco.com
CSIDS 2.111-18
After an interactive session is established, perform the following tasks to initialize

the IDSM:
Step 1
Use the session command to access the IDSM.
Step 2
Enter setup to begin the System Configuration Dialog.
Step 3
Press Enter or type Yes to continue with configuration dialog.
11-15
Assign and Apply Initial

Configuration
Enter the
PostOffice
parameter.
Enter yes to
apply the
configuration
and reset
IDSM.
Step 4
11-16
www.cisco.com
CSIDS 2.111-19
Enter the PostOffice parameters for the IDSM.

CIDS Setting Parameter
Value
Description
IDSM virtual terminal password
<password>
IDSM session password.
Sensors IP address
<IP Address>
The IP address of the IDSM.
Sensors IP subnet mask
<Subnet mask>
The network subnet mask

associated with the IDSM.
Sensors default gateway
<IP Address>
The IP address of the default

gateway for the IDSM.
Sensors host name
<Host Name>
Alphanumeric identifier for the

IDSM (e.g., idsm1).
Sensors host id
1-65535
Numeric identifier for each IDSM.
Sensors host post office port
1-65535
Numeric identifier for the CIDS

postoffice protocol
communication port. The default
value is 45000.
Sensors organization name
<Org Name>
Alphanumeric identifier for a

group of CIDS components (e.g.,
securitynoc).
Sensors organization id
1-65535
Numeric identifier for a collection

of CIDS components.
Directors IP address
<IP Address>
The IP address of the Director.
Directors host name
<Host Name>
Alphanumeric identifier for the

Director (e.g. , director1)
Directors host post office port
1-65535

postoffice protocol
communication port. The default
value is 45000.
Directors host id
1-65535

Director.
Step 5
CIDS Setting Parameter
Value
Description
Directors heart beat interval
1-65535
The number of seconds a heart

beat packet is sent to CIDS
services to determine the
communication status. A route
down alarm is generated if a
response is not received. The
default value is 5.
Directors organization name
<Org Name>
Alphanumeric identifier for a

group of CIDS components (e.g.,
securitynoc).
Directors organization id
1-65535
Numeric identifier for a collection

of CIDS components.
Enter yes to apply the initial configuration and cause the IDSM to reset. The
IDSM is then initialized and can then communicate with the Director platform.
11-17
Configuring the Catalyst Switch of ID

Analysis
This section covers the commands used to configure a Catalyst 6000 Family
switch for Intrusion Detection analysis. The commands assign the command and
control port to the proper VLAN, capture traffic using either the SPAN or VLAN
ACL feature, and assign trunking ports.
Switch Configuration Tasks
Assign command and control port to a VLAN.

Capture interesting traffic using either the
SPAN or VACL feature.
Clear unwanted VLAN traffic from being sent
to the monitoring port. (Optional)
Assign the monitoring port to the VLAN.
(Optional, required if clearing VLAN traffic.)
www.cisco.com
CSIDS 2.111-21
The tasks to configure the switch for ID analysis are:
Assign the command and control port to a VLAN that will allow for
communication to the Director platform.
Capture interesting traffic using either the SPAN or VACL feature(s).
Clear unwanted VLAN traffic from being captured by using the following
commands:
Note
clear trunk
set trunk
Assign the monitoring port to a VLAN using the set vlan command.
Removing trunk traffic is not required for ID analysis.
Permitting only specific VLAN trunk traffic to the IDSM monitoring port is a
technique to optimize the Intrusion Detection analysis performance of the IDSM.
11-18
Assign Command and Control

Port
switch> (enable)
set vlan <vlan_num> <src_mod/src_ports>

Groups ports into a VLAN.
switch>(enable) set vlan 302 3/2

Assigns the command and control port to
VLAN 302.
www.cisco.com
CSIDS 2.111-22
Use the set vlan command to set group ports into a VLAN, or to set the private
VLAN type. The syntax for the set vlan command is as follows:
set vlan vlan_num mod/ports
vlan_num
Number identifying the VLAN.
mod/ports
Number of the module and ports on the module

belonging to the VLAN.
Note
The IDSM command and control port (port 2) must be assigned to a VLAN that can
communicate with CSPM.
11-19
Capture Traffic - SPAN

switch>(enable)
set span <src_mod/src_ports...| src_vlans...>

<dest_mod/dest_port>[rx | tx | both] [create]
Sets ports or VLANs to span to the destination port.
switch>(enable) set span 4/5 3/1 rx create

switch>(enable) set span 401 3/1 rx create
Sets port 5 on module 4 and VLAN 401 to span to the monitoring
port on the IDS module 3.
www.cisco.com
CSIDS 2.111-23
Use the set span command to designate the source and destination SPAN ports.
Use the set span disable command to remove the destination ports from
monitoring traffic. The syntax of the set span command is as follows:
set span src_mod / src_ports | src_vlans dest_mod / dest_port tx | rx | both create
set span disable dest_mod/dest_port | all
src_mod/src_ports
The module and port numbers of the source

traffic to be mirrored.
src_vlans
VLAN number(s) of traffic to be mirrored.
dest_mod/dest_port
The module and port number assigned as the

destination for the mirrored traffic.
tx
Traffic is transmitted from the source port.
rx
Traffic is received at the source port.
both
Traffic is received or transmitted from the

source port/.
create
11-20
If you do not specify the keyword create with

the set span command, and you have only
one session, the session is overwritten. If a
matching destination port exists, the particular
session will be overwritten (with or without
specifying create). If you specify the keyword
create and there is no matching destination
port, the session will be created.
VACL Configuration Tasks
Create VACL to capture interesting traffic.

Commit VACL to memory.
Map VACL to VLAN(s).
Assign monitoring port as VACL capture port.
www.cisco.com
CSIDS 2.111-24
The tasks need to use VACLs to capture traffic are:
Create the VACL to capture interesting traffic.
Commit the VACL to memory.
MAP the VACL to VLAN(s).
Assign the monitoring port as the VACL capture port.
Note
Port 1 on the IDSM is assigned as the default VACL capture port.
11-21
Capture Traffic - VACLs

switch>(enable)
set security acl ip <acl_name> permit

Sets VACL to restrict and capture traffic.
switch>(enable) set security acl ip SPAN_

MIMIC permit ip any any capture
Sets VACL SPAN_MIMIC to capture all ip traffic for IDS
analysis. The SPAN_MIMIC VACL is equivalent to
capturing traffic using the SPAN feature.
www.cisco.com
CSIDS 2.111-25
Use the set security acl ip command to create VLAN ACLs to capture IP traffic
for Intrusion Detection analysis. Use the clear security acl map command to
remove VACL to VLAN mappings.
Note
VACLs have an implicit deny feature at the end of the list. All traffic not matching
the VACL will be dropped as a result.
The syntax for the set security acl ip command is as follows:

set security acl ip acl_name permit src_ip_spec capture
set security acl ip acl_name permit [ip | 0] src_ip_spec dest_ip_spec [capture]
set security acl ip acl_name permit [icmp | 1] src_ip_spec dest_ip_spec [icmp_type] [icmp_code]
| [icmp_message] [capture]
set security acl ip acl_name permit [tcp | 6] src_ip_spec [operator port [port]] dest_ip_spec
[operator port [port]] [established] [capture]
set security acl ip acl_name permit [udp | 17] src_ip_spec [operator port [port]] dest_ip_spec
[operator port [port]] [capture]
11-22
acl_name
Unique name that identifies the lists to which the

entry belongs.
permit
Keyword to allow traffic from the source IP address.
src_ip_spec
Source IP address and the source mask.
protocol
Keyword or number of an IP protocol
dest_ip_spec
Destination IP address and the destination mask.
capture
Keyword to specify packets are switched normally

and captured; permit must also be enabled.
ip | 0
(Optional.) Keyword or number to match any IP

packets.
icmp | 1
(Optional.) Keyword or number to match ICMP

packets.
icmp-type
(Optional.) ICMP message type name or a number.
icmp-code
(Optional.) ICMP message code name or a number.
icmp-message
ICMP message type name or ICMP message type

and code name.
tcp | 6
(Optional.) Keyword or number to match TCP

packets.
operator
(Optional.) Operands; valid values include lt (less

than), gt (greater than), eq (equal), neq (not equal),
and range (inclusive range).
port
(Optional.) Number or name of a TCP or UDP port;

valid port numbers are from 0 to 65535.
established
(Optional.) Keyword to specify an established

connection; used only for TCP protocol.
udp | 17
(Optional.) Keyword or number to match UDP

packets.
11-23
VACL Examples
switch>(enable) set security acl ip WEBONLY
permit tcp any host 172.30.1.50 eq 80 capture
switch>(enable) set security acl ip WEBONLY
permit ip any any
Sets VACL WEBONLY to capture only web traffic for IDS
analysis. Other IP traffic is allowed but not captured.
switch>(enable) set security acl ip 10_NET

permit ip 10.0.0.0 255.0.0.0 any capture
switch>(enable) set security acl ip 10_NET
permit ip any 10.0.0.0 255.0.0.0 capture
Sets VACL 10_NET to capture traffic destined to or originating
from the 10.0.0.0 network.
www.cisco.com
CSIDS 2.111-26
The WEB_ONLY VACL captures traffic destined for TCP port 80 (HTTP) for
Intrusion Detection analysis. All other IP traffic is permitted but is not capture.
The 10_NET VACL captures any IP traffic destined for or originating from the
10.0.0.0 network for Intrusion Detection analysis.
11-24
Commit and Map VACLs

switch> (enable)
commit security acl <acl_name|all>

Commits VACLs to switch.
switch>(enable) commit security acl WEBONLY

switch >(enable)
set security acl map <acl_name> <vlans>

Maps VACLs to VLANs.
switch>(enable) set security acl map WEBONLY

401
www.cisco.com
CSIDS 2.111-27
Use the commit security acl command to commit all Access Control Entries
(ACEs) or an ACE in NVRAM that have not been written to hardware. The
syntax for the commit security acl command is as follows:
commit security acl acl_name | all
acl_name
Name that identifies the VACL whose ACEs are to be

committed.
all
Keyword to commit ACEs for all the ACLs.
security acl
Keywords to specify security ACEs
Use the set security acl map command to map an existing VACL to a VLAN.
Use the clear security acl map command set to remove VACL-to-VLAN
mapping. The syntax for the set security acl map command is as follows:
set security acl map acl_name vlan
acl_name
Unique name that identifies the list to which the entry

belongs.
vlan
Number of the VLAN to be mapped to the VACL.
11-25
Assign Capture Ports

switch> (enable)
set security acl capture-ports <mod/ports>

Defines security acl capture ports.
switch>(enable) set security acl captureports 3/1
www.cisco.com
CSIDS 2.111-28
Port 1 on the IDSM is configured as the default destination capture port for all
captured VACL traffic. The set security acl capture command can be used to
specify other ports.
Use the set security acl capture-ports command to set the ports specified with
the capture option in the set security acl ip to show traffic captured on these ports.
Use the clear security acl capture-ports command to remove a port from the
capture port list.
set security acl capture-ports <mod/ports>[,<mod/ports>]
mod/ports
11-26
Module and port number
Trunking Traffic Configuration

Tasks (Optional)
Clear unwanted VLAN traffic from being sent

to the monitoring port.
Configure port 1 to add VLANs to the allowed
VLAN list for existing trunks.
Assign the monitoring port to the VLAN.
www.cisco.com
CSIDS 2.111-29
11-27
Trunk Traffic
switch> (enable)
clear trunk <mod/port> [vlans]

Clear specific VLANs from the allowed VLAN list for a
trunk port.
switch>(enable) clear trunk 3/1 1-1024

switch >(enable)
set trunk <mod/port> [vlans]

Add VLANs to the allowed VLAN list for existing trunks.
switch>(enable) set trunk 3/1 401

www.cisco.com
CSIDS 2.111-30
Use the clear trunk command to restore a trunk port to its default trunk type and
mode or to clear specific VLANs from the allowed VLAN list for a trunk port.
The syntax for the clear trunk command is as follows:
clear trunk <mod/port> [vlans]
mod/port
Number of the module and the port on the module.
vlans
(Optional.) Number of the VLAN to remove from the

allowed VLAN list; valid values are from 1 to 1000 and
1025 to 4094.
Use the set trunk command to configure trunk ports and to add VLANs to the
allowed VLAN list for existing trunks. The syntax for the set trunk command is
as follows:
set trunk <mod/port> [vlans]
11-28
mod/port
Number of the module and the port on the module.
vlans
(Optional.) VLANs to add to the list of allowed VLANs on

the trunk; valid values are from 1 to 1000 and 1025 to
4094.
Assign Monitoring Port to

VLAN
switch> (enable)
set vlan <vlan_num> <src_mod/src_ports>

Groups ports into a VLAN.
switch>(enable) set vlan 401 3/1

Assigns the monitoring port to VLAN 401.
www.cisco.com
CSIDS 2.111-31
Use the set vlan command to set group ports into a VLAN, or to set the private
VLAN type. The syntax for the set vlan command is as follows:
set vlan vlan_num mod/ports
vlan_num
Number identifying the VLAN.
mod/ports
Number of the module and ports on the module belonging to the VLAN.
11-29
Verifying the Configuration

This section discusses commands used to verify the Catalyst switch and IDSM
configuration.
Show Commands
switch>(enable) show config
switch> show span
switch> show security acl
Displays switch configurations including
span and VACL settings.
idsm# show configuration

idsm(diag)# show eventfile current
Displays various configurations and logfiles.
www.cisco.com
CSIDS 2.111-33
Use the show config switch command to display the nondefault system or module
configuration. The syntax for show config command is as follows:
show config
Use the show span switch command to display information about the current
SPAN configuration. The syntax for show span command is as follows:
show span
Use the show security acl switch command set to display the contents of the ACL
that are currently configured or last committed to NVRAM and hardware. The
syntax for show security acl command is as follows:
show security acl
Use the show configuration IDSM diagnostic command to display version and
configuration settings. The syntax for show configuration command is as
follows:
show configuration
Use the show eventfile IDSM command to display the contents of the IDSM
alarm log files. The syntax for show eventfile command is as follows:
show eventfile [current | backup | archive]
11-30
Clear Commands
idsm(diag)# diag resetcount

Resets IDS statistics.
idsm# clear config

Disables IDS.
Remove all IDS configurations.
www.cisco.com
CSIDS 2.111-34
Use the diag resetcount IDSM diagnostic command to reset the counters for IP
traffic received by the command and control port. The syntax for the diag
resetcount is as follows:
diag resetcount
Use the clear config command to clear the IDSM configuration. The syntax for
the clear config is as follows:
clear config
Note
The clear config command disables IDS features on the IDSM.
11-31
Adding the Catalyst 6000 IDSM to CSPM

This section covers the procedure of adding an IDSM to CSPM. After the IDSM
is added to CSPM, CSPM is able to configure the IDSM and log and display
alarms generated by the IDSM.
Add Sensor Wizard
www.cisco.com
CSIDS 2.111-36
Perform the following task to add an IDSM to CSPM:
11-32
Step 1
Choose Start>Programs>Cisco Systems>Cisco Secure Policy Manager>Cisco

Secure Policy Manager to launch the CSPM software.
Step 2
Log into the CSPM database.
Step 3
Select the Add Sensor wizard from the CSPM Wizards menu. The Sensor
Identification window opens.
Step 4
Enter the Sensor Identification parameters. Click Next to continue. The Sensor
Configuration window opens.
Step 5
Choose the Sensor Version from the Sensor Version drop-down menu.
Step 6
Choose the Signature Template from the Signature template drop-down menu.
IDSM Added to CSPM
Step 7
www.cisco.com
CSIDS 2.111-37
Verify the PostOffice parameters. Click Finish to generate the configuration files
and add the IDSM to the network topology.
CSPM will now receive alarms generated by the IDSM.
Note
IDSM configuration, including Signatures, is similar to appliance-based sensors.

Refer to the Sensor Configuration and Signature and Intrusion Detection
Configuration chapters for more information.
11-33
Updating IDSM Components

This section discusses IDSM application and maintenance partitions, service
packs, and signatures. Procedures to update partition images, service packs, and
signatures are also discussed.
IDSM Components
IDSM has two partitions: application and
maintenance.
IDSM can only have one active partition.
Application is by default the active
partition.
The application partition contains the IDS
engine.
Service pack and signature updates are
done from the application partition.
www.cisco.com
CSIDS 2.111-39
The IDSM has two independent partitions on its internal hard drive: the
application partition (hdd:1) and the maintenance partition (hdd:2). Each of these
partitions is 4 GB, contains its own image, and is capable of running even if the
other partition becomes corrupted. Only one partition may be active at a time. The
application partition contains the IDS engine and is active by default.
Note
11-34
The Catalyst set boot device command can be used to assign the default active
partition.
IDSM Components (cont.)

The maintenance partition contains
diagnostic functions.
Updating the application partition is done
from the maintenance partition.
Updating the maintenance partition is
done from the application partition.
Boot into a partition with the reset
command.
www.cisco.com
CSIDS 2.111-40
The maintenance partition contains maintenance and diagnostic functions and is

not capable of performing intrusion detection.
Updating a partition is done while it is not active. For instance, if the maintenance
partition became corrupt, you would install the maintenance image from the
application partition.
Use the Catalyst switch command reset to reboot the IDSM and make a partition
active.
The syntax for the reset command is as follows:
reset mod_num hdd:partition
11-35
Updating IDSM
Update files must be located on an

accessible FTP server.
Application and Maintenance image files
are in Microsoft Cab format.
Signatures and service packs are selfextracting executables.
www.cisco.com
CSIDS 2.111-41
The IDSM updates are released as files. The update process requires that the
update files exist on an accessible FTP server. The update files can be obtained
online from Ciscos Software Center at www.cisco.com. A valid Cisco
Connection Online (CCO) account is required.
Partition image files are distributed in Microsoft Cab format. Two supporting files
are required: .lst and .dat. The .lst file contains a list of the cab files required to
install the image. The .dat file is a binary file containing installation information.
Signatures and service packs are distributed as self-extracting executables.
11-36
IDSM Files
IDSM AAA #.# # S#.ext

Extension
Software Type
Signature version
Service pack level
IDSM version
Ex: IDSM-sig-2.5-1-S2.exe
www.cisco.com
CSIDS 2.111-42
An IDSM software filename has the following parts:
The four types of IDSM software files are:
Application (a)IDS engine image
Maintenance (m)IDS maintenance image
Service packs (sp)IDS engine fixes
Signatures (sig)IDS signature updates
IDSM versionThe IDSM version is represented by a numeric value and is

separated by a decimal. The preceding number is the major version and the
later is the minor version.
Service pack levelThe service pack level identifies the level at which the
IDSM has been patched.
Signature versionThe signature version identifies the signatures detected

by IDSM.
ExtensionThe filename extension can be one the following:
exeSelf-extracting executable for signature or service pack updates.
cabMicrosoft cab files for IDSM software images.
lstText file containing a list of the cab files required for an IDSM
software image.
datBinary file containing information required for installation of an
IDSM software image.
An example of an IDSM software file is IDSM-sig-2.5-1-S2.exe. This filename

represents signature update 2 for IDSM major version 2, minor version 5, and
service pack level 1.
11-37
Update Signatures and

Service Packs
idsm (config)#
apply [signatureupdate | servicepack] site

'value user 'value' dir 'value' file 'value'
Updates signatures detected by IDSM or a service pack
level of IDSM.
idsm(config)# apply signatureupdate site ftpsrv

user netrangr dir cabs file IDSM-sig2.5-1-S2.exe
www.cisco.com
CSIDS 2.111-43
Use the apply configuration command to install a signature update or a service

pack. The syntax for the apply command is as follows:
apply [signatureupdate | servicepack] site value user value dir value file value
11-38
signatureupdate
Keyword to specify a signature update file is to be installed.
servicepack
Keyword to specify a service pack file is to be installed.
site
Keyword to specify that the files to be installed exist on an

FTP server.
value
IP address or hostname of the FTP server.
user
Keyword to specify an existing user account on the FTP

server will be used to transfer the files.
value
The username of the account on the FTP server.
dir
Keyword to specify that the files are stored in a specified

directory.
value
The directory where the files are located.
file
Keyword to specify that a file is to be transferred from the

FTP server.
value
The filename of the file to be transferred and installed.
Update IDSM Partitions

idsm (config)#
ids-installer system /nw /install

/server=ip_address /user=username
/dir=directory /prefix=update_file
/save=yes|no
Updates application or maintenance partition.
idsm(config)# ids-installer system /nw /install

/server=172.30.1.50 /user=netranger /dir=cabs
/prefix=IDSM-m-2.5-0 /save=yes
Updates maintenance partition with the 2.5(0) image from the
FTP server with the IP address of 172.30.1.50.
www.cisco.com
CSIDS 2.111-44
Use the ids-installer configuration command to install an IDSM partition image.

The syntax for the ids-installer command is as follows:
ids-installer system /nw /install /server=ip_address /user=username /dir=directory
/prefix=update_file /save=yes
system
Keyword to specify a system action is to be performed.
/nw
Keyword to specify the installation of the image will be

done from the network.
/install
Keyword to specify the system action will be a install.
/server
Keyword to specify the image file exists on an FTP server.
ip_address
IP address of the FTP server.
/user
Keyword to specify a username will be required to

download the image file.
username
/dir

directory.
directory
The directory where the files are located. The single quotes
are required.
/prefix
Keyword to specify the prefix of the image file is required.
update_file
Prefix of the image file to be transferred and installed.
/save
Keyword to specify if the image file will be saved as the

cache copy.
yes | no
If yes, the image file will be installed and saved as a

cached copy.
If no, the image file is installed but not save.
11-39
Troubleshooting
This section covers techniques to troubleshoot the Catalyst 6000 IDSM.
IDSM Status LED

Status Description
Green
IDSM is operational
Amber
IDSM is disabled or running a boot

and self-diagnostic sequence
Red
Diagnostic other than an individual

port test failed
Off
IDSM power is off
www.cisco.com
CSIDS 2.111-46
The status LED is a quick method to determine the state of the IDSM. The status
LED is located in the left corner of the module.
11-40
Status Color
Description
Green
IDSM is operational
Amber
IDSM is disabled or running a boot and self-diagnostics

sequence
Red
Diagnostic other than an individual port test failed
Off
IDSM power is off
Switch Commands
switch> show module
Shows the status of the modules in
the switch. The ok state indicates
the module is online.
switch> show port 2

Shows the status of the ports on
module 2.
switch>(enable) reset 2 hdd:2

Resets module 2 and boots it from
partition 2.
www.cisco.com
CSIDS 2.111-47
Use the show module command to display the module status and information.
The syntax for the show module command is as follows:
show module [mod]
mod
Number of the module
Use the show port command to display port status and counters.
show port [mod[/port]]
mod/port
Number of the module and optionally, the number

of the port on the module
Use the reset command to restart the system or an individual module, schedule a
system reset, or cancel a scheduled reset. The syntax for the reset command is as
follows:
reset mod_num hdd:partition
mod_num
Number of the module to reset.
hdd
Keyword to specify the boot image is on a hard disk.
partition
Number of the partition on the hard disk that will become

active after the module is reset.
11-41
Switch Commands (cont.)
switch> set module power up 3

Powers up module 3.
switch> set module power down 3

Shows the status of the ports on module 3.
www.cisco.com
CSIDS 2.111-48
Use the set module power command to turn on or shut off the power to a module.
The IDSM must be shutdown before it can be removed from the switch chassis.
Use the IDSM shutdown command prior to powering off the module.
set module power up | down mod
up
Keyword to turn on the power to a module.
down
Keyword to turn off the power to a module.
mod
Number of the module.
WARNING Do not remove the IDSM from the switch until after the IDSM shuts down
completely. Removing the IDSM without going through a shutdown procedure can damage
your IDSM.
11-42
IDSM Commands
idsm(diag)# nrconns
Displays the IDSM communication status with the
Director.
idsm(diag)# diag bootresults

Displays the IDSM boot time diagnostic results.
idsm(diag)# report systemstatus site

10.0.0.3 user netrangr dir .
Transfers the system status file to an FTP server.
www.cisco.com
CSIDS 2.111-49
The following IDSM commands are executed in the diagnostics mode: nrconns,
diag bootresults, report systemstatus, and show errorfile. To enter the diagnostics
mode enter diag at the idsm prompt.
Use the nrconns command to display the current IDS communication service
status. The syntax for the nrconns command is as follows:
nrconns
Use the diag bootresults command to display the boot time diagnostic results.
The syntax for the diag bootresults command is as follows:
diag bootresults
Use the report systemstatus command to transfer the system status to an FTP
server. The file is in html format and contains diagnostic information and IDSM
configuration files. The filename is the name of the IDSM followed by
SystemStatusReport. For instance of the if the IDSM hostname is idsm0, the
filename is idsm0SystemStatusReport.html. The syntax for the report
systemstatus command is as follows:
report systemstatus site ip_address user username dir directory
site
Keyword to specify that an FTP server is the destination for

the file transfer
user
Keyword to specify that a username is required to transfer

the file to the FTP server.
username
dir

directory.
directory
The directory where the files will be stored.
11-43
IDSM Commands (cont.)

idsm(diag)# show errorfile packetd
Shows the contents of the packetd error file.
idsm # shutdown
Performs a graceful shutdown of the IDSM.
www.cisco.com
CSIDS 2.111-50
Use the show errorfile diagnostic command to display the contents of the IDSM
error log files. The syntax for the show errorfile command is as follows:
show errorfile [filexferd | loggerd | packetd | postofficed | sapd] [current | backup]
filexfered
Keyword that specifies to display the contents of the

filexfered error log file.
loggerd

loggerd error log file.
packetd

packetd error log file.
postofficed

postofficed error log file.
sapd
Keyword that specifies to display the contents of the sapd

error log file.
current
Keyword to display the contents of the current log file

specified.
backup
Keyword to display the contents of the archived log file

specified.
Use the shutdown command to shut down the IDSM operating system. The
syntax for the shutdown command is as follows:
shutdown
11-44
Summary
This section summarizes what you have learned in this chapter.
Summary
The Catalyst 6000 IDSM is a line card for
the Catalyst 6000 Family switches.
The Catalyst 6000 IDSM is initialized using
the setup command.
The set span command is used to
configure a Catalyst switch to capture
traffic using the SPAN feature.
The set security acl command is used to
configure a Catalyst switch to capture
traffic using the VACL feature.
www.cisco.com
CSIDS 2.111-52
11-45
Summary (cont.)
The Add Sensor wizard in CSPM is used
to add the Catalyst 6000 IDSM to CSPM.
The following commands are used to
verify the Catalyst 6000 IDSM
configuration:
show configuration.
show eventfile.
11-46
www.cisco.com
CSIDS 2.111-53
Summary (cont.)
The following commands are used to
verify the Catalyst 6000 Family switch
configuration:
show config.
show span.
show security acl.
IDSM has two partitions: application and
maintenance.
www.cisco.com
CSIDS 2.111-54
11-47
Summary (cont.)
IDSM partitions are updated while offline.
The application partition and maintenance
partitions are updated using the IDSM
configuration ids-installer program.
Signature and service packs are installed
from the application partition.
Signatures and service packs are installed
using the apply IDSM configuration
command.
11-48
www.cisco.com
CSIDS 2.111-55
Lab ExerciseConfigure a Catalyst 6000

IDSM
Complete the following lab exercise to practice what you learned.
Objective
Initialize the Catalyst 6000 IDSM.
Configure the Catalyst 6000 Family switch to capture traffic for Intrusion
Detection analysis.
Add the IDSM to an existing network topology in CSPM.
Apply a signature update to the IDSM application partition.
Transfer the IDSM System Status report to your CSPM host.
Visual Objective
The following figure displays the configuration you will complete in this lab
exercise.

Pod P
Your Pod
Pod Q
Peer Pod
172.30.1.0 /24
e0/1 .10P
idsmP
sensorP
e0/0 .1
.4
.6
10.0.P.0 /24
CSPM
sensorQ
e0/0 .1
.4
.6
idsmQ
10.0.Q.0 /24
10.0.P.3
CSPM
e0/1 .10Q
rQ
rP
10.0.Q.3
www.cisco.com
CSIDS 2.111-57
11-49
Setup
Before starting this lab exercise, set up your equipment so that you can ensure you
have connectivity to the switch that you are going to configure. Verify that your
pod has an FTP server with a public directory with write privileges for file
transfers.
Directions
Your task in this lab exercise is to configure the Catalyst 6000 Family switch and
IDSM to detect alarms and send alarm notifications to CSPM. Then you will add
the IDSM to an existing CSPM network topology. Follow the convention where
P=pod number and PVLAN=300 + P. For example, student pod 3 would have
PVLAN= 303. Your instructor will assign your Module number, M, and the IP
address of the switch, SW.
Your instructor will provide you with the values to complete the following table.
Parameter
Value
PVLAN
M
SW
Task 1
Initialize the IDSM
Perform the following lab steps to initialize the IDSM.
Step 1
From you Windows host, telnet to the switch.

c:> telnet SW
(where SW = IP address of switch)

Step 2
Disable console error messages during your telnet session into the switch.
switch> (enable) set logging session disable
Step 3
Session and log into your idsm:

switch> session M
(where M = module number assigned)

login: ciscoids
password: attack
Step 4
Run the setup command:

# setup
Step 5
11-50
Follow the system configuration dialog and enter the following CIDS
Communications Infrastructure parameters:
Parameter
Value
IDSM virtual terminal password
Keep the default setting of current
Sensors IP address
Sensors IP subnet mask
255.255.255.0
Parameter
Value
Sensors default gateway
Sensors host name
idsmP (where P = pod number)
Sensors host id
Sensors host post office port
45000
Directors IP address
Directors host name
Directors host post office port
Keep the default setting of 45000
Directors host id
Directors heart beat interval
Keep the default setting of 5
Directors organization name
Directors organization id
Note
Step 6
The IDSM command and control port is assigned the sensors settings.
After entering and reviewing all communication parameters enter yes when
prompted to apply this configuration. If you made any mistakes, enter no and rerun the setup command.
Note
The IDSM will reset after you accept and apply the configuration. You will be
logged out and returned to the switch prompt.
Task 2Configure the switch for ID analysis

Perform the following lab steps to configure the switch for Intrusion Detection
analysis using the VLAN ACL (VACL) feature. Follow the convention where
P=pod number and PVLAN=300 + P. For example, student pod 3 would have
PVLAN= 303. Your instructor will assign your Module number, M.
Step 1
Go into privileged mode:

switch> enable
Password: cisco
switch>(enable)
Step 2
Verify your IDS module status is ok. Do NOT continue until the module status is
ok.
switch>(enable) show module M
switch> (enable) show module 3
Mod Slot Ports Module-Type
Model
3 3
2
Intrusion Detection System WS-X6381-IDS
Sub Status
no ok
11-51
Step 3
Set the command and control port to the VLAN that can communicate with
CSPM:
switch>(enable) set vlan PVLAN M/2
(where PVLAN = 300 + pod number, and M=module number assigned)

Note
Step 4
You will receive an error if you attempt to add the command and control interface
to a VLAN if the module status is not ok.
Create the VACL to capture all IP traffic destined to your VLAN:

switch#(enable) set security acl ip SPAN_PVLAN permit ip any any capture
(where PVLAN = 300 + pod number)

Step 5
Commit the VACL to NVRAM:

switch#(enable) commit security acl SPAN_PVLAN

Step 6
Map the VACL to the VLAN:

switch#(enable) set security acl map SPAN_PVLAN PVLAN

Note
The destination capture port is assigned by default to IDSM Port 1.
Task 3
Verify the switch and IDSM Configuration
Perform the following lab steps to verify the switch and IDSM configurations are
correct.
Step 1
Display your switchs IDSM configuration:

switch>(enable) show config M
switch> (enable) show conf 3
This command shows non-default configurations only.
Use 'show config <mod> all' to show both default and non-default configurations.
..............
begin
!
# ***** NON-DEFAULT CONFIGURATION *****
!
!#time: Sat Nov 25 2000, 02:55:48
!
# default port status is enable
!
!
#module 3 : 2-port Intrusion Detection System
set port gvrp
3/2 disable
set security acl capture-ports 3/1
end
11-52
Step 2
Display the switchs security ACL settings:

switch>(enable)show security acl
ACL
Type VLANS
-------------------------------- ---- ----SPAN_301
IP 301
switch>(enable)show security acl map PVLAN
switch>(enable)show security acl map 301
VLAN 301 is mapped to IP ACL SPAN_301.
Step 3
Session into your IDS module and display the IDSM configuration:
idsm# show configuration
Using 46178304 out of 267702272 bytes of available memory
!
Using 460935168 out of 4211310592 bytes of available disk space
!
Sensor version is : 2.5(1)S1
!
Sensor application status:
nr.postofficed
running
nr.fileXferd
running
nr.loggerd
running
nr.packetd
running
nr.sapd
running
Configuration last modified Tue Nov 07 01:03:54 2000
Sensor:
IP Address:
10.0.0.6
Netmask:
255.255.255.0
Default Gateway:
10.0.0.1
Host Name:
idsm0
Host ID:
6
Host Port:
45000
Organization Name:
pod0
Organization ID:
100
Director:
IP Address:
10.0.0.84
Host Name:
director84
Host ID:
84
Host Port:
45000
Heart Beat Interval (secs): 5
Organization Name:
pod0
Organization ID:
100on
Step 4
Display the IDSM logfile:

idsm# diag
idsm#(diag) show eventfile current
4,0,2000/11/25,01:07:12,2000/11/25,01:07:12,10000,6,100,OUT,OUT,5,997,0,TCP/IP,0.0
.0.0,0.0.0.0,0,0,0.0.0.0,84.100 route 1 down
4,1,2000/11/25,01:07:29,2000/11/25,01:07:29,10000,6,100,OUT,OUT,1,0,0,TCP/IP,0.0.0
.0,0.0.0.0,0,0,0.0.0.0,postofficed initial notification msg
11-53
Task 4
Add the IDSM to CSPM
Perform the following lab steps to add the IDSM to an existing network topology
in CSPM:
Step 1
From your Windows host, launch the CSPM software. Choose

Start>Programs>Cisco Systems>Cisco Secure Policy Manager>Cisco Secure
Policy Manager from the menu bar.
Step 2
Log into the CSPM database as Administrator with the password attack.
Step 3
Choose the Add Sensor wizard from the CSPM menu bar. The Sensor
Identification window opens.
Step 4
Enter the Sensor Identification parameters.

Parameter
Value
Sensors host name
idsmP (where P = pod number)
Sensors host id
Sensors IP address
Policy Enforcement Associated

Network Service
Keep the default setting of Cisco Post

Office
Step 5
Step 6
Choose the Sensor Version and Signature Template to apply to the IDSM.
Parameter
Value
Sensor version
Signature template
Step 7
Step 8
Verify the PostOffice parameters. Click Finish to add the IDSM to the network
topology.
Step 9
files.
Step 10 Select idsmP (where P = pod number) from the Network Topology Tree.

Step 13 After you get an Upload completed message in the Status section proceed to the
next task.
Note
11-54
Notify the instructor that you have completed these tasks before proceeding.
Task 5
Apply a Signature Update
Performing the following lab steps to apply a signature update to the IDSM
application partition:
Step 1
Telnet into the switch from your Windows host.
Step 2
Session into your IDSM.

switch> session M

login: ciscoids
Password: attack
Step 3
Go into configuration mode.

idsm# config t
Step 4
Apply the signature update.

Parameter
Value
FTPSITE
USERNAME
FTPDIR
FILENAME
idsm#(config) apply signatureupdate site FTPSITE user USERNAME dir FTPDIR file
FILENAME
Step 5
A warning message is displayed. Enter yes when prompted to continue with the
install.
Step 6
Enter the password attack when prompted. Wait for the file to download. When
the download is completed, the IDSM will shutdown and restart. You will be
logged out and returned to the switch prompt.
Step 7
Session into your IDSM once the module status is ok.
Step 8
Verify the service pack was installed.

idsm# show config
Task 6
Transfer the IDSM System Status Report
Performing the following lab steps to transfer the IDSM system status file:
Step 1
Telnet into the switch from your Windows host.
Step 2
Session into your IDSM.

switch> session M
(where M=module number assigned)

login: ciscoids
Password: attack
11-55
Step 3
Go into diagnostics mode.

idsm# diag
Step 4
Transfer the system status file to your FTP server.

idsm(diag)# report systemstatus site 10.0.P.3 user ftp dir .
(where P=pod number)

Step 5
Enter yes when prompted to continue generating the system status report.
Step 6
Enter the password attack when prompted.
Step 7
Launch your web browser from your windows host.
Step 8
Open the IDSM system status report. In your web browser, choose File>Open.
Locate the file in your FTP directory. Use your browsers browse feature.
C:\InetPub\ftproot\idsm0SystemStatusReport.html
Completion Criteria
You completed this lab exercise if you were able to do the following:
11-56
Successfully configure the IDSM to communicate with CSPM.
Successfully configure the switch to capture traffic.
Successfully add the IDSM to an existing network topology in CSPM.
Successfully apply the signature update to the IDSM application partition.
Successfully transfer the IDSM System Status report to the CSPM host.
12
Authentication,
Authorization, and
Accounting
Configuration on the
Cisco PIX Firewall
Overview
Objectives
Introduction
Installation of CSACS for Windows NT
Authentication configuration
Authorization configuration
Accounting configuration
Troubleshooting the AAA configuration
Summary
Lab exercise
Objectives
Objectives
Upon completion of this chapter, you will be able to
perform the following tasks:
Define authentication, authorization, and accounting.
Describe the differences between authentication,
authorization, and accounting.
Describe how users authenticate to the PIX Firewall.
Describe how cut-through proxy technology works.
Name the AAA protocols supported by the PIX Firewall.
Install and configure CSACS for Windows NT.
Configure AAA on the PIX Firewall.
12-2
Cisco Secure PIX Firewall Advanced 2.0
www.cisco.com
CSPFA 2.012-2
Introduction
This section introduces the authentication, authorization, and accounting concepts
and how the Cisco Secure PIX Firewall supports them.
Authentication, Authorization,
and Accounting
Authentication
Who you are
Can exist without authorization
Authorization
What you can do
Requires authentication
Accounting
What you did
www.cisco.com
CSPFA 2.012-4
Authentication, Authorization, and Accounting (AAA) is used to tell the PIX

Firewall who the user is, what the user can do, and what the user did.
Authentication is valid without authorization. Authorization is never valid without
authentication.
Suppose you have 100 users inside and you want only six of these users to
perform FTP, Telnet, or HTTP outside the network. Tell the PIX Firewall to
authenticate outbound traffic and give all 6 users identifications on the Terminal
Access Controller Access Control System (TACACS+) or Remote Authentication
Dial-In User Service (RADIUS) AAA server. With simple authentication, these
six users are authenticated with a username and password, and then permitted
outside the network. The other 94 users cannot go outside the network. The PIX
Firewall prompts users for their username and password, then passes their
username and password to the TACACS+ or RADIUS AAA server. Depending on
the response, the PIX Firewall opens or denies the connection.
Suppose one of these users, baduser, is not to be trusted. You want to allow
baduser to perform FTP, but not HTTP or Telnet, to the outside network. This
means you must add authorization, that is, authorize what users can do in addition
to authenticating who they are. This is only valid with TACACS+. When you add
authorization to the PIX Firewall, it first sends the untrusted user a username and
password to the AAA server, then sends an authorization request telling the AAA
server what command baduser is trying to do. With the server set up properly,
baduser is allowed to perform FTP but is not allowed to perform HTTP or
Telnet.
Authentication, Authorization, and Accounting Configuration on the Cisco PIX Firewall
12-3
What the User Sees

Telnet
PIX Firewall:
HTTP
Username: smith
Password: 2bon2b
Server:
Username: john
smith@john
Password: v1v10k4
2bon2b@vlvl0k4
FTP
PIX Firewall:
Username: smith@john
Password: 2bon2b@v1v10k4
www.cisco.com
CSPFA 2.012-5
You can authenticate with the PIX Firewall in one of three ways:
TelnetYou get a prompt generated by the PIX Firewall. You have up to

four chances to log in. If the username or password fail after the fourth
attempt, the PIX Firewall drops the connection. If authentication and
authorization are successful, you are prompted for a user name and password
by the destination server.
FTPYou get a prompt from the FTP program. If you enter an incorrect
password, the connection is dropped immediately. If the username or
password on the authentication database differs from the username or
password on the remote host to which you are accessing via FTP, enter the
username and password in the following formats:
aaa_username@remote_username
aaa_password@remote_password
The PIX Firewall sends the aaa_username and aaa_password to the AAA
server, and if authentication and authorization are successful, the
remote_username and remote_password are passed to the destination FTP
server.
Note
Some FTP GUIs do not display challenge values.
HTTPYou see a pop-up window generated by the web browser. If you

enter an incorrect password, you are prompted again. If the username or
password on the authentication database differs from the username or
password on the remote host to which you are using HTTP to access, enter
the username and password in the following formats:
12-4
aaa_username@remote_username
aaa_password@remote_password
The PIX Firewall sends the aaa_username and aaa_password to the AAA
server, and if authentication and authorization are successful, the
remote_username and remote_password are passed to the destination HTTP
server.
Keep in mind that browsers cache usernames and passwords. If you believe
that the PIX Firewall should be timing out an HTTP connection but it is not,
re-authentication may actually be taking place with the web browser sending
the cached username and password back to the PIX Firewall. The Syslog
service will show this phenomenon. If Telnet and FTP seem to work
normally, but HTTP connections do not, this is usually why.
The PIX Firewall supports authentication usernames up to 127 characters and
passwords of up to 63 characters. A password or username may not contain an at
(@) character as part of the password or username string.
Note
If PIX Firewalls are in tandem, Telnet authentication works in the same way as a
single PIX Firewall, but FTP and HTTP authentication have additional complexity
because you have to enter each password and username with an additional at
(@) character and password or username for each in-tandem PIX Firewall.
Note
Once authenticated with HTTP, a user never has to reauthenticate no matter how
low the PIX Firewall uauth timeout is set. This is because the browser caches the
"Authorization: Basic=Uuhjksdkfhk==" string in every subsequent connection to
that particular site. This can only be cleared when the user exits all instances of
the web browser and restarts. Flushing the cache is of no use.
12-5
Cut-Through Proxy Operation

The user makes a request
to access the web server.
Internet
Internet
web server
remote_user@local_user
remote_pass@local_pass
The user is prompted by the

PIX Firewall.
Intranet
The PIX Firewall

queries CSACS for
the remote
username and
password.
If CSACS authenticates, the

user is cut-through the
PIX Firewall, and the local
username and password
are passed to the web
server to authenticate.
CSACS
www.cisco.com
CSPFA 2.012-6
The PIX Firewall gains dramatic performance advantages because of the cutthrough proxy, a method of transparently verifying the identity of users at the
firewall and permitting or denying access to any TCP- or UDP-based application.
This method eliminates the price and performance impact that UNIX systembased firewalls impose in similar configurations, and leverages the authentication
and authorization services of CSACS.
The PIX Firewalls cut-through proxy challenges a user initially at the application
layer, and then authenticates against standard TACACS or RADIUS+ databases.
After the policy is checked, the PIX Firewall shifts the session flow and all traffic
flows directly and quickly between the server and the client while maintaining
session state information.
12-6
Supported AAA Servers

TACACS+
Cisco
Cisco Secure
Secure
ACS
ACS NT
NT
RADIUS
Cisco
Cisco Secure
Secure
ACS
ACS UNIX
UNIX
Cisco
Cisco Secure
Secure
ACS
ACS NT
NT
Cisco
Cisco Secure
Secure
ACS
ACS UNIX
UNIX
Livingston
Livingston
Merit
Merit
TACACS+
TACACS+
Freeware
Freeware
www.cisco.com
CSPFA 2.012-7
The PIX Firewall supports the following AAA protocols and servers:
Terminal Access Controller Access Control System Plus (TACACS+)
Cisco Secure Access Control Server for Windows NT (CSACS-NT)
CSACS for UNIX (CSACS-UNIX)
TACACS+ Freeware
Remote Authentication Dial-In User Service (RADIUS)
CSACS for Windows NT (CSACS-NT)
CSACS for UNIX (CSACS-UNIX)
Livingston
Merit
12-7
Installation of CSACS for Windows NT

This section explains how to install the Cisco Secure Access Control Server
(CSACS) for Windows NT.
Installation Wizard
Note
www.cisco.com
CSPFA 2.012-9
Close all Windows programs before you run the setup program.
To start installation of CSACS for Windows NT, complete the following steps:
12-8
Step 1
Log in as the local system administrator to the machine on which you are
installing CSACS.
Step 2
Insert the CSACS CD-ROM into your CD-ROM drive. The Installation window
opens.
Step 3
Click Install. The Software License Agreement window opens.
Step 4
Read the Software License Agreement. Click Accept to agree to the licensing
terms and conditions. The Welcome window opens.
Step 5
Click Next. The Before You Begin window opens.
Step 6
Verify that each condition is met, and then click the check box for each item.
Click Next.
Step 7
Click Next. (Click Explain for more information on the listed items. If any
condition is not met, click Cancel to exit the program.)
Step 8
If all conditions are met, click Next to continue.
Note
Step 9
If this is a new installation, skip to Step 11.
(Optional.) If CSACS is already installed, the Previous Installation window opens.

You are prompted to remove the previous version and save the existing database
information. To keep the existing data, click Yes, keep existing database and
click Next. To use a new database, deselect the check box and click Next. If you
checked the check box, the setup program backs up the existing database
information and removes the old files. When the files are removed, click OK.
Step 10 If Setup finds an existing configuration, you are prompted whether you want to
import the configuration. To keep the existing configuration, click Yes, import
configuration and click Next. To use a new configuration, deselect the check box
and click Next. The Choose Destination Location window opens.
Step 11 To install the software in the default directory, click Next. To use a different
directory, click Browse and enter the directory to use. If the directory does not
exist, you are prompted to create one. Click Yes. The Authentication Database
Step 12 Click the option button for the authentication databases to be used by CSACS.
Check the CSACS Database only option (the default). Also check the Windows
NT User Database option. If you select the first option, Cisco Secure ACS will
use only the CSACS database for authentication; if you select the second option,
CSACS will check both databases.
Step 13 (Optional.) To limit dial-in access to only those users you specified in the
Windows NT User Manager, click the Yes, reference "Grant dialin permission
to user" setting. Click Next. The Network Access Server Details window opens.
12-9
Basic Configuration
Authenticate users using
TACACS+ (Cisco)
RADIUS (Cisco)
Access server name
Enter the PIX Firewall name
Access server IP address
Enter the PIX Firewall IP
address
Windows NT server IP address
Enter the AAA server IP
address
TACACS+ or RADIUS key
Enter a secret key
Must be the same in the PIX
Firewall
www.cisco.com
CSPFA 2.012-10
Step 14 Complete the following information:
Authenticate Users UsingType of security protocol to be used. TACACS+

(Cisco) is the default.
Access Server NameName of the network access server (NAS) that will be
using the CSACS services.
Access Server IP AddressIP address of the NAS that will be using the
CSACS services.
Windows NT Server IP AddressIP address of this Windows NT server.
TACACS+ or RADIUS KeyShared secret of the NAS and CSACS. These

passwords must be identical to ensure proper function and communication
between the NAS and CSACS. Shared secrets are case sensitive. Setup
installs the CSACS files and updates the Registry. Click Next. The Interface
Step 15 The Interface Configuration options are disabled by default. Click the check box
to enable any or all of the options listed. Click Next. The Active Service
Monitoring window opens.
Note
Configuration options for these items are displayed in the CSACS interface only if
they are enabled. You can disable or enable any or all of these and additional
options after installation in the Interface Configuration: Advanced Options window.
Step 16 To enable the CSACS monitoring service, CSMon, check the Enable Log-in
Monitoring check box, then select a script to execute when the login process fails
the test:
12-10
No Remedial ActionLeave CSACS operating as is.
RebootReboot the system on which CSACS is running.
Restart All(Default.) Restart all CSACS services.
Restart RADIUS/TACACS+Restart only RADIUS, TACACS+, or both

protocols.
You can also develop your own scripts to be executed if there is a system failure.
See the online documentation for more information.
Step 17 To have CSACS generate an e-mail message when administrator events occur,
check the Enable Mail Notifications check box, then enter the following
information:
SMTP Mail ServerThe name and domain of the sending mail server (for
example, server1.company.com).
Mail account to notifyThe complete e-mail address of the intended

recipient (for example, msmith@company.com).
Step 18 Click Next. The CSACS Service Initiation window opens. If you do not want to
configure a NAS from Setup, click Next. To configure a single NAS now, click
Yes, I want to configure Cisco IOS now. Click Next.
12-11
Authentication Configuration
This section discusses how to configure authentication on the PIX Firewall.
Specify AAA Servers

pixfirewall (config)#
aaa-server group_tag protocol auth_protocol
Assigns TACACS+ or RADIUS protocol to a group tag
aaa-server group_tag (if_name) host
server_ip key timeout seconds
Identifies the AAA server for a given group tag
pixfirewall(config)# aaa-server MYTACACS protocol tacacs+
pixfirewall(config)# aaa-server MYTACACS (inside) host
10.0.0.2 secretkey timeout 10
www.cisco.com
CSPFA 2.012-12
Use the aaa-server command to specify AAA server groups. The PIX Firewall
lets you define separate groups of TACACS+ or RADIUS servers for specifying
different types of traffic, such as a TACACS+ server for inbound traffic and
another for outbound traffic. The aaa command references the group tag to direct
authentication, authorization, or accounting traffic to the appropriate AAA server.
You can have up to 14 tag groups, and each group can have up to 16 AAA servers
for a total of up to 256 TACACS+ or RADIUS servers. When a user logs in, the
servers are accessed one at a time, starting with the first server you specify in the
tag group, until a server responds.
The default configuration provides these following two aaa-server protocols:
aaa-server MYTACACS protocol tacacs+
aaa-server RADIUS protocol radius
Note
12-12
If you are upgrading from a previous version of the PIX Firewall and have aaa
command statements in your configuration, using the default server groups
enables you to maintain backward compatibility with the aaa command statements
in your configuration
Note
The previous server type option at the end of the aaa authentication and aaa
accounting commands has been replaced with the aaa-server group tag.
Backward compatibility with previous versions is maintained by the inclusion of two
default protocols for TACACS+ and RADIUS.
Note
The PIX Firewall listens for RADIUS on ports 1645 and 1646. If your RADIUS
server uses ports 1812 and 1813, you will need to reconfigure it to listen on ports
1645 and 1646.
The syntax for all forms of the aaa-server command is as follows:

aaa-server group_tag (if_name) host server_ip key timeout seconds
no aaa-server group_tag (if_name) host server_ip key timeout seconds
aaa-server group_tag protocol auth_protocol
clear aaa-server [group_tag]
group_tag
An alphanumeric string that is the name of

the server group. Use the group_tag in the
aaa command to associate aaa
authentication, aaa authorization, and
aaa accounting command statements with
an AAA server.
if_name
The interface name on the side where the

AAA server resides.
host server_ip
The IP address of the TACACS+ or

RADIUS server.
key
A case-sensitive, alphanumeric keyword of

up to 127 characters that is the same value
as the key on the TACACS+ server. Any
characters entered past 127 are ignored.
The key is used between the client and
server for encrypting data between them.
The key must be the same on both the
client and server systems. Spaces are not
permitted in the key, but other special
characters are.
If a key is not specified, encryption does not
occur.
timeout seconds
A retransmit timer that specifies the duration

that the PIX Firewall retries access. Access
to the AAA server is retried four times
before choosing the next AAA server. The
default is 5 seconds. The maximum time is
30 seconds.
For example, if the timeout value is 10
seconds, the PIX Firewall retransmits for 10
seconds and if no acknowledgment is
received, tries three times more for a total of
40 seconds to retransmit data before the
next AAA server is selected.
protocol auth_protocol
The type of AAA server, either TACACS+ or

RADIUS.
12-13
Enable Authentication
aaa authentication include|exclude authen_service
inbound|outbound|if_name local_ip local_mask foreign_ip
foreign_mask group_tag
Defines traffic to be authenticated
authen_service = any, ftp, http, or telnet
any = all TCP traffic
pixfirewall(config)# aaa authentication include any inbound
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
pixfirewall(config)# aaa authentication include telnet
outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
pixfirewall(config)# aaa authentication include ftp dmz
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
pixfirewall(config)# aaa authentication exclude any outbound
10.0.0.33 255.255.255.255 0.0.0.0 0.0.0.0 MYTACACS
www.cisco.com
CSPFA 2.012-13
The aaa authentication command enables or disables user authentication

services. When you start a connection via Telnet, FTP, or HTTP, you are
prompted for a username and password. A AAA server, designated previously
with the aaa-server command, verifies whether the username and password are
correct. If they are correct, the PIX Firewalls cut-through proxy permits further
traffic between the initiating host and the target host.
The aaa authentication command is not intended to mandate your security
policy. The AAA servers determine whether a user can or cannot access the
system, what services can be accessed, and what IP addresses the user can access.
The PIX Firewall interacts with Telnet, FTP, and HTTP to display the prompts for
logging. You can specify that only a single service be authenticated, but this must
agree with the AAA server to ensure that both the firewall and server agree.
For each IP address, one aaa authentication command is permitted for inbound
connections and one for outbound connections. The PIX Firewall permits only
one authentication type per network. For example, if one network connects
through the PIX Firewall using TACACS+ for authentication, another network
connecting through the PIX Firewall can authenticate with RADIUS, but one
network cannot authenticate with both TACACS+ and RADIUS.
Note
The new include and exclude options are not backward compatible with PIX
Firewall versions 5.0 and earlier. If you downgrade to an earlier version, the aaa
authentication command statements are removed from your configuration.
The syntax for all forms of the aaa authentication command is as follows:
aaa authentication include | exclude authen_service inbound | outbound | if_name local_ip
local_mask foreign_ip foreign_mask group_tag
no aaa authentication [include | exclude authen_service inbound | outbound | if_name local_ip
local_mask foreign_ip foreign_mask group_tag]
12-14
clear aaa [authentication include | exclude authen_service inbound | outbound | if_name local_ip
include
Creates a new rule with the specified

service to include.
exclude
Creates an exception to a previously stated

rule by excluding the specified service from
authentication to the specified host. The
exclude parameter improves the former
except option by enabling the user to
specify a port to exclude to a specific host
or hosts.
authen_service
The services that require user

authentication before they are let through
the firewall. Use any, ftp, http, or telnet.
The any value enables authentication for all
TCP services.
inbound
Authenticates inbound connections.

Inbound means the connection originates
on the outside interface and is being
directed to the inside or any other perimeter
interface.
outbound
Authenticate outbound connections.

Outbound means the connection originates
on the inside and is being directed to the
outside or any other perimeter interface.
if_name
Interface name from which users require

authentication. Use if_name in combination
with the local_ip address and the foreign_ip
address to determine where access is
sought and from whom. The local_ip
address is always on the interface with the
highest security level and foreign_ip is
always on the lowest.
local_ip
The IP address of the host or network of

hosts that you want to be authenticated.
You can set this address to 0 to mean all
hosts and to let the authentication server
decide which hosts are authenticated.
local_mask
Network mask of local_ip. Always specify a

specific mask value. Use 0 if the IP address
is 0. Use 255.255.255.255 for a host.
foreign_ip
The IP address of the hosts you want to

access the local_ip address. Use 0 to mean
all hosts.
foreign_mask
Network mask of foreign_ip. Always specify

a specific mask value. Use 0 if the IP
address is 0. Use 255.255.255.255 for a
host.
group_tag
The group tag set with the aaa-server

command.
12-15
aaa authentication Example

.50
pixfirewall(config)# nat
(inside) 1 10.0.0.0
255.255.255.0
pixfirewall(config)# aaa
authentication include
any outbound 0 0 MYTACACS
authentication exclude
any outbound 10.0.0.42
255.255.255.255 0.0.0.0
0.0.0.0 MYTACACS
172.26.26.0/24
192.168.0.0/24
3
1
.42
www.cisco.com
.5
10.0.0.0/24
AAA server
CSPFA 2.012-14
In the example above, workstations on the 10.0.0.0 network can originate

outbound connections, but users must be authenticated. Host 10.0.0.42, however,
is allowed to start outbound connections without being authenticated.
12-16
How to Add Users to

CSACS-NT
www.cisco.com
CSPFA 2.012-15
To add users to the CSACS, complete the following steps:

Step 1
Click User Setup from the navigation bar. The Select window opens.
Step 2
Enter a name in the User field.

Note
Step 3
The username can contain up to 32 characters. Names cannot contain the

following special characters: #, ?, ", *, >, <. Leading and trailing spaces are not
allowed.
Click Add/Edit. The Edit window opens. The username being added or edited
appears at the top of the window.
The Edit window contains the following sections:
Account Disabled
Supplementary User Info
User Setup
Account Disable
Account Disabled
If you need to disable an account, select the Account Disabled check box in the
Account Disabled section to deny access for this user.
Note
You must click Submit to have this action take effect.
12-17
Supplementary User Info

In this section, you can enter supplemental information to appear in each user
profile. The fields shown below are available by default; however, you can insert
additional fields by clicking Interface Configuration in the navigation bar and then
clicking User Data Configuration (configuring supplemental information is
optional):
Real NameIf the username is not the users real name, enter the real name
here.
DescriptionEnter a detailed description of the user.
User Setup
In the User Setup group box, you can edit or enter the following information for
the user as applicable:
Note
Password AuthenticationFrom the drop-down menu, choose a database to

use for username and password authentication. You can select the Windows
NT user database or the Cisco Secure database. The Windows NT option
authenticates a user with an existing account in the Windows NT User
Database located on the same machine as the CSACS server. The Cisco
Secure Database option authenticates a user from the local CSACS database.
If you select this database, enter and confirm the Password Authentication
Protocol (PAP) password to be used. The Separate CHAP/MS-CHAP/ARAP
option is not used with the PIX Firewall.
The Password and Confirm Password fields are required for all authentication
methods except for all third-party user databases.
Group to which the user is assignedFrom the Group to which the user is
assigned drop-down menu, choose the group to which to assign the user. The
user inherits the attributes and operations assigned to the group. By default,
users are assigned to the Default Group. Users who authenticate via the
Unknown User method who are not found in an existing group are also
assigned to the Default Group.
CallbackThis is not used with the PIX Firewall.
Client IP Address AssignmentThis is not used with PIX Firewall.
Account Disable
The Account Disable group box can be used to define the circumstances under
which the users account will become disabled.
Note
12-18
This is not to be confused with account expiration due to password aging.

Password aging is defined for groups only, not for individual users.
Never radio buttonSelect to keep the users account always enabled. This
is the default.
Disable account if radio buttonClick to disable the account under the

circumstances you specify in the following fields:
Date exceedsFrom the drop-down menus, choose the month, date, and
year on which to disable the account. The default is 30 days after the user
is added.
Failed attempts exceedSelect the check box and enter the number of
consecutive unsuccessful login attempts to allow before disabling the
account. The default is 5.
Failed attempts since last successful loginThis counter shows the
number of unsuccessful login attempts since the last time this user logged
in successfully.
Reset current failed attempts count on submitIf an account is disabled

because the failed attempts count has been exceeded, select this check box
and click Submit to reset the failed attempts counter to 0 and reinstate the
account.
If you are using the Windows NT user database, this expiration information is in
addition to the information in the Windows NT user account. Changes here do not
alter settings configured in Windows NT.
When you have finished configuring all user information, click Submit.
12-19
Authentication of Non-Telnet,
FTP, or HTTP Traffic
Option 1Authenticate first by accessing a

Telnet, FTP, or HTTP server before accessing
other services.
Option 2Authenticate to the PIX Firewall virtual
Telnet service before accessing other services.
www.cisco.com
CSPFA 2.012-16
The PIX Firewall authenticates users via Telnet, FTP, or HTTP. But what if users
need to access a Microsoft file server on port 139 or a Cisco IP/TV server for
instance? How will they be authenticated? Whenever users are required to
authenticate to access services other than Telnet, FTP, or HTTP, they need to do
one of the following:
12-20
Option 1Authenticate first by accessing a Telnet, FTP, or HTTP server

before accessing other services.
Option 2Authenticate to the PIX Firewall virtual Telnet service before

accessing other services. When there are no Telnet, FTP, or HTTP servers
with which to authenticate, or just to simplify authentication for the user, the
PIX Firewall allows a virtual Telnet authentication option. This permits the
user to authenticate directly with the PIX Firewall using the virtual Telnet IP
address.
Virtual Telnet Example

pixfirewall(config)# virtual
telnet 192.168.0.5
pixfirewall(config)# aaa-server
MYTACACS protocol
protocol tacacs+
pixfirewall(config)# aaa-server
MYTACACS (inside)
(inside) host
10.0.0.3 secretkey
secretkey
authentication include any
any
outbound 0.0.0.0
0.0.0.0 0.0.0.0
0.0.0.0
0.0.0.0 0.0.0.0 MYTACACS
MYTACACS
Backbone, web, FTP,

and TFTP server
172.26.26.50
Superserver
Internet
.1
192.168.0.0 /24
.2
The PIX Firewall passes the username and

password
to the AAA server at 10.0.0.3 for
authentication.
If the AAA server verifies that the username

and password are correct, the PIX Firewall
caches the users authentication credentials
for the duration of the uauth timeout.
The user is able to connect to Superserver

on port 139 using the Run command
without being required to re-authenticate.
PIX Firewall
.1
10.0.0.0 /24
1
C:\> telnet 192.168.0.5

LOGIN Authentication
Username: aaauser
Password: aaapass
Authentication Successful
.3
AAA server
\\Superserve
www.cisco.com
CSPFA 2.012-17
The virtual Telnet option provides a way to pre-authenticate users who require
connections through the PIX Firewall using services or protocols that do not
support authentication. The virtual Telnet IP address is used both to authenticate
in and authenticate out of the PIX Firewall.
When an unauthenticated user Telnets to the virtual IP address, the user is
challenged for the username and password, and then authenticated with the
TACACS+ or RADIUS server. Once authenticated, the user sees the message
Authentication Successful and the authentication credentials are cached in the
PIX Firewall for the duration of the user authentication (uauth) timeout.
If a user wishes to log out and clear the entry in the PIX Firewall uauth cache, the
user can again Telnet to the virtual address. The user is prompted for a username
and password, the PIX Firewall removes the associated credentials from the uauth
cache, and the user receives a Logout Successful message.
In the previous figure, the user wants to establish a NetBIOS session on port 139
to access the file server named Superserver. The user telnets to the virtual Telnet
address at 192.168.0.5, and is immediately challenged for a username and
password before being authenticated with the TACACS+ AAA server. Once
authenticated, the PIX Firewall allows the user to connect to the file server
without re-authentication.
12-21
Configuration of Virtual Telnet

Authentication
virtual telnet ip_address

IP address
For inbound clients, this must be an unused
global address.
For outbound clients, this must be an unused
global address routed directly to the PIX Firewall.
pixfirewall(config)# virtual telnet

192.168.0.3
www.cisco.com
CSPFA 2.012-18
When using virtual Telnet to authenticate inbound clients, the IP address must be
an unused global address. When using virtual Telnet to authenticate outbound
clients, the IP address must be an unused global address routed directly to the PIX
Firewall.
The syntax for the virtual telnet command is as follows:
virtual telnet ip_address
ip_address
12-22
Unused global IP address on PIX Firewall,

used for Telnet for authentication.
Virtual HTTP
Virtual HTTP solves the problem of http
requests failing when web servers require
credentials that differ from those required by
the PIX Firewalls AAA server.
When virtual HTTP is enabled, it redirects the
browser to authenticate first to a virtual web
server on the PIX Firewall.
After authentication, the PIX Firewall forwards
the web request to the intended web server.
Virtual HTTP is transparent to the user.
www.cisco.com
CSPFA 2.012-19
With the virtual HTTP option, web browsers work correctly with the PIX
Firewalls HTTP authentication. The PIX Firewall assumes that the AAA server
database is shared with a web server and automatically provides the AAA server
and web server with the same information. The virtual HTTP option works with
the PIX Firewall to authenticate the user, separate the AAA server information
from the web clients URL request, and direct the web client to the web server.
The virtual HTTP option works by redirecting the web browsers initial
connection to an IP address, which resides in the PIX Firewall, authenticating the
user, then redirecting the browser back to the URL that the user originally
requested. This option is so named because it accesses a virtual HTTP server on
the PIX Firewall, which in reality does not exist.
This option is especially useful for PIX Firewall interoperability with Microsoft
Internet Information Server (IIS), but is useful for other authentication servers.
When using HTTP authentication to a site running Microsoft IIS that has Basic
text authentication or NT Challenge enabled, users may be denied access from
the Microsoft IIS server because the browser appends the string: Authorization:
Basic=Uuhjksdkfhk== to the HTTP GET commands. This string contains the
PIX Firewall authentication credentials. Windows NT Microsoft IIS servers
respond to the credentials and assume that a Windows NT user is trying to access
privileged pages on the server. Unless the PIX Firewall username and password
combination is exactly the same as a valid Windows NT username and password
combination on the Microsoft IIS server, the HTTP GET command is denied.
To solve this problem, the PIX Firewall redirects the browsers initial connection
to its virtual HTTP IP address, authenticates the user, then redirects the browser
back to the URL that the user originally requested. Virtual HTTP is transparent to
the user; therefore, users enter actual destination URLs in their browsers as they
normally would.
Note
Do not set the timeout uauth duration to 0 seconds when using the virtual HTTP
option. This will prevent HTTP connections to the real web server.
12-23
Configuration of Virtual HTTP

Authentication
virtual http ip_address

IP address
For inbound clients, this must be an
unused global address.
For outbound clients, this must be an
address routed directly to the PIX Firewall.
pixfirewall(config)# virtual
http 192.168.0.3
www.cisco.com
CSPFA 2.012-20
The virtual address identifies the IP address of the virtual HTTP server on the PIX
Firewall. For inbound use, ip_ address can be any unused global address. Access
to this address must be provided by an access-list and static command pair. For
outbound use, ip_address must be an address routed directly to the PIX
Firewall.The syntax for the virtual http command is as follows:
virtual http ip_address [warn]
no virtual http ip_address
12-24
ip_address
The PIX Firewalls network interface IP

address.
warn
Informs virtual http command users that

the command was redirected. This option is
only applicable for text-based browsers
where the redirect cannot happen
automatically.
Authentication of Console
Access
aaa authentication [serial | enable | telnet |

ssh] console group_tag
Defines a console access method that requires authentication
pixfirewall(config)#
console MYTACACS
console MYTACACS
console MYTACACS
console MYTACACS
aaa authentication serial

aaa authentication enable
aaa authentication telnet
aaa authentication ssh
www.cisco.com
CSPFA 2.012-21
Use the aaa authentication console command to require authentication

verification to access the PIX Firewalls console. Authenticated access to the PIX
Firewall console has different types of prompts depending on the option you
choose. While the enable and ssh options allow three tries before stopping with
an access denied message, both the serial and telnet options cause you to be
prompted continually until you have successfully logged in.
The serial option requests a username and password before the first commandline prompt on the serial console connection. The telnet option forces you to
specify a username and password before the first command-line prompt of a
Telnet console connection. The ssh option requests a username and password
before the first command-line prompt on the SSH console connection. The enable
option requests a username and password before accessing privileged mode for
serial, Telnet, or SSH connections.
Telnet access to the PIX Firewall console is available from any internal interface
(and from the outside interface with IPSec configured) and requires previous use
of the telnet command. SSH access to the PIX Firewall console is available from
any interface without IPSec configured and requires previous use of the ssh
command.
Authentication of the serial console creates a potential deadlock situation if the
authentication server requests are not answered and you need access to the
console to attempt diagnosis. If the console login request times out, you can gain
access to the PIX Firewall from the serial console by entering the PIX Firewall
username and the enable password. The maximum password length for accessing
the console is 16 characters.
Note
The serial console option also logs to a Syslog server changes made to the
configuration from the serial console.
12-25
The syntax for the aaa authentication console command is as follows:

aaa authentication [serial | enable | telnet | ssh] console group_tag
no aaa authentication [serial | enable | telnet | ssh] console group_tag
12-26
serial
Requests a username and password before

the first command-line prompt on the serial
console connection.
enable

accessing privileged mode for serial or
Telnet connections.
telnet
Forces you to specify a username and

password before the first command-line
prompt of a Telnet console connection.
ssh

the first command line prompt on the SSH
console connection.
console
Specifies that access to the PIX Firewall

console requires authentication and, as an
option, logs configuration changes to a
Syslog server.
group_tag

command.
How to Change the

Authentication Timeouts
timeout uauth hh:mm:ss [absolute|inactivity]

Sets the time interval before users will be required to reauthenticate
AbsoluteTime interval starts at user login
InactivityTime interval for inactive sessions (no traffic)
pixfirewall(config)# timeout uauth 3:00:00 absolute

pixfirewall(config)# timeout uauth 0:30:00 inactivity
www.cisco.com
CSPFA 2.012-22
Use the timeout uauth command to specify how long the cache should be kept
after the user connections become idle. The timeout command value must be at
least 2 minutes. Use the clear uauth command to delete all authorization caches
for all users, which will cause them to reauthenticate the next time they create a
connection.
The inactivity and absolute qualifiers cause users to reauthenticate after either a
period of inactivity or an absolute duration. The inactivity timer starts after a
connection becomes idle. If a user establishes a new connection before the
duration of the inactivity timer, the user is not required to reauthenticate. If a user
establishes a new connection after the inactivity timer expires, the user must
reauthenticate.
The absolute timer runs continuously, but waits to reprompt the user when the
user starts a new connection, such as clicking a link after the absolute timer has
elapsed. The user is then prompted to reauthenticate. The absolute timer must be
shorter than the xlate timer, otherwise a user could be reprompted after their
session already ended.
The inactivity timer gives users the best Internet access because they are not
prompted to regularly reauthenticate. Absolute timers provide security and
manage the PIX Firewall connections better. By being prompted to reauthenticate
regularly, users manage their use of the resources more efficiently. Also by being
reprompted, you minimize the risk that someone will attempt to use another users
access after they leave their workstation, such as in a college computer lab. You
may want to set an absolute timer during peak hours and an inactivity timer during
other times.
Both an inactivity timer and an absolute timer can operate at the same time, but
you should set the absolute timer duration for a longer time than the inactivity
timer. If the absolute timer is set less than the inactivity timer, the inactivity timer
never occurs. For example, if you set the absolute timer to 10 minutes and the
12-27
inactivity timer to an hour, the absolute timer reprompts the user every 10
minutes, and the inactivity timer will never be started.
If you set the inactivity timer to some duration, but the absolute timer to zero,
users are only reauthenticated after the inactivity timer elapses. If you set both
timers to zero, users have to reauthenticate on every new connection.
Note
Do not set the timeout uauth duration to 0 seconds when using the virtual HTTP
option or passive FTP.
The syntax for the timeout uauth command is as follows:

timeout uauth hh:mm:ss [absolute | inactivity]
show timeout
clear uauth
12-28
uauth hh:mm:ss
Duration before the authentication and

authorization cache times out and the user
has to reauthenticate the next connection.
This duration must be shorter than the xlate
values. Set to 0 to disable caching.
absolute
Runs the uauth timer continuously, but after

timer elapses, waits to reprompt the user
until the user starts a new connection(for
example, clicking a link in a web browser).
To disable absolute, set it to zero (0). The
default is 5 minutes.
inactivity
Starts the uauth timer after a connection

becomes idle. The default is 0.
How to Change the

Authentication Prompts
auth-prompt [accept | reject | prompt] string

Defines the prompt users see when authenticating
Defines the message users get when they successfully or
unsuccessfully authenticate
By default, only the username and password prompts are seen
pixfirewall(config)# auth-prompt prompt Please

Authenticate to the Firewall
pixfirewall(config)# auth-prompt reject
Authentication Failed, Try Again
pixfirewall(config)# auth-prompt accept Youve been
Authenticated
www.cisco.com
CSPFA 2.012-23
Use the auth-prompt command to change the AAA challenge text for HTTP,
FTP, and Telnet access. This is text that appears above the username and
password prompts that you view when logging in.
Note
Microsoft Internet Explorer only displays up to 37 characters in an authentication

prompt, Netscape Navigator displays up to 120 characters, and Telnet and FTP
display up to 235 characters in an authentication prompt.
The syntax for the auth-prompt command is as follows:

auth-prompt [accept | reject | prompt] string
no auth-prompt [accept | reject | prompt] string
show auth-prompt
clear auth-prompt
accept
If a user authentication via Telnet is

accepted, the accept message is displayed.
reject
If a user authentication via Telnet is

rejected, the reject message is displayed.
prompt
The AAA challenge prompt string follows

this keyword. This keyword is optional for
backward compatibility.
string
A string of up to 235 alphanumeric

characters. Special characters should not
be used; however, spaces and punctuation
characters are permitted. Entering a
question mark or pressing the Enter key
ends the string. (The question mark appears
in the string.)
12-29
Authorization Configuration
This section discusses the configuration of the PIX Firewall for authorization.
Enable Authorization
aaa authorization include | exclude author_service

inbound | outbound | if_name local_ip local_mask
foreign_ip foreign_mask group_tag
Defines traffic that requires AAA server authorization
author_service = any, ftp, http, or telnet
any = All TCP traffic
pixfirewall(config)# aaa authorization include ftp

pixfirewall(config)# aaa authorization exclude ftp
outbound 10.0.0.33 255.255.255.255 0.0.0.0 0.0.0.0
MYTACACS
www.cisco.com
CSPFA 2.012-25
The PIX Firewall uses authorization services with TACACS+ AAA servers that
determine which services an authenticated user can access.
Note
The PIX Firewall does not support RADIUS authorization.
The syntax for the aaa authorization command is as follows:

aaa authorization include | exclude author_service inbound | outbound | if_name local_ip
no aaa authorization include | exclude author_service inbound | outbound | if_name local_ip
clear aaa authorization [include | exclude author_service inbound | outbound | if_name local_ip
include author_service
12-30
The services that require authorization. Use

any, ftp, http, or telnet. Services not
specified are authorized implicitly. Services
specified in the aaa authentication
command do not affect the services, which
require authorization.
exclude author_service

authorization to the specified. The exclude
parameter improves the former except
option by allowing the user to specify a port
to exclude for a specific host or hosts.
inbound
Authenticates or authorizes inbound

connections. Inbound means the connection
originates on the outside interface and is
being directed to the inside or any other
perimeter interface.
outbound
Authenticates or authorizes outbound

connections. Outbound means the
connection originates on the inside and is
being directed to the outside or any other
if_name

sought and from whom.
local_ip

hosts that you want to be authenticated or
authorized. You can set this address to 0 to
mean all hosts and to let the authentication
server decide which hosts are
authenticated.
local_mask

is 0. Use 255.255.255.255 for a host.
foreign_ip

all hosts.
foreign_mask

host.
group_tag

command.
12-31
Authorization Rules Allowing

Specific Services
Select IOS Commands
Select Deny
Select Command
Enter the allowable service
Leave blank
Select Permit
Click Submit to add more rules
Click Submit + Restart when finished
www.cisco.com
CSPFA 2.012-26
Complete the following steps to add authorization rules for specific services in
CSACS:
12-32
Step 1
Click Group Setup from the navigation bar. The Group Setup window opens.
Step 2
Scroll down in Group Setup until you find IOS Commands, and select the IOS
Commands check box.
Step 3
Select Deny, which is found under Unmatched Cisco IOS commands.
Step 4
Select the Command check box.
Step 5
In the command field, enter one of the following allowable services: ftp, telnet,
or http.
Step 6
Leave the Arguments field blank.
Step 7
Select Permit, which is found under Unlisted arguments.
Step 8
Click Submit to add more rules, or click Submit + Restart when finished.
Authorization Rules Allowing

Services Only to Specific Hosts
Select IOS Commands
Select Deny
Select Command
Enter the allowable destination hosts
Select Deny
www.cisco.com
CSPFA 2.012-27
Complete the following steps to add authorization rules for services to specific
hosts in CSACS:
Step 1
Step 2
Scroll down in Group Setup until you find IOS Commands and select the IOS
Command check box.
Step 3
Select Deny, which is found under Unmatched Cisco IOS commands, select
Deny.
Step 4
Step 5
In the command field, enter one of the following allowable services: ftp, telnet,
or http.
Step 6
In the Arguments field, enter the IP addresses of the host that users are authorized
to go to. Use the following format:
permit ip_addr
(where ip_addr = the IP address of the host)

Step 7
Select Deny, which is found under Unlisted arguments.
Step 8
12-33
Authorization of Non-Telnet, FTP,

or HTTP Traffic
aaa authorization include | exclude author_service inbound |

outbound | if_name local_ip local_mask foreign_ip foreign_mask
group_tag
author_service = protocol or port
protocoltcp (6), udp (17), icmp (1), or others (protocol #)
port:
single port (e.g., 53), port range (e.g., 2000-2050), or port 0 (all ports)
ICMP message type (8 = echo request, 0 = echo reply)
port is not used for protocols other than TCP, UDP, or ICMP
pixfirewall(config)# aaa authorization include udp/0 inbound

0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
pixfirewall(config)# aaa authorization include tcp/30-100 outbound
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
pixfirewall(config)# aaa authorization include icmp/8 outbound
0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
www.cisco.com
CSPFA 2.012-28
The syntax of the aaa authorization of non-Telnet, FTP, or HTTP command is as

follows:
aaa authorization include | exclude author_service inbound | outbound | if_name local_ip
no aaa authorization [include | exclude author_service inbound | outbound | if_name local_ip
clear aaa [authorization [include | exclude author_service inbound | outbound | if_name local_ip
local_mask foreign_ip foreign_mask group_tag]]
12-34
include author_service
The services that require authorization. Use

a protocol or port number. Services not
specified are authorized implicitly. Services
specified in the aaa authentication
command do not affect the services that
require authorization.
exclude author_service

authorization to the specified host or
networks.
inbound

outbound

if_name

with the local_ip address and the
foreign_ip address to determine where
access is sought and from whom.
local_ip

authenticated.
local_mask

is 0. Use 255.255.255.255 for a host.
foreign_ip

all hosts.
foreign_mask

host.
group_tag

command.
12-35
Authorization of Non-Telnet, FTP, or

HTTP Traffic on CSACS-NT
Select IOS Commands

Select Deny
Select Command
Leave blank
Select Permit
www.cisco.com
CSPFA 2.012-29
Complete the following steps to add authorization rules for specific non-telnet,
FTP, or HTTP services in CSACS:
12-36
Step 1
Step 2
Scroll down in Group Setup until you find IOS Commands, and select the IOS
Command check box.
Step 3
Select Deny, which is found under Unmatched Cisco IOS commands.
Step 4
Step 5
In the command field, enter an allowable service using the following format:
protocol or port (where protocol is the protocol number and port is the port
number).
Step 6
Leave the Arguments field blank.
Step 7
Select Permit, which is found under Unlisted arguments.
Step 8
Accounting Configuration
This section demonstrates how to enable and configure accounting for all
services, select services, or no services.
Enable Accounting
aaa accounting include | exclude acctg_service

inbound | outbound | if_name local_ip
Defines traffic that requires AAA server accounting
acctg_service = any, ftp, http, or telnet
any = All TCP traffic
pixfirewall(config)# aaa accounting include any

pixfirewall(config)# aaa accounting exclude any
outbound 10.0.0.33 255.255.255.255 0.0.0.0 0.0.0.0
MYTACACS
www.cisco.com
CSPFA 2.012-31
The syntax for the aaa accounting command is as follows:

aaa accounting include | exclude acctg_service inbound | outbound | if_name local_ip
no aaa accounting include | exclude authen_service inbound | outbound | if_name group_tag
clear aaa [accounting [include | exclude authen_service inbound | outbound | if_name
group_tag]]
include acctg_service
The accounting service. Accounting is

provided for all services, or you can limit it
to one or more services. Possible values
are any, ftp, http, telnet, or protocol/port.
Use any to provide accounting for all TCP
services. To provide accounting for UDP
services, use the protocol/port form.
exclude acctg_service
Create an exception to a previously stated

authentication, authorization, or accounting
to the specified host. The exclude
option by allowing the user to specify a port
to exclude to a specific host or hosts.
12-37
inbound

outbound

if_name

foreign_ip_address to determine where
local_ip

authenticated.
local_mask

is 0. Use 255.255.255.255 for a host.
foreign_ip

all hosts.
foreign_mask

host.
group_tag

command.
To specify the value of the acctg.service argument using the protocol/port form,
enter the protocol as a number (6 for TCP, 17 for UDP, 1 for ICMP, and so on).
The port is the TCP or UDP destination port. A port value of 0 (zero) means all
ports. If the protocol specified is ICMP, the port is the ICMP type, such as 8 for
ICMP echo and 0 for ICMP echo-reply. Examples of the aaa accounting
command using protocol/port form follow:
12-38
aaa accounting include udp/53 inbound 0 0 0 0 MYTACACSEnables

accounting for DNS lookups from the outside interface
aaa accounting include 1/0 outbound 0 0 0 0 MYTACACSEnables

accounting of ICMP echo-reply packets arriving at the inside interface from
inside hosts
aaa accounting include 1/8 outbound 0 0 0 0 MYTACACSEnables

accounting only for ICMP echoes (pings) that arrive at the inside interface
from an inside host
aaa match acl_name Option

Usage
aaa authentication | authorization | accounting
match acl_name inbound | outbound | interface_name
group_tag
Enables TACACS+ or RADIUS user authentication, authorization, and
accounting of traffic specified in an access list
pixfirewall(config)# access-list mylist permit tcp

10.0.0.0 255.255.255.0 172.26.26.0 255.255.255.0
pixfirewall(config)# aaa authentication match mylist
outbound MYTACACS
All TCP traffic from 10.0.0.0 to 172.26.26.0 is permitted, but users must
be authenticated
www.cisco.com
CSPFA 2.012-32
In the PIX Firewall software versions 5.2 and higher, the match acl_name option
is available in the aaa command. The aaa command can take part of its input
from an access control list (ACL).
In the previous example, the acl mylist permits all TCP traffic from network
10.0.0.0 to network 172.26.26.0. The match acl_name option in the aaa
command instructs the PIX Firewall to require authentication when the action the
user is trying to perform matches the actions specified in mylist. Therefore, any
time a user on the 10.0.0.0 internal network uses any TCP application to access
network 172.26.26.0, he will be required to authenticate. In other words, the
command aaa authentication match mylist outbound MYTACACS is equal to
aaa authentication include any outbound 10.0.0.0 255.255.255.0 172.26.26.0
255.255.255.0 MYTACACS.
Traditional aaa command configuration and functionality continue to work as in
previous versions and are not converted to the ACL format. Hybrid
configurations, which are traditional configurations combined with the new ACL
configurations, are not recommended.
The syntax for the aaa authentication | authorization | accounting command is
as follows:
aaa authentication | authorization | accounting match acl_name inbound | outbound | if_name
group_tag
match acl_name
Specifies an access-list command statement

name.
inbound

being directed to the inside interface.
12-39
12-40
outbound

being directed to the outside interface.
if_name

sought and from whom.
group_tag
The group tab set with the aaa-server

command.
How to View Accounting

Information in CSACS-NT
www.cisco.com
CSPFA 2.012-33
Complete the following steps to add authorization rules for specific non-telnet,
FTP, or HTTP services in CSACS:
Step 1
Click Reports and Activity from the navigation bar. The Report and Activity
window opens.
Step 2
Click TACACS+ Accounting from the Reports to display the accounting records.
12-41
Accounting of Non-Telnet,
FTP, or HTTP Traffic
aaa accounting include | exclude acctg_service inbound |

outbound | if_name local_ip local_mask foreign_ip
foreign_mask group_tag
acctg_service = protocol or port
protocol: tcp (6), udp (17), or others (protocol #)
port = single port (e.g., 53), port range (e.g., 2000-2050), or port 0 (all ports)
(port is not used for protocols other than TCP or UDP)
pixfirewall(config)# aaa accounting include udp/53 inbound

0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
pixfirewall(config)# aaa accounting include udp/54-100
www.cisco.com
CSPFA 2.012-34
The syntax for the aaa accounting of non-Telnet, FTP, or HTTP traffic command
is as follows:
aaa accounting include | exclude acctg_service inbound | outbound | if_name local_ip
no aaa accounting include | exclude authen_service inbound | outbound | if_name group_tag
clear aaa [accounting [include | exclude authen_service inbound | outbound | if_name
group_tag]]
12-42
include acctg_service
The accounting service. Accounting is

provided for all services, or you can limit it
to one or more services. Possible values
are any, ftp, http, or telnet. Use any to
provide accounting for all TCP services. To
provide accounting for UDP services, use
the protocol/port form.
exclude acctg_service

authentication, authorization, or accounting
to the specified host. The exclude
option by enabling the user to specify a port
to exclude to a specific host or hosts.
inbound

outbound

if_name

foreign_ip address to determine where
local_ip

authenticated.
local_mask

is 0. Use 255.255.255.255 for a host.
foreign_ip

access the local__ip address. Use 0 to
mean all hosts.
foreign_mask

host.
group_tag

command.
12-43
Troubleshooting the AAA Configuration

This section discusses the procedure for verifying the authentication,
authorization, and accounting (AAA) configuration.
show Commands
show aaa-server
show aaa [authentication | authorization | accounting]

pixfirewall(config)# show aaa-server
aaa-server MYTACACS (inside) host 10.0.0.2 secretkey timeout 5
pixfirewall(config)# show aaa
aaa authentication any outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
MYTACACS
aaa authentication telnet console MYTACACS
aaa authorization telnet outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
MYTACACS
aaa accounting any outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
MYTACACS
www.cisco.com
CSPFA 2.012-36
The syntax for the show aaa-server and show aaa commands are as follows:
show aaa-server
clear aaa-server [group_tag]
no aaa-server group_tag (if_name) host server_ip key timeout seconds
show aaa [authentication | authorization | accounting]
12-44
group tag
An alphanumeric string that is the name of

the server group.
if_name
The interface name on which the server

resides.
host server_ip
The IP address of the TACACS+ or RADIUS

server.
key
A case-sensitive, alphanumeric keyword of

up to 127 characters that is the same value
as the key on the TACACS+ server. Any
characters entered past 127 are ignored.
The key is used between the client and
server for encrypting data between them.
The key must be the same on both the
client and server systems. Spaces are not
permitted in the key, but other special
characters are.
timeout seconds
A retransmit timer that specifies the duration

that the PIX Firewall retries access. Access
to the AAA server is retried four times
before choosing the next AAA server. The
default is 5 seconds. The maximum time is
30 seconds.
authentication
Displays user authentication, prompts user

for username and password, and verifies
information with the authentication server.
authorization
Displays TACACS+ user authorization for

services. (The PIX Firewall does not support
RADIUS authorization.) The authentication
server determines what services the user is
authorized to access.
accounting
Displays accounting services with the

authentication server. Use of this command
requires that you previously used the aaaserver command to designate an
authentication server.
12-45
show Commands (cont.)

show auth-prompt [prompt | accept | reject]

show virtual [http | telnet]
show timeout uauth

pixfirewall(config)# show
auth-prompt prompt prompt
auth-prompt prompt accept
auth-prompt prompt reject
auth-prompt
Authenticate to the Firewall
Youve been Authenticated
Authentication Failed
pixfirewall(config)# show timeout uauth

timeout uauth 3:00:00 absolute uauth 0:30:00 inactivity
pixfirewall(config)# show virtual
virtual http 192.168.0.2
virtual telnet 192.168.0.2
www.cisco.com
CSPFA 2.012-37
The syntax for the show auth-prompt, show timeout uauth, and the show
virtual commands are as follows:
show auth-prompt [prompt | accept | reject]
show timeout uauth
show virtual [http | telnet]
12-46
prompt
Displays the prompt users get when

authenticating.
accept
Displays the message users get when

successfully authenticating.
reject
Displays the message users get when

unsuccessfully authenticating.
timeout uauth
Displays the current uauth timer values for

all authenticated users.
http
Displays the virtual HTTP configuration.
telnet
Displays the virtual Telnet configuration.
Summary
This section summarizes what you have learned in this chapter.
Summary
Authentication is who you are, authorization is what you can
do, and accounting is what you did.
The PIX Firewall supports the following AAA protocols:
TACACS+ and RADIUS.
Users are authenticated with Telnet, FTP, or HTTP by the PIX
Firewall.
Cut-through proxy technology allows users through the PIX
Firewall after authenticating.
To enable AAA, two steps must be taken:
Configure AAA on the PIX Firewall.
Install and configure CSACS on a server.
www.cisco.com
CSPFA 2.012-39
12-47
Lab ExerciseConfigure AAA on the PIX

Firewall Using CSACS for Windows NT
Complete the following lab exercise to practice what you have learned in this
chapter.
Objectives
Install CSACS for a Windows NT server.
Add a user to the CSACS database.
Identify a AAA server and protocol.
Configure and test inbound authentication.
Configure and test outbound authentication.
Configure and test console access authentication.
Configure and test Virtual Telnet authentication.
Change and test authentication timeouts and prompts.
Configure and test authorization.
Configure and test accounting.
Visual Objective
The following figure displays the configuration you will complete in this lab
exercise.
12-48

P = Your pod number
All netmasks = 255.255.255.0
172.26.26.0
Internet
.50
Backbone server
web/FTP/TFTP
Perimeter router
.1
e1
192.168.P.0
.2
e0
.1
PIX Firewall
172.16.P.0
e2
.1
.2
e1
10.0.P.0
.3
Pod DMZ server

web/FTP
AAA server
Student
workstation
www.cisco.com
CSPFA 2.012-41
Task 1Install CSACS for a Windows NT Server

Perform the following steps to install CSACS on your Windows NT server:
Step 1
Install CSACS on your Windows NT server from the CD-ROM or from the files
on your hard drive, as indicated by the instructor.
When installing from the CD-ROM, complete the following:
Windows NT automatically starts the autorun.exe program and you are

prompted to install CSACS.
Click Install to start the installation process.
When installing from files in your hard drive, complete the following:
Open the folder where the installation files are located and double-click
the setup.exe program to start installation.
Or choose Start>Run and enter setup.exe with a full path to the file.
Step 2
Click OK in the Warning window.
Step 3
Click Accept to accept the Software License Agreement. The Welcome window
opens.
Step 4
Read the Welcome panel. Click Next to continue. The Before You Begin window
opens.
Step 5
Read and then select all four check boxes for the items in the Before You Begin
panel. This is a reminder of things you should do prior to installation. Click Next
to continue. The Choose Destination Location window opens.
Step 6
Use the default installation folder indicated in the Choose Destination Location
windows by clicking Next to continue. The Authentication Database
Configuration windows open.
12-49
Step 7
Verify that Check the Cisco Secure ACS database only is already selected in the
Authentication Database Configuration panel. Click Next to continue.
Step 8
Enter the following information in the Cisco Secure ACS Network Access Server
Details panel:
Authenticate users: TACACS+ (Cisco IOS)
Access server name: pixP
(where P =pod number)
Access server IP address: 10.0.P.1
Windows NT Server IP address: 10.0.P.3
TACACS+ or RADIUS key: secretkey

Step 9
Click Next to start the file installation process.
Step 10 Select all six items displayed in the Advanced Options panel. Click Next to
continue.
Step 11 Verify that Enable Log-in Monitoring is already selected in the Active Service
Monitoring panel. Click Next to continue.
CAUTION Do not select Yes, I want to configure Cisco IOS software now in the Network Access Server
Configuration panel; this only applies to Cisco IOS routers.
Step 12 Click Next to continue.

Step 13 Verify that the following are already selected in the Cisco Secure ACS Service
Initiation panel:
Yes, I want to start the Cisco Secure ACS Service now
Yes, I want Setup to launch the Cisco Secure ACS Administrator from my
browser following installation
Note
Do not select Yes, I want to review the Readme file.
Step 14 Click Next to start the CSACS service.

Step 15 Read the Setup Complete panel and then click Finish to end the installation
wizard and start your web browser with CSACS.
Task 2Add a User to the CSACS Database

Perform the following steps to add a user to the CSACS database in your
Windows NT server:
Step 1
12-50
The CSACS interface should now be displayed in your web browser. Click User
Setup to open the User Setup interface.
Step 2
Add a user by entering aaauser in the user field.
Step 3
Click Add/Edit to go into the user information edit window.
Step 4
Give the user a password by entering aaapass in both the Password and Confirm
Password fields.
Step 5
Click Submit to add the new user to the CSACS database. Wait for the interface
to return to the User Setup main window.
Task 3Identify a AAA Server and Protocol

Perform the following steps to identify a AAA server and a AAA protocol on the
PIX Firewall:
Step 1
Create a group tag called MYTACACS and assign the TACACS+ protocol to it:
pixP(config)# aaa-server MYTACACS protocol tacacs+
Step 2
Assign the CSACS IP address and the encryption key secretkey.

pixP(config)# aaa-server MYTACACS (inside) host 10.0.P.3 secretkey
Step 3
Verify your configuration:

pixP(config)# show aaa-server
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server MYTACACS (inside) host 10.0.P.3 secretkey timeout 5
Task 4Configure and Test Inbound Authentication

Perform the following steps to enable the use of inbound authentication on the
PIX Firewall:
Step 1
Configure the PIX Firewall to require authentication for all inbound traffic:
pixP(config)# aaa authentication include any inbound 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 MYTACACS
Step 2

pixP(config)# show aaa authentication
aaa authentication include any outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
Step 3
Enable console logging of all messages:

pixP(config)# logging console debug
Note
Step 4
If your web browser is open, close it. Choose File>Close from the web browsers
menu.
You must now test a peer pod inbound web authentication. Open your web
browser, and go to a peers DMZ web server:
http://192.168.Q.11
12-51
Step 5
When the web browser prompts you, enter aaauser for the username and aaapass
for the password. On your PIX Firewall console, you should see the following:
109001: Auth start for user '???' from 192.168.Q.10/1726 to 10.0.P.2/80
109011: Authen Session Start: user 'aaauser', sid 0
109005: Authentication succeeded for user 'aaauser' from 10.0.P.2/80 to
192.168.Q.10/1921 on interface outside
302001: Built outbound TCP connection 3928 for faddr 192.168.Q.10/1921 gaddr
192.168.P.10/80 laddr 10.0.P.3/80 (aaauser)
(where P = pod number, and Q = peer pod number)

Step 6
After a peer successfully authenticates to your PIX Firewall, display your PIX
Firewall authentication statistics:
pixP(config)# show uauth
Current
Most Seen
Authenticated Users
1
1
Authen In Progress
0
1
user 'pixuser' at 192.168.Q.10, authenticated
absolute timeout: 0:05:00
inactivity timeout: 0:00:00
Task 5Configure and Test Outbound Authentication

Perform the following steps to enable the use of outbound authentication on the
PIX Firewall:
Step 1
Configure the PIX Firewall to require authentication for all outbound traffic:
pixP(config)# aaa authentication include any outbound 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 MYTACACS
Step 2

pixP(config)# show aaa authentication
aaa authentication include any outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
aaa authentication include any inside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
Step 3
Test FTP outbound authentication from your Windows NT server:

C:\> ftp 172.26.26.50
Connected to 172.26.26.50
220-FTP authentication :
220
User (172.26.26.50:(none)): aaauser@ftpuser
331-Password:
331
Password: aaapass@ftppass
230-220 172.26.26.50 FTP server ready.
331-Password required for ftpuser
230-User ftpuser logged in.
230
ftp>
On your PIX Firewall console, you should see the following:

109001: Auth start for user '???' from 10.0.P.3/1726 to 172.26.26.50/21
12-52

172.26.26.50/21 on interface inside
302001: Built outbound TCP connection 3928 for faddr 172.26.26.50/21 gaddr
192.168.P.10/1726 laddr 10.0.P.3/1726 (aaauser)

Step 4
Display authentication statistics on the PIX Firewall:

Current
Most Seen
Authenticated Users
1
1
Authen In Progress
0
1
user 'aaauser' at 10.0.P.3, authenticated (P = your pod number)
Step 5
Clear the uauth timer:

pixP(config)# clear uauth
Current
Authenticated Users
0
Authen In Progress
0
Note
Step 6
Most Seen
1
1
If your web browser is open, close it. Choose File>Exit from the web browsers
menu.
Test web outbound authentication. Open your web browser and go to the
following URL:
http://172.26.26.50
Step 7
When you are prompted for a username and password, enter aaauser as the
username and aaapass as the password:
User Name: aaauser
Password: aaapass
Step 8
Display authentication statistics on the PIX Firewall:

Current
Most Seen
Authenticated Users
1
1
Authen In Progress
0
1
user 'pixuser' at 10.0.P.2, authenticated
Task 6Configure and Test Console Access Authentication

Perform the following steps to enable console Telnet authentication at the PIX
Firewall:
Step 1
Configure the PIX Firewall to require authentication for Telnet console

connections:
pixP(config)# aaa authentication telnet console MYTACACS
12-53
Step 2

pixP(config)# show
aaa authentication
aaa authentication
aaa authentication
Step 3
aaa authentication
include any outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
include any inside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
include any 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
Configure the PIX Firewall to allow console Telnet logins:

pixP(config)# telnet 10.0.P.3 255.255.255.255 inside

Step 4

pixP(config)# show telnet
10.0.P.3 255.255.255.255 inside

Step 5

Current
Authenticated Users
0
Authen In Progress
0
Step 6
Most Seen
1
1
Save your configuration:

pixP(config)# write memory
Step 7
Reboot your PIX Firewall:

pixP(config)# reload
Step 8
Telnet to the PIX Firewall console:

C:\> telnet 10.0.P.1
PIX passwd: cisco
Welcome to the PIX firewall
Copyright (c) 1996-1999 by Cisco Systems, Inc.
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706
Username: aaauser
Password: aaapass
Type help or '?' for a list of available commands.
pixP>

307002: Permitted Telnet login session from 10.0.P.3
12-54
111006: Console Login from aaauser at console
Task 7Configure and Test Virtual Telnet Authentication

Perform the following steps to enable the use of authentication with virtual Telnet
on the PIX Firewall:
Step 1
Configure the PIX Firewall to accept authentication to a virtual Telnet service:

pixP(config)# virtual telnet 192.168.P.5

Step 2
Verify the virtual Telnet configuration:

pixP(config)# show virtual telnet
virtual telnet 192.168.P.5

Step 3

Current
Authenticated Users
0
Authen In Progress
0
Step 4
Most Seen
1
1
Telnet to the virtual Telnet IP address to authenticate from your Windows NT

server:
C:\> telnet 192.168.P.5
Username: aaauser
Password: aaapass

Note
Step 5
menu.
Test that you are authenticated. Open your web browser and enter the following in
the URL field:
http://172.26.26.50
You should not be prompted to authenticate.

Step 6

Current
Authenticated Users
0
Authen In Progress
0
Most Seen
1
1
12-55
Note
Step 7
menu.
Test that you are not authenticated and need to reauthenticate. Open your web
browser and enter the following in the URL field:
http://172.26.26.50
Step 8
When you are prompted, enter aaauser for the username and aaapass for the
password.
Task 8Change and Test Authentication Timeouts and Prompts

Perform the following steps to change the authentication timeouts and prompts:
Step 1
View the current uauth timeout settings:

pixP(config)# show timeout uauth
Step 2
Set the uauth absolute timeout to 3 hours:

pixP(config)# timeout uauth 3 absolute
Step 3
Set the uauth inactivity timeout to 30 minutes:

pixP(config)# timeout uauth 0:30 inactivity
Step 4
Verify the new uauth timeout settings:

pixP(config)# show timeout uauth
Step 5
View the current authentication prompt settings:

pixP(config)# show auth-prompt
Nothing should be displayed.

Step 6
Set the prompt that users get when authenticating:

pixP(config)# auth-prompt prompt Please Authenticate
Step 7
Set the message that users get when successfully authenticating:

pixP(config)# auth-prompt accept Youve been Authenticated
Step 8
Set the message that users get when their authentication is rejected:
pixP(config)# auth-prompt reject Authentication Failed, Try Again
Step 9
Verify the new prompt settings:

pixP(config)# show
auth-prompt prompt
auth-prompt accept
auth-prompt reject
auth-prompt
Please Authenticate
You've been Authenticated
Authentication Failed, Try Again
Step 10 Clear the uauth timer:

Current
Authenticated Users
0
Authen In Progress
0
12-56
Most Seen
1
1
Step 11 Telnet to the Virtual Telnet IP address to test your new authentication prompts.
From your Windows NT server, enter the following:

C:\> telnet 192.168.P.5
Please Authenticate
Username: wronguser
Password: wrongpass Authentication Failed, Try Again
Please Authenticate
Username: aaauser
Password: aaapass
Youve been Authenticated
Task 9Configure and Test Authorization

Perform the following steps to enable the use of authorization on the PIX
Firewall:
Step 1
Configure the PIX Firewall to require authorization for all outbound FTP traffic:
pixP(config)# aaa authorization include ftp outbound 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 MYTACACS
Step 2
Configure the PIX Firewall to require authorization for all outbound ICMP traffic:
pixP(config)# aaa authorization include icmp/8 outbound 0.0.0.0 0.0.0.0 0.0.0.0
0.0.0.0 MYTACACS
Step 3

pixP(config)# show aaa authorization
aaa authorization include ftp inside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
aaa authorization include 1/8 inside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
Step 4
Test ICMP Echo Request failure from your Windows NT server:

C:\> ping 172.26.26.50
Pinging 172.26.26.50 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

109001: Auth start for user 'aaauser' from 10.0.P.3/0 to 172.26.26.50/0
109008: Authorization denied for user 'aaauser' from 10.0.P.2/0 to 172.26.26.50/0
on interface inside

Step 5
Test FTP authorization failure from your Windows NT server:

C:\> ftp 172.26.26.50
220
12-57

331-Password:
331
530
530Authorization Denied
530
Error: Connection closed by foreign host.

109008: Authorization denied for user 'aaauser' from 10.0.P.3/1364 to

Step 6
Click Group Setup to open the Group Setup interface.
Step 7
Choose Default Group (1 user) from the Group drop-down menu.
Step 8
Verify that your user belongs to the selected group. Click Users in Group to
display the users under that group. The following information should be shown
for the user:
Step 9
User: aaauser
Status: Enabled
Group: Default Group (1 user)
Click Edit Settings to go to the Group Settings for your group.
Step 10 Scroll down in Group Settings until you find IOS Commands, and select the IOS
Commands check box.

Step 11 Select the Command check box.
Step 12 Enter ftp in the Command field.
Step 13 Enter permit 172.26.26.50 in the Arguments field.
Step 14 Click Submit to save the changes. Wait for the interface to return to the Group
Setup main window.

Step 15 Click Edit Settings to go to the Group Settings for your group again.
Step 16 Scroll down in Group Settings until you find IOS Commands.
Step 17 Select the Command check box.
Step 18 Enter 1/8 in the Command field.
Step 19 Select Permit in the Unlisted arguments field.
Step 20 Click Submit + Restart to save the changes and restart CSACS. Wait for the
interface to return to the Group Setup main window.

Step 21 Test FTP authorization success from your Windows NT server:
C:\> ftp 172.26.26.50
12-58
220
331-Password:
331
230-220 172.26.26.50 FTP server ready.
230
ftp>

109007: Authorization permitted for user 'aaauser' from 10.0.P.3/1726 to
302001: Built outbound TCP connection 3928 for faddr 172.26.26.50/21 gaddr
192.168.P.10/1726 laddr 10.0.P.3/1726 (aaauser)

Step 22 Test ICMP Echo Request success from your Windows NT server:
C:\> ping 172.26.26.50
Pinging 172.26.26.50 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 172.26.26.50: bytes=32 time<10ms TTL=128
Reply from 172.26.26.50: bytes=32 time<10ms TTL=128

109001: Auth start for user 'aaauser' from 10.0.P.3/0 to 172.26.26.50/0
109007: Authorization permitted for user 'aaauser' from 10.0.P.2/0 to
Task 10Configure and Test Accounting

Perform the following steps to enable the use of accounting on the PIX Firewall:
Step 1
Configure the PIX Firewall to perform accounting for all outbound traffic:
pixP(config)# aaa accounting include any outbound 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
MYTACACS
Step 2

pixP(config)# show aaa accounting
aaa accounting include any inside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 MYTACACS
Step 3

12-59

Current
Authenticated Users
0
Authen In Progress
0
Step 4
Most Seen
1
1
Test FTP outbound accounting from your Windows NT server:

C:\> ftp 172.26.26.50
220
331-Password:
331
230-220 172.26.26.50 FTP server ready.
230
ftp>
Step 5
View the accounting records. On CSACS, click Reports and Activity to open the
Reports and Activity interface.
Step 6
Click the TACACS+ Accounting link.
Step 7
Click the TACACS+ Accounting active.csv link to open the accounting records.
You should see the following:
Date
Time
4/27/00
11:14:45
Note
Step 8
User-Name GroupName
aaauser
Default
Group
Caller-Id
Acct-Flags
10.0.P.2
start
NASPortname
PIX
NAS-IPAddress
10.0.P.1
cmd
ftp
If your web browser is open, close it. Choose File>Exit from the web browsers
menu.
Test web outbound accounting. Open your web browser and enter the following in
the URL field:
http://172.26.26.50
Step 9
Click the TACACS+ Accounting link.
Step 10 Click the TACACS+ Accounting active.csv link to open the accounting records.
You should see the following:

Date
Time
4/27/00
11:16:35 aaauser Default

Group
Group
10.0.0.2 start

Group
Group
Group
10.0.0.2 start
4/27/00
4/27/00
4/27/00
4/27/00
12-60
UserName
Group- Caller-Id AcctName

Flags
10.0.0.2 start
10.0.0.2 stop
10.0.0.2 stop
NASNAS-IP- cmd
Portna Address
me
PIX
10.0.0.1 http
PIX
10.0.0.1 http
PIX
10.0.0.1 http
PIX
10.0.0.1 http
PIX
10.0.0.1 http
4/27/00
4/27/00
4/27/00
4/27/00
4/27/00
4/27/00
4/27/00

Group
Group
Group
Group
Group
Group
Group
10.0.0.2 start
10.0.0.2 start
10.0.0.2 start
10.0.0.2 start
10.0.0.2 start
10.0.0.2 start
10.0.0.2 start
PIX
10.0.0.1 http
PIX
10.0.0.1 http
PIX
10.0.0.1 http
PIX
10.0.0.1 http
PIX
10.0.0.1 http
PIX
10.0.0.1 http
PIX
10.0.0.1 ftp
Step 11 Disable AAA by entering the following command.

pixP(config)# clear aaa
Step 12 Turn off the logging:

pixP(config)# no logging console debug
12-61
13
Event Notification and

Alarm Reporting
Overview
This chapter describes the event notification and alarm reporting features in Cisco
Secure Policy Manager (CSPM).
Objectives
Event notification
Alarm reporting
Sample alarm reports
Summary
Objectives
Objectives

Add a SMTP server to the NTT.
Configure CSPM for IDS event notification.
Generate CSIDS alarm reports.
13-2
www.cisco.com
CSIDS 2.113
Event Notification
This section discusses the event notification features, e-mail notification, script
execution, and how to configure these features within CSPM.
Features
Performed by the CSPM host

Define actions based on alarm severity level
Provides e-mail notificationcustom message
description
Provides custom script executionscript must
handle the passed arguments
www.cisco.com
CSIDS 2.113
The Cisco Intrusion Detection System (CIDS) is able to notify network security
administrators via e-mail. The e-mail notification feature provides a method to
notify network security administrators while away from the CSPM host. The email message can be customized to provide a detailed or brief message regarding
the alarm generated.
CIDS also has a script execution feature that enables network security
administrators to create and execute custom scripts. The CSPM host passes alarm
arguments to the script, which handles the arguments. The network security
administrators could, for example, create a script that will generate an SNMP trap,
which could then be sent to a central network management station (NMS).
Both the e-mail notification method and script execution is assigned per alarm
severity level. CSPM provides three alarm severity levels: low, medium, and high.
E-mail notification and script execution can be performed simultaneously per
alarm severity level. For instance, you could assign an e-mail to be sent to the
network security administrator for high level alarms and a script be executed that
would also send an SNMP trap to the NMS.
Event Notification and Alarm Reporting
13-3
E-mail Notification
Sensor
CSPM
Untrusted
network
Targets
SMTP
server
Hacker
www.cisco.com
CSIDS 2.113
The illustration demonstrates how the e-mail notification process occurs. The
sensor detects an attack launched by the hacker and generates an alarm that is sent
to CSPM. Based on the severity of the attack, CSPM generates an e-mail message
and forwards the message to a Simple Mail Transfer Protocol (SMTP) server. The
SMTP server delivers the message to the defined recipients. CSPM also enables
you to specify multiple e-mail recipients.
Note
13-4
CSPM currently delivers messages only to an SMTP server.
Configuration Tasks
Add an SMTP server to the NTT.

Assign an SMTP server to a CSPM host.
Choose a CIDS event alarm severity level.
Choose a log event and an issue disposition.
Assign the scheduling values.
Define the message subject and content.
Choose the e-mail method and assign
recipients.
Apply the notification configuration.
Save the changes to CSPM.
www.cisco.com
CSIDS 2.113
To configure e-mail notification in CSPM, perform the following tasks:
Note
Add an SMTP server to the Network Topology Tree (NTT). This task may
involve adding a new network to the CSPM NTT.
Add an SMTP server only if one does not already exist in the NTT.
Assign an SMTP server to the CSPM hosts properties.
Choose the CIDS event alarm severity level. Notification can be configured
per alarm severity level.
Choose a log event and an issue disposition. To configure notification

settings, you must choose Log Event and Issue notification specified below
disposition.
Assign scheduling values. Define when an event will cause a notification to

be generated.
Define the message subject and content. Customize the subject and content of
the e-mail message.
Choose the E-mail notification method and assign e-mail recipients. Select email as the notification method and assign who will receive the e-mail
messages.
Apply the configuration. This task applies the notification settings.
Save the changes to CSPM. This task saves the configuration changes made
to CSPM and enables the notification feature.
13-5
Add a New Host
Right-click
Right-click and
and
choose
choose
New>Host
New>Host
Select
Select the
the
network
network
www.cisco.com
CSIDS 2.113
To add a new SMTP host to the CSPM NTT, perform the following tasks:
Step 1
Select the network where the SMTP server exists.

Note
13-6
If the SMTP server does not exist in a defined network within the NTT, a new
network object must be created.
Step 2
Right click and choose New>Host. The Host window opens in the right pane.
Step 3
Rename the hostname in the NTT. (This step is recommended but not required.)
Assign Host Information
Enter
Enter the
the IP
IP
Address
Address
Click
Click Add
Add
www.cisco.com
CSIDS 2.113
Step 4
Enter the IP address of the SMTP server in the IP addresses field.
Step 5
Click the Add button. The IP address appears in the list box below the IP
Addresses field.
13-7
Add SMTP Service
Click
Click Add
Add
Choose
Choose
SMTP
SMTP
CSIDS 2.113
Step 6
Click the Add button associated with the Resident Client/Server products. The
Add Client/Server Product window opens.
Step 7
Choose SMTP from the list of product types.
Step 8
Click the OK button in the Add Client/Server Product window.

Note
13-8
www.cisco.com
The default product name is the product name with a version number appended
(for example, SMTP 1).
Rename SMTP Service
Click
Click
SMTP
SMTP
Rename
Rename
Service
Service
Name
Name
Click
Click
OK
OK
Step 9
www.cisco.com
CSIDS 2.113
Click the SMTP product name tab. The SMTP general settings screen opens.
Step 10 Rename the product name. (This step is optional).

Step 11 Click the OK button.
Step 12 Click the Save button on the toolbar.
13-9
Assign an SMTP Server
Select
Select
CSPM
CSPM Host
Host
Choose
Choose
SMTP
SMTP server
server
www.cisco.com
CSIDS 2.113
The CSPM host must know about an SMTP host before the e-mail notification
can be enabled. To assign an SMTP server to the CSPM host, perform the
following tasks:
13-10
Step 1
Select the CSPM host from the NTT. The CSPM general window opens.
Step 2
Choose the SMTP server from the SMTP Server drop-down menu.
Step 3
Click the OK button.
Step 4
Click the Save button on the toolbar.
Configure Notification
Choose
Choose
Tools>Configure
Tools>Configure Notification
Notification
www.cisco.com
CSIDS 2.113
CSPM has been configured to enable the e-mail notification feature. Now the email notification feature needs to be configured. To configure the e-mail
notification feature, perform the following tasks:
Step 1
Choose Tools>Configure Notification from the main menu. The Configure

Logging and Notification window opens in the right pane.
13-11
Select Event Category, Alarm

Severity and Disposition
Select
Select
IDS
IDS Events
Events
Choose
Choose the
the
alarm
alarm
severity
severity
Select
Select
Log
Log event
event and
and
issue
issue notification
notification
specified
specified below
below
www.cisco.com
CSIDS 2.113
CSPM is able to log and notify on events including CIDS. CIDS notification is
handled by selecting IDS Events.
Note
Step 2
Select IDS Events in the Select Event Category group box.
Step 3
Choose the alarm severity level from the Event Description column.
Note
Step 4
13-12
For more information regarding CSPM notifications, refer to the Cisco Secure
Policy Manager Configuring and Reporting Documentation.
Notification is assigned per alarm severity level. You have to configure each alarm
severity level individually.
Select Log event and issue event specified below from the Event Disposition
group box. The Notification Scheduling, Notification Message, and Notification
Methods group boxes appear.
Assign Scheduling Values
Assign
Assign
values
values
www.cisco.com
CSIDS 2.113
CIDS enables the network security administrator to configure when a CIDS alarm
triggers a notification method. The following table identifies the configurable
scheduling parameters.
Scheduling Parameter
Description
Issue First Notification

After N events
19998
The initial notification is generated after the

defined number of CIDS events (alarms) is
triggered. The default value is 1.
Notify again every N

events
19998
A subsequent notification is generated after initial

notification is triggered. The default value is 1.
Reset count every N

hours
19998
The time interval in which the CIDS event

counters is reset. The default value is 1.
The following is an example of how notification scheduling values are affected

when a notification is generated. The notification values are assigned as follows:
Issue First Notification After value is assigned 5
Notify Again Every value is 10
Reset Count Every value is 2
The initial notification is generated after five occurrences of the CIDS event are
triggered. The next notification is generated after the tenth CIDS event is
triggered because the fifth alarm was triggered, which would be the fifteenth
actual event. The CIDS event counter is reset after two hours.
13-13
Define the Message Subject

and Content
Click
Click
Message
Message
Enter
Enter information
information in
in
the
the Subject
Subject and
and
Message
Message fields
fields
www.cisco.com
CSIDS 2.113
CSPM enables the network security administrator to customize the e-mail

message subject and body content.
The Notification Message group box contains the Include event description check
box, Message button, and the Require confirmation check box. The following
describes each item:
Include event description check boxThe CIDS event description will be

included in the body of the e-mail message. The CIDS event descriptions are
High Severity Alarms, Low Severity Alarms, and Medium Severity Alarms.
Message buttonProvides the mechanism to customize the e-mail message

subject line and body content. The From: line in the e-mail message
currently cannot be customized. The e-mail message will be from the user
Cisco Secure Policy Manager.
Require confirmation check boxThis feature is disabled.
Note
The alarm variable names are case sensitive.
The body of the message can be customized with alarm data. The following tables
identify the alarm variables that can be defined in the body of the e-mail message.
Applicable to All CIDS Event Types
13-14
Alarm Variable
Description
${MsgType}
Integer value indicating the event type
2Error
3Command
4Alarm
Alarm Variable
Description
${RecordID}
Record the identification for the event.
${GlobalTime}
GMT timestamp for when the event was generated (expressed in

seconds since midnight, January 1, 1970).
${LocalTime}
Sensor local timestamp for when the event was generated (expressed
in seconds since midnight, January 1, 1970).
${DateStr}
Sensor local date stamp for when the event was generated (in
YYYY/MM/DD format).
${TimeStr}
Sensor local timestamp for when the event was generated (in
HH:MM:SS format).
${ApplID}
Postoffice application identification on the Sensor that generated the

event.
${HostID}
Postoffice host identification of the Sensor that generated the event.
${OrgID}
Postoffice organization identification on the Sensor that generated the

event.
${MsgCount}
Number of events that occurred in the current interval, causing this

notification to be generated.
Applicable to Alarm Events Only

Alarm Variable
Description
${SrcDirection}
Location of the source (attacking) entity with respect to the

protected network. Values are IN for inside the protected
network, or OUT for outside the protected network.
${DstDirection}
Location of the destination (attacked) entity with respect to

the protected network. Values are IN for inside the
protected network, or OUT for outside the protected
network.
${AlarmLevel}
Severity level of the alarm.
${SigID}
Signature identification that triggered the alarm.
${SubSigID}
Sub-signature identification that triggered the alarm (if

applicable).
${ProtocolType}
The protocol of the alarmcurrently always TCP/IP.
${SrcIpAddr}
IP address of the source (attacking) entity.
${DstIpAddr}
IP address of the destination (attacked) entity.
${SrcIpPort}
IP port number of the source (attacking) entity.
${DstIpPort}
IP port number of the destination (attacked) entity.
${RouterIpAddr}
IP address of the router that sent the syslog message to

the Sensor (10000 series alarms only) otherwise 0.0.0.0.
${AlarmDetails}
Details and/or context data for the alarm.
Applicable to Command Events Only

Alarm Variable
Description
${CmdApplID}
Postoffice application identification on the entity that issued

the command.
${CmdHostID}
Postoffice host identification of the entity that issued the

command.
13-15
Alarm Variable
Description
${CmdOrgID}
Postoffice organization identification of the entity that

issued the command.
${CmdMsg}
The command that was issued.
Applicable to Error Events Only
13-16
Alarm Variable
Description
${ErrMsg}
The generated error message.
Select the E-mail Method
Select
Select
E-Mail
E-Mail
www.cisco.com
CSIDS 2.113
The notification method now needs to be selected to enable e-mail notification.

Note
Step 5
The e-mail notification method is grayed out if an SMTP server has not been
assigned to the CSPM host.
Select E-Mail in the Notification Methods group box. The Addresses button
becomes available for selection.
Note
The e-mail notification and script execution notification methods can be enabled
simultaneously.
13-17
Assign the E-mail Recipients
Click
Click
Addresses
Addresses
Enter
Enter the
the
e-mail
e-mail
addresses
addresses of
of
the
the recipients
recipients
Click
Click
Add
Add
www.cisco.com
CSIDS 2.113
Now you need to assign who will receive the e-mail messages once the
notification is triggered based on the notification scheduling values.
Step 6
Click the Addresses button. The E-mail Recipients window opens.
Step 7
Enter the e-mail addresses in the Recipient(s) text box.

Note
13-18
The addresses can be comma delimited. There is a 30-character limit for the
Recipient(s) text box. Use the Add feature to add additional e-mail addresses to
overcome this limitation.
Step 8
Click the Add button to add the recipient. You can add multiple recipients by
repeating Step 7 and this step.
Step 9
Click the OK button when you finish adding all e-mail recipients.
Apply the Configuration
Click
Click
Apply
Apply
www.cisco.com
CSIDS 2.113
At this point, you will need to apply the notification configuration.

Step 10 Click the Apply button. The configuration is applied and the Apply button is
grayed out.
13-19
Save the Changes
www.cisco.com
CSIDS 2.113
To enable the notification feature, the configuration setting changes must be saved
in CSPM.
Step 11 Click the Save button on the toolbar.
The e-mail notification feature configuration is complete. Notification is

configured per alarm severity level. Repeat the previous steps for each alarm
severity level.
13-20
Script Execution
CSPM
Sensor
script.bat
Untrusted
network
Targets
Hacker
www.cisco.com
CSIDS 2.113
The figure demonstrates how the script execution process occurs. The Sensor
detects an attack launched by the hacker and generates an alarm, which is sent to
CSPM. Based on the severity of the attack, CSPM executes a script. CSPM then
passes alarm arguments to the script or program, and the script parses the
arguments and performs the defined actions.
Note
The script must be executable. The script can be a binary executable (that is, a
program).
13-21
Configuration Tasks
Choose the CIDS event alarm severity level.
Choose the log event and issue notification
disposition.
Assign the notification scheduling values.
Choose the script notification method.
Assign the scripts to be executed.
Apply the notification configuration.
Save the changes to CSPM.
www.cisco.com
CSIDS 2.113
To configure script execution in CSPM, perform the following tasks:
13-22
Choose the CIDS event alarm severity levelNotification can be configured

per alarm severity level.
Choose the log event and issue dispositionTo configure notification

settings you must choose Log Event and Issue notification disposition.
Assign the scheduling valuesDefine when an event will cause a

notification to be generated.
Choose the script notification methodSelect a script as the notification

method.
Assign the scripts to be executedThis task assigns the names of the

executable scripts or programs that will be executed.
Apply the configurationThis task applies the notification settings.
Save the changes to CSPMThis task saves the configuration changes made
to CSPM and enables the notification feature.
Configure Notification
Choose
Choose
Tools>Configure
Tools>Configure Notification
Notification
www.cisco.com
CSIDS 2.113
To configure the script execution, perform the following tasks:

Step 1
Choose Tools>Configure Notification from the main menu. The Configure

Logging and Notification window opens in the right pane.
13-23
Select Event Category, Alarm

Severity and Disposition
Select
Select
IDS
IDS Events
Events
Select
Select the
the
Alarm
Alarm
Severity
Severity
Select
Select
Log
Log event
event and
and
issue
issue notification
notification
specified
specified below
below
www.cisco.com
CSIDS 2.113
CSPM is able to log and notify on events including CIDS. CIDS notification is
handled by selecting IDS Events.
Note
Step 2
Select IDS Events from the Select Event Category group box.
Step 3
Select the alarm severity level from the Event Description column.
Note
Step 4
13-24
For more information regarding CSPM notifications, refer to the Cisco Secure
Policy Manager Configuring Notification and Reporting documentation.
Notification is assigned per alarm severity level. You will have to configure each
alarm severity level individually.
Select Log event and issue event specified below from the Event Disposition
box. The Notification Scheduling, Notification Message, and Notification
Methods group boxes appear.
Assign the Scheduling Values
Assign
Assign
values
values
www.cisco.com
CSIDS 2.113
CIDS enables the network security administrator to configure when a CIDS alarm
triggers a notification method. The following table identifies the configurable
scheduling parameters.
Scheduling Parameter
Description
Issue First Notification

After N events
19998
The initial notification is generated after the

defined number of CIDS events (alarms) is
triggered. The default value is 1.
Notify again every N

events
19998
A subsequent notification is generated after initial

notification is triggered. The default value is 1.
Reset count every N

hours
19998
The time interval in which the CIDS event

counters is reset. The default value is 1.
The following is an example of how notification scheduling values are affected

when a notification is generated. The notification values are assigned as follows:
Issue First Notification After value is assigned 5
Notify Again Every value is 10
Reset Count Every value is 2
The initial notification is generated after five occurrences of the CIDS event are
triggered. The next notification is generated after the tenth CIDS event is
triggered because the fifth alarm was triggered, which would be the fifteenth
actual event. The CIDS event counter is reset after two hours.
13-25
Select the Script Method
www.cisco.com
CSIDS 2.113
The notification method now needs to be selected to enable script execution.

Note
Step 5
Select Script in the Notification Methods group box. The Name button becomes
available for selection.
Note
13-26
The script notification method can function properly without an SMTP defined in
the NTT.
The e-mail notification and script execution notification methods can be enabled
simultaneously.
Assign the Executable Script
Enter
Enter the
the
script
script name
name
Click
Click
Add
Add
Click
Click
Name
Name
www.cisco.com
CSIDS 2.113
Now you need to assign the name of the script to be executed once the
notification is triggered based on the notification scheduling values.
Step 6
Click the Name button in the Notification Methods group box. The Notification
Script(s) window opens.
Step 7
Enter the location and names of the scripts in the Script Name(s) text box.
Note
It is recommended to enter the full path name of the location of the script. If the full
path name is not given, CSPM will attempt to locate the script in the system
executable path. The system path is defined by the PATH system variable.
The script must be executable by the CSPM host, and it is responsible for parsing
the arguments passed to it by CSPM. The tables below identify the arguments that
will be passed to the script.
Note
The arguments are sent to the script in the order listed. The arguments sent to the
script are dependent on the IDS event type except for events applicable to all IDS
event types.
Applicable to all IDS Event Types

Alarm Variable
Description
${MsgType}
Integer value indicating the event type
2Error
3Command
4Alarm
13-27
Alarm Variable
Description
${RecordID}
Record ID for the event.
${GlobalTime}
GMT timestamp for when the event was generated, expressed in

seconds since midnight, January 1, 1970.
${LocalTime}
Sensor local timestamp for when the event was generated, expressed
in seconds since midnight, January 1, 1970.
${DateStr}
Sensor local date stamp for when the event was generated, in
YYYY/MM/DD format.
${TimeStr}
Sensor local timestamp for when the event was generated, in

HH:MM:SS format.
${ApplID}
Postoffice application identification on the Sensor that generated the

event.
${HostID}
Postoffice host identification of the Sensor that generated the event.
${OrgID}
Postoffice organization identification on the Sensor that generated the

event
${MsgCount}
Number of events that occurred in the current interval, causing this

notification to be generated. (Note that the message count is passed
in as the last parameter in the argument list for all event types)
Note
The message count is passed in as the last parameter in the argument list for all
event types.
Applicable to Alarm Events Only
13-28
Alarm Variable
Description
${SrcDirection}
Location of the source (attacking) entity with respect to the

protected network. Values are IN for inside the protected
network, or OUT for outside the protected network.
${DstDirection}
Location of the destination (attacked) entity with respect to

the protected network. Values are IN for inside the
protected network, or OUT for outside the protected
network.
${AlarmLevel}
Severity level of the alarm.
${SigID}
Signature identification that triggered the alarm.
${SubSigID}
Sub-signature identification that triggered the alarm (if

applicable).
${ProtocolType}
The protocol of the alarm currently always TCP/IP.
${SrcIpAddr}
IP address of the source (attacking) entity.
${DstIpAddr}
IP address of the destination (attacked) entity.
${SrcIpPort}
IP port number of the source (attacking) entity.
${DstIpPort}
IP port number of the destination (attacked) entity.
${RouterIpAddr}
IP address of the router which sent the syslog message to

the sensor (10000 series alarms only) otherwise 0.0.0.0.
${AlarmDetails}
Details and/or context data for the alarm.
Applicable to Command Events Only

Alarm Variable
Description
${CmdApplID}
Postoffice application identification on the entity that issued

the command.
${CmdHostID}
Postoffice host identification of the entity that issued the

command.
${CmdOrgID}
Postoffice organization identification of the entity that

issued the command.
${CmdMsg}
The command that was issued.
Applicable to Error Events Only

Alarm Variable
Description
${ErrMsg}
The generated error message.
13-29
Apply the Configuration
www.cisco.com
CSIDS 2.113
At this point, you will need to apply the notification configuration.

Step 8
13-30
Click the Apply button. The configuration is applied and the Apply button is
grayed out.
Save the Changes
www.cisco.com
CSIDS 2.113
To enable the script execution feature, the configuration setting changes must be
saved in CSPM.
Step 9
Click the Save button on the toolbar.

The script execution notification feature configuration is complete. Notification is
configured per alarm severity level. Repeat the previous steps for each alarm
severity level.
13-31
Alarm Reporting
This section discusses the alarm reporting feature of CSPM.
Features
Reports generated from CSPM database
Reports accessible remotely via HTTP, HTTPS,
and the CSPM View Reports feature
Customizable reports
Summary Reports
Top n Reports
Sensor Reports
Day and Hour Reports
Correlation Reports
www.cisco.com
CSIDS 2.113
CSPM has a powerful alarm reporting feature that provides the network security
administrator with the tool to generate custom CIDS reports. The alarm reports
are generated from the data in the CSPM alarm database.
Note
Reports cannot currently be generated from archived or offline CIDS log files.
The reports are accessible via the following three methods:
HTTPThe reports can be accessed remotely via a web browser using the
HTTP protocol. This method is not recommended because information is
sent in clear-text.
HTTPSThe reports can be access remotely via a web browser using Secure
Socket Layer, which provides an encrypted session. It is recommended to use
this method when accessing and generating reports outside of CSPM.
CSPM View ReportsCSPM provides a secure method of accessing reports

via the View Reports feature in CSPM.
The alarm reporting feature provides a mechanism to generate customized reports.

The following are the reports that can be customized and generated:
13-32
Intrusion Detection Summary
Top Sources of Alarms
Top Destinations of Alarms
Top Alarms
Top Source Destination Pairs of Alarms
Alarm Source
Alarm Destination
Alarms
Alarms Source Destination Pair
Alarms by Hour
Alarms by Day
Alarms by Sensor
Sensor Alarm Correlation
13-33
View Reports (CSPM)
Choose
Choose
Tools>View
Tools>View
Reports
Reports
www.cisco.com
CSIDS 2.113
To view the CIDS alarm reports from within CSPM, perform the following tasks:
Step 1
13-34
Choose Tools>View Reports from the main menu. The Cisco Secure Policy
Manager Reports window opens in the right pane.
On Demand Reports
www.cisco.com
CSIDS 2.113
Currently CIDS alarm reports can only be generated on demand.

Step 2
Click the On Demand button. The CSPM Reports index window opens in the
right pane.
Note
The remaining discussion focuses on accessing the reports via a web browser.
The same alarm reports can be generated from within CSPM.
13-35
Accessing the Reports (HTTP)
www.cisco.com
CSIDS 2.113
The alarm reports can be accessed remotely via HTTP. However, this method is
considered insecure because the login information and the report data will
traverse the network in the clear. This method may be acceptable for out-of-band
management networks.
To access reports via HTTP, perform the following tasks:
Step 1
Launch a web browser.
Step 2
Point the web browser to port 8080 on the CSPM host:

http://director0:8080
Step 3
Select the report to generate. The Enter Network Password window opens.
Step 4
Log in with a valid CSPM user account with privileges to generate and view
reports.
Note
13-36
Once you are authenticated, you will not be prompted again.
Accessing the Reports

(HTTPS)
www.cisco.com
CSIDS 2.113
The alarm reports can be accessed remotely securely via HTTPS. The HTTPS
method uses Secure Sockets Layer (SSL) to ensure privacy.
To access reports via HTTPS, perform the following tasks:
Step 1
Launch a web browser.
Step 2
Point the web browser to the CSPM host:

https://director0
or
https://director0:443
Step 3
Select the report to generate. The Enter Network Password window opens.
Step 4
Log in with a valid CSPM user account with privileges to generate and view
reports.
Note
Once you are authenticated, you will not be prompted again.
13-37
www.cisco.com
CSIDS 2.113
The Intrusion Detection Summary report has the following configurable filters:
Time RangeThe time range filter enables the network security

administrator to generate a report within a specified time range.
Start/EndDrop-down menus that enable you to specify a time range in

which to query the database for alarms.
Source DirectionDrop-down menu that enables you to select the

keyword IN or OUT as the direction.
Destination DirectionDrop-down menu that enables you to select the

SignaturesThe signatures filter enables the network security administrator

to generate a report based on all signatures, specific signatures, or signature
categories.
13-38
LastThis filter enables you to query the database based on alarms

received within the last hour, day, minute, or second.
Destination DirectionThe source direction filter enables the network

security administrator to generate a report based on the destination of the
attack.
Since dawn of timeThe default selection that will query the database
for the oldest possible record.
Source DirectionThe source direction filter enables the network security

administrator to generate reports based on the source of the attack.
Time ZoneDrop-down menu that enables you to choose the

appropriate time zone.
All SignaturesAll known CIDS signatures.
General SignaturesSelection box that enables you to select a specific

signature or multiple signatures.
Signature CategoriesSelection box that enables you to select a specific
signature category for multiple categories. The following are the
categories from which to select:
Signature Category Names
Back Orifice Signatures
RPC-based Application
Signatures
Cisco IOS Signatures
SATAN Signatures
DNS Signatures
Security Violation Signatures
Finger Signatures
SMTP/Sendmail Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
String Match Signatures
IDENT Signatures
TCP Header Signatures
IMAP Signatures
TCP Hijack Signatures
INN Signatures
Telnet Signatures
IP Header Signatures
Loki Signatures
UDP Header Signatures
POP Signatures
Windows/Net BIOS Signatures
PostOffice Comm Status
WWW Signatures
Alarm LevelSelection box that enables you to select a specific alarm

severity level. The possible values are Low, Medium, and High.
Sensor OrganizationThe Sensor organization filter enables the network

security administrator to generate a report based on a CIDS organization
name.
Rlogin Signatures
Alarm LevelThe alarm level filter enables the network security

administrator to generate a report based on the alarm severity level.
Signatures
Sensor OrganizationSelection box that enables you to select a specific

organization name or multiple organization names. The possible values
are organization names known to CSPM.
13-39
Top Sources of Alarms
www.cisco.com
CSIDS 2.113
The Top Sources of Alarm report has the following configurable filters:




categories.
13-40

security administrator to a generate report based on the destination of the
attack.
Time ZoneDrop-down menu that enables you to choose the

appropriate time zone.

Note
Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures
Any AddressAll destination address are included.

Single AddressA specific IP address is specified. The IP address is
specified by choosing a value for each IP address octet from a drop-down
menu.
Address RangeA range of IP addresses are included from the given
Start Address to the End Address. The Start and End IP addresses are
menu.

Top NThe Top N filter enables the network security administrator to

generate a report based on the top number (N) alarms.
Zero is currently not included as a valid range for any octet.
Rlogin Signatures
Destination IP AddressThe Destination IP address filter enables the

security administrator to generate a report based on the destination IP address
of the attack.
Signatures
Top NA numeric value must be entered in the Top N text box.
SensorThe Sensor filter enables the network security administrator to

generate a report based on a CIDS Sensor name.
13-41
13-42
SensorSelection box that enables you to select a specific Sensor name

or multiple Sensor names. The possible values are Sensor names known
to CSPM.
Top Destinations of Alarms
www.cisco.com
CSIDS 2.113
The Top Destination of Alarm report has the following configurable filters:




categories.

attack.
Time ZoneDrop-down menu that enables you to select the appropriate

time zone.

13-43
Note
13-44
Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.


Rlogin Signatures
Source IP AddressThe Source IP address filter enables the security

administrator to generate a report based on the source IP address of the
attack.
Signatures


to CSPM.
13-45
Top Alarms
www.cisco.com
CSIDS 2.113
The Top Alarms report has the following configurable filters:




categories.
13-46

attack.

time zone.

Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
Start Address to the End Address. The Start and End IP address are
menu.
13-47



13-48


to CSPM.
Top Source Destinations Pairs
www.cisco.com
CSIDS 2.113
The Top Source Destination Pairs of Alarms report has the following configurable
filters:




categories.

attack.

time zone.

13-49
13-50
Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
Start Address to the End Address. The Start and End IP address are
menu.


SensorThe sensor filter enables the network security administrator to



to CSPM.
13-51
Alarm Source
www.cisco.com
CSIDS 2.113
The Alarm Source report has the following configurable filters:




categories.
13-52

attack.

time zone.

Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
menu.
13-53

Alarm CountThe Alarm Count filter enables the network security

administrator to generate a report based on the number of alarms.
Alarm CountA numeric value must be entered in the Alarm Count text
box.

13-54


to CSPM.
Alarm Destination
www.cisco.com
CSIDS 2.113
The Alarm Destination report has the following configurable filters:




categories.

attack.

time zone.

13-55
13-56
Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
menu.


box.



to CSPM.
13-57
Alarms
www.cisco.com
CSIDS 2.113
The Alarms report has the following configurable filters:




categories.
13-58

attack.

time zone.

Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
menu.
13-59


box.

13-60


to CSPM.
Alarm Source Destination Pair
www.cisco.com
CSIDS 2.113
The Alarm Source Destination Pair report has the following configurable filters:




categories.

attack.

time zone.

13-61
13-62
Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
menu.


box.



to CSPM.
13-63
Alarms by Hour
www.cisco.com
CSIDS 2.113
The Alarms by Hour report has the following configurable filters:




categories.
13-64

attack.

time zone.

Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
menu.
13-65


box.

13-66


to CSPM.
Alarms by Day
www.cisco.com
CSIDS 2.113
The Alarms by Day report has the following configurable filters:




categories.

attack.

time zone.

13-67
13-68
Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
menu.


box.



to CSPM.
13-69
Alarms by Sensor
www.cisco.com
CSIDS 2.113
The Alarms by Sensor report has the following configurable filters:




categories.
13-70

attack.

time zone.

Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
menu.
13-71


box.

13-72


to CSPM.
Sensor Alarm Correlation
www.cisco.com
CSIDS 2.113
The Sensor Alarm Correlation report has the following configurable filters:




categories.

attack.

time zone.

13-73
13-74
Signatures
SATAN Signatures
DNS Signatures
Finger Signatures
FTP Signatures
SSH Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
INN Signatures
Telnet Signatures
Loki Signatures
POP Signatures
WWW Signatures

menu.
menu.

of the attack.
Note
Rlogin Signatures

attack.
Signatures

menu.
menu.


box.

Note


to CSPM.
Two or more sensors must be selected in order to perform a correlation.
13-75
Sample Reports
This section has CIDS sample reports that can be generated.
www.cisco.com
CSIDS 2.113
This is a sample IDS Intrusion Detection Summary report. The report has the
following sections:
13-76
Alarms by Level
Alarm Level
Count
Alarms by Source and Destination Direction
Alarm Level
Src Dir
Dest Dir
Count
Percent
Alarms by Signature Category
Alarm Level
Signature Category
Count
Percent
Top Source
www.cisco.com
CSIDS 2.113
This is a sample IDS Top Source report. The report has the following sections:
Summary
Alarm Level
Count
Src IP Address
Details
Alarm Level
Count
Src IP Address
Dest IP Address
Signature
Percent
Most Recent
13-77
Top Source Destination Pair
www.cisco.com
CSIDS 2.113
This is a sample IDS Top Source Destination Pair report. The report has the
following sections:
13-78
Summary
Alarm Level
Count
Src IP Address
Dest IP Address
Details
Alarm Level
Count
Src IP Address
Dest IP Address
Signature
Percent
Most Recent
Alarms
www.cisco.com
CSIDS 2.113
This is a sample IDS Alarms report. The report has the following section:
Summary
Alarm Level
Count
Signature
13-79
Alarm Source
www.cisco.com
CSIDS 2.113
This is a sample IDS Alarm Source report. The report has the following sections:
13-80
Summary
Alarm Level
Count
Src IP Address
Details
Alarm Level
Count
Src IP Address
Dest IP Address
Signature
Percent
Most Recent
Alarm Source Destination Pair
www.cisco.com
CSIDS 2.113
This is a sample IDS Alarm Source Destination Pair report. The report has the
following sections:
Summary
Details
Summary
Alarm Level
Count
Src IP Address
Dest IP Address
Details
Alarm Level
Count
Src IP Address
Dest IP Address
Signature
Percent
Most Recent
13-81
Alarm by Day
www.cisco.com
CSIDS 2.113
This is a sample IDS Alarm by Day report. The report has the following sections:
13-82
Summary
Date
Alarm Level
Count
Details
Date
Alarm Level
Count
Src IP Address
Dest IP Address
Signature
Percent
Alarm by Hour
www.cisco.com
CSIDS 2.113
This is a sample IDS Alarm by Hour report. The report has the following sections:
Summary
Date/Hour
Alarm Level
Count
Details
Date/Hour
Alarm Level
Count
Src IP Address
Dest IP Address
Signature
Percent
13-83
Alarm by Sensor
www.cisco.com
CSIDS 2.113
This is a sample IDS Alarm by Sensor report. The report has the following
sections:
13-84
Summary
Sensor
Alarm Level
Count
Details
Sensor
Alarm Level
Count
Src IP Address
Dest IP Address
Signature
Percent
Most Recent
Summary
This section summarizes the event notification and alarm reporting features in
CSPM.
Summary
Notification processing is done by the CSPM
host.
An SMTP server must exist in the NTT to
perform CSIDS e-mail notification.
Custom scripts can be executed after an alarm
is detected.
CSPM provides CIDS HTML and text alarm
reports.
Alarm reporting is provided over HTTP or
HTTPS.
www.cisco.com
CSIDS 2.113
13-85
Lab Exercise
Complete the following laboratory exercises to practice what you learned in this
chapter.
Objectives
In this lab you will complete the following tasks:
Add a SMTP server to the CSPM NTT for e-mail notification.
Configure e-mail notification in CSPM.
Launch an attack that will trigger an IDS event to generate an e-mail

notification.
Generate IDS Alarm Reports.
Visual Objective
This figure displays the information you will need to complete this laboratory
exercise.

Pod P
Your Pod
Pod Q
Peer Pod
172.30.1.0 /24
e0/1 .10P
sensorP
e0/0 .1
.4
idsmP
e0/1 .10Q
sensorQ
e0/0 .1
.4
rQ
rP
.6
10.0.P.0 /24
10.0.P.3
idsmQ
10.0.Q.0 /24
10.0.P.10
CSPM
.6
SMTP/POP
10.0.Q.10
CSPM
SMTP/POP
10.0.Q.3
www.cisco.com
CSIDS 2.113
equipment to do the lab.
13-86
Task 1Add an SMTP Server to the CSPM NTT

Complete the following steps to add a host with the SMTP service to the NTT:
Step 1
Right-click the network Net- 10.0.P.0 from the NTT.

Step 2
Choose New>Host. A host general properties panel appears in the right pane. The
cursor focus is in the hostname box.
Step 3
Rename the host to my smtp server. The new name appears in the NTT.
Step 4
Enter the IP address of the host in the IP addresses box.

IP Address
Step 5
Click the top Add button. The IP address appears in the IP address list box.
Step 6
Click the bottom Add button. The Add Client/Server Product window opens.
Step 7
Choose SMTP from the list of Product Types.
Step 8
Click OK to return the host properties pane.
Step 9
Click the SMTP tab in the host properties pane. The SMTP properties pane
appears.
Note
The SMTP tab has a version number appended to it.
Step 10 Rename the SMTP service name to podP smtp service.

Step 11 Click OK to accept the changes.
Step 12 Click Save in the main toolbar to save the changes to the CSPM database.
Task 2Define the CSPM Hosts SMTP Server

Complete the following steps to define which SMTP server the CSPM host will
use for e-mail notifications:
Step 1
Select the CSPM host, directorP, from the NTT. The CSPM host General
properties pane appears.
Step 2
Choose my smtp server from the SMTP server drop-down menu.
Step 3
Click OK to accept the changes.
Step 4
Click Save in the main toolbar to save the changes to the CSPM database.
13-87
Task 3Configure E-Mail Notification for High Severity

Alarms
Complete the following steps to configure e-mail notification when the CSPM
host receives a high severity alarm:
Step 1
Choose Tools>Configure Notifications. The Configure Logging and

Notifications pane appears.
Step 2
Select IDS events in the Select Event Category group box.
Step 3
Choose High Severity Alarms from the list of Event Descriptions.
Step 4
Choose the Event Disposition Log Event and issue notification specified
below.
Step 5
Accept the default Notification Scheduling values.
Step 6
Select Include event description in the Notification Message group box.
Step 7
Click Message. The Notification message content window opens.
Step 8
Enter the following in the Subject field:

High Severity Notification
Step 9
Enter the following message in the text box (the variable names will be
substituted with the actual alarm values in the message):
Sensor ${HostID} detected Signature ${SigID} launched by ${SrcIpAddr}:${SrcIpPort}
against ${DstIpAddr}:${DstIpPort} at ${TimeStr} on ${DateStr}.
Note
The variable names are case sensitive. Enter the variable names exactly as they
appear.
Step 10 Click OK to accept the message subject and body content.

Step 11 Select the notification method: E-mail.
Step 12 Click Address to add a list of e-mail recipients. The E-mail recipients window
opens.
Step 13 Enter the e-mail addresses of the recipients as assigned by the instructor.
E-mail Address
Step 14 Click Add. The e-mail recipients address appears.
Step 15 Click OK to close the E-mail recipients window.
Step 16 Click Apply to accept the notification settings.
Step 17 Click Save in the main toolbar to save the changes to the CSPM database.
13-88
Task 4Test E-Mail Notification

Complete the following tasks to generate high severity alarms that will cause an email notification to be generated. Your instructor will assign a peers pod number
(Q).
Step 1
Launch your web browser.
Step 2

http://10.0.Q.3/../..

Step 3

http://10.0.Q.3/msadc/msadcs.dll

Step 4
Launch your mail client software.
Step 5
Retrieve your e-mail from the mail server.
Task 5Generate CIDS Alarm Reports

Complete the following tasks to generate CIDS alarm reports:
Step 1
Launch your web browser and enter the following in the URL field:
https://localhost/Reports
Step 2
Select a report as assigned by the instructor.
Step 3
Authenticate when prompted.
Step 4
Click View (Window) to generate a default report. A new web browser opens
displaying the CIDS alarm report.
13-89
Cisco Intrusion
Detection System
Signature Structures
and Implementations
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
1000
IP options-Bad Option
List
ATOMIC
CONTEXT
1001
IP options-Record
Packet Route
ATOMIC
CONTEXT
1002
IP options-Timestamp
ATOMIC
CONTEXT
1003
IP options-Provide s,
c, h, and tcc
ATOMIC
CONTEXT
1004
IP options-Loose
Source Route
ATOMIC
CONTEXT
1005
IP options-SATNET
ID
ATOMIC
CONTEXT
1006
IP options-Strict
Source Route
ATOMIC
CONTEXT
1100
IP Fragment Attack
ATOMIC
CONTEXT
1101
Unknown IP Protocol
ATOMIC
CONTEXT
1102
Impossible IP Packet
ATOMIC
CONTENT
1103
IP Fragments Overlap
COMPOSITE
CONTEXT
1104
IP Localhost Source
Spoof
ATOMIC
CONTENT
1105
Broadcast Source
Add
ATOMIC
CONTENT
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
Address
1106
Multicast Ip Source
Address
ATOMIC
CONTENT
1200
IP Fragmentation
Buffer Full
ATOMIC
CONTENT
1201
IP Fragment Overlap
ATOMIC
CONTENT
1202
IP Fragment Overrun
- Datagram Too Long
ATOMIC
CONTENT
1203
IP Fragment
Overwrite - Data is
Overwritten
ATOMIC
CONTENT
1204
IP Fragment Missing
Initial Fragment
ATOMIC
CONTENT
1205
IP Fragment Too
Many Datagrams
ATOMIC
CONTENT
1206
IP Fragment Too
Small
ATOMIC
CONTENT
1207
IP Fragment Too
Many Frags
ATOMIC
CONTENT
1208
IP Fragment
Incomplete Datagram
ATOMIC
CONTENT
1220
Jolt2 Fragment
Reassembly DoS
attack
COMPOSITE
CONTENT
2000
ICMP Echo Reply
ATOMIC
CONTEXT
2001
ICMP Host
Unreachable
ATOMIC
CONTEXT
2002
ICMP Source Quench
ATOMIC
CONTEXT
2003
ICMP Redirect
ATOMIC
CONTEXT
2004
ICMP Echo Request
ATOMIC
CONTEXT
2005
ICMP Time Exceeded

for a Datagram
ATOMIC
CONTEXT
2006
ICMP Parameter
Problem on Datagram
ATOMIC
CONTEXT
2007
ICMP Timestamp
Request
ATOMIC
CONTEXT
2008
ICMP Timestamp
Reply
ATOMIC
CONTEXT
2009
ICMP Information
Request
ATOMIC
CONTEXT
2010
ICMP Information
Reply
ATOMIC
CONTEXT
2011
ICMP Address Mask

Request
ATOMIC
CONTEXT
2012
ICMP Address Mask

Reply
ATOMIC
CONTEXT
2100
ICMP Network Sweep

/E h
COMPOSITE
CONTEXT
A-2
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
w/Echo
2101
ICMP Network Sweep

w/Timestamp
COMPOSITE
CONTEXT
2102
ICMP Network Sweep

w/Address Mask
COMPOSITE
CONTEXT
2150
Fragmented ICMP
Traffic
ATOMIC
CONTEXT
2151
Large ICMP Traffic
ATOMIC
CONTEXT
2152
ICMP Flood
COMPOSITE
CONTEXT
2153
Smurf
COMPOSITE
CONTEXT
2154
Ping of Death Attack
ATOMIC
CONTEXT
3000
TCP Ports
ATOMIC
CONTEXT
3001
TCP Port Sweep
COMPOSITE
CONTEXT
3002
TCP SYN Port Sweep
COMPOSITE
CONTEXT
3003
TCP Frag SYN Port

Sweep
COMPOSITE
CONTEXT
3005
TCP FIN Port Sweep
COMPOSITE
CONTEXT
3006
TCP Frag FIN Port

Sweep
COMPOSITE
CONTEXT
3010
TCP High Port Sweep
COMPOSITE
CONTEXT
3011
TCP FIN High Port

Sweep
COMPOSITE
CONTEXT
3012
TCP Frag FIN High

Port Sweep
COMPOSITE
CONTEXT
3015
TCP Null Port Sweep
COMPOSITE
CONTEXT
3016
TCP Frag Null Port

Sweep
COMPOSITE
CONTEXT
3020
TCP SYN FIN Port

Sweep
COMPOSITE
CONTEXT
3021
TCP Frag SYN FIN

Port Sweep
COMPOSITE
CONTEXT
3030
TCP SYN Host

Sweep
COMPOSITE
CONTEXT
3031
TCP FRAG SYN Host

Sweep
COMPOSITE
CONTEXT
3032
TCP FIN Host Sweep
COMPOSITE
CONTEXT
3033
TCP FRAG FIN Host

Sweep
COMPOSITE
CONTEXT
3034
TCP NULL Host

Sweep
COMPOSITE
CONTEXT
3035
TCP FRAG NULL

Host Sweep
COMPOSITE
CONTEXT
3036
TCP SYN FIN Host

Sweep
COMPOSITE
CONTEXT
3037
TCP FRAG SYN FIN

H tS
COMPOSITE
CONTEXT
Cisco Intrusion Detection System Signature Structures and Implementation
A-3
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
Host Sweep
3038
Fragmented NULL
TCP Packet
ATOMIC
CONTEXT
3039
Fragmented
Orphaned FIN packet
ATOMIC
CONTEXT
3040
NULL TCP Packet
ATOMIC
CONTEXT
3041
SYN/FIN Packet
ATOMIC
CONTEXT
3042
Orphaned Fin Packet
ATOMIC
CONTEXT
3043
Fragmented SYN/FIN
Packet
ATOMIC
CONTENT
3045
Queso Sweep
COMPOSITE
CONTEXT
3050
Half-open SYN Attack
COMPOSITE
CONTEXT
3100
Smail Attack
COMPOSITE
CONTENT
3101
Sendmail Invalid
Recipient
COMPOSITE
CONTENT
3102
Sendmail Invalid
Sender
COMPOSITE
CONTENT
3103
Sendmail
Reconnaissance
COMPOSITE
CONTENT
3104
Archaic Sendmail
Attacks
COMPOSITE
CONTENT
3105
Sendmail Decode
Alias
COMPOSITE
CONTENT
3106
Mail Spam
COMPOSITE
CONTEXT
3107
Majordomo Execute
Attack
COMPOSITE
CONTENT
3108
MIME Overflow Bug
COMPOSITE
CONTENT
3109
Q-Mail Length Crash
COMPOSITE
CONTENT
3110
Suspicious Mail
Attachment
COMPOSITE
CONTENT
3150
FTP Remote
Command Execution
COMPOSITE
CONTENT
3151
FTP SYST Command

Attempt
COMPOSITE
CONTENT
3152
FTP CWD ~root
COMPOSITE
CONTENT
3153
FTP Improper
Address Specified
ATOMIC
CONTENT
3154
FTP Improper Port

Specified
ATOMIC
CONTENT
3155
FTP RETR Pipe

Filename Command
Execution
ATOMIC
CONTENT
3156
FTP STOR Pipe

Filename Command
Execution
ATOMIC
CONTENT
3157
FTP PASV Port Spoof
COMPOSITE
CONTENT
A-4
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
3200
WWW Phf Attack
COMPOSITE
CONTENT
3201
WWW General cgibin Attack
COMPOSITE
CONTENT
3202
WWW .url File

Requested
COMPOSITE
CONTENT
3203
WWW .lnk File

Requested
COMPOSITE
CONTENT
3204
WWW .bat File

Requested
COMPOSITE
CONTENT
3205
HTML File Has .url

Link
COMPOSITE
CONTENT
3206
HTML File Has .lnk

Link
COMPOSITE
CONTENT
3207
HTML File Has .bat

Link
COMPOSITE
CONTENT
3208
WWW campas
Attack
COMPOSITE
CONTENT
3209
WWW Glimpse
Server Attack
COMPOSITE
CONTENT
3210
WWW IIS View

Source Attack
COMPOSITE
CONTENT
3211
WWW IIS Hex View

Source Attack
COMPOSITE
CONTENT
3212
WWW NPH-TESTCGI Attack
COMPOSITE
CONTENT
3213
WWW TEST-CGI
Attack
COMPOSITE
CONTENT
3214
IIS DOT DOT VIEW

Attack
COMPOSITE
CONTENT
3215
IIS DOT DOT

EXECUTE Attack
COMPOSITE
CONTENT
3216
IIS Dot Dot Crash

Attack
COMPOSITE
CONTENT
3217
WWW php View File

Attack
COMPOSITE
CONTENT
3218
WWW SGI Wrap

Attack
COMPOSITE
CONTENT
3219
WWW PHP Buffer

Overflow
COMPOSITE
CONTENT
3220
IIS Long URL Crash

Bug
COMPOSITE
CONTENT
3221
WWW cgiviewsource Attack
COMPOSITE
CONTENT
3222
WWW PHP Log

Scripts Read Attack
COMPOSITE
CONTENT
3223
WWW IRIX cgihandler Attack
COMPOSITE
CONTENT
A-5
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
3224
HTTP WebGais
COMPOSITE
CONTENT
3225
HTTP Gais
Websendmail
COMPOSITE
CONTENT
3226
WWW Webdist Bug
COMPOSITE
CONTENT
3227
WWW Htmlscript Bug
COMPOSITE
CONTENT
3228
WWW Performer Bug
COMPOSITE
CONTENT
3229
Website Win-CSample Buffer

Overflow
COMPOSITE
CONTENT
3230
Website Uploader
COMPOSITE
CONTENT
3231
Novell convert
COMPOSITE
CONTENT
3232
WWW finger attempt
COMPOSITE
CONTENT
3233
WWW count-cgi
Overflow
COMPOSITE
CONTEXT
3250
TCP Hijack
COMPOSITE
CONTEXT
3251
TCP Hijacking
Simplex Mode
COMPOSITE
CONTEXT
3300
NetBIOS OOB Data
ATOMIC
CONTEXT
3301
NETBIOS Stat
ATOMIC
CONTENT
3302
NETBIOS Session
Setup Failure
ATOMIC
CONTEXT
3303
Windows Guest Login
ATOMIC
CONTENT
3304
Windows Null
Account Name
ATOMIC
CONTENT
3305
Windows Password
File Access
ATOMIC
CONTENT
3306
Windows Registry
Access
ATOMIC
CONTENT
3307
Windows Redbutton
Attack
COMPOSITE
CONTENT
3308
Windows LSARPC
Access
ATOMIC
CONTENT
3309
Windows SRVSVC
Access
ATOMIC
CONTENT
3400
Sunkill
COMPOSITE
CONTENT
3401
Telnet-IFS Match
COMPOSITE
CONTENT
3450
Finger Bomb
ATOMIC
CONTENT
3500
Rlogin -froot Attack
COMPOSITE
CONTENT
3525
IMAP Authenticate
Buffer Overflow
COMPOSITE
CONTENT
3526
Imap Login Buffer

Overflow
COMPOSITE
CONTENT
3530
Cisco Secure ACS

Oversized TACACS+
ATOMIC
CONTENT
A-6
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
Attack
3540
Cisco Secure ACS

CSAdmin Attack
ATOMIC
CONTEXT
3550
POP Buffer Overflow
COMPOSITE
CONTENT
3575
INN Buffer Overflow
COMPOSITE
CONTEXT
3576
INN Control Message

Exploit
COMPOSITE
CONTENT
3600
IOS Telnet Buffer

Overflow
COMPOSITE
CONTENT
3601
IOS Command
History Exploit
COMPOSITE
CONTENT
3602
Cisco IOS Identity
ATOMIC
CONTENT
3603
IOS Enable Bypass
COMPOSITE
CONTENT
3650
SSH RSAREF2
Buffer Overflow
COMPOSITE
CONTEXT
3990
BackOrifice BO2K
TCP Non Stealth
COMPOSITE
CONTENT
3991
BackOrifice BO2K
TCP Stealth 1
COMPOSITE
CONTENT
3992
BackOrifice BO2K
TCP Stealth 2
COMPOSITE
CONTENT
4000
UDP Packet
ATOMIC
CONTEXT
4001
UDP Port Sweep
COMPOSITE
CONTEXT
4002
UDP Flood
COMPOSITE
CONTEXT
4050
UDP Bomb
ATOMIC
CONTEXT
4051
Snork
ATOMIC
CONTEXT
4052
Chargen DoS
ATOMIC
CONTEXT
4053
Back Orifice
COMPOSITE
CONTENT
4054
RIP Trace
ATOMIC
CONTENT
4055
BackOrifice BO2K
UDP
COMPOSITE
CONTENT
4100
Tftp Passwd File
COMPOSITE
CONTENT
4150
Ascend Denial of
Service
COMPOSITE
CONTENT
4600
IOS UDP Bomb
COMPOSITE
CONTEXT
5034
WWW IIS newdsn

attack
COMPOSITE
CONTENT
5035
HTTP cgi HylaFAX

Faxsurvey
COMPOSITE
CONTENT
5036
WWW Windows
Password File Access
Attempt
COMPOSITE
CONTENT
5037
WWW SGI
MachineInfo Attack
COMPOSITE
CONTENT
A-7
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
5038
WWW wwwsql file

read Bug
COMPOSITE
CONTENT
5039
WWW finger attempt
COMPOSITE
CONTENT
5040
WWW Perl
Interpreter Attack
COMPOSITE
CONTENT
5041
WWW anyform attack
COMPOSITE
CONTENT
5042
WWW CGI Valid

Shell Access
COMPOSITE
CONTENT
5043
WWW Cold Fusion

Attack
COMPOSITE
CONTENT
5044
WWW Webcom.se
Guestbook attack
COMPOSITE
CONTENT
5045
WWW xterm display

attack
COMPOSITE
CONTENT
5046
WWW dumpenv.pl
recon
COMPOSITE
CONTENT
5047
WWW Server Side

Include POST attack
COMPOSITE
CONTENT
5048
WWW IIS BAT EXE

attack
COMPOSITE
CONTENT
5049
WWW IIS
showcode.asp access
COMPOSITE
CONTENT
5050
WWW IIS .htr

Overflow Attack
COMPOSITE
CONTENT
5051
IIS Double Byte Code

Page
ATOMIC
CONTENT
5052
FrontPage Extensions
PWD Open Attempt
ATOMIC
CONTENT
5053
FrontPage _vti_bin
Directory List Attempt
ATOMIC
CONTENT
5054
WWWBoard
Password
ATOMIC
CONTENT
5055
HTTP Basic
Authentication
Overflow
COMPOSITE
CONTENT
5056
WWW Cisco IOS %%

DoS
COMPOSITE
CONTENT
5057
WWW Sambar
Samples
COMPOSITE
CONTENT
5058
WWW info2www
Attack
COMPOSITE
CONTENT
5059
WWW Alibaba Attack
COMPOSITE
CONTENT
5060
WWW Excite ATgenerate.cgi Access
COMPOSITE
CONTENT
5061
WWW
catalog_type.asp
Access
COMPOSITE
CONTENT
A-8
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
5062
WWW classifieds.cgi
Attack
COMPOSITE
CONTENT
5063
WWW
dmblparser.exe
Access
COMPOSITE
CONTENT
5064
WWW imagemap.cgi
Attack
COMPOSITE
CONTENT
5065
WWW IRIX
infosrch.cgi Attack
COMPOSITE
CONTENT
5066
WWW man.sh
Access
COMPOSITE
CONTENT
5067
WWW plusmail
Attack
COMPOSITE
CONTENT
5068
WWW formmail.pl
Access
COMPOSITE
CONTENT
5069
WWW whois_raw.cgi
Attack
COMPOSITE
CONTENT
5070
WWW msadcs.dll
Access
COMPOSITE
CONTENT
5071
WWW msacds.dll
Attack
COMPOSITE
CONTENT
5072
WWW bizdb1search.cgi Attack
COMPOSITE
CONTENT
5073
WWW EZshopper
loadpage.cgi Attack
COMPOSITE
CONTENT
5074
WWW EZshopper
search.cgi Attack
COMPOSITE
CONTENT
5075
WWW IIS Virtualized

UNC Bug
COMPOSITE
CONTENT
5076
WWW webplus bug
COMPOSITE
CONTENT
5077
WWW Excite ATadmin.cgi Access
COMPOSITE
CONTENT
5078
WWW Piranha
passwd attack
COMPOSITE
CONTENT
5079
WWW PCCS MySQL

Admin Access
ATOMIC
CONTENT
5080
WWW IBM
WebSphere Access
ATOMIC
CONTENT
5081
WWW WinNT
cmd.exe Access
ATOMIC
CONTENT
5082
WWW Roxen %00

Access
ATOMIC
CONTENT
5083
WWW Virtual Vision

FTP Browser Access
ATOMIC
CONTENT
5084
WWW Alibaba Attack

2
ATOMIC
CONTENT
5085
WWW IIS Source

Fragment Access
ATOMIC
CONTENT
A-9
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
5086
WWW WEBactive
Logfile Access
ATOMIC
CONTENT
5087
WWW Sun Java

Server Access
ATOMIC
CONTENT
5088
WWW Akopia
MiniVend Access
ATOMIC
CONTENT
5089
WWW Big Brother

Directory Access
ATOMIC
CONTENT
5090
WWW FrontPage
htimage.exe Access
ATOMIC
CONTENT
5091
WWW Cart32
Remote Admin
Access
COMPOSITE
CONTENT
5092
WWW CGI-World
Poll It Access
ATOMIC
CONTENT
5093
WWW PHP-Nuke
admin.php3 Access
ATOMIC
CONTENT
5095
WWW CGI Script

Center Account
Manager Attack
ATOMIC
CONTENT
5096
WWW CGI Script

Center Subscribe Me
Attack
ATOMIC
CONTENT
5097
WWW FrontPage
MS-DOS Device
Attack
COMPOSITE
CONTENT
5099
WWW GWScripts
News Publisher
Access
ATOMIC
CONTENT
5100
WWW CGI Center

Auction Weaver File
Access
ATOMIC
CONTENT
5101
WWW CGI Center

Auction Weaver
Attack
ATOMIC
CONTENT
5102
WWW
phpPhotoAlbum
explorer.php Access
ATOMIC
CONTENT
5103
WWW SuSE Apache

CGI Source Access
ATOMIC
CONTENT
5104
WWW YaBB File

Access
ATOMIC
CONTENT
5105
WWW Ranson
Johnson mailto.cgi
Attack
ATOMIC
CONTENT
5106
WWW Ranson
Johnson mailform.pl
Access
ATOMIC
CONTENT
5107
WWW Mandrake
Linux /perl Access
ATOMIC
CONTENT
A-10
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
5108
WWW Netegrity Site

Minder Access
ATOMIC
CONTENT
5109
WWW Sambar Beta

search.dll Access
ATOMIC
CONTENT
5110
WWW SuSE Installed

Packages Access
ATOMIC
CONTENT
5111
WWW Solaris
Answerbook 2
Access
ATOMIC
CONTENT
5112
WWW Solaris
Answerbook 2 Attack
ATOMIC
CONTENT
5113
WWW CommuniGate
Pro Access
ATOMIC
CONTENT
5114
WWW IIS Unicode

Attack
ATOMIC
CONTENT
6001
Normal SATAN Probe
COMPOSITE
CONTENT
6002
Heavy SATAN Probe
COMPOSITE
CONTENT
6050
DNS HINFO Request
ATOMIC
CONTENT
6051
DNS Zone Transfer
ATOMIC
CONTENT
6052
DNS Zone Transfer

from High Port
ATOMIC
CONTENT
6053
DNS Request for All

Records
ATOMIC
CONTENT
6054
DNS Version Request
ATOMIC
CONTENT
6055
DNS Inverse Query

Buffer Overflow
ATOMIC
CONTENT
6056
BIND NXT Buffer

Overflow
COMPOSITE
CONTENT
6057
BIND SIG Buffer

Overflow
COMPOSITE
CONTEXT
6100
RPC Port Registration
ATOMIC
CONTENT
6101
RPC Port
Unregistration
ATOMIC
CONTENT
6102
RPC Dump
ATOMIC
CONTENT
6103
Proxied RPC Request
ATOMIC
CONTENT
6104
RPC Set Spoof
ATOMIC
CONTENT
6105
RPC Unset Spoof
ATOMIC
CONTENT
6110
RPC RSTATD Sweep
COMPOSITE
CONTEXT
6111
RPC RUSERSD
Sweep
COMPOSITE
CONTEXT
6112
RPC NFS Sweep
COMPOSITE
CONTEXT
6113
RPC MOUNTD
Sweep
COMPOSITE
CONTEXT
6114
RPC YPPASSWDD
Sweep
COMPOSITE
CONTEXT
A-11
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
6115
RPC
SELECTION_SVC
Sweep
COMPOSITE
CONTEXT
6116
RPC REXD Sweep
COMPOSITE
CONTEXT
6117
RPC STATUS Sweep
COMPOSITE
CONTEXT
6118
RPC ttdb Sweep
COMPOSITE
CONTENT
6150
ypserv Portmap
Request
ATOMIC
CONTENT
6151
ypbind Portmap
Request
ATOMIC
CONTENT
6152
yppasswdd Portmap
Request
ATOMIC
CONTENT
6153
ypupdated Portmap
Request
ATOMIC
CONTENT
6154
ypxfrd Portmap
Request
ATOMIC
CONTENT
6155
mountd Portmap
Request
ATOMIC
CONTENT
6175
rexd Portmap
Request
ATOMIC
CONTENT
6180
rexd Attempt
ATOMIC
CONTEXT
6190
statd Buffer Overflow
COMPOSITE
CONTEXT
6191
RPC.tooltalk buffer
overflow
COMPOSITE
CONTENT
6192
RPC mountd Buffer

Overflow
COMPOSITE
CONTENT
6193
RPC CMSD Buffer

Overflow
ATOMIC
CONTENT
6194
sadmind RPC Buffer

Overflow
ATOMIC
CONTENT
6195
RPC amd Buffer

Overflow
COMPOSITE
CONTENT
6200
Ident Buffer Overflow
COMPOSITE
CONTENT
6201
Ident Newline
COMPOSITE
CONTENT
6202
Ident Improper
Request
COMPOSITE
CONTENT
6250
FTP Authorization
Failure
COMPOSITE
CONTENT
6251
Telnet Authorization
Failure
COMPOSITE
CONTENT
6252
Rlogin Authorization
Failure
COMPOSITE
CONTENT
6253
POP3 Authorization
Failure
COMPOSITE
CONTENT
6255
SMB Authorization
Failure
COMPOSITE
CONTENT
A-12
CIDS Signature ID
CIDS Sub Signature

ID
CIDS Signature
Name
CIDS Signature
Structure
CIDS Signature
Implementation
6300
Loki ICMP Tunnelling
COMPOSITE
CONTEXT
6302
General Loki ICMP

Tunneling
COMPOSITE
CONTEXT
6500
RingZero Trojan
COMPOSITE
CONTENT
6501
TFN Client Request
COMPOSITE
CONTENT
6502
TFN Server Reply
COMPOSITE
CONTENT
6503
Stacheldraht Client
Request
COMPOSITE
CONTENT
6504
Stacheldraht Server
Reply
COMPOSITE
CONTENT
6505
Trinoo Client Request
COMPOSITE
CONTENT
6506
Trinoo Server Reply
COMPOSITE
CONTENT
6507
TFN2K Control Traffic
COMPOSITE
CONTENT
6508
Mstream Control
Traffic
COMPOSITE
CONTENT
8000
2302
Telnet-/etc/shadow
Match
COMPOSITE
CONTENT
8000
2101
FTP Retrieve
Password File
COMPOSITE
CONTENT
8000
2303
Telnet-+ +
COMPOSITE
CONTENT
8000
51301
Rlogin-IFS Match
COMPOSITE
CONTENT
8000
51302
Rlogin-/etc/shadow
Match
COMPOSITE
CONTENT
8000
51303
Rlogin-+ +
COMPOSITE
CONTENT
A-13
Cisco
Intrusion Detection
System Signatures
and Recommended
Alarm Levels
Overview
This Appendix contains recommended CIDS signature alarm levels. The tables
are meant solely as a reference guide. The recommended alarm levels are:
DisableThe signature should be disabled due to the possibility of a large

number of alarms generated by normal network traffic.
LowThe signature has been determined to be a low threat. Low severity

alarms are triggered by normal network traffic or benign signature. CIDS
Signature IDs 6250-6255 (failed login attempts) and CIDS Signature ID 3602
(IOS Cisco Identification) are examples of signatures with a recommended
low alarm level.
MediumThe signature has been determined to be an indicator of possible

malicious activity. Medium severity alarms should be investigated to
determine the nature of the traffic that triggered the signature.
HighThe signature is associated with a real threat and should be taken

seriously. High severity alarms typically indicate an intrusion attempt or a
denial of service attack.
General Signatures
B-2
Signature Sub Signature Signature Name

ID
ID
Recommended
Alarm Level
1000
IP options-Bad Option List
Low
1001
IP options-Record Packet Route
Low
1002
IP options-Timestamp
Low
1003
IP options-Provide s, c, h, and tcc
Low
1004
IP options-Loose Source Route
High
1005
IP options-SATNET ID
Low
1006
IP options-Strict Source Route
High
1100
IP Fragment Attack
Medium
1101
Unknown IP Protocol
Low
1102
Impossible IP Packet
High
1103
IP Fragments Overlap
High
1104
IP Localhost Source Spoof
High
1200
IP Fragmentation Buffer Full
Low
1201
IP Fragment Overlap
High
1202
IP Fragment Overrun - Datagram Too Long
High
1203
IP Fragment Overwrite - Data is Overwritten
High
1204
IP Fragment Missing Initial Fragment
Low
1205
IP Fragment Too Many Datagrams
Low
1206
IP Fragment Too Small
Low
1207
IP Fragment Too Many Frags
Low
1208
IP Fragment Incomplete Datagram
Low
1220
Jolt2 Fragment Reassembly DoS attack
High
2000
ICMP Echo Reply
Disable
2001
ICMP Host Unreachable
Disable
2002
ICMP Source Quench
Disable
2003
ICMP Redirect
Disable
2004
ICMP Echo Request
Disable
2005
ICMP Time Exceeded for a Datagram
Disable
2006
ICMP Parameter Problem on Datagram
Disable
2007
ICMP Timestamp Request
Disable
2008
ICMP Timestamp Reply
Disable
2009
ICMP Information Request
Disable
2010
ICMP Information Reply
Disable
2011
ICMP Address Mask Request
Disable
2012
ICMP Address Mask Reply
Disable

ID
ID
Recommended
Alarm Level
2100
ICMP Network Sweep w/Echo
Medium
2101
ICMP Network Sweep w/Timestamp
High
2102
ICMP Network Sweep w/Address Mask
High
2150
Fragmented ICMP Traffic
Disable
2151
Large ICMP Traffic
Disable
2152
ICMP Flood
High
2153
Smurf
High
2154
Ping of Death Attack
High
3001
TCP Port Sweep
High
3002
TCP SYN Port Sweep
Medium
3003
TCP Frag SYN Port Sweep
High
3005
TCP FIN Port Sweep
High
3006
TCP Frag FIN Port Sweep
High
3010
TCP High Port Sweep
Disable
3011
TCP FIN High Port Sweep
High
3012
TCP Frag FIN High Port Sweep
High
3015
TCP Null Port Sweep
High
3016
TCP Frag Null Port Sweep
High
3020
TCP SYN FIN Port Sweep
High
3021
TCP Frag SYN FIN Port Sweep
High
3030
TCP SYN Host Sweep
Low
3031
TCP FRAG SYN Host Sweep
High
3032
TCP FIN Host Sweep
High
3033
TCP FRAG FIN Host Sweep
High
3034
TCP NULL Host Sweep
High
3035
TCP FRAG NULL Host Sweep
High
3036
TCP SYN FIN Host Sweep
High
3037
TCP FRAG SYN FIN Host Sweep
High
3038
Fragmented NULL TCP Packet
High
3039
Fragmented Orphaned FIN packet
High
3040
NULL TCP Packet
High
3041
SYN/FIN Packet
High
3042
Orphaned Fin Packet
High
3043
Fragmented SYN/FIN Packet
High
3045
Queso Sweep
High
3050
High
3100
Smail Attack
High
Cisco Intrusion Detection System Signatures and Recommended Alarm Levels
B-3
B-4

ID
ID
Recommended
Alarm Level
3101
Sendmail Invalid Recipient
High
3102
Sendmail Invalid Sender
High
3103
Sendmail reconnaissance
Low
3104
Archaic Sendmail Attacks
Low
3105
Sendmail Decode Alias
Medium
3106
Mail Spam
Medium
3107
Majordomo Execute Attack
High
3108
MIME Overflow Bug
High
3109
Q-Mail Length Crash
High
3110
Suspicious Mail Attachment
Medium
3150
FTP Remote Command Execution
Low
3151
FTP SYST Command Attempt
Disable
3152
FTP CWD ~root
High
3153
FTP Improper Address Specified
High
3154
FTP Improper Port Specified
High
3155
FTP RETR Pipe Filename Command Execution
High
3156
FTP STOR Pipe Filename Command Execution
High
3157
FTP PASV Port Spoof
High
3200
WWW Phf Attack
High
3201
WWW General cgi-bin Attack
High
3202
WWW .url File Requested
High
3203
WWW .lnk File Requested
High
3204
WWW .bat File Requested
High
3205
HTML File Has .url Link
Disable
3206
HTML File Has .lnk Link
Disable
3207
HTML File Has .bat Link
Disable
3208
WWW campas Attack
High
3209
WWW Glimpse Server Attack
High
3210
WWW IIS View Source Attack
Medium
3211
WWW IIS Hex View Source Attack
Disable
3212
WWW NPH-TEST-CGI Attack
Medium
3213
WWW TEST-CGI Attack
Medium
3214
IIS DOT DOT VIEW Attack
Disable
3215
IIS DOT DOT EXECUTE Attack
High
3216
IIS Dot Dot Crash Attack
High
3217
WWW php View File Attack
High
3218
WWW SGI Wrap Attack
High

ID
ID
Recommended
Alarm Level
3219
WWW PHP Buffer Overflow
High
3220
IIS Long URL Crash Bug
Disable
3221
WWW cgi-viewsource Attack
Medium
3222
WWW PHP Log Scripts Read Attack
Medium
3223
WWW IRIX cgi-handler Attack
Medium
3224
HTTP WebGais
Medium
3225
HTTP Gais Websendmail
Medium
3226
WWW Webdist Bug
Medium
3227
WWW Htmlscript Bug
Medium
3228
WWW Performer Bug
Medium
3229
Website Win-C-Sample Buffer Overflow
High
3230
Website Uploader
Medium
3231
Novell convert
High
3232
WWW finger attempt
Medium
3233
WWW count-cgi Overflow
High
3250
TCP Hijack
High
3251
TCP Hijacking Simplex Mode
High
3300
NetBIOS OOB Data
High
3301
NETBIOS Stat
Disable
3302
NETBIOS Session Setup Failure
Disable
3303
Windows Guest Login
Low
3304
Windows Null Account Name
Disable
3305
Windows Password File High
High
3306
Windows Registry High
High
3307
Windows Redbutton Attack
High
3308
Windows LSARPC High
Disable
3309
Windows SRVSVC High
Disable
3400
Sunkill
Medium
3401
Telnet-IFS Match
Medium
3450
Finger Bomb
Medium
3500
Rlogin -froot Attack
High
3525
IMAP Authenticate Buffer Overflow
High
3526
Imap Login Buffer Overflow
High
3530
Cisco Secure ACS Oversized TACACS+ Attack
Medium
3540
Cisco Secure ACS CSAdmin Attack
High
3550
POP Buffer Overflow
High
3575
INN Buffer Overflow
High
B-5
B-6

ID
ID
Recommended
Alarm Level
3576
INN Control Message Exploit
High
3600
IOS Telnet Buffer Overflow
High
3601
IOS Command History Exploit
High
3602
Cisco IOS Identity
Low
3603
IOS Enable Bypass
High
3650
SSH RSAREF2 Buffer Overflow
High
3990
BackOrifice BO2K TCP Non Stealth
High
3991
BackOrifice BO2K TCP Stealth 1
High
3992
BackOrifice BO2K TCP Stealth 2
High
4001
UDP Port Sweep
High
4002
UDP Flood
Disable
4050
UDP Bomb
Medium
4051
Snork
Medium
4052
Chargen DoS
Medium
4053
Back Orifice
High
4054
RIP Trace
High
4055
BackOrifice BO2K UDP
High
4100
Tftp Passwd File
High
4150
Ascend High of Service
Medium
4600
IOS UDP Bomb
High
5034
High
5035
HTTP cgi HylaFAX Faxsurvey
High
5036
WWW Windows Password File High Attempt
High
5037
WWW SGI MachineInfo Attack
Medium
5038
WWW wwwsql file read Bug
High
5039
WWW finger attempt
Medium
5040
WWW Perl Interpreter Attack
High
5041
WWW anyform attack
High
5042
WWW CGI Valid Shell High
High
5043
WWW Cold Fusion Attack
High
5044
WWW Webcom.se Guestbook attack
High
5045
WWW xterm display attack
High
5046
WWW dumpenv.pl Low
Medium
5047
WWW Server Side Include POST attack
High
5048
WWW IIS BAT EXE attack
High
5049
WWW IIS showcode.asp High
Medium
5050
WWW IIS .htr Overflow Attack
High

ID
ID
Recommended
Alarm Level
5051
IIS Double Byte Code Page
Medium
5052
FrontPage Extensions PWD Open Attempt
High
5053
FrontPage _vti_bin Directory List Attempt
High
5054
WWWBoard Password
Medium
5055
HTTP Basic Authentication Overflow
High
5056
WWW Cisco IOS %% DoS
Disable
5057
WWW Sambar Samples
Medium
5058
WWW info2www Attack
High
5059
WWW Alibaba Attack
High
5060
WWW Excite AT-generate.cgi High
Medium
5061
WWW catalog_type.asp High
High
5062
WWW classifieds.cgi Attack
High
5063
WWW dmblparser.exe High
Medium
5064
WWW imagemap.cgi Attack
High
5065
WWW IRIX infosrch.cgi Attack
High
5066
WWW man.sh High
Medium
5067
WWW plusmail Attack
High
5068
WWW formmail.pl High
Medium
5069
WWW whois_raw.cgi Attack
High
5070
WWW msadcs.dll High
High
5071
WWW msacds.dll Attack
High
5072
WWW bizdb1-search.cgi Attack
High
5073
WWW EZshopper loadpage.cgi Attack
High
5074
WWW EZshopper search.cgi Attack
High
5075
WWW IIS Virtualized UNC Bug
Medium
5076
WWW webplus bug
Medium
5077
WWW Excite AT-admin.cgi High
Medium
5078
WWW Piranha passwd attack
High
5079
WWW PCCS MySQL Admin High
Medium
5080
WWW IBM WebSphere High
Medium
5081
WWW WinNT cmd.exe High
High*
5082
WWW Roxen %00 High
Low
5083
WWW Virtual Vision FTP Browser High
Medium
5084
WWW Alibaba Attack 2
Medium
5085
WWW IIS Source Fragment High
Medium
5086
WWW WEBactive Logfile High
Low
5087
WWW Sun Java Server High
Medium
B-7
B-8

ID
ID
Recommended
Alarm Level
5088
WWW Akopia MiniVend High
Medium
5089
WWW Big Brother Directory High
Medium
5090
WWW FrontPage htimage.exe High
Medium
5091
WWW Cart32 Remote Admin High
Medium
5092
WWW CGI-World Poll It High
Medium
5093
WWW PHP-Nuke admin.php3 High
Medium
5095
WWW CGI Script Center Account Manager Attack Medium
5096
WWW CGI Script Center Subscribe Me Attack
Medium
5097
WWW FrontPage MS-DOS Device Attack
Medium
5098
WWW OReilly Pro uploader.exe access
Medium
5099
WWW GWScripts News Publisher High
Medium
5100
WWW CGI Center Auction Weaver File High
Medium
5101
WWW CGI Center Auction Weaver Attack
Medium
5102
WWW phpPhotoAlbum explorer.php High
Medium
5103
WWW SuSE Apache CGI Source High
Medium
5104
WWW YaBB File High
Medium
5105
WWW Ranson Johnson mailto.cgi Attack
Medium
5106
WWW Ranson Johnson mailform.pl High
Medium
5107
WWW Mandrake Linux /perl High
Medium
5108
WWW Netegrity Site Minder High
Medium
5109
WWW Sambar Beta search.dll High
Medium
5110
WWW SuSE Installed Packages High
Low
5111
WWW Solaris Answerbook 2 High
Medium
5112
WWW Solaris Answerbook 2 Attack
Medium
5113
WWW CommuniGate Pro High
Medium
5114
WWW IIS Unicode Attack
High
6001
Normal SATAN Probe
High
6002
Heavy SATAN Probe
High
6050
DNS HINFO Request
Medium
6051
DNS Zone Transfer
Low
6052
DNS Zone Transfer from High Port
High
6053
DNS Request for All Records
Low
6054
DNS Version Request
Medium
6055
DNS Inverse Query Buffer Overflow
High
6056
BIND NXT Buffer Overflow
High
6057
BIND SIG Buffer Overflow
High
6100
RPC Port Registration
High

ID
ID
Recommended
Alarm Level
6101
RPC Port Unregistration
High
6102
RPC Dump
High
6103
Proxied RPC Request
Low
6104
RPC Set Spoof
High
6105
RPC Unset Spoof
High
6110
RPC RSTATD Sweep
High
6111
RPC RUSERSD Sweep
High
6112
RPC NFS Sweep
High
6113
RPC MOUNTD Sweep
High
6114
RPC YPPASSWDD Sweep
High
6115
RPC SELECTION_SVC Sweep
High
6116
RPC REXD Sweep
High
6117
RPC STATUS Sweep
High
6118
RPC ttdb Sweep
High
6150
ypserv Portmap Request
Low
6151
ypbind Portmap Request
Low
6152
yppasswdd Portmap Request
Disable
6153
ypupdated Portmap Request
Low
6154
ypxfrd Portmap Request
Low
6155
mountd Portmap Request
Disable
6175
rexd Portmap Request
Medium
6180
rexd Attempt
High
6190
statd Buffer Overflow
High
6191
RPC.tooltalk buffer overflow
High
6192
RPC mountd Buffer Overflow
High
6193
RPC CMSD Buffer Overflow
High
6194
sadmind RPC Buffer Overflow
High
6195
RPC amd Buffer Overflow
High
6200
Ident Buffer Overflow
High
6201
Ident Newline
High
6202
Ident Improper Request
High
6250
FTP Authorization Failure
Low
6251
Telnet Authorization Failure
Low
6252
Rlogin Authorization Failure
Low
6253
POP3 Authorization Failure
Low
6255
SMB Authorization Failure
Low
6300
Loki ICMP Tunnelling
High
B-9

ID
ID
Recommended
Alarm Level
6302
General Loki ICMP Tunneling
High
6500
RingZero Trojan
High
6501
TFN Client Request
High
6502
TFN Server Reply
High
6503
Stacheldraht Client Request
High
6504
Stacheldraht Server Reply
High
6505
Trinoo Client Request
High
6506
Trinoo Server Reply
High
6507
TFN2K Control Traffic
High
6508
Mstream Control Traffic
High
Connection Signatures
B-10
Signature ID
Sub Signature ID
Signature Name
Recommended
Alarm Level
3000
Connection Request - tcpmux
Disable
3000
Connection Request - echo
Disable
3000
Connection Request - discard
Disable
3000
11
Connection Request - systat
Disable
3000
13
Connection Request - daytime
Disable
3000
15
Connection Request - netstat
Disable
3000
19
Connection Request - chargen
Disable
3000
20
Connection Request - ftp-data
Disable
3000
21
Connection Request - ftp
Disable
3000
23
Connection Request - telnet
Disable
3000
25
Connection Request - smtp
Disable
3000
37
Connection Request - time
Disable
3000
43
Connection Request - whois
Disable
3000
53
Connection Request - dns
Disable
3000
70
Connection Request - gopher
Disable
3000
79
Connection Request - finger
Disable
3000
80
Connection Request - www
Disable
3000
87
Connection Request - link
Disable
3000
88
Connection Request - kerberosv5
Disable
3000
95
Connection Request - supdup
Disable
3000
101
Connection Request - hostnames
Disable
3000
102
Connection Request - iso-tsap
Disable
3000
103
Connection Request - x400
Disable
Signature ID
Sub Signature ID
Signature Name
Recommended
Alarm Level
3000
104
Connection Request - x400-snd
Disable
3000
105
Connection Request - csnet-ns
Disable
3000
109
Connection Request - pop-2
Disable
3000
110
Connection Request - pop3
Disable
3000
111
Connection Request - sunrpc
Disable
3000
117
Connection Request - uucppath
Disable
3000
119
Connection Request - nntp
Disable
3000
123
Connection Request - ntp
Disable
3000
137
Connection Request - netbios
Disable
3000
138
Connection Request - 138
Disable
3000
139
Disable
3000
143
Connection Request - imap2
Disable
3000
144
Connection Request - NeWS
Disable
3000
177
Connection Request - xdmcp
Disable
3000
178
Connection Request - nextstep
Disable
3000
179
Connection Request - bgp
Disable
3000
194
Connection Request - irc
Disable
3000
220
Connection Request - imap3
Disable
3000
372
Connection Request - ulistserv
Disable
3000
512
Connection Request - exec
Medium
3000
513
Connection Request - login
Medium
3000
514
Connection Request - shell
Medium
3000
515
Connection Request - printer
Disable
3000
530
Connection Request - courier
Disable
3000
540
Connection Request - uucp
Disable
3000
600
Connection Request - pcserver
Disable
3000
750
Connection Request - kerberosv4
Disable
3000
3128
Disable
3000
8080
Disable
4000
Udp Traffic - echo
Disable
4000
Udp Traffic - discard
Disable
4000
13
Udp Traffic - daytime
Disable
4000
19
Udp Traffic - chargen
Disable
4000
37
Udp Traffic - time
Disable
4000
53
Udp Traffic - dns
Disable
4000
69
Udp Traffic - tftp
Medium
4000
70
Udp Traffic - gopher
Disable
B-11
Signature ID
Sub Signature ID
Signature Name
Recommended
Alarm Level
4000
80
Udp Traffic - www
Disable
4000
88
Udp Traffic - kerberos-v5
Disable
4000
111
Udp Traffic - sunrpc
Disable
4000
123
Udp Traffic - ntp
Disable
4000
177
Udp Traffic - xdmcp
Disable
4000
179
Udp Traffic - bgp
Disable
4000
220
Udp Traffic - imap3
Disable
4000
372
Udp Traffic - ulistserv
Disable
4000
512
Udp Traffic - biff
Disable
4000
513
Udp Traffic - who
Disable
4000
514
Udp Traffic - syslog
Disable
4000
515
Udp Traffic - printer
Disable
4000
517
Udp Traffic - talk
Disable
4000
518
Udp Traffic - ntalk
Disable
4000
520
Udp Traffic - route
Disable
4000
2049
Udp Traffic - nfs
Disable
String Signatures
B-12

ID
ID
Recommended
Alarm Level
8000
2101
FTP Retrieve Password File
High
8000
2302
Telnet-/etc/shadow Match
High
8000
2303
Telnet-+ +
Low
8000
51301
Rlogin-IFS Match
High
8000
51302
Rlogin-/etc/shadow Match
High
8000
51303
Rlogin-+ +
Low
Cisco Intrusion
Detection System
Log Files
Overview
Cisco Intrusion Detection System (CIDS) provides four levels of
logging:
Events (Alarms)
Errors
Commands
IP Sessions
The active Cisco IDS log file located in /usr/nr/var. The IP log files
are located in /usr/nr/var/iplog. Each CIDS service maintains its own
error log file and is located in /usr/nr/var. The active log files are
closed and archived, and a new active log files are created when the
file size or time thresholds are exceeded. By default, log files will be
archived and a new one created when the active log reaches 1 GB or
after 60 minutes, which ever comes first. IP log files, by default, will
remain active for 30 minutes or until the session that triggered the IP
log action is terminated. Archived log files are located in
/usr/nr/var/new or CIDS log and error log files and in
/usr/nr/var/iplog/new for IP session log files.
This appendix will focus on CIDS log file filename conventions and
event and command records found in CIDS log files.
CIDS Log file filename convention
IP log file
CIDS log file
iplog.XXX.XXX.XXX.XXX.YYYYMMDDHHMM
iplogKeyword identifying the file as a

CIDS IP log session file.
XXX.XXX.XXX The IP address of the

attacking host.
YYYYYear the file was created.
MMMonth the file was created.
DDDay the file was created.
HHHour the file was created.
MMMinute of the hour the file was

created.
log.YYYYMMDDHHMM
Service Error log file
logKeyword identifying the file as a

CIDS log file.
XXX.XXX.XXXThe IP address of the

attacking host.
YYYYYear the file was created.
MMMonth the file was created.
DDDay the file was created.
HHHour the file was created.
MMMinute of the hour the file was

created.
error.service.processid
errorKeyword identifying it as a CIDS

service log file.
serviceCIDS service name.
processidNumeric value of the service

process identification number.
Some examples CIDS log files are:

log.200101301040
A CIDS log file created January 30, 2001 at 10:40.

iplog.10.0.0.84.200101301103
A CIDS IP session log file for attacking host, 10.0.0.84, created

January 30, 2001 at 11:03.
errors.managed.928
A CIDS error log file for the managed service. The managed service
has system process identification number 928.
C-2
The following table has the fields associated with event records found
in CIDS log files.
Event Record fields
Record Type
Record ID
Numeric value indicating the record number. The value

begins at 1,000,000 each time the packetd process is
started and is incremented by one.
GMT Date stamp
Greenwich Mean Time date stamp when the record was

generated. Format is YYYY/MM/DD
GMT Timestamp
Greenwich Mean Time time stamp when the record was

generated. Format is HH:MM:SS
Local Date stamp
Local date stamp when the record was generated.

Format is YYYY/MM/DD
Local Timestamp
Local timestamp when the record was generated.

Format is HH:MM:SS
Application ID
CIDS service that generated the record. Possible values

are as follows:
10000postofficed
10003managed
10004eventd
10005loggerd
10006smid
10007sapd
10008packetd
10010fileXferd
10010iosids
20001CSPM
Host ID
PostOffice host identification of the CIDS component

that was the source of the record.
Organization ID
PostOffice organization identification of the CIDS

component that was the source of the record.
Source Direction
The location of the attacking host that caused the

record to be generated. The keywords IN and OUT
specify if the host was inside or outside the defined
internal network.
Destination
Direction
The location of the target host that was the destination

of the attack. The keywords IN and OUT specify if the
host was inside or outside the defined internal network.
Alarm Level
Numeric value of the CIDS alarm severity level. Default

Severity values are as follows:
1Low
3Medium
5High
Cisco Intrusion Detection System Log Files C-3
Signature ID
CIDS signature identification number.
Sub-signature ID
CIDS sub-signature identification associated with the

signature identification.
Protocol
TCP/IPOnly supported protocols supported by CIDS.
Source IP
Address
The IP address of the attacking host that caused the

record to be generated.
Destination IP
Address
The IP address of the target host that was the

destination of the attack.
Source Port
Numeric value of the TCP/UDP source port.
Destination Port
Numeric value of the TCP/UDP destination port.
Data Source IP
Address
IP Address of a Cisco IOS router that is sending syslog

messages to this Sensor. The value 0.0.0.0 signifies
that the Sensor detected the attack.
Optional Event
detail
Additional information associated with certain CIDS

signatures.
Optional Event
context
Additional data associated with CIDS signatures.
The following is a sample Event record:

4,1000010,2001/01/30,17:03:47,2001/01/30,11:03:47,10008,8,100,OUT,IN
,5,8000,2302,TCP/IP,10.0.0.84,172.30.1.208,1045,23,0.0.0.0,/etc/shad
ow,FFFD01FFFD03FFFB01610080073776964733E202F6574632F736861646F
C-4
Event (Alarm) record.
1000010
The Event record number generated by CIDS.
2001/01/30
The record was generated January 30, 2001.
17:03:47
The record was generated at 5:03:47 PM.
2001/01/30
11:03:47
The record was generated at 11:03:47 AM local

time.
10008
packetd generated the event.
This is the host identification of the Sensor or

Director that generated the log record.
100
This is the organization identification of the Sensor

or Director that generated the log record.
OUT
The source of the attack was outside of the defined

internal networks.
IN
The destination of the attack was inside the defined

internal networks.
The alarm has a High severity level.
8000
The CIDS signature that triggered was a string

signature.
2302
The CIDS string sub-signature identification

i t d ith
t hi / t / h d
associated with matching /etc/shadow

TCP/IP
Indicates TCP/IP network traffic.
10.0.0.84
The Source IP address that triggered the event.
172.30.1.208
The Destination IP address of the triggered event.
1045
The source port number of the network traffic that

triggered the event.
23
The destination port of the attacking host.
0.0.0.0
0.0.0.0 signifies that the Sensor specified by the

recorded Host and organization identification
detected this event.
/etc/shadow
The string /etc/shadow triggered the logging of this

event.
FFFD01FFFD03FFF
B0161008007377
6964733E202F6574
632F736861646F
Provides detailed context data associated with the

signature detected.
The following table has the fields associated with command log
records found in CIDS log files.
Command Log Record fields
Record Type
Record ID
Numeric value indicating the record number. The value

begins at 1 for each application every time CIDS is
started and is incremented by one. For example,
managed and postofficed command log records both
start at 1 and increment each time the respective
service generates a record.
GMT Date stamp
Greenwich Mean Time date stamp when the record was

generated. Format is YYYY/MM/DD
GMT Timestamp
Greenwich Mean Time time stamp when the record was

generated. Format is HH:MM:SS
Local Date stamp
Local date stamp when the record was generated.

Format is YYYY/MM/DD
Local Timestamp
Local timestamp when the record was generated.

Format is HH:MM:SS
Application ID
CIDS service that executed the command
10000postofficed
10003managed
10004eventd
10005loggerd
10006smid
10007sapd
10008packetd
10010fileXferd
10010iosids
20001CSPM
Host ID

that was the source of the record.
Organization ID

component that was the source of the record.
Application ID
CIDS service that requested the command be executed.
10000postofficed
10003managed
10004eventd
10005loggerd
10006smid
10007sapd
10008packetd
10010fileXferd
10010iosids
20001CSPM
Host ID

that requested the command is executed.
Organization ID

component that requested the command is executed.
Command
The command executed.
The following is an example of a Command Log record:

3,24,2001/01/30,17:18:35,2001/01/30,11:18:35,10003,8,100,20001,84,10
0,EXEC ShunNet 171.69.2.0 255.255.255.0 1440
C-6
Command log record
24
The command log record number generated by

CIDS.
2001/01/30
17:18:35
The record was generated at 5:18:35 PM.
2001/01/30
11:18:35
The record was generated at 11:18:35 AM local

time.
10003
managed generate the record.

Director that generated the log record.
100

Di t th t
t d th l
d
or Director that generated the log record.

20001
Identification number identifying CSPM as the

service requesting the command be execute.
84

Director that requested the command is executed
100

or Director that requested the command is executed.
EXEC ShunNet
171.69.2.0
255.255.255.0 1440
The CIDS component issued a Block command to

block the network 171.69.2.0 for 1 day.
Cisco Intrusion
Detection System
Software Update
Overview
This appendix discusses the process and procedures to update the Cisco Intrusion
Detection System (CIDS) software.
Why backup the Sensor or Director
How to obtain CIDS software updates
CIDS software update requirements
CIDS software update installation
Removal of CIDS software updates
Upgrade and recovery using CIDS Upgrade/Recovery CD
Why Backup the Sensor or Director

This section discusses the importance of performing a backup of the Sensor or
Director prior to the installation of software updates.
CIDS software updates are released to keep the product current and fix any
identified software bugs. The software updates will replace CIDS services and
configuration files. The Update/Recovery CD will format your entire hard drive to
insure that the Sensor was restored to the initial factory software installation.
Consequently, it is good practice to make backups of your Sensor prior to the
installation of any software updates. Backups allow you to fall back to the
configuration prior to the update if you experience any problems. A full backup of
the Sensor or Director is recommended. However, if a full backup cannot be
performed, the following directories should be archived at a minimum:
/usr/nrCIDS installation directory and subdirectories
/opt/OVHP OpenView installation directory (Director only)
Note
D-2
The directories are for UNIX Sensors or Directors.
How to Obtain CIDS Software Updates

This section discusses how to obtain CIDS software updates.
A valid Cisco Connection Online (CCO) account is required to obtain CIDS
software updates. Software updates are found at CCOs Software Center. CIDS
software is located with the Cisco software products. Software updates can be
found for the following CIDS products:
Appliance Sensors
IDS Management
The software files should be downloaded and transferred to the Sensor or

Director.
CIDS Software Upgrade
D-3
CIDS Software Update Requirements

This section discusses the hardware and software requirements needed for
installing a CIDS software update.
Software updates are CIDS product or platform dependent. For instance, you
cannot apply a software update for a HP-UX Sensor to a Solaris x86 Sensor.
Download any readme files associated with the software update to determine the
latest hardware or software requirements.
Note
D-4
Readme files contain the current information regarding the software update.
Please read the file to insure your Sensor or Director meets the requirements.
CIDS Software Update Installation

This section discusses the recommended software update installation process.
Software update files for UNIX-based CIDS Sensors or Directors are released as
UNIX tar or binary files. The filename extensions are .tar for tar files and .bin for
binary files. The following steps are performed to install a signature update for a
UNIX CIDS Sensor or Director with a binary software update file:
Step 1
Download the software update file.
Step 2
Log in as root.
Step 3
(Optional) Create a temporary directory:

# mkdir /var/temp
Step 4
Transfer the files to the temporary directory on the Sensor or Director.
Step 5
Telnet to the CIDS Sensor or Director and log in as root.
Step 6
Change to the directory were the software update files are stored:
# cd /var/temp
Step 7
Change the file permissions to 755. This will make the file executable.
# /var/temp> chmod 755 filename.bin
Where filename is the CSIDS software upgrade filename.
Step 8
Execute the install command:

# /var/temp> filename.bin install
or
# /var/temp> filename.bin -I
The following steps are performed to install a signature update for a UNIX CIDS
Sensor or Director with a tarred software update file:
Step 1
Step 2
(Optional) Create a temporary directory.

# mkdir /var/temp
Step 3
Step 4
Telnet to the CIDS Sensor or Director and login as root.
Step 5
Change to the directory where the software update files are stored:
# cd /var/temp
Step 6
Untar the software update file:

# /var/temp> tar -xvf filename.tar
Step 7

# /var/temp> ./install
D-5
Removal of CIDS Software Updates

This section discusses how to remove software updates.
Software update files for UNIX-based CIDS Sensors or Directors are released as
UNIX tar or binary files. The filename extensions are .tar for tar files and .bin for
binary files. The following steps are performed to remove a signature update for a
UNIX CIDS Sensor or Director with a binary software update file:
Step 1
Step 2
Log in as root.
Step 3

# mkdir /var/temp
Step 4
Step 5
Step 6
Change to the directory were the software update files are stored:
# cd /var/temp
Step 7
Change the file permissions to 755. This will make the file executable.
# /var/temp> chmod 755 filename.bin
Step 8
Execute the uninstall command filename.bin:

# /var/temp> filename.bin uninstall
or
# /var/temp> filename.bin -U
The following steps are performed to install a signature update for a UNIX CIDS
Sensor or Director with a tarred software update file:
Step 1
Step 2

# mkdir /var/temp
Step 3
Step 4
Step 5
Change to the directory where the software update files are stored:
# cd /var/temp
Step 6
Untar the software update file:

# /var/temp> tar -xvf filename.tar
Step 7

# /var/temp> ./install -retrieve
D-6
Upgrade and Recovery Using CIDS

Upgrade/Recovery CD
The CIDS Upgrade/Recovery CD restores a Sensor to the initial factory software
installation. Its use is restricted to upgrading or recovering CIDS Sensor
appliances.
WARNING The CIDS Upgrade/Recovery CD completely erases the contents of your

Sensor's hard drive. All configuration data stored on the Sensor will be overwritten. Make
backups of any configuration files prior to performing the upgrade or recovery.
The following steps are performed to recover or upgrade a Sensor to the initial
factory software installation:
Step 1
Attach a monitor and keyboard to the Sensor.
Step 2
Log in to the Sensor as root and run sysconfig-sensor.
Step 3
Record the Sensor configuration information using the Sensor information

worksheet on the last page of this appendix.
Step 4
Place the CIDS Upgrade/Recovery CD in the CD-ROM drive.
Step 5
Reboot the Sensor using the init or reboot command:

# init 6
or
# reboot
Step 6
Press F2 to enter the BIOS Setup Menu.
Step 7
Verify that the boot sequence is Floppy Drive, CD-ROM, Hard Drive. The Sensor
was booted from the CD before the hard drive to perform the upgrade/recovery.
Step 8
Exit the BIOS Setup Menu, saving changes to the boot sequence if necessary.
Step 9
Read the upgrade or recovery installation instructions. Use the spacebar to scroll
through the instructions.
Step 10 Enter yes when prompted to re-image the Sensor. The upgrade or recovery will
take approximately between 3060 minutes.

Note
Your screen may blink or blank out depending on the monitors energy saving
capabilities. DO NOT turn the Sensor off. The upgrade/recovery may still be active.
Step 11 Remove the Upgrade/Recovery CD, and reboot the Sensor when prompted.
Step 12 Enter ok to reboot the Sensor.
The Sensor is restored to the initial factory software installation. The passwords
are reset to the default password of attack. The Sensor will need to be
bootstrapped using the sysconfig-sensor command before it will communicate
with the Director.
D-7
Sensor Information Worksheet

The Sensor information can be collected by running the sysconfig-sensor
command and selecting the associated options.
Sensor Network Information (options 1-4)
IP Address
IP Netmask
IP Host Name
Default Route
Network Access Control (option 5)
Allowed Host (s)
Allowed Services
Communications Infrastructure (option 6)
Sensor Host ID
Sensor Host Name
Sensor Organization Name
IDS Manager Host ID
IDS Manager Organization ID
IDS Manager Organization Name
Current Inbound Configuration [IDS Manager to Sensor] (option 9)
Cipher Key
Authentication Key
SPI
Current Outbound Configuration [Sensor to IDS Manager] (option 9)
Cipher Key
Authentication Key
SPI
D-8
Cisco Intrusion
Detection System
Signature Tuning and
Port Mapping
Overview
Cisco IDS allows for certain signatures to be tuned for your network environment.
Signature tuning provides the security administrator with more control over how
the signatures are triggered.
CIDS also enables you to map TCP ports to CIDS intrusion detection engines.
Signature port mapping provides the security administrator with the ability to
configure ports of interest for CIDS signatures that detect malicious activity
associated with HTTP, Syn Flood, Telnet, and HiJack attacks.
Signature Tuning Parameters

The following table specifies the CIDS signatures, and their parameters and
values that can be modified.
Signature
ID
Signature Name
Parameter(s)
1103
IP Fragmentation
Overlap
Expiration
1-250 (10)
2100
ICMP Net sweep-echo
Expiration
1-65536 (90)
Threshold
1-65536 (5)
ICMP Net sweeptimestamp
Expiration
1-65536 (90)
Threshold
1-65536 (5)
ICMP Net sweepaddress-mask
Expiration
1-65536 (90)
Threshold
1-65536 (5)
ICMP Flood
Expiration
1-65536 (5)
Threshold
1-65536 (25)
Expiration
1-65536 (5)
Threshold
1-65536 (25)
Expiration
1-65536 (90)
Threshold
1-65536 (5)
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FRAG SYN Port

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FIN Low Port

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FRAG FIN Port

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP High Port Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FIN High Port

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FRAG high FIN

Port Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP NULL Port Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FRAG NULL Port

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP SYN FIN Port

S
Expiration
1-65536 (90)
2101
2102
2152
2153
3001
3002
3003
3005
3006
3010
3011
3012
3015
3016
3020
E-2
Cisco Secure Intrusion Detection 2.1
ICMP Smurf
TCP Port Sweep
TCP SYN Port Sweep
Allowable Value(s)
(Default)
Signature
ID
Signature Name
Sweep
Parameter(s)
Allowable Value(s)
(Default)
Threshold
1-65536 (5)
TCP FRAG SYN FIN

Port Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP SYN Host Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FRAG SYN Host

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FIN Host Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FRAG FIN Host

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP NULL Host

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FRAG NULL Host

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP SYN FIN Host

Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
TCP FRAG SYN/FIN

Host Sweep
Expiration
1-65536 (90)
Threshold
1-65536 (5)
3045
TCP Queso sweep
Expiration
1-65536 (90)
3050
Expiration
1-65536 (5)
Threshold
1-65536 (50)
3021
3030
3031
3032
3033
3034
3035
3036
3037
3106
Sendmail SPAM
Max Number
of RCPT TO
Allowed
1-65536 (50)
3108
MIME overflow bug
Max MIME
content length
1-65536 (200)
3109
Qmail Length Crash
Max length for

qmail overflow
1-65536 (250)
3219
WWW PHP buffer

overflow
Max length for

qmail overflow
1-65536 (128)
3220
WWW IIS long URL

crash
Max length for

HTTP IIS
overflow
1-65536 (7168)
3300
NetBIOS OOB data
Expiration
1-65536 (10)
3307
Windows Redbutton
Expiration
1-65536 (30)
3526
IMAP Login Buffer

Overflow
Max Length for

IMAP overflow
1-65536 (128)
3650
SSH RSAREF2 Buffer

Overflow
Expiration
1-65536 (15)
4001
UDP Port Sweep
Expiration
1-65536 (90)
CIDS Signature Tuning and Port Mapping
E-3
Signature
ID
4002
UDP Flood
Parameter(s)
Allowable Value(s)
(Default)
Threshold
1-65536 (5)
Expiration
1-65536 (10)
Threshold
1-65536 (100)
6001
Normal SATAN probe
Expiration
1-65536 (15)
6110
RPC RSTATD Port

Sweep
Expiration
1-65536 (20)
Threshold
1-65536 (5)
RPC RUSERSD Port

Sweep
Expiration
1-65536 (20)
Threshold
1-65536 (5)
RPC NFS Port Sweep
Expiration
1-65536 (20)
Threshold
1-65536 (5)
RPC MOUNTD Port

Sweep
Expiration
1-65536 (20)
Threshold
1-65536 (5)
RPC YPPASSWDD
Port Sweep
Expiration
1-65536 (20)
Threshold
1-65536 (5)
RPC SELEVT SVC

Port Sweep
Expiration
1-65536 (20)
Threshold
1-65536 (5)
RPC REXD Port

Sweep
Expiration
1-65536 (20)
Threshold
1-65536 (5)
RPC STATUS Port

Sweep
Expiration
1-65536 (20)
Threshold
1-65536 (5)
RPC TTDB Port

Sweep
Expiration
1-65536 (20)
Threshold
1-65536 (5)
SMB Authorization
failure
Expiration
1-65536 (60)
Threshold
1-65536 (3)
ICMP Loki
Expiration
1-65536 (60)
Threshold
1-65536 (3)
Expiration
1-65536 (60)
Threshold
1-65536 (3)
6111
6112
6113
6114
6115
6116
6117
6118
6255
6300
6302
E-4
Signature Name
Cisco Secure Intrusion Detection 2.1
ICMP Modified Loki

The following table specifies the default port mappings for CIDS signature
groups. The allowable port values for each signature group is a numeric value
from 1-65535.
Signature Group
Default Ports
TCP HIJACK Ports
21,23,25,80,110,143,513
TCP SYNFLOOD Ports
21,23,25,80,110,113,119,143,513,1080,8000,8080
TCP Telnet Ports
23
TCP HTTP Ports
80,3128,8080
WARNING CIDS will not detect attacks launched against ports deleted from a specific
group of signatures.
CIDS Signature Tuning and Port Mapping
E-5
Contact VSEC Training

VSEC Training values your opinion. Let us know what you think about this
course, any suggestions you have for this course, or any inaccuracies that you find
in the course material. Send an e-mail to vsec-tng@cisco.com. You must include
one of the following statements in the subject line of your e-mail, which
summarizes your message:
Kudos
Technical inaccuracies
Grammatical/style inaccuracies
General suggestions

CISCO IDS Student Guide PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CISCO IDS Student Guide PDF

Transféré par

Droits d'auteur :

Formats disponibles

CSIDS

Cisco Secure Intrusion

Cisco Systems, Inc.

Use the CIDS NSDB to view signature and

Cisco Secure Intrusion Detection System 2.1

Copyright 2001, Cisco Systems, Inc.

Course Objectives (cont.)

Copyright 2001, Cisco Systems, Inc.

Course Agenda (cont.)

2001, Cisco Systems, Inc.

Cisco Secure Intrusion Detection System 2.1

Copyright 2001, Cisco Systems, Inc.

Length and times

Break and lunch room

2001, Cisco Systems, Inc.

2001, Cisco Systems, Inc.

Copyright 2001, Cisco Systems, Inc.

IDS Switch Module

2001, Cisco Systems, Inc.

Cisco Secure Intrusion Detection System 2.1

Copyright 2001, Cisco Systems, Inc.

Lab Visual Objective

2001, Cisco Systems, Inc.

Copyright 2001, Cisco Systems, Inc.

Network Security and

Need for network security

Attack types and methods

The Cisco Security Wheel

Cisco AVVID and SAFE

2-2 Cisco Secure Intrusion Detection System 2.1

Copyright 2001, Cisco Systems, Inc.

Copyright 2001, Cisco Systems, Inc.

Network Security and Cisco Intrusion Detection 2-3

Need for Network Security

Security Incidents on the Rise

The Internet has made

2001, Cisco Systems, Inc.

2-4 Cisco Secure Intrusion Detection System 2.1

Copyright 2001, Cisco Systems, Inc.

Four Basic Types of Threats

2001, Cisco Systems, Inc.

There are four primary threats to network security:

Unstructured threats consist of mostly inexperienced individuals using easily

Copyright 2001, Cisco Systems, Inc.

Network Security and Cisco Intrusion Detection 2-5

are hired by organized crime, industry competitors, or state-sponsored intelligence

2-6 Cisco Secure Intrusion Detection System 2.1

Copyright 2001, Cisco Systems, Inc.

Attack Types and Methods

2001, Cisco Systems, Inc.

Reconnaissance is the unauthorized discovery and mapping of systems, services,

Copyright 2001, Cisco Systems, Inc.

Network Security and Cisco Intrusion Detection 2-7

2001, Cisco Systems, Inc.

Access is an all-encompassing term that refers to unauthorized data manipulation,

2-8 Cisco Secure Intrusion Detection System 2.1

Copyright 2001, Cisco Systems, Inc.

2001, Cisco Systems, Inc.

Denial of service (DoS) is when an attacker disables or corrupts networks,

Copyright 2001, Cisco Systems, Inc.

Network Security and Cisco Intrusion Detection 2-9

Common commands or administrative utilities