From aa0f5b38aec14428b4b80e06f90ff781f8bca5f1 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Mon, 22 May 2006 05:12:18 +0000 Subject: Import initial strongswan 2.7.0 version into SVN. --- doc/src/kernel.html | 392 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 392 insertions(+) create mode 100644 doc/src/kernel.html (limited to 'doc/src/kernel.html') diff --git a/doc/src/kernel.html b/doc/src/kernel.html new file mode 100644 index 000000000..a4beab417 --- /dev/null +++ b/doc/src/kernel.html @@ -0,0 +1,392 @@ + + +Kernel configuration for FreeS/WAN + + + + + + + +

Kernel configuration for FreeS/WAN

+ +

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

+ +

Not everyone needs to worry about kernel configuration

+ +

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:

+ + +

+This document is for those who choose to configure their FreeS/WAN kernel +themselves.

+ +

Assumptions and notation

+ +

+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."

+ +

Labels used

+ +

+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."

+ +

Kernel options for FreeS/WAN

+ +

+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 the attacker uses once he or she has become root on your system. + The kit introduces assorted additional compromises so that the attacker + will continue to "own" your system despite most things you might + do to recovery the situation. 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 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.
+
+
+ + -- cgit v1.2.3