Difference between revisions of "Cisco PIX"
(→Vendor IDs) |
(No difference)
|
Latest revision as of 19:34, 18 August 2011
Contents
- 1 Platform Notes
- 2 Version History
- 3 Backoff Patterns
- 4 Vendor IDs
- 5 Authentication Methods
- 6 ISAKMP SA Lifetime
- 7 Transform ordering and rewriting
- 8 Aggressive Mode
- 9 Response to Noncompliant and Malformed Packets
- 10 NAT Traversal
- 11 IKEv2
- 12 Remote Access VPN Client
- 13 Other Interesting Behaviour
- 14 Default Configuration
Platform Notes
Cisco PIX runs on proprietary hardware that is based on an Intel x86 CPU.
The PIX operating system is now called PIX OS, but its original name was Finesse (Fast INternEt Server Executive). This name can still be observed by the string 'Finesse floppy bootstrap (V2.0)' near the beginning of the OS image file. Below is an example from the PIX OS 7.2(1) image file:
0000700 nul nul cr nl F i n e s s e sp f l o p 0000720 p y sp b o o t s t r a p sp ( V 2 0000740 . 0 ) cr nl nul f nul nul nul nul stx dc2 esc del nul
The PIX can be used for both site-to-site and remote access IPsec VPNs, but site-to-site is more common.
Version History
Version | Release Date | Notes |
---|---|---|
4.0 | ||
4.1 | Sep 1997 | |
4.2 | ||
4.3 | Feb 1999 | |
4.4 | Jun 1999 | |
5.0 | ||
5.1 | ||
5.2 | Sep 2000 | XAUTH authentication support |
5.3 | Dec 2000 | |
6.0 | Aug 2001 | Windows L2TP/IPSec support |
6.1 | Dec 2001 | |
6.2 | May 2002 | |
6.3 | Mar 2003 | AES encryption, VPN Accelerator Card+, NAT Traversal, DH Group 5 |
7.0 | Mar 2005 | DH Group 7 (ECC) |
7.1 | Feb 2006 | |
7.2 | May 2006 | Hybrid authentication |
8.0 | Jun 2007 |
The dates in this table were taken from the release notes. Where possible this was from the release notes for the (1) release.
IPsec support was first added around PIX OS 4.2 or 4.3. Originally this used the RedCreek Ravlin PCI/45 card, later the PIX used its own IPsec implementation. The exact dates and versions are not known.
Backoff Patterns
There are three different backoff patterns for PIX:
- 0, 15, 15 - Up to and including version 6.2
- 0, 5, 5, 5, 5, 5 - Version 6.3
- 0, 8, 8, 8 - Version 7.0
Note that the last pattern is the same as that for the Cisco VPN Concentrator 3000.
Pattern #1 - 0, 15, 15
This pattern has been observed on the PIX OS 5.1(2), 5.2(9), 5.3(4), 6.0(4), 6.1(5) and 6.2(4). This three-packet backoff pattern is also generated by Cisco IOS 11.3 and 12.0 (but not later IOS versions, which have a separate pattern). It is not known if this is coincidence, or if it indicates that the code has a common source.
Here is an example of the old backoff pattern from a PIX 520 running PIX OS 6.2(4):
$ ike-scan -M --showbackoff 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f96326b1159c) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) IKE Backoff Patterns: IP Address No. Recv time Delta Time 192.168.124.154 1 1170495500.587673 0.000000 192.168.124.154 2 1170495515.579325 14.991652 192.168.124.154 3 1170495530.577177 14.997852 192.168.124.154 Implementation guess: Cisco IOS 11.3 or 12.0 / PIX <= 6.2
Pattern #2 - 0, 5, 5, 5, 5, 5
This pattern has been observed on PIX OS 6.3(5). It is unique to PIX, and is not generated by any version of Cisco IOS. Here is an example of the new backoff pattern from a PIX 520 running PIX OS 6.3(5):
$ ike-scan -M --showbackoff 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f96306fe758f) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) IKE Backoff Patterns: IP Address No. Recv time Delta Time 192.168.124.154 1 1170494449.831231 0.000000 192.168.124.154 2 1170494454.826044 4.994813 192.168.124.154 3 1170494459.825283 4.999239 192.168.124.154 4 1170494464.824547 4.999264 192.168.124.154 5 1170494469.823799 4.999252 192.168.124.154 6 1170494474.823060 4.999261 192.168.124.154 Implementation guess: Cisco PIX >= 6.3
Pattern #3 - 0, 8, 8, 8
This pattern has been observed on PIX OS 7.0(1).
It is the same pattern as that produced by the Cisco VPN Concentrator 3000. It is not known if this is coincidence, or if it indicates that the code has a common source.
$ ike-scan -M --showbackoff 192.168.124.150 Starting ike-scan 1.9.1 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.150 Main Mode Handshake returned HDR=(CKY-R=85aecaf99749dfe2) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) IKE Backoff Patterns: IP Address No. Recv time Delta Time 192.168.124.150 1 1203685056.329436 0.000000 192.168.124.150 2 1203685064.329919 8.000483 192.168.124.150 3 1203685072.330683 8.000764 192.168.124.150 4 1203685080.331149 8.000466 192.168.124.150 Implementation guess: Cisco VPN Concentrator
Vendor IDs
In Main Mode, Cisco PIX returns the following Vendor IDs in the first packet:
- IKE Fragmentation (4048b7d56ebce88525e7de7f00d6c2d3c0000000) - version 7.0
In Aggressive Mode, Cisco PIX returns the following Vendor IDs:
- Cisco IOS VID (data varies, see below) - up to version 6.3
- XAUTH (09002689dfd6b712) - version 6.2 and above
- Cisco Unity VID (12f5f28c457168a9702d9fe274cc0100) - version 6.0 and above
- Dead Peer Detection (afcad71368a1f1c96b8696fc77570100) - version 6.0 to 7.0
- IKE Fragmentation (4048b7d56ebce88525e7de7f00d6c2d3c0000000) - version 7.0 and above
- Cisco VPN Concentrator (1f07f70eaa6514d3b0fa96542a500100) - version 7.0 and above
The Cisco IOS VID is a complex VID that is not fully understood. It appears to consist of two parts: the first 8 hex characters (4 bytes) always appear to be the same for a given PIX when testing from the same source IP to the same PIX destination IP, and are independent of PIX OS version; the remaining 24 hex characters (12 bytes) appear to be random. Below is a sample of ten such Vendor IDs from a PIX 520 running 6.2(4) at 192.168.124.154 testing from 192.168.124.7:
d4715e7ebc4a5b8c622b7e1869fae71e d4715e7edd506da39524ccee7ab81fbf d4715e7eb2aa27d33322bac737f4ef9e d4715e7e00449d77ee6b672a5e9238cd d4715e7e0e969aab40946d67bd03414e d4715e7ea64b8b8c613a308c52295c2a d4715e7e89a46ea8e126c2e242301f26 d4715e7e5ec21481d75a593bc126c33a d4715e7e6b83330ee4c6df84d03aa0ee d4715e7e988624af23c53725d09c90a8
And here are ten Vendor IDs from the same PIX running the same version testing from 192.168.124.3:
7a7a166eadfed609d2481872507b8cb5 7a7a166ea8f47a9a45f7bb6aa20708a8 7a7a166ecd1eedcc606755b81a0dff41 7a7a166e6a2cb1a255c3a382102ddded 7a7a166e2b52a4053646a22b04d33dba 7a7a166e90573ac10272953080be666f 7a7a166ec74bcd61bbef041cdbd79426 7a7a166e14fe955cf0553f67d439a8c1 7a7a166e19f5959470922c8a021fc044 7a7a166ebabe9a740fa0a9d105943f2e
This IOS Vendor ID is also returned by Cisco IOS.
The examples below show the Aggressive Mode responses from a Cisco PIX 520 running PIX OS versions from 5.1 to 6.3 inclusive. The Cisco IOS VID (starting with d4715e7e) is always present; the Cisco Unity and Dead Peer Detection VIDs appear at version 6.0, and swap places in version 6.3; XAUTH appears at version 6.2.
In the examples below, the IPsec-related configuration file entries are:
hostname pixfirewall isakmp enable inside isakmp key abc123 address 0.0.0.0 netmask 0.0.0.0 isakmp policy 20 authentication pre-share isakmp policy 20 encryption des isakmp policy 20 hash md5 isakmp policy 20 group 2 isakmp policy 20 lifetime 5000
PIX OS 5.1(2)
192.168.124.154 Aggressive Mode Handshake returned HDR=(CKY-R=21b6f963715e22f7) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=5000) VID=d4715e7e715f22f778982f93a1845b5f KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pixfirewall.) Nonce(20 bytes) Hash(16 bytes)
PIX OS 5.2(9)
192.168.124.154 Aggressive Mode Handshake returned HDR=(CKY-R=21b6f9636509dba6) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=5000) VID=d4715e7e6508dba6f0f69c3e82b6d7cf KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pixfirewall.) Nonce(20 bytes) Hash(16 bytes)
PIX OS 5.3(4)
192.168.124.154 Aggressive Mode Handshake returned HDR=(CKY-R=21b6f963a9b1d9e3) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=5000) VID=d4715e7ea9b0d9e3ab32d1e5a2207f44 KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pixfirewall.) Nonce(20 bytes) Hash(16 bytes)
PIX OS 6.0(4)
192.168.124.154 Aggressive Mode Handshake returned HDR=(CKY-R=21b6f9636fa22e17) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection) VID=d4715e7e6fa32e17b0922379f9da6ea2 KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pixfirewall.) Nonce(20 bytes) Hash(16 bytes)
PIX OS 6.1(5)
192.168.124.154 Aggressive Mode Handshake returned HDR=(CKY-R=21b6f963392d5339) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection) VID=d4715e7e392c5339d667caac4e5065cb KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pixfirewall) Nonce(20 bytes) Hash(16 bytes)
PIX OS 6.2(4)
192.168.124.154 Aggressive Mode Handshake returned HDR=(CKY-R=21b6f963dcb1205e) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) VID=09002689dfd6b712 (XAUTH) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection) VID=d4715e7edcb0205ec2b0061092730d9e KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pixfirewall) Nonce(20 bytes) Hash(16 bytes)
PIX OS 6.3(5)
192.168.124.154 Aggressive Mode Handshake returned HDR=(CKY-R=21b6f963ae748b41) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) VID=09002689dfd6b712 (XAUTH) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=d4715e7eae758b4163d38f5a9f0fe678 KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pixfirewall) Nonce(20 bytes) Hash(16 bytes)
PIX OS 7.0(1)
192.168.124.150 Aggressive Mode Handshake returned HDR=(CKY-R=680479dbf3c6342e) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) KeyExchange(128 bytes) Nonce(20 bytes) ID(Type=ID_FQDN, Value=pixfirewall.nta-monitor.com) Hash(16 bytes) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=09002689dfd6b712 (XAUTH) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0) VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) VID=1f07f70eaa6514d3b0fa96542a500100 (Cisco VPN Concentrator)
PIX OS 7.1(2)
10.0.0.2 Aggressive Mode Handshake returned HDR=(CKY-R=5aac800a4ca24461) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) KeyExchange(128 bytes) Nonce(20 bytes) ID(Type=ID_FQDN, Value=pixfirewall.nta-monitor.com) Hash(16 bytes) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=09002689dfd6b712 (XAUTH) VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) VID=1f07f70eaa6514d3b0fa96542a500100 (Cisco VPN Concentrator)
In the examples below, the IPsec-related configuration file entries are:
ip local pool testpool 192.168.0.10-192.168.0.15 crypto ipsec transform-set FirstSet esp-3des esp-sha-hmac crypto dynamic-map dyn1 10 set transform-set FirstSet crypto map mymap 200 ipsec-isakmp dynamic dyn1 crypto map mymap interface outside crypto isakmp identity hostname hostname pixfirewall isakmp enable outside crypto isakmp policy 10 authentication pre-share encryption des hash md5 group 2 lifetime 86400 username testuser password hmQhTUMT1T5Z4KHC encrypted tunnel-group testgroup type ipsec-ra tunnel-group testgroup general-attributes address-pool testpool tunnel-group testgroup ipsec-attributes pre-shared-key *
PIX OS 7.2(4)
10.0.0.2 Aggressive Mode Handshake returned HDR=(CKY-R=7112ed4b5f892837) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=XAUTH LifeType=Seconds LifeDuration=28800) KeyExchange(128 bytes) Nonce(20 bytes) ID(Type=ID_FQDN, Value=pixfirewall.nta-monitor.com) Hash(16 bytes) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=09002689dfd6b712 (XAUTH) VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) VID=1f07f70eaa6514d3b0fa96542a500100 (Cisco VPN Concentrator)
Note: PIX OS 7.2(4) only supports XAUTH (65001) authentication, whereas most other versions support both PSK and XAUTH.
PIX 8.0(4)
10.0.0.2 Aggressive Mode Handshake returned HDR=(CKY-R=a98571bdaa0c046a) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) KeyExchange(128 bytes) Nonce(20 bytes) ID(Type=ID_FQDN, Value=pixfirewall.nta-monitor.com) Hash(16 bytes) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=09002689dfd6b712 (XAUTH) VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) VID=1f07f70eaa6514d3b0fa96542a500100 (Cisco VPN Concentrator)
Authentication Methods
Cisco PIX supports Pre-Shared Key (PSK) and RSA Signature authentication for IKE Phase-1. The configuration command usage for PIX OS 6.3 is:
isakmp policy <priority> authen <pre-share|rsa-sig>
Version 7.0 adds support for DSA signature authentication.
It can also support XAUTH, which provides a second level of authentication after Phase-1 has completed. XAUTH can be used together with either PSK or RSA Phase-1 authentication. XAUTH uses the authentication method number 65001.
Below are two examples showing XAUTH authentication against a PIX 520 running PIXOS 6.3(5). The first example shows main mode, and the second aggressive mode.
$ ike-scan --trans=1,1,65001,2 -M 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f9632fdad9f1) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=XAUTH LifeType=Seconds LifeDuration=28800)
$ ike-scan -A --id=vpntest --trans=1,1,65001,2 -M 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Aggressive Mode Handshake returned HDR=(CKY-R=21b6f963564f45dd) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=XAUTH LifeType=Seconds LifeDuration=28800) VID=09002689dfd6b712 (XAUTH) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=d4715e7e564e45ddc89ef51ab1cebd59 KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pixfirewall.nta-monitor.com) Nonce(20 bytes) Hash(16 bytes)
ISAKMP SA Lifetime
PIX OS 6.3(5) supports SA lifetimes in seconds, kilobytes, or both for IKE Phase-1. For both life types (seconds and kilobytes), it supports values from 1 to 0xffffffff. It ignores the value zero, and also any value that is represented in more that four bytes (even if the actual value so represented is smaller than 0xffffffff). It also accepts no SA lifetime values at all.
Here we specify no lifetime attributes, and the PIX responds without any lifetime attributes in its response.
$ ike-scan -M --lifetime=none 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f96333512b9a) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK)
Here we specify the value 1 for both seconds and kilobytes, and observe both returned.
$ ike-scan -M --lifetime=1 --lifesize=1 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f9630035bbc2) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=1 LifeType=Kilobytes LifeDuration=1)
Here is the same thing with the value 0xffffffff. In this case, the PIX returns the attributes as variable length.
$ ike-scan -M --lifetime=0xffffffff --lifesize=0xffffffff 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f96338fff894) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration(4)=0xffffffff LifeType=Kilobytes LifeDuration(4)=0xffffffff)
If we specify values that use more than four bytes, they are ignored.
$ ike-scan -M --lifetime=0xffffffffffffffff --lifesize=0xffffffffffffffff 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f9630d0092c5) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK)
Transform ordering and rewriting
PIX OS 6.3(5) always returns transform attributes in the order: Enc [,KeyLength], Hash, Group, Auth [,LifeType=Seconds] [,LifeType=Kilobytes]
$ ike-scan -M --trans="(1=1,2=1,3=1,4=2)" 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f9633d4a4872) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK)
$ ike-scan -M --trans="(4=2,3=1,2=1,1=1)" 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f9637b1e919b) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK)
$ ike-scan -M --trans="(14=128,4=2,3=1,2=1,1=7)" 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f963ba7e8452) SA=(Enc=AES KeyLength=128 Hash=MD5 Group=2:modp1024 Auth=PSK)
$ ike-scan -M --trans="(14=128,11=1,12=5678,11=2,12=1234,4=2,3=1,2=1,1=7)" 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f963be74aaa7) SA=(Enc=AES KeyLength=128 Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=5678 LifeType=Kilobytes LifeDuration=1234)
Aggressive Mode
Cisco PIX supports both Main Mode and Aggressive Mode. It does not seem to require a valid userid in order to respond, at least with version 6.3 using the simple configuration shown above.
Here is an example of an aggressive mode response from a PIX 520 running PIX OS 6.3(5).
$ ike-scan -M -A --id=whocares 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Aggressive Mode Handshake returned HDR=(CKY-R=21b6f963a74f0633) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) VID=09002689dfd6b712 (XAUTH) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=d4715e7ea74e0633bc1483f4e8c3a1ea KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pixfirewall) Nonce(20 bytes) Hash(16 bytes)
There are additional examples of aggressive mode responses in the Vendor ID section above.
It is possible to disable aggressive mode with the comfiguration command:
isakmp am-disable
It is beleived that this is only possible on PIXOS 7.0 and above - certainly my PIX 520 running 6.3(5) does not understand this command. For PIXOS versions that do not support this command, there appears to be no way to disable aggressive mode.
Response to Noncompliant and Malformed Packets
The examples below come from PIXOS 6.3(5) running on a PIX 520.
No Acceptable Transforms
$ ike-scan -M --trans=1,1,1,1 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=21b6f96360d6af21)
Bad IKE version
PIXOS 6.3(5) does not appear to check the IKE version.
$ ike-scan -M --headerver=0x30 --trans=1,1,1,2 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f96341c64339) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
$ ike-scan -M --headerver=0x11 --trans=1,1,1,2 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f963d07d62a5) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
Invalid DOI
No response from PIXOS 6.3(5).
$ ike-scan -M --doi=2 --trans=1,1,1,2 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) Ending ike-scan 1.9: 1 hosts scanned in 2.437 seconds (0.41 hosts/sec). 0 returned handshake; 0 returned notify
Invalid Situation
PIXOS 6.3(5) does not appear to check this.
$ ike-scan -M --situation=2 --trans=1,1,1,2 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f9634d309764) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
Invalid Initiator Cookie
PIXOS 6.3(5) does not appear to check this, or perhaps it considers a zero initiator cookie to be valid.
$ ike-scan -M --cookie=0000000000000000 --trans=1,1,1,2 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f9636c76fba1) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
Invalid Flags
No response from PIXOS 6.3(5).
$ ike-scan -M --hdrflags=255 --trans=1,1,1,2 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) Ending ike-scan 1.9: 1 hosts scanned in 2.438 seconds (0.41 hosts/sec). 0 returned handshake; 0 returned notify
Invalid Protocol
No response from PIXOS 6.3(5).
$ ike-scan -M --protocol=2 --trans=1,1,1,2 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) Ending ike-scan 1.9: 1 hosts scanned in 2.436 seconds (0.41 hosts/sec). 0 returned handshake; 0 returned notify
Invalid SPI
PIXOS 6.3(5) does not appear to check this.
$ ike-scan -M --spisize=32 --trans=1,1,1,2 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f963c7a9454b) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
Non-Zero Reserved Fields
No response from PIXOS 6.3(5).
$ ike-scan -M --mbz=255 --trans=1,1,1,2 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) Ending ike-scan 1.9: 1 hosts scanned in 2.437 seconds (0.41 hosts/sec). 0 returned handshake; 0 returned notify
NAT Traversal
Cisco PIX versions 6.3 and later support NAT Traversal. Although there is a command-line option to enable it, the PIX always responds to NAT Traversal regardless of this setting. I suspect that this setting only controls whether the PIX will attempt to use NAT Traversal as an initiator.
Below is an example of a PIX 520 running PIX OS 6.3(5) responding to a Main Mode IKE request with NAT Traversal encapsulation.
$ ike-scan --nat-t -M 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f96394565f37) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
IKEv2
PIX OS does not support IKEv2 as of version 6.3(5).
Remote Access VPN Client
Cisco PIX uses the Cisco VPN client for remote access connections. This client is also used for VPN connections to other Cisco VPN products including IOS (used on Cisco routers) and Cisco VPN Concentrator 3000 series. This VPN client is sometimes known as the Cisco Unity Client.
The Cisco VPN client supports Windows, MacOS, Linux and Solaris. The screenshot on the right shows version 4.8.01 of the Windows client running on Windows XP.
The VPN client can be configured for either Group authentication, which is a username/password authentication scheme using IKE Pre-Shared Key authentication (possibly with a later XAUTH authentication step to provide secondary user-level authentication), or Certificate Authentication.
Cisco VPN Client version 4.8.01 offers the following fourteen transforms in order using group authentication:
No. | Encryption | Hash | Authentication | DH Group | Lifetime (Seconds) |
---|---|---|---|---|---|
1 | AES/256 | SHA1 | XAUTH | 2 (MODP 1024) | 2,147,483 |
2 | AES/256 | MD5 | XAUTH | 2 (MODP 1024) | 2,147,483 |
3 | AES/256 | SHA1 | PSK | 2 (MODP 1024) | 2,147,483 |
4 | AES/256 | MD5 | PSK | 2 (MODP 1024) | 2,147,483 |
5 | AES/128 | SHA1 | XAUTH | 2 (MODP 1024) | 2,147,483 |
6 | AES/128 | MD5 | XAUTH | 2 (MODP 1024) | 2,147,483 |
7 | AES/128 | SHA1 | PSK | 2 (MODP 1024) | 2,147,483 |
8 | AES/128 | MD5 | PSK | 2 (MODP 1024) | 2,147,483 |
9 | 3DES | SHA1 | XAUTH | 2 (MODP 1024) | 2,147,483 |
10 | 3DES | MD5 | XAUTH | 2 (MODP 1024) | 2,147,483 |
11 | 3DES | SHA1 | PSK | 2 (MODP 1024) | 2,147,483 |
12 | 3DES | MD5 | PSK | 2 (MODP 1024) | 2,147,483 |
13 | DES | MD5 | XAUTH | 2 (MODP 1024) | 2,147,483 |
14 | DES | MD5 | PSK | 2 (MODP 1024) | 2,147,483 |
For the authentication methods, PSK is Pre-Shared Key (value 1), and XAUTH is XAUTH Init PreShared (value 65001).
This corresponds to the following proposal: ((AES/256 or AES/128 or 3DES) and (SHA1 or MD5) and (XAUTH or PSK) and Group2) or (DES and MD5 and (XAUTH or PSK) and Group2).
The lifetime of 2,147,483 seconds is a mystery. This corresponds to a SA lifetime of about 24 days, which is an absurdly large value.
It also sends five Vendor ID payloads:
- XAUTH (09002689dfd6b712)
- Dead Peer Detection v1.0 (afcad71368a1f1c96b8696fc77570100)
- IKE Fragmentation (4048b7d56ebce88525e7de7f00d6c2d380000000)
- draft-ietf-ipsec-nat-t-ike-02\n (90cb80913ebb696e086381b5ec427b1f)
- Cisco Unity (12f5f28c457168a9702d9fe274cc0100)
Other Interesting Behaviour
Responder Cookie
The first four bytes (eight hex digits) of PIX responder cookie are fixed for a given system, and only the last four bytes vary between requests. This is a good way to fingerprint a PIX, because it's the only system that behaves in this way.
Below is an example from a PIX 520 running PIX OS 6.2(4) where the first four bytes of the responder cookie are 21b6f963:
$ ike-scan -M 192.168.124.154 192.168.124.154 192.168.124.154 192.168.124.154 Starting ike-scan 1.9 with 4 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f963dca2c372) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f963b56c3b7e) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f96367406b60) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f963ca5e6ed1) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
The first part of the cookie does not change with software version (at least between 6.0, 6.1, 6.2 and 6.3), device reboot, configuration change or time (at least not in six months). It is suspected that it is a unique value that is based on the system itself.
Lifetime attribute ordering
If both lifetime in seconds and lifetime in kilobytes are specified, then the PIX will only respond if the lifetime in seconds is first. If the lifetime in kilobytes is first, then it will respond with the notify message NO-PROPOSAL-CHOSEN.
The examples below demonstrate this behaviour. First, we specify Enc=DES, Hash=MD5, Auth=PSK, Group=2, LifeType=Seconds, LifeTime=123, LifeType=KiloBytes, LifeTime=456, which works. Then we specify Enc=DES, Hash=MD5, Auth=PSK, Group=2, LifeType=KiloBytes, LifeTime=123, LifeType=Seconds, LifeTime=456, which fails.
$ ike-scan -M --trans="(1=1,2=1,3=1,4=2,11=1,12=123,11=2,12=456)" 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Main Mode Handshake returned HDR=(CKY-R=21b6f9634e717f32) SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=123 LifeType=Kilobytes LifeDuration=456)
$ ike-scan -M --trans="(1=1,2=1,3=1,4=2,11=2,12=123,11=1,12=456)" 192.168.124.154 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.124.154 Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=21b6f9636c71fceb)
Default Configuration
The Cisco PIX does not have a default configuration as such, as IPsec has to be manually configured.
It can be configured either via the command line, or via a GUI (PDM for PIXOS 6.x, or ASDM for 7.x).
PIX OS 6.x
The screenshot on the right shows an example IKE Phase-1 configuration on PIXOS 6.3(5) using PDM. The equivalent command-line settings are:
isakmp policy 20 authentication pre-share isakmp policy 20 encryption des isakmp policy 20 hash md5 isakmp policy 20 group 2 isakmp policy 20 lifetime 5000
PIX OS 7.x
PIX OS 7.x requires more configuration settings before it will respond to IKE requests. The following command-line settings are the minimum needed:
* Enable ISAKMP for the appropriate interface * Define an ISAKMP policy * Define a crypto map * Assign the crypto map to the appropriate interface
For example, on PIX OS 7.2:
access-list 101 extended permit ip host 10.1.2.3 host 10.1.2.3 crypto isakmp enable outside crypto isakmp policy 10 authentication pre-share encryption des hash md5 group 2 lifetime 5000 crypto dynamic-map dyn1 10 match address 101 crypto map mymap 200 ipsec-isakmp dynamic dyn1 crypto map mymap interface outside