From aaa0331ecf95ced1e913ac9be50168cf0e7cbb82 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:21:07 +0000 Subject: [svn-upgrade] Integrating new upstream version, strongswan (2.8.2) --- doc/testing.html | 332 ------------------------------------------------------- 1 file changed, 332 deletions(-) delete mode 100644 doc/testing.html (limited to 'doc/testing.html') diff --git a/doc/testing.html b/doc/testing.html deleted file mode 100644 index 77626ba5d..000000000 --- a/doc/testing.html +++ /dev/null @@ -1,332 +0,0 @@ - - - -Introduction to FreeS/WAN - - - - -Contents -Previous -Next -
-

Testing FreeS/WAN

- This document discusses testing FreeS/WAN. -

Not all types of testing are described here. Other parts of the - documentation describe some tests:

-
-
installation document
-
testing for a successful install
-
configuration document
-
basic tests for a working configuration
-
web links document
-
General information on tests for interoperability between various - IPsec implementations. This includes links to several test sites.
-
interoperation document.
-
More specific information on FreeS/WAN interoperation with other - implementations.
-
performance document
-
performance measurements
-
-

The test setups and procedures described here can also be used in - other testing, but this document focuses on testing the IPsec - functionality of FreeS/WAN.

-

Testing opportunistic connections

-

This section teaches you how to test your opportunistically encrypted - (OE) connections. To set up OE, please see the easy instructions in our quickstart guide.

-

Basic OE Test

-

This test is for basic OE functionality. - - For additional tests, keep - reading.

-

Be sure IPsec is running. You can see whether it is with:

-
    ipsec setup status
-

If need be, you can restart it with:

-
    service ipsec restart
-

Load a FreeS/WAN test website from the host on which you're running - FreeS/WAN. Note: the feds may be watching these sites. Type one of:

-

-
   links oetest.freeswan.org
-
   links oetest.freeswan.nl
- - -

A positive result looks like this:

-
-   You  seem  to  be  connecting  from:  192.0.2.11 which DNS says is:
-   gateway.example.com
-     _________________________________________________________________
-                                                                                
-   Status E-route
-   OE    enabled    16    192.139.46.73/32    ->    192.0.2.11/32   =>
-   tun0x2097@192.0.2.11
-   OE    enabled    176    192.139.46.77/32    ->   192.0.2.11/32   =>
-   tun0x208a@192.0.2.11
-
-

If you see this, congratulations! Your OE box will now encrypt its - own traffic whenever it can. If you have difficulty, see our - OE troubleshooting tips.

-

OE Gateway Test

-

If you've set up FreeS/WAN to protect a subnet behind your gateway, - you'll need to run another simple test, which can be done from a - machine running any OS. That's right, your Windows box can be protected - by opportunistic encryption without any FreeS/WAN install or - configuration on that box. From each protected subnet node -, load the FreeS/WAN website with:

-
   links oetest.freeswan.org
-
   links oetest.freeswan.nl
-

A positive result looks like this:

-
-   You  seem  to  be  connecting  from:  192.0.2.98 which DNS says is:
-   box98.example.com
-     _________________________________________________________________
-                                                                                
-   Status E-route
-   OE    enabled    16    192.139.46.73/32    ->    192.0.2.98/32   =>
-   tun0x134ed@192.0.2.11
-   OE    enabled    176    192.139.46.77/32    ->   192.0.2.11/32   =>
-   tun0x134d2@192.0.2.11
-
-

If you see this, congratulations! Your OE gateway will now encrypt - traffic for this subnet node whenever it can. If you have difficulty, - see our OE troubleshooting tips -.

-

Additional OE tests

-

When testing OE, you will often find it useful to execute this - command on the FreeS/WAN host:

-
   ipsec eroute
-

If you have established a connection (either for or for a subnet - node) you will see a result like:

-
    192.0.2.11/32   -> 192.139.46.73/32  => tun0x149f@192.139.46.38
-
-

Key:

- - - - - -
1.192.0.2.11/32Local start point of the - protected traffic.
2.192.0.2.194/32Remote end point of the - protected traffic.
3.192.0.48.38Remote FreeS/WAN node (gateway or - host). May be the same as (2).
4.[not shown]Local FreeS/WAN node (gateway or - host), where you've produced the output. May be the same as (1).
-

For extra assurance, you may wish to use a packet sniffer such as - tcpdump to verify that packets are being encrypted. You should see - output that indicates ESP encrypted data, for example:

-
    02:17:47.353750 PPPoE  [ses 0x1e12] IP 154: xy.example.com > oetest.freeswan.org: ESP(spi=0x87150d16,seq=0x55)
-

Testing with User Mode Linux

-

User Mode Linux - allows you to run Linux as a user process on another Linux machine.

-

As of 1.92, the distribution has a new directory named testing. It - contains a collection of test scripts and sample configurations. Using - these, you can bring up several copies of Linux in user mode and have - them build tunnels to each other. This lets you do some testing of a - FreeS/WAN configuration on a single machine.

-

You need a moderately well-endowed machine for this to work well. - Each UML wants about 16 megs of memory by default, which is plenty for - FreeS/WAN usage. Typical regression testing only occasionally uses as - many as 4 UMLs. If one is doing nothing else with the machine (in - particular, not running X on it), then 128 megs and a 500MHz CPU are - fine.

- Documentation on these scripts is here. - There is also documentation on automated testing - here. -

Configuration for a testbed network

-

A common test setup is to put a machine with dual Ethernet cards in - between two gateways under test. You need at least five machines; two - gateways, two clients and a testing machine in the middle.

-

The central machine both routes packets and provides a place to run - diagnostic software for checking IPsec packets. See next section for - discussion of using tcpdump(8) for - this.

-

This makes things more complicated than if you just connected the two - gateway machines directly to each other, but it also makes your test - setup much more like the environment you actually use IPsec in. Those - environments nearly always involve routing, and quite a few apparent - IPsec failures turn out to be problems with routing or with firewalls - dropping packets. This approach lets you deal with those problems on - your test setup.

-

What you end up with looks like:

-

Testbed network

-
      subnet a.b.c.0/24
-             |
-      eth1 = a.b.c.1
-         gate1
-      eth0 = 192.168.p.1
-             |
-             |
-      eth0 = 192.168.p.2
-         route/monitor box
-      eth1 = 192.168.q.2
-             |
-             |
-      eth0 = 192.168.q.1
-         gate2
-      eth1 = x.y.z.1
-              |
-       subnet x.y.z.0/24
-
Where p and q are any convenient values that do not interfere with other
-routes you may have. The ipsec.conf(5) file then has, among other things:
-
conn abc-xyz
-      left=192.168.p.1
-      leftnexthop=192.168.p.2
-      right=192.168.q.1
-      rightnexthop=192.168.q.2
-

Once that works, you can remove the "route/monitor box", and connect - the two gateways to the Internet. The only parameters in ipsec.conf(5) - that need to change are the four shown above. You replace them with - values appropriate for your Internet connection, and change the eth0 IP - addresses and the default routes on both gateways.

-

Note that nothing on either subnet needs to change. This lets you - test most of your IPsec setup before connecting to the insecure - Internet.

-

Using packet sniffers in testing

-

A number of tools are available for looking at packets. We will - discuss using tcpdump(8), a - common Linux tool included in most distributions. Alternatives - offerring more-or-less the same functionality include:

-
-
Ethereal
-
Several people on our mailing list report a preference for this over - tcpdump.
-
windump
-
a Windows version of tcpdump(8), possibly handy if you have Windows - boxes in your network
-
-Sniffit
-
A linux sniffer that we don't know much about. If you use it, please - comment on our mailing list.
-
-

See also this - index of packet sniffers.

-

tcpdump(8) may misbehave if run on the gateways themselves. It is - designed to look into a normal IP stack and may become confused if you - ask it to display data from a stack which has IPsec in play.

-

At one point, the problem was quite severe. Recent versions of - tcpdump, however, understand IPsec well enough to be usable on a - gateway. You can get the latest version from - tcpdump.org.

-

Even with a recent tcpdump, some care is required. Here is part of a - post from Henry on the topic:

-
> a) data from sunset to sunrise or the other way is not being
-> encrypted (I am using tcpdump (ver. 3.4) -x/ping -p to check
-> packages) 
-
-What *interface* is tcpdump being applied to?  Use the -i option to
-control this.  It matters!  If tcpdump is looking at the ipsecN
-interfaces, e.g. ipsec0, then it is seeing the packets before they are
-encrypted or after they are decrypted, so of course they don't look
-encrypted.  You want to have tcpdump looking at the actual hardware
-interfaces, e.g. eth0. 
-
-Actually, the only way to be *sure* what you are sending on the wire is to
-have a separate machine eavesdropping on the traffic.  Nothing you can do
-on the machines actually running IPsec is 100% guaranteed reliable in this
-area (although tcpdump is a lot better now than it used to be).
-

The most certain way to examine IPsec packets is to look at them on - the wire. For security, you need to be certain, so we recommend doing - that. To do so, you need a separate sniffer machine located - between the two gateways. This machine can be routing IPsec - packets, but it must not be an IPsec gateway. Network configuration for - such testing is discussed above.

-

Here's another mailing list message with advice on using tcpdump(8):

-
Subject: RE: [Users] Encrypted???
-   Date: Thu, 29 Nov 2001
-   From: "Joe Patterson" <jpatterson@asgardgroup.com>
-
-tcpdump -nl -i $EXT-IF proto 50
-
--nl tells it not to buffer output or resolve names (if you don't do that it
-may confuse you by not outputing anything for a while), -i $EXT-IF (replace
-with your external interface) tells it what interface to listen on, and
-proto 50 is ESP.  Use "proto 51" if for some odd reason you're using AH, and
-"udp port 500" if you want to see the isakmp key exchange/tunnel setup
-packets.
-
-You can also run `tcpdump -nl -i ipsec0` to see what traffic is on that
-virtual interface.  Anything you see there *should* be either encrypted or
-dropped (unless you've turned on some strange options in your ipsec.conf
-file)
-
-Another very handy thing is ethereal (http://www.ethereal.com/) which runs
-on just about anything, has a nice gui interface (or a nice text-based
-interface), and does a great job of protocol  breakdown.  For ESP and AH
-it'll basically just tell you that there's a packet of that protocol, and
-what the spi is, but for isakmp it'll actually show you a lot of the tunnel
-setup information (until it gets to the point in the protocol where isakmp
-is encrypted....)
-

Verifying encryption

-

The question of how to verify that messages are actually encrypted - has been extensively discussed on the mailing list. See this - thread.

-

If you just want to verify that packets are encrypted, look at them - with a packet sniffer (see previous section -) located between the gateways. The packets should, except for some of - the header information, be utterly unintelligible. The output - of good encryption looks exactly like random noise.

-

A packet sniffer can only tell you that the data you looked at was - encrypted. If you have stronger requirements -- for example if your - security policy requires verification that plaintext is not leaked - during startup or under various anomolous conditions -- then you will - need to devise much more thorough tests. If you do that, please post - any results or methodological details which your security policy allows - you to make public.

-

You can put recognizable data into ping packets with something like:

-
        ping -p feedfacedeadbeef 11.0.1.1
-

"feedfacedeadbeef" is a legal hexadecimal pattern that is easy to - pick out of hex dumps.

-

For other protocols, you may need to check if you have encrypted data - or ASCII text. Encrypted data has approximately equal frequencies for - all 256 possible characters. ASCII text has most characters in the - printable range 0x20-0x7f, a few control characters less than 0x20, and - none at all in the range 0x80-0xff. 0x20, space, is a good character to - look for. In normal English text space occurs about once in seven - characters, versus about once in 256 for random or encrypted data.

-

One thing to watch for: the output of good compression, like that of - good encryption, looks just like random noise. You cannot tell just by - looking at a data stream whether it has been compressed, encrypted, or - both. You need a little care not to mistake compressed data for - encrypted data in your testing.

-

Note also that weak encryption also produces random-looking output. - You cannot tell whether the encryption is strong by looking at the - output. To be sure of that, you would need to have both the algorithms - and the implementation examined by experts.

-

For IPsec, you can get partial assurance from interoperability tests. - See our interop document. When twenty - products all claim to implement 3DES, - and they all talk to each other, you can be fairly sure they have it - right. Of course, you might wonder whether all the implementers are - consipring to trick you or, more plausibly, whether some - implementations might have "back doors" so they can get also it wrong - when required.. If you're seriously worried about things like that, you - need to get the code you use audited (good luck if it is not Open - Source), or perhaps to talk to a psychiatrist about treatments for - paranoia.

-

Mailing list pointers

-

Additional information on testing can be found in these - mailing list messages:

- -
-Contents -Previous -Next - - -- cgit v1.2.3