## Introduction

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.

## Lab Topology

The diagram below is a reminder of the lab topology:

## User Credentials

As a reminder, the user credentials are as follows:

    username isplab algorithm-type scrypt secret lab-PW
    enable algorithm-type scrypt secret lab-EN

Note that we are using the `scrypt` hashing algorithm, rather than the default type 5 encryption (MD5) which is considered insecure and obsolete now.

## Basic Best Practice

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.

### Setting the time zone on the router

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 10

or

    clock timezone GMT+10 10

Note 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.

### Timestamps

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 year

Check 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.

### Login Banner

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
              Network Startup Resource Center
    ^

The above banner is not very sophisticated, or helpful, or informative. In the real world 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
    ^

### Logging

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 local4

This 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.

### Simple Network Management Protocol (SNMP)

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`. The lab’s central network monitoring system is on `100.64.0.248`. We will first create an access-list which allows only these two appliances to have SNMP access to the routers:

    ip access-list standard SNMPv4
     permit 100.68.X.30
     permit 100.64.0.248
     deny   any log
    !

As our network is dual stack, and modern Cisco IOSes now listen to SNMP connections over IPv6 as well, we need to create an IPv6 access-list too:

    ipv6 access-list SNMPv6
     permit ipv6 host 2001:DB8:X:21::30 any
     permit ipv6 host 2001:DB8::248 any
     deny ipv6 any any log
    !

We now need to enable SNMP on the router - we will be using SNMPv3, which is the latest and most secure version of SNMP.

SNMP has 3 security levels to choose from as shown in the table below:

SNMP Security Level | Cisco’s name | Authentication | Encryption
--- | --- | --- | ---
noAuthNoPriv | noauth | no | no
authNoPriv | auth | yes | no
authPriv | priv | yes | yes

Note that Cisco has given them non-standard names. For our lab we’ve chosen the “authNoPriv” (which is secure against active attacks, but allows us to see the SNMP data in tcpdump).

First we create the SNMP group, including the access-lists we created earlier:

    snmp-server group ReadGroup v3 auth access ipv6 SNMPv6 SNMPv4

Note how the IOS CLI requires the IPv6 access-list protecting the SNMP port to be added. Format is:

    snmp-server group <group> v3 auth access [ipv6 <ipv6 acl>] <ipv4 acl>

which is perhaps not the most intuitive. Care is needed.

Then we define the user “admin” which is a member of this group (the user is what the monitoring system will log in as) including the password “NetManage”:

    snmp-server user admin ReadGroup v3 auth sha NetManage

(Note that the definition of the user `admin` will not appear in the displayed configuration.)

And finally we set the location and make the internal interface index number persist through reboots and the addition or removal of interfaces:

    snmp-server location Routing Security Workshop
    snmp-server ifindex persist

## Remote Access

### Configuring the VTYs for SSH access

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.org

and then we need to generate the SSH key pairs for the router:

    crypto key generate ec keysize 384

This generates an Elliptic Curve key - key sizes available are 256 and 384 bits. (EC keys are much shorter than RSA keys for equivalent strength)

Finally set the SSH version to be version 2:

    ip ssh version 2

SSHv2 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.

### Modifying VTY access for SSH

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 ssh
    !

This 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.

### SSH source address

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 0

We 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.

### Disabling Telnet Access

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 ssh
    !

Try using telnet now for a connection to another router – does it work? What happens?

## Administrative Access

### Configuring VTY access

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 (and let’s allow the classroom backbone IPv4 network in as well, as once we have our lab connected to the classroom backbone, we can then use SSH to access our routers rather than coming through the console port):

    ip access-list extended ipv4-vty
     remark Router Loopbacks
     permit ip 100.68.X.0 0.0.0.15 any
     remark Classroom Backbone
     permit ip 100.64.0.0 0.0.3.255 any
     deny   ip any any log
    !

And then create the IPv6 access-list (again include the classroom backbone IPv6 network):

    ipv6 access-list ipv6-vty
     remark Router Loopbacks
     permit ipv6 2001:DB8:X:0::/64 any
     remark Classroom Backbone
     permit ipv6 2001:DB8:0:0::/64 any
     deny   ipv6 any any log
    !

Remember that in a dual stack network environment, “whatever you do for IPv4, also do for IPv6”.

### Applying the filter to the VTY ports

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 in
    !

Test 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?