Crypto IP Encapsulation (CIPE)

Why Use CIPE?

There are several reasons why CIPE would be a smart choice for security and systems administrators:

• Red Hat Linux ships with CIPE, so it is available to all Red Hat Linux edge machines (for example, firewalls or gateways) that you wish to connect to your Intranet. Red Hat Linux also includes CIPE-supported encryption ciphers in its general distribution.

• CIPE supports encryption using either of the standard Blowfish or IDEA encryption algorithms. Depending on encryption export regulations in your country, you may use the default (Blowfish) to encrypt all CIPE traffic on your Intranet.

• Because CIPE is software based, any older machine that is able to run Red Hat Linux can become a CIPE gateway, saving an organization from having to purchase expensive dedicated VPN hardware simply to connect two LANs securely.

• CIPE is actively developed to work in conjunction with IP Tables, IP Chains, and other rules-based firewalls. Simple peer acceptance of incoming CIPE UDP packets is all that is needed to coexist with existing firewall rules.

• Administrators can configure CIPE through text files.

CIPE Installation

The installation of CIPE is equivalent to installing a new network interface under Linux. The CIPE RPM contains configuration files found in /etc/cipe/, the CIPE daemon (/usr/sbin/ciped-cb), network scripts that load the kernel module and activates/deactivates the CIPE interface (if*-cipcb), and sample configuration files found in /usr/share/doc/cipe-<version>/samples/. There is also a detailed texinfo page explaining the CIPE protocol.

This guide details a sample configuration involving a workstation client that wishes to connect securely to a remote LAN with a CIPE gateway. The workstation uses a dynamic IP address via cable modem connection, while the CIPE-enabled gateway machine employs the 192.168.1.0/24 range. This is what is known as a "typical" CIPE configuration. The following diagram illustrates the network architecture for this CIPE configuration:

Installing CIPE between the client and the CIPE server will allow for a secured peer-to-peer connection using the Internet as a medium for transmission of WAN traffic. The client workstation will then transfer a file through the Internet to the CIPE-enabled firewall, where each packet will be timestamped, encrypted, and given the peer address of the receiving CIPE-enabled firewall. The destination firewall then reads the header information, strips it, and sends it through to the remote LAN router to be then routed to its destination node. This process is seamless and completely transparent to end users. The majority of the transaction is done between the CIPE-enabled peers.

CIPE Server Configuration

To setup the CIPE server, simply install the RPM package from the Red Hat Linux disc or via Red Hat Network.

	Important
	If you are using an older version of Red Hat Linux and/or have an older version of CIPE, you should upgrade to the latest version.

The next step is to copy the sample configuration files from /usr/share/doc/cipe-version/samples (where version is the version of CIPE installed on your system) to /etc/cipe/. Once they are copied, you will need to edit the /etc/cipe/options.cipcbx (x is incremental starting from 0, for those who wish to have more than one CIPE connection on the CIPE server) file to include your LAN subnet addresses and publicly routable firewall IP addresses. The following is the example options file included with the Red Hat Linux CIPE RPM which, for this example, is renamed to options.cibcb0:

# Surprise, this file allows comments (but only on a line by themselves)
# 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         6.5.4.3

# our CIPE device's IP address
ipaddr          6.7.8.9

# 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              bigred.inka.de:6789

# ...and the UDP address we connect to. Of course no wildcards here.
peer            blackforest.inka.de:6543

# The static key. Keep this file secret!
# The key is 128 bits in hexadecimal notation.
key             xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The ptpaddr is the remote LAN's CIPE address. The ipaddr is the workstation's CIPE IP address. The me address is the client's publicly routable IP address that sends the UDP packets over the Internet, while peer is the publicly routable IP address of CIPE server. Note that the client workstation's IP address is 0.0.0.0 because it uses a dynamic connection. The CIPE client will handle the connection to the host CIPE server. The key field (represented by x's; your key should be secret) is the shared static key. This key must be the same for both peers or connection will not be possible. See the Section called CIPE Key Management for information on how to generate a shared static key for your CIPE machines.

Here is the edited /etc/cipe/options.cipcb0 that the client workstation will use:

ptpaddr        10.0.1.2
ipaddr         10.0.1.1
me             0.0.0.0
peer           LAN.EXAMPLE.COM:6969
key            123456ourlittlesecret7890shhhh

Here is the /etc/cipe/options.cipcb0 file for the CIPE server:

ptpaddr        10.0.1.1
ipaddr         10.0.1.2
me             LAN.EXAMPLE.COM:6969
peer           0.0.0.0
key            123456ourlittlesecret7890shhhh

Configuring Clients for CIPE

After successfully configuring the CIPE server and testing for functionality, you can now deploy the connection on the client machine.

The CIPE client should be able to connect and disconnect the CIPE connection in an automated way. Therefore, CIPE contains built-in mechanisms to customize settings for individual uses. For example, a remote employee can connect to the CIPE device on the LAN by typing the following:

/sbin/ifup cipcb0

The device should automatically come up, and any firewall rules and routing information should be executed along with the connection. The remote employee should be able to terminate the connection with the following:

/sbin/ifdown cipcb0

Configuring clients requires the creation of localized scripts that are run after the device has loaded. The device configuration itself can be configured locally via a user-created file called /etc/sysconfig/network-scripts/ifcfg-cipcb0. This file contains pieces of parameters that determine whether the CIPE connection occurs at boot-time and what the name of the CIPE device is, among other things. The following is the ifcfg-cipcb0 file for a remote client connecting to the LAN A CIPE server:

# These first four should be self explanatory. Change as required.
DEVICE=cipcb0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

# This is the device for which we add a host route to our CIPE peer through.
# You may hard code this, but if left blank, we punt and try to guess from
# the routing table in the /etc/cipe/ip-up.local file.
PEERROUTEDEV=

# We need to use internal DNS when connected via cipe. These may change,
# but for now, they are correct as of 20010604.
DNS=192.168.1.254

The CIPE device is named cipcb0. The CIPE device will be loaded at boot-time (configured via the ONBOOT field) and will not use a boot protocol (for example, DHCP) to receive an IP address for the device. The PEERROUTEDEV field determines the CIPE server device name that the client will be connecting to. If no device is specified in this field, one will be determined after the device has been loaded.

If your internal networks are behind a firewall (always a good policy), you need to set rules to allow the CIPE interface on the client machine to send and receive UDP packets. Refer to Chapter 7 for information on configuring a firewall for Red Hat Linux. For our example, IP tables rules are implemented.

	Note
	Clients should be configured such that all localized parameters are placed in a user-created file called /etc/cipe/ip-up.local. The local parameters should be reverted when the CIPE session is shut down using /etc/cipe/ip-down.local.

Firewalls should be configured on client machines to accept the CIPE UDP encapsulated packets. Rules may vary widely, but the basic acceptance of UDP packets is required for CIPE connectivity. The following IP tables rules allow UDP packets for the CIPE connection for the remote client connecting to the LAN; the final rule adds IP Masquerading to allow the remote client to communicate to the LAN and the Internet:

/sbin/modprobe iptables
/sbin/service iptables stop
/sbin/iptables -P INPUT REJECT
/sbin/iptables -F INPUT
/sbin/iptables -A INPUT -j ACCEPT -p udp -s 10.0.1.1
/sbin/iptables -A INPUT -j ACCEPT -i cipcb0
/sbin/iptables -A INPUT -j ACCEPT -i lo
/sbin/iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

You must also add routing rules to the client machine to access the nodes behind the CIPE connection as if they were on the local network. This can be done by running the route command. For our example, the client workstation would need to add the following network route:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.1.2

The following shows the final /etc/cipe/ip-up.local script for the client workstation:

#!/bin/bash -v
if [ -f /etc/sysconfig/network-scripts/ifcfg-$1 ] ; then
        . /etc/sysconfig/network-scripts/ifcfg-$1
else
        cat <<EOT | logger
Cannot find config file ifcfg-$1. Exiting.
EOF
        exit 1
fi

if [ -n ${PEERROUTEDEV} ]; then
        cat <<EOT | logger
Cannot find a default route to send cipe packets through!
Punting and hoping for the best.
EOT
        # Use routing table to determine peer gateway
        export PEERROUTEDEV=`/sbin/route -n | grep ^0.0.0.0 | head -n 1 \
           | awk '{ print $NF }'`

fi

####################################################
# Add The routes for the remote local area network #
####################################################

route add -host 10.0.1.2 dev $PEERROUTEDEV
route add -net 192.168.1.0 netmask 255.255.255.0 dev $1

####################################################
# IP TABLES Rules to restrict traffic              #
####################################################

/sbin/modprobe iptables
/sbin/service iptables stop
/sbin/iptables -P INPUT REJECT
/sbin/iptables -F INPUT
/sbin/iptables -A INPUT -j ACCEPT -p udp -s 10.0.1.2
/sbin/iptables -A INPUT -j ACCEPT -i $1
/sbin/iptables -A INPUT -j ACCEPT -i lo
/sbin/iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

Customizing CIPE

CIPE can be configured in numerous ways, from passing parameters as command-line arguments when starting ciped to generating new shared static keys. This allows a security administrator the flexibility to customize CIPE sessions to ensure security as well as increase productivity. The following chart details some of the command-line parameters when running ciped.

	Note
	The most common parameters should be placed in the /etc/cipe/options.cipcbx file for automatic loading at runtime. Be aware that any parameters passed at the command-line as options will override respective parameters set in the /etc/cipe/options.cipcbx configuration file.

CIPE Key Management

As previously mentioned, CIPE incorporates a secure combination of static link keys and encrypted traffic to create a secure tunnel over carrier networks such as the Internet. The use of static, link keys provides a common point of reference for two CIPE-enabled networks to pass information securely. Therefore, it is imperative that both CIPE-enabled network gateways share the exact same key, or CIPE communication will not be possible.

ps -auxw | md5sum