diff options
Diffstat (limited to 'doc/src/firewall.html')
| -rw-r--r-- | doc/src/firewall.html | 895 |
1 files changed, 0 insertions, 895 deletions
diff --git a/doc/src/firewall.html b/doc/src/firewall.html deleted file mode 100644 index 5051b458d..000000000 --- a/doc/src/firewall.html +++ /dev/null @@ -1,895 +0,0 @@ -<html> -<head> - <meta http-equiv="Content-Type" content="text/html"> - <title>FreeS/WAN and firewalls</title> - <meta name="keywords" - content="Linux, IPsec, VPN, security, FreeSWAN, firewall, ipchains, iptables"> - <!-- - - 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: firewall.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="firewall">FreeS/WAN and firewalls</a></h1> - -<p>FreeS/WAN, or other IPsec implementations, frequently run on gateway -machines, the same machines running firewall or packet filtering code. This -document discusses the relation between the two.</p> - -<p>The firewall code in 2.4 and later kernels is called Netfilter. The -user-space utility to manage a firewall is iptables(8). See the <a -href="http://netfilter.samba.org">netfilter/iptables web site</a> for -details.</p> - -<h2><a name="filters">Filtering rules for IPsec packets</a></h2> - -<p>The basic constraint is that <strong>an IPsec gateway must have packet -filters that allow IPsec packets</strong>, at least when talking to other -IPsec gateways:</p> -<ul> - <li>UDP port 500 for <a href="glossary.html#IKE">IKE</a> negotiations</li> - <li>protocol 50 if you use <a href="glossary.html#ESP">ESP</a> encryption - and/or authentication (the typical case)</li> - <li>protocol 51 if you use <a href="glossary.html#AH">AH</a> packet-level - authentication</li> -</ul> - -<p>Your gateway and the other IPsec gateways it communicates with must be -able to exchange these packets for IPsec to work. Firewall rules must allow -UDP 500 and at least one of <a href="glossary.html#AH">AH</a> or -<a href="glossary.html#ESP">ESP</a> on -the interface that communicates with the other gateway.</p> - -<p>For nearly all FreeS/WAN applications, you must allow UDP port 500 and the -ESP protocol.</p> - -<p>There are two ways to set this up:</p> -<dl> - <dt>easier but less flexible</dt> - <dd>Just set up your firewall scripts at boot time to allow IPsec packets - to and from your gateway. Let FreeS/WAN reject any bogus packets.</dd> - <dt>more work, giving you more precise control</dt> - <dd>Have the <a href="manpage.d/ipsec_pluto.8.html">ipsec_pluto(8)</a> - daemon call scripts to adjust firewall rules dynamically as required. - This is done by naming the scripts in the <a - href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> variables - <var>prepluto=</var>, <var>postpluto=</var>, <var>leftupdown=</var> and - <var>rightupdown=</var>.</dd> -</dl> - -<p>Both methods are described in more detail below.</p> - -<h2><a name="examplefw">Firewall configuration at boot</a></h2> - -<p>It is possible to set up both firewalling and IPsec with appropriate -scripts at boot and then not use <var>leftupdown=</var> and -<var>rightupdown=</var>, or use them only for simple up and down -operations.</p> - -<p>Basically, the technique is</p> -<ul> - <li>allow IPsec packets (typically, IKE on UDP port 500 plus ESP, protocol - 50) - <ul> - <li>incoming, if the destination address is your gateway (and - optionally, only from known senders)</li> - <li>outgoing, with the from address of your gateway (and optionally, - only to known receivers)</li> - </ul> - </li> - <li>let <a href="glossary.html#Pluto">Pluto</a> deal with IKE</li> - <li>let <a href="glossary.html#KLIPS">KLIPS</a> deal with ESP</li> -</ul> - -<p>Since Pluto authenticates its partners during the negotiation, and KLIPS -drops packets for which no tunnel has been negotiated, this may be all you -need.</p> - -<h3><a name="simple.rules">A simple set of rules</a></h3> - -<p>In simple cases, you need only a few rules, as in this example:</p> -<pre># allow IPsec -# -# IKE negotiations -iptables -I INPUT -p udp --sport 500 --dport 500 -j ACCEPT -iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT -# ESP encryption and authentication -iptables -I INPUT -p 50 -j ACCEPT -iptables -I OUTPUT -p 50 -j ACCEPT -</pre> - -<P>This should be all you need to allow IPsec through <var>lokkit</var>, -which ships with Red Hat 9, on its medium security setting. -Once you've tweaked to your satisfaction, save your active rule set with:</P> -<PRE>service iptables save</PRE> - -<h3><a name="complex.rules">Other rules</a></h3> -You can add additional rules, or modify existing ones, to work with IPsec and -with your network and policies. We give a some examples in this section. - -<p>However, while it is certainly possible to create an elaborate set of -rules yourself (please let us know via the <a href="mail.html">mailing -list</a> if you do), it may be both easier and more secure to use a set which -has already been published and tested.</p> - -<p>The published rule sets we know of are described in the <a -href="#rules.pub">next section</a>.</p> - -<h4>Adding additional rules</h4> -If necessary, you can add additional rules to: -<dl> - <dt>reject IPsec packets that are not to or from known gateways</dt> - <dd>This possibility is discussed in more detail <a - href="#unknowngate">later</a></dd> - <dt>allow systems behind your gateway to build IPsec tunnels that pass - through the gateway</dt> - <dd>This possibility is discussed in more detail <a - href="#through">later</a></dd> - <dt>filter incoming packets emerging from KLIPS.</dt> - <dd>Firewall rules can recognise packets emerging from IPsec. They are - marked as arriving on an interface such as <var>ipsec0</var>, rather - than <var>eth0</var>, <var>ppp0</var> or whatever.</dd> -</dl> - -<p>It is therefore reasonably straightforward to filter these packets in -whatever way suits your situation.</p> - -<h4>Modifying existing rules</h4> - -<p>In some cases rules that work fine before you add IPsec may require -modification to work with IPsec.</p> - -<p>This is especially likely for rules that deal with interfaces on the -Internet side of your system. IPsec adds a new interface; often the rules -must change to take account of that.</p> - -<p>For example, consider the rules given in <a -href="http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-5.html">this -section</a> of the Netfilter documentation:</p> -<pre>Most people just have a single PPP connection to the Internet, and don't -want anyone coming back into their network, or the firewall: - - ## Insert connection-tracking modules (not needed if built into kernel). - # insmod ip_conntrack - # insmod ip_conntrack_ftp - - ## Create chain which blocks new connections, except if coming from inside. - # iptables -N block - # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT - # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT - # iptables -A block -j DROP - - ## Jump to that chain from INPUT and FORWARD chains. - # iptables -A INPUT -j block - # iptables -A FORWARD -j block</pre> - -<p>On an IPsec gateway, those rules may need to be modified. The above allows -new connections from <em>anywhere except ppp0</em>. That means new -connections from ipsec0 are allowed.</p> - -<p>Do you want to allow anyone who can establish an IPsec connection to your -gateway to initiate TCP connections to any service on your network? Almost -certainly not if you are using opportunistic encryption. Quite possibly not -even if you have only explicitly configured connections.</p> - -<p>To disallow incoming connections from ipsec0, change the middle section -above to:</p> -<pre> ## Create chain which blocks new connections, except if coming from inside. - # iptables -N block - # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT - # iptables -A block -m state --state NEW -i ppp+ -j DROP - # iptables -A block -m state --state NEW -i ipsec+ -j DROP - # iptables -A block -m state --state NEW -i -j ACCEPT - # iptables -A block -j DROP</pre> - -<p>The original rules accepted NEW connections from anywhere except ppp0. -This version drops NEW connections from any PPP interface (ppp+) and from any -ipsec interface (ipsec+), then accepts the survivors.</p> - -<p>Of course, these are only examples. You will need to adapt them to your -own situation.</p> - -<h3><a name="rules.pub">Published rule sets</a></h3> - -<p>Several sets of firewall rules that work with FreeS/WAN are available.</p> - -<h4><a name="Ranch.trinity">Scripts based on Ranch's work</a></h4> - -<p>One user, Rob Hutton, posted his boot time scripts to the mailing list, -and we included them in previous versions of this documentation. They are -still available from our <a -href="http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/firewall.html#examplefw">web -site</a>. However, they were for an earlier FreeS/WAN version so we no longer -recommend them. Also, they had some bugs. See this <a -href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/04/msg00316.html">message</a>.</p> - -<p>Those scripts were based on David Ranch's scripts for his "Trinity OS" for -setting up a secure Linux. Check his <a -href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html">home -page</a> for the latest version and for information on his <a -href="biblio.html#ranch">book</a> on securing Linux. If you are going to base -your firewalling on Ranch's scripts, we recommend using his latest version, -and sending him any IPsec modifications you make for incorporation into later -versions.</p> - -<h4><a name="seawall">The Seattle firewall</a></h4> - -<p>We have had several mailing lists reports of good results using FreeS/WAN -with Seawall (the Seattle Firewall). See that project's <a -href="http://seawall.sourceforge.net/">home page</a> on Sourceforge.</p> - -<h4><a name="rcf">The RCF scripts</a></h4> - -<p>Another set of firewall scripts with IPsec support are the RCF or -rc.firewall scripts. See their <a -href="http://jsmoriss.mvlan.net/linux/rcf.html">home page</a>.</p> - -<h4><a name="asgard">Asgard scripts</a></h4> - -<p><a href="http://heimdall.asgardsrealm.net/linux/firewall/">Asgard's -Realm</a> has set of firewall scripts with FreeS/WAN support, for 2.4 kernels -and iptables.</p> - -<h4><a name="user.scripts">User scripts from the mailing list</a></h4> - -<p>One user gave considerable detail on his scripts, including supporting <a -href="glossary.html#IPX">IPX</a> through the tunnel. His message was too long -to conveniently be quoted here, so I've put it in a <a -href="user_examples.html">separate file</a>.</p> - -<h2><a name="updown">Calling firewall scripts, named in ipsec.conf(5)</a></h2> - -<p>The <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> configuration -file has three pairs of parameters used to specify an interface between -FreeS/WAN and firewalling code.</p> - -<p>Note that using these is not required if you have a static firewall setup. -In that case, you just set your firewall up at boot time (in a way that -permits the IPsec connections you want) and do not change it thereafter. Omit -all the FreeS/WAN firewall parameters and FreeS/WAN will not attempt to -adjust firewall rules at all. See <a href="#examplefw">above</a> for some -information on appropriate scripts.</p> - -<p>However, if you want your firewall rules to change when IPsec connections -change, then you need to use these parameters.</p> - -<h3><a name="pre_post">Scripts called at IPsec start and stop</a></h3> - -<p>One pair of parmeters are set in the <var>config setup</var> section of -the <a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> file and affect -all connections:</p> -<dl> - <dt>prepluto=</dt> - <dd>script to be called before <a - href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> IKE daemon is - started.</dd> - <dt>postpluto=</dt> - <dd>script to be called after <a - href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> IKE daemon is - stopped.</dd> -</dl> -These parameters allow you to change firewall parameters whenever IPsec is -started or stopped. - -<p>They can also be used in other ways. For example, you might have -<var>prepluto</var> add a module to your kernel for the secure network -interface or make a dialup connection, and then have <var>postpluto</var> -remove the module or take the connection down.</p> - -<h3><a name="up_down">Scripts called at connection up and down</a></h3> - -<p>The other parameters are set in connection descriptions. They can be set -in individual connection descriptions, and could even call different scripts -for each connection for maximum flexibility. In most applications, however, -it makes sense to use only one script and to call it from <var>conn -%default</var> section so that it applies to all connections.</p> - -<p>You can:</p> -<dl> - <dt><strong>either</strong></dt> - <dd>set <var>leftfirewall=yes</var> or <var>rightfirewall=yes</var> to - use our supplied default script</dd> - <dt><strong>or</strong></dt> - <dd>assign a name in a <var>leftupdown=</var> or <var>rightupdown=</var> - line to use your own script</dd> -</dl> - -<p>Note that <strong>only one of these should be used</strong>. You cannot -sensibly use both. Since <strong>our default script is obsolete</strong> -(designed for firewalls using <var>ipfwadm(8)</var> on 2.0 kernels), most -users who need this service will <strong>need to write a custom -script</strong>.</p> - -<h4><a name="fw.default">The default script</a></h4> - -<p>We supply a default script named <var>_updown</var>.</p> -<dl> - <dt>leftfirewall=</dt> - <dd></dd> - <dt>rightfirewall=</dt> - <dd>indicates that the gateway is doing firewalling and that <a - href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> should poke holes in - the firewall as required.</dd> -</dl> - -<p>Set these to <var>yes</var> and Pluto will call our default script -<var>_updown</var> with appropriate arguments whenever it:</p> -<ul> - <li>starts or stops IPsec services</li> - <li>brings a connection up or down</li> -</ul> - -<p>The supplied default <var>_updown</var> script is appropriate for simple -cases using the <var>ipfwadm(8)</var> firewalling package.</p> - -<h4><a name="userscript">User-written scripts</a></h4> - -<p>You can also write your own script and have Pluto call it. Just put the -script's name in one of these <a -href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> lines:</p> -<dl> - <dt>leftupdown=</dt> - <dd></dd> - <dt>rightupdown=</dt> - <dd>specifies a script to call instead of our default script - <var>_updown</var>.</dd> -</dl> - -<p>Your script should take the same arguments and use the same environment -variables as <var>_updown</var>. See the "updown command" section of the <a -href="manpage.d/ipsec_pluto.8.html">ipsec_pluto(8)</a> man page for -details.</p> - -<p>Note that <strong>you should not modify our _updown script in -place</strong>. If you did that, then upgraded FreeS/WAN, the upgrade would -install a new default script, overwriting your changes.</p> - -<h3><a name="ipchains.script">Scripts for ipchains or iptables</a></h3> - -<p>Our <var>_updown</var> is for firewalls using <var>ipfwadm(8)</var>, the -firewall code for the 2.0 series of Linux kernels. If you are using the more -recent packages <var>ipchains(8)</var> (for 2.2 kernels) or -<var>iptables(8)</var> (2.4 kernels), then you must do one of:</p> -<ul> - <li>use static firewall rules which are set up at boot time as described <a - href="#examplefw">above</a> and do not need to be changed by Pluto</li> - <li>limit yourself to ipchains(8)'s ipfwadm(8) emulation mode in order to - use our script</li> - <li>write your own script and call it with <var>leftupdown</var> and - <var>rightupdown</var>.</li> -</ul> - -<p>You can write a script to do whatever you need with firewalling. Specify -its name in a <var>[left|right]updown=</var> parameter in <a -href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> and Pluto will -automatically call it for you.</p> - -<p>The arguments Pluto passes such a script are the same ones it passes to -our default _updown script, so the best way to build yours is to copy ours -and modify the copy.</p> - -<p>Note, however, that <strong>you should not modify our _updown script in -place</strong>. If you did that, then upgraded FreeS/WAN, the upgrade would -install a new default script, overwriting your changes.</p> - -<h2><a name="NAT">A complication: IPsec vs. NAT</a></h2> - -<p><a href="glossary.html#NAT.gloss">Network Address Translation</a>, also -known as IP masquerading, is a method of allocating IP addresses dynamically, -typically in circumstances where the total number of machines which need to -access the Internet exceeds the supply of IP addresses.</p> - -<p>Any attempt to perform NAT operations on IPsec packets <em>between the -IPsec gateways</em> creates a basic conflict:</p> -<ul> - <li>IPsec wants to authenticate packets and ensure they are unaltered on a - gateway-to-gateway basis</li> - <li>NAT rewrites packet headers as they go by</li> - <li>IPsec authentication fails if packets are rewritten anywhere between - the IPsec gateways</li> -</ul> - -<p>For <a href="glossary.html#AH">AH</a>, which authenticates parts of the -packet header including source and destination IP addresses, this is fatal. -If NAT changes those fields, AH authentication fails.</p> - -<p>For <a href="glossary.html#IKE">IKE</a> and <a -href="glossary.html#ESP">ESP</a> it is not necessarily fatal, but is -certainly an unwelcome complication.</p> - -<h3><a name="nat_ok">NAT on or behind the IPsec gateway works</a></h3> - -<p>This problem can be avoided by having the masquerading take place <em>on -or behind</em> the IPsec gateway.</p> - -<p>This can be done physically with two machines, one physically behind the -other. A picture, using SG to indicate IPsec <strong>S</strong>ecurity -<strong>G</strong>ateways, is:</p> -<pre> clients --- NAT ----- SG ---------- SG - two machines</pre> - -<p>In this configuration, the actual client addresses need not be given in -the <var>leftsubnet=</var> parameter of the FreeS/WAN connection description. -The security gateway just delivers packets to the NAT box; it needs only that -machine's address. What that machine does with them does not affect -FreeS/WAN.</p> - -<p>A more common setup has one machine performing both functions:</p> -<pre> clients ----- NAT/SG ---------------SG - one machine</pre> - -<p>Here you have a choice of techniques depending on whether you want to make -your client subnet visible to clients on the other end:</p> -<ul> - <li>If you want the single gateway to behave like the two shown above, with - your clients hidden behind the NAT, then omit the <var>leftsubnet=</var> - parameter. It then defaults to the gateway address. Clients on the other - end then talk via the tunnel only to your gateway. The gateway takes - packets emerging from the tunnel, applies normal masquerading, and - forwards them to clients.</li> - <li>If you want to make your client machines visible, then give the client - subnet addresses as the <var>leftsubnet=</var> parameter in the - connection description and - <dl> - <dt>either</dt> - <dd>set <var>leftfirewall=yes</var> to use the default - <var>updown</var> script</dd> - <dt>or</dt> - <dd>use your own script by giving its name in a - <var>leftupdown=</var> parameter</dd> - </dl> - These scripts are described in their own <a href="#updown">section</a>. - <p>In this case, no masquerading is done. Packets to or from the client - subnet are encrypted or decrypted without any change to their client - subnet addresses, although of course the encapsulating packets use - gateway addresses in their headers. Clients behind the right security - gateway see a route via that gateway to the left subnet.</p> - </li> -</ul> - -<h3><a name="nat_bad">NAT between gateways is problematic</a></h3> - -<p>We recommend not trying to build IPsec connections which pass through a -NAT machine. This setup poses problems:</p> -<pre> clients --- SG --- NAT ---------- SG</pre> - -<p>If you must try it, some references are:</p> -<ul> - <li>Jean_Francois Nadeau's document on doing <a - href="http://jixen.tripod.com/#NATed gateways">IPsec behind NAT</a></li> - <li><a href="web.html#VPN.masq">VPN masquerade patches</a> to make a Linux - NAT box handle IPsec packets correctly</li> -</ul> - -<h3><a name="NAT.ref">Other references on NAT and IPsec</a></h3> - -<p>Other documents which may be relevant include:</p> -<ul> - <li>an Internet Draft on <a - href="http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-04.txt">IPsec - and NAT</a> which may eventually evolve into a standard solution for this - problem.</li> - <li>an informational <a - href="http://www.cis.ohio-state.edu/rfc/rfc2709.txt">RFC</a>, - <cite>Security Model with Tunnel-mode IPsec for NAT Domains</cite>.</li> - <li>an <a - href="http://www.cisco.com/warp/public/759/ipj_3-4/ipj_3-4_nat.html">article</a> - in Cisco's <cite>Internet Protocol Journal</cite></li> -</ul> - -<h2><a name="complications">Other complications</a></h2> - -<p>Of course simply allowing UDP 500 and ESP packets is not the whole story. -Various other issues arise in making IPsec and packet filters co-exist and -even co-operate. Some of them are summarised below.</p> - -<h3><a name="through">IPsec <em>through</em></a> the gateway</h3> - -<p>Basic IPsec packet filtering rules deal only with packets addressed to or -sent from your IPsec gateway.</p> - -<p>It is a separate policy decision whether to permit such packets to pass -through the gateway so that client machines can build end-to-end IPsec -tunnels of their own. This may not be practical if you are using <a -href="#NAT">NAT (IP masquerade)</a> on your gateway, and may conflict with -some corporate security policies.</p> - -<p>Where possible, allowing this is almost certainly a good idea. Using IPsec -on an end-to-end basis is more secure than gateway-to-gateway.</p> - -<p>Doing it is quite simple. You just need firewall rules that allow UDP port -500 and protocols 50 and 51 to pass through your gateway. If you wish, you -can of course restrict this to certain hosts.</p> - -<h3><a name="ipsec_only">Preventing non-IPsec traffic</a></h3> -You can also filter <em>everything but</em> UDP port 500 and ESP or AH to -restrict traffic to IPsec only, either for anyone communicating with your -host or just for specific partners. - -<p>One application of this is for the telecommuter who might have:</p> -<pre> Sunset==========West------------------East ================= firewall --- the Internet - home network untrusted net corporate network</pre> - -<p>The subnet on the right is 0.0.0.0/0, the whole Internet. The West gateway -is set up so that it allows only IPsec packets to East in or out.</p> - -<p>This configuration is used in AT&T Research's network. For details, -see the <a href="intro.html#applied">papers</a> links in our introduction.</p> - -<p>Another application would be to set up firewall rules so that an internal -machine, such as an employees-only web server, could not talk to the outside -world except via specific IPsec tunnels.</p> - -<h3><a name="unknowngate">Filtering packets from unknown gateways</a></h3> - -<p>It is possible to use firewall rules to restrict UDP 500, ESP and AH -packets so that these packets are accepted only from known gateways. This is -not strictly necessary since FreeS/WAN will discard packets from unknown -gateways. You might, however, want to do it for any of a number of reasons. -For example:</p> -<ul> - <li>Arguably, "belt and suspenders" is the sensible approach to security. - If you can block a potential attack in two ways, use both. The only - question is whether to look for a third way after implementing the first - two.</li> - <li>Some admins may prefer to use the firewall code this way because they - prefer firewall logging to FreeS/WAN's logging.</li> - <li>You may need it to implement your security policy. Consider an employee - working at home, and a policy that says traffic from the home system to - the Internet at large must go first via IPsec to the corporate LAN and - then out to the Internet via the corporate firewall. One way to do that - is to make <var>ipsec0</var> the default route on the home gateway and - provide exceptions only for UDP 500 and ESP to the corporate gateway. - Everything else is then routed via the tunnel to the corporate - gateway.</li> -</ul> - -<p>It is not possible to use only static firewall rules for this filtering if -you do not know the other gateways' IP addresses in advance, for example if -you have "road warriors" who may connect from a different address each time -or if want to do <a href="glossary.html#carpediem">opportunistic -encryption</a> to arbitrary gateways. In these cases, you can accept UDP 500 -IKE packets from anywhere, then use the <a href="#updown">updown</a> script -feature of <a href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> to dynamically -adjust firewalling for each negotiated tunnel.</p> - -<p>Firewall packet filtering does not much reduce the risk of a <a -href="glossary.html#DOS">denial of service attack</a> on FreeS/WAN. The -firewall can drop packets from unknown gateways, but KLIPS does that quite -efficiently anyway, so you gain little. The firewall cannot drop otherwise -legitmate packets that fail KLIPS authentication, so it cannot protect -against an attack designed to exhaust resources by making FreeS/WAN perform -many expensive authentication operations.</p> - -<p>In summary, firewall filtering of IPsec packets from unknown gateways is -possible but not strictly necessary.</p> - -<h2><a name="otherfilter">Other packet filters</a></h2> - -<p>When the IPsec gateway is also acting as your firewall, other packet -filtering rules will be in play. In general, those are outside the scope of -this document. See our <a href="web.html#firewall.linux">Linux firewall -links</a> for information. There are a few types of packet, however, which -can affect the operation of FreeS/WAN or of diagnostic tools commonly used -with it. These are discussed below.</p> - -<h3><a name="ICMP">ICMP filtering</a></h3> - -<p><a href="glossary.html#ICMP.gloss">ICMP</a> is the -<strong>I</strong>nternet <strong>C</strong>ontrol <strong>M</strong>essage -<strong>P</strong>rotocol. It is used for messages between IP implementations -themselves, whereas IP used is used between the clients of those -implementations. ICMP is, unsurprisingly, used for control messages. For -example, it is used to notify a sender that a desination is not reachable, or -to tell a router to reroute certain packets elsewhere.</p> - -<p>ICMP handling is tricky for firewalls.</p> -<ul> - <li>You definitely want some ICMP messages to get through; things won't - work without them. For example, your clients need to know if some - destination they ask for is unreachable.</li> - <li>On the other hand, you do equally definitely do not want untrusted folk - sending arbitrary control messages to your machines. Imagine what someone - moderately clever and moderately malicious could do to you, given control - of your network's routing.</li> -</ul> - -<p>ICMP does not use ports. Messages are distinguished by a "message type" -field and, for some types, by an additional "code" field. The definitive list -of types and codes is on the <a href="http://www.iana.org">IANA</a> site.</p> - -<p>One expert uses this definition for ICMP message types to be dropped at -the firewall.</p> -<pre># ICMP types which lack socially redeeming value. -# 5 Redirect -# 9 Router Advertisement -# 10 Router Selection -# 15 Information Request -# 16 Information Reply -# 17 Address Mask Request -# 18 Address Mask Reply - -badicmp='5 9 10 15 16 17 18'</pre> - -<p>A more conservative approach would be to make a list of allowed types and -drop everything else.</p> - -<p>Whichever way you do it, your ICMP filtering rules on a FreeS/WAN gateway -should allow at least the following ICMP packet types:</p> -<dl> - <dt>echo (type 8)</dt> - <dd></dd> - <dt>echo reply (type 0)</dt> - <dd>These are used by ping(1). We recommend allowing both types through - the tunnel and to or from your gateway's external interface, since - ping(1) is an essential testing tool. - <p>It is fairly common for firewalls to drop ICMP echo packets - addressed to machines behind the firewall. If that is your policy, - please create an exception for such packets arriving via an IPsec - tunnel, at least during intial testing of those tunnels.</p> - </dd> - <dt>destination unreachable (type 3)</dt> - <dd>This is used, with code 4 (Fragmentation Needed and Don't Fragment - was Set) in the code field, to control <a - href="glossary.html#pathMTU">path MTU discovery</a>. Since IPsec - processing adds headers, enlarges packets and may cause fragmentation, - an IPsec gateway should be able to send and receive these ICMP messages - <strong>on both inside and outside interfaces</strong>.</dd> -</dl> - -<h3><a name="traceroute">UDP packets for traceroute</a></h3> - -<p>The traceroute(1) utility uses UDP port numbers from 33434 to -approximately 33633. Generally, these should be allowed through for -troubleshooting.</p> - -<p>Some firewalls drop these packets to prevent outsiders exploring the -protected network with traceroute(1). If that is your policy, consider -creating an exception for such packets arriving via an IPsec tunnel, at least -during intial testing of those tunnels.</p> - -<h3><a name="l2tp">UDP for L2TP</a></h3> -<p> -Windows 2000 does, and products designed for compatibility with it may, build -<a href="glossary.html#L2TP">L2TP</a> tunnels over IPsec connections. - -<p>For this to work, you must allow UDP protocol 1701 packets coming out of -your tunnels to continue to their destination. You can, and probably should, -block such packets to or from your external interfaces, but allow them from -<var>ipsec0</var>.</p> - -<p>See also our Windows 2000 <a href="interop.html#win2k">interoperation -discussion</a>.</p> - -<h2><a name="packets">How it all works: IPsec packet details</a></h2> - -<p>IPsec uses three main types of packet:</p> -<dl> - <dt><a href="glossary.html#IKE">IKE</a> uses <strong>the UDP protocol and - port 500</strong>.</dt> - <dd>Unless you are using only (less secure, not recommended) manual - keying, you need IKE to negotiate connection parameters, acceptable - algorithms, key sizes and key setup. IKE handles everything required to - set up, rekey, repair or tear down IPsec connections.</dd> - <dt><a href="glossary.html#ESP">ESP</a> is <strong>protocol number - 50</strong></dt> - <dd>This is required for encrypted connections.</dd> - <dt><a href="glossary.html#AH">AH</a> is <strong>protocol number - 51</strong></dt> - <dd>This can be used where only authentication, not encryption, is - required.</dd> -</dl> - -<p>All of those packets should have appropriate IPsec gateway addresses in -both the to and from IP header fields. Firewall rules can check this if you -wish, though it is not strictly necessary. This is discussed in more detail -<a href="#unknowngate">later</a>.</p> - -<p>IPsec processing of incoming packets authenticates them then removes the -ESP or AH header and decrypts if necessary. Successful processing exposes an -inner packet which is then delivered back to the firewall machinery, marked -as having arrived on an <var>ipsec[0-3]</var> interface. Firewall rules can -use that interface label to distinguish these packets from unencrypted -packets which are labelled with the physical interface they arrived on (or -perhaps with a non-IPsec virtual interface such as <var>ppp0</var>).</p> - -<p>One of our users sent a mailing list message with a <a -href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00006.html">diagram</a> -of the packet flow.</p> - -<h3><a name="noport">ESP and AH do not have ports</a></h3> - -<p>Some protocols, such as TCP and UDP, have the notion of ports. Others -protocols, including ESP and AH, do not. Quite a few IPsec newcomers have -become confused on this point. There are no ports <em>in</em> the ESP or AH -protocols, and no ports used <em>for</em> them. For these protocols, <em>the -idea of ports is completely irrelevant</em>.</p> - -<h3><a name="header">Header layout</a></h3> - -<p>The protocol numbers for ESP or AH are used in the 'next header' field of -the IP header. On most non-IPsec packets, that field would have one of:</p> -<ul> - <li>1 for ICMP</li> - <li>4 for IP-in-IP encapsulation</li> - <li>6 for TCP</li> - <li>17 for UDP</li> - <li>... or one of about 100 other possibilities listed by <a - href="http://www.iana.org">IANA</a></li> -</ul> - -<p>Each header in the sequence tells what the next header will be. IPsec adds -headers for ESP or AH near the beginning of the sequence. The original -headers are kept and the 'next header' fields adjusted so that all headers -can be correctly interpreted.</p> - -<p>For example, using <strong>[</strong> <strong>]</strong> to indicate data -protected by ESP and unintelligible to an eavesdropper between the -gateways:</p> -<ul> - <li>a simple packet might have only IP and TCP headers with: - <ul> - <li>IP header says next header --> TCP</li> - <li>TCP header port number --> which process to send data to</li> - <li>data</li> - </ul> - </li> - <li>with ESP <a href="glossary.html#transport">transport mode</a> - encapsulation, that packet would have: - <ul> - <li>IP header says next header --> ESP</li> - <li>ESP header <strong>[</strong> says next --> TCP</li> - <li>TCP header port number --> which process to send data to</li> - <li>data <strong>]</strong></li> - </ul> - Note that the IP header is outside ESP protection, visible to an - attacker, and that the final destination must be the gateway.</li> - <li>with ESP in <a href="glossary.html#tunnel">tunnel mode</a>, we might - have: - <ul> - <li>IP header says next header --> ESP</li> - <li>ESP header <strong>[</strong> says next --> IP</li> - <li>IP header says next header --> TCP</li> - <li>TCP header port number --> which process to send data to</li> - <li>data <strong>]</strong></li> - </ul> - Here the inner IP header is protected by ESP, unreadable by an attacker. - Also, the inner header can have a different IP address than the outer IP - header, so the decrypted packet can be routed from the IPsec gateway to a - final destination which may be another machine.</li> -</ul> - -<p>Part of the ESP header itself is encrypted, which is why the -<strong>[</strong> indicating protected data appears in the middle of some -lines above. The next header field of the ESP header is protected. This makes -<a href="glossary.html#traffic">traffic analysis</a> more difficult. The next -header field would tell an eavesdropper whether your packet was UDP to the -gateway, TCP to the gateway, or encapsulated IP. It is better not to give -this information away. A clever attacker may deduce some of it from the -pattern of packet sizes and timings, but we need not make it easy.</p> - -<p>IPsec allows various combinations of these to match local policies, -including combinations that use both AH and ESP headers or that nest multiple -copies of these headers.</p> - -<p>For example, suppose my employer has an IPsec VPN running between two -offices so all packets travelling between the gateways for those offices are -encrypted. If gateway policies allow it (The admins could block UDP 500 and -protocols 50 and 51 to disallow it), I can build an IPsec tunnel from my -desktop to a machine in some remote office. Those packets will have one ESP -header throughout their life, for my end-to-end tunnel. For part of the -route, however, they will also have another ESP layer for the corporate VPN's -encapsulation. The whole header scheme for a packet on the Internet might -be:</p> -<ul> - <li>IP header (with gateway address) says next header --> ESP</li> - <li>ESP header <strong>[</strong> says next --> IP</li> - <li>IP header (with receiving machine address) says next header --> - ESP</li> - <li>ESP header <strong>[</strong> says next --> TCP</li> - <li>TCP header port number --> which process to send data to</li> - <li>data <strong>]]</strong></li> -</ul> - -<p>The first ESP (outermost) header is for the corporate VPN. The inner ESP -header is for the secure machine-to-machine link.</p> - -<h3><a name="dhr">DHR on the updown script</a></h3> - -<p>Here are some mailing list comments from <a -href="manpage.d/ipsec_pluto.8.html">pluto(8)</a> developer Hugh Redelmeier on -an earlier draft of this document:</p> -<pre>There are many important things left out - -- firewalling is important but must reflect (implement) policy. Since - policy isn't the same for all our customers, and we're not experts, - we should concentrate on FW and MASQ interactions with FreeS/WAN. - -- we need a diagram to show packet flow WITHIN ONE MACHINE, assuming - IKE, IPsec, FW, and MASQ are all done on that machine. The flow is - obvious if the components are run on different machines (trace the - cables). - - IKE input: - + packet appears on public IF, as UDP port 500 - + input firewalling rules are applied (may discard) - + Pluto sees the packet. - - IKE output: - + Pluto generates the packet & writes to public IF, UDP port 500 - + output firewalling rules are applied (may discard) - + packet sent out public IF - - IPsec input, with encapsulated packet, outer destination of this host: - + packet appears on public IF, protocol 50 or 51. If this - packet is the result of decapsulation, it will appear - instead on the paired ipsec IF. - + input firewalling rules are applied (but packet is opaque) - + KLIPS decapsulates it, writes result to paired ipsec IF - + input firewalling rules are applied to resulting packet - as input on ipsec IF - + if the destination of the packet is this machine, the - packet is passed on to the appropriate protocol handler. - If the original packet was encapsulated more than once - and the new outer destination is this machine, that - handler will be KLIPS. - + otherwise: - * routing is done for the resulting packet. This may well - direct it into KLIPS for encoding or encrypting. What - happens then is described elsewhere. - * forwarding firewalling rules are applied - * output firewalling rules are applied - * the packet is sent where routing specified - - IPsec input, with encapsulated packet, outer destination of another host: - + packet appears on some IF, protocol 50 or 51 - + input firewalling rules are applied (but packet is opaque) - + routing selects where to send the packet - + forwarding firewalling rules are applied (but packet is opaque) - + packet forwarded, still encapsulated - - IPsec output, from this host or from a client: - + if from a client, input firewalling rules are applied as the - packet arrives on the private IF - + routing directs the packet to an ipsec IF (this is how the - system decides KLIPS processing is required) - + if from a client, forwarding firewalling rules are applied - + KLIPS eroute mechanism matches the source and destination - to registered eroutes, yielding a SPI group. This dictates - processing, and where the resulting packet is to be sent - (the destinations SG and the nexthop). - + output firewalling is not applied to the resulting - encapsulated packet - -- Until quite recently, KLIPS would double encapsulate packets that - didn't strictly need to be. Firewalling should be prepared for - those packets showing up as ESP and AH protocol input packets on - an ipsec IF. - -- MASQ processing seems to be done as if it were part of the - forwarding firewall processing (this should be verified). - -- If a firewall is being used, it is likely the case that it needs to - be adjusted whenever IPsec SAs are added or removed. Pluto invokes - a script to do this (and to adjust routing) at suitable times. The - default script is only suitable for ipfwadm-managed firewalls. Under - LINUX 2.2.x kernels, ipchains can be managed by ipfwadm (emulation), - but ipchains more powerful if manipulated using the ipchains command. - In this case, a custom updown script must be used. - - We think that the flexibility of ipchains precludes us supplying an - updown script that would be widely appropriate.</pre> -</body> -</html> |