Real World Linux Security Prentice Hall Ptr Open Source Technology Series
12.2 Virtual Private Networks (VPNs)
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.
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.
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:
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:
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 |