This part of the lab assumes that all of the routers in the topology below have configured routing protocols. All three of the "corp owned" routers branch off the ISP_1 router (I know, no redundancy but I only have so many WIC cards to play with). As seen in the more focused topology below, the corp owned routers and ISP_1 routers use OSPF area 1 for their routing protocol. An area 0 backbone will later be added to expand the topology. The corp_border router also runs EIGRP for the 207.100.100.0/27 network, and this route is redistributed into OSPF area 1. Since this mostly delves back into basic CCNA R/S, I won't be reviewing how the routing was configured, but instead will be focusing on CCNA Security implementation topics. The lab assumes completed routing, where the ASA can ping all of the external router interfaces. Internal subnets will all utilize NAT to simulate a real world environment, as the ISP will be filtering all RFC1928 addresses from entering its interfaces.
Topology:
Security Policy
To give a roadmap or outline to the configurations, here is the basic security policy for the lab:
-Only administrators from the IP address 172.16.100.10 should have management access to corporation owned network equipment
-All network management tools and protocols will use encryption whenever possible
-Centralized authentication, authorization, and accounting must be used
-All edge routers will be hardened from outside attacks
-There will be no plaintext passwords stored on network config files
-All edge routers will shield their internal networks through the use of IOS software firewalls
-All logging will be centralized and encrypted in transit to the logging server
-A full mesh site to site VPN tunnel will be used across the enterprise edge routers
Lab Topics
This part of the lab covers the following:
Implement AAA
Implement security on Cisco routers
Implement zone based firewall policy using CCP
Implement IP ACLs
Implement secure network management
Implement AAA
We'll start by doing a mock configuration of AAA using CCP on the Corp border router. Then we will implement a local user AAA config on all of the routers. Remember from the CCNA that in order to use CCP, you need to have HTTP (preferably HTTPS) running, a local user on the router, and set http to authentication local.
CORP_BORDER(config)#ip http secure-server
CORP_BORDER(config)#ip http authentication local
CORP_BORDER(config)#username admin pri
CORP_BORDER(config)#username admin privilege 15 password cisco
CORP_BORDER(config)#do wr
Now we should be able to login via CCP and mock a setup of AAA using a TACACS+ server. Throughout this lab, I am connected behind the Corp Border ASA.
A few bits of advice here in getting CCP to run correctly-I'm using Windows 7 64bit and IE 10 for my lab computer. You need to install the java plugin for IE. Additionally, you need to enable compatibility view on IE for CCP by adding your localhost address to the compatibility page (tools->compatibility view settings). Last, you must launch CCP as administrator. Otherwise you will be greeted by CCP freezing on "finding ports".
So first, when you get CCP running, you're presented with the select/manage community window. Enter in the IP address for the router, followed by user/password, select the "connect securely" checkbox to connect over HTTPS (and for commands to be relayed via SSH and not telnet..), and click Ok.
After you add the device, you'll need to discover it by clicking the discover box at the bottom of the page.
Mine discovered with warnings-my routers are fairly old (2600XMs) so not everything within CCP is functional, but I have enough functionality for this lab. To create the AAA configuration, select the Configure button and browse down to Router->AAA->AAA Summary. Click on the Enable AAA button.
There will be a brief pause, followed by a second pop up window displaying the commands that will be sent over to the devices running configuration. Click Deliver. Now that there is a backup AAA command set in place, we'll configure the TACACS+ server line, and then create a method list for login and authentication via TACACS. Click on the AAA Servers and Groups drop down folder in the navigation pane, and then select Servers. Select Add. You can then enter in an IP for the TACACS+ server, along with the secure key for authenticating the router against TACACS. If you click Ok, it will show you that it will deliver the commands to the router:
tacacs-server host 172.16.100.105 key 0 ********
no ip tacacs source-interface
no tacacs-server timeout
I clicked cancel here, as I do not have a TACACS+ server, but to complete the mock configuration, you would next need to create the method list for authentication and exec authorization using TACACS+ as a method (and preferably local as a second method incase the TACACS server is unreachable..), and apply that method list to the desired interfaces. You can do so by clicking "add" under AAA->Authentication-> Login and AAA->Authorization->Exec. You simply define the methods you'd like to use, give it a name, and click ok. To apply your custom method lists, you'll have to select Router Access->VTY and select your custom method lists to apply them against the VTY lines.
I'm going to use a basic AAA configuration to use local authentication on all the routers. First I'll create a local user, then I'll use the following 3 commands to apply the default method list against the console, VTY, and aux lines. Don't forget to create a local user-it's never a fun experience to enable AAA, copy run start, exit the router, and have no local user to login with-or if you are using TACACS, not to have local defined as a second method. Don't ask me how I know this.
CORP_BORDER(config)#aaa new-model
CORP_BORDER(config)#aaa authentication login default local
CORP_BORDER(config)#aaa authorization exec default local
Securing the Router with CCP
For certification purposes, I'll first cover securing the router with CCP. You can either use the command line auto-secure command, use CCP's security Audit and then fix items individually, or use one step lock down to secure the router. Using CCP, navigate down to Security->Security Audit
The wizard itself for the audit is fairly self explanatory. At the end, you will be presented with your audit report.
You can either use one-step lock down, or fix the items individually. If you were in a production environment, you'd probably want to just check the items individually to verify CCP doesn't break anything that you do in fact need.
I selected all, except enabling the firewall as this would enable the CBAC firewall on my older routers.
Implement Zone Based Firewall with CCP
Unfortunately, only one of my routers has the capability to run the ZBF. The others only support CBAC. So I'll walk through the configuration of the ZBF but will not be implementing it at this time.
To configure the ZBF in CCP, navigate to Security->Firewall->Firewall.
The wizard is fairly self explanatory-select your trusted inside and untrusted outside interfaces. For my purposes, I set all of but one of the serial interfaces to trusted. Next you are presented with a screen with a slider bar to determine what level of security for the firewall to run.
Before completion, the wizard will display what commands will be relayed to the firewall.
Implement IP ACLs
Our mock ISP has a policy of prohibiting IRC traffic. As a basic mitigation, ACLs will be applied inbound on all serial interfaces to try deny irc traffic following the commonly used TCP port number of 194. Of course using something that inspects at the application layer (like the ZBF) would be more effective here, but this is just a refresh on configuring access lists.
ISP_1(config)#ip access-list extended PACKET-FILTER
ISP_1(config-ext-nacl)#deny tcp any any eq irc log
ISP_1(config-ext-nacl)#permit ip any any
ISP_1(config-ext-nacl)#exit
ISP_1(config)#int s1/0
ISP_1(config-if)#ip access-group PACKET-FILTER in
ISP_1(config-if)#int s1/1
ISP_1(config-if)#ip access-group PACKET-FILTER in
ISP_1(config-if)#int s1/2
ISP_1(config-if)#ip access-group PACKET-FILTER in
ISP_1(config-if)#int s1/3
ISP_1(config-if)#ip access-group PACKET-FILTER in
Now, the ISP has also decided to to block any inbound addresses that match those listed in RFC 1918 across all interfaces. All RFC 1918 blocks as the source or destination will be denied. Since the permit ip any any list is line number 20, we will configure these lines as 11-16. Remember that ACL's use wildcards. This would be simpler with the creation of object groups, but this router IOS does not support object-groups.
ISP_1#show ip access-lists
Extended IP access list PACKET-FILTER
10 deny tcp any any eq irc log
20 permit ip any any
ISP_1#conf t
ISP_1(config)#ip access-list extended PACKET-FILTER
ISP_1(config-ext-nacl)#11 deny ip 10.0.0.0 0.255.255.255 any log
ISP_1(config-ext-nacl)#12 deny ip 172.16.0.0 0.15.255.255 any log
ISP_1(config-ext-nacl)#13 deny ip 192.168.0.0 0.0.255.255 any log
ISP_1(config-ext-nacl)#14 deny ip any 10.0.0.0 0.255.255.255 log
ISP_1(config-ext-nacl)#15 deny ip any 172.16.0.0 0.15.255.255 log
ISP_1(config-ext-nacl)#16 deny ip any 192.168.0.0 0.0.255.255 log
ISP_1(config-ext-nacl)#exit
ISP_1(config)#exit
ISP_1#show ip acces
Extended IP access list PACKET-FILTER
10 deny tcp any any eq irc log
11 deny ip 10.0.0.0 0.255.255.255 any log
12 deny ip 172.16.0.0 0.15.255.255 any log
13 deny ip 192.168.0.0 0.0.255.255 any log
14 deny ip any 10.0.0.0 0.255.255.255 log
15 deny ip any 172.16.0.0 0.15.255.255 log
16 deny ip any 192.168.0.0 0.0.255.255 log
20 permit ip any any
ISP_1#wr
So far, an audit has been run on all of the edge routers, unnecessary services have been disabled, and the routers have been hardened. Hypothetically, a ZBF has been implemented on each border router, and AAA with TACACS has been configured (for this topology, you would either need a VPN setup, or have individual TACACS servers at each site). The ISP router is filtering out any traffic sourced or destined to a private IP address, along with any IRC traffic. So far, we've met a few items for the security policy. I've highlighted the items in red which are still not in compliance:
-Only administrators from the IP address 172.16.100.10 should have management access to corporation owned network equipment
-All network management tools and protocols will use encryption
Only SSH and HTTPS are being used to manage remote devices
-Centralized authentication, authorization, and accounting must be used
AAA with a centralized TACACS server was hypothetically configured
-All edge routers will be hardened from outside attacks
CCP audit was run, which disabled unused services, and enabled numerous security features on untrusted interfaces
-There will be no plaintext passwords stored on network config files
CCP audit enabled service password encryption, along with forcing the creation of an enable secret
-All edge routers will shield their internal networks through the use of router firewalls
ZBF was hypothetically created on all edge routers
-All logging will be centralized and encrypted in transit to the logging server
-A full mesh site to site VPN tunnel will be used across the enterprise edge routers
The last three items will be covered in the next lab, which will configure the full mesh site to site VPN tunnels between the remote sites. The management access will be restricted by an access-class applied to the VTY lines and the http server. Logging will be encrypted within the VPN tunnels across the public WAN links, and SNMPv3 will be used whenever possible. A network monitoring system will be setup to collect these logs.
No comments:
Post a Comment