$Id: README 9919 2007-01-22 22:52:36Z rsh $ ike-scan - Discover and fingerprint IKE hosts (IPsec VPN Servers) Note: This README file is no longer being actively maintained. Although it is still reasonably accurate it does not cover all of ike-scan's functionality. Please refer to the ike-scan wiki at http://www.nta-monitor.com/wiki/ for up-to-date information about installing and using ike-scan and other related IPsec topics. 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 functionality 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 Aggressive 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. In the options below a letter or word in angle brackets like <f> denotes a value or string that should be supplied. The corresponding text should indicate the meaning of this value or string. When supplying the value or string, do not include the angle brackets. Text in square brackets like [<f>] mean that the enclosed text is optional. This is used for options which take an optional argument. 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. Use of the --nat-t option changes the default source port to 4500 --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. Use of the --nat-t option changes the default destination port to 4500 --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. --bandwidth=<n> or -B <n> Set desired outbound bandwidth to <n>, default=56000 The value is in bits per second by default. If you append "K" to the value, then the units are kilobits per second; and if you append "M" to the value, the units are megabits per second. The "K" and "M" suffixes represent the decimal, not binary, multiples. So 64K is 64000, not 65536. --interval=<n> or -i <n> Set minimum packet interval to <n> ms. The packet interval will be no smaller than this number. The interval specified is in milliseconds by default. if "u" is appended to the value, then the interval is in microseconds, and if "s" is appended, the interval is in seconds. If you want to use up to a given bandwidth, then it is easier to use the --bandwidth option instead. You cannot specify both --interval and --bandwidth because they are just different ways to change the same underlying variable. --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 retries 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 separate 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 this as a a decimal integer, e.g. 86400, then the attribute will use a 4-byte value. If you specify it as a hex number, e.g. 0xFF, then the attribute will use the appropriate size value (one byte for this example). If you specify the string "none" then no lifetime attribute will be added at all. 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 this as a a decimal integer, e.g. 86400, then the attribute will use a 4-byte value. If you specify it as a hex number, e.g. 0xFF, then the attribute will use the appropriate size value (one byte for this example). 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 (PSK). 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. This is not applicable to IKEv2. --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. You can use this option more than once to send an arbitrary number of custom transforms. There are two ways to specify the transform: The new way, where you specify the attribute/value pairs, and the old way where you specify the values for a fixed list of attributes. For the new method, the transform <t> is specified as (attr=value, attr=value, ...) Where "attr" is the attribute number, and "value" is the value to assign to that attribute. You can specify an arbitary number of attribute/value pairs. See RFC 2409 Appendix A for details of the attributes and values. Note that brackets are special to some shells, so you may need to quote them, e.g. --trans="(1=1,2=2,3=3,4=4)". For example, --trans=(1=1,2=2,3=1,4=2) specifies Enc=3DES-CBC, Hash=SHA1, Auth=shared key, DH Group=2; and --trans=(1=7,14=128,2=1,3=3,4=5) specifies Enc=AES/128, Hash=MD5, Auth=RSA sig, DH Group=5. For the old method, the transform <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. 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. This option is not yet supported for IKEv2. --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=500. 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 backoff 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 and IKEv2. For both of these, it is used to determine the size of the key exchange payload. If you use Aggressive Mode with custom transforms, then you will normally need to use the --dhgroup option unless you are using the default DH group. 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. --noncelen=<n> or -c <n> Set the nonce length to <n> bytes. Default=20 This option controls the length of the nonce payload that is sent in an aggressive mode or IKEv2 request. Normally there is no need to use this option unless you want to reduce the nonce size to speed up pre-shared key cracking, or if you want to see how a particular server handles different length nonce payloads. RFC 2409 states that the length of nonce payload must be between 8 and 256 bytes, but ike-scan does not enforce this. Specifying a large nonce length will increase the size of the packet sent by ike-scan. A very large nonce length may cause fragmentation, or exceed the maximum IP packet size. This option is only applicable to IKE aggressive mode. --headerlen=<n> or -L <n> Set the length in the ISAKMP header to <n> bytes. You can use this option to manually specify the value to be used for the ISAKMP header length. By default, ike-scan will fill in the correct value. Use this option to manually specify an incorrect length. <n> can be specified as "+n" which sets the length to n bytes more than it should be, "-n" which sets it to n bytes less, or "n" which sets it to exactly bytes. Changing the header length to an incorrect value can sometimes disrupt VPN servers. --mbz=<n> or -Z <n> Use the value <n> for reserved (MBZ) fields, default=0. Specifying this option makes the outgoing packet non-RFC compliant, and should only be used if you want to see how a VPN server will respond to invalid packets. The value of <n> should be in the range 0-255. --headerver=<n> or -E <n> Specify the ISAKMP header version. The default is 0x10 (16) which corresponds to v1.0. Specifying a non-default value will make the outgoing packet non-RFC compliant, and should only be used if you want to see how the VPN server reacts to strange versions. The value should be in the range 0-255. --certreq=<c> or -C <c> Add the CertificateRequest payload <c>. <c> should be specified as a hex value. The first byte of the hex value will be interpreted as the certificate type; the remaining bytes as the certificate authority as described in RFC 2408 3.10. The certificate types are listed in RFC 2408 sec 3.9. RFC 2048 states "The Certificate Request payload MUST be accepted at any point during the exchange" --doi=<d> or -D <d> Set the SA DOI to <d>, default 1 (IPsec). You will not normally want to change this unless you want to see how the VPN server responds to a non-standard DOI. --situation=<s> or -S <s> Set the SA Situation to <d>, default 1. The meaning of the situation depends on the DOI, and is detailed in the appropriate DOI document. For the IPsec DOI, the default Situation of 1 represents SIT_IDENTITY_ONLY. You will not normally want to change this unless you want to see how the VPN server responds to a non-standard situation. --protocol=<p> or -j <p> Set the Proposal protocol ID to <p>, default 1. The meaning of the proposal protocol ID depends on the DOI, and is detailed in the appropriate DOI document. For the IPsec DOI, the default proposal protocol id of 1 represents PROTO_ISAKMP. You will not normally want to change this unless you want to see how the VPN server responds to a non-standard protocol ID. --transid=<t> or -k <t> Set the Transform ID to <t>, default 1. The meaning of the transform ID depends on the DOI, and is detailed in the appropriate DOI document. For the IPsec DOI, the default transform id of 1 represents KEY_IKE. You will not normally want to change this unless you want to see how the VPN server responds to a non-standard transform ID. --spisize=<n> Set the proposal SPI size to <n>. Default=0 If this is non-zero, then a random SPI of the specified size will be added to the proposal payload. The default of zero means no SPI. --hdrflags=<n> Set the ISAKMP header flags to <n>. Default=0 The flags are detailed in RFC 2408 section 3.1 --hdrmsgid=<n> Set the ISAKMP header message ID to <n>. Default=0 This should be zero for IKE Phase-1. --cookie=<n> Set the ISAKMP initiator cookie to <n> The cookie value should be specified in hex. By default, the cookies are automatically generated and have unique values. If you specify this option, then you can only specify a single target, because ike-scan requires unique cookie values to match up the response packets. --exchange=<n> Set the exchange type to <n> This option allows you to change the exchange type in the ISAKMP header to an arbitrary value. Note that ike-scan only supports Main and Aggressive modes (values 2 and 4 respectively). Specifying other values will change the exchange type value in the ISAKMP header, but will not adjust the other payloads. The exchange types are defined in RFC 2408 sec 3.1. --nextpayload=<n> Set the next payload in the ISAKMP header to <n> Normally, the next payload is automatically set to the correct value. --randomseed=<n> Use <n> to seed the pseudo random number generator. This option seeds the PRNG with the specified number, which can be useful if you want to ensure that the packet data is exactly repeatable when it includes payloads with random data such as key exchange or nonce. By default, the PRNG is seeded with an unpredictable value. --timestamp Display timestamps for received packets. This option causes a timestamp to be displayed for each received packet. --sourceip=<s> Set source IP address for outgoing packets to <s>. This option causes the outgoing IKE packets to have the specified source IP address. The address can either be an IP address in dotted quad format, or the string "random" which will use a different random source address for each packet that is sent. If this option is used, no packets will be received This option requires raw socket support, and you will need superuser privileges to use this option, even if you specify a high source port. This option does not work on all operating systems. --shownum Display the host number for received packets. This displays the ordinal host number of the responding host before the IP address. It can be useful when sending many packets to the same target IP, to see if any probes are being ignored. --nat-t Use RFC 3947 NAT-Traversal encapsulation. This option adds the non-ESP marker to the beginning of outgoing packets and strips it from received packets, as described in RFC 3947. It also changes the default source port to 4500 and the default destination port to 4500, which are the ports for NAT-T IKE. These port numbers can be changed with the --sport and --dport options, providing they are used after the --nat-t option. --rcookie=<n> Set the ISAKMP responder cookie to <n>. This sets the responder cookie to the specified hex value. By default, the responder cookie is set to zero. --ikev2 or -2 Use IKE version 2 This causes the outgoing packets to use IKEv2 format as defined in RFC 4306 instead of the default IKEv1 format. Any packets returned are automatically decoded as IKE or IKEv2 depending on their payloads irrespective of this option. The --ikev2 option is currently experimental. It has not been extensively tested, and it only supports sending the default proposal. Report bugs or send suggestions to ike-scan@nta-monitor.com See the ike-scan homepage at http://www.nta-monitor.com/tools/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 it uses an outbound data rate of 56000 bits per second. This can be changed with the --bandwidth option. If you want to send packets at a specific rate, you can use the --interval option. 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-1; 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 transform 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 arbitrary 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 identification 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/tools/ike-scan/submit-patterns.html 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/tools/ike-scan/submit-patterns.html 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/tools/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.