Wow, it’s been a lengthy discussion on CCNA security topics and I hope it’s been fun also. In previous posts, we have discussed password management, remote connections with Telnet and SSH, and switch security. (Part 1, Part 2, and Part 3.) Now, let’s wrap things up.
In this final article, we will be putting some finishing touches on security topics like turning off unnecessary services, restricting remote access using ACLs and then some general troubleshooting.
CCNA Training – Resources (Intense)
Our network diagram remains the same as before (see below):
TUNING NETWORK SERVICES
There are some services that run by default on Cisco network devices. Some of these services may be exploited by attackers and it is recommended that they are turned off if not required. We will discuss a few of them here.
For a more detailed list, you can refer to: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper09186a00801dbf61.html. Some of them can be disabled or enabled globally, while others are on a per-interface basis.
TCP and UDP Small Servers
Cisco network devices support some TCP and UDP services that are quite useful for running diagnostics. However, these services can be used to perform Denial of Service (DoS) attacks. If they are not being used on a network, they should be turned off.
The finger service can provide information about the users who are currently logged into a network device. This information can be used maliciously by an attacker.
Packet Assembler and Disassembler (PAD) is used to enable X.25 connections between network devices. When not required, this service should be turned off.
By default, Cisco routers do not continually check if TCP sessions are active. Idle TCP sessions can be dangerous because they can be hijacked by attackers. Also, too many idle sessions can use up required resources on the network device. Therefore TCP keepalives should be turned on to continually test that remote sessions are not idle.
In a Bootp environment, a Cisco network device can act as a server for other network devices (clients) to download IOS images. This service should be turned off if not required.
Using source routing, information contained in an IP packet can specify the route through which the packet should take to its final destination. This can be potentially dangerous because an attacker can control a malicious packet to pass through a route with reduced security settings or devices like firewalls.
Although many Cisco network devices can be configured using the CLI, recent provision from Cisco allows a web-based GUI for configuration. This is where the HTTP server is useful. However, HTTP on its own sends messages in clear text and as such, if this service is not required, it should be turned off.
If the HTTP service is required, it should be restricted to only certain IP addresses (using an access-list with the ip http access-class command) and also configured with authentication methods (using the ip http authentication command).
Cisco Discovery Protocol (CDP) is useful for network management because it helps to discover neighbours of already known network devices. If CDP is not required, then it should be disabled globally (no cdp run) and on each interface (no cdp enable).
As you may be familiar with, ICMP can be a very useful troubleshooting tool. An ICMP Redirect message may be used by a router to tell a host to use a more optimum route to a particular destination. The ICMP Unreachable messages may be used to notify senders of an unavailable or incorrect IP address. The ICMP Mask Reply message provides the network mask of a particular network to the device that requested this. While all these messages are useful for diagnostics, they can also be used in unauthorised ways by attackers and should be turned off.
Directed broadcast allows broadcast messages to be sent to a different network other than the one on which the sender is attached to. This can be used for DoS attacks (like the smurf attack that uses ICMP). Directed broadcast can also be disabled per-interface.
Proxy ARP allows a network device to reply to an ARP request on behalf of another device. This can be useful for features like NAT but should be disabled if not required.
While you may be required to remember how to turn on/off most of these services for your exam, in the real world, there is an easier way of doing things. This is by using the AutoSecure feature available on network devices. It does all the above and more. AutoSecure is like the one-step security lockdown of a network device. Let’s see how it works by configuring it on Router_US from our network diagram.
After answering a series of questions and inputting certain values, it shows the configuration it wants to apply and asks for confirmation.
As you have seen, AutoSecure can help create best security practices which can then be tweaked as required for your network.
RESTRICTING REMOTE ACCESS CONNECTIONS
In the second article in this series, we saw how Telnet and SSH could be used for remote connections to network devices. But even with usernames and passwords, you don’t want just everybody connecting remotely to your network devices. There is usually a subset of IP addresses that should be allowed to connect remotely. This is what we deal with in this section.
Hopefully, you are already familiar with Access Control Lists (some articles have been written on the subject here). Using ACLs, we can limit the access to our network devices’ VTY lines and it’s very easy to configure. The steps to achieve this can be described as follows:
- Configure the ACL. Specify the allowed IP addresses.
- Apply the ACL to the line(s).
- Test your configuration.
It is important to note that ACLs on lines are restricted to standard ACLs (named or numbered) which is all you need if you think about it since what you are concerned about is where the connection is coming from (source IP address). However, it means that these ACLs cannot be applied per remote-access-method, i.e. you cannot allow some IP addresses to connect using Telnet while you allow some to connect with SSH. The ACL is applied to the VTY line as a whole.
Let’s configure this on Router_UK. Before we begin, let’s ensure that there are currently no restrictions. From Router_US, I can telnet into Router_UK using the configured username and password, as shown below:
Also, from PC_UK, I can open a Telnet connection to Router_UK as shown below:
So let’s configure Router_UK to only allow remote connections from IP addresses on its LAN, i.e. 192.168.100.0/24.
Now, we will try to initiate those connections again. Router_US first:
Notice how the connection is now refused. Let’s try to telnet PC_UK which is on the Router_UK LAN:
As you can see, that connection is allowed. If we check the access-list statistics, we can see what traffic has been allowed.
You may be interested in logging denied remote connection attempts. To do this, you can add an explicit deny any any log statement at the end of the ACL. As you should be aware, there’s an implicit deny any any after every ACL but specifying it explicitly helps with logging if required.
We are gradually coming to the end of this series. Let’s look at some troubleshooting scenarios.
As the Network Administrator of Company XYZ, you want to set up remote connection for your switch with IP address 192.168.200.253. Just before you go home for the weekend, you decide to check that you can log in remotely; however you got this message:
What do you do to resolve this issue?
By default, Cisco network devices have a “login” command under the VTY lines configuration. This command requires that a password be set before the device will accept remote connections. This issue can thus be resolved in two ways:
Set a password on the line (or use username and password as we have learnt).
Disable the requirement for password by using the “no login” command. This of course is less secure as shown below:
You are the Lead Network Administrator of company XYZ and you have other network administrators under you. You have configured different usernames and passwords for the different admins along with the appropriate privilege levels. You got an e-mail from one of the administrators, Bob, telling you that he cannot log in with the password you configured for him. You are required to resolve this issue. This was the command you issued to create Bob’s profile:
What is the problem here?
When configuring username, password and privilege, the privilege option must be specified before the password option else the password becomes everything after password (or secret). In the scenario above, the password for bob is actually “bob123 privilege 3“. The right way to do this is shown below:
You have enabled port security on all access ports on your Cisco LAN switch. You only enabled port security with its default settings. Users connect to the network with desktop computers. Whenever users resume in the morning, they complain that there’s some delay they experience in accessing the network. You have determined that this delay is due to the fact that the MAC addresses on the interfaces have to be relearned every morning when the switch is restarted. How do you resolve this?
The default setting of port security does not enable dynamic MAC addresses to be saved in configuration. This means that every time the switch is restarted, these MAC addresses have to be relearned. To solve this issue, you can:
- Configure static secure MAC addresses on each port: Since desktops are being used to connect to the network, you can configure static secure MAC addresses on each switch interface. This may not scale properly for a large network.
- Enable sticky address learning: With sticky address learning, MAC addresses can be learnt dynamically and then added to the running configuration which can then be saved to the start-up configuration.
That brings us to the end of this series. In this series, we have discussed Password Management techniques, remote connections using Telnet and SSH, switch security including Port security and VLAN security, tuning network services by turning off unnecessary services, using ACLs to restrict remote connections and finally, we looked at some troubleshooting scenarios.
The world of security can be very fun and I hope you have enjoyed this series. I wish you success in your exams.
- Cisco AutoSecure White Paper: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper09186a00801dbf61.html
- Cisco IOS Switch Security Configuration Guide:http://www.nsa.gov/ia/_files/switches/switch-guide-version1_01.pdf