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/kernel.html | 353 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 353 insertions(+) create mode 100644 doc/kernel.html (limited to 'doc/kernel.html') diff --git a/doc/kernel.html b/doc/kernel.html new file mode 100644 index 000000000..de305683a --- /dev/null +++ b/doc/kernel.html @@ -0,0 +1,353 @@ + + + +Introduction to FreeS/WAN + + + + +Contents +Previous +Next +
+

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.
+
+
+
+
+Contents +Previous +Next + + -- cgit v1.2.3