diff options
Diffstat (limited to 'doc/firewall.html')
| -rw-r--r-- | doc/firewall.html | 767 |
1 files changed, 0 insertions, 767 deletions
diff --git a/doc/firewall.html b/doc/firewall.html deleted file mode 100644 index 0747ab83d..000000000 --- a/doc/firewall.html +++ /dev/null @@ -1,767 +0,0 @@ -<!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> |