Tài liệu Cisco Security Setup & Configuration: Part 3 – Network & Host-Based IPS pdf

Cisco Security
Setup & Configuration:
Part 3 – Network &
Host-Based IPS
1-800-COURSES
www.globalknowledge.com
Expert Reference Series of White Papers
Introduction
This paper is the third in a three-part series of white papers, each of which focuses on a functional area of
securing your network. So far, we have a perimeter router secured and configured with interface Access
Control Lists (ACLs). We also have a firewall using stateful inspection and switches in between controlling our
ports for secure end station connectivity. This all sounds very impressive and complete, but is it?
Of course not,
or this white paper series would be complete. The problem is that routers, firewalls, and switch-
es aren’t always enough. There are still attacks out there that travel over valid client requests and responses.
These attacks would be permitted by our perimeter ACLs and stateful firewalls. Or perhaps a worm infects an
end station and tries to propagate throughout our network. Maybe even some of our own end-users decide to
chew up all of our bandwidth downloading Spider Man II using Bit Torrent.
In all of these situations static ACLs, or even stateful firewalls would not be enough. That is where we install,
configure, and use Network- and Host-based Intrusion Prevention Systems (IPS).
IPS/HIPS
IPS/HIPS provide for an increased level of protection not available from a static access list or stateful firewall
inspection. IPS and HIPS offer security by sensing abnormalities in traffic communications or protocol,
and
packet behaviors that are known to have malicious objectives. Here are some recommendations for installing
and hardening your IPS sensors:
Allowing for a sufficient discovery period prior to sensor installation is a key item often overlooked. Many envi-
ronments simply try to rack and stack a sensor, give it a quick IP address, and let it do its thing. Then they
wonder why there is a high level of false positives, an interruption to network communication, or an unman-
ageable amount of log information.
To properly configure and optimize your IPS sensor, I suggest a minimum of two weeks (ideally a month) of

network discovery and communications analysis. Options available to help you discover network applications
would be client/end-user questioning, packet sniffer, and Network-Based Application Recognition (NBAR). The
information gained from your investigation period can be used to fine-tune your sensor to your environment.
Secure sensor management is just as important as securely managing your switch,
router and firew
all. Here we
not only need to ensure secure access to the sensors configuration but also to the sensor’s log information. We
have a simple saying: “If you’re going to log it, you must read it.” This means dedicating a management sta-
tion to retrieve, store, and read your sensor log files. On this station, install IPS Device Manager (IDM) and IPS
Event Viewer (IEV).
When installing and configuring these applications
,
be sure to use secure management pro-
Isaac A. Valdez, Global Knowledge Instructor, CCSI, CCSP, CCNP, CCDP
Cisco Security Setup & Configuration:
Part 3 – Network & Host-Based IPS
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 2
t
ocol alternatives, such as https over http, and to define the exact management station addresses allowed to
manage the sensor. For example, use IDM via Configuration/Sensor Setup/Allowed Hosts/Add to define the
exact management subnet allowed to manage the sensor.
Having a lab environment to test your configuration changes and upgrade is crucial. For that reason, an addi-
tional sensor that is not a part of your production network is suggested. This allows you to test operating sys-
tem and signature upgrades, signature tuning, and creation before rolling these changes out to your produc-
tion network. Once your tests prove to be safe for your production network, you should roll these changes out
to non-critical parts of your corporate environment first before finally making these tested changes on high-
profile devices.
As you make changes to the installed signatures, document the changes in as much detail as possible. This

allows you to verify that new signature updates have not overwritten your custom settings and will help you
troubleshoot your configuration in the event of a problem.
Integrated Platform
While our focus has been largely on specialized equipment offering a specific service, there are devices avail-
able from Cisco Systems that integrate all of these services into a single affordable platform.
Integrated Services Routers (ISRs)
ISRs are the new 1800, 2800, and 3800 series routers, which have the ability to integrate routing, security,
voice, and wireless into a single chassis
. From a security standpoint, they support hardware co-processor cards
to off-load the tunneling, authentication, and encryption services of a VPN. These models also support a subset
of IPS features that include over 700 IPS signatures and the ability to create signatures specific to your envi-
ronment.
Adaptive Security Appliances (ASAs)
ASAs are the next generation firewalls available from Cisco Systems. It is important to understand that the
ASAs are not designed as a replacement to the existing Packet Internet Exchange (PIX) product line; instead,
they fit nicely to fill in k
ey areas where a PIX may be too much or not enough for the current environment.
As of the writing of this document,
there are 3
ASA models available: the ASA 5510, 5520, and 5540. Available
in all 3 models are the IPS, Content Security Service, and 4-port Gig module. The IPS module (AIP-SSM) pro-
vides a full-features network based IPS that can be configured and monitored just as an external sensor. The
Content Security module (CSC-SSM) provides a full suite of Anti-X features, including anti-Virus, Phishing,
SPAM, Trojan, and Malware, plus URL filtering. These modules, once inserted into the expansion bay of the new
ASAs, provide high-level security services in a consolidated chassis via a single command set, all at an afford-
able price when compared to purchasing individual security appliances
.
Enterprise 6500 and 7600 Series Devices
These combine high performance, high port density, and advanced features into a single module-based chassis.
From a security standpoint, the operating system natively supports all security features mentioned in the

“Switch Security”
section of this white paper
.
Now we add to these features a suite of service modules that
include a F
irew
all Services Module (FWSM), Intrusion Prevention Services Modules (IPSM), and VPN Service
Module (VPNSM). These service modules integrate advanced security features with high backplane speeds to
offer enterprise-class security services.
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 3
Management Protocols
Now that your network is installed and configured to provide all of the services needed, per your corporate
security policy, how do you manage it? Many environments are perfectly content with managing their network
by the easiest and quickest means available. This is a BIG mistake! Many management applications, such as
remote shell (rsh) or telnet, send all details between the management station and managed device in plain
text. This allows anyone who is in the same VLAN (either manually configured or through a compromised con-
nection) to view all of your commands and parameters with a simple protocol analyzer. Sure, switches help to
minimize the traffic an end port receives, and you can implement usernames and passwords to access your
device, but keep in mind that all communications still crosses the wire in plain text. For this reason, you should
use secure and efficient management protocols to connect to your enterprise devices.
Let’s review some management protocol alternatives and methods for securely managing your devices:
Secure versus Non-Secure Versions:
ftp over tftp tftp does not use credentials before accepting file requests or sending file responses.
Using ftp at least allows you to require credentials before files are transferred.
scp over ftp When possible the secure copy protocol (scp) should be used even over ftp. While ftp
allows for the checking of credentials by way of authentication, all information
exchanged (credentials and files) are sent across the network in plain text. For that
reason, scp is suggested for use over ftp when supported by the operating system or

appliance.
ssh over telnet Just as in tftp and ftp, telnet communicates all information in the clear. To make mat-
ters worse, by default, telnet will send only one character per packet. This means that
not only is there is an incredible amount of padding in each packet, but all of your
sensitive information is sent in plain text for others to see. This is the driving force
behind using secure shell (ssh) as a secure management alternative for managing all
network devices
. When we say ‘all’, we mean all; ssh can be configured on any oper-
ating system where supported. This means router, switches, firewalls, and even
servers. To find out more, visit www.openssh.org.
https over http
Http is another popular protocol that sends all information in plain text. Even though
this protocol supports authentication, all communications are still sent in the clear.
By using https, you first perform authentication with the end device and then encrypt
all communications to follow.
Authenticated NTP
In many environments, time is paramount. Time can be used for timed access restric-
tions, daily authentication and access, digital certificates, building access, and trou-
bleshooting by way of internal and system log files. If time is compromised, many
systems can be at risk. As a result, using authenticated ntp peers is highly recom-
mended. Many environments will purchase and configure internal ntp appliances just
to ensure a high degree of security and control.
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 4
s
nmp version 3 The Simple Network Management Protocol (SNMP) has been around for almost 20
years and, even though it provides a great method of network discovery and config-
uration, it has done so in a very insecure manner. That is, until version 3.
Ver. 1: Provides for no authentication or protection (encryption) of information

transferred. All a management station needs is the assigned community
strings for your Read Only and Read Write device attributes.
Ver. 2: Provide for hashed authentication, but still transfers your device attributes in
plain text.
Ver. 3: Provides the ability to authenticate the requesting management station
using a hashed pass phrase and protect the information transferred (privacy)
using DES, 3DES, and AES encryption algorithms.
T
he main stumbling block for migrating to SNMP version 3 is the investment
of upgrading. Each operating system(s) and application(s) must support this
new version. You must configure all of your managed devices and train your
administrators to use these new features
. All of this tak
es time and money
.
Many environments may not have such resources or be able to prioritize
such a need at the moment.
One-Time Passwords In any system where user credentials (username and password) are required, the
leaking of these credentials is always a weak point. One way to minimize your expo-
sure would be to change user credentials on a set schedule
, every 30 days as an
example. Still, the user credentials could be compromised within this time period,
rendering everything insecure again until the next change schedule. A final solution
to this problem would be the use of One-Time Passwords (OTP).
There are three components to the OTP authentication system: a user with a unique
key fob (e.g., token card), an authenticating device (e.g., router), and authentication
server (e.g., RSA token server). The key fob held by the user is registered to the user
on the authentication server by a unique serial number. This key fob generates a
unique value at a set interval (e.g., every 60 sec.). User credentials are required
before the user can connect to and communicate through the perimeter router

.
At
the time of connection,
when the user is prompted by the router for authentication
credentials, the user enters username, pin, and unique value found on the key fob.
Here you have the user entering credentials made up of something they know (user-
name and pin) plus a v
alue unique to them (random number) by w
ay of the k
ey fob
.
Now
,
if their authentication credentials are compromised,
those v
alues will only be
valid until the fob generates a new random value, which is less than 60 seconds.
You’d better hurry!
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 5
Suggested Hardening
Now that you have configured secure alternatives for device management and enabled secure authentication
with OTPs, you may want to harden the managed device even more by defining the permissible management
addresses.
Router management security, covered in the “Router Hardening” section of this series, suggested the use of
the “access-class” command to define permissible source addresses for telnet or ssh sessions. Configure a
standard ACL to permit the source addresses of the desired management stations, and then apply this ACL in
“line vty” mode using the “access-class” command. Now, the only management stations allowed to ssh into
the router will be those permitted by the standard ACL.

These same concepts hold true on the Firewall, IPS Sensor, and VPN Concentrator. You just configure these per-
mitted addresses in different ways using different management utilities.
• On the PIX/ASA firewall, you would use the “telnet,” “ssh,” and “http” commands to define the permis-
sible addresses and ingress interface for such management traffic types.
• On the IPS Sensor, you would use IPS Device Manager (IDM) and navigate to Configuration/Sensor
Setup/Allowed Hosts/Add to define the exact management subnet allowed to manage the sensor.
• Finally, the VPN Concentrator is secured through the Administration/Access Rights/Access Control List
options found within the web management interface.
Additionally, on the router, you may want to utilize the “source-interface” command for telnet, ssh, syslog, ntp,
and tftp, to name a few. You point the source-interface command to the routers “loopback” interface. This
command defines the source interface address (now loopback) from where all of the above-listed protocol
communications will source their pack
ets
. Now you can create perimeter ACL entries to permit only those pro-
tocols when coming from those addresses, the addresses applied to the router(s) loopback interface. The end
result is to allow only management protocol communications to and from your infrastructure equipment and IT
subnet.
Approach to Device Management (In-Band versus Out-of-Band)
In-Band uses the same network to carry user traffic and management traffic alike. Out-of-Band (OOB) creates a
separate network dedicated to carrying only management communications.
When using the above-listed protocols (telnet or ssh, http or https) to manage your network, it is important to
understand that these packets could be crossing the same subnets with your user’s traffic. Again, if insecure
protocols are used (telnet,
http), end users could capture your management credentials and even device con-
figurations. Additionally, by using the very network that carries user traffic to manage your devices’ “In-Band
Management,
”
you run the risk of loosing connectivity to your devices when the network experiences a failure
.
For that reason, the OOB alternative is available.

OOB network management uses a completely separate infrastructure to carry your management traffic.
Specifically, there are two types to review:
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 6
•
First, you have an OOB management option that uses Console Servers. These are devices that connect to
the console ports of your networking equipment and provide physical access to the appliance even over
long distances. The console server could be a true console server from a dedicated manufacturer, such as
Cyclades, or an asynchronous module installed into your 2600 series router, for example. From the com-
fort of your desktop, you would ssh (of course) to the console server. There, you chose the end device
you want to manage, either through a web interface or simple command line. Figure 8 shows a sample
topology using a Cisco 2511 as your console server.
The benefit of this approach is direct, constant access to the end device, even in the event of a network
failure. As long as you can access the console server (via modem, if needed), you can access the end
device. Now, you can manage your router, even if routing fails or manage your switch before the needed
VLANs have even been created. This approach truly offers constant access. Of course, there is a problem,
which is why we’re reviewing two options. Since all communications from the console server to the end
device are character-based (no IP communication is used), you do not have the ability to run IP-based
applications
,
such as syslog,
snmp
,
ntp, and the like. That is where the second solution would be useful.
• Secondly, you have an OOB approach that still uses a separate physical infrastructure, but this time the
infrastructure is created by a separate VLAN. This VLAN is dedicated to pass only IP-based management
communications, such as syslog, snmp, ntp, http, and others, as needed. This VLAN must exist throughout
your campus network.
As what is known as an end-to-end

VLAN
,
which is not without its own consider
-
ations (we will have to save this for another white paper).
T
his means a dedicated end-to-end
VLAN on
all switches, interface, or sub-interface on all routers, firewalls, and the external interface of your VPN
Concentrator. Now, you can use your standard IP-based management applications, as you have direct IP
access to each device.
This approach is not without its issues as well;
you may still loose connectivity
, if routing or IP communi-
cation is interrupted.
You will also never have full access to the device by way of tracking the boot
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 7
p
rocess or entering “monitor” mode (they require direct connectivity to the console port). Nevertheless,
this approach still offers great value by way of logging, remote access, and device tracking/status, and
configuration management.
• Each approach has its own benefits and considerations, which is why a common solution for enterprise
networks is to use a combination of the two. Many environments will dedicate a VLAN and needed
interfaces for dedicated IP-based management applications. Additionally, a console server will be
installed and connected to the console port of each device to provide access in times of network out-
ages or misconfiguration.
Change Management/Control
A final, but equally important, aspect of network security is change management and control. Once your sys-

tems are configured and operating properly, it is important to control access to their configurations and track
all changes made. This level of monitoring offers insight and control into the changes made to the devices that
make up your network infrastructure.
Document! Document! Document!
If you’re the average network engineer, you do not like to be tied down to your desk typing away for hours at
a time just to create a document explaining all the things you already know! The key here is not to document
all network details for your benefit but for the benefit of your teammates, fill-ins
, and management. Detailed
network documentation is invaluable for many reasons. It is invaluable to the new hire when learning about
your network, the poor guy who has to troubleshoot a networking problem at 3 A.M., or the lucky person who
get to replace you while you’re attending new security training classes
. Bottom line, documentation is a critical
part to network operation, learning, troubleshooting and, yes, security. Get used to it—make documenting
your network a continuous function and part of your job description.
• While documenting your network, strongly consider saving your documents in industry standard formats
such as .pdf or .html for your documents and .png for your diagrams. Then store these documents (both
electronically and physically) in a central location.
An IT server that is part of the corporate backup rota
-
tion would be ideal for the electronic formats, while a simple 3-ring binder locked in a team lead’s desk
would be a good place for the physical copy. I suggest time stamping each version and print out to keep
track of which document is most up-to-date.
• Update this documentation on a regular basis. Make this part of your work-cycle and job description to
ensure your documentation is as accurate as possible. There are few things worse than trying to trou-
bleshoot a network problem and searching for a network diagram only to find an hour later that this
diagram is six months old.
• A sound approach to ensuring that you have enough time to document your network is to add 15 –
20% to your project time just for documentation. Once the project is approved, you automatically have
extra time just for documentation.
IT Support and Repair Ticketing System

Many in-house support departments use a ticketing and repair system. This allows them to centralize all sys-
tems-related issues reported by end users and track the progress repairing those systems. Such a process is
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 8
i
deal for any size environment; all you need to do is pick a solution to match the size of your company. Your
solution could range from a simple email address to report and track issues all the way to a custom relational
database stored on a central server. The most important feature of your tracking system should be the ability
to search previous repair tickets. Too often, engineers will spend time helping a user or troubleshooting a sys-
tem that is experiencing the same problem Bob fixed just last week.
Such a system benefits everyone in your IT department. Management benefits by having a system to meter the
progress or workload of their engineers to monitor work load, hiring, or pay increases. Engineers benefit not
only by the searching option, but also in justifying requests for additional resources such as hardware, soft-
ware, engineers, and, yes, even salary (that’s a resource too).
Key features to look for in such a system would be a standard scalable database format. Pick a system where
your database can grow by simply adding more resources to the supporting server (hard drive, RAM, controllers)
or by choosing a database format that can be easily exported and imported into a more advanced structure. For
example, start with an Access database on a shared workstation and later grow into a relational database
stored on an SQL server
. Additionally, you want your solution to offer extensive, even customizable, fields to
maintain system and user information. Lastly, this solution should offer rich search and reporting capabilities.
System Flow Charts (Failure, Upgrade, and Replacement)
These can also be categorized under documentation. Here, you would create a flow chart outlining each
“process” under the control of the IT department. This could be as simple as creating a new user account in
your Directory, troubleshooting your switched network,
or even replacing a failed system. These flow charts are
designed to help document your network, teach a new hire, guide an engineer through a troubleshooting
process, or even get you through a security audit. As with your documentation, store these flow charts in a
physically and logically central location for easy access. Have a regular process in place to update these flow

charts as your network grows and use these charts as you experience problems. The more you use these
charts, the more they can be refined into a very useful troubleshooting and training tools
.
Configuration File Storage, Backup, and Retrieval
These are k
ey components to change management and control. If you do not have a sound backup process for
your configurations, then retrieving the needed file, in the event of a failure, could be almost impossible.
Without a reliable storage for your configuration files
,
the change control process just falls apart.
Two key components are needed here: a proven application to identify changes made and offer the ability to
roll-back to a previous configuration as needed;
and a safe
,
secure
,
and archived location for your configura-
tion files. A simple suggestion would be to have an FTP/TFTP/SCP daemon running on an IT department server
and to add that server to your corporate back rotation. A weekly full backup with daily differential backup
should be more than enough for this server and will help save time and space.
Conclusion
T
his concludes our three-part series on Cisco Security for Setup and Configuration. We discussed many security
topics covering the entire spectrum of options for securing your network as a whole. As you can imagine, we
did not review ALL possible security options, features, or applications. There is always room for extra security or
maybe you’re in an environment where a feature just won’t work. Either way, this is why security is a dynamic
process that will change with your organization.
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 9

A
s with any project, you must start with a set of objectives in mind. From those objectives, you create a set of
requirements to guide your progress to completion. In network security, your objectives and requirements are
laid out in your Corporate Security Policy, which defines what you need and how you would like to secure your
network. Create your security policy by using the very regulations and requirements that govern your business
communications (HIPPA, SOx, VISA, FBI, etc.) Be sure to refer to your security policy often to ensure that cur-
rent and future systems are installed correctly.
Once you are ready to install any new system, be sure to manage your installation using the 4-step Security
Lifecycle: Secure, Monitor, Test, and Improve. This is a continuous process that followed through to completion,
loops back on itself in a constant cycle of protection. Focus on hardening a device during the installation and
configuration of each new service.
When securing your network, it is important to implement security at every layer as available by your network-
ing device. Start your security configuration where the network starts – at the physical layer. Leverage each
device’s built-in services. For example, use switch security features to control layer 1 & 2 and routers abilities
at layer 3 and 4. Once basic network security is configured, you can add in advanced services offered by your
firewall in the form of stateful and deep packet inspection, IDS/IPS for deep packet inspection, and protocol
anomaly detection and finally on the end stations you can use HIPS.
Once a network is installed, configured,
and operational,
many organizations begin to think about how to
manage their equipment. This is a common mistake. Secure network management should be a consideration
all along. To create a network conducive to secure management, management should be an objective from the
beginning of your design process
. Whenever you address management of your network, be sure to do so in as
secure a manner as possible. Be sure to use secure protocols over insecure alternatives. Thoroughly document
your network configuration and related systems. Track all changes made to your configuration, as well as each
process and procedure for maintaining your environment. The most important aspect to network documenta-
tion is keeping your documentation up-to-date and in a secure, centrally accessible location.
Remember! Security is a constantly growing and evolving protective shield over your network. As your busi-
ness needs change, your network will change, and so to will your methods of protecting it.

Learn More
Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge.
Check out the following Global Knowledge courses:
SND (Securing Cisco
®
Network Devices)
SNRS (Securing Networks with Cisco
®
Routers and Switches)
SNPA (Securing Networks with PIX and ASA)
CSVPN (Cisco
®
Secure Virtual Private Networks)
SNPA/CSVPN Mini Camp
F
or more information or to register
, visit www.globalknowledge.com or call 1-800-COURSES to speak with a
sales representative.
Our courses and enhanced, hands-on labs offer practical skills and tips that you can immediately put to use.
Our expert instructors draw upon their experiences to help you understand k
ey concepts and how to apply
them to your specific work situation.
Choose from our more than 700 courses
, delivered through Classrooms,
e-Learning, and On-site sessions, to meet your IT and management training needs.
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 10
About the Author
Isaac A. Valdez is President and Owner of IV Consulting Services, Inc., a contract consulting and training firm

based in Tampa, Florida.
In addition to a B.S. in Computer Engineering, Isaac has 15 years of experience in hardware design, network
design, network administration, and certification training. Fresh out of college, he was hired as an in-house
hardware technician where he learned the ins and outs of hardware troubleshooting and repair. After a few
years in hardware, Isaac made his move to Network Administration for the big players at the time: Novell,
Microsoft, and Cisco Systems.
His consulting and training experience ranges from Novell NetWare & GroupWise, Microsoft Windows NT,
Windows 2000 and Windows 2003, Cisco Routing, Switching, LAN/WAN, Wireless and Security, plus a list of
Enterprise applications for Messaging, Front and Back Office, Management and Remote Access.
In the Cisco certification track, Isaac teaches a total of 15 courses toward the CCNA, CCDA, CCNP, CCDP, CCIP
and CCSP certifications
. These courses include INTRO, ICND, ARCH, DESGN, BSCI, BCMSN, BCRAN, CIT, BGP,
QoS, SND, SNRS, SNPA, CSVPN and CSIDS.
Now that all that boring technical stuff is over, Isaac really prides himself on being a very curious individual.
When he’s done with work (and even instead of work at times),
he likes to get away from the k
eyboard and
books to enjoy the finer things in life
. Balance is key!
If you have any questions feel free to contact him at
Additional Resources
Below are some useful links for researching many of the ideas we discussed in this series of white papers, to
download tools for testing your security configuration,
and to learn more about network security from certified
security instructors
. Good luck and have fun!
Web sites for creating a security policy

http://www
.sans

.org/resources/policies/#primer
/>Web site guidelines for network design
/>W
eb site tools for vulner
ability testing:

/> />Book
Penetration Testing and Network Defense
,
Cisco Press
, ISBN 1587052083
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 11