$Id: README,v 1.1.1.1 2005/01/13 18:44:53 mcr Exp $

ike-scan - Discover and fingerprint IKE hosts (IPsec VPN Servers)

TABLE OF CONTENTS

   1.  BUILDING AND INSTALLING
   2.  OVERVIEW
   3.  USAGE
   4.  IMPLEMENTATION DETAILS
      4.1.  Host Input and Memory Requirements
      4.2.  Rate Limiting
      4.3.  Cookie Generation and Remote Host Identification
      4.4.  IKE Packet Details
      4.5.  Backoff Fingerprinting
      4.6.  Syslog
   5.  PROGRAM OUTPUT
   6.  EXAMPLES
   7.  SUPPORTED PLATFORMS
   8.  FURTHER READING AND RFCS
   9.  CONTACT ADDRESS

1.  BUILDING AND INSTALLING

ike-scan uses the standard GNU autoconf and automake tools, so installation
is the normal process:

a) Unzip/Untar the tarball (e.g. tar xzf <tarball-name> if you're using GNU tar)
b) cd to the ike-scan source directory (e.g. cd ike-scan-1.7)
c) ./configure (use "./configure --with-openssl" to use the OpenSSL libraries)
d) make
e) make check (optional, but recommended)
f) make install (you'll need to be root for this bit)

If you plan on performing pre-shared key cracking, then you should configure
ike-scan to use the OpenSSL hash functions rather than its built-in functions
because the OpenSSL ones are normally faster.  To do this, make sure you have
the OpenSSL include files and libraries installed, and run configure as
"./configure --with-openssl" in step (c) above.  Whether you use OpenSSL or
not won't affect the functionallity of ike-scan, just the speed of pre-shared
key cracking with psk-crack.

Some operating systems install the OpenSSL headers and libraries by default;
others require that you install an optional package, for example on Debian
Linux you need to install the libssl-dev package.  Alternatively, you can
download and install the OpenSSL tarball from http://www.openssl.org/

It should build on most modern Unix-like OSes.  It works on Windows with Cygwin
and can be used as a standalone Windows executable when cygwin1.dll is present.

If you are using the Windows-32 binary package, please also read the file
README-WIN32 which details the differences when running on the Windows
platform.

The program is known to build and run on Linux, FreeBSD, OpenBSD, NetBSD,
Win32/Cygwin, Solaris, MacOS X, HP Tru64, HP-UX, and SCO OpenServer.  For more
details see the section "SUPPORTED PLATFORMS" below.

For installation instructions, see the file INSTALL.

2.  OVERVIEW

ike-scan discovers IKE hosts and can also fingerprint them using the
retransmission backoff pattern.

ike-scan can perform the following functions:

a) Discovery: Determine which hosts in a given IP range are running IKE.
   This is done by displaying those hosts which respond to the IKE requests
   sent by ike-scan.

b) Fingerprinting: Determine which IKE implementation the hosts are using,
   and in some cases determine the version of software that they are running.
   This is done in two ways: firstly by UDP backoff fingerprinting which
   involves recording the times of the IKE response packets from the
   target hosts and comparing the observed retransmission backoff pattern
   against known patterns; and secondly by Vendor ID fingerprinting which
   compares Vendor ID payloads from the VPN servers against known vendor id
   patterns.

c) Transform Enumeration: Find which transform attributes are supported by the
   VPN server for IKE Phase-1 (e.g. encryption algorithm, hash algorithm etc.).

d) User Enumeration: For some VPN systems, discover valid VPN usernames.

e) Pre-Shared Key Cracking: Perform offline dictionary or brute-force password
   cracking for IKE Aggressice Mode with Pre-Shared Key authentication. This
   uses ike-scan to obtain the hash and other parameters, and psk-crack (which
   is part of the ike-scan package) to perform the cracking.

The retransmission backoff fingerprinting concept is discussed in more
detail in the UDP backoff fingerprinting paper which should be included
in the ike-scan kit as udp-backoff-fingerprinting-paper.txt.

The program sends IKE phase-1 (Main Mode or Aggressive Mode) requests to the
specified hosts and displays any responses that are received.  It handles
retry and retransmission with backoff to cope with packet loss.  It also
limits the amount of bandwidth used by the outbound IKE packets.

IKE is the Internet Key Exchange protocol which is the key exchange and
authentication mechanism used by IPsec.  Just about all modern VPN systems
implement IPsec, and the vast majority of IPsec VPNs use IKE for key exchange.
Main Mode is one of the modes defined for phase-1 of the IKE exchange (the
other defined mode is aggressive mode).  RFC 2409 section 5 specifies that
main mode must be implemented, therefore all IKE implementations can
be expected to support main mode. Many also support Aggressive Mode.

3.  USAGE

Below is the output from "ike-scan --help".  This is intended as a guide only
and may be slightly out-of date.  You should use ike-scan --help to display
information on the usage and options for your version once you have built the
program.

Usage: ike-scan [options] [hosts...]

Target hosts must be specified on the command line unless the --file option is
given, in which case the targets are read from the specified file instead.

The target hosts can be specified as IP addresses or hostnames.  You can also
specify IPnetwork/bits (e.g. 192.168.1.0/24) to specify all hosts in the given
network (network and broadcast addresses included), and IPstart-IPend
(e.g. 192.168.1.3-192.168.1.27) to specify all hosts in the inclusive range.

These different options for specifying target hosts may be used both on the
command line, and also in the file specified with the --file option.

Options:

--help or -h		Display this usage message and exit.

--file=<fn> or -f <fn>	Read hostnames or addresses from the specified file
			instead of from the command line. One name or IP
			address per line.  Use "-" for standard input.

--sport=<p> or -s <p>	Set UDP source port to <p>, default=500, 0=random.
			Some IKE implementations require the client to use
			UDP source port 500 and will not talk to other ports.
			Note that superuser privileges are normally required
			to use non-zero source ports below 1024.  Also only
			one process on a system may bind to a given source port
			at any one time.

--dport=<p> or -d <p>	Set UDP destination port to <p>, default=500.
			UDP port 500 is the assigned port number for ISAKMP
			and this is the port used by most if not all IKE
			implementations.

--retry=<n> or -r <n>	Set total number of attempts per host to <n>,
			default=3.

--timeout=<n> or -t <n>	Set initial per host timeout to <n> ms, default=500.
			This timeout is for the first packet sent to each host.
			subsequent timeouts are multiplied by the backoff
			factor which is set with --backoff.

--interval=<n> or -i <n> Set minimum packet interval to <n> ms, default=75.
			This controls the outgoing bandwidth usage by limiting
			the rate at which packets can be sent.  The packet
			interval will be no smaller than this number.
			The outgoing packets have a total size of 364 bytes
			(20 bytes IP hdr + 8 bytes UDP hdr + 336 bytes data)
			when the default transform set is used, or 112 bytes
			if a custom transform is specified.  Therefore
			for default transform set: 50=58240bps, 80=36400bps and
			for custom transform: 15=59733bps, 30=35840bps.

--backoff=<b> or -b <b>	Set timeout backoff factor to <b>, default=1.50.
			The per-host timeout is multiplied by this factor
			after each timeout.  So, if the number of retrys
			is 3, the initial per-host timeout is 500ms and the
			backoff factor is 1.5, then the first timeout will be
			500ms, the second 750ms and the third 1125ms.

--verbose or -v		Display verbose progress messages.
			Use more than once for greater effect:
			1 - Show when each pass is completed and when
			    packets with invalid cookies are received.
			2 - Show each packet sent and received and when
			    hosts are removed from the list.
			3 - Display the host, Vendor ID and backoff lists
			    before scanning starts.

--quiet or -q		Don't decode the returned packet.
			This prints less protocol information so the
			output lines are shorter.

--multiline or -M	Split the payload decode across multiple lines.
			With this option, the decode for each payload is
			printed on a seperate line starting with a TAB.
			This option makes the output easier to read, especially
			when there are many payloads.

--lifetime=<s> or -l <s> Set IKE lifetime to <s> seconds, default=28800.
			RFC 2407 specifies 28800 as the default, but some
			implementations may require different values.
			If you specify 0, then no lifetime will be specified.
			You can use this option more than once in conjunction
			with the --trans options to produce multiple transform
			payloads with different lifetimes.  Each --trans option
			will use the previously specified lifetime value.

--lifesize=<s> or -z <s> Set IKE lifesize to <s> Kilobytes, default=0.
			If you specify 0, then no lifesize will be specified.
			You can use this option more than once in conjunction
			with the --trans options to produce multiple transform
			payloads with different lifesizes.  Each --trans option
			will use the previously specified lifesize value.

--auth=<n> or -m <n>	Set auth. method to <n>, default=1 (pre-shared key).
			RFC defined values are 1 to 5.  See RFC 2409 Appendix A.
			Checkpoint hybrid mode is 64221.
			GSS (Windows "Kerberos") is 65001.
			XAUTH uses 65001 to 65010.

--version or -V		Display program version and exit.

--vendor=<v> or -e <v>	Set vendor id string to hex value <v>.
			You can use this option more than once to send
			multiple vendor ID payloads.

--trans=<t> or -a <t>	Use custom transform <t> instead of default set.
			<t> is specified as enc[/len],hash,auth,group.
			Where enc is the encryption algorithm,
			len is the key length for variable length ciphers,
			hash is the hash algorithm, and group is the DH Group.
			See RFC 2409 Appendix A for details of which values
			to use.  For example, --trans=5,2,1,2 specifies
			Enc=3DES-CBC, Hash=SHA1, Auth=shared key, DH Group=2
			and --trans=7/256,1,1,5 specifies
			Enc=AES-256, Hash=MD5, Auth=shared key, DH Group=5
			You can use this option more than once to send
			an arbitary number of custom transforms.

--showbackoff[=<n>] or -o[<n>]	Display the backoff fingerprint table.
			Display the backoff table to fingerprint the IKE
			implementation on the remote hosts.
			The optional argument specifies time to wait in seconds
			after receiving the last packet, default=60.
			If you are using the short form of the option (-o)
			then the value must immediately follow the option
			letter with no spaces, e.g. -o25 not -o 25.

--fuzz=<n> or -u <n>	Set pattern matching fuzz to <n> ms, default=100.
			This sets the maximum acceptable difference between
			the observed backoff times and the reference times in
			the backoff patterns file.  Larger values allow for
			higher variance but also increase the risk of
			false positive identifications.
			Any per-pattern-entry fuzz specifications in the
			patterns file will override the value set here.

--patterns=<f> or -p <f> Use IKE patterns file <f>,
			default=/usr/local/share/ike-scan/ike-backoff-patterns.
			This specifies the name of the file containing
			IKE backoff patterns.  This file is only used when
			--showbackoff is specified.

--vidpatterns=<f> or -I <f> Use Vendor ID patterns file <f>,
			default=/usr/local/share/ike-scan/ike-vendor-ids.
			This specifies the name of the file containing
			Vendor ID patterns.  These patterns are used for
			Vendor ID fingerprinting.

--aggressive or -A	Use IKE Aggressive Mode (The default is Main Mode)
			If you specify --aggressive, then you may also
			specify --dhgroup, --id and --idtype.  If you use
			custom transforms with aggressive mode with the --trans
			option, note that all transforms should have the same
			DH Group and this should match the group specified
			with --dhgroup or the default if --dhgroup is not used.

--id=<id> or -n <id>	Use <id> as the identification value.
			This option is only applicable to Aggressive Mode.
			<id> can be specified as a string, e.g. --id=test or as
			a hex value with a leading "0x", e.g. --id=0xdeadbeef.

--idtype=n or -y n	Use identification type <n>.  Default 3 (ID_USER_FQDN).
			This option is only applicable to Aggressive Mode.
			See RFC 2407 4.6.2 for details of Identification types.

--dhgroup=n or -g n	Use Diffie Hellman Group <n>.  Default 2.
			This option is only applicable to Aggressive Mode where
			it is used to determine the size of the key exchange
			payload.
			Acceptable values are 1,2,5,14,15,16,17,18 (MODP only).

--gssid=<n> or -G <n>	Use GSS ID <n> where <n> is a hex string.
			This uses transform attribute type 16384 as specified
			in draft-ietf-ipsec-isakmp-gss-auth-07.txt, although
			Windows-2000 has been observed to use 32001 as well.
			For Windows 2000, you'll need to use --auth=65001 to
			specify Kerberos (GSS) authentication.

--random or -R		Randomise the host list.
			This option randomises the order of the hosts in the
			host list, so the IKE probes are sent to the hosts in
			a random order.  It uses the Knuth shuffle algorithm.

--tcp[=n] or -T[n]	Use TCP transport instead of UDP.
			This allows you to test a host running IKE over TCP.
			You won't normally need this option because the vast
			majority of IPsec systems only support IKE over UDP.
			The optional value <n> specifies the type of IKE over
			TCP.  There are currently two possible values:
			1 = RAW IKE over TCP as used by Checkpoint (default);
			2 = Encapsulated IKE over TCP as used by Cisco.
			If you are using the short form of the option (-T)
			then the value must immediately follow the option
			letter with no spaces, e.g. -T2 not -T 2.
			You can only specify a single target host if you use
			this option.

--tcptimeout=n or -O n	Set TCP connect timeout to n seconds (default=10).
			This is only applicable to TCP transport mode.

--pskcrack[=f] or -P[f]	Crack aggressive mode pre-shared keys.
			This option outputs the aggressive mode pre-shared key
			(PSK) parameters for offline cracking using the
			"psk-crack" program that is supplied with ike-scan.
			You can optionally specify a filename, "f", to write
			the PSK parameters to.  If you do not specify a filename
			then the PSK parameters are written to standard output.
			If you are using the short form of the option (-P)
			then the value must immediately follow the option
			letter with no spaces, e.g. -Pfile not -P file.
			You can only specify a single target host if you use
			this option.
			This option is only applicable to IKE aggressive mode.

--nodns or -N		Do not use DNS to resolve names.
			If you use this option, then all hosts must be
			specified as IP addresses.

Report bugs or send suggestions to ike-scan@nta-monitor.com
See the ike-scan homepage at http://www.nta-monitor.com/ike-scan/

4.  IMPLEMENTATION DETAILS

4.1. Host Input and Memory Requirements

The hosts to scan can be specified on the command line or read from an
input file using the --file=<fn> option.  The program can cope with
large numbers of hosts limited only by the amount of memory needed to store
the list of host_entry structures.  Each host_entry structure requires 45
bytes on a 32-bit system, so a class B network (65534 hosts) would require
about 2.8 MB for the list.  The hosts can be specified as either IP
addresses or hostnames, however the program will store all hosts internally
as IP addresses and will only display IP addresses in the output (ike-scan
calls gethostbyname(3) to determine the IP address of each host, but this can
be disabled with the --nodns (-N) option).

4.2. Rate Limiting

The program limits the rate at which it sends IKE packets to ensure that
it does not overload the network connection.  By default the rate limit
is one packet every 80ms which equates to a data rate of 36400 bits per
second given the default packet size of 364 bytes.  For faster links, the
packet rate can be raised by lowering the minimum packet interval using
--interval=<n> which sets the minimum packet interval to n ms.  ike-scan
uses select(2) and gettimeofday(2) to implement the rate limiting.

To determine the required inter-packet interval to acheive a given bandwidth,
you can use the following formula:

interval in ms = ((packet size in bytes * 8) / bandwidth in bps) * 1000

E.g. if you want to use a bandwidth of 64000 bits per second with a packet size
of 364 bytes, you would need an interval of:

((364 * 8) / 64000) * 1000 = 45.5 ms

4.3. Cookie Generation and Remote Host Identification

ike-scan generates unique IKE cookies for each host, and it uses these
cookies to determine which host the response packets belong to.  Note that
it does not rely on the source IP address of the response packets because
it is possible for a response packet to be sent from a different IP address
than it was originally sent to.  See the PROGRAM OUTPUT section for an
example of this.

The cookies are generated by taking the first 64 bits of an MD5 hash of the
current time in seconds and microseconds as returned by gettimeofday(), the
unique host number, and the host IP address.  This ensures that the cookies
are unique with a reasonable degree of certainty.

If --verbose (-v) is in effect, any packets that are received with cookies that
do not match will result in a message like:

---	Ignoring 84 bytes from 172.16.2.2 with unknown cookie 195c837e5a39f657

If --verbose is not in effect, such packets are silently ignored.

This type of cookie mismatch may be caused by:

a) The host is still returning IKE responses to a previous ike-scan run;
b) The packet is not an IKE packet or has been corrupted somehow; or
c) An IKE packet which is nothing to do with ike-scan has been received.

4.4. IKE Packet Details

The main mode packets sent contain an ISAKMP header and an SA payload.  The SA
payload contains a single proposal, and the proposal can contain a variable
number of transforms as detailed below.

By default, the SA proposal contains 8 transforms.  These 8 transforms
represent all possible combinations of:
a) Encryption Algorithm: DES-CBC and 3DES-CBC;
b) Hash Algorithm: MD5 and SHA; and
c) DH Group: 1 (MODP 768) and 2 (MODP 1024).

An example tcpdump output of the main mode packet sent by ike-scan using
the default transform set is shown below.  This shows the 8 transforms and
also shows the order in which they are sent:

16:57:16.024536 192.168.124.8.500 > 172.16.2.2.500:  [udp sum ok]isakmp 1.0 msgid 00000000: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=8
            (t: #1 id=ike (type=enc value=3des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
            (t: #2 id=ike (type=enc value=3des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
            (t: #3 id=ike (type=enc value=1des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
            (t: #4 id=ike (type=enc value=1des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
            (t: #5 id=ike (type=enc value=3des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp768)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
            (t: #6 id=ike (type=enc value=3des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp768)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
            (t: #7 id=ike (type=enc value=1des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp768)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080))
            (t: #8 id=ike (type=enc value=1des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp768)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)))) (DF) (ttl 64, id 0, len 364)

This default transform set is designed to be acceptable to most IKE
implementations - most will accept at least one of the offered transforms.
However, it is sometimes necessary to use a different authentication method
(pre-shared key is the most common, but is not always supported), and
occasionally it is necessary to specify a different cipher such as 256-bit
AES. More rarely it may be necessary to change the lifetime.  Finally, some
implementations require a specific "Vendor ID" string to be sent by the client
before they will respond.  This can be specified with the --vendor option.

The default transform set results in a packet data length of 336 bytes which
when IP and UDP headers are added gives a total packet size of 364 bytes.

It is possible to specify the Authentication Method with --auth
(default is 1 - pre-shared key) and the IKE lifetime in seconds with
--lifetime (default is 28800 seconds or 8 hours as recommended by RFC 2407).
If you specify --lifetime as 0, then no lifetime attribute is included in
the transfrom payloads.  If you are specifying custom transforms, you can
you can use this option more than once to produce transform payloads with
different lifetimes.  Each --trans option will use the previously specified
lifetime value.

It is possible to specify a custom transform set with
--trans=e[/l],h,a,g where "e" is the Encryption Algorithm, "l" is the key
length for variable length ciphers, "h" is the Hash Algorithm, "a" is the
Authentication Method and g is the DH Group.  These are specified as
numeric values; see RFC 2409 Appendix A for details of which values to use.
For example: "--trans=5,2,1,2" specifies:
Enc=5 (3DES-CBC), Hash=2 (SHA1), Auth=1 (shared key), DH Group=2 (modp 1024)
and "--trans=7/256,1,1,5" specifies:
Enc=7 (AES), Keylen=256 bits, Hash=MD5, Auth=shared key, DH Group=5 (modp 1536)
You can use the --trans option more than once to send an arbitary number of
custom transforms in the proposal.

Specifying a custom transform set overrides any authentication method
specified with --auth.  However, it still uses the lifetime value specified
in the last --lifetime option.

An example of a complex custom transform set is:

--trans=5,2,1,2 --lifetime=0 --trans=7/256,1,3,5 --lifetime=600
--trans=7/128,1,3,5

This would specify the following three transforms:

a) 3DES Encryption with SHA1 hash, shared key authentication, DH group 2,
   and the default lifetime;

b) 256-bit AES Encryption with MD5 hash, RSA authentication, DH group 5,
   and no lifetime; and

b) 128-bit AES Encryption with MD5 hash, RSA authentication, DH group 5,
   and lifetime of 600 second.

If a custom transform set is specified, the packet length will differ from
the default.  Fewer than 8 transforms will make it smaller, and more than
8 transforms will make it larger.  If the packet size exceeds the MTU, then
it will be fragmented.  You may need to increase the --interval setting for
large packets to avoid overloading your network connection.  Some VPN servers
may ignore very long packets.

A custom transform can be useful in the following situations:
a) If none of the transforms in the default transform set is acceptable to
   the remote IKE implementation;
b) If you know that a particular transform will be acceptable, and you want
   to minimise bandwidth use or allow faster scanning rates; or
c) If you want to determine exactly which transforms a remote IKE
   implementation supports for fingerprinting.

The default mode used is Main Mode.  However, it is possible to specify
Aggressive Mode with the --aggressive option.  When this is done, three
additional payloads will be included: Key Exchange, Nonce and ID.  This will
increase the packet size, and you may need to increase --interval to ensure
that ike-scan doesn't try to use too much bandwidth as a result.  If you use
Aggressive Mode, you can also use the following options:

--id		Set identification value.
--idtype	Set identificatiion type (Default 3 (ID_USER_FQDN)).
--dhgroup	Specify Diffie-Hellman group (Default 2 - MODP 1024).

If you use Aggressive Mode, then you can only use one Diffie Hellman group
in the transform set.  If you specify custom transforms with the --trans
option, you should ensure that they all use the same group, and that this
group matches the DH group specified with the --dhgroup option, or the default
of 2 if --dhgroup is not specified.

IKE hosts may respond in one of two ways:

a) With an IKE main or aggressive mode response packet containing the cookie
   that was originally sent to the host.  This is a "handshake" response and
   indicates that the host supports IKE and finds our proposal acceptable; or

b) With an IKE notify message containing the cookie that was originally sent
   to the host.  This is a "notify" response and indicates that the host
   is running IKE, but does not accept our proposal.

An example tcpdump output for a "handshake" response is:

16:57:48.068698 172.16.2.2.500 > 192.168.124.8.500:  [udp sum ok]isakmp 1.0 msgid 00000000: phase 1 R ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=3des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00007080)))) (ttl 126, id 37891, len 112)

This shows that the IKE host has responded with an ISAKMP header and an SA
payload containing a single proposal.  This proposal contains a single
transform representing the transform chosen from the proposal sent by ike-scan.

An example tcpdump output for a "notify" response is:

17:12:55.038554 192.168.89.22.500 > 192.168.37.1.500:  [udp sum ok]isakmp 1.0 msgid 00000000: phase 1 R inf:
    (n: doi=0 proto=1 type=NO-PROPOSAL-CHOSEN) (ttl 52, id 39577, len 68)

This shows that the IKE host has responded with an ISAKMP header and a
notify payload.  The notify payload is an informational message with the type
"NO-PROPOSAL-CHOSEN".

ike-scan does not respond to any of the IKE responses it receives, so the
IKE main mode handshake will never complete.  Some IKE implementations do
not log handshakes that don't complete; these implementations will not
log the scanning and therefore the owners of these systems will not be
aware of the scanning.  It is possible to use ike-scan to determine if
a given implementation will log these scanning attempts if you have access
to the system logs.

4.5. Backoff Fingerprinting

For those hosts that respond, ike-scan records the times of the received
IKE responses.  The backoff between IKE responses varies between different
IKE implementations and can therefore be used as a fingerprint.  The
--showbackoff option is used to display the backoff times for each host
which responded.  Note that using the --showbackoff option will cause ike-scan
to wait for 60 seconds after the last received packet to ensure that it has
seen all of the responses.  This 60 second wait can be altered by specifying
a different value in seconds to the --showbackoff option.

When all of the packets have been received, the backoff table is displayed,
and the program attempts to match the backoff pattern against the known
backoff patterns contained in the text file "ike-backoff-patterns".  It is
possible to add new patterns to this file.  If you discover new backoff
patterns, you are encouraged to submit them so that they can be included
in future releases of ike-scan.  See:
http://www.nta-monitor.com/ike-scan/submit.htm
for details on how to submit new backoff patterns.

Note that only hosts which respond with a handshake can be fingerprinted by
backoff timings; hosts which respond with a notify message cannot.  This is
because notify messages are only ever sent once and are not subject to
retransmission with backoff.

If you discover IKE hosts with backoff patterns which are not recognised by
ike-scan, then you are encouraged to submit the pattern and details of
the IKE implementation to me so I can incorporate it into future versions of
ike-scan.  See:
http://www.nta-monitor.com/ike-scan/submit.htm
For details of how to submit new backoff patterns.

Note that any packet loss will prevent the backoff fingerprinting from working
because the program needs to see all of the responses.

ike-scan can also be used to fingerprint IKE hosts in other ways.  For example:

a) Some systems (such as Checkpoint Firewall-1) allow the use of any
source port (e.g. --sport=0) whereas others (e.g. Windows 2000) only
respond to IKE requests from source port 500 (actually, Windows 2000
responds to requests from any port, but always sends the responses back
to port 500 which amounts to the same thing).

b) Some systems use proprietary notify message codes which allows them to
be identified.  For example, Checkpoint Firewall-1 4.0, 4.1 and NG Base
use notify message code 9101.  ike-scan recognises this and will identify
the system as "Checkpoint Firewall-1 4.x or NG Base".

c) Different systems support different transforms, and this support
can be determined by trying all possible combinations with --trans.
Note however, that the user can usually change the transform set, so this
cannot be relied upon by itself.

d) Different implementations require different IKE Lifetimes.  Some
implementations will accept any lifetime, whereas others will only accept
lifetimes below a certain value.

e) By using another tool (e.g. tcpdump) to sniff the returned IKE packets,
the IP ID and IP TTL can be determined.  These can be useful in
fingerprinting the IP stack which can help to determine the IKE implementation.

f) The IKE host may send Vendor ID payloads which uniquely identify the
implementation.  This Vendor ID fingerprinting method was first proposed by
Brett Eldridge <beldridg@pobox.com>.  ike-scan will display any vendor ID
payloads that it receives, and will attempt to match these against known
Vendor ID patterns.

4.6. Syslog

The program can log brief details to a syslog server if SYSLOG is defined
in ike-scan.h when the program is compiled.  You can also define the
syslog facility to use.

By default, syslog is enabled and the facility is set to "user".  The
lines in ike-scan.h that define this behaviour are:

#define SYSLOG 1                        /* Use syslog if defined */
#define SYSLOG_FACILITY LOG_USER        /* Syslog facility to use */

The messages are logged with the priority LOG_INFO.

If syslog is defined, each run of ike-scan will log two syslog messages:
one when ike-scan starts showing the arguments it was invoked with, and one
when it ends showing the number of hosts scanned and the number of transform
and notify responses received.

The maximum length of the syslog messages is limited by the MAXLINE definition
in "ike-scan.h".  At present, this is 255 which will cause runs with very large
numbers of IP addresses specified on the command line to be incompletely
reported.  If you are scanning large numbers of IP addresses, you should
really be reading them from a file or stdin rather than specifying them on the
command line.

An example of syslog output for a single ike-scan run is:

Jan 17 17:12:05 helium ike-scan[3157]: Starting: ike-scan 172.16.2.2
Jan 17 17:12:05 helium ike-scan[3157]: Ending: 1 hosts scanned. 0 returned transform; 1 returned notify

5.  PROGRAM OUTPUT

The program output consists of two sections:

a) The IKE host detection section; and
b) The IKE backoff pattern section (if --showbackoff is specified).

The IKE host detection section contains one line for each host that
responds.  The response can either be a successful handshake or an
informational message.  Only the first packet returned by any given host
is displayed in this section.

Some examples of the IKE host detection section are:

10.0.1.98	IKE Handshake returned (1 transforms)
10.0.1.22	Notify message 14 (NO-PROPOSAL-CHOSEN)
10.0.1.189	(10.0.1.130) Notify message 9101 (No common authentication method with Firewall.)

In the above example output, host 10.0.1.98 has returned an IKE handshake,
10.0.1.22 has returned notify message 14 (decimal) which corresponds to
the RFC-defined error message "NO-PROPOSAL-CHOSEN" (see RFC 2408 section
3.14.1), and 10.0.1.189 has returned a non-standard notify message 9101
but the response has come from the IP address 10.0.1.130 rather than the
address which the request was sent to (presumably this is a multi-homed
system).  Notify message 9101 is not defined by RFC 2408, but it is known
to be a Checkpoint proprietary notify code (therefore the system is probably
Firewall-1) and the program displays the text included in the notify message.

Some examples of the IKE backoff pattern section are:

IP Address      No.     Recv time               Delta Time
172.16.2.2      1       1042549209.247980       0.000000
172.16.2.2      2       1042549211.239254       1.991274
172.16.2.2      3       1042549213.241935       2.002681
172.16.2.2      4       1042549215.244731       2.002796
172.16.2.2      5       1042549217.247512       2.002781
172.16.2.2      6       1042549219.250254       2.002742
172.16.2.2      7       1042549221.253044       2.002790
172.16.2.2      8       1042549225.258551       4.005507
172.16.2.2      9       1042549229.264074       4.005523
172.16.2.2      10      1042549233.269605       4.005531
172.16.2.2      11      1042549237.275145       4.005540
172.16.2.2      12      1042549241.280654       4.005509
172.16.2.2      Implementation guess: Firewall-1 4.1/NG

10.0.1.98	1       1042549209.426540       0.000000
10.0.1.98	2       1042549224.425435       14.998895
10.0.1.98	3       1042549239.422251       14.996816
10.0.1.98	Implementation guess: Cisco IOS / PIX

Here, host 172.16.2.2 returned a total of 12 packets and the
pattern matched "Firewall-1 4.1/NG", and host 10.0.1.98 returned
3 packets matching the pattern for "Cisco IOS / PIX".  The recv
time column shows the absolute time when the packet was received
in seconds and microseconds since the epoch; delta time shows the
elapsed time between packets in seconds and microseconds.

6.  EXAMPLES

1) ike-scan 172.16.2.2

The above example will run IKE detection against the single host 172.16.2.2.
No backoff fingerprinting will be done, and all options (timeouts, retrys,
transform set Etc) will be the default.

2) ike-scan --file=hostlist.txt

This will read the target hosts from the file "hostlist.txt".

3) cat hostlist.txt | ike-scan --file=- --showbackoff=20

This reads the hosts from stdin and performs both IKE detection and backoff
fingerprinting.  The backoff wait is specified as 20 seconds.

4) ike-scan 172.16.0.0/16

This will run ike-scan against all hosts in the network specified by
172.16.0.0/16 (including network and broadcast addresses).  In this case, this
will result in a total of 65536 hosts being scanned - from 172.16.0.0 to
172.16.255.255 inclusive.

5) ike-scan 172.16.0.0-172.16.255.255

This uses the range notation to scan a total of 65536 hosts from 172.16.0.0 to
172.16.255.255 inclusive.

7.  SUPPORTED PLATFORMS

ike-scan has been built and tested on the following platforms:

Debian Linux 1.3.1 on IA32 with gcc 2.7.2.1, libc5 and 2.0.29 Kernel
Debian Linux 2.2r7 (Potato) on IA32 with gcc 2.95.2 and 2.2.17 Kernel
Debian Linux 3.0r1 (Woody) on IA32 with gcc 2.95.4 and 2.4.18 Kernel
Debian Linux 3.1 (Sarge) on IA32 with gcc 3.3.4 and 2.4.27 Kernel
Debian Linux 3.0 (Woody) on PA-RISC with gcc 3.0.4 and 2.4.17-64 Kernel
Debian Linux 3.0 (Woody) on Alpha with gcc 3.3.1 and 2.4.18-smp Kernel
Redhat Advanced Server 3.2 on IA64 with gcc 3.2.3 and 2.4.21-19.EL Kernel
HP-UX 11.11 on PA-RISC with gcc 3.4.1
HP-UX 11.11 on PA-RISC with HP cc HP92453-01 B.11.11.32003.GP
FreeBSD 4.3 on IA32 with gcc 2.95.3
OpenBSD 3.1 on IA32 with gcc 2.95.3
NetBSD 1.6 on IA32 with gcc 2.95.3
SCO OpenServer 5.0.7 on IA32 with gcc 2.95.3
Windows NT 4.0 / Cygwin 1.5.12 on IA32 with gcc 3.3.3
Solaris 2.8 on SPARC with gcc 2.95.3
HP Tru64 Unix v5.1 on Alpha with Tru64 cc
MacOS X (Darwin 7.7.0) on PowerPC

I've also had reports that it builds OK on the following systems:

RedHat Linux 7.1 with 2.4 Kernel
RedHat Linux 8.0 with 2.4 Kernel
Debian Linux 3.1 on Alpha
Debian Linux 3.1 on ARM
Debian Linux 3.1 on HP PA-RISC
Debian Linux 3.1 on Intel IA64
Debian Linux 3.1 on Motorola 68000
Debian Linux 3.1 on MIPS
Debian Linux 3.1 on PowerPC
Debian Linux 3.1 on IBM S390
Debian Linux 3.1 on SPARC

It should work, or be capable of working, on any Unix-like system which
has a 64-bit integer type, supports sockets and has the system calls malloc,
gethostbyname, gettimeofday, inet_ntoa, memset, select, socket, and strerror.

If you port ike-scan to a system not listed above, please let me know the
details of the changes required so I can add them to future releases.

8.  FURTHER READING AND RFCS

For an in-depth coverage of IPsec including IKE, I recommend the book
"IPsec The New Security Standard for the Internet, Intranets and Virtual
Private Networks" by Doraswamy and Harkins, ISBN 0-13-011898-2.  I used this
book together with the RFCs to learn about IKE.

The following RFCs relate to IKE:

RFC 2407  The Internet IP Security Domain of Interpretation for ISAKMP
RFC 2408  Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409  The Internet Key Exchange (IKE)
RFC 2412  The OAKLEY Key Determination Protocol

All of these RFCs can be obtained from: http://www.ietf.org/rfc

9.  CONTACT ADDRESS

Email:  ike-scan@nta-monitor.com

Web:  http://www.nta-monitor.com/ike-scan/

Postal address:

   Roy Hills
   NTA Monitor Limited
   14 Ashford House
   Medway City Estate
   Rochester
   Kent ME2 4FA
   UK

I would like to hear from you if you have any of the following:

a) A modern Unix-like OS which ike-scan won't build on;

b) An OS not listed in the list above which ike-scan builds and runs OK on;

c) Any IKE implementation patterns that are not already in the
   ike-backoff-patterns file.  Please include details of the pattern and
   also details of the IKE implementation;

d) Any Vendor ID pattern that is not already in the ike-vendor-ids file; or

e) Any comments or suggestions about the program.

