Tải bản đầy đủ (.pdf) (12 trang)

Tài liệu Cisco Security Setup & Configuration: Part 2 – Routers, Firewalls, &VPN Concentrators pptx

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (152.53 KB, 12 trang )

Cisco Security Setup
& Configuration:
Part 2 – Routers,
Firewalls, & VPN
Concentrators
1-800-COURSES
www.globalknowledge.com
Expert Reference Series of White Papers
Introduction
This paper is the second in a three-part series of white papers, each of which focuses on a functional area of
securing your network. As introduced in the first installment, network security should be implemented through-
out your entire network. Take a layered approach and introduce security at every layer possible. This second
paper will suggest steps to secure your Router, Firewall, and Virtual Private Network (VPN) Concentrators.
Router
A router offers rich layer 3 services such as access lists, route control, peer router authentication, and rate lim-
iting features. Let’s start with the basics before reviewing some of the more advanced features.
The following command is used to disable all un-used interfaces:
int f0/0
shut
Next, disable all unused services on both an interface and global level. It is important for you to decide which
services are, or are not, needed by your environment. Also, keep in mind that many of these services may
already be disabled by default. You can use the Cisco Internetwork Operating System (IOS) Command Lookup
tool to find out which service is already enabled or disabled in your specific IOS revision:
/>int f0/1
ip address 200.200.7.1 255.255.255.0
no ip redirect
no ip unreachable
no ip directed-broadcast
no ip proxy-arp
no ip mask-reply
no cdp enable


no mop
ip verify unicast reverse-path
ntp disable
no shut
Isaac A. Valdez, Global Knowledge Instructor, CCSI, CCSP, CCNP, CCDP
Cisco Security Setup & Configuration:
Part 2 – Routers, Firewalls, & VPN Concentrators
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 2
T
here are many services throughout the Cisco IOS that can use a loopback interface. These services include
routing, ntp, syslog, and telnet, just to name a few. Therefore, it is a good idea to create a loopback interface
for such services as needed:
int loopback0
ip address 100.100.100.5 255.255.255.255
IP Verify
IP Verify is a wonderfully simple security feature that does not get used as much as it should. For every packet
that enters an interface where this feature has been enabled, the router will check the source address of the
packet against the routing table. If the source address, per the routing table, is accessible (by checking back-
wards = reverse path) via the ingress interface, then the packet is permitted into that interface. If not, the
source address is thought to be a spoofed address, and the packet is dropped.
There is one note of caution: this process can take up considerable router resources by cross-referencing each
packet against the routing table (if there is not another feature available to ease such overhead). That is where
Cisco Express Forwarding (CEF) comes into play. Note how CEF is enabled globally before you enable reverse
path verification on the ingress interface.
ip cef
ip verify unicast reverse-path {std or etc acl#}
Note: A standard or extended Access Control List (ACL) can be added to this command. This addition would be use-
ful in asymmetric routing environments where the ACL defines which packets to (permit) and not to (deny) verify.

Many environments enable security at many layers throughout their network but forget to authenticate the
sources of their route information. This is where peer routing authentication comes in handy
.
Our example illustrates how to authenticate Routing Information Protocol (RIP) routing peers. Authentication
of routing peers is supported on all routing protocols except for RIPv1 and Interior Gatew
ay Routing Protocol
(IGRP); however, the commands may not always be the same. First, we create a set of authentication keys
global to the router
.
Next, we set the authentication mode and point to the authentication key on the interface
pointing to the desired peer.
key chain rip-auth
key 1
key-string rip-key1
int f0/1
ip rip authentication mode md5
ip rip authentication key-chain rip-auth
TCP Intercept
TCP Intercept is a security feature that allows the router to monitor tcp sessions through its interfaces. This
allows the router to detect and terminate tcp sessions that are no longer valid. Invalid or stale TCP sessions
can be used to launch a Denial of Service (DoS) attack on our end stations behind the router
.
A note of cau
-
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 3
t
ion: this feature adds additional overhead to the router and should be monitored once enabled. It is suggest-
ed that the administrator check the processor utilization (“show proc cpu” command) before and after

enabling this feature.
ip tcp intercept mode intercept
ip tcp intercept list 101
access-list 101 permit tcp any 10.1.0.0 0.0.255.255
ip tcp intercept connection-timeout 43200
ip tcp intercept drop-mode oldest *
ip tcp intercept max-incomplete high 500
ip tcp intercept max-incomplete low 400
ip tcp intercept one-minute high 500
ip tcp intercept one-minute low 400
ip tcp intercept first-timeout 10
Notice how you are able to define an ACL that indicates the addresses monitored by the tcp intercept com-
mand. You can also define maximum and minimum values that govern the drop criteria of the router.
Committed Access Rate (CAR)
CAR allows administrators to permit certain types of traffic without allowing that traffic to consume their
entire connection. An ideal use of this command is in enabling certain traffic types, typically Internet Control
and Messaging Protocol (ICMP) messages used for testing and VPN connectivity, but not allowing attackers to
use these ICMP messages to launch a DoS.
Start by creating an ACL to permit the types of ICMP traffic we need in our network.
! Creates rate limiting commands for control of ICMP traffic.
no access-list 199
access-list 199 remark (T
his
ACL will set aside 50kbps of traffic for ICMP - a necessary evil.)
access-list 199 permit icmp any any echo-reply
access-list 199 permit icmp any any echo
access-list 199 permit icmp any any parameter-problem
access-list 199 permit icmp any any packet-too-big
access-list 199 permit icmp any any unreachable
access-list 199 permit icmp any any time-exceeded

access-list 199 deny icmp any any log-input
Next, use the “rate-limit” command on the ingress interface to define the amount of bandwidth dedicated to
the above traffic. As you can see with the “exceed-action” parameter, all traffic permitted by ACL 199 that
reaches or exceeds 60kbps will be dropped.
K
eep in mind that,
although rate limiting is considered a Quality of Service (QoS)mechanism,
it simply trans
-
mits or drops pack
ets based on the amount of bandwidth used.
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 4
i
nt f0/0
! Commands 1st) Apply ACL to inbound traffic 2nd) Apply C.A.R. to prevent DoS via ICMP
ip access-group OutToIn in
rate-limit input access-group 199 50000 5000 10000 conform-action transmit exceed
action drop
Infrastructure ACLs
Infrastructure ACLs are an excellent way to protect your network against current and future attacks. This type
of ACL is simply an extended ACL that, at the least, denies specific source and destination addresses that are
known to be used in attack situations. The type of ACL entries (ACEs) found in your infrastructure ACLs were
originally documented in RFC 2827 and are now updated in RFC 3704.
For example, denying any source or destination addresses that are defined by RFC 1918 (Private IP Space) on
your perimeter router would be a simple but effective way to mitigate attacks from spoofed addresses. This
approach underscores the fact that such addresses should never be seen on the public connected internet and,
therefore, never seen by your perimeter devices. By eliminating all packets with such addresses, you can miti-
gate all attacks using spoofed addresses.

Addresses mentioned in RFC 3704 (prev
. 2827) that should be listed in your infrastructure ACL are:
all private
addresses defined by RFC 1918, packets where multicast addresses are found as the source address, subnet 0,
loopback (127), and the broadcast address of 255.255.255.255 as a source or destination address, and your
internal network when listed as the sources, just to name a few
. As an additional step toward security, you
may also want to list the protocols and ports used by the top known vulnerabilities as posted by the Computer
Emergency Response Team (CERT) or SysAdmin, Audit, Network, Security (SANS) websites.
Here’s an example:
no ip access-list extended OutToIn
ip access-list extended OutToIn
remark
The following lines deny RFC 1918 as Source Addr.
deny ip 10.0.0.0 0.255.255.255 any log-input
deny ip any 10.0.0.0 0.255.255.255 log-input
deny ip 172.16.0.0 0.15.255.255 any log-input
deny ip any 172.16.0.0 0.15.255.255 log-input
deny ip 192.168.0.0 0.0.255.255 any log-input
deny ip any 192.168.0.0 0.0.255.255 log-input
remark The following lines deny RFC 2827 into our network
deny ip any 0.0.0.0 0.255.255.255 log-input
deny ip 0.0.0.0 0.255.255.255 any log-input
deny ip any host 255.255.255.255 log-input
deny ip host 255.255.255.255 any log-input
deny ip 224.0.0.0 15.255.255.255 any log-input
deny ip any 224.0.0.0 15.255.255.255 log-input
deny tcp any any range 161 162 log-input
deny udp any any range 161 162 log-input
deny ip 169.254.0.0 0.0.255.255 any log-input

Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 5
deny ip 127.0.0.0 0.255.255.255 any log-input
d
eny ip any 127.0.0.0 0.255.255.255 log-input
remark The following line denies the "Test Network Block"
deny ip 192.0.2.0 0.0.0.255 any log-input
remark Expressly deny protocol/port used by (Trin00, TrinV3, Stacheldracht, Subseven)
deny tcp any any eq 1524 log-input
deny tcp any any eq 27665 log-input
deny udp any any eq 31335 log-input
deny udp any any eq 27444 log-input
deny tcp any any eq 16660 log-input
deny tcp any any eq 65000 log-input
deny tcp any any eq 33270 log-input
deny tcp any any eq 39168 log-input
deny tcp any any range 6711 6712 log-input
deny tcp any any eq 6776 log-input
deny tcp any any eq 6669 log-input
deny tcp any any eq 2222 log-input
deny tcp any any eq 7000 log-input
remark The following lines permit IPSec Phase I & II to Perimeter Router
permit udp host 100.100.50.2 host 100.100.7.2 eq isakmp
permit esp host 100.100.50.2 host 100.100.7.2
remark The following lines permit Internal Access back in
permit ip any 200.200.7.0 0.0.0.255
remark
The following lines permit RIPv2 & NTP updates to out Perimeter Router
permit udp host 100.100.7.1 host 224.0.0.9 eq 520

permit udp host 100.100.7.2 host 224.0.0.9
permit udp host 192.43.244.18 eq 123 any eq 123
remark The following lines permit only needed ICMP options and
remark denies & logs ICMP flood attempts.
permit icmp any any echo-reply
permit icmp any any echo
permit icmp any any parameter
-problem
permit icmp any any packet-too-big
permit icmp any any unreachable
permit icmp any any time-exceeded
deny icmp any any log-input fragments
remark
T
he following lines should
ALWAYS appear at the BOTTOM for complete logging
deny tcp any any log-input
deny udp any any log-input
deny ip any any log
Note how the “remark” option is used throughout the ACL to indicate a new section of ACEs and remind the
administrator of what the next few lines do
.
Access Class
T
he
“access-class” command allows you to define permitted source addresses used when managing the
router. This command references an ACL to define permitted source addresses and is then applied to your vty
lines (management via telnet and secure shell [ssh]) or the web interface. Take a look at the following example:
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.

Page 6
a
ccess-list 10 remark Lines to permit our Loopback and Management subnets.
access-list 10 permit 10.1.100.0 0.0.0.255
access-list 10 permit 10.1.101.0 0.0.0.255
access-list 10 permit 10.1.50.0 0.0.0.255
access-list 10 deny any log-input
! Now apply the above access-list to the lines used by telnet or ssh.
line vty 0 4
access-class 10 in
! Also apply the access-list if using Router Web Access.
ip http access-class 10 in
Now, the only management sessions (telnet, ssh, http) allowed to this device will be from the addresses
defined by ACL #10.
Many of the above-listed security settings (and then some) can be automatically configured and enabled using
the “auto secure” command on your router. This command creates a hardened configuration for the router,
based on Cisco
Technical
Assistance Center (T
AC) and Network Security Agency (NSA) recommendations. The
settings created are then presented to the administrator for approval before being added to the router.
Once again, there are several security options av
ailable at the router level of your network.
Notice how so
many of these options focus on the packet at layer 3 and above, namely: access lists, routing peers, and rout-
ing related services. As always, test these services in a lab environment to see how they will impact your net-
work and can be put to best use
.
Firewall
The term firewall, I feel, has been marketed into oblivion. The definitions can be distilled down to the most

common types.
Packet Filtering: This approach is an access list device that processes all packets against the interface access
list for a simple “permit” or “deny” response. Here, you only have the static and largely stateless filtering of
packets.
Pr
oxy Filtering
:
Here, the proxy device receives the request for external services by the end user and
retrieves (requests) these services from the true destination “on behalf” of the original user. Now, all security
services
,
such as filtering and caching,
can be performed on the proxy server
.
T
he drawback is in performance
where this single proxy device can become a single point of failure and slow-down. It is important to under-
stand that the Cisco Firewalls do not perform traditional proxy services; instead, they perform Proxy
Authentication by challenging the user for credentials before any new connection is permitted.
Stateful Inspection: This is a process of checking each packet against a session table. If this packet constitutes
a new session,
a series of security checks are performed to ensure the new pack
et is permitted.
Once permitted,
detailed state information for this new session is tracked for the life of the communication; any variations in this
session are identified by the firewall, and the session is terminated. Although many enterprise firewall vendors
offer all of the above-listed services
, stateful inspection is considered the true definition of a firewall.
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.

Page 7
T
he first suggestion for hardening your firewall installation is similar to those used to harden your router: dis-
able all unused services. In the case of the firewall, disable all unused protocol inspections. This process is easy
enough—simply discover which applications are and are not used by your specific environment and configure
your firewall accordingly. This means leaving all protocol inspections enabled that match the applications used
and disabling all others that are not used.
In this example, we found that the client does not use Voice over Internet Protocol (VoIP). They perform mail
security only on the mail servers and only allow secure device management via secure shell (ssh).
First, view all protocols inspected by the firewall to get an idea of which to disable:
show fixup
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
Next, disable all protocol entries effectively patching holes on our firew
all:
no fixup protocol h323 h225
no fixup protocol h323 ras
no fixup protocol rsh
no fixup protocol sip

no fixup protocol skinny
no fixup protocol smtp
F
inally, verify our configuration to ensure all changes took place as desired:
sh fixup
no fixup protocol rsh 514
no fixup protocol sip 5060
no fixup protocol skinny 2000
no fixup protocol smtp 25
no fixup protocol h323 h225 1720
no fixup protocol h323 ras 1718-1719
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol http 80
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 8
f
ixup protocol rtsp 554
fixup protocol sip udp 5060
fixup protocol sqlnet 1521
fixup protocol tftp 69
Keep in mind that the protocol inspections enabled or disabled will vary by the specific environment.
Network Address (NAT) and Port Address Translation (PAT) Hardening
NAT and PAT hardening is a simple process of defining the exact addresses permitted for translation. Many
environments configure NAT and PAT (on both routers and firewalls) to translate ALL ADDRESSES that enter an
internal interface. This opens up the NAT/PAT device for NAT exhaustion attacks made possible by spoofing
internal/client packets with unique IP addresses.
Here, we define the exact internal subnets as being the only valid source addresses for translation:
nat (inside) 1 10.1.0.0 255.255.0.0 500 250

nat (dmz) 1 172.16.0.0 255.255.0.0 500 50
global (outside) 1 interface
Note: This example defines the 10.1 subnet on the inside and the 172.16 network on the dmz (demilitarized
zone) as the only valid addresses for translation and only when they attempt to communicate through the out-
side interface. Now a client’
s packet, once it is received on the inside interface, must originate from the
10.1.0.0 subnet, or it will not be considered for translation.
Defining Connection Limits
Defining connection limits is a nice way to mitigate attacks at the network level before they reach your end
stations
. In this example, we will use v
alues that are available at the end of your “nat”
& “static” commands.
nat (inside) 1 10.1.0.0 255.255.0.0 500 50
nat (dmz) 1 172.16.0.0 255.255.252.0 500 50
static (dmz,outside) 200.200.1.10 172.16.1.10 netmask 255.255.255.255 500 50
static (dmz,outside) 200.200.1.11 172.16.1.11 netmask 255.255.255.255 500 50
T
he first v
alue of 500 defines the embryonic limit,
also known as the half-open limit.
T
his sets a maximum
number of half-open TCP sessions to a specific host, thereby protecting that host from TCP-based DoS attacks.
The value of 50 references a maximum connection limit. Here, we have the firewall prevent any newly estab-
lished connections to this specific host, if they exceed the defined limit of 50.
The “static” command option protects your internal server from becoming a destination of an inbound attack
while the “nat” command option prevents your internal users from launching an attack outbound.
Secure Management
Secure management is just as important as secure configurations. Once the device is installed and operational,

having secure means by which the device is managed should be a top priority
. In this example we will only
enable remote management via ssh and disable all other management options:
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 9
P
erimFW01(config)# sh telnet
InteractHQ 255.255.255.0 outside
10.3.3.0 255.255.255.0 inside
PerimFW01(config)# clear telnet
First, view and disable (if needed) all telnet configuration options:
PerimFW01(config)# ssh 10.1.100.0 255.255.255.0 inside
PerimFW01(config)# ssh timeout 3
Next, use the “ssh” command to define the exact addresses (hosts or subnets) allowed to manage our firewall:
PerimFW01(config)# sh http
http server enabled
InteractHQ 255.255.255.0 outside
OtherRemote 255.255.255.0 inside
10.3.3.0 255.255.255.0 inside
PerimFW01(config)# clear http
Finally, view and disable (if desired/needed) all web management options into the firewall. Keep in mind that
the last command will prevent an administrator from using key features such as PIX Device Manager
(PDM)/Adaptive Security Device Manager (ASDM) and http/https Authentication Proxy
.
Notice how many of the hardening techniques used by the router are also available on the firewall.
Additionally
, we can leverage the stateful inspection features of the firewall by controlling which applications
will be monitored and controlling the number of sessions permitted through the firewall interfaces. Finally, we
addressed secure management of your newly installed firewall.

Be sure to define the exact addresses allowed
for the specific management application.
VPN Concentrators
VPN concentrators are a growing component of a corporation’s Remote Access topology. As organizations
move to secure remote access connectivity, VPN Concentrators become a key network component and, as a
result, securing them becomes a high priority.
T
he following suggestions are an excerpt from a more complete white paper written by David W. Chapman. It
is titled
Hardening Guidelines for Cisco 3000 Series VPN Concentrators
and can be found in the Global
Knowledge web site at:
www.globalknowledge.com/training/whitepaperlist.asp.
Secure Communications/Management
Use secure communications/management with your VPN Concentrator(s). The following examples hold true for
managing all network devices and for all
VPN configurations
, regardless of the device used to terminate the
remote access tunnel.
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 10
U
se http vs. https
Remotely manage your concentrator via https instead of http.
Configured at: Configuration/System/Management Protocols
Configure user access rights
Change default usernames and define administrative user abilities to the local concentrator.
Configured at: Administration/Access Rights/Administrators
Apply access lists where possible

Restrict traffic types allowed through the concentrator interface(s) and over a VPN tunnel.
Configured at: Configuration/Policy Management/Traffic Management/Filters
Configure Management filters
Define permissible addresses for remote management sessions.
Configured at: Administration/Access Rights/Access Control List
Secure your tunnel configurations
Deactivate un-used Phase I Internet Key Exchange (IKE) and Phase II (IPSec) policies.
Configured at:
Configuration/Tunneling & Security/IPSec/IKE Proposals and
Configuration/Policy Management/Traffic Management/Security Association
Secure Remote
Access Gr
oups
Set user and group specific permissions for your remote access VPN sessions.
Configured at: Configuration/User Management/Groups and/or Base Group
Out-of-Band Management
Out-of-band management is another, more secure
, alternative for managing your VPN Concentrator. All models
from the 3015 through the 3080 support a 3rd interface (public, private, and external). This 3rd interface can
be used for a secure DMZ, a segregated wireless network for LAN side tunnels or for out-of-band network
management.
Although your
VPN Concentrator may serve a specialized purpose in your network,
it is still a critical point for
network security.
Summary
Once your security policy is created, you can move forward with securing your network devices. We have
reviewed the process for hardening your Router, Firewall, and VPN Concentrator in ways that parallel the
requirements of your security policy
. The process for configuring each device centers on each device’s strong

points. We used ACLs, routing, and packet rate limiting as a few examples of available router options. Next, we
leveraged the packet inspection process of your firewall to control applications supported and limit established
sessions through the firewall. Finally, we hardened the VPN Concentrator by configuring secure management
access, controlling traffic flow through the concentrator’s interfaces, and disabling all unused IPSec (Phase I &
Phase II) policies
.
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 11
T
he third and final paper of this series reviews the suggested steps for hardening your IDS/IPS Sensors, reviews
a set of devices from Cisco Systems, which integrate rich security features into a single chassis, and finishes
the overall discussion by reviewing suggestions for secure network management.
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
For 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 key 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.
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 hardw
are 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 hardw
are, 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 tow
ard the CCNA,
CCD
A,

CCNP, CCDP, CCIP
and CCSP certifications
.
T
hese 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 keyboard and
books to enjoy the finer things in life
.
Balance is k
ey!
If you have any questions feel free to contact him at
Copyright ©2006 Global Knowledge T
raining LLC. All rights reserved.
Page 12

×