User-Space Tunneling
User-space tunnels are not an integral part of the operating system. They carry out their duty on top of TCP and UDP. This section discusses several representative examples, but a much larger variety exists. Several approaches are designed to circumvent corporate security by creating transparent tunnels (tcp80/tcp443) over HTTP(S) proxies or SOCKS5 relays.
Note that I do not discuss these approaches; they are potentially dangerous for corporate security. In addition, to a large extent, they are responsible for deployments of expensive and performance-impaired application layer gateways. Security compromises from the inside are difficult to tackle, time-consuming, and considerably increase administrative and logging burden. Proxies are there for good reasons and add security to corporate Internet architectures. Transparent proxies are one building block of modern security architectures; their caching purpose is of diminishing importance. Olaf Titz, from the CIPE Project,[3] says it best:
There are several different places where encryption can be built in to an existing network infrastructure, corresponding to the different protocol layers:
On the network level? Packets traveling between hosts on the network are encrypted. The encryption engine is placed near the driver, which sends and receives packets. An implementation is found in CIPE.
On the socket level? A logical connection between programs running on different hosts (TCP connection; transport or session layer in OSI) is encrypted. The encryption engine intercepts or proxies connections. SSH and SSL work this way.
On the application level? Applications contain their own encryption engine and encrypt data themselves. The best-known example is PGP for encrypting mail.
CIPE (Crypto IP Encapsulation)
CIPE is an established tunnel approach in the Linux community, based on tunneling IP datagrams over encrypted UDP carrier datagrams. This procedure offers transparency in contrast to TCP-tied approaches such as secure shell (SSH) or Secure Sockets Layer (SSL). CIPE creates point-to-point tunnels differentiated by port number. Because of its lightweight and elegant design, its performance characteristics are impressive. It behaves well in NAT and SOCKS5 relay environments, can to some extent handle dynamic IP addresses, and is based on Blowfish/IDEA cryptographic algorithms with a 128-bit key length.
CIPE also was ported to the Windows 2000 Server platform. The CIPE protocol performs two main tasks: encryption and checksumming of the payload packets, and dynamic key exchange. The CIPE suite consists of a kernel module, which resembles a pseudo network device, the ciped driver, and the pkcipe utility for key management. pkcipe introduced Diffie-Hellman key exchange and RSA signatures to tackle the security problem of long-lived static keys and administrative burden with many tunnels. As we know from partial or full-meshed IPSec architectures, point-to-point tunnels scale horribly (one issue successfully addressed by MPLS VPNs). For installation and operational details, consult the CIPE page at http://sites.inka.de/sites/bigred/devel/cipe.html. The next version of CIPE will take advantage of the Linux CryptoAPI, thus marking another major step toward a homogeneous architecture on Linux.
CIPE links can be qualified as belonging to different classes of carriers. Those classes are based on how they are able to reach the Internet:[4]
Direct connection on a static IP address
Direct connection on a dynamic IP address
Indirect connection through a SOCKS server
Indirect connection through a NAT (masquerading) router
Example 11-10 demonstrates a static CIPE setup between two Linux gateways and a configuration with pkcipe.
Example 11-10. Linux CIPE Tunnel Setup
[root@callisto:~#] modprobe cipcb cipe_debug=0 [root@callisto:/etc/cipe#] ls -al total 36 drwx------ 3 root root 4096 Aug 15 16:27 ./ drwxr-xr-x 86 root root 8192 Aug 15 10:15 ../ -rw-r----- 1 root root 272 Aug 15 12:37 identity -r-------- 1 root root 887 Aug 15 12:37 identity.priv -rwxr-x--- 1 root root 620 Feb 22 2002 ip-down* -rwxr-x--- 1 root root 1632 Feb 22 2002 ip-up* -rw------- 1 root root 679 Aug 15 12:40 options drwx------ 2 root root 4096 Aug 15 12:37 pk/ [root@callisto:/etc/cipe#] cat options # This is probably the minimal set of options that has to be set # Without a "device" line, the device is picked dynamically # the peer's IP address ptpaddr 10.1.1.2 mask 255.255.255.252 # our CIPE device's IP address ipaddr 10.1.1.1 # my UDP address. Note: if you set port 0 here, the system will pick # one and tell it to you via the ip-up script. Same holds for IP 0.0.0.0. me 192.168.1.1:6789 # ...and the UDP address we connect to. Of course no wildcards here. peer 192.168.1.2:6543 # The static key. Keep this file secret! # The key is 128 bits in hexadecimal notation. key 3248fd20adf9c00ccf9ecc2393bbb3e4 [root@callisto:/etc/cipe/pk#] cat pollux -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDl3o1MUEQN8IjZ9g74OwO1i8Cn +nveaW0rqsH8qDmgwe2ofQH2RdHADhd+OgbWDzODxlKp/iSTPAExeDo2gvfy+V3f cFn04T+Zsng5uDl6YZ/h35r937l9ve/XoxDGzIyg1RSnl6xvIsO9BFu6J7dc5JES +bzICr4T58q6kauTlwIDAQAB -----END PUBLIC KEY------- ipaddr 10.1.1.1 ptpaddr 10.1.1.2 mask 255.255.255.252 [root@callisto:~#] modprobe cipcb cipe_debug=1 cipe_maxdev=10 [root@callisto:~#] ciped-cb -o /etc/cipe/options [root@callisto:~#] ifconfig -a cipcb0 Link encap:IPIP Tunnel HWaddr inet addr:10.1.1.1 P-t-P:10.1.1.2 Mask:255.255.255.252 UP POINTOPOINT RUNNING NOARP MTU:1442 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:42 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:7104 (6.9 Kb) [root@callisto:/etc/xinetd.d#] cat pkcipe service pkcipe { socket_type = stream protocol = tcp wait = no user = root server = /usr/local/sbin/pkcipe server_args = -s 963 disable = no } [root@pollux:~#] pkcipe -c 192.168.1.1:pkcipe
V-TUN (Virtual Tunnel)
V-TUN (http://vtun.sourceforge.net/) runs on Linux, BSD, and Solaris platforms. I consider it the most flexible and feature-rich package for VPN deployments outside kernel space. It supports encryption, traffic shaping, and compression for TCP-/UDP-based tunnels for point-to-point VPN or mobile IP architectures via IP, PPP, SLIP, Ethernet, and other tunnel types. V-TUN requires the universal TUN/TAP driver, which resembles a virtual point-to-point network device or virtual Ethernet network device respectively and can be found at http://vtun.sourceforge.net/tun/index.html.
The good news is that on all tested current operating systems (Linux 2.4, OpenBSD 3.3, FreeBSD 4.6, NetBSD 1.6.1), the TUN/TAP driver is an integral part or module of the kernel. It requires recompiling of the kernels but no additional software besides V-TUN. For additional information, consult the man pages vtund(8) and vtund.conf(5).
Examples 11-11 and 11-12 demonstrate a V-TUN setup between Linux and OpenBSD.
Example 11-11. V-TUN Tunnel Setup on Linux
[root@callisto:~#] modprobe tun [root@callisto:/etc#] cat vtund.myconfig options { port 5000; # Listen on this port. # Syslog facility syslog daemon; # Path to various programs ppp /usr/sbin/pppd; ifconfig /sbin/ifconfig; route /sbin/route; firewall /sbin/iptables; ip /sbin/ip; } default { compress no; # Compression is off by default speed 0; # By default maximum speed, No shaping keepalive yes; # Keepalives stat yes; encrypt yes; } pollux { passwd cisco; # Password type tun; # IP tunnel proto udp; # UDP protocol compress lzo:9; # LZO compression level 9 device tun0; encrypt yes; # Encryption keepalive yes; # Keep connection alive stat yes; speed 128:64; # Tunnel shaping Kbps IN:OUT up { ifconfig "%% 10.2.2.1 pointopoint 10.2.2.2 mtu 1450"; }; down { }; } castor { passwd cisco; # Password type tun; # IP tunnel proto udp; # UDP protocol compress lzo:9; # LZO compression level 9 device tun1; encrypt yes; # Encryption keepalive yes; # Keep connection alive stat yes; up { ifconfig "%% 10.3.3.1 pointopoint 10.3.3.2 mtu 1450"; }; } europa { passwd cisco; # Password type tun; # IP tunnel proto udp; # UDP protocol compress lzo:9; # LZO compression level 9 device tun2; encrypt yes; # Encryption keepalive yes; # Keep connection alive stat yes; up { ifconfig "%% 10.4.4.1 pointopoint 10.4.4.2 mtu 1450"; }; } *** Start the vtund in server mode *** [root@callisto:~#] vtund -s -f /etc/vtund.myconfig [root@callisto:~#] ifconfig ?a ... tun2 Link encap:Point-to-Point Protocol inet addr:10.4.4.1 P-t-P:10.4.4.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1450 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:588 (588.0 b) TX bytes:840 (840.0 b) ... [root@callisto:~#] ps ax | )grep vtun 2404 ? S< 0:00 vtund[s]: europa tun tun2 6103 pts/4 S 0:00 grep vtun
Example 11-12. V-TUN Tunnel Setup on OpenBSD
[root@europa:~#] modprobe tun [root@europa:/etc#] cat vtund.myconfig options { port 5000; # Connect to this port. timeout 60; # General timeout # Path to various programs ppp /usr/sbin/pppd; ifconfig /sbin/ifconfig; route /sbin/route; firewall /sbin/ipf; } default { keepalive yes; # Keepalives } europa { passwd cisco; # Password device tun1; # Device tun1 #persist yes; # Persist mode up { ifconfig "%% 10.4.4.2 10.4.4.1 mtu 1450"; ifconfig "%% up"; #route "add -net 192.168.45.0/24 gw 10.4.4.1"; }; } *** Start the vtund in client mode *** [root@europa:~#] vtund -f /etc/vtund.myconfig europa 192.168.1.1 [root@europa:~#] ifconfig -A ... tun1: flags=51<UP,POINTOPOINT,RUNNING> mtu 1450 inet 10.4.4.2 --> 10.4.4.1 netmask 0xff000000 ... [root@europa:~#] ping 10.4.4.1 PING 10.4.4.1 (10.4.4.1): 56 data bytes 64 bytes from 10.4.4.1: icmp_seq=0 ttl=64 time=1.350 ms 64 bytes from 10.4.4.1: icmp_seq=1 ttl=64 time=1.288 ms 64 bytes from 10.4.4.1: icmp_seq=2 ttl=64 time=1.227 ms --- 10.4.4.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/std-dev = 1.227/1.288/1.350/0.058 ms [root@callisto:~#] tcpdump -i tun2 tcpdump: listening on tun2 18:32:32.081336 10.4.4.2 > 10.4.4.1: icmp: echo request 18:32:32.081351 10.4.4.1 > 10.4.4.2: icmp: echo reply 18:32:33.091594 10.4.4.2 > 10.4.4.1: icmp: echo request 18:32:33.091611 10.4.4.1 > 10.4.4.2: icmp: echo reply 18:32:34.101714 10.4.4.2 > 10.4.4.1: icmp: echo request 18:32:34.101730 10.4.4.1 > 10.4.4.2: icmp: echo reply
WARNING
Be aware of the fact that user-space tunneling solutions interfere with each other when run simultaneously. This might cause problems with binding to sockets or several programs controlling one and the same tun device. This is most certainly the case with V-TUN and OpenVPN. Never run these tools at the same time on the same gateway!
OpenVPN
OpenVPN (http://openvpn.sourceforge.net/) and V-TUN are somewhat related approaches, because both rely on the universal TUN/TAP driver to tunnel an IP subnet or virtual Ethernet adapter. OpenVPN is the most portable solution I came across in my evaluation. It can connect MAC OS X, Linux, BSD, Solaris, and Microsoft Windows via a VPN user-space daemon over TCP/UDP ports and a highly evolved SSL/TLS protocol integration (OpenSSL) with PKI support. It can handle dynamic IP addresses and operate in NAT environments. It offers tunnel bandwidth shaping, compression, encryption, and authentication featuring preshared key conventional encryption or certificate-based public key encryption. Example 11-13 demonstrates an example setup between Linux and OpenBSD.
Example 11-13. Callisto-to-Europa (OpenVPN Tunnel with Static-Key Security (Preshared Secret)
[root@europa:~#] openvpn --remote 192.168.14.1 --dev tun3 --ifconfig 10.5.5.2 10.5.5.1 --verb 5 --secret /etc/openvpn.key & [root@europa:~#] ifconfig ?A ... tun3: flags=51<UP,POINTOPOINT,RUNNING> mtu 1256 inet 10.5.5.2 --> 10.5.5.1 netmask 0xffffffff ... [root@callisto:~#] openvpn --remote 192.168.14.3 --dev tun3 --ifconfig 10.5.5.1 10.5.5.2 --verb 5 --secret /etc/openvpn.key & [root@callisto:~#] ifconfig ?a ... tun3 Link encap:Point-to-Point Protocol inet addr:10.5.5.1 P-t-P:10.5.5.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1256 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:336 (336.0 b) TX bytes:2520 (2.4 Kb) ... [root@callisto:~#] ping 10.5.5.2 PING 10.5.5.2 (10.5.5.2) from 10.5.5.1 : 56(84) bytes of data. WR64 bytes from 10.5.5.2: icmp_seq=1 ttl=255 time=1.36 ms WR64 bytes from 10.5.5.2: icmp_seq=2 ttl=255 time=1.40 ms WR64 bytes from 10.5.5.2: icmp_seq=3 ttl=255 time=1.12 ms --- 10.5.5.2 ping statistics --- 3 packets transmitted, 3 received, 0% loss, time 2016ms rtt min/avg/max/mdev = 1.129/1.298/1.403/0.124 ms
Stunnel/SSLwrap?SSL/TLS-Based "Wrapped" Tunnels and SSL Proxying/Relaying
SSL-based wrapper approaches work only for the TCP transport protocol. For example, Stunnel can encrypt TCP connections via SSL transport encryption acting as a multiplatform SSL tunneling proxy. Almost all open-source implementations are based on the OpenSSL (http://www.openssl.org) library. As mentioned at http://www.stunnel.org, "Stunnel can allow you to secure non-SSL aware daemons and protocols (like POP, IMAP, LDAP, etc) by having Stunnel provide the encryption, requiring no changes to the daemon's code."[5] SSLwrap takes a similar approach.
Secure Shell (SSH)
Although there is probably no need to introduce secure shell, I want to put it in context with our tunnel discussion. SSH uses port 21/tcp, sftp port 115/tcp, and its home base is at http://www.openssh.org. It evolved from an initial replacement for Telnet, rlogin, FTP, and rexec into a versatile and highly secure transport tunnel/relay solution with integrated strong authentication and single-sign-on capabilities. Although encrypted, the scp/sftp transfer performs extremely well. Many of OpenSSH's cryptography features rely on the OpenSSL library.
The following is a list of OpenSSH features:[6]
Open-source project
Free licensing
Strong encryption (3DES, Blowfish)
X11 forwarding (encrypt X Window System traffic)
Port forwarding (encrypted channels for legacy protocols)
Strong authentication (public key, one-time password, and Kerberos authentication)
Agent forwarding (single sign-on)
Interoperability (compliance with SSH 1.3, 1.5, and 2.0 protocol standards)
sftp client and server support in both SSH1 and SSH2 protocols
Kerberos and AFS ticket passing
Data compression
At the time of this writing, Cisco devices support only SSHv1, and there are no plans to support SSHv2 in the foreseeable future because of a focus on the IPSec architectures as a strategic platform. Cisco implements SSH server and client features and SSH terminal-line access. To figure out which Cisco IOS releases support SSH, consult Cisco.com. For example configurations, look at the Cisco.com document "Configuring Secure Shell on Routers and Switches Running Cisco IOS." SSH is straightforward to set up, but only as an integral part of authentication, authorization, and accounting (AAA).
