Section 12.2 Virtual Private Networks (VPNs) | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

12.2 Virtual Private Networks (VPNs)

graphics/fourdangerlevel.gif

Private networks were quite popular until recently. Most large organizations leased private networks to connect their different office locations together. The vendor promised that their data was secure, and most of the time it was. Unfortunately, only the largest users could afford a private network and even then it was expensive. As an alternative, companies started using the Internet. The lack of security on the Internet eventually caused many to act sensibly about security, well, until Wi-Fi came about anyway.

When a large dealer for a certain well-known company put a sniffer on one of its satellite network's base stations, the dealer discovered that the promised per-dealer encryption did not exist, and that any other dealer could sniff its customer data, quote requests, etc. and use it to steal customers away. I then was hired to create a VPN for them to solve the problem before lawsuits flew.

The security lesson here is not to automatically trust any vendor. The big guys are not always more trustworthy than the small ones. And, if you control your own VPNs, you don't need to trust the telecommunications vendor concerning security. Linux makes an excellent VPN. Also, the same box can serve as a firewall and router for T1, E1, Frame Relay, and many other common protocols.

The trend now, and a good one, is for organizations to link their different offices with VPNs operating over the Internet. With this implementation, you get much lower cost, easier installation, and excellent security that exceeds the uncertain security of a real private network. There are, however, different and incompatible VPN protocols. The correct one for you depends on your requirements.

The almost universally supported standard is IPSec.

12.2.1 VPN Dangers

Many people consider VPNs to be the security equivalent of the Fountain of Youth. If only they could find the right one and get it deployed, they could bathe forever in its rejuvenating waters. Gone will be the dangers of home and mobile users insecurely connecting to the corporate network over telnet, FTP, POP, or IMAP. Gone, too, will be the risk of Windows mail viruses from these remote systems. However, when the next bad Windows virus enters the main office network via a user's violated home system and propagates via the VPN to the rest of the offices, the SysAdmin's boss instead will make her feel like she is bathing in molten lava.

What happened? Well, a VPN or any encrypted path, including SSH or SSL only protects the data between the two VPN boxes. It will securely transport viruses and other evil packets right along with the data the company actually wants to transport. It will do nothing to protect either the sender or the receiver (whether it is the main office, a home user, or a remote office) from being infected. Therefore, it is critical to understand this and implement various rings of security. The typical path of a virus through an organization's VPN is shown in Figure 12.1.

Figure 12.1. Virus path through the VPN.

graphics/12fig01.gif

More important details and concepts on ways around the corporate firewall and ways to block them can be found in "Firewalls and the Corporate Moat" on page 73.

It is critical to refuse a VPN connection from any remote system or network that cannot maintain at least as high a level of security as your local network. If your local network has a firewall to restrict traffic to allowed ports, the remote systems and networks must use one as well. Unless your home users are knowledgeable enough to configure their systems with your corporate firewalls, you should insist on doing it for them. If you do not consider Windows sufficiently secure to serve as your corporate firewall, how can it serve as one at home? One of my clients asked me to configure some old 486 boxes as Linux firewalls to protect their researchers' home Silicon Graphics workstations as a condition of their being allowed to SSH into the department's on-campus network of SGIs. Others are planning to do this as well.

Following this methodology, if your campus network has a firewall and virus filter between it and the Internet, any and all remote systems (including home and mobile systems) need equivalent protection before their data can be allowed to pass through the corporate VPN to the main network. This solution will place you at the whim of users, unless the home VPN/firewall and virus-filtering system are one system and only knowledgeable people have privileged access to it. An alternate solution is to have data coming into each office from the office's VPN undergo filtering in order to block unacceptable ports and viruses. Ideally, both solutions (i.e., filtering between the Internet and remote users and filtering data coming into each office via the VPN) should be used, for more Rings of Security.

Make full use of Linux's IP Tables or IP Chains so that you allow only necessary traffic to travel through the VPN. If you limit your remotes to using POP or IMAP to get mail, using SMTP to send mail to your Linux- or UNIX-based mail server, and using http to browse the internal Linux- or UNIX-based Web server (and all are kept secure through techniques in this book), your primary concern becomes mail-borne viruses. If you filter out attachments in mail from these remote systems, you will be well-protected.

To give an idea on how to approach your VPN security, here is a typical scenario. Suppose that we have the following communication needs between the main office and the Albany branch office:

Albany users have access to use the POP3 and SMTP services on the system at 192.168.0.3 for retrieving and sending mail.
Albany users have access to the internal web server (HTTP and HTTPS) on the system at 192.168.0.4 for a corporate intranet.

The main office SysAdmin needs to manage the Samba server in the Albany office at 192.168.1.9 from her Linux workstation with IP 192.168.0.6.

The IP Tables rules in the main office might look like

 # Allow POP and SNMP traffic initiated from Albany iptables -A FORWARD -i ppp0 -p tcp --syn -m state \    --state NEW \ -s 192.168.1.0/24 -d 192.168.0.3 110 -j ACCEPT iptables -A FORWARD -i ppp0 -p tcp --syn -m state \    --state NEW \ -s 192.168.1.0/24 -d 192.168.0.3  25 -j ACCEPT # Allow HTTP and HTTPS traffic initiated from Albany iptables -A FORWARD -i ppp0 -p tcp --syn -m state \    --state NEW \ -s 192.168.1.0/24 -d 192.168.0.4  80 -j ACCEPT iptables -A FORWARD -i ppp0 -p tcp --syn -m state \    --state NEW \ -s 192.168.1.0/24 -d 192.168.0.4 443 -j ACCEPT # Allow SSH traffic initiated from main office to Samba server iptables -A FORWARD -i ppp0 -p tcp --syn -m state \    --state NEW \ -s 192.168.0.6    -d 192.168.1.9  22 -j ACCEPT # Allow established subsequent packets to #   initial SYN packet (RELATED is NO-OP) iptables -A FORWARD -p tcp -m state \   --state ESTABLISHED,RELATED -j ACCEPT # Block all other traffic from the VPN #   (you might not want to log all of it) iptables -A FORWARD -i ppp0        -s 192.168.1.0/24 \   -j LOG --log-prefix "I want DROP -l" iptables -A FORWARD -i ppp0        -s 192.168.1.0/24 \   -j DROP

and the IP Chains rules, if used, might look like:

 # Watch -s (source) and -d (destination) arguments # I'm being tricky  --Bob # Allow POP and SNMP traffic initiated from Albany ipchains -A input  -i ppp0 -p tcp -s 192.168.1.0/24 \   -d 192.168.0.3 110      -j ACCEPT ipchains -A output -i ppp0 -p tcp -d 192.168.1.0/24 \   -s 192.168.0.3 110 ! -y -j ACCEPT ipchains -A input  -i ppp0 -p tcp -s 192.168.1.0/24 \   -d 192.168.0.3  25      -j ACCEPT ipchains -A output -i ppp0 -p tcp -d 192.168.1.0/24 \   -s 192.168.0.3  25 ! -y -j ACCEPT # Allow HTTP and HTTPS traffic initiated from Albany ipchains -A input  -i ppp0 -p tcp -s 192.168.1.0/24 \   -d 192.168.0.4  80      -j ACCEPT ipchains -A output -i ppp0 -p tcp -d 192.168.1.0/24 \   -s 192.168.0.4  80 ! -y -j ACCEPT ipchains -A input  -i ppp0 -p tcp -s 192.168.1.0/24 \   -d 192.168.0.4 443      -j ACCEPT ipchains -A output -i ppp0 -p tcp -d 192.168.1.0/24 \   -s 192.168.0.4 443 ! -y -j ACCEPT # Allow SSH traffic initiated from main office #   to Samba server ipchains -A output -i ppp0 -p tcp -s 192.168.0.6 \   -d 192.168.1.9  22      -j ACCEPT ipchains -A input  -i ppp0 -p tcp -d 192.168.0.6 \   -s 192.168.1.9  22 ! -y -j ACCEPT # Block all other traffic from the VPN (you might #   not want to log all of it) ipchains -A input  -i ppp0        -s 192.168.1.0/24 \   -j DENY -l ipchains -A output -i ppp0        -d 192.168.1.0/24 \   -j DENY -l

12.2.2 VPN Using SSH, PPP, and Perl

A fascinating application of SSH is the ssh-ppp Perl script that runs PPP on top of a secure SSH connection. As you recall, a PPP connection shows up as a network interface. The route command can be used to specify that traffic to certain networks and hosts be sent through a particular interface. Even if an office is on the Internet, a simple route command on each end will route traffic destined for the other end over the secure PPP route instead of over the open Internet. Suppose a company's main office has a class C network address of 192.168.0.0, and the Albany office has a class-C network of 192.168.1.0. Each office's VPN uses eth0 as the external interface and host 1 on the internal interface. The main office's gateway would issue the commands

 route add -host 192.168.1.1 dev eth0 route add -net  192.168.1.0 netmask 255.255.255.0 dev ppp0

For the Albany office the commands would be

 route add -host 192.168.0.1 dev eth0 route add -net  192.168.0.0 netmask 255.255.255.0 dev ppp0

Presently, this script is available at

http://csociety.ecn.purdue.edu/~sigos/projects/ssh/ssh-ppp/ssh-ppp

Additionally, there is the Linux mini-HOWTO on the same subject. It is rather dated, using ipfwadm and ssh1, but it should be easy to modify for use with IP Tables or IP Chains and ssh2. I recommend against using ssh1, as it has security weaknesses in its design.

www.linuxdoc.org/HOWTO/mini/VPN.html

I have used this PPP-over-SSH technique at a number of client sites with great success. There is nothing to buy, and, because all data goes through the universally trusted SSH, both you and your management can be satisfied that it is secure. I have used it successfully for a fault-tolerant failover configuration for several clients. Each of these clients has two separate connections to the Internet; each connection is over a separate wire going through different circuits with no commonality except the local central telephone office. If the primary connection goes down, gets taken down for maintenance, suffers a DDoS attack, or even if one of the client's Sangoma T1/E1^[1] telephony cards or Ethernet cards fails, the VPN will switch to the hot backup VPN is under a minute with not even the loss of established TCP connections, such as X for FTP sessions.

^[1] None of my clients' Sangoma T1 cards ever have failed. This small Canadian company (www.sangoma.com) gives fantastic support and their support people know their cards, Linux, telephony, and Windows very well. For about US$830 per card, you can have your Linux firewall/VPN also do the routing and eliminate the cost and support issues of an external (insert your favorite brand here) router. Their cards support PPP, Frame Relay, and other protocols and are compatible with North American (T1) and European (E1) standards.

There are a few things to keep in mind:

The routing is a bit tricky. You need to route the remote network over the PPP interface (typically ppp0) so that it travels through the VPN and gets encrypted before being sent over the Internet. However, you need to route traffic to the remote VPN box itself directly over the external interface (usually eth0).
PPP's compression algorithms, especially its IP compressions, are buggy, in my experience, so they should be turned off (as per man 8 pppd). If they are not turned off, you may experience frequent crashes or even mysteriously dropped packets, resulting in hung connections or dropped links. The following options should be set in the /etc/ppp/options file:
```
 
```
```
 lcp-echo-interval 60 nodeflate noccp noaccomp nobsdcomp nopcomp nopredictor1 novj novjccomp default-asyncmap 
```
If pppd dies, the ppp0 interface will vanish and with it the route to cause traffic destined for the remote network to go over ppp0. Thus, your default route likely will cause your sensitive data to travel over the Internet unencrypted. If you are using IP Masquerading on your internal network, the packets will not arrive at their destination and thus only one packet of data will be compromised. If you are using real IP addresses, you could get caught with your pants down. For protection, it is critical to have IP Tables or IP Chains rules to prevent this, assuming that your external interface is eth0. (Prior to these rules, you would need rules to allow SSH or similar traffic that underlies the VPN method through the external interface.)
For the previous example, at the main office, the IP Tables rule
```
 
```
```
 iptables -A FORWARD -o eth0 -d 192.168.1.0/24 -j LOG iptables -A FORWARD -o eth0 -d 192.168.1.0/24 -j DROP iptables -A FORWARD -o eth0 -s 192.168.1.0/24 -j LOG iptables -A FORWARD -o eth0 -s 192.168.1.0/24 -j DROP 
```
or IP Chains rule
```
 
```
```
 ipchains -A output -i eth0 -d 192.168.1.0/24 -j DENY -l ipchains -A input  -i eth0 -s 192.168.1.0/24 -j DENY -l 
```
will stop this.
Encryption requires lots of computrons. See "VPN Performance Measurement" on page 429 for a discussion on this.
If more than two VPN boxes will be connected, you must allow for each PPP interface being allocated as the lowest numbered one not presently in use. Thus, the order in which they are started is critical to maintaining synchronization with the route commands and firewall rules. If only one fails at a time, it simply can be restarted (because of the "lowest numbered one not presently in use" algorithm). If more than one is down at any time, they must be restarted in the order that they originally were started.

12.2.3 CIPE (Crypto IP Encapsulation)

The fellow who came up with the ssh-ppp Perl script later created the free VPN scheme, CIPE, for higher reliability and flexibility as well as the ability to operate on other platforms such as Windows. The principle is the same. CIPE is very easy to set up for two servers, but can be more difficult for more than two VPN boxes connected together. In the few years that it has been around, it has become quite popular. IP Masquerading did not work with CIPE on Red Hat 7.1 or 7.2. Red Hat released RPMs to correct this in the kernel on June 10, 2002. Its official site is at

http://sites.inka.de/~W1011/devel/cipe.html

12.2.4 VPN Using FreeS/WAN IPSec

IPSec is the 800-pound gorilla of VPN protocols. Everyone supports it, so if you have it, everyone can talk to you. It is somewhat nontrivial to set up, but even your Windows and Mac users can connect into your corporate network from home or hotel. The FreeS/WAN project is an open-source implementation of IPSec for Linux. It is a VPN solution. It may be downloaded from the following site, but cannot be made available on the CD-ROM due to export/import restrictions on encryption software:

www.freeswan.org

Information on VPN solutions for Linux is available at

www.seifried.org/lasg/vpn/.

I have found it and other of Seifried's writings to be quite helpful. He is available on a consulting basis.

FreeS/WAN works well. The developers are responsive and well… it's free. This is the best solution if you need VPN access from Windows, Macs, a Cisco router, or anything else that supports IPSec. Many Admins will need to be familiar with this scenario.

12.2.5 PPTP (Point-to-Point Tunneling Protocol)

PPTP is Microsoft's proprietary protocol for a VPN solution. Its security is considered to be seriously flawed and it should be considered only as a last resort. However, if you are vacationing at a Redmond-sponsored resort, bring your penguin along and dress him in PPTP from

www.moretonbay.com/pptp.html

Fortunately, even Bill is moving to IPSec.

12.2.6 Zebedee

Zebedee is yet another VPN solution for Linux, Windows, UNIX, Java, and Ruby. It is intended principally to forward a small list of ports between a pair of systems securely, similar to SSH's -L flag. It transports TCP and UDP traffic and was intended to be easy to configure a feature not found in most VPNs. It is not compatible with IPSec. It can be downloaded from www.winton.org.uk/zebedee/.

12.2.7 VPN Performance Measurement

Because encryption is computationally intensive, the throughput of a VPN can be substantially less than the bandwidth of your Internet feed. A 250MHz Pentium II-class Linux system using the PPP-over-SSH method should keep a T1 interface (1.544Mbps) running at full speed. A 1.6GHz Pentium-class system should achieve 10Mbps throughput. These numbers are with the default (i.e., 3des or Triple DES) SSH algorithm. Selecting a less computationally expensive algorithm in SSH may increase throughput with a minimal decrease in security. This is entirely dependent on the encryption method used. The cipher can be controlled through use of the -c argument to ssh. Consult the man page for the options available to you.

Any VPN (or other encrypted tunnel) will have significant bandwidth limitations that must be evaluated before picking a solution. Sadly, some vendors' numbers are deceptive at best. In the industry standard IPSec arena, for example, some numbers quoted are with a weak insecure encryption mode selected or with serious loss of data, even though the IPSec standard (IETF RFC 1242) specifically defines throughput as a zero-loss metric. Also, be careful that the numbers reflect random incompressible data (or with a data stream similar to what yours will be). Remember that a gigabyte of binary zeros can be compressed into five bytes by a good algorithm.

In the Gigabyte arena, the clear winner is Quarry Technologies (www.quarrytech.com), a manufacturer of very high performance switches and similar networking hardware.^[2]

^[2] www.lightreading.com/document.asp?doc_id=16812

Top