Introduction
I decided to publish this article even if not treating the newest arguments and/or something strictly connected to programming. However some subjects seems to be evergreen and I still see around a horror configurations made by "experts". I also saw from CP pools that many of you apart for development perform even other task as networking configuration or system configurations.
This article is a translation of my original post written in Italian by the end of 2008 and published on areanetworking.it. As you may know, my working experience and specialized studies have provided me with knowledge and skills in the analysis, implementation, optimization, troubleshooting and documentation of LAN/WAN network systems with strong "hands on" technical knowledge. However in that period I was programming only and it was a long time that I didn't seriously configured a router. One of my old customers commissioned a configuration of three routers, one in the main office and other two in branches. It was for me something new and challenging because I never before configured fully mashed VPN connection so I wanted to get a bit further and configure also other aspects in a more detailed way. I checked my previous configurations an no one of them satisfied me completely. So I pulled down all the documentation I found and started studying. The following lines are the result of that.
Configuring virtual terminal lines
Let´s start, first thing that I did is to separate the virtual terminal lines in two groups, the first one will be reserved for the connections from external networks meanwhile the second will be used for the connections from internal networks. From the external networks will be only possible to connect via SSH where from the internal networks telnet will also be an option.
To achieve this I have given the following commands:
line vty 0 1
line vty 2 4
In this post I will not get in depth about SSH protocol, if you are interested in different version of the protocol, you will find many information's by Googleing the keywords. If you yet do not know anything about it, it is a way to connect to the terminal where all the data exchanged between client and server are encoded. To achieve that let´s give the following commands:
line vty 0 1
transport input ssh
line vty 2 4
transport input telnet ssh
SSH settings
Now we need to make sure that we set up the hostname and the domain name, otherwise, generating the cryptography key will fail. If there is the default hostname set, it would be advisable to change it. Both can be set with the following commands:
hostname MyRouter
ip domain-name majcica.com
Following task is generating the cryptography key base on whom the SSH connection will be secured (will be used to encrypt the data).
crypto key generate rsa
Once you issue this command you will be asked to choose the key size. I will suggest you to leave the default value (512) which is more than enough for 99% of cases. When this operation is over, you will receive the message that SSH is activated and that the current version is 1.5. Unfortunately there is no SSH 1.5 and you may be confused, however this is the way Cisco indicates that SSH version 1 is active. You can always check the current active version by the following command:
show ip ssh
In case it says 1.99 it means that both SSH1 and SSH2 are enabled, meanwhile if the result is 2.0 it means that only the version 2 is enabled.
Setting the access list's and details
In order to prevent the access to a virtual terminal interfaces that accepts the telnet connection let's suppose that our internal network is 10.10.10.0\24 (10.10.10.x network with a mask 255.255.255.0). Because of that we will create an access list that accepts the traffic only from internal network and block the traffic from all other sources. In order to achieve this is sufficient issuing the following command:
access-list 15 permit 10.10.10.0 0.0.0.255 log
and then apply this access list to a proper virtual terminal interface:
line vty 2 4
access-class 15 in
If we try now to access the router via telnet from a network that is different than our internal, the request will time out. But if we try to access it from an external network via SSH the router will replay and we will be able to establish a connection.
Next step is setting the time out (60 seconds is a reasonable value), enabling SSH version 2, setting the interface from which route will replay to SSH request (outside interface, in our case are ATM0.1 - ADSL connection) and a maximum authentication retries.
ip ssh time-out 60
ip ssh authentication-retries 5
ip ssh source-interface ATM0.1
ip ssh version 2
Logging and improvements
Initially I tough that this is sufficient but once I configured logging, I found that, meanwhile testing, there was no trace about the who and when connected to the router. As I believe that this are information's that we should log, I made a little research and found the following commands:
login on-failure log
login on-success log
First one enable logs on failed attempts meanwhile the second one enables the log on successful log in's.
Till here everything was fine until couple of days later I consulted the log files and found that someone was attempting brute force log in attacks on my router. I needed a solution for this problem, and limiting the access via ACL was not an option as I often connect to the router via a dynamically obtained IP address. At the end I found that we can set a dynamic block for the users who fails authenticating a certain amount of time in a determinate time interval. Basically if we want to prevent that user receive a response from SSH service for 300 seconds in case he misses the password three times in 30 sec, we need to issue the following command:
login block-for 300 attempts 3 within 30
This for me was sufficient, and it seems a decent practice, however if you feel paranoid you can still change the default SSH port, apply restrictive ACL, etc.
Following you will find an example extract from syslog showing a brute force attack and the quite mode in action.
2009-01-27 08:28:48 Local7.Warning 10.10.10.254 81: 000086: Jan 27 08:28:47.028 Berlin: %SEC_LOGIN-4-LOGIN_FAILED:
Login failed [user: nagios] [Source: 210.192.123.204] [localport: 22] [Reason: Login Authentication Failed]
at 08:28:47 Berlin Tue Jan 27 2009
2009-01-27 08:28:53 Local7.Warning 10.10.10.254 82: 000087: Jan 27 08:28:52.194 Berlin: %SEC_LOGIN-4-LOGIN_FAILED:
Login failed [user: user] [Source: 210.192.123.204] [localport: 22] [Reason: Login Authentication Failed]
at 08:28:52 Berlin Tue Jan 27 2009
2009-01-27 08:28:57 Local7.Warning 10.10.10.254 83: 000088: Jan 27 08:28:57.169 Berlin: %SEC_LOGIN-4-LOGIN_FAILED:
Login failed [user: test] [Source: 210.192.123.204] [localport: 22] [Reason: Login Authentication Failed]
at 08:28:57 Berlin Tue Jan 27 2009
2009-01-27 08:28:57 Local7.Alert 10.10.10.254 84: 000089: Jan 27 08:28:57.169 Berlin: %SEC_LOGIN-1-QUIET_MODE_ON:
Still timeleft for watching failures is 19 secs, [user: test] [Source: 210.192.123.204] [localport: 22]
[Reason: Login Authentication Failed] [ACL: sl_def_acl] at 08:28:57 Berlin Tue Jan 27 2009
2009-01-27 08:33:58 Local7.Notice 10.10.10.254 85: 000104: Jan 27 08:33:57.083 Berlin: %SEC_LOGIN-5-QUIET_MODE_OFF:
Quiet Mode is OFF, because block period timed out at 08:33:57 Berlin Tue Jan 27 2009
Conclusion
I didn't went in detail on all steps supposing that you have basic knowledge on how to operate on Cisco IOS. All the information's I got from Cisco.com. Also this procedure where valid by the end of 2008 when the original article was written. However it should not be drastically changed in the newest version of IOS. If so, check the documentation on cisco.com and eventually post your question's in the comments.
Joyful configuring!
