Dynamic ARP Inspection with NON-DHCP hosts

The Dynamic ARP Inspection concept is well understood, but sometimes the commands and requirements can be hard to remember. This scenario shows how DAI works with DHCP snooping to block ARP requests from untrusted ports and how NON-DHCP clients can still be apart of the network.

R1,R3 and R5 are all on VLAN100, connected to switch SW1:

R1 = Static host
R3 = DHCP Server
R5 = DHCP client

SW1 has ARP Inspection and DHCP snooping enabled already, with trust enabled on the port connected to R3.

SW1#sho run | inc snoop|arp
ip dhcp snooping vlan 100
ip dhcp snooping
ip arp inspection vlan 100
 ip dhcp snooping trust

R5 gets an IP address from R3 and now we have the following entry on SW1:

SW1#sho ip dhcp snooping binding 
MacAddress         IpAddress   Lease(sec) Type           VLAN  Interface
------------------ ----------- ---------- -------------  ----  ---------------
00:00:00:00:00:05  192.168.0.5 86381      dhcp-snooping  100   FastEthernet0/5
Total number of bindings: 1

R5 tries to ping R1 but can't:

R5#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:

*Jan  7 09:36:20.361: IP: tableid=0, s=192.168.0.5 (local), d=192.168.0.1
            (Ethernet0/0), routed via RIB
*Jan  7 09:36:20.361: IP: s=192.168.0.5 (local), d=192.168.0.1 (Ethernet0/0),
             len 100, sending
*Jan  7 09:36:20.361:     ICMP type=8, code=0
*Jan  7 09:36:20.361: IP ARP: creating incomplete entry for IP address:
             192.168.0.1 interface Ethernet0/0
*Jan  7 09:36:20.361: IP ARP: sent req src 192.168.0.5 0000.0000.0005,
                 dst 192.168.0.1 0000.0000.0000 Ethernet0/0

On SW1 we see this:

SW1#debug arp 
07:43:49: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/1, vlan 100.
([0000.0000.0001/192.168.0.1/0000.0000.0005/192.168.0.5/07:43:49 UTC Mon Mar 1 1993])

SW1 is not allowing the ARP reply from R1 because the port is untrusted in the arp inspection configuration and R1's address is not in the DHCP snooping database. We can see the request make it on R1:

R1#
*Mar  2 00:31:09.685: IP ARP: rcvd req src 192.168.0.5 0000.0000.0005,
             dst 192.168.0.1 Ethernet0/0
*Mar  2 00:31:09.685: IP ARP: sent rep src 192.168.0.1 0000.0000.0001,
                 dst 192.168.0.5 0000.0000.0005 Ethernet0/0

But R5 never gets the reply. For NON-DHCP hosts we can create an ARP ACL and apply it to the DAI configuration:

SW1(config)#arp access-list ARP-TEST  
SW1(config-arp-nacl)#permit ip host 192.168.0.1 ?
  mac  Sender MAC address
SW1(config-arp-nacl)#permit ip host 192.168.0.1 mac ?
  H.H.H  Sender MAC address
  any    Any MAC address
  host   Single Sender host
SW1(config-arp-nacl)#permit ip host 192.168.0.1 mac host 0000.0000.0001
SW1(config-arp-nacl)#exit
SW1(config)#ip arp inspection filter ARP-TEST vlan 100 

Now let's ping:

R5#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 8/9/12 ms
R5#

There is another option for the DAI filter and that is "static".

SW1(config)#ip arp inspection filter ARP-TEST vlan 100  ?
  static  Apply the ACL statically
  

If we applied this argument to the command, DAI would only check the ARP ACL and not fallback to the DHCP snooping database. That would prevent R5 ARPs from being allowed:

SW1(config)#ip arp inspection filter ARP-TEST vlan 100  static 

R5#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5#

Check debugs on SW1:

SW1#
07:52:53: %SW_DAI-4-ACL_DENY: 1 Invalid ARPs (Req) on Fa0/5, vlan 100.
([0000.0000.0005/192.168.0.5/0000.0000.0000/192.168.0.1/07:52:53 UTC Mon Mar 1 1993])

Requests are being denied inbound on f0/5 now.

CBAC with APPFW

I have begun my goal of reading the entire 12.4 Security Configuration Guide. I likely won't read it all because many things are probably unrelated to CCIE R&S, but you never really can tell. Especially since the blueprint has "Other Security Features" on it. This configuration is part of CBAC and so I thought I would test a small scenario.

R4----s1/0 R5----R6

R4 is the http server and R6 is the client. Here is how I set them up to verify it's working:

R4#copy run test.html
Destination filename [test.html]?
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of flash: complete
Verifying checksum... OK (0x7071)
1942 bytes copied in 4.628 secs (420 bytes/sec)
R4#
R4#dir
Directory of flash:/

1 -rw- 1942 test.html

7864316 bytes total (7862308 bytes free)
R4#conf t
R4(config)#ip http path flash:

R4 is setup, let's test R6 the client:

R6#copy http://192.168.45.4/test.html flash:
Destination filename [test.html]?
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of flash: complete
Loading http://192.168.45.4/test.html !
Verifying checksum... OK (0x7071)
1942 bytes copied in 0.688 secs (2823 bytes/sec)
R6#

Good, so we know that works. Now we can configure R5 as the HTTP Application FW. This does require CBAC as well as some new appfw commands which I have never used. There are MANY more options besides this, so I suggest you read the DocCD for a more in depth explanation. I just wanted to get the gist of it here:

ip inspect name APPFW appfw HTTPFW
ip inspect name APPFW http
!
appfw policy-name HTTPFW
application http
strict-http action allow alarm
content-length minimum 1945 action reset alarm
port-misuse tunneling action reset

interface Serial1/0
description TO R4
ip inspect APPFW out

Notice the minimum content length is 1945 byes. This will prevent R6 from copying the file via HTTP (test.html is 1942 bytes as we can see above):

6#copy http://192.168.45.4/test.html flash:
Destination filename [test.html]?
Erase flash: before copying? [confirm]n
%Error opening http://192.168.45.4/test.html (I/O error)
R6#

Jump to R5 and see the message:

R5#
*Mar 2 05:34:02.708: %APPFW-4-HTTP_CONT_TYPE_SIZE: Sig:11 Content size 1942 out of range - Reset - Content size out-of-bounds from 192.168.56.6:25101 to 192.168.45.4:80

If we change the minimum content legth to 1942, everything works as expected:

R5(config)#appfw policy-name HTTPFW
R5(cfg-appfw-policy)#application http
R5(cfg-appfw-policy-http)#content-length minimum 1942 action reset alarm

R6#copy http://192.168.45.4/test.html flash:
Destination filename [test.html]?
%Warning:There is a file already existing with this name
Do you want to over write? [confirm]y
Erase flash: before copying? [confirm]n
Loading http://192.168.45.4/test.html !
Verifying checksum... OK (0x7071)
1942 bytes copied in 0.396 secs (4904 bytes/sec)
R6#

Finding out port numbers with NBAR show commands

I had a filtering task that said to allow H323 Traffic to a specific vlan. Well...what ports does H323 use? I could not find it on the DocCD but I remembered a show command that will let us know:

R1#sho ip nbar port-map h323 
port-map h323       udp 1300 1718 1719 1720 11720 
port-map h323       tcp 1300 1718 1719 1720 11000 - 11999 

Sweet!

Blocking traffic to random unicast MAC addresses

Ran into this command today. Never even knew about it:

Rack1SW1(config)#int f0/22
Rack1SW1(config-if)#switchport ?
access Set access mode characteristics of the interface
backup Set backup for the interface
block Disable forwarding of unknown uni/multi cast addresses
host Set port host
mode Set trunking mode of the interface
nonegotiate Device will not engage in negotiation protocol on this
interface
port-security Security related command
priority Set appliance 802.1p priority
private-vlan Set the private VLAN configuration
protected Configure an interface to be a protected port
trunk Set trunking characteristics of the interface
voice Voice appliance attributes


Rack1SW1(config-if)#switchport block unicast
Rack1SW1(config-if)#switchport block multicast

From the DocCD:

"By default, the switch floods packets with unknown destination MAC addresses out of all ports. If unknown unicast and multicast traffic is forwarded to a protected port, there could be security issues. To prevent unknown unicast or multicast traffic from being forwarded from one port to another, you can block a port (protected or nonprotected) from flooding unknown unicast or multicast packets to other ports."

Configuring Port Blocking

IP Source Guard

I was reading through the 3560 Configuration guide looking for things to lab and I came up with this. I already had DHCP snooping configured from my last lab so it was real easy.

Topology:

R1---SW1---R3

R1 has an address via DHCP:

R1#show ip int brief | ex unas
Ethernet0/0 192.168.12.1 YES DHCP up up

R1 can ping R3 on it's subnet:

R1#ping 192.168.12.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms

Sw1 has dhcp snooping already enabled. Here we configure IP source guard:

SW1(config)#int f0/1
SW1(config-if)#ip verify source

Now on R1 if we change the IP address, we cannot ping anymore:

R1(config)#int e0/0
R1(config-if)#ip address 192.168.12.100 255.255.255.0
R1(config-if)#^Z

R1#ping 192.168.12.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Verify IP source guard is in effect on SW1:

SW1#show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan
--------- ----------- ----------- --------------- -----------------
Fa0/1 ip active deny-all 12

Set R1 to get address via DHCP:

R1(config)#int e0/0
R1(config-if)#ip address dhcp
*Mar 1 02:53:06.259: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 assigned DHCP address 192.168.12.4, mask 255.255.255.0, hostname R1

Now R1 can ping again:

R1#ping 192.168.12.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms

Verify on SW1:

SW1#show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan
--------- ----------- ----------- --------------- -----------------
Fa0/1 ip active 192.168.12.4 12

You can also configure static bindings, but I will probably do that in another blog :)

Parser View

I was reading this pdf called "1001 things to do with a Cisco Router" and I came across this topic. I have done it before while doing the ISCW but here it is again.

FIRST, ENABLE AAA:

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#aaa new-model

SET ENABLE PASSWORD:

R4(config)#enable secret cisco
R4(config)#^Z

SWITCH TO VIEW MODE:

R4#en view
Password:
R4#
*Mar 2 23:03:20.352: %PARSER-6-VIEW_SWITCH: successfully set to view 'root'.
R4#

NOW WE CAN CREATE THE VIEW:

R4(config)#parser view operator
R4(config-view)#?
View commands:
commands Configure commands for a view
default Set a command to its defaults
exit Exit from view configuration mode
no Negate a command or set its defaults
secret Set a secret for the current view
R4(config-view)#commands exec include ping
% Password not set for the view operator
R4(config-view)#secret operator
R4(config-view)#commands exec include ping
R4(config-view)#commands exec include show hardware
R4(config-view)#commands exec include show interface
R4(config-view)#commands exec include show ver
R4(config-view)#exit

LOG IN TO THE VIEW:

R4#en view operator
Password:

*Mar 2 23:05:41.212: %PARSER-6-VIEW_SWITCH: successfully set to view 'operator'.

R4#show ?
flash: display information about flash: file system
hardware Hardware specific information
interfaces Interface status and configuration
parser Display parser information
slot0: display information about slot0: file system
slot1: display information about slot1: file system
version System hardware and software status

ALSO, YOU CAN ADD THE VIEW TO THE USER:

R4(config)#username operator view operator password operator

Extended ping with TOS byte

Here is the scenario:

R2---R6---R7

R6 is only supposed to allow traffic with an IP precedence level of critical to R7. Easy right? Well with extended ping you can verify that it is working.

On R6 we the following ACL applied to the interface towards R7:

access-list 101 permit ospf any any
access-list 101 permit ip any any precedence critical log
access-list 101 deny ip any any log

The only traffic being allowed is ospf to maintain the adjacency with R7 and "critical" IP traffic.

For our extended ping we need to find the hex value of the critical precedence. Critical is precedence 5 which in the ToS byte would break out to 101 000 00. We can align it like this:

1010 0000

This is equal to hex value 0xA0 (the first four bits are 10 which is A, the last 4 are 0). So here is our first ping which fails:

R2#ping 150.100.220.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.220.7, timeout is 2 seconds:
U.U.
Success rate is 0 percent (0/4)

Now we send the extended ping with ToS value 0xA0

R2#ping
Protocol [ip]:
Target IP address: 150.100.220.7
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 0xA0
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.220.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms
R2#

On R6 we can verify the matches:

R6#show access-lists 101
Extended IP access list 101
10 permit ospf any any (1 match)
20 permit ip any any precedence critical log (5 matches)
30 deny ip any any log (44 matches)

Lock and Key

Here is the example I am following, pretty much to a T, except I am doing BGP for routing protocol and the topology is different.

Lock-and-Key: Dynamic Access Lists

Here is my topology:

[R1]----[R2]----[R3]

The goal is to prevent R1 from telnetting to R3 (172.12.23.3) unless it has authenticated to R2 first, via telnet. All configuration is on R2, but remember to configure your vty on R3.

First create a username and password on R2

R2(config)#username test password test

Next setup the router to allow access once telnet session is established:

R2(config)#line vty 0 4
R2(config-line)#autocommand access-enable
R2(config-line)#login local

Next create and apply the the ACL. Note that I am using BGP for a routing protocol and I need to allow that before anything else is configured.

R2(config)#access-list 120 permit tcp any any eq bgp
R2(config)#access-list 120 permit tcp any eq bgp any eq bgp
R2(config)#access-list 120 dynamic testlist timeout 15 permit ip any any
R2(config)#access-list 120 permit tcp any host 172.12.12.2 eq telnet
R2(config)#int s1/0
R2(config-if)#ip access-group 120 in

Let's try to telnet to R1 from R3:

R1#telnet 172.12.23.3
Trying 172.12.23.3 ...
% Destination unreachable; gateway or host down

R1#

Now let's telnet to R2 first, notice that our session gets dropped immediately:

R1#telnet 172.12.12.2
Trying 172.12.12.2 ... Open


User Access Verification

Username: test
Password:
[Connection to 172.12.12.2 closed by foreign host]
R1#

Now let's try and telnet to R3:

R1#telnet 172.12.23.3
Trying 172.12.23.3 ... Open


User Access Verification

Password:
R3>

Perfect! Some things to remember about lock and key are:

1) always allow your routing protocol at the top (lines 1 and 2 of the ACL)
2) allow telnet to the local router interface (line 4 of the above ACL)

BGP - TTL security

Suppose R5 and R6 are EBGP peers. Each send BGP packets with TTL of 1 to each other. They process any BGP packet with a TTL value of 1 or higher. So if an attacker wants to cause mayhem he can send tons of BGP packets to an edge router in a type of DoS attack and these packets will be processed no matter how far away the attacker is. With BGP TTL Security we can configure the router to expect to receive packets with higher TTL values. That way, an attacker more than the configured number of hops away, will never be able to DoS the router.

Example:

On R6 we configure:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 ttl-security hops 5

After 3 minutes (BGP default time) without a keepalive, R6 drops the neighbor:

Mar 1 03:16:55.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.5 Down BGP Notification sent
Mar 1 03:16:55.467: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.5 4/0 (hold time expired) 0 bytes

The reason this happens is because after the TTL security command is configured, R6 will silently drop any packet with a TTL lower of 250 or lower. If it receives a packet with TTL 250, I think it will drop it according to my testing. How can we make R5 send packets with a TTL of 251? We can use TTL-security on that router to or use ebgp-multihop.

In this case I use ebgp-multihop:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 ebgp-multihop 251

.Jul 14 23:01:46.740: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up

In this case we use TTL security on R5:

R5(config)#router bgp 65005
R5(config-router)#no neighbor 172.14.45.6 ebgp-multihop 251
R5(config-router)#neighbor 172.14.45.6 ttl-security hops 5

After clearing the session:

.Jul 14 23:05:15.131: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up

You can verify like this:

R6#show ip bgp neighbors 172.14.45.5 | inc TTL
(output omitted)
External BGP neighbor may be up to 5 hops away.
Connection is ECN Disabled, Mininum incoming TTL 250, Outgoing TTL 255

I don't know why ebgp-multihop didn't work with 250. Perhaps the router decrements it before processing and then sees 249 as the TTL.

RPF check

RPF check is another way to prevent spoofing. If you are familiar with Multicast routing then this shouldn't be too hard to understand. Basically the router looks up the source IP address of the packet in the route-table and (depending on the configuration) can drop it if the source interface doesn't match the interface in the route table.

For example, if R4 receives a packet on serial 1/0 but the source address isn't in it's table it drops the packet. Let's try it out.

Here's our topology:

[R1]----[R4] s1/0 ----[R5]

R1-R4: 10.0.0.0/24
R4-R5: 155.1.45.0/24

OSPF area 0 is on all interfaces

R5 has 2 loopbacks:
155.1.55.55/32
155.1.155.155/32

We are not going to advertise the loopbacks into OSPF so that the RPF check will fail on R4. We are also going to use an ACL so that only one loopback is actually checked via RPF.

On R4:

R4(config)#access-list 100 permit ip 150.1.55.0 0.0.0.255 any
R4(config)#access-list 100 deny ip any any log

R4(config-if)#int s1/0
R4(config-if)#ip verify unicast reverse-path 100

That's it for the config! Let's look at R4's routing table.

R4#show ip route | begin Gateway
Gateway of last resort is not set

155.1.0.0/24 is subnetted, 3 subnets
C 155.1.0.0 is directly connected, Serial1/1
C 155.1.4.0 is directly connected, Loopback0
C 155.1.45.0 is directly connected, Serial1/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0

Notice that R4 has no route to either of R5's loopbacks, but it will only perform an RPF check on packets coming from 155.1.155.155. On R5 (both pings get no reply because R4 has no route back but only the first set get blocked by R4 as we'll see below):

R5#ping 10.0.0.1 source 155.1.155.155

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 155.1.155.155
.....
Success rate is 0 percent (0/5)
R5#ping 10.0.0.1 source 155.1.55.55

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 155.1.55.55
.....
Success rate is 0 percent (0/5)
R5#

On R4:

R4#
*Mar 1 08:21:29.285: %SEC-6-IPACCESSLOGDP: list 100 denied icmp 155.1.155.155 -> 10.0.0.1 (0/0), 1 packet
R4#

For more go here:
Configuring Unicast Reverse Path Forwarding

TCP Intercept: Watch vs Intercept

TCP Intercept is used to prevent DoS attacks where the attacker tries to use up all the TCP resources by sending SYN packets and then never replying to the SYN-ACK (the source is spoofed which is why the attacker doesn't respond). Here we configure R4 to detect this attack and prevent it by dropping these "half-open" connections. I am not sure how to spoof an address from a Cisco router, so we'll just configure TCP intercept and do some monitoring.

[R5]---[R4]---[R1]

10.0.0.0 is the LAN address range between R1 and R4. We'll create an ACL that matches telnet traffic from R5 to R1. R1 in this case is the server we want to protect from the SYN Attack.

R4(config)#access-list 100 permit tcp any 10.0.0.0 0.0.0.255 eq 23

R4(config)#ip tcp intercept ?
connection-timeout Specify timeout for connection info
drop-mode Specify incomplete connection drop mode
finrst-timeout Specify timeout for FIN/RST
list Specify access-list to use
max-incomplete Specify maximum number of incomplete connections before clamping
mode Specify intercepting mode
one-minute Specify one-minute-sample watermarks for clamping
watch-timeout Specify timeout for incomplete connections in watch mode

R4(config)#ip tcp intercept list 100
R4(config)#ip tcp intercept max-incomplete high 200
R4(config)#ip tcp intercept max-incomplete low 150
R4(config)#ip tcp intercept connection-timeout 60
R4(config)#ip tcp intercept drop-mode random

Debugging and Verification:

R4#debug ip tcp intercept
TCP intercept debugging is on

*Mar 1 06:28:33.866: INTERCEPT: new connection (155.1.45.5:31039 SYN -> 10.0.0.1:23)
*Mar 1 06:28:33.874: INTERCEPT(*): (155.1.45.5:31039 <- ACK+SYN 10.0.0.1:23)
*Mar 1 06:28:33.954: INTERCEPT: 1st half of connection is established (155.1.45.5:31039 ACK -> 10.0.0.1:23)
*Mar 1 06:28:33.958: INTERCEPT(*): (155.1.45.5:31039 SYN -> 10.0.0.1:23)
*Mar 1 06:28:34.034: INTERCEPT: 2nd half of connection established (155.1.45.5:31039 <- ACK+SYN 10.0.0.1:23)
*Mar 1 06:28:34.038: INTERCEPT(*): (155.1.45.5:31039 ACK -> 10.0.0.1:23)
*Mar 1 06:28:34.042: INTERCEPT(*): (155.1.45.5:31039 <- WINDOW 10.0.0.1:23)

I don't like the output above. I expected to see R4's address somewhere in the output since it is "intercepting" the connections. Perhaps I am misunderstanding this...both "halves" look the same to me.

Anyways, here's a show command:

R4#show tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode

Established:
Client Server State Create Timeout Mode
155.1.45.5:31039 10.0.0.1:23 ESTAB 00:00:49 00:59:14 I
R4#

Now let's see what it looks like in watch mode:

R4(config)#ip tcp intercept mode watch

R4#
*Mar 1 06:30:58.082: INTERCEPT: new connection (155.1.45.5:12568 SYN -> 10.0.0.1:23)
*Mar 1 06:30:58.182: INTERCEPT: (155.1.45.5:12568 <- ACK+SYN 10.0.0.1:23)
*Mar 1 06:30:58.310: INTERCEPT: (155.1.45.5:12568 ACK -> 10.0.0.1:23)
R4#show tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode

Established:
Client Server State Create Timeout Mode
R4#

Notice that "show tcp intercept connections" only gives output when the router is in intercept mode.

CBAC Example

Context-Based access control is another way to dynamically modify access-lists on the fly to allow return traffic. Here we configure a simple example that allows FTP traffic as well as PING from inside to outside. First let's apply an ACL inbound on R4 serial 1/0 and see what happens we ping from R1 to R5:

R1 --INSIDE--> R4 s1/0 --OUTSIDE--> R5

On R4:

ip access-list extended INBOUND
permit ospf any any
deny ip any any log
interface Serial1/0
ip access-group INBOUND in

Now from R1:

R1#ping 155.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.5.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#

Now on R4 we add the following CBAC configuration:

ip inspect name CBAC ftp
ip inspect name CBAC tcp router-traffic
ip inspect name CBAC icmp router-traffic

interface Serial1/0
ip inspect CBAC out

Now back to R1:

R1#ping 155.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/115/268 ms
R1#

Verify on R4 (Do this quick or the session will be gone)

R4#show ip inspect sessions
Established Sessions
Session 659A79DC (10.0.0.1:8)=>(155.1.5.5:0) icmp SIS_OPEN
R4#

I tried testing ftp but for some reason the "ftp-server enable" doesn't seem to exist in my IOS with is 12.4 ADVENT. Anyways, that should give you a quick idead of how CBAC is used to punch holes in ACLs for return traffic.

Also remember that we DENY traffic INBOUND on the OUTSIDE interface if we want to inspect it in the OUTBOUND direction.

R.E.F.L.E.C.T

Here's the topology:

R1 --INSIDE--> R4 --OUTSIDE--> R5

We are going to apply a reflexive ACL on R4 to permit outgoing telnet, web and ping traffic.

Let's go to R4 and create our outbound ACL with the keyword "reflect" used to create our reflexive ACL.

R4(config)#ip access-list extended OUTBOUND
R4(config-ext-nacl)#permit tcp any any eq 23 reflect ?
WORD Access-list name
R4(config-ext-nacl)#permit tcp any any eq 23 reflect MIRROR
R4(config-ext-nacl)#permit tcp any any eq 80 reflect MIRROR
R4(config-ext-nacl)#permit icmp any any echo reflect MIRROR
R4(config-ext-nacl)#exit

Next we "evaluate" the reflexive ACL on our inbound ACL (note that I am doing OSPF between R4 and R5 and I don't want the adjacency to break).

R4(config)#ip access-list extended INBOUND
R4(config-ext-nacl)#evaluate MIRROR
R4(config-ext-nacl)#permit ospf any any
R4(config-ext-nacl)#deny ip any any log
R4(config-ext-nacl)#exit
R4(config)#

Apply these ACLs inbound and outbound on your outside interface, in my case S1/0:

R4(config)#int s1/0
R4(config-if)#ip access-group INBOUND in
R4(config-if)#ip access-group OUTBOUND out

Let's do some telnetting from R1 to R5

R1#telnet 155.1.5.5
Trying 155.1.5.5 ... Open

User Access Verification

Username: cisco

Flip over to R4 for Verification:

R4#show ip access-lists MIRROR
Reflexive IP access list MIRROR
permit tcp host 155.1.5.5 eq telnet host 155.1.4.4 eq 58347 (51 matches) (time left 298)
R4#

Let's examine the ACL MIRROR, The source is our telnet destination (the device we are telnetting to). This ACL is being used inbound on our outside interface to allow return traffic. Also I should note that R4 is doing NAT, with 155.1.4.4 being the translated address of R1's actual interface address (10.0.0.1). So you can see reflexive ACL's are very neat because they automatically allow for return traffic while we filter inbound and outbound.

SSH for VTY access

This is a very simple lab for SSH access:

R1 and R2 connected to same LAN
R1 will be the client, R4 the server

Let's enable SSH on R2:

R2(config)#ip domain-name theseblues.com

R2(config)#crypto key generate rsa
The name for the keys will be: R2.theseblues.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]:
% Generating 512 bit RSA keys, keys will be non-exportable...[OK]

R2(config)#
*Mar 1 00:18:50.259: %SSH-5-ENABLED: SSH 1.99 has been enabled
R2(config)#
R2(config)#line vty 0 4
R2(config-line)#login local
R2(config-line)#transport input ssh
R2(config-line)#exit
R2(config)#username dh password blues

Let's SSH from R1:

R1#ssh ?
-c Select encryption algorithm
-l Log in using this user name
-m Select HMAC algorithm
-o Specify options
-p Connect to this port
-v Specify SSH Protocol Version
WORD IP address or hostname of a remote system

R1#ssh -l dh 192.168.0.2

Password:

R2>en
% No password set
R2>

Forgot the enable password! You know what to do...

NTP authentication

This is scenario 3 dealing with NTP and in this post I will set up NTP authentication. Remember that the purpose is for the client to authenticate the server. First will make sure NTP is synchronized on the client. Next, we will turn on authentication on the client only until the clocks become unsynchronized. Finally, we will configure the server with the appropriate key and make sure the client is synchronized again.

We use the same topology as the other NTP scenarios:
R4, R5 and R6 connected via full mesh frame-relay on subnet 172.12.45.0/24

Let's make sure R6, the master, is synchronized first:

R6#show clock
20:14:37.215 MDT Mon Jun 2 2008

R6#show ntp status | inc Clock is
Clock is synchronized, stratum 2, reference is 127.127.7.1

R4:

R4#show ntp status | in Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

and R5:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

Let's configure authentication on R4:

R4(config)#ntp authenticate
R4(config)#ntp authentication-key 1 md5 cisco
R4(config)#ntp trusted-key 1
R4(config)#ntp server 172.12.45.6 key 1

R4#debug ntp validity
NTP peer validity debugging is on
R4#debug ntp authentication
NTP authentication debugging is on

In a few moments we get these debug messages:

R4(config)#
Jun 3 03:24:49.759: NTP: packet from 172.12.45.6 failed validity tests 10
Jun 3 03:24:49.763: Authentication failed
R4(config)#

What's strange is that R4 is still synchronized with R6:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6

So I waited about 10 minutes (it seemed that long) and now R4 is unsynchronized:

R4#show ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock

Now let's configure NTP authentication on R6:

R6(config)#ntp authenticate
R6(config)#ntp authentication-key 1 md5 cisco

On R4 I will set up some debugging, a lot of the output doesn't make much sense, but here it is:

R4#debug ntp packets
NTP packets debugging is on

!! HERE R4 TRANSMITS A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.711: NTP: xmit packet to 172.12.45.6:
.Jun 3 03:36:10.715: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Jun 3 03:36:10.715: rtdel 0D4E (51.971), rtdsp 05CD (22.659), refid AC0C2D06 (172.12.45.6)
.Jun 3 03:36:10.719: ref CBEF37C1.C8A9606E (20:23:45.783 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.719: org CBEF3A6A.BF8D3204 (20:35:06.748 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: rec CBEF3A6A.C784D317 (20:35:06.779 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: xmt CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.727: Authentication key 1

!! HERE R4 RECEIVES A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.771: NTP: rcv packet from 172.12.45.6 to 172.12.34.4 on FastEthernet0/1:
.Jun 3 03:36:10.775: leap 0, mode 4, version 3, stratum 2, ppoll 64
.Jun 3 03:36:10.779: rtdel 0000 (0.000), rtdsp 0002 (0.031), refid 7F7F0701 (127.127.7.1)
.Jun 3 03:36:10.779: ref CBEF3A89.50E1C8AB (20:35:37.315 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: org CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: rec CBEF3AAA.C3941C78 (20:36:10.763 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.787: xmt CBEF3AAA.C39DD400 (20:36:10.764 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: inp CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: Authentication key 1

R4 is now synchronized:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6
nominal freq is 250.0000 Hz, actual freq is 250.0004 Hz, precision is 2**18
reference time is CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
clock offset is 22.8825 msec, root delay is 59.68 msec
root dispersion is 15897.92 msec, peer dispersion is 15875.02 msec

Let's check R5 to see if it is still synchronized:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

As you can see, R5 is still synchronized because it is not requesting authentication from R6. R4 on the other sends the request with an authentication key and requires that the time-source, R6, does so as well.

Well, this lab went okay. I have had many problems with ntp authentication before. Initially, I thought I would have problems again when R4 was not un-synchronizing with R6 when we first set up a key on R4. Well, it took a few minutes, so I guess patience is this key. You can't afford to be too patient though, you only have 8 hours on lab day :)

IP Accounting for traffic violations

R6 <---FRAME---> R5 <----ETHERNET---> R3

First step is to create the ACL that blocks traffic. Here will block traffic (and configure accounting) for packets from R6 to R3. IP address 6.6.6.10 is a loopback on R6 being advertised into OSPF to R5 and on to R3. 3.3.3.3 is the loopback on R3.

R5#show run | section access-list 101
access-list 101 deny ip host 6.6.6.10 host 3.3.3.3
access-list 101 permit ip any any

Apply the ACL to the interface where traffic is to be restricted. FastEthernet0/0 is the interface connected to R3's LAN interface. Enable accounting for access-violations on that interface with the command "ip accounting access-violations"

R5#show run int f0/0
Building configuration...

Current configuration : 153 bytes
!
interface FastEthernet0/0
ip address 172.12.34.5 255.255.255.0
ip access-group 101 out
ip accounting access-violations
speed 100
full-duplex
end

Ping from R6 to verify that traffic is blocked:

R6#ping 3.3.3.3 source 6.6.6.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.10
U.U.U
Success rate is 0 percent (0/5)

Verify accounting on R5:

R5#show ip accounting access-violations
Source Destination Packets Bytes ACL
6.6.6.10 3.3.3.3 6 600 101

Accounting data age is 4

The output of the command shows how many packets (6) and bytes (600) were blocked as well as the ACL (101) that blocked them.