The purpose of this lab is to secure the router control plane before proceeding further with routing system security exercises. All the exercises here apply to all the routers in the group - note that the Customer router has a different set of requirements, and these will be noted with each exercise as applicable.
The following subsections implement basic good practices when setting up any network devices. The following examples are well know essentials for Cisco devices - modify and apply to suit network devices used in your day job.
The router can be set with a time zone offset from UTC/GMT. The timezone command takes a string of characters – obviously set it to the local timezone. Note that only the first seven characters are used in any time display. The following sets the time zone for Australia (Australian Eastern Standard Time as found in Brisbane) with a UTC/GMT offset of +10.
clock timezone AEST 10or
clock timezone GMT+10 10Note that industry standard practice for many network operators running networks across multiple timezones is to set all the routers to UTC/GMT. This makes the cross comparison of logs much easier.
Different IOS devices have different default settings for how the logging and debugging timestamps appear. To be most useful for any network operator, it is generally a good idea to turn all timestamp options on so that the most detail is recorded along with the log messages.
IOS supports the following options:
Router(config)#service timestamps log datetime ?
localtime Use local time zone for timestamps
msec Include milliseconds in timestamp
show-timezone Add time zone information to timestamp
year Include year in timestamp
<cr>We will enable all of these for both debug and log messages, like this:
service timestamps log datetime localtime msec show-timezone year
service timestamps debug datetime localtime msec show-timezone yearCheck the log file from now on in the class - you will see that the log messages will have full information that you set for them just now.
Cisco IOS by default has a simple welcome message when a new administrative connection to the router is opened. Most Network Operators tend to customise this banner to be appropriate to their business. We will now set up a login banner for the routers in the workshop lab. Use an appropriate greeting – one that doesn’t give information away, and makes it very clear that access to the device is restricted to those with permission to do so. If you use an inappropriate greeting, expect the lab instructors to ask you to change it.
This example is a possibility:
banner login ^
Routing Infrastructure and Security Operations Workshop Lab
^The above banner is not very sophisticated, or helpful, or informative. It is better to have one which makes very clear that access is only for authorised personnel, something like this:
banner login ^
This system is the property of the Network Startup Resource Center
Access is for authorised persons only.
Unauthorised access is forbidden and subject to criminal
and civil penalties. By accessing this system you acknowledge
that your actions will be monitored.
For assistance, please contact +1 (234) 567-8901
^
Routers by default capture syslog data produce locally by various features in the IOS. However, the default logging set up is probably not optimal for Network Operators. Each router team should configure logging defaults on their router to be as follows:
no logging console
logging source-interface Loopback 0
logging trap debugging
logging buffered 16384 debugging
logging facility local4This command set will set the log source interface to the Loopback 0 interface, trap level to debug (i.e. most detailed), create a 16K buffer on the router and store the most detailed logs there, and any logs sent to any log host (unconfigured) should be sent using syslog facility local4.
It is highly desirable (if not best practice) to disable logging to the router console. If you still haven’t done this then the command to do so is no logging console. Console logging is on by default in IOS.
We will also configure the SNMP community string on all our routers in our group. Note that many network devices still ship to users with community string public allowing read-only access from the world, and community string private allowing read-write access from the world. Luckily Cisco IOS doesn’t default this way!
The IPv4 address of the SRV appliance in the lab is 100.68.X.30. We will first create an access-list which allows only this appliance to have SNMP access to the routers:
ip access-list standard SNMP
permit 100.68.X.30
deny any logWe will now apply this access-list to the SNMP process, as well as set the community string to be NetManage. We also set the source interface for SNMP traps and informs to be the Loopback interface. Finally, we tell the device to retain the interface index through reboots and the addition or removal of interfaces.
Here is a sample configuration:
snmp-server community NetManage RO SNMP
snmp-server location NSRC Lab
snmp-server source-interface informs Loopback0
snmp-server source-interface traps Loopback0
snmp-server ifindex persistIf your router doesn't take the snmp-server ifindex command, try this SNMP command instead:
snmp ifmib ifindex persist
Now that we have configured and tested basic IPv6 filtering on the router, we are going to configure access to the router to be somewhat more secure. Everything is sent in the clear through telnet, and it’s use is considered historical and deprecated by most network operators today.
First of all, we need to enable SSH on the routers – SSH is not enabled by default on Cisco IOS. To do this, confirm that you set the domain name in the previous exercise to be:
ip domain name ws.nsrc.organd then we need to generate the SSH key pairs for the router:
crypto key generate rsaThe router will respond, asking what key modulus is required. Choose a modulus of at least 768 (the minimum for SSH version 2), preferably 1024. For example:
The name for the keys will be: c1.ws.nsrc.org
Choose the size of the key modulus in the range of 360 to 4096 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes. Let’s use 1024 for this lab - more than this will take a very long time on our virtualised environment:
How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 1 seconds)
C1(config)#Finally set the SSH version to be version 2:
ip ssh version 2SSHv2 is now configured on the router, and ready to use. To verify that SSH is working, try and SSH to the router itself - this is an example for the core router in your group:
CX# ssh 100.68.X.2
Password:
CX>You should get the password prompt, and following entry of the correct password, the standard command prompt. Once you have verified that SSH works, disconnect from the SSH session you just initiated.
IOS by default allows all transports to connect to the VTY ports. We want to change this behaviour to enhance the security of the router access.
line vty 0 4
exec-timeout 15 0
transport input sshThis sequence of commands changes the exec-timeout (how long the vty session can remain idle before disconnection) to 15 minutes (the default is 30 minutes), and disabling all connecting transports apart from SSH.
Test to make sure that SSH from the permitted host can get access to the router.
Try using telnet from the permitted host as well. Do you get access?
Use the debug command to see if you can capture the SSH packets and see the encrypted passwords.
Most Network Operators use the router Loopback address for administrative purposes as well as the anchor point for their network’s iBGP sessions. In this step we will configure SSH so that it uses the loopback interface as the source address for all SSH packets originated by the router.
ip ssh source-interface loopback 0We will now test that this has worked. Use SSH to connect from your router to a neighbouring router in your group and then enter the “who” command. You will see that you are logged in, and the source address will be displayed.
Telnet is a well-known security risk and most network operators disable its use on their network infrastructure equipment. (Equipment which doesn’t support SSH should probably be retired and replaced with equipment which supports secure administrator access.) We will now also disable telnet access from the router, as the following example shows:
line vty 0 4
transport output ssh
line con 0
transport output sshTry using telnet now for a connection to another router – does it work? What happens?
We will now configure a filter to allow only the trusted hosts to have access to our routers. Note that all attempts are logged by the router system log process, so that there is an audit trail of all access to the router. Part of the AAA suite in Cisco IOS allows these authentication logs to be exported to a syslog server where further access tracking can be undertaken.
We will use the loopback addresses in the filter, as we should normally be connecting from router to router sourced from the loopback interface. From the address plan, you can see that the loopbacks for the routers in our AS come from 100.68.X.0/28 (the first /28 of the IPv4 address block) and 2001:DB8:X:0::/64 (the first /64 in the IPv6 address block).
Create the IPv4 access-list first:
ip access-list extended ipv4-vty
permit ip 100.68.X.0 0.0.0.15 any
deny ip any any logAnd then create the IPv6 access-list:
ipv6 access-list ipv6-vty
permit ipv6 2001:DB8:X:0::/64 any
deny ipv6 any any logRemember that in a dual stack network environment, “whatever you do for IPv4, also do for IPv6”.
Once the filter is set up, apply it to the vty ports on the router:
line vty 0 4
access-class ipv4-vty in
ipv6 access-class ipv6-vty inTest to make sure that these filters work. One way you can do it is connect to another router in your group, and then try and SSH back to your router with a source address other than the loopback address. Do you get in? Try again with SSH using the loopback as a source address. Do you get in now?