ZBFP is a successor of CBAC and it is the most flexible firewall implementation available on IOS. The main idea is to think about zones, not physical interfaces. With CBAC you couldn’t build policy based on flow or direction. For example a policy applied on OUTSIDE interface works the same for traffic to DMZ and to LAN. ZBFP can easily separate these flows and you can have two different rules depending on out interface. Let’s test one scenario:

I’m going to add a policy for traffic from R2 to R3. Only telnet and icmp should be allowed.

First I create a class and policy map:

!
class-map type inspect match-any CM-ICMP-TCP
 match protocol icmp
 match protocol tcp
!
policy-map type inspect PM-ICMP-TCP
 class type inspect CM-ICMP-TCP
  inspect
 class class-default
!

and then zones and a service policy:

!
zone security INSIDE
zone security OUTSIDE
!
zone-pair security INS->OUT source

I would like to talk about defeating DDOS and scenarios how we can actually use it. Let’s get started ! I’m going to talk about two methods:

1) before you forward any packet, check if you know the return path. If you know, forward the packet, if you don’t – drop it. There are two ways of implementation: strict and loose. First one accepts packets only when the return path is through the interface which is the ingress one. The second one accept any packet if the router has the return path via any interface. As you can see you can’t use this solution for transit or multihomed networks. It should be rather singlehomed, stub network. During DDOS attackers spoof a source IP and the solution will work (packets will be dropped) only for those with invalid source IP addresses. If the source IP is a valid, the packet will be forwarded.

2) edge router checks if the source IP is the one, which...

Today I would like to talk about one technique that helps to mitigate DOS attack - RTBH. The technique is defined by RFC 5635 (2009) which is updated (and extension) of RFC 3882 (2004). As you see it’s quite old document and today we can find much better tools to mitigate such attacks.

It isn’t complex technique, the configuration is very simple and the result of it is to send unwanted traffic to interface Null0 (silently drop) on the edge of your network. As you know, routers can easily route packets rather than analyze them and drop based on ACL entries. When DOS attack starts you can see huge number of packets that need to be processed by your router. Route all of them to the Null0 interface, requires less router resources when you compare with filtering based on access list.

The main problem is that the technique is not much granular. You can choose source or destination IP, what...

With many VPN tunnels in your production environment you may be asked to modify some policies. What kind of tasks you can do without impact on the business traffic and what can be performed only during a change window?

You can add a new ACE, it doesn’t terminate tunnels:

R4(config-ext-nacl)do sh runn | s access
ip access-list extended VPN
 permit ip host 150.1.4.4 20.0.0.0 0.0.0.255
R4(config-ext-nacl)per
R4(config-ext-nacl)permit ip
R4(config-ext-nacl)permit ip 150.1.4.0 0.0.0.255  20.0.0.0 0.0.0.255
R4(config-ext-nacl)
R4(config-ext-nacl)

As you see nothing happened, but when you remove any entry, even not related with your SA you can see:

R4(config-ext-nacl)do  sh run | s access
ip access-list extended VPN
 permit ip 150.1.4.0 0.0.0.255 20.0.0.0 0.0.0.255
 permit ip host 150.1.4.4 20.0.0.0 0.0.0.255
R4(config-ext-nacl)
R4(config-ext-nacl)no  permit ip 150.1.4.0 0.0.0.255 20.0.0.0

http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/vpn_site2site.htmlwp1042401

You can find one statement under the above link: “Configure ACLs that mirror each other on both sides of the connection.”

The answer is: not really. Let’s test it: one peer has following encryption domain:

asa1 sh run access-list
access-list VPN extended permit ip 20.0.0.0 255.255.255.0 host 150.1.4.4
asa1

one the second one:

R4(config-ext-nacl)
R4(config-ext-nacl)do sh runn | s access
ip access-list extended VPN
 permit ip 150.1.4.0 0.0.0.255 20.0.0.0 0.0.0.255
R4(config-ext-nacl)

As you see the ACL on my ASA is more specific (host 150.1.4.4).

Before I initiate traffic let’s check the ipsec sessions:

R4sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: DOWN
Peer: 10.0.0.1 port 500
  IPSEC FLOW: permit ip

In my today post I’d like analyze different version of traceroute on three platforms. You need to know exactly what protocols/types are used when you would like to permit them on your firewall.

1) Cisco version

I’m going now traceroute from R17 to R18:

This is what I captured on R17 interface:

Let me explain what we see:

R17 sends udp packet with ttl=1 to discover device in one hop distance. R16 decrements ttl by 1 and sees that ttl=0 and sends icmp packet ‘time exceeded):

-> udp - dst port: 33434, ttl=1
<- icmp - time exceeded (due to ttl=0) - type 11, code 0 - ttl=255

-> udp - dst port: 33435, ttl=1
<- icmp - time exceeded (due to ttl=0) - type 11, code 0 - ttl=255

-> udp - dst port: 33436, ttl=1
<- icmp - time exceeded (due to ttl=0) - type 11, code 0 - ttl=255

After three repeats R17 increases ttl by 1 and sends next three packets. R15 receives them, decreases ttl...

In today’s post I would like to look closer into one feature - proxy arp. On Cisco routers it is enabled by default and I think it’s worth of writing about possible pros and cons.
To be on the same page just few words about ARP (Address Resolution Protocol). ARP is used to resolve IP addresses to MAC (physical). When we want to send packet to a host with known IP address, we need first know its MAC or MAC of a next hop. This is place where ARP start its job. Let’s look into below diagram.

Assume that R1 has never contacted with R3 and I’m going to check its ARP table:

R1sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.1                -   ca00.18c4.0008  ARPA   FastEthernet0/0
R1

As you see I have only one entry with IP and MAC of the local interface. Before I ping R3 I enable debugging to see what’s happening behind the scene.

Today I’m going to present how to implement a high availability for ZBPF. Below you can see the scenario I work on:

As you see I have two routers (R1 and R2) which now operates separately. From R4 we can reach R5 via R1 and R2:

R4sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      4.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C

In my today lab I will try to implement DMVPN with some additional features like VRF and IPv6. As you see in the below picture, routers can establish secure connection over ASA.

My basic ip/ipv6 configuration:

hub:

hostname R1
!
vrf definition GREEN
 !
 address-family ipv6
 exit-address-family
!
ip vrf RED
!
ipv6 unicast-routing
!
interface Loopback100
 vrf forwarding GREEN
 no ip address
 ipv6 address 2001:100::1/64
!
interface FastEthernet0/0
 ip vrf forwarding RED
 ip address 5.5.5.1 255.255.255.0
 speed auto
 duplex auto
!
ip route vrf RED 0.0.0.0 0.0.0.0 5.5.5.2

next the spoke1:

hostname R2
!
vrf definition GREEN
 !
 address-family ipv6
 exit-address-family
!
ip vrf RED
!
ipv6 unicast-routing
!
interface Loopback100
 vrf forwarding GREEN
 no ip address
 ipv6 address 2001:200::2/64
!
interface FastEthernet0/0
 ip vrf forwarding RED
 ip address 6.6.6.1 255.255.255.0
 duplex