 |  |
14.11. Point-to-Point Tunneling Protocol (PPTP)
PPTP is an encapsulation protocol based on the Point-to-Point Protocol (PPP) and the Generic Routing Encapsulation (GRE) protocol. PPP was originally designed to facilitate using IP and similar protocols over dialup connections and provides a general way to encapsulate protocols at the level of IP. PPTP is an extension of PPP, which takes PPP packets, encrypts them, and encapsulates them in GRE packets. Figure 14-3 shows the layers of encapsulation involved in sending a TCP packet via PPTP. Since PPP supports encapsulating multiple protocols, so does PPTP. It is most often used to provide virtual private networking, tunneling IP over IP, but it can also be used to tunnel non-IP protocols like IPX.
Figure 14-3. PPTP encapsulation of a TCP packet
Since PPTP tunnels packets over IP, there must be an IP-level connection between the hosts. In many situations, that connection allows the hosts to be attacked using other protocols. For instance, if you are using PPTP as a virtual private network across the Internet, the hosts have some sort of Internet connection and will have all the normal vulnerabilities of Internet-connected hosts. You will need to disable all non-PPTP connections or otherwise protect the machines. In particular, we recommend avoiding PPTP products that allow traffic to or from the host to use the underlying network directly.There's been a great deal of controversy over the security of PPTP. Some of this has been due to weaknesses in Microsoft implementations of PPTP, many of which have been fixed. However, there are some design weaknesses in PPTP as well.
14.11.1. Design Weaknesses in PPTP
Although PPTP is an encrypted protocol, not all the parts of the conversation are encrypted. Before the PPTP server starts accepting the GRE packets, a negotiation takes place over TCP. PPTP encryption protects the information being tunneled but not the negotiation involved in setting up the tunnel. The negotiation is done in cleartext and includes client and server IP addresses, the name and software version information about the client, the username, and sometimes the hashed password used for authentication. All of this information is exposed to eavesdropping.This negotiation is also done before the client has to authenticate, which makes the server particularly vulnerable to hostile clients. An attacker doesn't have to be able to authenticate in order to engage the server in negotiation, tying up resources and potentially confusing the server.
14.11.2. Implementation Weaknesses in PPTP
As we discussed earlier, PPTP sends authentication information in cleartext. In many versions of Microsoft PPTP, this information can include a LanMan hash of the user's password. As described in Chapter 21, "Authentication and Auditing Services", it is relatively easy to use a LanMan hash to discover a password. You can disable Lan Manager authentication and should do so on all clients and servers you control. This will force the authentication to use more secure Windows NT password hashes.icrosoft's implementation also has problems with the encryption. Microsoft offers two levels of encryption, both using the symmetric key encryption algorithm called RC4; one uses a 40-bit key, and the other uses a 128-bit key. (See Appendix C, "Cryptography", for more information on RC4 and the importance of key length.) The 40-bit RC4 algorithm is not particularly strong to begin with, and icrosoft weakens it further by basing the key on the user's password, so that a user will have multiple sessions with the same key. The longer a key is used, the stronger it needs to be, and the time between password changes may be a very long time indeed.
When 128-bit keys are in use, Microsoft bases the key on the user's password and on a pseudo-random number so that it's different for each connection. This is a major improvement, although using the user's password does reduce the number of probable keys and makes it important for PPTP users to have good passwords.
ost PPTP implementations, including Microsoft's, are susceptible to problems with control negotiations. As we pointed out earlier, these negotiations take place before the client authentication, which means that any attacker can send them. It's therefore extremely important for servers to be able to deal with bad negotiations, but in fact, many servers will crash if they receive garbled negotiations, and some will crash even when sent random garbage that bears no resemblance to a valid negotiation. Although Microsoft offers an option to control PPTP access by source IP address, it's enforced on the GRE tunnel, not on the TCP-based negotiation. If you are doing PPTP from known source addresses, you can protect the PPTP server with a packet filter in front of it; if you are not, you have no choice but to live with these denial of service attacks.
14.11.3. Packet Filtering Characteristics of PPTP
PPTP negotiation takes place on TCP port 1723. The actual tunnel is based on GRE, which is IP protocol 47, and uses GRE protocol hexadecimal 880B (indicating that the tunneled packets are PPP). GRE is discussed further in Chapter 4, "Packets and Protocols ".| Direction | Source Addr. | Dest. Addr. | Protocol | Source Port | Dest. Port | ACK Set | Notes |
|---|---|---|---|---|---|---|---|
| In | Ext | Int | GRE |
[37]
|
[37] |
[38]
|
Tunnel data, external client to internal server |
| Out | Int | Ext | GRE | [37] | [37] | [38] | Tunnel reply, internal server to external client |
| In | Ext | Int | TCP | >1023 | 1723 |
[39]
|
Setup request, external client to internal server |
| Out | Int | Ext | TCP | 1723 | >1023 | Yes | Setup response, internal server to external client |
| Out | Int | Ext | GRE | [37] | [37] | [38] | Tunnel data, internal client to external server |
| In | Ext | Int | GRE | [37] | [37] | [38] | Tunnel reply, external server to internal client |
| Out | Int | Ext | TCP | >1023 | 1723 | [39] | Setup request, internal client to external server |
| In | Ext | Int | TCP | 1723 | >1023 | Yes | Setup response, external server to internal client |
[37]GRE does not have ports. GRE does have protocol types, and PPTP is protocol type hexadecimal 880B.
[38]GRE has no ACK equivalent.
[39]ACK will not be set on the first packet (establishing connection) but will be set on the rest.
14.11.4. Proxying Characteristics of PPTP
It would theoretically be possible to proxy PPTP, as long as you could find a proxy system that supported GRE. It's not clear that there's any point in proxying a tunneling protocol, however. A proxy system can't apply much security, since all of the traffic is encrypted. The only thing a proxy system could protect you from is attacks on the PPTP server over the negotiation protocol.
14.11.5. Network Address Translation Characteristics of PPTP
In general, network address translation won't interfere with PPTP; although there are embedded addresses, they're intended to pass through a tunnel in any case. You will require a network address translation system that supports GRE, as well as TCP and UDP. Network address translation will not conceal any information when used with PPTP, and will not allow you to use PPTP between two networks that are using the same address space, because the original address information will be visible once the PPTP encapsulation is removed.
14.11.6. Summary of Recommendations for PPTP
- Use PPTP with caution; it does not provide as much security as other options for doing virtual private networking but may be an acceptable option if you need to tunnel protocols for reasons other than securing the information they're carrying.
- If you are going to use PPTP, proxying does not give you any significant protection, and you might as well simply pass it through packet filters.
- Configure PPTP clients and servers to use the highest available level of encryption.
|  | |
| 14.10. Remote Access Service |  | 14.12. Layer 2 Transport Protocol |
