Monthly Archives: March 2013

i like ike…

ike phase 1

defines the key exchange mechanism used to pass and validate ike policies between peers

ike phase 2

exchanges and matches ipsec policies for the authentication and encryption of data

enable ike

r1(config)#crypto isakmp enable

create the isakmp policy

the isakmp policy defines authentication, encryption and hash used for control traffic for the peers to establish an SA (security association). once established between the peers, ike phase 1 is complete

h a g l e

hash authentication group lifetime encryption

r1(config)#crypto isakmp policy 10
r1(config-isakmp)#?
ISAKMP commands:
authentication  Set authentication method for protection suite
default         Set a command to its defaults
encryption      Set encryption algorithm for protection suite
exit            Exit from ISAKMP protection suite configuration mode
group           Set the Diffie-Hellman group
hash            Set hash algorithm for protection suite
lifetime        Set lifetime for ISAKMP security association
no              Negate a command or set its defaults

this policy must match for the peers

r1(config-isakmp)#hash sha
r1(config-isakmp)#authenti pre-share
r1(config-isakmp)#group 5
r1(config-isakmp)#lifetime 3600
r1(config-isakmp)#encryption aes 256

r1(config-isakmp)#do sh crypto isakmp policy

Global IKE policy
Protection suite of priority 10
encryption algorithm:   AES – Advanced Encryption Standard (256 bit key.
hash algorithm:         Secure Hash Standard
authentication method:  Pre-Shared Key
Diffie-Hellman group:   #5 (1536 bit)
lifetime:               3600 seconds, no volume limit
Default protection suite
encryption algorithm:   DES – Data Encryption Standard (56 bit keys).
hash algorithm:         Secure Hash Standard
authentication method:  Rivest-Shamir-Adleman Signature
Diffie-Hellman group:   #1 (768 bit)
lifetime:               86400 seconds, no volume limit

create a pre-shared key for this example:

r1(config)#crypto isakmp key psycho add 10.2.2.1

a transform set is a crypto parameter used to negotiate the SA:

r1(config)#crypto ipsec transform-set 50 esp-aes 256 esp-sha-hmac

create an access-list to define interesting traffic:

access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

reverse this for the peer…

create a crypto map to match the access-list to the peers various ike and ipsec settings…

r1(config)#crypto map CMAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
r1(config-crypto-map)#match address 101
r1(config-crypto-map)#set peer 10.2.2.1
r1(config-crypto-map)#set pfs group5
r1(config-crypto-map)#set transform-set 50
r1(config-crypto-map)#set security-association lifetime seconds 900
r1(config-crypto-map)#

assign the maps to the interfaces and send some traffic to light em up… (until traffic has been generated there will be no SA)

r3(config)#int s0/0
r3(config-if)#crypto map CMAP
r3(config-if)#
*Mar 31 12:18:11.831: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

r3#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status

IPv6 Crypto ISAKMP SA

ping from the host makes it interesting… note the first one times out…

vpn_ping

r1#sh crypto isakmp sa
dst             src             state          conn-id slot status
10.1.1.1        10.2.2.1        QM_IDLE              1    0 ACTIVE

r1#sh crypto ipsec sa

interface: Serial0/0
Crypto map tag: CMAP, local addr 10.1.1.1

protected vrf: (none)
local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)
current_peer 10.2.2.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 7, #pkts encrypt: 7, #pkts digest: 7
#pkts decaps: 7, #pkts decrypt: 7, #pkts verify: 7
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.2.2.1
path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0
current outbound spi: 0x7805C8A3(2013644963)

inbound esp sas:
spi: 0x6BB78A0B(1807190539)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: SW:1, crypto map: CMAP
sa timing: remaining key lifetime (k/sec): (4501618/613)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x7805C8A3(2013644963)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2002, flow_id: SW:2, crypto map: CMAP
sa timing: remaining key lifetime (k/sec): (4501618/595)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

zbfw…

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00808bc994.shtml#topic1

Zone-Based Policy Firewall (also known as Zone-Policy Firewall, or ZFW) changes the firewall configuration from the older interface-based model to a more flexible, more easily understood zone-based model. Interfaces are assigned to zones, and inspection policy is applied to traffic moving between the zones. Inter-zone policies offer considerable flexibility and granularity, so different inspection policies can be applied to multiple host groups connected to the same router interface.

Zones establish the security borders of your network. A zone defines a boundary where traffic is subjected to policy restrictions as it crosses to another region of your network. ZFW’s default policy between zones is deny all. If no policy is explicitly configured, all traffic moving between zones is blocked. This is a significant departure from stateful inspection’s model where traffic was implicitly allowed until explicitly blocked with an access control list (ACL).

The second major change is the introduction of a new configuration policy language known as CPL. Users familiar with the Cisco IOS Software Modular quality-of-service (QoS) CLI (MQC) might recognize that the format is similar to QoS’s use of class maps to specify which traffic will be affected by the action applied in a policy map.

auto secure

noooooooooooooooo… auto sec will cbac the hell out of you… ie… before you get cbac’ed, understand what inspection does:

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a0080094e8b.shtml

CBAC access lists include ip inspect statements that allow the inspection of the protocol to make sure that it is not tampered with before the protocol goes to the systems behind the firewall.

no ip bootp server
no ip domain lookup
ip domain name ccie
ip inspect audit-trail
ip inspect udp idle-time 1800
ip inspect dns-timeout 7
ip inspect tcp idle-time 14400
ip inspect name autosec_inspect cuseeme timeout 3600
ip inspect name autosec_inspect ftp timeout 3600
ip inspect name autosec_inspect http timeout 3600
ip inspect name autosec_inspect rcmd timeout 3600
ip inspect name autosec_inspect realaudio timeout 3600
ip inspect name autosec_inspect smtp timeout 3600
ip inspect name autosec_inspect tftp timeout 30
ip inspect name autosec_inspect udp timeout 15
ip inspect name autosec_inspect tcp timeout 3600
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
login block-for 60 attempts 2 within 30

make it go away…

r1#sh access-list
Extended IP access list 100
10 permit udp any any eq bootpc
Extended IP access list autosec_firewall_acl
10 permit udp any any eq bootpc
20 deny ip any any (120 matches)
Extended IP access list sl_def_acl
10 deny tcp any any eq telnet log
20 deny tcp any any eq www log
30 deny tcp any any eq 22 log
40 permit ip any any log

yikes…

r1#sh ip route | b Gate
Gateway of last resort is 10.1.1.2 to network 0.0.0.0

10.0.0.0/30 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Serial0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 [1/0] via 10.1.1.2

r1(config)#ip access-list ext autosec_firewall_acl
r1(config-ext-nacl)#15 permit eigrp any any
r1(config-ext-nacl)#end
r1#sh ip route | b Gate
Gateway of last resort is 10.1.1.2 to network 0.0.0.0

10.0.0.0/30 is subnetted, 2 subnets
D       10.2.2.0 [90/2681856] via 10.1.1.2, 00:00:05, Serial0/0
C       10.1.1.0 is directly connected, Serial0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 [1/0] via 10.1.1.2

bad autosec, bad… i want to inspect your flows…

r1#sh run int s0/0
Building configuration…

Current configuration : 270 bytes
!
interface Serial0/0
ip address 10.1.1.1 255.255.255.252
ip access-group autosec_firewall_acl in
ip verify unicast source reachable-via rx allow-default 100
no ip redirects
no ip unreachables
no ip proxy-arp
ip inspect autosec_inspect out
clock rate 64000
end

 

2.3.a Implement and troubleshoot HDLC

slarp

it is worth mentioning… i once bumped into this quite by surprise and it shook me… serial line address resolution protocol… there is not a lot out there on it… it’s basically a dhcp mechanism for serial interfaces supporting a /30 network, whereby the side that is unknown get’s the other half of the /30… this guy has more on it here:

http://www.davidsudjiman.info/2007/01/07/serial-line-address-resolution-protocol-slarp/

it is a legacy from what i have gathered…

wiki discusses it here briefly:

http://en.wikipedia.org/wiki/Cisco_HDLC

if in use it will show up as the method for which it came to be in show ip interface brief…

beware the SLARP monster…

 

2.1.f Implement and troubleshoot spanning-tree

of course i got the new ccna book (the icnd2, anyway) because this is monumental… it has been quite a while since there has been a sweeping change to this series…  anyone who has slaved through ccna will want to read this, no matter your current cert level… it also comes with extra content like videos, test engine, etc…  you owe it to yourself to take a walk down memory lane…

here is a nice sample tidbit…  you know by default the priority of a switch is 32,768 without the extended system id… when using the root primary macro, the new setting will be 24,576… you also know that priority is set in 4096 increments… but that’s an 8192 difference not 4096… do the math…

For the switch intended to take over as the root if the first switch fails, use the spanning-tree
vlan vlan-id root secondary command. This command is much like the spanning-tree vlan
vlan-id root primary command, but with a priority value worse than the primary switch but
better than all the other switches. This command sets the switch’s base priority to 28,672
regardless of the current root’s current priority value.