From aaa0331ecf95ced1e913ac9be50168cf0e7cbb82 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:21:07 +0000 Subject: [svn-upgrade] Integrating new upstream version, strongswan (2.8.2) --- doc/kernel.html | 353 -------------------------------------------------------- 1 file changed, 353 deletions(-) delete mode 100644 doc/kernel.html (limited to 'doc/kernel.html') diff --git a/doc/kernel.html b/doc/kernel.html deleted file mode 100644 index de305683a..000000000 --- a/doc/kernel.html +++ /dev/null @@ -1,353 +0,0 @@ - - - -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:

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.

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