Contents
Previous
Next
 This section lists many of the options available when configuring a 
Linux  kernel, and explains how they should be set on a FreeS/WAN IPSEC 
 gateway.
Note that in many cases you do not need to mess with these.
 You may have a Linux distribution which comes with FreeS/WAN 
installed (see this list).  In that 
case, you need not do a FreeS/WAN installation or a kernel 
 configuration. Of course, you might still want to configure and 
rebuild your  kernel to improve performance or security. This can be 
done with standard  tools described in the 
Kernel HowTo.
If you need to install FreeS/WAN, then you do need to configure a 
kernel.  However, you may choose to do that using the simplest 
procedure:
- Configure, build and test a kernel for your system before adding 
FreeS/WAN. See the 
Kernel HowTo for details. This step cannot be  skipped
. FreeS/WAN needs the results of your configuration.
- Then use FreeS/WAN's make oldgo command. This sets 
 everything FreeS/WAN needs and retains your values everywhere else.
 This document is for those who choose to configure their FreeS/WAN 
kernel themselves.
 Help text for most kernel options is included with the kernel 
files, and is accessible from within the configuration utilities. We 
assume you will refer to that, and to the 
Kernel HowTo, as necessary. This document covers only the 
FreeS/WAN-specific aspects of the problem.
 To avoid duplication, this document section does not cover settings 
for the additional IPSEC-related kernel options which become available 
after you have patched your kernel with FreeS/WAN patches. There is 
help text for those available from within the configuration utility.
 We assume a common configuration in which the FreeS/WAN IPSEC 
gateway is also doing ipchains(8) firewalling for a local network, and 
possibly masquerading as well.
 Some suggestions below are labelled as appropriate for "a true 
paranoid". By this we mean they may cause inconvenience and it is not 
entirely clear  they are necessary, but they appear to be the safest 
choice. Not using them  might entail some risk. Of course one suggested 
mantra for security  administrators is: "I know I'm paranoid. I wonder 
if I'm paranoid  enough."
Six labels are used to indicate how options should be set. We mark 
the  labels with [square brackets]. For two of these labels, you have 
no  choice:
- [required]
- essential for FreeS/WAN operation.
- [incompatible]
- incompatible with FreeS/WAN.
those must be set correctly or FreeS/WAN will not work
FreeS/WAN should work with any settings of the others, though of 
course  not all combinations have been tested. We do label these in 
various ways,  but these labels are only suggestions.
- [recommended]
- useful on most FreeS/WAN gateways
- [disable]
- an unwelcome complication on a FreeS/WAN gateway.
- [optional]
- Your choice. We outline issues you might consider.
- [anything]
- This option has no direct effect on FreeS/WAN and related tools, so 
 you should be able to set it as you please.
 Of course complexity is an enemy in any effort to build secure 
systems. For maximum security, any feature that can reasonably 
be turned off should be. "If in doubt, leave it out."
Indentation is based on the nesting shown by 'make menuconfig' with 
a  2.2.16 kernel for the i386 architecture.
- Code maturity and level options
- 
- Prompt for development ...  code/drivers
- [optional] If this is no, experimental drivers are  not 
shown in later menus. 
For most FreeS/WAN work, no is the preferred  setting. 
Using new or untested components is too risky for a  security gateway. However, for some hardware (such as the author's network  cards) the 
only drivers available are marked  new/experimental. In such 
cases, you must enable this  option or your cards will not appear under 
"network device  support". A true paranoid would leave this option off 
and  replace the cards. 
 
Processor type and features
[anything]
Loadable module support
- Enable loadable module support
- [optional] A true paranoid would disable this. An attacker who  has 
root access to your machine can fairly easily install a  bogus module 
that does awful things, provided modules are  enabled. A common tool 
for attackers is a "rootkit", a set  of tools used once they have 
become root to introduce assorted  additional compromises so that they 
"own" your system  despite most recovery efforts. For Linux, there is a 
tool called 
 knark which is basically a rootkit packaged as a kernel module. 
With modules disabled, an attacker cannot install a bogus module. 
 The only way  he can achieve the same effects is to install a new 
kernel and  reboot. This is considerably more likely to be noticed. 
Many FreeS/WAN gateways run with modules enabled. This  simplifies 
some administrative tasks and some ipchains features  are available 
only as modules. Once an enemy has root on your  machine your security 
is nil, so arguably defenses which come  into play only in that 
situation are pointless.
Set version information ....
[optional] This provides a check to prevent loading modules 
 compiled for a different kernel.
Kernel module loader
[disable] It gives little benefit on a typical FreeS/WAN gate  and 
entails some risk.
General setup
We list here only the options that matter for FreeS/WAN.
- Networking support
- [required]
- Sysctl interface
- [optional] If this option is turned on and the  /proc
 filesystem installed, then you can control  various system behaviours 
by writing to files under  /proc/sys. For example: 
        echo 1 > /proc/sys/net/ipv4/ipforward
 turns IP forwarding on. 
Disabling this option breaks many firewall scripts. A true  paranoid 
would disable it anyway since it might conceivably be  of use to an 
attacker.
Plug and Play support
[anything]
Block devices
[anything]
Networking options
- Packet socket
- [optional] This kernel feature supports tools such as  tcpdump(8) 
which communicate directly with network hardware,  bypassing kernel 
protocols. This is very much a two-edged sword: 
- such tools can be very useful to the firewall admin,  especially 
during initial testing
- should an evildoer breach your firewall, such tools could  give him 
or her a great deal of information about the rest  of your network
 We recommend disabling this option on production gateways.
- Kernel/User netlink socket
- [optional] Required if you want to use advanced 
 router features.
- Routing messages
- [optional]
- Netlink device emulation
- [optional]
- Network firewalls
- [recommended] You need this if the IPSEC gateway also  functions as 
a firewall. 
Even if the IPSEC gateway is not your primary firewall, we  suggest 
setting this so that you can protect the gateway with at  least basic 
local packet filters.
Socket filtering
[disable] This enables an older filtering interface. We suggest 
 using ipchains(8) instead. To do that, set the "Network  firewalls" 
option just above, and not this one.
Unix domain sockets
[required] These sockets are used for communication between the 
 ipsec(8) commands and the 
ipsec_pluto(8) daemon.
TCP/IP networking
[required]
- IP: multicasting
- [anything]
- IP: advanced router
- [optional] This gives you policy routing, which some  people have 
used to good advantage in their scripts for  FreeS/WAN gateway 
management. It is not used in our  distributed scripts, so not required 
unless you want it  for custom scripts. It requires the 
netlink interface between kernel code  and the iproute2(8) command.
- IP: kernel level autoconfiguration
- [disable] It gives little benefit on a typical FreeS/WAN  gate and 
entails some risk.
- IP: firewall packet netlink device
- [disable]
- IP: transparent proxy support
- [optional] This is required in some firewall configurations,  but 
should be disabled unless you have a definite need for it. 
- IP: masquerading
- [optional] Required if you want to use 
 non-routable private  IP addresses for your local network.
- IP: Optimize as router not host
- [recommended]
- IP: tunneling
- [required]
- IP: GRE tunnels over IP
- [anything]
- IP: aliasing support
- [anything]
- IP: ARP daemon support (EXPERIMENTAL)
- Not required on most systems, but might prove useful on 
 heavily-loaded gateways.
- IP: TCP syncookie support
- [recommended] It provides a defense against a 
denial of  service attack which uses bogus TCP connection  requests 
to waste resources on the victim machine.
- IP: Reverse ARP
- 
- IP: large window support
- [recommended] unless you have less than 16 meg RAM
IPv6
[optional] FreeS/WAN does not currently support IPv6, though work 
on  integrating FreeS/WAN with the Linux IPv6 stack has begun. 
 Details. It should be possible to use IPv4 FreeS/WAN on a machine which also 
 does IPv6. This combination is not yet well tested. We would be quite 
 interested in hearing results from anyone expermenting with it, via 
the  mailing list. 
 We do not recommend using IPv6 on production FreeS/WAN gateways 
until  more testing has been done. 
Novell IPX
[disable]
Appletalk
[disable] Quite a few Linux installations use IP but also have 
 some other protocol, such as Appletalk or IPX, for communication  with 
local desktop machines. In theory it should be possible to  configure 
IPSEC for the IP side of things without interfering  with the second 
protocol. 
We do not recommend this. Keep the software on your gateway  as 
simple as possible. If you need a Linux-based Appletalk or  IPX server, 
use a separate machine.
Telephony support
[anything]
SCSI support
[anything]
I2O device support
[anything]
Network device support
[anything] should work, but there are some points to note. 
The development team test almost entirely on 10 or 100 megabit 
 Ethernet and modems. In principle, any device that can do IP should be 
 just fine for IPSEC, but in the real world any device that has not 
 been well-tested is somewhat risky. By all means try it, but don't bet 
 your project on it until you have solid test results.
If you disabled experimental drivers in the Code 
maturity section above, then those drivers  will not be shown here. 
Check that option before going off to hunt for  missing drivers.
If you want Linux to automatically find more than one ethernet 
 interface at boot time, you need to:
- compile the appropriate driver(s) into your kernel. Modules will 
 not work for this
- add a line such as 
   append="ether=0,0,eth0 ether=0,0,eth1"
 to your /etc/lilo.conf file. In some cases you may need to specify 
 parameters such as IRQ or base address. The example uses "0,0"  for 
these, which tells the system to search. If the search does not 
 succeed on your hardware, then you should retry with explicit 
parameters.  See the lilo.conf(5) man page or the 
 LILO mini-HowTo for details.
run lilo(8)
 Having Linux find the cards this way is not necessary, but is usually 
more  convenient than loading modules in your boot scripts.
Amateur radio support
[anything]
IrDA (infrared) support
[anything]
ISDN subsystem
[anything]
Old CDROM drivers
[anything]
Character devices
The only required character device is: 
- random(4)
- [required] This is a source of random
 numbers which are required for many cryptographic protocols, 
 including several used in IPSEC. 
If you are comfortable with C source code, it is likely a  good idea 
to go in and adjust the #define lines in 
 /usr/src/linux/drivers/char/random.c to ensure that  all sources 
of randomness are enabled. Relying solely on  keyboard and mouse 
randomness is dubious procedure for a gateway  machine. You could also 
increase the randomness pool size from  the default 512 bytes (128 
32-bit words).
Filesystems
[anything] should work, but we suggest limiting a gateway  machine 
to the standard Linux ext2 filesystem in most  cases.
Network filesystems
[disable] These systems are an unnecessary risk on an IPSEC 
 gateway.
Console drivers
[anything]
Sound
[anything] should work, but we suggest enabling sound only if  you 
plan to use audible alarms for firewall problems.
Kernel hacking
[disable] This might be enabled on test machines, but should  not 
be on production gateways.
Contents
Previous
Next