[people/ms/strongswan.git] / doc / src / kernel.html

<html>
<head>
<title>Kernel configuration for FreeS/WAN</title>
<meta name="keywords" content="Linux, IPsec, VPN, security, FreeSWAN, kernel">

<!--

Written by Sandy Harris for the Linux FreeS/WAN project
Freely distributable under the GNU General Public License

More information at www.freeswan.org
Feedback to users@lists.freeswan.org

CVS information:
RCS ID:          $Id: kernel.html,v 1.1 2004/03/15 20:35:24 as Exp $
Last changed:    $Date: 2004/03/15 20:35:24 $
Revision number: $Revision: 1.1 $

CVS revision numbers do not correspond to FreeS/WAN release numbers.
-->
</head>

<body>

<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 &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>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>
             
            </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>
              We do not recommend using IPv6 on production FreeS/WAN gateways until
              more testing has been done.
              </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 &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>
     <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>
  </dl>
</body>
</html>
Commit	Line	Data
997358a6 MW	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.1 2004/03/15 20:35:24 as Exp $
	16	Last changed: $Date: 2004/03/15 20:35:24 $
	17	Revision number: $Revision: 1.1 $
	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 "network device
141	support". 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 "rootkit", 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 "own" 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 > /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 "Network
234	firewalls" 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 "0,0"
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>