hzw -

My notes about IT, security, CCIE Security journey, routers, firewalls and many more…To contact me, send an email to: myitmicroblog@gmail.com

Page 9


L2 security – Address Resolution Protocol (ARP).

I would like to look closer on the ARP protocol, how it works and what kind of security method we can use to control ARP packets.

       /----\                  /----\ 
      |  R1  |----------------|  R2  |
       \----/\                /\----/ 
            Gig0/0       Gig0/0
            10.0.0.1   10.0.0.2     

Let’s check what we see in the ARP table:

R1sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.1                -   ca02.0eb8.0008  ARPA   GigabitEthernet0/0
R1sh arp detail
ARP entry for 10.0.0.1, link type IP.
  Interface, via GigabitEthernet0/0, last updated 69 minutes ago.
  Encap type is ARPA, hardware address is ca02.0eb8.0008, 6 bytes long.
  ARP subblocks:
  * Interface ARP Subblock

R1

R2sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.2                -   ca03.0eb8.0008
...

Continue reading →


L2 security – protected ports.

Sometimes we have to isolate some hosts from each other. We can use ‘private vlan’ feature or simpler solution like ‘protected ports’. The feature can be easily enabled on designated ports. The communication between ‘protected’ and normal ports is allowed. The main difference between ‘private vlan’ and ‘protected port’ is the second one is limited to only one device. You can’t block traffic between two ports on separate devices.

                   Fa1/0/9   Fa1/0/11           
          /----\      \  ----- /       /----\ 
         |  R1  |-------| sw1 |-------|  R2  |
          \----/\        -----        /\----/ 
               Gig0/0      |      Gig0/0
              10.0.0.1     |     10.0.0.2     
                           | \
                        /----\ fa0/0 
                       |  R3  | 10.0.0.3
                        \----/

Let’s configure switch ports Fa1/0/9 and...

Continue reading →


L2 security – storm control.

Storm control is a security feature that protects network against packet flood. You can monitor unicast, broadcast and multicast packets. There are three measure methods: traffic rate: pps – packet per second, bps – bit per second, and percentage of interface bandwidth. You can define two actions which will be triggered once the storm occurs: shutdown or trap.
Let’s do some tests on the following scenario:

            both switch port access vlan1 

                   Fa1/0/9   Fa1/0/11           
          /----\      \  ----- /       /----\ 
         |  R1  |-------| sw1 |-------|  R2  |
          \----/\        -----        /\----/ 
               Gig0/0             Gig0/0
              10.0.0.1           10.0.0.2     

a) Storm control for unicast:

On both ports of sw1 we enable storm control with limit of 5 packets per second:

MP-SW(config-if-range)storm-control unicast level
...

Continue reading →


ZBFP and self zone policy.

Let’s continue our tests with the ZBPF. Now I’m going to implement L3 firewall (no transparent) and block EIGRP and OSPF packets sent and received on the outside interface (gig0/0).

                    OUTSIDE     L3 firewall      INSIDE
                  [10.0.0.1]                   [10.0.0.3] 
                    /----\        /----\         /----\ 
                      R1  |------|  R2  |-------|  R3  |
                    \----/      / \----/ \       \----/ 
                            gig0/0     gig0/1  

                               <-X->| <-->
                               eigrp, ospf
R1:

!
interface GigabitEthernet0/0
 ip address 10.0.0.1 255.255.255.0
 !
!
router eigrp 1
 network 0.0.0.0
!
router ospf 1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!

R2:

interface GigabitEthernet0/0
 ip address 10.0.0.2 255.255.255.0
!
interface GigabitEthernet0/1
...

Continue reading →


Transparent Firewall (IOS) and ZBPF.

I would like to continue working with transparent firewalls and today we try to implement the Zone Base Policy Firewall:

         OUTSIDE     L2 firewall      INSIDE
        [10.0.0.1]                   [10.0.0.3] 
          /----\        /----\         /----\ 
         |  R1  |------|  R2  |-------|  R3  |
          \----/      / \----/ \       \----/ 
                gig0/0.10   gig0/1.20  
                      icmp, telnet

                      <---------      

R2 - firewall is not enabled:

bridge irb
!
bridge 1 protocol ieee
!
interface GigabitEthernet0/0
 no sh
!
interface GigabitEthernet0/0.10
 encapsu dot 10
 no ip address
 bridge-group 1
!
interface GigabitEthernet0/1
 no sh
!
interface GigabitEthernet0/1.20
 encapsu dot 20
 no ip address
 bridge-group 1
!
no ip routing
!

R2 is configured as the L2 device and it doesn’t do any traffic control:

r1ping 10.0.0.3
...

Continue reading →


Transparent Firewall (IOS) and CBAC.

Sometimes you have to implement L2 firewall in your network. There are many reasons to choose this solution and one of them is to preserve your L3 design. On Cisco routers you can implement IRB (Integrated Routing & Bridging) or CRB (Concurrent Routing & Bridging). The first one allows on exchanging traffic between routed and bridged interfaces. While CRB totally separate these types of traffic (L2 and L3). If you need L3 interface together with L2 you have to add BVI interface with IP from the same subnet as its neighbors.


IRB (with BVI interface):

bridge irb
!
interface GigabitEthernet0/0.10
 encapsulation dot1Q 10
 bridge-group 1
!
interface GigabitEthernet0/1.20
 encapsulation dot1Q 20
 bridge-group 1
!
interface BVI1
 ip address 31.31.31.31 255.255.255.0
!
bridge 1 protocol ieee
!

IRB (without BVI interface):

bridge irb
!
interface GigabitEthernet0/0.10
 encapsulation
...

Continue reading →


DMVPN phase 3 OSPF.

I’ve recently tested the different phases (1-3) of a DMVPN for EIGRP and OSPF. I found one strange thing for phase 3 and OSPF. According to official Cisco documentation (IOS 15.2) for OSPF, you should apply the following configurations for the Tunnel interface:

Phase 1 – no direct communication between spoke routers

HUB & SPOKE: ip ospf network point-to-multipoint

Phase 2 – direct communication between spokes is allowed

HUB & SPOKE: ip ospf network broadcast
SPOKE: ip ospf priority 0

Phase 3* – improved Phase 2

HUB: ip nhrp redirect
     ip ospf network point-to-multipoint 
SPOKE: ip nhrp shortcut
       ip ospf network point-to-multipoint 

I discovered that while using phase 3 configuration traffic between Spoke routers is always sent through the Hub (just like for phase 1) and this seems to be caused by a problem with the NHRP:

                          HUB
...

Continue reading →


General overview of Context-Based Access Control (CBAC).

On the Cisco IOS you can enable state-full firewall and enable protocols which should be inspected. There are many general settings like audit, logging and some settings per each named inspection. Each named inspection has to be applied on an interface with proper direction (in/out).

ip inspect name CBAC ftp timeout 30

ip inspect name CBAC tcp

int gig0/0

inspect CBAC out

There is no implicit deny for non-inspected protocols after the inspection (like for ZBFW) and to protect your network you have to add an access list with the deny statement:

ip access-list extended OUT

deny ip any any


int gig0/0

ip access-group OUT in 

View →


The logic of NTP authentication, who can speak with whom (sec, non-sec ntp client, server)?

You can have both types of clients (with and without authentication) and they can speak with the same NTP server. For instance, if your server has an authentication enabled you can have also clients without authentication and they can still synchronize their clocks. The authentication doesn’t protect against unauthorized clients who are in the network but against false NTP servers. If you install unauthorized server with wrong or without password, clients with password won’t synchronize their clocks with the NTP server. So, it’s better to have clients with authentication enabled, they are protected against such attacks.

ntp server (no auth) <---->   ntp client (no auth)
ntp server (auth)    <---->   ntp client (auth)
ntp server (auth)    <---->   ntp client (no auth)
ntp server (auth)    <--X-->  ntp client (auth) different passwords
ntp server (no auth) <--X-->  ntp client (auth)

Continue reading →