diff options
| author | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-05-22 05:12:18 +0000 |
|---|---|---|
| committer | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-05-22 05:12:18 +0000 |
| commit | aa0f5b38aec14428b4b80e06f90ff781f8bca5f1 (patch) | |
| tree | 95f3d0c8cb0d59d88900dbbd72110d7ab6e15b2a /doc/firewall.html | |
| parent | 7c383bc22113b23718be89fe18eeb251942d7356 (diff) | |
| download | vyos-strongswan-aa0f5b38aec14428b4b80e06f90ff781f8bca5f1.tar.gz vyos-strongswan-aa0f5b38aec14428b4b80e06f90ff781f8bca5f1.zip | |
Import initial strongswan 2.7.0 version into SVN.
Diffstat (limited to 'doc/firewall.html')
| -rw-r--r-- | doc/firewall.html | 767 |
1 files changed, 767 insertions, 0 deletions
diff --git a/doc/firewall.html b/doc/firewall.html new file mode 100644 index 000000000..0747ab83d --- /dev/null +++ b/doc/firewall.html @@ -0,0 +1,767 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> +<HTML> +<HEAD> +<TITLE>Introduction to FreeS/WAN</TITLE> +<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1"> +<STYLE TYPE="text/css"><!-- +BODY { font-family: serif } +H1 { font-family: sans-serif } +H2 { font-family: sans-serif } +H3 { font-family: sans-serif } +H4 { font-family: sans-serif } +H5 { font-family: sans-serif } +H6 { font-family: sans-serif } +SUB { font-size: smaller } +SUP { font-size: smaller } +PRE { font-family: monospace } +--></STYLE> +</HEAD> +<BODY> +<A HREF="toc.html">Contents</A> +<A HREF="manpages.html">Previous</A> +<A HREF="trouble.html">Next</A> +<HR> +<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> +<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> +<HR> +<A HREF="toc.html">Contents</A> +<A HREF="manpages.html">Previous</A> +<A HREF="trouble.html">Next</A> +</BODY> +</HTML> |