|
|
Initiation responsibility: Head of IT Section, Administrator
Implementation responsibility: Administrator
In many organisations there is a requirement to link up the various local networks which are installed at individual locations. In most cases this is achieved using leased lines or public networks which are outside the control of the organisation. In such cases there is a danger that the transmitted data could be intercepted or tampered with or that an adversary could pass himself off as an authorised communication partner (a masquerade attack). These threats can be countered through use of a Virtual Private Network (VPN). With the aid of cryptographic procedures, it is then possible to protect the integrity and confidentiality of the data and to reliably authenticate communication partners. Linux FreeS/WAN is a freeware software package for the Linux operating system, with whose assistance a VPN that complies with the IPSEC standard can be established.
Planning
As the first step in the planning phase, the requirements which the product that will be used to protect the communications link must satisfy should be established. These include, for example, whether it needs to work alongside existing components or whether other protocols apart from TCP/IP have to be transported. The documentation for FreeS/WAN should then be worked through and used to determine whether this software package is suitable for the task in hand. If it is suitable, then the next step is to identify and document which functions of FreeS/WAN are to be used for what purpose and how it should be incorporated into the existing network structure.
Installation
FreeS/WAN runs on the freeware operating system Linux and meshes with the IP protocol stack of the kernel.
It is recommended that FreeS/WAN is only run on PCs that are configured for this purpose and that no other services - apart from any routing functions which may be required - are activated on these PCs (see also S 4.97 One Service per Server). In particular, they should not execute any firewall functions but should be independent of the firewall system. To install the operating system it is recommended using a Linux package which already contains FreeS/WAN. This facilitates installation considerably, as otherwise it is usually necessary to recompile the Linux kernel. Reference should be made here to the FreeS/WAN documentation. Moreover, only those software modules within the Linux package which are absolutely necessary should be installed.
Configuration
FreeS/WAN implements a whole range of different functions which are defined in IPSEC. Through appropriate configuration settings it is therefore possible to use this software package in many different environments, and for quite different application areas. The example provided below illustrates how FreeS/WAN can be used to protect communications between two local networks over the Internet. The configuration of the components in the two networks is as follows:
The two locations west and east of an organisation both have a connection to the Internet. They both use a multi-level firewall system which, however, for the sake of simplification is represented in the diagram by a single symbol. gateway.west and gateway.east are IT systems which run under the Linux operating system and are to serve as gateways for the local networks lan.west and lan.east with the aid of FreeS/WAN. Each of the gateways has two network cards connecting it to the firewall systems and the local networks. The aim is to ensure that all the IT systems in lan.west and lan.east can communicate securely with each other. Protection of communications is to be transparent for these IT systems.
It is important that a suitable key management procedure is chosen. It is recommended that automatic exchange of keys over a public key procedure (RSA) is used. Compared with the other procedures supported by the FreeS/WAN, this offers the highest security level. The first step in the configuration process therefore entails the generation of RSA key pairs for the two gateways. This can be achieved, for example, using the command ipsec rsasigkey. The keys should be at least 768 bits long. As noted in the documentation, the keys thus generated may only be used for signatures and not for encryption. The FreeS/WAN software package ensures that this is the case. The command ipsec rsasigkey produces in each case the public and private RSA keys. It is critical to the security of the VPN that the private key cannot be compromised under any circumstances (see also S 2.46 Appropriate Key Management). The private key is stored in file /etc/ipsec.secrets on the gateway. Ownership and permissions should be set as follows:
By contrast, the public key is entered in file /etc/ipsec.conf (see below). This file is where all the other settings for FreeS/WAN are made. The format is designed in such a way that it may be possible to use the same file on both gateways. Configuration entails making settings in the form parameter = value in several sections. All the parameters which have to be set differently for the two gateways have the prefix left or right. The relevant FreeS/WAN entity can tell independently from the IP address which of the two parameters applies to it. Generally, the only difference between the versions of file /etc/ipsec.conf which are stored on the two gateways is therefore confined to the parameter interfaces, for example because on one side an ethernet is used and on the other side a token ring. In the present example recommendations as to how to configure file /etc/ipsec.conf are provided below.
config setup section
This section contains general settings which are not specific to any particular connection.
First of all, the parameter interfaces is used to specify over which network interfaces secure connections should be established. No encrypted packets are sent over any other interfaces. In the example presented above, the connection to the firewall is in each case established by the eth0 interface of the gateway.
If the parameter forwardcontrol is set to the value yes, FreeS/WAN will independently enable or disable the forwarding of IP packets when IPSEC is activated or inactivated. This is recommended as this setting will prevent packets from being transmitted unencrypted when the VPN is not available. On starting up the Linux system, steps should be taken to ensure that forwarding of IP packets is disabled until the network interfaces have been activated. How this setting is implemented will depend on the version of Linux that is being used.
The dumpdir parameter should be set to a blank value in order to prevent the FreeS/WAN components from generating core dumps in the event of a program error. Otherwise there is a danger that unauthorised persons could extract secret keys, for example, from these core dumps.
The pluto daemon is part of the FreeS/WAN package and is used for automatic key management. The parameters plutoload and plutostart determine which connections are automatically loaded into the pluto database and activated. It is advisable to set these parameters in each case to the special value %search. This will ensure that the connections which have been specified via the auto parameter are loaded and activated.
conn west-east section
This section contains settings which apply specifically to a particular connection, for example west-east.
The operating mode for this connection is specified with the type parameter. Since in the present case the network traffic is to be protected between two local networks using gateways, it is imperative that the tunnel mode is used. The transport mode is only permitted for host-to-host communication, passthrough only for manual key management.
If the parameters plutoload and plutostart are set to the special value %search, then the parameter auto determines whether the present connection is automatically loaded into the pluto database and activated. In our example the connection is to be directly activated, so the parameter auto is therefore set to start.
The parameter auth determines which of the two IPSEC functions, Encapsulating Security Payload (ESP) or Authentication Header (AH) is used during authentication. In the present case both encryption and authentication with ESP are possible. This is the standard setting.
It is recommended that authentication is performed using digital signatures with the RSA algorithm (rsasig setting). This provides a higher level of security than the "shared secrets" procedure (secret setting) as well as simplifying administration.
pfs stands for Perfect Forward Secrecy and means that messages which have been exchanged in the past are not compromised even if the private keys of the two gateways become known. (However, the security of future connections can no longer be assured.) The recommended setting for this parameter is the default value yes.
Parameter keyingtries specifies the maximum permitted number of attempts at establishing or updating the corresponding connection. It is recommended that the special value 0 is entered, i.e. so that there is no limit on the number of attempts. The preconfigured value 3 for the parameter keyingtries is inadequate for most applications.
The IP addresses of the two gateways are set through parameters left and right. It is recommended that the IP addresses are entered numerically rather than using the special value %defaultroute. By performing a comparison with the IP addresses which have been assigned to the corresponding network interfaces of the IT system, FreeS/WAN can detect which of the two roles (left or right) this IT system is assuming.
For parameters leftnexthop and rightnexthop, in each case the IP address of the component which forwards the packets over the insecure network should be entered. In the present example this component is part of the firewall system. However, depending on the segmentation and layout of the active network components in the local network, in many cases the next router downstream on the route to the Internet firewall should be entered.
These two parameters determine which two subnetworks should communicate securely with each other. In the present example these are the local networks lan.west and lan.east. The values are entered in the format subnetwork/mask, for example 10.10.0.0/16.
The parameters leftid and rightid are used to assign names which are necessary for authentication to the two gateways. It is recommended that the names are specified in the form of DNS names with the prefix "@". This will prevent FreeS/WAN from resolving the DNS names to IP addresses before they can be used to query the DNS server.
These two parameters are used to specify the public keys for the gateways. By contrast, the matching secret keys must be entered in file /etc/ipsec.secrets on the relevant gateway.
Routing
FreeS/WAN uses the routing tables of the underlying Linux operating system when forwarding IP packets. It is therefore necessary to generate rules on both gateways using the route command so that packets for the local and remote networks are forwarded via the appropriate network card.
Remote administration of a gateway
In the default configuration, gateway.west and gateway.east cannot communicate over the VPN. The secure tunnel only transports data between lan.west and lan.east. This is desirable for security reasons unless one of the two gateways is to be administered from the respective other side. In that case another connection must be defined in the ipsec.conf file. This additional connection differs from the west-east connection in that the parameter leftsubnet is missing (if gateway.west is to be remotely administered from lan.east) or else that the parameter rightsubnet is missing (if gateway.east is to be remotely administered from lan.west).
Firewall settings
firewall.west and firewall.east should be configured so that the encrypted user packets and the necessary management packets can be exchanged between the two gateways. In the present example, the following rules are necessary to achieve this:
If, contrary to the example, the value ah was set for the parameter auth, IP packets with protocol number 51 must be allowed through. Any other communication with the gateway or the local network must be prevented by the relevant firewall system.
As the firewall system and the gateway are implemented so that they are separate from each other, the parameters leftfirewall and rightfirewall, plus leftupdown and rightupdown are not used.
Where Network Address Translation (NAT) is used, it should be noted that address translation must be performed either on a component between the gateway and the local network or on the gateway itself. Generally the addresses cannot be translated within the firewall system. The reason for this is that parts of the IP packets are modified when NAT is used, so that IPSEC integrity checking generally will not work. NAT may therefore only be performed "behind" the IPSEC gateway. If address translation is to be performed on the same IT system on which FreeS/WAN is also operated, it should be noted that this will make processing of the IP packets on that IT system very complex. Information on this point will be found in the FreeS/WAN documentation. It is therefore simpler and administration is also easier if NAT is carried out on a separate component between the gateway and the local network.
VPN functional test
Before the VPN is used in actual operations, it is necessary to check that it is functioning as desired. During the test phase, instead of the two local networks only test computers should be connected to the gateways. Otherwise the possibility that "real" data will be sent unprotected over the Internet if the VPN does not function correctly straightaway cannot be excluded.
It is necessary to check that the packets are really encrypted. As described in the documentation, the simplest way of doing this is using the tools ping and tcpdump. The ping tool enables IP packets which are easy to detect to be generated, while tcpdump can be used to monitor the network traffic generated by FreeS/WAN. It should be noted that the ping command must be run on the test computer and not on the gateway. In the present configuration example, the VPN only protects the traffic between the local networks (which are replaced during the test phase by one or more test computers) and not the traffic from or to the gateways. (See also "Remote administration of a gateway" above on this point.) The command tcpdump for monitoring the network traffic generated can be run on any IT system between the two gateways.
If the VPN is not functioning as desired, for example no communication is possible or the network traffic is not encrypted, FreeS/WAN provides a number of diagnostic tools. For example, information on the status of the software program can be obtained from examining the contents of the pseudo-file /proc/net/ipsec_tncfg and by running the command ipsec look. Further information on this subject is contained in the FreeS/WAN documentation.
Additional controls:
| © Copyright
by Bundesamt für Sicherheit in der Informationstechnik |
last update: October 2000 |