Previous Index Next

ISCS version 0.1.1

PEP Installation – Generic Linux

Basic Preparation

Install Linux on the hardware which will become your PEP. The PEP only requires iptables, iproute2 and ssh. However, the full functionality is realized when one also installs an IPSec VPN using either or both the kernel based IPSec and IKE or *swan based IPSec and IKE ( StrongSWAN - www.strongswan.org ; OpenSWAN - www.openswan.org ). Although it is not required, performance, security and functionality will be enhanced if you install the following iptables patches:

All of the submitted patches

All of the pending patches

base/NETMAP

base/mport

base/iprange

extra/tcp-window-tracking

One may wish to apply other extra patches depending on protocols planned for use such as extra/h323-conntrack-nat and extra/mms-conntrack-nat. DO NOT APPLY EXTRA/RPC.

Many of these patches have been included in the core kernel since this document was first written. If in doubt, simply try a test rule with the various matches and targets and see if the PEP accepts them.

ISCS version 0.1.1 configures neither the VPN nor iproute2 so you will need to manually create the VPN connections as well as any advanced routing features (other than binding IP addresses for NAT - ISCS will handle that).

Make sure that advanced routing and netfilter are properly enabled and configured in your kernel. If not, you will need to recompile your kernel before proceeding.

Ensure that ssh and ntp are running at startup. An exception to ntp is if the PEP is running in a Xen unprivileged domain (a virtual machine). In that case the Xen host provides the time to the guest. SSH should be configured to allow root connections, use only SSH version 2 (make sure there is only one uncommented Protocol line and that it reads “Protocol 2” without the quotation marks), disable password authentication and allow authentication via rsa (/etc/ssh/sshd_config file on Linux).

Copy the id_rsa.pub key for the root user on the DBD into the /root/.ssh/authorized_keys file on the PEP. Make sure the DBD can connect to the PEP without being prompted for a password or to accept the PEP's key. This is a common error when first using ISCS. If one does not connect via SSH from the command line a first time or in some other way populate the known_hosts file, the SPM will hang the first time it tries to connect to a PEP as it awaits approval to accept the key from stdin.

Please verify that the PEP is functioning at this point before proceeding.

PEP Customization

We will now customize the PEP for ISCS.

The PEP launches its iptables rules from the distribution independent bash script /etc/PEP/iptables.load. Therefore, one must alter the native iptables init script for the distribution being used so that the start routine calls /etc/PEP/iptables.load. For example, this is the start section from /etc/init.d/iptables from a Fedora Core 4 system:

start() {
    # Do not start if there is no config file.
    [ -f "$IPTABLES_DATA" ] || return 1

    echo -n $"Applying $IPTABLES firewall rules: "

    OPT=
    [ "x$IPTABLES_SAVE_COUNTER" = "xyes" ] && OPT="-c"

    $IPTABLES-restore $OPT $IPTABLES_DATA
    if [ $? -eq 0 ]; then
        success; echo
    else
        failure; echo; return 1
    fi

    # Load additional modules (helpers)
    if [ -n "$IPTABLES_MODULES" ]; then
        echo -n $"Loading additional $IPTABLES modules: "
        ret=0
        for mod in $IPTABLES_MODULES; do
            echo -n "$mod "
            modprobe $mod > /dev/null 2>&1
            let ret+=$?;
        done
        [ $ret -eq 0 ] && success || failure
        echo
    fi

    touch $VAR_SUBSYS_IPTABLES
    return $ret
}

One would edit the $IPTABLES-restore line to call /etc/PEP/iptables.load instead so the resulting section reads:

start() {
    # Do not start if there is no config file.
    #[ -f "$IPTABLES_DATA" ] || return 1 # DO NOT PERFORM THIS CHECK AS $IPTABLES_DATA may be missing in ISCS

    echo -n $"Applying $IPTABLES firewall rules: "

    OPT=
    [ "x$IPTABLES_SAVE_COUNTER" = "xyes" ] && OPT="-c"

    /etc/PEP/iptables.load
    if [ $? -eq 0 ]; then
        success; echo
    else
        failure; echo; return 1
    fi

    # Load additional modules (helpers)
    if [ -n "$IPTABLES_MODULES" ]; then
        echo -n $"Loading additional $IPTABLES modules: "
        ret=0
        for mod in $IPTABLES_MODULES; do
            echo -n "$mod "
            modprobe $mod > /dev/null 2>&1
            let ret+=$?;
        done
        [ $ret -eq 0 ] && success || failure
        echo
    fi

    touch $VAR_SUBSYS_IPTABLES
    return $ret
}

Create an /etc/PEPBackup directory.

Create an /etc/PEP directory and copy the following files from the tarball PEP directory to /etc/PEP:
iptables.boot
iptables.load.linux
iptables.chains
SpecialRoutesUP
SpecialRoutesDown
All the files placed so far into /etc/PEP except iptables.boot and iptables.chains are bash scripts and so must be flagged as executable. The SpecialRoutesUp and SpecialRoutesDown contain sample data. YOU MUST REPLACE THE SAMPLE DATA with your real data.

Rename iptables.load.linux to iptables.load (mv iptables.load.linux iptables.load)

Copy the proxyarp file from the tarball PEP directory into /etc/init.d (or wherever the PEP's initialization scripts are stored). proxyarp must be flagged as executable and should be loaded just after the network initialization script. In many distributions, this can be accomplished using chkconfig.

Add the following lines to /etc/rc.d/rc.local:

echo 1 > /proc/sys/net/ipv4/ip_forward #enable forwarding

# We must set the following after enabling forwarding since enabling forwarding resets them all to their defaults

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

Configuration to support Remote Access (" Road Warriors")

The PEPs have the ability to implement "out-of-band" user authentication and apply this authentication throughout the entire WAN without relying upon spoofable virtual IP addresses or requiring direct connections to whichever PEP is protecting the resource one wishes to access. In other words, if one wants to connect to one's home office in New York and access resources behind the Hong Kong, London and Chicago PEPs, one can do so using non-IP credentials (currently ISCS only supports X.509 certificates) and use those credentials in Hong Kong, London and Chicago even though connected through New York.

This can be accomplished on a Linux PEP via either IPSec or OpenVPN. There are significant practical differences between the two. The following table may help one decide which is best for one's environment:

Our experience in the ISCS project is that the combination of OpenVPN and openswan is elegant and powerful. Do be aware that there is a bug in openswan 2.4.4 where it returns a fragmentation needed ICMP packet to OpenVPN with an MTU of zero. This causes excessive chatter and fragmentation and a severe degradation of performance. The bug can be circumvented by setting fragicmp=off in the openswan config settings. One can use IPSec and OpenVPN concurrently for two different types of remote access.

The PEP currently supports only X.509 certificates for out-of-band user authentication and access control. The PEP is able to dynamically adjust the iptables rules based upon the Distinguished Name (DN) included in the certificate and apply these rules throughout the WAN. This is done through the use of several scripts and files. The files are automatically produced when one assigns X.509 Accessors into an Access Group although one needs to create some stub files during the PEP setup. The IPSec solution will require DN's in RFC2253 syntax whereas OpenVPN will use the openssl syntax. This is reflected in the names of the various files. Follow these steps:

For an OpenVPN installation:

1. Create an empty read/write file named /etc/PEP/DNList and another named /etc/PEP/DNListDENY

2. Copy the DNRead file from the tarball PEP directory into /etc/PEP/. Flag it as executable (chmod a+x /etc/PEP/DNRead)

3. Copy the clientconn.script and clientdisconn.script files from the tarball PEP directory into /etc/openvpn. Flag them as executable (chmod a+x /etc/openvpn/client*.script).

4. Configure the OpenVPN server configuration files to call /etc/openvpn/clientconn.script as the client-connect script (client-connect /etc/openvpn/clientconn.script) and /etc/openvpn/clientdisconn.script and the client-disconnect script (client-disconnect /etc/openvpn/clientdisconn.script).

5. The IP protocol and ports used by OpenVPN are user configurable. Consequently access to the OpenVPN ports must be allowed just as any other service when the PEP is defined in the SPM. Create the PEP using the appropriate model with OpenVPN support. Add the interfaces for the tun and tap interface virtual networks to the Private Interfaces along with all pertinent network settings just as one would do for any directly connected networks. Once the PEP has been created, add Resources to it in the Resources panel of the Resource Groups tab for the IP protocols and ports it is using for OpenVPN connections. Add these Resources to the Public Resources (not the Internet) Resource Group.

For an IPSec installation:

1. Create an empty read/write file named /etc/PEP/DNList2253 and another named /etc/PEP/DNList2253DENY

2. Copy the DNRead2253 and X509updown files from the tarball PEP directory into /etc/PEP/. Flag them as executable (e.g., chmod a+x /etc/PEP/DNRead2253)

3. Configure any client IPSec connections, e.g., Road Warriors, to call the /etc/PEP/X509updown script instead of the default updown script (e.g., leftupdown=/etc/PEP/X509updown)

4. The PEPs will automatically listen for traffic on IP Protocol 50 (ESP) and UDP ports 500 and 4500 (IKE and ESP in UDP encapsulation).

Final Steps:

Reboot the PEP. The PEP will generate errors and warning messages about not forwarding any traffic. This is correct. Since we do not have any configuration files on the PEP, it fails safe by not allowing any access except DBD administration access. Ensure that the DBD can connect to the PEP as root via SSH without being prompted for a password. If so, the PEP is now ready to be integrated into an ISCS network.

Previous Index Next