[thirdparty/strongswan.git] / doc / kernel.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 &quot;a true
 paranoid&quot;. 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: &quot;I know I'm paranoid. I wonder
 if I'm paranoid enough.&quot;</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>. &quot;If in doubt, leave it out.&quot;</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
 &quot;network device support&quot;. 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 &quot;rootkit&quot;, 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 &quot;own&quot; 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 &gt; /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 &quot;Network firewalls&quot;
 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=&quot;ether=0,0,eth0 ether=0,0,eth1&quot;
</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 &quot;0,0&quot; 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>
Commit	Line	Data
997358a6 MW	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
	2	<HTML>
	3	<HEAD>
	4	<TITLE>Introduction to FreeS/WAN</TITLE>
	5	<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
	6	<STYLE TYPE="text/css"><!--
	7	BODY { font-family: serif }
	8	H1 { font-family: sans-serif }
	9	H2 { font-family: sans-serif }
	10	H3 { font-family: sans-serif }
	11	H4 { font-family: sans-serif }
	12	H5 { font-family: sans-serif }
	13	H6 { font-family: sans-serif }
	14	SUB { font-size: smaller }
	15	SUP { font-size: smaller }
	16	PRE { font-family: monospace }
	17	--></STYLE>
	18	</HEAD>
	19	<BODY>
	20	<A HREF="toc.html">Contents</A>
	21	<A HREF="testing.html">Previous</A>
	22	<A HREF="adv_config.html">Next</A>
	23	<HR>
	24	<H1><A name="kernelconfig">Kernel configuration for FreeS/WAN</A></H1>
	25	<P> This section lists many of the options available when configuring a
	26	Linux kernel, and explains how they should be set on a FreeS/WAN IPsec
	27	gateway.</P>
	28	<H2><A name="notall">Not everyone needs to worry about kernel
	29	configuration</A></H2>
	30	<P>Note that in many cases you do not need to mess with these.</P>
	31	<P> You may have a Linux distribution which comes with FreeS/WAN
	32	installed (see this<A href="intro.html#products"> list</A>). In that
	33	case, you need not do a FreeS/WAN installation or a kernel
	34	configuration. Of course, you might still want to configure and rebuild
	35	your kernel to improve performance or security. This can be done with
	36	standard tools described in the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
	37	Kernel HowTo</A>.</P>
	38	<P>If you need to install FreeS/WAN, then you do need to configure a
	39	kernel. However, you may choose to do that using the simplest
	40	procedure:</P>
	41	<UL>
	42	<LI>Configure, build and test a kernel for your system before adding
	43	FreeS/WAN. See the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
	44	Kernel HowTo</A> for details.<STRONG> This step cannot be skipped</STRONG>
	45	. FreeS/WAN needs the results of your configuration.</LI>
	46	<LI>Then use FreeS/WAN's<VAR> make oldgo</VAR> command. This sets
	47	everything FreeS/WAN needs and retains your values everywhere else.</LI>
	48	</UL>
	49	<P> This document is for those who choose to configure their FreeS/WAN
	50	kernel themselves.</P>
	51	<H2><A name="assume">Assumptions and notation</A></H2>
	52	<P> Help text for most kernel options is included with the kernel files,
	53	and is accessible from within the configuration utilities. We assume
	54	you will refer to that, and to the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
	55	Kernel HowTo</A>, as necessary. This document covers only the
	56	FreeS/WAN-specific aspects of the problem.</P>
	57	<P> To avoid duplication, this document section does not cover settings
	58	for the additional IPsec-related kernel options which become available
	59	after you have patched your kernel with FreeS/WAN patches. There is
	60	help text for those available from within the configuration utility.</P>
	61	<P> We assume a common configuration in which the FreeS/WAN IPsec
	62	gateway is also doing ipchains(8) firewalling for a local network, and
	63	possibly masquerading as well.</P>
	64	<P> Some suggestions below are labelled as appropriate for "a true
65	paranoid". By this we mean they may cause inconvenience and it is not
66	entirely clear they are necessary, but they appear to be the safest
67	choice. Not using them might entail some risk. Of course one suggested
68	mantra for security administrators is: "I know I'm paranoid. I wonder
69	if I'm paranoid enough."</P>
70	<H3><A name="labels">Labels used</A></H3>
71	<P> Six labels are used to indicate how options should be set. We mark
72	the labels with [square brackets]. For two of these labels, you have no
73	choice:</P>
74	<DL>
75	<DT>[required]</DT>
76	<DD>essential for FreeS/WAN operation.</DD>
77	<DT>[incompatible]</DT>
78	<DD>incompatible with FreeS/WAN.</DD>
79	</DL>
80	<P>those must be set correctly or FreeS/WAN will not work</P>
81	<P>FreeS/WAN should work with any settings of the others, though of
82	course not all combinations have been tested. We do label these in
83	various ways, but<EM> these labels are only suggestions</EM>.</P>
84	<DL>
85	<DT>[recommended]</DT>
86	<DD>useful on most FreeS/WAN gateways</DD>
87	<DT>[disable]</DT>
88	<DD>an unwelcome complication on a FreeS/WAN gateway.</DD>
89	<DT>[optional]</DT>
90	<DD>Your choice. We outline issues you might consider.</DD>
91	<DT>[anything]</DT>
92	<DD>This option has no direct effect on FreeS/WAN and related tools, so
93	you should be able to set it as you please.</DD>
94	</DL>
95	<P> Of course complexity is an enemy in any effort to build secure
96	systems.<STRONG> For maximum security, any feature that can reasonably
97	be turned off should be</STRONG>. "If in doubt, leave it out."</P>
98	<H2><A name="kernelopt">Kernel options for FreeS/WAN</A></H2>
99	<P> Indentation is based on the nesting shown by 'make menuconfig' with
100	a 2.2.16 kernel for the i386 architecture.</P>
101	<DL>
102	<DT><A name="maturity">Code maturity and level options</A></DT>
103	<DD>
104	<DL>
105	<DT><A name="devel">Prompt for development ... code/drivers</A></DT>
106	<DD>[optional] If this is<VAR> no</VAR>, experimental drivers are not
107	shown in later menus.
108	<P>For most FreeS/WAN work,<VAR> no</VAR> is the preferred setting.
109	Using new or untested components is too risky for a security gateway.</P>
110	<P>However, for some hardware (such as the author's network cards) the
111	only drivers available are marked<VAR> new/experimental</VAR>. In such
112	cases, you must enable this option or your cards will not appear under
113	"network device support". A true paranoid would leave this option off
114	and replace the cards.</P>
115	</DD>
116	<DT>Processor type and features</DT>
117	<DD>[anything]</DD>
118	<DT>Loadable module support</DT>
119	<DD>
120	<DL>
121	<DT>Enable loadable module support</DT>
122	<DD>[optional] A true paranoid would disable this. An attacker who has
123	root access to your machine can fairly easily install a bogus module
124	that does awful things, provided modules are enabled. A common tool for
125	attackers is a "rootkit", a set of tools the attacker uses once he or
126	she has become root on your system. The kit introduces assorted
127	additional compromises so that the attacker will continue to "own" your
128	system despite most things you might do to recovery the situation. For
129	Linux, there is a tool called<A href="http://www.sans.org/newlook/resources/IDFAQ/knark.htm">
130	knark</A> which is basically a rootkit packaged as a kernel module.
131	<P>With modules disabled, an attacker cannot install a bogus module. The
132	only way he can achieve the same effects is to install a new kernel and
133	reboot. This is considerably more likely to be noticed.</P>
134	<P>Many FreeS/WAN gateways run with modules enabled. This simplifies
135	some administrative tasks and some ipchains features are available only
136	as modules. Once an enemy has root on your machine your security is
137	nil, so arguably defenses which come into play only in that situation
138	are pointless.</P>
139	<P></P>
140	</DD>
141	<DT>Set version information ....</DT>
142	<DD>[optional] This provides a check to prevent loading modules compiled
143	for a different kernel.</DD>
144	<DT>Kernel module loader</DT>
145	<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
146	entails some risk.</DD>
147	</DL>
148	</DD>
149	<DT>General setup</DT>
150	<DD>We list here only the options that matter for FreeS/WAN.
151	<DL>
152	<DT>Networking support</DT>
153	<DD>[required]</DD>
154	<DT>Sysctl interface</DT>
155	<DD>[optional] If this option is turned on and the<VAR> /proc</VAR>
156	filesystem installed, then you can control various system behaviours by
157	writing to files under<VAR> /proc/sys</VAR>. For example:
158	<PRE> echo 1 > /proc/sys/net/ipv4/ipforward</PRE>
159	turns IP forwarding on.
160	<P>Disabling this option breaks many firewall scripts. A true paranoid
161	would disable it anyway since it might conceivably be of use to an
162	attacker.</P>
163	</DD>
164	</DL>
165	</DD>
166	<DT>Plug and Play support</DT>
167	<DD>[anything]</DD>
168	<DT>Block devices</DT>
169	<DD>[anything]</DD>
170	<DT>Networking options</DT>
171	<DD>
172	<DL>
173	<DT>Packet socket</DT>
174	<DD>[optional] This kernel feature supports tools such as tcpdump(8)
175	which communicate directly with network hardware, bypassing kernel
176	protocols. This is very much a two-edged sword:
177	<UL>
178	<LI>such tools can be very useful to the firewall admin, especially
179	during initial testing</LI>
180	<LI>should an evildoer breach your firewall, such tools could give him
181	or her a great deal of information about the rest of your network</LI>
182	</UL>
183	We recommend disabling this option on production gateways.</DD>
184	<DT><A name="netlink">Kernel/User netlink socket</A></DT>
185	<DD>[optional] Required if you want to use<A href="#adv"> advanced
186	router</A> features.</DD>
187	<DT>Routing messages</DT>
188	<DD>[optional]</DD>
189	<DT>Netlink device emulation</DT>
190	<DD>[optional]</DD>
191	<DT>Network firewalls</DT>
192	<DD>[recommended] You need this if the IPsec gateway also functions as a
193	firewall.
194	<P>Even if the IPsec gateway is not your primary firewall, we suggest
195	setting this so that you can protect the gateway with at least basic
196	local packet filters.</P>
197	</DD>
198	<DT>Socket filtering</DT>
199	<DD>[disable] This enables an older filtering interface. We suggest
200	using ipchains(8) instead. To do that, set the "Network firewalls"
201	option just above, and not this one.</DD>
202	<DT>Unix domain sockets</DT>
203	<DD>[required] These sockets are used for communication between the<A href="manpage.d/ipsec.8.html">
204	ipsec(8)</A> commands and the<A href="manpage.d/ipsec_pluto.8.html">
205	ipsec_pluto(8)</A> daemon.</DD>
206	<DT>TCP/IP networking</DT>
207	<DD>[required]
208	<DL>
209	<DT>IP: multicasting</DT>
210	<DD>[anything]</DD>
211	<DT><A name="adv">IP: advanced router</A></DT>
212	<DD>[optional] This gives you policy routing, which some people have
213	used to good advantage in their scripts for FreeS/WAN gateway
214	management. It is not used in our distributed scripts, so not required
215	unless you want it for custom scripts. It requires the<A href="#netlink">
216	netlink</A> interface between kernel code and the iproute2(8) command.</DD>
217	<DT>IP: kernel level autoconfiguration</DT>
218	<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
219	entails some risk.</DD>
220	<DT>IP: firewall packet netlink device</DT>
221	<DD>[disable]</DD>
222	<DT>IP: transparent proxy support</DT>
223	<DD>[optional] This is required in some firewall configurations, but
224	should be disabled unless you have a definite need for it.</DD>
225	<DT>IP: masquerading</DT>
226	<DD>[optional] Required if you want to use<A href="glossary.html#non-routable">
227	non-routable</A> private IP addresses for your local network.</DD>
228	<DT>IP: Optimize as router not host</DT>
229	<DD>[recommended]</DD>
230	<DT>IP: tunneling</DT>
231	<DD>[required]</DD>
232	<DT>IP: GRE tunnels over IP</DT>
233	<DD>[anything]</DD>
234	<DT>IP: aliasing support</DT>
235	<DD>[anything]</DD>
236	<DT>IP: ARP daemon support (EXPERIMENTAL)</DT>
237	<DD>Not required on most systems, but might prove useful on
238	heavily-loaded gateways.</DD>
239	<DT>IP: TCP syncookie support</DT>
240	<DD>[recommended] It provides a defense against a<A href="glossary.html#DOS">
241	denial of service attack</A> which uses bogus TCP connection requests
242	to waste resources on the victim machine.</DD>
243	<DT>IP: Reverse ARP</DT>
244	<DD></DD>
245	<DT>IP: large window support</DT>
246	<DD>[recommended] unless you have less than 16 meg RAM</DD>
247	</DL>
248	</DD>
249	<DT>IPv6</DT>
250	<DD>[optional] FreeS/WAN does not currently support IPv6, though work on
251	integrating FreeS/WAN with the Linux IPv6 stack has begun.<A href="compat.html#ipv6">
252	Details</A>.
253	<P> It should be possible to use IPv4 FreeS/WAN on a machine which also
254	does IPv6. This combination is not yet well tested. We would be quite
255	interested in hearing results from anyone expermenting with it, via the<A
256	href="mail.html"> mailing list</A>.</P>
257	<P> We do not recommend using IPv6 on production FreeS/WAN gateways
258	until more testing has been done.</P>
259	</DD>
260	<DT>Novell IPX</DT>
261	<DD>[disable]</DD>
262	<DT>Appletalk</DT>
263	<DD>[disable] Quite a few Linux installations use IP but also have some
264	other protocol, such as Appletalk or IPX, for communication with local
265	desktop machines. In theory it should be possible to configure IPsec
266	for the IP side of things without interfering with the second protocol.
267	<P>We do not recommend this. Keep the software on your gateway as simple
268	as possible. If you need a Linux-based Appletalk or IPX server, use a
269	separate machine.</P>
270	</DD>
271	</DL>
272	</DD>
273	<DT>Telephony support</DT>
274	<DD>[anything]</DD>
275	<DT>SCSI support</DT>
276	<DD>[anything]</DD>
277	<DT>I2O device support</DT>
278	<DD>[anything]</DD>
279	<DT>Network device support</DT>
280	<DD>[anything] should work, but there are some points to note.
281	<P>The development team test almost entirely on 10 or 100 megabit
282	Ethernet and modems. In principle, any device that can do IP should be
283	just fine for IPsec, but in the real world any device that has not been
284	well-tested is somewhat risky. By all means try it, but don't bet your
285	project on it until you have solid test results.</P>
286	<P>If you disabled experimental drivers in the<A href="#maturity"> Code
287	maturity</A> section above, then those drivers will not be shown here.
288	Check that option before going off to hunt for missing drivers.</P>
289	<P>If you want Linux to automatically find more than one ethernet
290	interface at boot time, you need to:</P>
291	<UL>
292	<LI>compile the appropriate driver(s) into your kernel. Modules will not
293	work for this</LI>
294	<LI>add a line such as
295	<PRE>
296	append="ether=0,0,eth0 ether=0,0,eth1"
297	</PRE>
298	to your /etc/lilo.conf file. In some cases you may need to specify
299	parameters such as IRQ or base address. The example uses "0,0" for
300	these, which tells the system to search. If the search does not succeed
301	on your hardware, then you should retry with explicit parameters. See
302	the lilo.conf(5) man page for details.</LI>
303	<LI>run lilo(8)</LI>
304	</UL>
305	Having Linux find the cards this way is not necessary, but is usually
306	more convenient than loading modules in your boot scripts.</DD>
307	<DT>Amateur radio support</DT>
308	<DD>[anything]</DD>
309	<DT>IrDA (infrared) support</DT>
310	<DD>[anything]</DD>
311	<DT>ISDN subsystem</DT>
312	<DD>[anything]</DD>
313	<DT>Old CDROM drivers</DT>
314	<DD>[anything]</DD>
315	<DT>Character devices</DT>
316	<DD>The only required character device is:
317	<DL>
318	<DT>random(4)</DT>
319	<DD>[required] This is a source of<A href="glossary.html#random"> random</A>
320	numbers which are required for many cryptographic protocols, including
321	several used in IPsec.
322	<P>If you are comfortable with C source code, it is likely a good idea
323	to go in and adjust the<VAR> #define</VAR> lines in<VAR>
324	/usr/src/linux/drivers/char/random.c</VAR> to ensure that all sources
325	of randomness are enabled. Relying solely on keyboard and mouse
326	randomness is dubious procedure for a gateway machine. You could also
327	increase the randomness pool size from the default 512 bytes (128
328	32-bit words).</P>
329	</DD>
330	</DL>
331	</DD>
332	<DT>Filesystems</DT>
333	<DD>[anything] should work, but we suggest limiting a gateway machine to
334	the standard Linux ext2 filesystem in most cases.</DD>
335	<DT>Network filesystems</DT>
336	<DD>[disable] These systems are an unnecessary risk on an IPsec gateway.</DD>
337	<DT>Console drivers</DT>
338	<DD>[anything]</DD>
339	<DT>Sound</DT>
340	<DD>[anything] should work, but we suggest enabling sound only if you
341	plan to use audible alarms for firewall problems.</DD>
342	<DT>Kernel hacking</DT>
343	<DD>[disable] This might be enabled on test machines, but should not be
344	on production gateways.</DD>
345	</DL>
346	</DD>
347	</DL>
348	<HR>
349	<A HREF="toc.html">Contents</A>
350	<A HREF="testing.html">Previous</A>
351	<A HREF="adv_config.html">Next</A>
352	</BODY>
353	</HTML>