Chapter 4. Security Protocols

The wisest mind has something yet to learn.

—Author Unknown

Some of you might be wondering why this chapter is called “Security Protocols” since, in the IT realm, the term protocol is usually reserved for routing protocols of some sort. The best routing protocol is Open Shortest Path First (OSPF), and you should learn more about it when you can. At this time, however, the discussion focuses on security. According to Newton’s Telecom Dictionary, a protocol is defined as, “a set of rules governing the format of messages that are exchanged between computers and people.”

In the realm of security, a security protocol is defined as a secure procedure for regulating data transmission between computers. This chapter concerns the methods of encrypting data securely for transmission over a network. Later chapters cover the means of transporting data securely.

This chapter will allow you to develop an understanding of how data can be secured. In many ways, being able to protect data through encryption is yet another layer of a network’s security.

Consider the fact that each day, information is being disclosed to people whom you do not wish to have it; more often than not, this is sensitive information. In many cases, this is not intentional, nor is it related to criminal activity or attackers in any way. Do you find this difficult to believe? Think about the following points:

• Sensitive data is placed on servers connected to your LAN for other people to access.

• Sensitive data is copied to floppy disks, CDs, and DVDs, or printed and handed to the recipient.

• Sensitive data is e-mailed across the network, or perhaps the Internet.

• Sensitive data is transmitted in some other manner.

• Sensitive data is placed on a web server.

Certainly, these common examples of “business as usual” and “how we do business” are easily recognizable scenarios to everyone. We have all done this at some time or another. The danger here is that the sensitive data is being sent in the clear; this means that anyone can read the data if they intercept it intentionally or accidentally, or even unintentionally (have you ever sent an e-mail to the wrong person?). You might ask yourself what possible kind of data could be used in a negative manner. Consider the following types of data:

• Personal data—Have you ever entered your address, phone number, date of birth, and so on into a web page or an e-mail?

• Financial data—Do you use Quicken or other money-management software on your computer? Is that computer ever connected to a network? What about checking bank account information online, tracking stocks you own, or entering credit-card data online?

• Customer data—Does your company enter customer information into a database or take orders online?

• Medical data—When was the last time you walked into a hospital or doctor’s office and did not see a computer? Last time I was there, the doctor had a Palm Pilot with all my data loaded onto it. What would happen if he lost it or it was stolen?

These are the most commonly known types of data, but what about movies, music, new product plans, future projections, source code, and so on?

Most of the time, there is no danger of any sort; however, this is not always the case. When there is a mistake, it can be extremely serious. The point here is that everyone and every company has data that is important and that they would not want shared. This chapter discusses ways to protect this data.

DES Encryption

In 1972, the National Institute of Standards and Technology (NIST), known at the time as the National Bureau of Standards, decided that a strong cryptographic algorithm was needed to protect nonclassified information. Historically, this was right around the time that the Internet as we know it today was beginning to expand into colleges and universities across the country and around the world. This was one of the driving factors behind the NIST decision to have a way for people to protect their data.

In typical government fashion, a public proposal was developed that outlined the specifications for this new cryptographic algorithm. The algorithm was required to be cheap, easily distributable, flexible for inclusion into many applications, and very secure.

In 1974, IBM submitted the Lucifer algorithm, which appeared to meet most of the design requirements NIST outlined in its proposal. Lucifer appeared to be a good solution and included the specification to be 128 bits in length. NIST did not have the technical knowledge to completely evaluate Lucifer, so it enlisted the help of the National Security Agency (NSA).

In the mid-1970s, the NSA was distrusted because of its secretive activities. The Cold War was occurring at this time, and the NSA was fulfilling its role in the nation’s security. The NSA advised NIST that the 128-bit key had to be shrunk to 56 bits, thus significantly weakening the protection offered by the Data Encryption Standard (DES).

NIST adopted the modified Lucifer algorithm as a federal standard on November 23, 1976, and changed its name to the Data Encryption Standard (DES). The algorithm specification was published in January 1977, and with official backing by the government, it became a widely employed algorithm in a short amount of time.

In the late 1970s and early 1980s, when the best desktop computers were from Atari and Commodore, the security offered by DES was ideal. However, as computers became faster, the added element of people “looking” at DES, shortcuts were found; it was quickly realized that the 56-bit key was not large enough to be used as the basis for security.

In 1997, NIST discontinued its endorsement of DES and began to work on a replacement cryptographic algorithm known as the Advanced Encryption Standard (AES). Everyone loves a challenge, and the company RSA Security began sponsoring a series of DES challenges to see who could crack DES in the shortest amount of time. In the beginning, DES was cracked in days; however, more recently coming in at 22 hours, 15 minutes, the DES Challenge III was solved by the Electronic Frontier Foundation’s “Deep Crack” in a combined effort with distributed.net. The foundation used a specially developed computer called the DES Cracker and a worldwide network of nearly 100,000 PCs, with which it was able to test over 245 billion keys per second. You can visit the RSA DES Challenge web page here:

http://www.rsasecurity.com/rsalabs/challenges/des3/index.html

This illustrates that any organization with moderate resources can break through DES with some effort these days. Despite the growing concerns about its vulnerability, financial services and other industries worldwide still widely use DES to protect sensitive online applications.

Encryption Strength

DES is 56 bits, meaning that the key to decrypt DES will be 56 bits in length. Basic mathematics tells us that, if there are 56 bits, they are made up of 8 bytes of 7 bits per byte (8 * 7 = 56). If you are thinking that each byte has 8 bits, you are correct. You can, therefore, have 128 values to choose from for each character from the normal ASCII character set. ASCII, however, has 256 characters; this is double the capacity of DES, and that means that there are two possible keys for DES (that is, there are always two ASCII characters that are interchangeable). In addition, the last bit on a DES key is ignored.

The strength of any encryption algorithm lies in the fact that it would take a long time to guess the used key. You can see the possible number of combinations through some simple math:

128⁸= 128 * 128 * 128 * 128 * 128 * 128 * 128 * 128 = 72,057,594,037,927,936 (72 thousand plus billion) possible combinations

Each bit can have two states: off or on (0 or 1). There are normally 8 bits in a byte; because 8 bytes exist here, this makes 64 bits in total. Also, DES uses only 7 bits in the byte because one is ignored, as mentioned previously. This makes 56 bits in total. Converting the preceding byte calculations into bits would result in the following:

256⁸ = 2⁶⁴

128⁸ = 2⁵⁶ which is how the strength of DES being 56-bit encryption is expressed

Let’s put this math into a real-world example. Consider that you know a piece of data has been encrypted using DES and you are trying to crack the key. Your computer has the ability to try 1 million different keys every minute. If you had to try all 72 thousand billion possible keys, it would take your computer 137,096 years to try every possible key. This seems pretty impressive, doesn’t it? This certainly was the argument that led NIST and the NSA to support DES in the 1970s. However, computers have advanced quite a bit since then. The DES Crack Challenge employed technology that was trying 254 billion different keys per second.

Limitations of DES

Chapter 2, “Security Policies and Responses,” discussed having a password policy that includes special characters and numbers to increase the effectiveness of the passwords (keys) in use. Assume for a moment that people or companies are either not listening to the policy or think it is irrelevant. What effect might this have on the ability to crack a DES encrypted password (key)?

Assume that someone encrypts some important data using a key that contains normal characters—say, any letter between A and Z. Perhaps it is his mother’s name, favorite sports team, or hometown? Using only normal letters makes a password/key hundreds of thousands of times easier to crack.

The entire alphabet consists of 26 characters; because there are two possible combinations (mathematically) for each, there are really only 13 in binary. Looking at this using numbers, it can be expressed as follows:

If we have the entire alphabet, we have 26 characters; that reduces the number of possible combinations from thousands of billions down to 208 billion (208,827,064,576).

As explained previously, this number is reduced further because DES is not using all the bits in a byte to a very manageable 815 million (815,730,721). The end result is a password that can be cracked very quickly if you use only letters. You can see how quickly the key could be cracked if your computer could try a million different keys per minute—in less than 14 hours, your password could be cracked. In practice, however, most people who are using just letters of the alphabet are using them in the form of a word; those can be cracked in minutes.

Triple DES Encryption

DES was a fantastic answer to a problem in the 1970s; what the developers did not expect or anticipate was how much the world would change in less than 30 years. They did not understand that they were on the leading edge of the IT revolution. Ultimately, however, technology has made the protection level of DES such that it left businesses needing another solution.

The DES algorithm became obsolete. To fill the gap, Triple DES (written as 3DES) was developed from the original DES algorithm. The development of 3DES happened quickly because it was based on the existing DES algorithm.

Looking at the names of the two different algorithms, you might be inclined to believe that 3DES makes your encryption three times more difficult to break. 3DES actually makes your encryption five billion, trillion, trillion times harder to break—that is, 5 * 10³³.

The 3DES algorithm uses three separate keys when running its encryption algorithm and associated computations. Through the use of three separate keys, the key length has effectively been increased from 8 to 24 characters, thereby resulting in 168 bits-worth of encryption strength. Mathematically, this means that the number of possible key combinations can be expressed as

2¹⁶⁸ = 3.7 * 10⁵⁰ (370 trillion trillion trillion trillion) different combinations

Earlier in this chapter, I mentioned what would happen if you could crack keys at the rate of 1 million per minute. I have no idea how long it would take using 3DES, but I will be long gone from this earth by the time you finish. This is why 3DES is considered so strong. You can read more about cracking 3DES in financial ATM applications in the article, Extracting a 3DES Key from an IBM 4758, which you can find online at http://public.planetmirror.com/pub/descrack/.

Encryption Strength

3DES is an extension of DES that takes three keys and encrypts the data, as shown in Figure 4-1.

Figure 4-1. Triple DES Encryption Steps

The overall procedure to encrypt data is the same in 3DES and DES; however, in 3DES, the encryption process is repeated three times. The plain text data, such as an MS-Word document, is encrypted with the first key. The result is then encrypted with the second key, and that result is then encrypted with the third key—hence the name 3DES.

Limitations of 3DES

The resulting actions of having to encrypt every piece of plain text data three times means that 3DES runs slower than normal DES. If used properly with three different keys, 3DES is several magnitudes stronger than DES.

You want to avoid having the same key for each of the three encryption steps. If any of the keys are the same, the end result is that you are using a slower version of DES. As discussed in this section, 3DES is a much stronger method of encryption than DES and is used today in many places.

Message Digest 5 Algorithm

With the development of the Internet and the evolution of the world to become oriented in data and connectivity, we have also learned that “there be hackers” out there. This means that you must be concerned with issues such as security, authenticity, and integrity of data.

These issues are important for almost everyone, from the military/government to healthcare/personal records to financial data. All organizations require secret or private data to be kept from those who should not have access to it. Security in the form of authenticity and integrity of data is being driven as follows:

• Authenticity is responsible for ensuring that the group or person sending the data is who he says he is. A digital signature is an example of the importance of authenticity.

• Integrity is responsible for ensuring that the data is not altered during transmission and that exactly what was sent was received. Have you ever downloaded a software application or operating system patch? It is important that the downloaded file has not lost any of its integrity; this is the importance of integrity.

Message Digest 5 (MD5) is one of the best available methods of ensuring that these security needs are met. A message-digest algorithm is designed to accept data and generate fixed length output; this output is called a hash value, fingerprint, or a message digest and is the key to the security that MD5 provides.

Developed in 1994 by Rivest, MD5 is a one-way hash algorithm that takes any length of data and produces a 128-bit nonreversible fingerprint known as a hash. (RFC 1321 officially describes MD5.) This output hash/fingerprint cannot be reverse engineered to determine the data that was used to produce it. Functionally, this means that it is impossible to derive the original file contents from the MD5; this is why they call it one-way.

It is important to note that MD5 does not actually encrypt or alter any data. Rather, it creates a hash from which the data’s authenticity and integrity can be determined. Because MD5 does not encrypt data, it is not restricted by any exportation rules. You can freely use and distribute this MD5 anywhere in the world.

The following section looks at MD5 in action and where you might have unknowingly encountered MD5. The actual mathematics of how MD5 creates these hashes is beyond the scope of this book. Readers wanting to learn more about MD5 are encouraged to read RFC 1321, “The MD5 Message-Digest Algorithm” (http://www.isi.edu/in-notes/rfc1321.txt).

MD5 Hash in Action

If you own a computer, you have most likely experienced MD5 without even knowing it. MD5 plays a large role in networking, and it can help you in a variety of ways:

• When downloading files from the Internet, you can use MD5 to ensure that the downloaded file has been unaltered after being made available on a server. The MD5 hash is calculated after a file is downloaded.

• Ensure that the integrity of system files is maintained—various tools, such as tripwire (covered later), use MD5 to monitor and consistently verify that operating system files have not been altered. This protects crucial systems and alerts administrators if something has changed because the hashes no longer match.

When using a one-way hash operation like MD5, you can compare a calculated message digest against the received message digest to verify that the message has not been tampered with. This comparison is called a hash check.

MD5 checksums are widely used in software development to provide assurance that a downloaded file or patch is unaltered. By verifying a published MD5 checksum and comparing MD5 checksum on record with the software provider with a downloaded file’s checksum, a user can be sure that the file is the same as that offered by the developers if a match occurs.

This comparison procedure protects everyone by providing a measure of protection when downloading software and by ensuring that there are no trojan horses or computer viruses. As previously discussed, this is the definition of a digital signature. Digital signatures are especially important for electronic commerce and are a key component of most authentication schemes. To be effective, digital signatures must be unbreakable, which is an idealistic goal. As a viable compromise, the signature must be able to be independently verifiable, difficult to break, and have a design that allows its strength to increase and evolve. As demonstrated in the discussion of DES, the growth of technology can overtake security if you do not take the proper precautions or follow up on updated security needs.

Point-to-Point Tunneling Protocol (PPTP)

This section discusses the Point-to-Point Tunneling Protocol (PPTP), which was developed by Ascend Communications, Microsoft Corporation, 3Com/Primary Access, ECI Telematics, and U.S. Robotics.

PPTP operates at Layer 2 of the OSI reference model and is based on the Point-to-Point Protocol (PPP) standard for dialup networking that allows any user with a PPP client to use an ISP to connect to the Internet. PPTP builds on the functionality of PPP, which is used for traditional dialup networking, by allowing users to connect securely via a VPN (covered in Chapter 6, “Router Security”) to secure networks such as that of their employers or business partners.

Point-to-Point Tunneling Protocol (PPTP) is a protocol (or a set of communication rules) that allows corporations to extend their own corporate network through private “tunnels” over the public Internet. Effectively, a corporation uses a wide-area network (WAN) as a single large local-area network (LAN). A company no longer needs to lease its own lines for wide-area communication, but can securely use the public networks. This kind of interconnection is known as a virtual private network (VPN).

PPTP Functionality

PPTP packages data within PPP packets and then encapsulates the PPP packets within IP packets (datagrams) for transmission through an Internet-based VPN tunnel. PPTP supports data encryption and compression of these packets. PPTP also uses a form of Generic Routing Encapsulation (GRE) to move data to and from its final destination.

PPTP-based Internet remote access VPNs are by far the most common form of PPTP VPN. However, PPTP VPNs are not the most common VPNs in use. IPSec is by far the more secure and popular. Cisco IOS Software does allow the use of PPTP VPNs; however, you should definitely consider the shortcomings, which are explained in the section, “Limitations of PPTP.” When PPTP tunnels are established with a two-step creation process:

1. The user wanting to connect using a PPTP client connects to his ISP using PPP dialup networking (in most cases, traditional modem or ISDN)—or perhaps the user is permanently connected via cable modem, for example.
2. The PPTP client is launched, and it creates a control connection via TCP (port 1723) between the client and the server, thereby establishing the tunnel.

After the PPTP tunnel is established, two types of rather obvious packets of information flow through this tunnel: control messages, which manage the PPTP tunnel, and data packets.

PPTP relies on the inherent functionality of PPP to maintain the connection, encapsulate packets, and authenticate users. PPTP uses the Challenge Handshake Authentication Protocol (CHAP) or the Password Authentication Protocol (PAP).

PPTP directly handles maintaining the VPN tunnel and transmits data through the tunnel. PPTP also supports some additional security features for VPN data beyond what PPP provides.

PPTP remains a popular choice for VPNs, thanks to Microsoft. PPTP clients are freely available in all popular versions of Microsoft Windows. Windows servers and certain Cisco devices can function as PPTP-based VPN servers to terminate PPTP client connections.

Limitations of PPTP

As just discussed, the extensive use of Microsoft products is driving PPTP in many ways. Although other PPTP providers are available because many organizations have Windows servers, it is natural to want to use what you have. There are some limitations and drawbacks to using PPTP that revolve around its use in general.

The PPTP standard does not define how authentication and data encryption tasks are to be handled. This means that two different vendors might produce a PPTP-capable device or client, and yet they might not be able to work together, which introduces compatibility issues within an organization using different PPTP implementations. For example, if Vendor A implements PAP and Vendor B implements CHAP, they will not interoperate.

Concerns also persist around the security involved in the use of PPTP connections when compared with other available solutions—specifically, surrounding the implementation of Microsoft’s PPTP solution, which is the leader by far.

A company called Counterpane Internet Security is a managed security services provider founded by Bruce Schneier, who is also the current CTO. Mr. Schneier is also an author who helped developed several encryption technologies—specifically, Blowfish and Twofish. These folks have written some excellent and detailed papers on a variety of security-related subjects. Specifically, Bruce Schneier of Counterpane and Mudge of L0pht Heavy Industries conducted detailed analysis on Microsoft’s implementation of PPTP. In their own words, they summarize their findings:

“The Point-to-Point Tunneling Protocol (PPTP) was designed to solve the problem of creating and maintaining a VPN over a public TCP/IP network using the common Point-to-Point Protocol (PPP). Although the protocol leaves room for every type of encryption and authentication imaginable, most commercial products use the Microsoft Windows NT version of the protocol. This is the implementation that we cryptanalyze in this paper.

We have found Microsoft’s authentication protocol to be weak and easily susceptible to a dictionary attack; most passwords can be recovered within hours. We have found the encryption (both 40-bit and 128-bit) to be equally weak, and have discovered a series of bad design decisions that make other attacks against this encryption possible. We can open connections through a firewall by abusing the PPTP negotiations, and can mount several serious denial-of-service attacks on anyone who uses Microsoft PPTP.”

If you would like to read the entire paper or refer others to it, you can find it at

http://www.counterpane.com/pptp-paper.html

This additional paper from Counterpane Internet Security covers its findings and analysis of Microsoft’s implementation of CHAP—including both of the versions, MS-CHAP and MS-CHAPv2, respectively:

http://www.counterpane.com/pptpv2-paper.html

For a little humor regarding the findings, refer to the FAQs:

http://www.counterpane.com/pptp-faq.html

If you have taken the time to read through some of these papers on the Counterpane website, you are probably wondering how you can implement a VPN securely if PPTP is not advised. The primary alternative to PPTP is an IPSec-based VPNs. IPSec is an open standard that has been developed under the direction of the Internet Engineering Task Force (IETF) in its normal public process and is not owned by any one company. This is an important distinction because the manner in which Microsoft has implemented PPTP has made it proprietary to them. The following section examines the Layer 2 Tunneling Protocol (L2TP), which is also an extension of PPP, we will discuss IPSec in the VPN chapter.

Layer 2 Tunneling Protocol (L2TP)

Layer Two Tunneling Protocol (L2TP) is an extension of the Point-to-Point Tunneling Protocol (PPTP) that is documented in RFC 2661 and is used to enable the operation of a virtual private network (VPN) over the Internet. RFC 3193 defines using L2TP over a secure IPSec transport. In this approach, L2TP packets are exchanged over User Datagram Protocol (UDP) port 1701. IPSec Encapsulating Security Payload (ESP) protects UDP payload to ensure secure communication. Cisco and Microsoft agreed to merge their respective L2TP, thereby adopting the best features of two other tunneling protocols: PPTP from Microsoft and Layer 2 Forwarding (L2F) from Cisco Systems.

The two main components that make up L2TP are the L2TP Access Concentrator (LAC), which is the device that physically terminates a call, and the L2TP Network Server (LNS), which is the device that terminates and possibly authenticates the PPP stream.

In this regard, L2TP is similar to PPTP in its use of PPP and in both function and design. In this blending of two of the largest IT related companies, some areas definitely benefited—specifically, the area of securing sensitive data.

L2TP Versus PPTP

L2TP and PPTP have a variety of features and benefits in common that reflect their original design and function within networking. These similarities are as follows:

• Both provide a logical transport mechanism for sending PPP payloads.

• Both provide tunneling and encapsulation so that PPP payloads based on any protocol can be sent across an IP network.

• Both rely on the PPP connection process to perform user authentication and protocol configuration.

Although L2TP and PPTP share some similarities, they are different in the following ways:

• With PPTP, data encryption begins after the PPP connection process (and therefore PPP authentication) is completed. With L2TP/IPSec, data encryption begins before the PPP connection process.

• L2TP/IPSec connections use either DES or 3DES.

• PPTP requires only user-level authentication, and L2TP requires the same user-level authentication, as well as computer-level authentication through a computer certificate.

The following section discusses some of L2TP’s important benefits and how it can be used more securely than its predecessor, PPTP.

Benefits of L2TP

ISPs have been able to build VPN solutions using L2TP (because of its Internet standard status) as the method in which customers gain the benefits of VPNs within a carrier’s network. Some of the more specific benefits of L2TP include the following:

• Because it is standards-based, interoperability of L2TP capable devices between vendors is greatly increased.

• L2TP VPNs have become products for service providers.

• In Cisco-powered networks, end point-to-end point quality of service (QoS) can be provided through the use of QoS technologies such as DiffServ to categorize and handle traffic accordingly.

• IPSec is responsible for encryption, which is also standard-based (that is, defined in an RFC). IPSec provides per-packet data origin authentication (proof that the authorized user sent the data), data integrity (proof that the data was not modified in transit), replay protection (prevention from resending a stream of captured packets), and data confidentiality (prevention from interpreting captured packets without the encryption key). By contrast, PPTP provides only per-packet data confidentiality.

• Support for multiprotocol environments because, by design, L2TP can transport any routed protocols, including IP, IPX, and AppleTalk. L2TP also supports any WAN transmission technology, including Frame Relay, ATM, X.25, or SONET. It also supports LAN media such as Ethernet, Fast Ethernet, Token Ring, and FDDI.

In many ways, L2TP is the best of both vendors (Cisco and Microsoft); personally, I think Microsoft was the big winner because its tinkering with PPTP left a lot to be desired. The following section examines how L2TP functions.

L2TP Operation

As discussed previously, L2TP allows for the support of legacy protocols and over the tunnel through the use of GRE. This permits an architecture to be created that allows L2TP tunnels to connect rather easily over the public Internet or dialup.

Figure 4-2 shows the most common architecture that is used when an L2TP network is implemented. In this figure, note that the equipment shown is what an ISP or carrier would use when implementing a complete LT2P solution with all the aspects and benefits that we have described. It is commonplace for companies to use a subset of this design.

Figure 4-2. L2TP Network Architecture

L2TP will use the Internet and its network connections to make it possible for its endpoints to be in different geographic locations. In Figure 4-2, the users PC creates a dialup connection (Layer 2) to the L2TP Access Concentrator (LAC), which then authenticates them using the AAA Server and forwards the connection, which is encrypted, to the L2TP Network Server.

L2TP’s greatest security strength is its use of IPSec, which provides connections with confidentiality, per packet authentication, and anti-replay protection for control and data packets. In contrast, the Microsoft Point-to-Point Encryption (MPPE) used by PPTP encrypts only data and does not prevent forgery or replay, like IPSec does.

The following list describes the actual call-sequence steps as home users dial into their ISP to create an L2TP connection to their corporate office:

1. The remote user uses the analog telephone system or broadband to initiate a PPP connection from her home to an ISP.
2. The ISP network LAC accepts the connection at its Point of Presence (POP), and the PPP link is established.
3. After the end user and LNS negotiate LCP, the LAC partially authenticates the end user with CHAP or PAP. The username, domain name, or DNIS is used to determine whether the user is a VPDN client. This is how ISPs can offer these services because each company and user is unique. The AAA Server connected to the LAC defines each user.
4. If the user is not a VPN client (using L2TP), authentication continues, and the client accesses the Internet as a normal user. If the user is a VPN client, her connection names a specific endpoint (the L2TP network server [LNS]) where the user’s VPN terminates. The user’s information is sent to the AAA server, which is connected to the LNS, for further authentication.
5. The tunnel end points—the LAC and the LNS—authenticate each other before any data is transmitted from the user into the tunnel.
6. After the VPN tunnel (using L2TP) is created, an L2TP session is created for the end user to the corporate network.

The end result is that the exchange process appears to be between the dialup client and the remote LNS exclusively, as if no intermediary device (that is, the LAC) is involved. Figure 4-3 offers a visual representation of the L2TP incoming call sequence with its own corresponding sequence numbers. Note that the sequence numbers in Figure 4-3 are not related to the sequence numbers described previously.

Figure 4-3. L2TP Creation Steps

The following section examines one of my favorite protocols and tools for IT professionals today: Secure Shell (SSH). It is also a good security solution; no good book could be written without mentioning it, so I have to include it!.

Secure Shell (SSH)

Secure Shell, or SSH as it is more commonly known, is used to log in to a remote computer system, much in the same way that Telnet has been used in the past for the same purpose. The big difference between Telnet and SSH, however, is that SSH provides significantly enhanced security for your connection. SSH is a program that provides an encrypted communications path between two hosts over an untrusted, potentially insecure network such as the Internet. Therefore, it prevents users’ passwords and other sensitive data from being transmitted across the network in clear-text form. SSH solves the most important security problem on the Internet: hackers stealing or cracking passwords.

Used since 1995, SSH1 was designed to replace the nonsecure UNIX rcommands (rlogin, rsh, and rcp). These protocols provided UNIX users with a variety of useful tools; however, they were fraught with security concerns. The IETF released SSH2 in 1997 and improved the security and functionality of SSH1. At this time, SSH1 is slowly being phased out in favor of SSH2.

The most common usage of SSH is for creating a secure command shell (remote login) like the more common protocol, Telnet. However, SSH takes the basic functionality and vulnerabilities of Telnet and solves them in a manner that has made SSH the de facto connection standard.

SSH extends Telnet capabilities both in features and functionality. Today, SSH is available on virtually all computer platforms: Macintosh, Microsoft Windows, UNIX, Linux, and so on.

Typical SSH applications include remote access (login) to computer resources over the Internet or via some other untrusted network where you want to perform one of the three core SSH capabilities:

• Secure command shell

• Secure file transfer

• Secure Port forwarding

Although remote login is the primary use of SSH, the protocol can be used as a general purpose cryptographic tunnel that is capable of copying files, encrypting e-mail connections, and triggering remote execution of programs.

SSH Versus Telnet

Telnet is terribly insecure for so many reasons, except that it has no protection, encryption, or any way to protect your password or any activity you are conducting via Telnet. A simple Google search reveals the following as proof positive:

Perhaps you need another example relating to network security to make the point about Telnet’s insecurities a bit stronger. Look at Figure 4-4; here, I used a freely available tool, ettercap, that I installed on my Apple Powerbook and intercepted a Telnet session from another PC to a Cisco router.

Figure 4-4. ettercap Reveals Telnet use of Plain text

Let me help you understand what is happening in this figure. Upon starting ettercap, I activated its ARP Spoofing feature and inserted my laptop (using ettercap) into the communication session between the PC (192.168.254.70) and the Cisco router (192.168.254.99), as shown in the top box of the figure.

After seeing and selecting the Telnet session that was running between them, ettercap began capturing the ASCII characters being transmitted in both directions. The left column includes characters being transmitted from the PC and the right column shows the router’s characters. Thus, you can see that I logged in, input the password, entered enable mode, input my password, and executed a sh run command. The router prompts for passwords and its configuration is also shown as well (right window).

Of course, no proof to this level would be complete without showing you what SSH sends and how our little ettercap tool “sees” it. In Figure 4-5, I connected to a Cisco Firewall using SSH1 with DES (the only version of SSH that Cisco currently supports, unfortunately); as you can see, my actions and passwords are not visible.

Figure 4-5. SSH Encrypts All Data

SSH is clearly better than Telnet because it has encryption; however, the benefits of SSH do not stop there. SSH offers additional features and benefits as follows:

• Denies IP Spoofing of packets, thereby ensuring you know that host that is sending the packets.

• Encrypts packets to prevent the interception of clear text passwords and other data by intermediate hosts.

• IP source routing by preventing a host from pretending that an IP packet comes from another, trusted host.

• Prevents the manipulation of data by people in control of other devices along the route of your packets.

A much simpler way of looking at this is that SSH does trust any device other than the one with which it is trying to establish a secure connection. On the other hand, Telnet trusts anyone and pretty much anything; if I had wanted to, I could have taken over the Telnet connection shown in ettercap, erased the routers’ configuration and that is truly disturbing.

SSH Operation

To review, SSH is used to connect two different hosts using an encrypted communication session. In its simplest mode of operation, SSH uses TCP to connect to a host, and authenticates using a username and password; authentication is successful, and SSH begins encrypting data.

Depending on the version of SSH, a variety of different encryption methods can be available for use, as shown in Table 4-1.

Table 4-1. SSH Encryption Methods

Connecting keys are used during the authentication phase of SSH. Depending on the version of SSH used, either an RSA or DSA key is used with a pair created, one public and one private. Depending on the version of SSH, a variety of different authentication methods can be available for use, as shown in Table 4-2.

Table 4-2. SSH Authentication Ciphers

The private key is stored encrypted while the public key is stored on the users’ machine if they authenticates properly. This allows SSH software clients to connect automatically because the key is stored for use any time the user starts a connection.

Tunneling and Port Forwarding

SSH brings an interesting feature to the realm of security: the concept of forwarding certain traffic (identified by port number) via SSH in a tunnel. The two most common protocols to take advantage of this feature are FTP and X Windows. This forwarding feature provides SSH with the ability to utilize these other protocols for conducting operations on the host terminating the SSH connection. Perhaps the other end is a web server, and you want to upload new files over the Internet or you want desktop type access to the device using X Windows.

Figure 4-6 shows easy configuration of port forwarding. Notice also that X Windows can be easily forwarded because it is so commonly used in conjunction with SSH.

Figure 4-6. SecureCRT Allows SSH Tunneling

Limitations of SSH

SSH version 1 (SSH1) had several bugs and problems, so choose SSH version 2 (SSH2) if you have a choice. Choosing version 2 eliminates most of the limitations.

SSH does not help you protect any of your internal systems (PCs, servers, and so on); therefore, after an attacker gains access to one of those systems, he has access to SSH and it, too, can be subverted for his use.

The ability to tunnel through an SSH connection might make you think that it would be a good alternative to a VPN, but that is not the case. A better solution would be tunneling via SSH through a VPN connection—now that is a secure connection!

This section of the chapter covered SSH rather broadly and gave you enough information to understand what is happening. If you would like to learn more about SSH, I recommend the following book:

Barrett, Daniel J. and Richard Silverman. SSH, The Secure Shell: The Definitive Guide. Cambridge, MA: O’Reilly & Associates; 2001.

In summary, SSH is a popular and powerful tool for encrypting TCP sessions over a network. It is most commonly used for remote login, but also has other uses for increasing your network’s security.

Chapter Summary

This chapter discussed the importance and functionality of the DES and 3DES encryption technologies. You saw the math that is involved in each encryption technology in order to demonstrate the difficulty of cracking them—unless simple passwords are used, such as passwords with all letters.

There are several ways to tunnel and protect traffic within a network, and this chapter covered two methods: PPTP and L2TP. It discussed each of the benefits and recommended L2TP because it combines the best aspects of Microsoft and Cisco technologies. This chapter concluded with a discussion of SSH and the value it brings to your network.

Chapter Review Questions

The following questions will reinforce the concepts that were covered in this chapter.

1. How long, in bits, is the DES key?

2. In 3DES, the same key is used to encrypt at each of the three stages: true or false?

3. Define a hash in your own words.

4. What is used to create a digital signature?

5. Define authentication and provide an example.

6. Define authorization and provide an example.

7. A hash check occurs at what point in the operation of MD5?

8. Of the security protocols covered in this chapter, which of them use generic routing encapsulation (GRE)?

9. Describe several security benefits of L2TP.

10. What are the three core SSH capabilities?