354 lines
15 KiB
HTML
354 lines
15 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Introduction to FreeS/WAN</TITLE>
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
|
|
<STYLE TYPE="text/css"><!--
|
|
BODY { font-family: serif }
|
|
H1 { font-family: sans-serif }
|
|
H2 { font-family: sans-serif }
|
|
H3 { font-family: sans-serif }
|
|
H4 { font-family: sans-serif }
|
|
H5 { font-family: sans-serif }
|
|
H6 { font-family: sans-serif }
|
|
SUB { font-size: smaller }
|
|
SUP { font-size: smaller }
|
|
PRE { font-family: monospace }
|
|
--></STYLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="testing.html">Previous</A>
|
|
<A HREF="adv_config.html">Next</A>
|
|
<HR>
|
|
<H1><A name="kernelconfig">Kernel configuration for FreeS/WAN</A></H1>
|
|
<P> 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.</P>
|
|
<H2><A name="notall">Not everyone needs to worry about kernel
|
|
configuration</A></H2>
|
|
<P>Note that in many cases you do not need to mess with these.</P>
|
|
<P> You may have a Linux distribution which comes with FreeS/WAN
|
|
installed (see this<A href="intro.html#products"> list</A>). 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<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
|
|
Kernel HowTo</A>.</P>
|
|
<P>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:</P>
|
|
<UL>
|
|
<LI>Configure, build and test a kernel for your system before adding
|
|
FreeS/WAN. See the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
|
|
Kernel HowTo</A> for details.<STRONG> This step cannot be skipped</STRONG>
|
|
. FreeS/WAN needs the results of your configuration.</LI>
|
|
<LI>Then use FreeS/WAN's<VAR> make oldgo</VAR> command. This sets
|
|
everything FreeS/WAN needs and retains your values everywhere else.</LI>
|
|
</UL>
|
|
<P> This document is for those who choose to configure their FreeS/WAN
|
|
kernel themselves.</P>
|
|
<H2><A name="assume">Assumptions and notation</A></H2>
|
|
<P> 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<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
|
|
Kernel HowTo</A>, as necessary. This document covers only the
|
|
FreeS/WAN-specific aspects of the problem.</P>
|
|
<P> 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.</P>
|
|
<P> 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.</P>
|
|
<P> 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."</P>
|
|
<H3><A name="labels">Labels used</A></H3>
|
|
<P> 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:</P>
|
|
<DL>
|
|
<DT>[required]</DT>
|
|
<DD>essential for FreeS/WAN operation.</DD>
|
|
<DT>[incompatible]</DT>
|
|
<DD>incompatible with FreeS/WAN.</DD>
|
|
</DL>
|
|
<P>those must be set correctly or FreeS/WAN will not work</P>
|
|
<P>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<EM> these labels are only suggestions</EM>.</P>
|
|
<DL>
|
|
<DT>[recommended]</DT>
|
|
<DD>useful on most FreeS/WAN gateways</DD>
|
|
<DT>[disable]</DT>
|
|
<DD>an unwelcome complication on a FreeS/WAN gateway.</DD>
|
|
<DT>[optional]</DT>
|
|
<DD>Your choice. We outline issues you might consider.</DD>
|
|
<DT>[anything]</DT>
|
|
<DD>This option has no direct effect on FreeS/WAN and related tools, so
|
|
you should be able to set it as you please.</DD>
|
|
</DL>
|
|
<P> Of course complexity is an enemy in any effort to build secure
|
|
systems.<STRONG> For maximum security, any feature that can reasonably
|
|
be turned off should be</STRONG>. "If in doubt, leave it out."</P>
|
|
<H2><A name="kernelopt">Kernel options for FreeS/WAN</A></H2>
|
|
<P> Indentation is based on the nesting shown by 'make menuconfig' with
|
|
a 2.2.16 kernel for the i386 architecture.</P>
|
|
<DL>
|
|
<DT><A name="maturity">Code maturity and level options</A></DT>
|
|
<DD>
|
|
<DL>
|
|
<DT><A name="devel">Prompt for development ... code/drivers</A></DT>
|
|
<DD>[optional] If this is<VAR> no</VAR>, experimental drivers are not
|
|
shown in later menus.
|
|
<P>For most FreeS/WAN work,<VAR> no</VAR> is the preferred setting.
|
|
Using new or untested components is too risky for a security gateway.</P>
|
|
<P>However, for some hardware (such as the author's network cards) the
|
|
only drivers available are marked<VAR> new/experimental</VAR>. 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.</P>
|
|
</DD>
|
|
<DT>Processor type and features</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Loadable module support</DT>
|
|
<DD>
|
|
<DL>
|
|
<DT>Enable loadable module support</DT>
|
|
<DD>[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<A href="http://www.sans.org/newlook/resources/IDFAQ/knark.htm">
|
|
knark</A> which is basically a rootkit packaged as a kernel module.
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P></P>
|
|
</DD>
|
|
<DT>Set version information ....</DT>
|
|
<DD>[optional] This provides a check to prevent loading modules compiled
|
|
for a different kernel.</DD>
|
|
<DT>Kernel module loader</DT>
|
|
<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
|
|
entails some risk.</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>General setup</DT>
|
|
<DD>We list here only the options that matter for FreeS/WAN.
|
|
<DL>
|
|
<DT>Networking support</DT>
|
|
<DD>[required]</DD>
|
|
<DT>Sysctl interface</DT>
|
|
<DD>[optional] If this option is turned on and the<VAR> /proc</VAR>
|
|
filesystem installed, then you can control various system behaviours by
|
|
writing to files under<VAR> /proc/sys</VAR>. For example:
|
|
<PRE> echo 1 > /proc/sys/net/ipv4/ipforward</PRE>
|
|
turns IP forwarding on.
|
|
<P>Disabling this option breaks many firewall scripts. A true paranoid
|
|
would disable it anyway since it might conceivably be of use to an
|
|
attacker.</P>
|
|
</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>Plug and Play support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Block devices</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Networking options</DT>
|
|
<DD>
|
|
<DL>
|
|
<DT>Packet socket</DT>
|
|
<DD>[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:
|
|
<UL>
|
|
<LI>such tools can be very useful to the firewall admin, especially
|
|
during initial testing</LI>
|
|
<LI>should an evildoer breach your firewall, such tools could give him
|
|
or her a great deal of information about the rest of your network</LI>
|
|
</UL>
|
|
We recommend disabling this option on production gateways.</DD>
|
|
<DT><A name="netlink">Kernel/User netlink socket</A></DT>
|
|
<DD>[optional] Required if you want to use<A href="#adv"> advanced
|
|
router</A> features.</DD>
|
|
<DT>Routing messages</DT>
|
|
<DD>[optional]</DD>
|
|
<DT>Netlink device emulation</DT>
|
|
<DD>[optional]</DD>
|
|
<DT>Network firewalls</DT>
|
|
<DD>[recommended] You need this if the IPsec gateway also functions as a
|
|
firewall.
|
|
<P>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.</P>
|
|
</DD>
|
|
<DT>Socket filtering</DT>
|
|
<DD>[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.</DD>
|
|
<DT>Unix domain sockets</DT>
|
|
<DD>[required] These sockets are used for communication between the<A href="manpage.d/ipsec.8.html">
|
|
ipsec(8)</A> commands and the<A href="manpage.d/ipsec_pluto.8.html">
|
|
ipsec_pluto(8)</A> daemon.</DD>
|
|
<DT>TCP/IP networking</DT>
|
|
<DD>[required]
|
|
<DL>
|
|
<DT>IP: multicasting</DT>
|
|
<DD>[anything]</DD>
|
|
<DT><A name="adv">IP: advanced router</A></DT>
|
|
<DD>[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<A href="#netlink">
|
|
netlink</A> interface between kernel code and the iproute2(8) command.</DD>
|
|
<DT>IP: kernel level autoconfiguration</DT>
|
|
<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
|
|
entails some risk.</DD>
|
|
<DT>IP: firewall packet netlink device</DT>
|
|
<DD>[disable]</DD>
|
|
<DT>IP: transparent proxy support</DT>
|
|
<DD>[optional] This is required in some firewall configurations, but
|
|
should be disabled unless you have a definite need for it.</DD>
|
|
<DT>IP: masquerading</DT>
|
|
<DD>[optional] Required if you want to use<A href="glossary.html#non-routable">
|
|
non-routable</A> private IP addresses for your local network.</DD>
|
|
<DT>IP: Optimize as router not host</DT>
|
|
<DD>[recommended]</DD>
|
|
<DT>IP: tunneling</DT>
|
|
<DD>[required]</DD>
|
|
<DT>IP: GRE tunnels over IP</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>IP: aliasing support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>IP: ARP daemon support (EXPERIMENTAL)</DT>
|
|
<DD>Not required on most systems, but might prove useful on
|
|
heavily-loaded gateways.</DD>
|
|
<DT>IP: TCP syncookie support</DT>
|
|
<DD>[recommended] It provides a defense against a<A href="glossary.html#DOS">
|
|
denial of service attack</A> which uses bogus TCP connection requests
|
|
to waste resources on the victim machine.</DD>
|
|
<DT>IP: Reverse ARP</DT>
|
|
<DD></DD>
|
|
<DT>IP: large window support</DT>
|
|
<DD>[recommended] unless you have less than 16 meg RAM</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>IPv6</DT>
|
|
<DD>[optional] FreeS/WAN does not currently support IPv6, though work on
|
|
integrating FreeS/WAN with the Linux IPv6 stack has begun.<A href="compat.html#ipv6">
|
|
Details</A>.
|
|
<P> 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<A
|
|
href="mail.html"> mailing list</A>.</P>
|
|
<P> We do not recommend using IPv6 on production FreeS/WAN gateways
|
|
until more testing has been done.</P>
|
|
</DD>
|
|
<DT>Novell IPX</DT>
|
|
<DD>[disable]</DD>
|
|
<DT>Appletalk</DT>
|
|
<DD>[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.
|
|
<P>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.</P>
|
|
</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>Telephony support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>SCSI support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>I2O device support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Network device support</DT>
|
|
<DD>[anything] should work, but there are some points to note.
|
|
<P>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.</P>
|
|
<P>If you disabled experimental drivers in the<A href="#maturity"> Code
|
|
maturity</A> section above, then those drivers will not be shown here.
|
|
Check that option before going off to hunt for missing drivers.</P>
|
|
<P>If you want Linux to automatically find more than one ethernet
|
|
interface at boot time, you need to:</P>
|
|
<UL>
|
|
<LI>compile the appropriate driver(s) into your kernel. Modules will not
|
|
work for this</LI>
|
|
<LI>add a line such as
|
|
<PRE>
|
|
append="ether=0,0,eth0 ether=0,0,eth1"
|
|
</PRE>
|
|
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.</LI>
|
|
<LI>run lilo(8)</LI>
|
|
</UL>
|
|
Having Linux find the cards this way is not necessary, but is usually
|
|
more convenient than loading modules in your boot scripts.</DD>
|
|
<DT>Amateur radio support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>IrDA (infrared) support</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>ISDN subsystem</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Old CDROM drivers</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Character devices</DT>
|
|
<DD>The only required character device is:
|
|
<DL>
|
|
<DT>random(4)</DT>
|
|
<DD>[required] This is a source of<A href="glossary.html#random"> random</A>
|
|
numbers which are required for many cryptographic protocols, including
|
|
several used in IPsec.
|
|
<P>If you are comfortable with C source code, it is likely a good idea
|
|
to go in and adjust the<VAR> #define</VAR> lines in<VAR>
|
|
/usr/src/linux/drivers/char/random.c</VAR> 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).</P>
|
|
</DD>
|
|
</DL>
|
|
</DD>
|
|
<DT>Filesystems</DT>
|
|
<DD>[anything] should work, but we suggest limiting a gateway machine to
|
|
the standard Linux ext2 filesystem in most cases.</DD>
|
|
<DT>Network filesystems</DT>
|
|
<DD>[disable] These systems are an unnecessary risk on an IPsec gateway.</DD>
|
|
<DT>Console drivers</DT>
|
|
<DD>[anything]</DD>
|
|
<DT>Sound</DT>
|
|
<DD>[anything] should work, but we suggest enabling sound only if you
|
|
plan to use audible alarms for firewall problems.</DD>
|
|
<DT>Kernel hacking</DT>
|
|
<DD>[disable] This might be enabled on test machines, but should not be
|
|
on production gateways.</DD>
|
|
</DL>
|
|
</DD>
|
|
</DL>
|
|
<HR>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="testing.html">Previous</A>
|
|
<A HREF="adv_config.html">Next</A>
|
|
</BODY>
|
|
</HTML>
|