From 9790537d64272aed35fda336ef18fac1fccd960d Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:25:57 +0000 Subject: - New upstream release. --- doc/src/kernel.html | 392 ---------------------------------------------------- 1 file changed, 392 deletions(-) delete mode 100644 doc/src/kernel.html (limited to 'doc/src/kernel.html') diff --git a/doc/src/kernel.html b/doc/src/kernel.html deleted file mode 100644 index a4beab417..000000000 --- a/doc/src/kernel.html +++ /dev/null @@ -1,392 +0,0 @@ - - -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:

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.

- - -- cgit v1.2.3