freeswan/doc/src/testing.html

   1 <html>
   2 <head>
   3 <title>Testing FreeS/WAN</title>
   4
   5 <meta name="keywords" content="Linux, IPsec, VPN, security, FreeSWAN, testing">
   6
   7 <!--
   8
   9 Written by Sandy Harris for the Linux FreeS/WAN project
  10 Freely distributable under the GNU General Public License
  11
  12 More information at www.freeswan.org
  13 Feedback to users@lists.freeswan.org
  14
  15 CVS information:
  16 RCS ID:          $Id: testing.html,v 1.14 2002/03/18 19:32:04 sandy Exp $
  17 Last changed:    $Date: 2002/03/18 19:32:04 $
  18 Revision number: $Revision: 1.14 $
  19
  20 CVS revision numbers do not correspond to FreeS/WAN release numbers.
  21 -->
  22 </head>
  23
  24 <body>
  25 <h1><a name="test.freeswan">Testing FreeS/WAN</a></h1>
  26 This document discusses testing FreeS/WAN.
  27
  28 <p>Not all types of testing are described here. Other parts of the
  29 documentation describe some tests:</p>
  30 <dl>
  31   <dt><a href="install.html#testinstall">installation</a> document</dt>
  32     <dd>testing for a successful install</dd>
  33   <dt><a href="config.html#testsetup">configuration</a> document</dt>
  34     <dd>basic tests for a working configuration</dd>
  35   <dt><a href="web.html#interop.web">web links</a> document</dt>
  36     <dd>General information on tests for interoperability between various
  37       IPsec implementations. This includes links to several test sites.</dd>
  38   <dt><a href="interop.html">interoperation</a> document.</dt>
  39     <dd>More specific information on FreeS/WAN interoperation with other
  40       implementations.</dd>
  41   <dt><a href="performance.html">performance</a> document</dt>
  42     <dd>performance measurements</dd>
  43 </dl>
  44
  45 <p>The test setups and procedures described here can also be used in other
  46 testing, but this document focuses on testing the IPsec functionality of
  47 FreeS/WAN.</p>
  48
  49 <h2><a name="test.uml">Testing with User Mode Linux</a></h2>
  50
  51 <p><a href="http://user-mode-linux.sourceforge.net/">User Mode Linux</a>
  52 allows you to run Linux as a user process on another Linux machine.</p>
  53
  54 <p>As of 1.92, the distribution has a new directory named  testing. It
  55 contains a collection of test scripts and sample configurations. Using these,
  56 you can bring up several copies of Linux in user mode and have them build
  57 tunnels to each other. This lets you do some testing of  a FreeS/WAN
  58 configuration on a single machine.</p>
  59
  60 <p>You need a moderately well-endowed machine for this to work well. Each UML
  61 wants about 16 megs of memory by default, which is plenty for FreeS/WAN
  62 usage. Typical regression testing only occasionally uses as many as 4 UMLs.
  63 If one is doing nothing else with the machine (in particular, not running X
  64 on it), then 128 megs and a 500MHz CPU are fine.</p>
  65
  66 Documentation on these
  67 scripts is <a href="umltesting.html">here</a>. There is also documentation
  68 on automated testing <A href="makecheck.html">here</a>.
  69
  70 <h2><a name="testnet">Configuration for a testbed network</a></h2>
  71
  72 <p>A common test setup is to put a machine with dual Ethernet cards in
  73 between two gateways under test. You need at least five machines; two
  74 gateways, two clients and a testing machine in the middle.</p>
  75
  76 <p>The central machine both routes packets and provides a place to run
  77 diagnostic software for checking IPsec packets. See next section for
  78 discussion of <a href="#tcpdump.faq">using tcpdump(8)</a> for this.</p>
  79
  80 <p>This makes things more complicated than if you just connected the two
  81 gateway machines directly to each other, but it also makes your test setup
  82 much more like the environment you actually use IPsec in. Those environments
  83 nearly always involve routing, and quite a few apparent IPsec failures turn
  84 out to be problems with routing or with firewalls dropping packets. This
  85 approach lets you deal with those problems on your test setup.</p>
  86
  87 <p>What you end up with looks like:</p>
  88
  89 <h3><a name="testbed">Testbed network</a></h3>
  90 <pre>      subnet a.b.c.0/24
  91              |
  92       eth1 = a.b.c.1
  93          gate1
  94       eth0 = 192.168.p.1
  95              |
  96              |
  97       eth0 = 192.168.p.2
  98          route/monitor box
  99       eth1 = 192.168.q.2
 100              |
 101              |
 102       eth0 = 192.168.q.1
 103          gate2
 104       eth1 = x.y.z.1
 105               |
 106        subnet x.y.z.0/24</pre>
 107 <pre>Where p and q are any convenient values that do not interfere with other
 108 routes you may have. The ipsec.conf(5) file then has, among other things:</pre>
 109 <pre>conn abc-xyz
 110       left=192.168.p.1
 111       leftnexthop=192.168.p.2
 112       right=192.168.q.1
 113       rightnexthop=192.168.q.2</pre>
 114
 115 <p>Once that works, you can remove the "route/monitor box", and connect the
 116 two gateways to the Internet. The only parameters in ipsec.conf(5) that need
 117 to change are the four shown above. You replace them with values appropriate
 118 for your Internet connection, and change the eth0 IP addresses and the
 119 default routes on both gateways.</p>
 120
 121 <p>Note that nothing on either subnet needs to change. This lets you test
 122 most of your IPsec setup before connecting to the insecure Internet.</p>
 123
 124 <h3><a name="tcpdump.test">Using packet sniffers in testing</a></h3>
 125
 126 <p>A number of tools are available for looking at packets. We will discuss
 127 using <a href="http://www.tcpdump.org/">tcpdump(8)</a>, a common Linux tool
 128 included in most distributions. Alternatives offerring more-or-less the same
 129 functionality include:</p>
 130 <dl>
 131   <dt><a href="http://www.ethereal.com">Ethereal</a></dt>
 132     <dd>Several people on our mailing list report a preference for this over
 133       tcpdump.</dd>
 134   <dt><a href="http://netgroup-serv.polito.it/windump/">windump</a></dt>
 135     <dd>a Windows version of tcpdump(8), possibly handy if you have Windows
 136       boxes in your network</dd>
 137   <dt><a
 138   href="http://reptile.rug.ac.be/~coder/sniffit/sniffit.html">Sniffit</a></dt>
 139     <dd>A linux sniffer that we don't know much about. If you use it, please
 140       comment on our mailing list.</dd>
 141 </dl>
 142
 143 <p>See also this <a
 144 href="http://www.tlsecurity.net/unix/ids/sniffer/">index</a> of packet
 145 sniffers.</p>
 146
 147 <p>tcpdump(8) may misbehave if run on the gateways themselves. It is designed
 148 to look into a normal IP stack and may become confused if you ask it to
 149 display data from a stack which has IPsec in play.</p>
 150
 151 <p>At one point, the problem was quite severe. Recent versions of tcpdump,
 152 however, understand IPsec well enough to be usable on a gateway. You can get
 153 the latest version from <a href="http://www.tcpdump.org/">tcpdump.org</a>.</p>
 154
 155 <p>Even with a recent tcpdump, some care is required. Here is part of a post
 156 from Henry on the topic:</p>
 157 <pre>&gt; a) data from sunset to sunrise or the other way is not being
 158 &gt; encrypted (I am using tcpdump (ver. 3.4) -x/ping -p to check
 159 &gt; packages)
 160
 161 What *interface* is tcpdump being applied to?  Use the -i option to
 162 control this.  It matters!  If tcpdump is looking at the ipsecN
 163 interfaces, e.g. ipsec0, then it is seeing the packets before they are
 164 encrypted or after they are decrypted, so of course they don't look
 165 encrypted.  You want to have tcpdump looking at the actual hardware
 166 interfaces, e.g. eth0.
 167
 168 Actually, the only way to be *sure* what you are sending on the wire is to
 169 have a separate machine eavesdropping on the traffic.  Nothing you can do
 170 on the machines actually running IPsec is 100% guaranteed reliable in this
 171 area (although tcpdump is a lot better now than it used to be).</pre>
 172
 173 <p>The most certain way to examine IPsec packets is to look at them on the
 174 wire. For security, you need to be certain, so we recommend doing that. To do
 175 so, you need a <strong>separate sniffer machine located between the two
 176 gateways</strong>. This machine can be routing IPsec packets, but it must not
 177 be an IPsec gateway. Network configuration for such testing is discussed <a
 178 href="#testnet">above</a>.</p>
 179
 180 <p>Here's another mailing list message with advice on using tcpdump(8):</p>
 181 <pre>Subject: RE: [Users] Encrypted???
 182    Date: Thu, 29 Nov 2001
 183    From: "Joe Patterson" &lt;jpatterson@asgardgroup.com&gt;
 184
 185 tcpdump -nl -i $EXT-IF proto 50
 186
 187 -nl tells it not to buffer output or resolve names (if you don't do that it
 188 may confuse you by not outputing anything for a while), -i $EXT-IF (replace
 189 with your external interface) tells it what interface to listen on, and
 190 proto 50 is ESP.  Use "proto 51" if for some odd reason you're using AH, and
 191 "udp port 500" if you want to see the isakmp key exchange/tunnel setup
 192 packets.
 193
 194 You can also run `tcpdump -nl -i ipsec0` to see what traffic is on that
 195 virtual interface.  Anything you see there *should* be either encrypted or
 196 dropped (unless you've turned on some strange options in your ipsec.conf
 197 file)
 198
 199 Another very handy thing is ethereal (http://www.ethereal.com/) which runs
 200 on just about anything, has a nice gui interface (or a nice text-based
 201 interface), and does a great job of protocol  breakdown.  For ESP and AH
 202 it'll basically just tell you that there's a packet of that protocol, and
 203 what the spi is, but for isakmp it'll actually show you a lot of the tunnel
 204 setup information (until it gets to the point in the protocol where isakmp
 205 is encrypted....)</pre>
 206
 207 <h2><a name="verify.crypt">Verifying encryption</a></h2>
 208
 209 <p>The question of how to verify that messages are actually encrypted has
 210 been extensively discussed on the mailing list. See this <a
 211 href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00262.html">thread</a>.</p>
 212
 213 <p>If you just want to verify that packets are encrypted, look at them with a
 214 packet sniffer (see <a href="#tcpdump.test">previous section</a>) located
 215 between the gateways. The packets should, except for some of the header
 216 information, be utterly unintelligible. <strong>The output of good encryption
 217 looks <em>exactly</em> like random noise</strong>. </p>
 218
 219 <p>A packet sniffer can only tell you that the data you looked at was
 220 encrypted. If you have stronger requirements -- for example if your security
 221 policy requires verification that plaintext is not leaked during startup or
 222 under various anomolous conditions -- then you will need to devise much more
 223 thorough tests. If you do that, please post any results or methodological
 224 details which your security policy allows you to make public.</p>
 225
 226 <p>You can put recognizable data into ping packets with something like:</p>
 227 <pre>        ping -p feedfacedeadbeef 11.0.1.1</pre>
 228
 229 <p>"feedfacedeadbeef" is a legal hexadecimal pattern that is easy to pick out
 230 of hex dumps.</p>
 231
 232 <p>For other protocols, you may need to check if you have encrypted data or
 233 ASCII text. Encrypted data has approximately equal frequencies for all 256
 234 possible characters. ASCII text has most characters in the printable range
 235 0x20-0x7f, a few control characters less than 0x20, and none at all in the
 236 range 0x80-0xff. 0x20, space, is a good character to look for. In normal
 237 English text space occurs about once in seven characters, versus about once
 238 in 256 for random or encrypted data.</p>
 239
 240 <p>One thing to watch for: the output of good compression, like that of good
 241 encryption, looks just like random noise. You cannot tell just by looking at
 242 a data stream whether it has been compressed, encrypted, or both. You need a
 243 little care not to mistake compressed data for encrypted data in your
 244 testing.</p>
 245
 246 <p>Note also that weak encryption also produces random-looking output. You
 247 cannot tell whether the encryption is strong by looking at the output. To be
 248 sure of that, you would need to have both the algorithms and the
 249 implementation examined by experts. </p>
 250
 251 <p>For IPsec, you can get partial assurance from interoperability tests. See
 252 our <a href="interop.html">interop</a> document. When twenty products all
 253 claim to implement <a href="glossary.html#3DES">3DES</a>, and they all talk
 254 to each other, you can be fairly sure they have it right. Of course, you
 255 might wonder whether all the implementers are consipring to trick you or,
 256 more plausibly, whether some implementations might have "back doors" so they
 257 can get also it wrong when required.. If you're seriously worried about
 258 things like that, you need to get the code you use audited (good luck if it
 259 is not Open Source), or perhaps to talk to a psychiatrist about treatments
 260 for paranoia. </p>
 261
 262 <h2><a name="mail.test">Mailing list pointers</a></h2>
 263
 264 <p>Additional information on testing can be found in these <a
 265 href="mail.html">mailing list</a> messages:</p>
 266 <ul>
 267   <li>a user's detailed <a
 268     href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00571.html">setup
 269     diary</a> for his testbed network</li>
 270   <li>a FreeS/WAN team member's <a
 271     href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00425.html">notes</a>
 272     from testing at an IPsec interop "bakeoff"</li>
 273 </ul>
 274 </body>
 275 </html>