| Blogger Copy Paste From Internet

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 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 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).

IPSec Foundation
IPSec is a suite of protocols operating at the network layer to secure communication between IPSec peers, either client to gateway, host to host, or gateway to gateway. IPSec tunnel connections can originate from gateways (routers, firewalls), hosts, or IPSec hardware/software clients and can terminate at VPN concentrators, hosts, or gateways (routers, firewalls).

IPSec provides both authentication and encryption services. Encryption renders intercepted payload over intrinsically hostile or untrusted infrastructures useless, and authentication ensures that packets are from a legitimate peer and have not been altered in transit or maliciously injected (man-in-the-middle attacks).

Figure 11-4 demonstrates the most popular applications for IPSec. Although IPSec introduces some caveats with regard to NAT and MTU issues, it is still the approach of choice to secure IP datagram transport transparently over hostile or untrusted (shared) environments, such as the Internet per se or wireless or powerline infrastructures. A lot of work is going on right now to make IPSec more "NAT-friendly" (NAT-Traversal). For further details about current work in the IPSec area, visit the IPSec Charter of the IETF (http://www.ietf.org/html.charters/ipsec-charter.html).

If You Enjoyed This Post Please Take a Second To Share It.

Stay Connected With Free Updates

Subscribe via Email

Stylify

2:24 AM

User-Space Tunneling

CIPE (Crypto IP Encapsulation)

Example 11-10. Linux CIPE Tunnel Setup

V-TUN (Virtual Tunnel)

Example 11-11. V-TUN Tunnel Setup on Linux

Example 11-12. V-TUN Tunnel Setup on OpenBSD

OpenVPN

Example 11-13. Callisto-to-Europa (OpenVPN Tunnel with Static-Key Security (Preshared Secret)

Stunnel/SSLwrap—SSL/TLS-Based "Wrapped" Tunnels and SSL Proxying/Relaying

Secure Shell (SSH)

If You Enjoyed This Post Please Take a Second To Share It.

You Might Also Like

Stay Connected With Free Updates

teaser

This Month's Favs

Stylify

2:24 AM

User-Space Tunneling

CIPE (Crypto IP Encapsulation)

Example 11-10. Linux CIPE Tunnel Setup

V-TUN (Virtual Tunnel)

Example 11-11. V-TUN Tunnel Setup on Linux

Example 11-12. V-TUN Tunnel Setup on OpenBSD

OpenVPN

Example 11-13. Callisto-to-Europa (OpenVPN Tunnel with Static-Key Security (Preshared Secret)

Stunnel/SSLwrap—SSL/TLS-Based "Wrapped" Tunnels and SSL Proxying/Relaying

Secure Shell (SSH)

If You Enjoyed This Post Please Take a Second To Share It.

You Might Also Like

Stay Connected With Free Updates

teaser

This Month's Favs

2:24 AM