freeswan/doc/src/kernel.html

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