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

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