While most of the attention is paid to exterior threats, there are some steps you can take to prevent unwanted Cisco router access from within your organization.

Whether you want to limit what certain users can do and run on your routers, or prevent unauthorized users in your company from getting to config mode in the first place, here are four important yet simple steps you can take to do so.

Encrypt the passwords in your running configuration.

This is a basic Cisco router security command that is often overlooked. It doesn’t do you any good to set passwords for your ISDN connection or Telnet connections if anyone who can see your router’s running configuration can see the passwords. By default, these passwords are displayed in your running config in clear text.

One simple command takes care of that. In global configuration mode, run service password-encryption. This command will encrypt all clear text passwords in your running configuration.

Set a console password.

If I walked into your network room right now, could I sit down and start configuring your Cisco routers?

If so, you need to set a console password. This password is a basic yet important step in limiting router access in your network. Go into line configuration mode with the command “line con 0″, and set a password with the password command.

Limit user capabilities with privilege level commands.

Not everyone who has access to your routers should be able to do anything they want. With careful use of privilege levels, you can limit the commands given users can run on your routers.

Privilege levels can be a little clumsy at first, but with practice you’ll be tying your routers down as tight as you like. Visit www.cisco.com/univercd for documentation on configuring privilege levels.

Configure an “enable secret” password.

It’s not uncommon for me to see a router that has an enable mode password set, but it’s in clear text.

By using “enable secret”, the enable mode password will automatically be encrypted. Remember, if you have an enable password and enable secret password set on the same router, the enable secret password takes precedence.

These four basic steps will help prevent unwanted router access from inside your network. If only preventing problems from outside your network was as simple!

root@localhost# openssl genrsa -out www.mydomain.com.key 1024
Generating RSA private key, 1024 bit long modulus
………….++++++
………………..++++++
e is 65537 (0×10001)

Then, we need to generate the certificate request and fill in the appropriate information.  Make sure that the “Common Name” matches the domain you want to protect via SSL, so if you domain was www.mydomain.com, use that.  If you wanted to protect mydomain.com (without the www.) then use that.

root@localhost# openssl req -new -key www.mydomain.com.key -out www.mydomain.com.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [GB]:
State or Province Name (full name) [Berkshire]:
Locality Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server’s hostname) []:www.mydomain.com
Email Address []:email@mydomain.com

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Next, generate the self-signed certificate. You can specify the number of days the cert is valid for.

root@localhost# openssl x509 -req -days 365 -in www.mydomain.com.csr -signkey www.mydomain.com.key -out www.mydomain.com.crt
Signature ok
subject=/C=/ST=/L=/O=/CN=www.mydomain.com/emailAddress=email@mydomain.com
Getting Private key

Next, move the certificate and keyfile into apache’s SSL directory.

mv www.mydomain.com.key /etc/httpd/conf/ssl.key/
mv www.mydomain.com.crt /etc/httpd/conf/ssl.crt/

Finally, we configure our SSL virtual host in Apache.  The simplest way to do this is to copy the virtual host for the site you want to make SSL, then add/change the following bits.

<VirtualHost 192.168.1.100:443>
…
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.key/www.mydomain.com.key
SSLCertificateKeyFile /etc/httpd/conf/ssl.crt/www.mydomain.com.crt
…
</VirtualHost>

Binding to 1 Port
First we bind SSHd to a specific port. We do this because hackers will expect that you are going to use port 22 for SSH. You can change it to any random 4 or 5 digit number.

Find where it says:

#Port 22

And enter a new line below it like this(change 7676 to your own number):

Port 7676

Binding to SSHv2
Next we are going to only allow access to SSH version 2, and not SSH version one. We do this because SSH version 2 is a more secure protocol.

Find where it says:

#Protocol 2,1

And enter a new line below it like this:

Protocol 2

Binding to 1 IP Address
Third we will bind SSHd to a single IP address. The reason we do this is imagine that you have a webserver with 5 IPs (192.168.1.2 – 192.168.1.6) and you have all your hosted clients on 192.168.1.2. Most people trying to gain access are going to try to connect to that IP address. To make it more secure, we will take one IP out of your allocated space and use it only for SSH access. We will call this our Server Administion IP, say 192.168.1.6.

Find where it says:

#ListenAddress 0.0.0.0

And enter a new line below it like this:

ListenAddress 192.168.1.6

As a side note, if you use IPv6, there is a line below #ListenAddress 0.0.0.0 that is #ListenAddress ::. You can use this format to bind to a IPv6 address.

Disabling SSH access via root account
Fourth, we are going to disable SSH access for the root account. We do this for security reasons. If for some reason your root password was comprimised, and root was allowed to SSH in, your system would be compromised. If you have disabled SSH access for root, then the hacker would have to also figure out another authorized user’s password to SSH in, then su to root. So this provides one more layer of security. But this does not protect against bad passwords.

Find where it says:

#PermitRootLogin yes

And enter a new line below it like this:

PermitRootLogin no

Make the changes take effect
The last thing we need to do is restart the SSH process. This depends on which distribution you are running, but more RedHat based distros do it this way:

/etc/init.d/sshd restart

Finally, to gain access to your system, you would now ssh to 192.168.1.6 port 7676