Expert Reference Series of White Papers Cisco Security Setup & Configuration: Part – Routers, Firewalls, & VPN Concentrators 1-800-COURSES www.globalknowledge.com Cisco Security Setup & Configuration: Part – Routers, Firewalls, & VPN Concentrators Isaac A Valdez, Global Knowledge Instructor, CCSI, CCSP, CCNP, CCDP 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 throughout 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 services such as access lists, route control, peer router authentication, and rate limiting 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: http://www.cisco.com/cgi-bin/Support/Cmdlookup/home.pl 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 Copyright ©2006 Global Knowledge Training LLC All rights reserved Page There 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 backwards = 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 useful 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 Gateway 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 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 Training LLC All rights reserved Page tion: this feature adds additional overhead to the router and should be monitored once enabled It is suggested 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 command 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 (This 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 Keep in mind that, although rate limiting is considered a Quality of Service (QoS)mechanism, it simply transmits or drops packets based on the amount of bandwidth used Copyright ©2006 Global Knowledge Training LLC All rights reserved Page int 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 mitigate 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 Training LLC All rights reserved Page deny ip 127.0.0.0 0.255.255.255 any log-input deny 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 The 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 Access Class The “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 Training LLC All rights reserved Page access-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 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 (TAC) 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 available at the router level of your network Notice how so many of these options focus on the packet at layer and above, namely: access lists, routing peers, and routing related services As always, test these services in a lab environment to see how they will impact your network 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 Proxy 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 The drawback is in performance where this single proxy device can become a single point of failure and slow-down It is important to understand that the Cisco Firewalls 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 packet 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 Training LLC All rights reserved Page The first suggestion for hardening your firewall installation is similar to those used to harden your router: disable 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 firewall: 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 Finally, 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 Training LLC All rights reserved Page fixup 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) 10.1.0.0 255.255.0.0 500 250 nat (dmz) 172.16.0.0 255.255.0.0 500 50 global (outside) 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 outside 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 values that are available at the end of your “nat” & “static” commands nat (inside) 10.1.0.0 255.255.0.0 500 50 nat (dmz) 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 The first value of 500 defines the embryonic limit, also known as the half-open limit This 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 established 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 Training LLC All rights reserved Page PerimFW01(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 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 The 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 Training LLC All rights reserved Page 10 Use 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 Groups 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 Training LLC All rights reserved Page 11 The 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 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 keyboard and books to enjoy the finer things in life Balance is key! If you have any questions feel free to contact him at ivaldez@ivconsulting.com Copyright ©2006 Global Knowledge Training LLC All rights reserved Page 12 ... log-input deny ip any host 25 5 .25 5 .25 5 .25 5 log-input deny ip host 25 5 .25 5 .25 5 .25 5 any log-input deny ip 22 4.0.0.0 15 .25 5 .25 5 .25 5 any log-input deny ip any 22 4.0.0.0 15 .25 5 .25 5 .25 5 log-input deny tcp... your “nat” & “static” commands nat (inside) 10.1.0.0 25 5 .25 5.0.0 500 50 nat (dmz) 1 72. 16.0.0 25 5 .25 5 .25 2.0 500 50 static (dmz,outside) 20 0 .20 0.1.10 1 72. 16.1.10 netmask 25 5 .25 5 .25 5 .25 5 500 50... 0 .25 5 .25 5 .25 5 any log-input deny ip any 10.0.0.0 0 .25 5 .25 5 .25 5 log-input deny ip 1 72. 16.0.0 0.15 .25 5 .25 5 any log-input deny ip any 1 72. 16.0.0 0.15 .25 5 .25 5 log-input deny ip 1 92. 168.0.0 0.0 .25 5 .25 5