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