269 lines
12 KiB
Text
269 lines
12 KiB
Text
# The IKE Scanner (ike-scan) is Copyright (C) 2003-2007 Roy Hills,
|
|
# NTA Monitor Ltd.
|
|
#
|
|
# This program is free software; you can redistribute it and/or
|
|
# modify it under the terms of the GNU General Public License
|
|
# as published by the Free Software Foundation; either version 2
|
|
# of the License, or (at your option) any later version.
|
|
#
|
|
# This program is distributed in the hope that it will be useful,
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
# GNU General Public License for more details.
|
|
#
|
|
# You should have received a copy of the GNU General Public License
|
|
# along with this program; if not, write to the Free Software
|
|
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
#
|
|
# If this license is unacceptable to you, I may be willing to negotiate
|
|
# alternative licenses (contact ike-scan@nta-monitor.com).
|
|
#
|
|
# $Id: ike-backoff-patterns 9919 2007-01-22 22:52:36Z rsh $
|
|
#
|
|
# ike-backoff-patterns -- Backoff patterns file for ike-scan
|
|
#
|
|
# Author: Roy Hills <Roy.Hills@nta-monitor.com>
|
|
#
|
|
# Format:
|
|
# Implementation_Name<Tab>Backoff_Pattern
|
|
#
|
|
# Implementation_Name is a descriptive name for the IKE implementation
|
|
# (and version if applicable). Backoff_Pattern is the observed IKE
|
|
# retransmission backoff pattern for this implementation.
|
|
#
|
|
# The backoff pattern is specified as a comma-separated list of backoff
|
|
# times in seconds. The first number is always zero and represents the first
|
|
# packet received. Subsequent numbers represent the expected delay in
|
|
# seconds after the previous packet. For example, "0, 2, 2, 2" means that a
|
|
# total of four packets are sent with a delay of two seconds between each one.
|
|
#
|
|
# The numbers in the backoff pattern can be decimal numbers e.g. 1.5 for
|
|
# one and a half seconds. You can specify up to a maximum of 6 digits
|
|
# after the decimal point (microsecond resolution), although anything
|
|
# beyond millisecond resolution is not really practical. ike-scan uses
|
|
# a timeval struct to store the backoff pattern entries.
|
|
#
|
|
# You may also specify an per-pattern-entry "fuzz" value in milliseconds
|
|
# by appending /<fuzz> to the backoff time. This will override the default
|
|
# fuzz for that time only. The fuzz value specifies how close the specified
|
|
# time must be to the observed time for a match. E.g. a fuzz of 0 means that
|
|
# the observed timing must match exactly and a fuzz of 1000 means that the
|
|
# times must be within one second of each other (1000ms = 1sec). If no
|
|
# per-pattern-entry fuzz value is specified then a default fuzz value of 100ms
|
|
# (defined by DEFAULT_PATTERN_FUZZ in ike-scan.h) is applied. This default
|
|
# value may be changed with the --fuzz option to ike-scan.
|
|
#
|
|
# Lines beginning with '#' and blank lines are ignored.
|
|
#
|
|
# The input format is quite strict. In particular, the separator between
|
|
# the implementation name and the backoff pattern must be a single TAB and
|
|
# not a space, multiple tabs or spaces, or a mixture of tabs and spaces.
|
|
#
|
|
# If you have problems adding entries, run ike-scan as:
|
|
# ike-scan -v -v -v -o <any-target>
|
|
# To dump the backoff pattern table.
|
|
#
|
|
# You are encouraged to send comments, improvements or suggestions to
|
|
# me at ike-scan@nta-monitor.com.
|
|
# In particular, I would like you to submit any new patterns that you
|
|
# discover. See: http://www.nta-monitor.com/tools/ike-scan/submit-patterns.html
|
|
# For details of how to submit new backoff patterns.
|
|
#
|
|
|
|
# Discovered by: Roy Hills, November 2002
|
|
# Observed on: Cisco 2503 running IP-PLUS-IPsec56 IOS 11.3(11b)T2
|
|
# Observed on: Cisco 2503 running IP-PLUS-IPsec56 IOS 12.0(28c)
|
|
# Observed on: Cisco PIX 520 running 5.1(2)
|
|
# Observed on: Cisco PIX 520 running 5.2(9)
|
|
# Observed on: Cisco PIX 520 running 5.3(4)
|
|
# Observed on: Cisco PIX 520 running 6.0(4)
|
|
# Observed on: Cisco PIX 520 running 6.1(5)
|
|
# Observed on: Cisco PIX 520 running 6.2(4)
|
|
# Note: Cisco IOS 12.1, 12.2 and 12.3 (and possibly later versions as well)
|
|
# have a different pattern: 0,10,10,10,10,10. This is listed later
|
|
# under a different name.
|
|
# Note: PIX OS 6.3 has a different pattern: 0, 5, 5, 5, 5, 5. This is listed
|
|
# under a different name.
|
|
# Note: IPsec was introduced in Cisco IOS 11.3. Previous versions only
|
|
# supported the Cisco proprietary CET encryption.
|
|
Cisco IOS 11.3 or 12.0 / PIX <= 6.2 0, 15, 15
|
|
|
|
# Discovered by: Tony Lloyd, May 2006
|
|
# Observed on: Cisco PIX 520 running PIXOS 6.3(5)
|
|
Cisco PIX >= 6.3 0, 5, 5, 5, 5, 5
|
|
|
|
# 1st Pattern Discovered by: Roy Hills, November 2002
|
|
# Observed on: Cisco VPN Concentrator 3005 running (unknown version)
|
|
# Observed on: VPN 3000 Concentrator Version 3.6.3.Rel Oct 04 2002 16:23:00
|
|
# 2nd Pattern Discovered by: Guy Widloecher, March 2003
|
|
# Observed on: Cisco VPN 3005 Concentrator Version 3.5.2
|
|
# There are several models: 3005, 3015, 3020, 3030, 3060 and 3080, which are
|
|
# equivalent to the old Altiga C5, C15 Etc. All models are believed to share
|
|
# the same backoff pattern.
|
|
Cisco VPN Concentrator 0, 8, 8, 8
|
|
Cisco VPN Concentrator 0, 8, 8
|
|
|
|
# Discovered by: Roy Hills, December 2002
|
|
# Observed on: Checkpoint Firewall-1 4.0 SP7 on Windows NT Workstation 4.0 SP6a
|
|
Firewall-1 4.0 0, 3, 3, 3, 3, 6, 6, 6, 6, 6, 6, 6
|
|
|
|
# Discovered by: Roy Hills, November 2002
|
|
# Observed on: Checkpoint Firewall-1 4.1 SP6 on Windows NT Server 4.0 SP6a
|
|
# Observed on: Checkpoint Firewall-1 NG base on Windows NT Server 4.0 SP6a
|
|
# Observed on: Checkpoint Firewall-1 NG FP2 on Windows NT Server 4.0 SP6a
|
|
# Observed on: Checkpoint Firewall-1 NGX R60 on Windows 2003 Server
|
|
Firewall-1 4.1/NG/NGX 0, 2, 2, 2, 2, 2, 2, 4, 4, 4, 4, 4
|
|
|
|
# Discovered by: Roy Hills, December 2002
|
|
# Observed on: FreeS/WAN 1.9 on Debian Linux 2.2r7 (Potato) with 2.2.17 Kernel
|
|
# Observed on: strongSwan 4.0.5 on Debian Etch with 2.6.18 kernel
|
|
# Observed on: OpenSwan 2.2.0 on Debian Sarge with 2.6.16 kernel
|
|
Linux FreeS/WAN, OpenSwan, strongSwan 0, 10, 20
|
|
|
|
# Discovered by: Roy Hills, November 2002
|
|
# Additional fuzz on 1st retry suggested by Florent Trupheme, April 2005
|
|
# Observed on: Nortel Contivity 2500, OS version V4.06-120
|
|
# Observed on: Nortel Contivity 1600, OS version V3.60-45
|
|
Nortel Contivity 0, 16/600, 16, 16
|
|
|
|
# Discovered by: Roy Hills, December 2002
|
|
# Observed on: Watchguard Firebox 700 v6.1
|
|
# Observed on: Gnat Box (version unknown)
|
|
# Observed on: Cisco 2503 running IP-PLUS-IPsec56 IOS 12.1(27a)
|
|
# Observed on: Cisco 2503 running IP-PLUS-IPsec56 IOS 12.2(29)
|
|
# Observed on: Cisco 2621 running IP/FW/IDS Plus IPsec 3DES Basic 12.3(17a)
|
|
# Note that the Gnat box has a much larger variance than the watchguard, but
|
|
# they are both essentially the same pattern.
|
|
Cisco IOS 12.1, 12.2 or 12.3 / Watchguard Firebox / Gnat Box 0, 10/1000, 10/1000, 10/1000, 10/1000, 10/1000
|
|
|
|
# Discovered by: Roy Hills, December 2002
|
|
# Observed on: Windows 2000 Server SP1
|
|
# Observed on: Windows XP Pro SP1
|
|
# Note: Backoff fingerprinting cannot distinguish between 2000, 2003 and XP,
|
|
# but vendor IDs can.
|
|
Windows 2000, 2003 or XP 0, 1, 2, 4, 8, 16, 32
|
|
|
|
# 1st pattern Discovered by: Thomas Walpuski, Jan 2003
|
|
# Observed on: Various OpenBSD systems running isakmpd
|
|
# 2nd pattern discovered by: Marco Ivaldi <raptor@mediaservice.net>, Jan 2003
|
|
# Observed on: OpenBSD 3.2
|
|
# Observed on: FreeBSD 4.7-Stable with isakmpd-20021118 and OpenBSD 3.1
|
|
# Note: OpenBSD isakmpd is highly configurable, so it's difficult to get one
|
|
# pattern which will match all possible backoff pattern.
|
|
# Hakan Olsson has informed me that the actual algorithm used by isakmpd
|
|
# is "5 + 2*<retrans#>" which can be found in transport.c, ca line 310.
|
|
# Both patterns match this algorithm: the first with the default
|
|
# retransmission limit of 3 and the second with retransmits set to 5.
|
|
# It has also been pointed out that isakmpd can run on many platforms
|
|
# other than FreeBSD and OpenBSD, so the inclusion of these OS names in
|
|
# the pattern are misleading. However, I'm leaving the names unchanged
|
|
# in case someone relies on them in the program output.
|
|
FreeBSD/OpenBSD-isakmpd 0, 7, 9, 11
|
|
FreeBSD/OpenBSD-isakmpd 0, 7, 9, 11, 13, 15
|
|
|
|
# Discovered by: Paul van Maaren, January 2003
|
|
# 1st pattern observed Jan 2003 on: FreeBSD-4.7 STABLE with racoon-20021120a
|
|
# 2nd pattern observed Jun 2005 on: FreeBSD-5.3-RELEASE with racoon-20050510a
|
|
KAME/racoon-1 0, 20, 20, 20, 20, 20
|
|
KAME/racoon-2 0, 21.5, 21.5, 21.5, 21.5, 21.5
|
|
|
|
# Discovered by: Iain Lewis, February 2003
|
|
# Observed on: Netscreen 500
|
|
# Observed on: Netscreen 5GT running ScreenOS 5.1.0r1.0
|
|
Juniper-Netscreen 0, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4
|
|
|
|
# Discovered by: Doug Monroe, January 2003
|
|
# Observed on: Watchguard SOHO v5.1.7
|
|
# Note: There is quite a bit of variation with this pattern, hence the
|
|
# per-entry fuzz specifications.
|
|
watchguard-soho 0, 1/500, 9.5/3000, 1.5/2000, 9.5/3000, 1.5/2000, 9.5/3000, 1.5/2000, 9.5/3000, 1.5/2000, 9.5/3000, 1.5/2000
|
|
|
|
# Discovered by: Christopher Harrington, February 2003
|
|
# Observed on: SonicWall Pro 200
|
|
# Note: There is quite a bit of variation with this pattern, hence the
|
|
# per-entry fuzz specifications.
|
|
sonicwall-pro 0, 6.5/1500, 9/1000, 13/2000, 22/3000
|
|
|
|
# Discovered by: Florent Trupheme, April 2005
|
|
# Observed on Side Winder G2 Firewall
|
|
# Also observed on a separate Sidewinder G2 by Tim Ecott, July 2005
|
|
# Two different patterns have been observed: the 0,3,6,15,48 appears to be the
|
|
# more common one, but 0,3,4,12,36 has also been seen.
|
|
SideWinder G2 Firewall 0, 3, 6, 15, 48
|
|
SideWinder G2 Firewall 0, 3, 4, 12, 36
|
|
|
|
# Discovered by: Florent Trupheme, April 2005
|
|
# Observed on SonicWall unknown version
|
|
# Interestingly, this is different from the earlier sonicwall-pro entry.
|
|
Sonic Wall 0, 5, 8, 18
|
|
|
|
# Discovered by: Roy Hills, December 2003
|
|
# Observed on: Windows 2003 Server Enterprise Edition, Intel platform
|
|
# Note: The 2nd packet delay has been observed to vary between 0.5 and 1.5 sec.
|
|
# Otherwise, this is the same pattern as Windows 2000. Note that if the
|
|
# Win-2003 server happens to pick a delay of around 1 sec for the 2nd
|
|
# Packet, then ike-scan will mis-identify as Win-2000. Vendor ID
|
|
# payloads can distinguish Win-2003 from Win-2000 in any event, but
|
|
# that's another story.
|
|
Windows-2003 0, 1/600, 2, 4, 8, 16, 32
|
|
|
|
# Discovered by: Bob Davies, March 2004
|
|
# Observed on Lynksys router, Unknown version
|
|
Lynksys 0, 15/500, 15, 15
|
|
|
|
# Discovered by: Tony Lloyd, January 2005
|
|
# Observed on: suspected bordermanager box
|
|
# July 2006: Observed on: BorderManager 3.8 on NetWare 6.5
|
|
Novell-BorderManager 0, 4.5/1000, 6.9, 9.8
|
|
|
|
# Discovered by: Tony Lloyd, April 2005
|
|
# Observed on: Draytek ADSL Routers (several different versions)
|
|
draytek 0, 3, 6
|
|
|
|
# Discovered by: Tony Lloyd, June 2005
|
|
# Observed on: Cyberguard Firewall (exact model and version unknown)
|
|
cyberguard 0, 3.5, 7, 10, 10
|
|
|
|
# Discovered by: Tony Lloyd, June 2005
|
|
# Observed on: Fortinet FortiGate Firewall (exact model and version unknown)
|
|
# Note: some FortiGate Firewalls appear to have a 0,10,20 pattern instead
|
|
FortiGate 0, 6, 12
|
|
|
|
# Discovered by: Tony Lloyd, August 2005
|
|
# Observed on: Avaya VSU 100R
|
|
# The backoffs have quite a bit of variance, but the delays always seem to be
|
|
# between 13.3 and 15.7 seconds.
|
|
Avaya VSU 0, 14.5/1200, 14.5/1200, 14.5/1200, 14.5/1200
|
|
|
|
# Discovered by: Tony Lloyd, September 2005
|
|
# Observed on: Stonegate V2.2.0 on Linux
|
|
Stonegate 0, 0.5, 1, 2, 4, 8, 16, 30, 30, 30, 30
|
|
|
|
# Discovered by Paul Askew, December 2005
|
|
# Observed on: Netgear FVS328 ProSafe VPN Firewall Version 1.0.15
|
|
# The time between the first and second packets has quite a bit of variance,
|
|
# but the delays between subsequent packets do not.
|
|
Netgear ProSafe 0, 4.5/1000, 5, 5, 5
|
|
|
|
# Discovered by Paul Askew, December 2005
|
|
# Observed on: Netgear DG834V2 ADSL Firewall Router Version 2.10.22
|
|
# Interestingly, the backoff pattern for this device differs from that for
|
|
# the Netgear FVS328 ProSafe VPN Firewall.
|
|
Netgear ADSL Firewall Router 0, 10, 20
|
|
|
|
# Discovered by Roy Hills, October 2006
|
|
# Observed on: Linksys Etherfast DSL/Cable VPN Router, Model BEFVP41 V2 s/w 1.01.04
|
|
# Not really a pattern as the Linksys doesn't retransmit at all. However, this
|
|
# lack of retransmission is sufficiently unusual to be a pattern itself.
|
|
Linksys Etherfast 0
|
|
|
|
# Discovered by Roy Hills, November 2005
|
|
# Observed on: IBM RS/6000 runninx AIX 5.3
|
|
IBM AIX 0, 16, 32
|
|
|
|
# Discovered by Roy Hills, January 2007
|
|
# Observed on: Solaris 9/SPARC running on Ultra-5
|
|
#
|
|
# Sun's IPsec was introduced in Solaris 8, but this was manual keying only;
|
|
# IKE keying was not introduced until Solaris 9.
|
|
Sun Solaris 0, 0.5, 1, 2, 4, 8
|