Lock It Down: 10 Simple Ways to Boost the Security of Your Network

“Hurry up and deploy the gear. We have a deadline. Just get it done. We’ll go back later to lock it down.” Sound familiar? For years now, it’s been commonplace for network engineers to do just this. Except, someone rarely goes back to “lock it down”. There are countless ways to improve network security, but today we’ll focus on the low-hanging fruit by providing you with ten simple practices.

10 Simple Ways to Boost Network Security

Always lock rooms with sensitive network equipment. If an unauthorized person can walk into your communication closets, he/she can wreak serious havoc. A person with malicious intent can reset administrative passwords, gain full privileges, create backdoors, and so much more. Even someone without malicious intent can cause major problems. What happens if Jimmy the janitor decides to sweep and accidentally unplugs a distribution switch or two? Uh oh.

Keep your network device software updated . Cisco releases updated software about every three to six months. Some may live by the saying “if it ain’t broke, don’t fix it”, but that’s not applicable here. Updated software doesn’t just fix bugs or add new features, it also fixes known security vulnerabilities. Try to update your router, switch, and firewall software at least once a year.

A list of Cisco product updates can be found here: https://www.cisco.com/c/en/us/support/index.html

Everyone knows that passwords are the keys to the kingdom. Some Cisco devices, specifically IOS-based routers and switches, do not encrypt all types of passwords by default. Prying eyes may see this information and use it for malicious purposes. Enable password encryption by entering the “service password-encryption” command in global configuration mode[i].

• Quick Tip #1: When configuring enable passwords, use “enable secret’” instead of “enable password”’, as the latter uses a very weak form of encryption and is simple to crack.
• Quick Tip #2: When creating local user accounts, never use type 7 passwords. These are considered unsecure . There are countless tools available to decrypt these passwords very quickly.

In the old days, telnet was used as the standard to configure devices across the network. Unfortunately, telnet transmits everything in plain text, so anyone can read it. This includes usernames, passwords, configurations, and anything else sent through a telnet window.

Using telnet makes it easier for attackers to obtain sensitive information. Surprisingly, many organizations still use telnet for remote configuration of their switches, routers, and even firewalls. Secure Shell (SSH) encrypts this data across the network. It’s best to disable telnet and enable SSH where possible.

On an IOS-based Cisco router or switch, these quick commands should get you where you need to be:

Switch(config)# hostname <enter hostname>
Switch(config)# ip domain-name <enter domain name>
Switch(config)# crypto key generate rsa

To SSH to your device, an SSH software such as PuTTY, SecureCRT, or TeraTerm will need to be used.

Telnet is bad for managing network devices but is still good for some things. Telnet to towel.blinkenlights.nl to watch an ASCII version of Star Wars!

Your organization doesn’t want an angry employee, student, or visitor attempting to authenticate to your network gear. These devices should only be accessed by the appropriate IT staff. For Cisco routers and switches, this can be locked down by creating an access-control list (ACL) and applying it to the VTY lines. The ACL should only contain the IP addresses for approved devices, all other IP addresses will be denied access immediately.

Below is an example on how to do this for IOS-based devices[ii]:

Switch(config)# access-list 10 permit 10.10.10.0 0.0.0.255
Switch(config)# line vty 0 15
Switch(config-line)# access-class 10 in

SNMP is a necessity when it comes to monitoring your network environment. However, most organizations don’t configure SNMP in a secure manner. This data can contain network configurations, device versions, and unencrypted passwords (see #3 on this list). A device can also be configured via SNMP. An attacker would have a field-day if a read-write string was set to ‘cisco’ with no ACL applied!

Here are some tips on how to use SNMP wisely:

• Use SNMPv3 whenever possible. SNMPv3 allows for both authentication and encryption (privacy) which is a tremendous improvement over the older versions.
• Use an SNMP access-control List (ACL). This limits the IP addresses which can access the device via SNMP.
• If SNMPv2c must be used, don’t use simple (or default) read and read-write strings. Change the strings to be consistent with your organizations password requirements.

Network devices have a slew of services running in the background. Many are necessary, but not all. These unnecessary services can waste additional resources, but more importantly, can increase the attack surface of the device. Below is a list of IOS-based services you should disable, unless absolutely required[iii]:

• TCP & UDP Small Servers - Rarely used built-in services used for diagnostics relating to echo, chargen , discard, daytime commands. Disable by using the commands below:
  Device(Config)# no service tcp -small-servers
  Device(Config)# no service udp -small-servers
• IP Finger - Rarely used finger service allowing remote users to show the equivalent of the show users command. Disable by using the command below:
  Device(Config)# no ip finger (or no service finger)
• IP BOOTP Server - Rarely used bootstrap protocol. Disable by using the command below:
  Device(Config)# no ip bootp server
  (or ip dhcp bootp ignore if the DHCP service is used)
• MOP - Rarely used maintenance operation protocol. Disable by using the command below:
  Device(Config)# no mop enabled
• IP Domain Lookup - Rarely used, and sometimes annoying, DNS resolution services. Disable by using the command below:
  Device(Config)# no ip domain-lookup
• Service Pad - Rarely used packet assembler/disassembler service (used for x.25 networks). Disable by using the command below:
  Device(Config)# no service pad
• HTTP/HTTP Server - Rarely used internal web-server. If not being used, this should be disabled. Disable by using the commands below:
  Device(Config)# no ip http server
  Device(Config)# no ip http secure-server
• Service Config - Rarely used service for retrieving configurations from the network instead of on local storage. Disable by using the command below:
  Device(Config)# no service config
  
  

• Quick Tip #1: Cisco has started disabling some of these services by default in recent IOS versions. When in doubt, try and disable them anyway.

• Quick Tip #2: NX-OS devices are a bit smarter and require use of the ‘feature’ command to enable certain services and features.

Depending on your environment this one might not fall into the simple category. While there are various solutions to mitigate the risks and concerns with using VLAN 1, it’s usually simpler to avoid using it at all.

Here are a few reasons not to use it:

• By default, all Cisco switchports are assigned to VLAN
  This can be a security risk if unused switchports aren’t shut down or changed to a different VLAN.

• VLAN 1 is the default native VLAN on trunks
  Unless the native VLAN is changed to an unused VLAN, this is another security risk which can be used in a VLAN Hopping attack[iv].

• VLAN 1 is used for control related traffic
  Various protocols including VTP, CDP, and PAgP use this VLAN which traverse a trunk even if pruned. Using VLAN 1 for endpoints can be sub-optimal.

Device logs can be extremely helpful, especially when there is a security breach, or something breaks. Many organizations have poor logging practices which may not even be realized. For instance, timestamps may be incorrect, logs only exist on the local device, or logs are disabled altogether.

Here is a list of best practices for logging:

• Ensure logging is configured for the proper logging level
  On Cisco routers, switches, firewalls – this is usually level 6 (Informational)
• Both time and timestamps should be accurate
  The device should be using a valid NTP server and the time zone should be correct
• Use an external logging server
  Open-source (or minimal cost) syslog software is widely available
• Log to the device buffer
  Logging to the device’s buffer can make troubleshooting easier

Server teams are pros when it comes to backups. Unfortunately, that’s not always the case on the network side of the house. Routers, switches, and firewalls need some backup loving too. Configurations can be rebuilt without backups; however, it will be much more painful and time consuming which results in increased downtime.

For smaller organizations, a simple copy and paste of the configuration files will work just fine. Larger organizations may want to look at automated tools which do this on a regular basis.

A truly secure network environment is made up of many layers. The recommendations above address only a small handful. If this article peaks your interest in learning more about your own network security, feel free to reach out to our Security Team. We’ll be glad to perform a complete assessment and provide intuitive and informative results.

About the Author
Dave Barus has been working in the IT field for over 15 years with extensive experience in networking and security. He spent many years working overseas assisting the U.S. Military with the design, configuration, and management of enterprise networks in the Middle East. Since returning to the U.S. he has moved into the VAR space specializing in the design & implementation of various technologies for organizations throughout the world. Dave now works for Internetwork Engineering as a Solutions Engineer helping customers find the right technology solution for their business.

Sources:

[i] https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html#anc14

[ii] https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html#anc44

[iii] https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html#anc18

[iv] https://en.wikipedia.org/wiki/VLAN_hopping