Tag Archives: CCNP Training

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.

MOUNTAIN VIEW, Calif.–After four years and $500 million in investments, Cisco Systems unveiled its high-end router–but it could be six months to a year before it starts seeing any revenue from the product.

The router, dubbed the Carrier Routing System-1 (CRS-1), is designed for carrier networks that handle the highest volumes of Internet traffic. It is the first product engineered by Cisco that will allow several boxes to be clustered together to function as a single router.

CRS-1, which previously had been code-named HFR for Huge Fast Router, also is the first core router to offer 40 gigabit-per-second optical interfaces. Rumors and speculation about the product have circulated for almost a year.

Four carriers, including Deutsch Telecom, Sprint, MCI and NTT Communications, were at a Cisco event here Tuesday to kick off the router. The carriers said they have been working with Cisco for the past few years to develop the product, which can be clustered through a switch fabric chassis to reach a routing capacity of 92 terabits per second. One gigabit is a billion bits; 1 terabit is a trillion bits.

While all these carriers have already tested portions of the router, none of them indicated that they would be purchasing one this year. Cisco said the CRS-1 will be commercially available in July.

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

It’s typical for carriers to test new core routers for several months, but the sales cycle for the CRS-1 will be lengthened by the fact that Cisco also has built brand-new software for the product. Sprint, which has had the hardware and software in it labs since the summer of 2003, started running live traffic over a CRS-1 on Sunday in its San Jose, Calif., facility. But it plans to continue testing the product even more.

“We will continue testing the CRS the rest of this year and probably into 2005,” Kathy Walker, executive vice president of network services for Sprint, said in an interview. “Then we will look at developing a deployment plan.”

Walker said that Sprint, which uses Cisco routers exclusively in the core of its IP (Internet Protocol) network, will continue to purchase Cisco’s previous generation of routers, the Gigabit Switch Router (GSR). The company has already begun using the GSR 12800, which was introduced in December 2003.

One key issue for Sprint to work out before it can start using CRS gear is what to do with the existing routers in its network, Walker added. The company has invested millions of dollars in the previous versions of Cisco routers.

“One CRS replaces eight GSRs,” she said. “But I may already have seven GSRs in my network that I’ve already paid for. I have to figure out what I am going to do with them before I buy a CRS. Sometimes it doesn’t make economic sense to put in something new.”

The cost of the new product hasn’t been finalized yet, but Cisco said the base price will likely be around $450,000. Walker estimated that a fully loaded system could easily cost about $1 million. Considering the high cost of these devices, she said, it’s unlikely Sprint would purchase one with only the hope of growing into it. The company plans to purchase CRS-1 routers when it is fully ready to begin converging traffic from its different voice and data networks onto a single Internet-based backbone.

Other carrier customers also said they don’t expect to be buying the new Cisco router this year. MCI, which demonstrated Cisco’s 40-gigabit optical interface at the event, said it will be at least six months before it can even consider buying the CRS-1. MCI will begin full commercial testing of the product in June or July. But there is a possibility that Cisco may not actually win over MCI with the product.

“We plan to test it vigorously,” said Jack Wimmer, a vice president of network architecture and advanced technology for MCI. “It’s hard to predict how long this will take. We won’t make a decision on whether or not we will deploy the product until we see how it stacks up to equipment from other vendors.”

MCI already uses core routers from Cisco as well as from Juniper Networks, Cisco’s closest competitor. In terms of building out its next-generation core network, Wimmer said MCI is evaluating products from various vendors including Cisco, Juniper and Avici Systems. He also said the company is evaluating gear from start-ups, although he wouldn’t name them. Several companies including Caspian Networks, Chiaro Networks, Procket Networks, and Hyperchip have all developed routers in this high-end category.

Reality check
So how long will it take for Cisco to make its money back? Executives say that’s hard to tell.

“It purely depends on the growth of the Internet,” John Chambers, CEO of Cisco, said in an interview after the event. “The key is how fast the Internet grows. A conservative estimate is that it’s growing 100 percent per year, but then you look at Japan, and they are having growth of 400 (percent) to 500 percent per year.”

Mario Mazzola, chief development officer for Cisco, admitted in an interview that it could be a long time before the company fully makes its money back on the CRS-1. But he said the investment was well worth it, considering that some of the hardware and software developed to make the product more reliable can be ported to other Cisco products.

“This is a long-term type of investment,” he said. “We don’t expect to make a return on the investment in one year. It’s hard to say how long it will take, especially when you consider the technology will also be leveraged in many other products.”

Analysts said $500 million over four years is not an outrageous investment, considering Cisco spends about $700 million to $800 million in research and development every quarter.

“It’s such an incredibly strategic product for them,” said Erik Suppiger, an equities analyst with Pacific Growth Equities. “They simply have to have a product that is competitive in this market. It’s hard to say if they’ve overinvested since we don’t know how well-received it will be among customers.”