gecloud.ch/security-scripts
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
security-scripts/vpn/ike-scan-1.9/README
Peter Baumann ec0003bfa8 added vpn scripts
2013-06-04 17:07:08 +02:00

1042 lines
47 KiB
Text
Raw Permalink Blame History

$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.
Reference in a new issue View git blame Copy permalink