Tag Archives: Cisco Routers

Recently, Cisco Subnet blogger Brad Reese wrote the article, “Expert warns of scam to blackmail companies for cash to get back access to their Cisco routers.” In that post, he wrote about hackers who manage to hijack a company’s routers and then extort money from them by threatening to take down the network. The hackers were able to obtain control of the network because of poorly written Cisco IOS ACLs, easily guessed passwords, and unencrypted SNMP community strings (or easily guessed community strings).

Don’t let this happen to you and your network. Here are my top five best practices to secure your routers, your network, and your company from malicious attacks.
1. Understand the basics of router security

You must understand the basics of router security. Here are the essentials:

Physically secure the routers
If your routers are not physically secured, anyone can walk up, perform a password reset, and gain full access to that router’s configuration. Even if this isn’t a core router, they could take down your network by poisoning the routing tables on all routers. For this reason, routers should be in a locked room and preferably have video surveillance. Additionally, reliable electrical power and cooling must be provided.

for more info on CCNA Training and CCNA Certification and more Cisco exams log in to Certkingdom.com

Lock down the router with passwords
Routers must be secured with passwords at both the login mode (to prevent initial access) and the privileged mode (to prevent configuration changes). For more information on these different levels in the Cisco IOS, please see my article, “Understand the levels of privilege in the Cisco IOS.”

Apply login mode passwords on Console, AUX, and VTY (telnet/ssh) interfaces
Password controlled access needs not only to be on the VTY lines to prevent network access, but also on the Console and AUX ports. If the Console port is locked but the AUX port doesn’t have a password, then locking the Console wasn’t of much use, was it?

Set the correct time and date
To ensure that logs are correct and have not been tampered with, you must ensure that the router has the correct time and date. For more information, please see “Synchronize a Cisco router’s clock with Network Time Protocol (NTP).”

Enable proper logging
Logging should be enabled, preferably, back to a central source like a syslog server. At minimum, you need to configure a buffered log on the router. However, if the power is lost to that router, that local buffered log is lost. For this reason, to really be secure, you need to configure a syslog server (see the article, “SolutionBase: Monitor your network with Kiwi Syslog“), and send all router logs to that server. You could also put in the open source or commercial version of Tripwire. Preferably, you should increase the level of logging and even log configuration changes to the router. For example, you can use the following command to enable SNMP traps for configuration changes:

snmp-server enable traps config

For more information on Cisco router logging, please see, “Get to know your logging options in the Cisco IOS.”

Back up router configurations to a central source
Let’s say that someone does take control of your router or wipes out your router configurations. To replace that router quickly or replace the configuration, you need to have a backup of that configuration. To do this, ensure that your routers are backed up whenever configuration changes are made or each week or day. I have enjoyed using Kiwi CatTools to do this. For more information, see “Automate changes to your Cisco router with Kiwi CatTools.”

Secure other network devices such as switches and wireless access
Most of the items listed here also apply to Cisco switches and wireless access points. Here are a couple of articles on those topics that you should check out:

* 10 things you should know about securing wireless connections
* Lock Down Switch Port Security

Two more areas that I consider to be at the basic level of router security are locking down network access to the router with a stateful firewall or ACL and encrypting sensitive network traffic, but I will cover these points in more detail below (sections three and five, respectively).
2. Know your network: Diagram, audit, and document

If you are responsible for the security of a network you should know that network like you know the vulnerable doors and windows (think entry points) of your house.

You should diagram your network so that you have a map to help you and others visualize the entire network.

You should have the router configurations backed up (see Kiwi CatTools above). Finally, you should periodically audit your network security, both internally and externally (via a third party). There are tons of network scanning and auditing tools available. Here is a recent article of mine that covered one of them: “Audit your Cisco router’s security with Nipper.”
3. Protect your router with a firewall and ACLs

In Reese’s post about the hackers, he mentioned the fact that the company had poor access control lists (ACLs) in place on their routers. ACLs are typically what protect routers from attack. However, due to their complexity, many of them end up being misconfigured or ineffective. Make sure that your ACLs allow only traffic to the router and through the router that should be there. For internal routers this will only be internal traffic.

Make sure you understand that whatever isn’t permitted will be denied (the implicit deny), that ACLs are processed from the top down, that there should never be a permit any in the ACL, and that the ACL must be applied to an interface in the proper direction to be enabled. For more information on ACLs, please see some of my articles and video on this topic:

* Secure your router with Cisco’s SDM Firewall Policy Wizard
* Cisco IOS access lists: 10 things you should know
* Use advanced parameters on your Cisco IOS ACLs
* VIDEO: Harden your Cisco Router with IOS ACLs

Keep in mind that ACLs aren’t just used to prevent traffic from going through the router. They are also used to control SSH traffic, routing update, and to throttle traffic. For more information, see:

* Learn additional uses for Cisco IOS access control lists
* Control unwanted traffic on your Cisco router with CAR

Besides ACLs, the Cisco IOS offers a real stateful firewall if you use the Security/Firewall version of the IOS. A stateful firewall will be much better than just using ACLs. I recommend checking out my article, “Protect your network with the Cisco IOS Firewall,” and consider implementing one on your routers.
4. Change your passwords and make them complex

Another method that hackers use to take control of networks is password guessing or password sniffing. To prevent this, you should CHANGE YOUR PASSWORDS TO COMPLEX PASSWORDS TODAY. Don’t wait another day! An example of a complex password is MySuper!S3cr3tPa$$.

Make sure you always use type 5 password encryption on your routers (see “Be aware of how easily someone can crack a Cisco IOS password“). Make sure this command is on your router to encrypt most (but not all) passwords with type 5 encryption:

service password-encryption

Also, keep in mind that we aren’t just talking about login passwords. This includes all SNMP community strings and routing protocol update passwords. All of those should be complex and changed periodically.

For more information on this topic, please see, “How to Configure Passwords to Secure your Cisco Router.”
5. Always encrypt sensitive network traffic

Finally, hackers can obtain passwords to your routers by sniffing network traffic when you log in to your router with telnet, perform a “show run” via telnet, or use unencrypted SNMP strings.

You should always encrypt sensitive network traffic by using SSH and SNMP encryption. Start by enabling SSH and disable telnet to all network devices that support it (see “Configure SSH on your Cisco Router“).

If you are using SNMP, enable SNMP v3 with encryption and use it exclusively (for more information, see AES and 3-DES Encryption Support for SNMP Version 3).
Be careful

The point of this article is to (1) encourage you to take action to secure your network before malicious attackers take control of it and (2) to show you exactly which actions you need to take. You shouldn’t assume that your network isn’t a target because your company isn’t high profile or your data wouldn’t be valuable to an attacker. Take every reasonable step to protect your network; as you can see from this post, these steps aren’t necessarily difficult or costly.

With the threat of ASLEAP looming, Cisco created their new Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) protocol and submitted it to the IETF. EAP-FAST as proclaimed by Cisco marketing would be “as secure as PEAP” and “as easy as LEAP”! EAP-FAST achieves this by creating the same secure encrypted tunnel used to protect user credentials during the authentication session as PEAP without the need for any kind of PKI on the client end or even the server end. Naturally, I immediately became skeptical of that claim. Of course there are other ways such as secret key cryptography of achieving a secure key exchange without PKI, but none are ever as elegant or as easy to deploy in large scale. Is EAP-FAST the exception?
EAP-FAST phases

EAP-FAST under normal operation is just like PEAP and has two phases. Phase 1 sets up a secure encrypted tunnel and Phase 2 is a MS-CHAPv2 session that verifies the client to the authentication server. Since MS-CHAPv2 is widely known to be very weak against dictionary attacks, the encrypted tunnels established in Phase 1 provides a safe environment for the MS-CHAPv2 session. The difference is that EAP-FAST uses a PAC (Protected Access Credentials) shared secret to set up the tunnel where as PEAP uses the server side digital certificate to set up a TLS tunnel (similar to how secure Web servers work). A unique user specific PAC file is generated from a single EAP-FAST Master Key on the authentication server for each and every user. Distributing the PAC can be achieved by an optional “Phase 0” (AKA automatic provisioning) or by other out-of-band methods such as sneaker net, protected admin-only file share, or user specific restricted directory.
Marketing vs. reality

After carefully reading through the IETF draft of the EAP-FAST protocol submitted by Cisco, it became fairly obvious that Cisco’s marketing claims were not entirely accurate. Although it was technically true that EAP-FAST “could” be as secure as PEAP and it “could” be as easy as LEAP, Cisco’s marketing left out the fine print and omitted the fact that you just couldn’t have both at the same time.

for more info on CCNA Training and CCNA Certification and more Cisco exams log in to Certkingdom.com

The fact of the matter is, in order for EAP-FAST to truly be as secure as PEAP, it would have to run in “server-side authentication Diffie-Hellman mode” in “Phase 0” which ironically requires a server side Digital Certificate. As you recall, the very need for a server side Digital Certificate was the very thing that scared people away from PEAP in the first place. Cisco says that you could resort to other “out-of-band” methods of PAC provisioning which doesn’t require a server side certificate but the practicality of manual PAC provisioning is rather dubious. The EAP-FAST PAC refresh mechanism on the other hand does automatically provision keys in a secure manner but it can only be used to maintain the PAC but does not address the need for initial PAC provisioning.

In order to be as easy as LEAP, EAP-FAST had to run “Phase 0” in anonymous Diffie-Hellman mode. An anonymous Diffie-Hellman key exchange by definition means that you can’t verify who is on the other end. In this case, a hacker can pose as your access-point and authentication server in Phase 0 and wait for an unsuspecting user to connect at phase 0 and wait for the clear text username and the hashed passwords. Since the server is obviously a fake, it would fail the server challenge and phase 0 would be aborted by the client. However, enough of the MS-CHAPv2 session has been captured to perform an offline ASLEAP attack. If the user’s password is not extremely complex which is usually the case, then game over and the hacker gains both user credentials and access to your wireless LAN.

According to the EAP-FAST IETF draft paper, if such a man in the middle exploit is attempted, the user is to immediately change their password. However, there is no indication that the EAP-FAST client will automatically warn the user and administrator or force the password change. At least running EAP-FAST with this convenient but weak form of automatic PAC provisioning is still significantly more secure than running LEAP for two reasons.

* First, PAC provisioning is only done once to set up the PAC secret between the server and client and all subsequent EAP-FAST sessions skip “Phase 0”. LEAP on the other hand is vulnerable each and every time a user authenticates with the radius server during the wireless LAN authentication.
* Second, even during a phase 0 anonymous DH session, the attack must be active which exposes the hacker to detection and is significantly more risky. A LEAP attacker on the other hand can perform the exploit with virtual impunity.

Even though this is a significant improvement over LEAP, EAP-FAST can never be as secure as EAP-TLS, EAP-TTLS, or PEAP while running in this mode. EAP-FAST does provide a faster authentication session because it uses symmetric cryptography instead of the asymmetric cryptography that EAP-TLS, EAP-TTLS, or PEAP uses but that’s hardly an advantage. I have even tried PEAP authentication on 266 MHz PDA devices which is the slowest platform you would run EAP on and I can’t see any significant delays with PEAP. I really doubt you will ever miss a few milliseconds on your notebook when authenticating with PEAP for wireless LAN access. Speed in deployment is what I’m concerned about and this is where EAP-FAST falls on its face.
EAP-FAST deployment troubles

The deployment of EAP-FAST is marketed “as easy as LEAP” but the reality is not so simple. According to Cisco’s own EAP-FAST deployment guide, you cannot completely rely on automatic provisioning of PAC files because it is susceptible to an active attack. The following is an excerpt from that deployment guide.

Note: Because transmission of PACs in phase zero is secured by MS-CHAPv2 authentication and MS-CHAPv2 is vulnerable to dictionary attacks, we recommend that you limit use of automatic provisioning to initial deployment of EAP-FAST. After a large EAP-FAST deployment, PAC provisioning should be performed manually to ensure the highest security for PACs. For more information about manual PAC provisioning, see Manual PAC Provisioning.

Source: Cisco EAP-FAST deployment guide

As you can see in the fine print, EAP-FAST deployment is not that straight forward. You must eventually resort to manual provisioning of user specific PAC secrets that must be deployed with the greatest secrecy and care. The secret must even be kept from other legitimate users or else the PAC is still compromised because you wouldn’t want multiple users knowing the same PAC.

After reading the Manual PAC Provisioning section from the same Cisco document, it became rather amusing to see the amount of work it takes to deploy EAP-FAST in a secure manner. Having plenty of experience in deploying EAP-TLS or PEAP, I can tell you right now that EAP-FAST manual PAC provisioning is the most labor intensive way of deploying secure authentication. In the case of PEAP, trust of the PEAP server’s digital certificate is inherent if the certificate was purchased from a public Certificate Authority.

Even if you didn’t want to spend the $300 a year to buy a digital certificate for your PEAP server, you could always build your own Certificate Authority or self sign a digital certificate which could be deployed automatically using Active Directory. If your company runs Windows NT domains or some other non-Microsoft user directory which doesn’t support automatic deployment of a Root Certificate, then the public certificate “.cer file” of the PEAP server could simply be posted on a public intranet page for users to manually install in their root CTL (Certificate Trust List). There is absolutely no fear of the public certificate falling in to the wrong hands because it only contains the 1024-bit public key portion of the certificate which is practically impossible to crack.

With EAP-FAST user specific PAC files, you literally have to generate and manage thousands (one for every user) of unique user-specific private keys where you can’t even afford a single compromise of a single key. You can forget about posting that on a public intranet server let alone automatically deploying it with Active Directory group policies. Each PAC is unique and must be manually imported in to the Cisco ACU (Aironet Client Utility) on each end user’s laptop. You can see why I chuckle when Cisco claims EAP-FAST is “easy as LEAP” because it isn’t even as easy as EAP-TLS in a managed environment.
More limitations on Cisco EAP-FAST

Cisco EAP-FAST requires the use of newer Cisco Wi-Fi adapters since the older cards don’t support it. Cisco EAP-FAST also requires the use of a very expensive authentication platform using Cisco ACS (Access Control Server) which ironically isn’t as flexible or easy to manage as Microsoft’s built in RADIUS server IAS (Internet Authentication Service) and this is speaking from a lot of experience dealing with both platforms. The Cisco client also doesn’t support “machine login” which is a way for a computer to log on to the network before the user signs on to Windows. For Enterprise deployments this is extremely important because of the need for logon scripts and group policies to function properly. Cisco’s own Website instructs users to use the Microsoft Wireless Client if they wish to implement machine logins.
The bottom line on EAP-FAST

So is Cisco’s EAP-FAST an exception to the rule where you can’t get away with no PKI to facilitate secure key exchange on a large scale? I think we can safely conclude no, it cannot. After reading through the deployment section, one really begins to wonder if EAP-FAST is really worth all that trouble just to avoid deploying a digital certificate on the authentication server because you don’t want to build a PKI Certificate Authority or because you don’t want to purchase a $300 digital certificate every year. If you were hoping that EAP-FAST was going to be your savior, it won’t happen since it can never be “as easy as LEAP” if it wants to be secure like PEAP. The best solution is to use PEAP authentication.