CCNA Lab dot Net

Here are some tips I try to keep my router secure from all the unfriendly networks the internet has to offer.

1. Restrict telnet access to an ip access list:

Your router’s default configuration is not to allow telnet access by default. All of the system administrators enable some type of remote access to configure and manage the network device. Here is a way to secure telnet access to an ip access list.

access-list 1 permit 208.229.144.0 0.0.0.255

OK now this is very simple configuration first you need to enter configuration mode. Next you need to enter the line vty 0 4 (this means telnet lines 0 4 (5 virtual terminals ). Now add the access-class statement restricting inbound access to the access list 1. This is fairly simple and it does help with brute force attacks deny access to router.

2. Now we need to protect SNMP (Simple Network Management Protocol) from access. I use SNMP to monitor bandwidth, uptime, temperature, interface stats of all my core network devices. It is very scary when you can query someone network device. This will show you all kinds of stats about the network and maybe if it is configured improperly access to the router to make changes. So to protect the
SMNP from others eyes you need to restrict access to this tool with 2 modifications.

Configuring the community string NOT to public or read. “Public” or “Read” is the default for most equipment, change this to something unique to your network and treat this as a password and secure it. For my password I have chosen “ibs-networkmanagemnet” the next setting RO is read only no modification. The
last number refers to the access list number 10 permitting only one subnet on my network. So you can have the SNMP string but you cannot access the router because of the access list number 10.

3. Last, do not forget to enable service password-encryption. This will encrypt the passwords with a weak “type 7” encryption hash but at least your passwords will not be human readable. Note: this is a reversible type of encryption that can be CRACKED with any number of tools on the internet.

Some users of this free router pod has asked me several of questions on how I created this lab for everyone to use? I was
tasked to find a solution for network admin’s to work on our network without the network modifications impacting the admin’s connectivity. Naturally access to the console port would solve this problem. So I remembered back a few years in my Cisco class we talked about OOB or Out Of Band management. So I remember that there were a couple devices that I could configure to reverse telnet from a port to a device’s console port. I had a couple of CS500 (now EOL you might find them on ebay) hanging around from the 56K dial-up upgrade. You can also use an Async 16 or 32 A with octal cables to connect your devices. I
powered them on and began to configure for reverse telnet access.

Cisco 500 CS or NM-16A and a set of octal cables

First, I need to have access to the telnet on the CS500 so I configured networking and a gateway of last resort (or
default).

interface Ethernet 0

ip address 208.229.144.15 255.255.255.0

ip route 0.0.0.0 0.0.0.0 208.229.144.1

line vty 0 15

login

password cisco

Second, To telnet out these ports we need to specify an ip address and port number along with the telnet command. This
seems weird because we are not going to leave this access server. I need to configure a loopback address

interface Loopback 0

ip address 10.1.1.1 255.255.255.0

Third, we need a friendly way for anyone to connect to the lab routers; I would like to use IP hosts. Here I can define an
IP address and a line number. Per cisco we need to add 2000 + line number for the telnet command to work correctly

ip host SWITCH 2004 10.1.1.1

ip host ROUTER2 2003 10.1.1.1

ip host ROUTER1 2002 10.1.1.1

ip host LOCALHOST 10.1.1.1

Last, now here is the fun parts we need to tell each line how to handle certain types of flows. Now I configured each line
with the following commands.

line X

no exec (disables the EXEC process)

exec-timeout 0 0 (this will disconnect the user session once he disconnects from the access server, very useful because I
was
having a problem with open sessions after the user logs off the access server)

transport output telnet (we tell the port to only allow outbound telnet)

Wow that seems like a lot to ingest.