Connecting the world…

dynamic

FortiGate – IPSec with dynamic IP

Site-to-site VPN connections are a common way to connect a branch office to the corporate network. In the Netherlands it is still common to have a internet connection at a branch office with a dynamic IP address. The usage of dynamic IP address is not ideal when configuring a site-to-site VPN connection, because the configuration almost always relies on static IP addresses.

I recently configured an IPSec VPN between two FortiGate appliances and the branch appliance is using a dynamic IP address. I used Fortinet’s DDNS feature to configure the VPN.

To configure the branch FortiGate for DDNS, I had to configure the WAN interface to retrieve its IP address via DHCP. Next I configured DDNS.

config system ddns
edit 1
set ddns-server FortiGuardDDNS
set ddns-domain “branche01-booches.fortiddns.com”
set monitor-interface “wan1”
next
end

This can also be done in the GUI.

FortiDDNS

The VPN configuration on the hub firewall for dynamic DNS support is the same as the configuration of a regular VPN connection. The only difference is the configuration of the peer IP address. Instead of a static IP, you configure the DDNS FQDN.

config vpn ipsec phase1-interface
edit “vpn_p1_branche01”
set type ddns
set interface “wan1”
set proposal 3des-sha1
set dhgrp 2
set remotegw-ddns “branche01-booches.fortiddns.com”
set psksecret P$k-VPN!
next
end

And as you can image, this can also be done via the GUI.

FortiDDNS IPSec - HQ

Check the status of the VPN connection via the regular methods like cli (get vpn ike gateway or get vpn ipsec tunnel name <tunnel-name>) or via the GUI.

IPplan – IP address management

A lot of customers have different methods for their IP address management. Most of them use some kind of static documentation, like an Excel sheet. In the past I implemented IPplan multiple times. I like this tool, because it dynamically scans multiple IP subnets, using ICMP and/or Nmap. Another advantage of IPplan is its ability to perform hostname lookups.

Often I install IPplan on an active management system, like CactiEZ. The following howto shows the steps to implement IPplan under CactiEZ.

The first step is downloading the appropriate tar.gz file and extract his file in /var/www/html, like shown below.

tar zxvf ipplan-4.92a.tar.gz

Next I change the ownership and permissions of the ipplan directory.

chown –R apache:apache ipplan
chmod –R 750 ipplan

After changing the permissions I create the necessary database for ipplan.

mysql –u root –p
mysql> create database ipplan;

This creates a database called ipplan. Now we need to create a user with the appropriate permissions for the ipplan database.

mysql> GRANT SELECT,INSERT,UPDATE,DELETE on ipplan.* \
    -> TO ipplan@localhost IDENTIFIED by ‘password’;

You can change the value ‘password’ to a password you wish. Change the credentials, configured in the previous step, in the file called config.php.

Open a web browser and point it to the installation script in the admin directory (http://ip-address/ipplan/admin/install.php). You will be prompted to create the database schema. The user created above does not have enough permissions to create tables so you will need to either copy the statements into the database, or temporarily change the database password in the config.php file to a database user that has enough rights to do this. You could be asked to enter user credentials for the website. This user credentials can be found in config.php.

I always load the statements by copying the display output from the install.php script into a file (ipplan.sql) and then executing the file using mysql statements.

mysql –u root –p ipplan < ipplan.sql

The basic installation is now complete. We will now go ahead and create a private menu. Open the file config.php and find the section START OF MENU EXTENSION. Change this section into the following to create a private menu.

// private menu extensions to the ipplan menu system
define(“MENU_PRIV”, TRUE);
define(“MENU_EXTENSION”,
“.|4IP
..|Show used area’s|http://<ip address>/ipplan/user/modifyarearange.php?cust=1
..|Show used subnets|http://<ip address>/ipplan/user/treeview.php
..|Create new subnets|http://<ip address>/ipplan/user/createsubnetform.php
..|Edit subnets|http://<ip address>/ipplan/user/modifybaseform.php

);

The IPplan poller needs to be added to the crontab configuration. The IPplan poller uses a custom file to know which IP addresses the scan. I normally create a .txt file. The following output show the syntax for the .txt file.

172.22.2.0/24
10.10.0.0/22

I configure the poller to run every day at 9, 12 and 15. You can edit the crontab with the command:

crontab –e

# Crontab for IPplan poller
0 9,12,15 * * * php /var/www/html/ipplan/contrib/ipplan-poller.php -hostnames -c 1 -f /var/www/html/ipplan/4IP-Networks.txt

There is one last step to take. When you manually execute the command above, you will receive the following error message:

Cannot find NMAP!

The last step is to install NMAP and configure its location in config.php. CactiEZ uses yum to install packages. So I use the following command to install nmap.

yum install nmap

Nmap can be found in the directory /usr/bin/. Look for the nmap section in config.php and change the nmap configuration to the following.

//define(“NMAP”, ”);
define(“NMAP”, ‘/usr/bin/nmap’);

The rest of the configuration needs to be done through the web interface. My advise is to configure some user groups and users, before adding subnets to IPplan. You can also change more settings in config.php to match it to your own environment, like the e-mailserver and helpdesk e-mail address.

Sometimes you receive Fatal error: require_once(): Failed opening required ‘../adodb/adodb.inc.php’ message. I resolved this issue by changing line 42 & 43 in ipplan-poller.php from:

require_once(“../adodb/adodb.inc.php”);
require_once(“./config.php”);

to

require_once(“/var/www/html/ipplan/adodb/adodb.inc.php”);
require_once(“/var/www/html/ipplan/config.php”);

This should solve the problem.

Redundant DMVPN network

Today I looked at the configuration DMVPN (Dynamic Multipoint VPN). A Dynamic Multipoint Virtual Private Network is an enhancement of the virtual private network (VPN) configuration process of Cisco IOS-based routers. DMVPN prevents the need for pre-configured (static) IPsec peers in crypto-map configurations and ISAKMP peer statements. This feature of Cisco IOS allows greater scalability over previous IPsec configurations. An IPsec tunnel between two Cisco routers may be created on an as needed basis.

I have created a situation with GNS3, where I have two hub routers and one spoke router. This situation creates extra redundancy when connecting to the hub location. There are two ways to configure redundancy in DMVPN:

  1. Dual hub-dual DMVPN cloud
  2. Dual hub-single DMVPN cloud

In the first scenario the hub routers are connecting to there own DMVPN network. This means that the spoke need to configure two tunnel interfaces to connect to two different DMVPN networks. In the second scenario both hub routers connect to the same DMVPN network. I configured the second scenario using GNS3. The figure below shows my practice setup.

redundant_dmvpn

The configuration from the three routers can be found below.

router R0

key chain authen-hsrp
key 1
key-string hsrp@test
key chain authen-eigrp
key 1
key-string eigrp@test
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key pr3sh@r3d-k3y address 0.0.0.0 0.0.0.0
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 120 30 periodic
!
!
crypto ipsec transform-set stong-ts esp-aes 256 esp-sha-hmac
!
crypto ipsec profile dmvpn
set transform-set strong-ts
set pfs group5
!
interface Tunnel0
ip address 192.168.255.1 255.255.255.0
no ip redirects
ip mtu 1440
ip hello-interval eigp 1024 15
ip hold-time eigrp 1024 45
no ip next-hop-self eigrp 1024
ip authentication mode eigrp 1024 md5
ip authentication key-chain eigrp 1024 authen-eigrp
ip nhrp authentication nhrp@booches
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp holdtime 600
no ip split-horizon eigrp 1024
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile dmvpn
!
interface FastEthernet0/0
description outside
ip address 80.80.10.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
description inside
ip address 10.10.13.2 255.255.255.0
duplex auto
speed auto
standby 1 ip 10.10.13.1
standby 1 priority 200
standby 1 preempt
standby 1 authentication md5 key-chain authen-hsrp
!
router eigrp 1024
network 10.10.13.2 0.0.0.0
network 192.168.255.1 0.0.0.0
no auto-summary

router R1

key chain authen-hsrp
key 1
key-string hsrp@test
key chain authen-eigrp
key 1
key-string eigrp@test
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key pr3sh@r3d-k3y address 0.0.0.0 0.0.0.0
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 120 30 periodic
!
crypto ipsec transform-set strong-ts esp-aes 256 esp-sha-hmac
!
crypto ipsec profile dmvpn
set transform-set strong-ts
set pfs group5
!
interface Tunnel0
ip address 192.168.255.2 255.255.255.0
no ip redirects
ip mtu 1440
ip hello-interval eigrp 1024 15
ip hold-time eigrp 1024 45
no ip next-hop-self eigrp 1024
ip authentication mode eigrp 1024 md5
ip authentication key-chain eigrp 1024 authen-eigrp
ip nhrp authentication nhrp@booces
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp holdtime 600
no ip split-horizon eigrp 1024
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile dmvpn
!
interface FastEthernet0/0
description outside
ip address 50.50.1.3 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
description inside
ip address 10.10.13.3 255.255.255.0
duplex auto
speed auto
standby 1 ip 10.10.13.1
standby 1 priority 100
standby 1 preempt
standby 1 authentication md5 key-chain authen-hsrp
!
router eigrp 1024
network 10.10.13.3 0.0.0.0
network 192.168.255.2 0.0.0.0
no auto-summary

router R3

key chain authen-eigrp
key 1
key-string eigrp@booches
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key pr3sh@r3d-k3y address 0.0.0.0 0.0.0.0
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 120 30 periodic
!
crypto ipsec transform-set strong-ts esp-aes 256 esp-sha-hmac
!
crypto ipsec profile dmvpn
set transform-set strong-ts
set pfs group
!
interface Tunnel0
ip address 192.168.255.3 255.255.255.0
no ip redirects
ip mtu 1440
ip hello-interval eigrp 1024 15
ip hold-time eigrp 1024 45
ip authentication mode eigrp 1024 md5
ip authentication key-chain eigrp 1024 authen-eigrp
ip nhrp authentication nhrp@booches
ip nhrp map multicast dynamic
ip nhrp map 192.168.255.1 80.80.10.2
ip nhrp map multicast 80.80.10.2
ip nhrp map 192.168.255.2 50.50.1.3
ip nhrp map multicast 50.50.1.3
ip nhrp network-id 1
ip nhrp holdtime 600
ip nhrp nhs 192.168.255.1
ip nhrp nhs 192.168.255.2
no ip route-cache cef
no ip route-cache
no ip mroute-cache
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile dmvpn shared
!
interface FastEthernet0/0
description outside
ip address 40.40.10.4 255.255.255.0
speed auto
duplex auto
!
interface FastEthernet0/1
description inside
ip address 192.168.1.1 255.255.255.0
speed auto
duplex auto
!
router eigrp 1024
network 192.168.1.1 0.0.0.0
network 192.168.255.3 0.0.0.0
no auto-summary

I configured EIGRP authentication as an extra feature. This setup was configured with GNS3, so I guess it needs more tweaking to implement it in a real network. It should however provide a solid base for configuring a redundant DMVPN solution.

Policy NAT on Cisco router

A colleague of mine had to implement an IPSec VPN tunnel from a customer to a supplier. The customer has a Cisco router for connecting to the Internet, so nothing special. The router is already setup and in production. Configuring an extra IPSec VPN tunnel isn’t very hard, the most important part is the negotiation of Phase 1 and Phase 2 credentials for the IPSec VPN connection.

This particular situation was different, because the customer has to NAT his local IP addresses into the VPN tunnel. I don’t actual configure this quiet often on routers, but more on firewalls. I setup a testing environment with GNS3 to do my own configuration.

The testing environment is displayed below. When connecting from the LAN from R1 (10.1.1.0/24) to the Internet normal NAT overload in configured. In the picture the network behind R3 represents the Internet. When connecting from R1 to R2, the source IP address (Inside Local) is translated to an address from the pool 10.22.44.0/24 (Inside Global). There is also a static NAT mapping for IP address 10.1.1.222 into the VPN tunnel (10.22.44.222).

POLNAT-RTR

At first I configured the environment like showed above. I configured the different interfaces and the corresponding IP addresses. Router R1 and R2 use router R3 as default gateway. The configuration of the specific routers is attached at the end of the post.

The first snippet shows the necessary NAT configuration on R1 for the Internet connection.

interface Loopback0
description INSIDE
ip address 10.1.1.1 255.255.255.0
ip nat inside
!
interface FastEthernet0/0

description OUTSIDE
ip address 212.123.212.9 255.255.255.248
ip nat outside
duplex auto
speed auto

!
ip nat inside source list ACL-NAT interface FastEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 212.123.212.11
!
ip access-list extended ACL-NAT
permit ip 10.1.1.0 0.0.0.255 any

When trying to ping Lo0 on router R3, I see the following NAT table on router R1.

R1#ping 192.168.3.1 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/46/76 ms
R1#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:3   10.1.1.1:3         192.168.3.1:3      192.168.3.1:3

This proves that regular NAT overloading works perfectly with the current configuration. Next I configured the Policy IPSec VPN between routers R1 and R2. The configuration isn’t that spectacular, you should pay attention to the NAT statements and ACL statements. I even configured reverse route injection for the LAN network of R2. When enabling reverse route injection a route with the remote network (172.16.2.0) pops up in the routing table. This feature can be used when redistributing static routes into a routing protocol like EIGRP.

Next I will show some snippets, with some comments, of the configuration of router R1.

\\ Specifying the Phase I and Phase II properties for the IPSec VPN

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key VPN@Booches address 212.123.212.10
!
crypto ipsec transform-set VPN-TS esp-aes 256 esp-sha-hmac
!
crypto map CM-VPN-R2 10 ipsec-isakmp
set peer 212.123.212.10
set transform-set VPN-TS
match address VPN-R2
reverse-route

!

\\ Loopback interface with 2 IP addresses for testing purposes

\\ Secondary IP address is used for static policy NAT testing

interface Loopback0
ip address 10.1.1.222 255.255.255.0 secondary
ip address 10.1.1.1 255.255.255.0
ip nat inside

!

\\ Outside interface with the crypto map applied to this interface
interface FastEthernet0/0
description OUTSIDE
ip address 212.123.212.9 255.255.255.248
ip nat outside
duplex auto
speed auto
crypto map CM-VPN-R2

!

ip nat translation timeout 30

\\ NAT pool for dynamic policy NATZ
ip nat pool LAN-R2 10.22.44.1 10.22.44.254 netmask 255.255.255.0

\\ Default NAT for regular Internet related traffic
ip nat inside source list ACL-NAT interface FastEthernet0/0 overload

\\ NAT statement for dynamic policy NAT and static policy NAT
ip nat inside source list ACL-POLICY-NAT pool LAN-R2 overload
ip nat inside source static 10.1.1.222 10.22.44.222 route-map RM-STATIC-NAT extendable

!

\\ ACL to define traffic to be NATted for regular Internet related traffic

ip access-list extended ACL-NAT
deny   ip 10.1.1.0 0.0.0.255 172.16.2.0 0.0.0.255
deny   ip 10.22.44.0 0.0.0.255 172.16.2.0 0.0.0.255
permit ip 10.1.1.0 0.0.0.255 any

\\ ACL to define traffic to be dynamic policy NATted into IPSec VPN tunnel
ip access-list extended ACL-POLICY-NAT

deny   ip host 10.1.1.222 172.16.2.0 0.0.0.255
permit ip 10.1.1.0 0.0.0.255 172.16.2.0 0.0.0.255

\\ ACL to define traffic to be static policy NATted into IPSec VPN tunnel
ip access-list extended ACL-STATIC-POLICY-NAT
permit ip host 10.1.1.222 172.16.2.0 0.0.0.255

\\ ACL to define interesting traffic for the IPSec VPN tunnel
ip access-list extended VPN-R2
permit ip 10.22.44.0 0.0.0.255 172.16.2.0 0.0.0.255
!

\\ Route map static to configure static policy NAT statement
route-map RM-STATIC-NAT permit 10
match ip address ACL-STATIC-POLICY-NAT

I issued some ping commands and looked at the IP NAT Translations table to test the environment. The test results are displayed below.

SOURCE 10.1.1.1 (R1) – DESTINATION 172.16.2.1 (R2) & 212.123.212 (R3)

R1#ping 172.16.2.1 source 10.1.1.1
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/52/120 ms
R1#ping 212.123.212.11 source 10.1.1.1
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/48/84 ms
R1#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:29  10.1.1.1:29        212.123.212.11:29  212.123.212.11:29
icmp 10.22.44.1:28     10.1.1.1:28        172.16.2.1:28      172.16.2.1:28

SOURCE 10.1.1.222 (R1) – DESTINATION 172.16.2.1 (R2) & 212.123.212 (R3)

R1#ping 172.16.2.1 source 10.1.1.222
Packet sent with a source address of 10.1.1.222
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/48/84 ms
R1#ping 192.168.3.1 source 10.1.1.222
Packet sent with a source address of 10.1.1.222
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/44/60 ms
R1#sh ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:37  10.1.1.222:37      192.168.3.1:37     192.168.3.1:37
icmp 10.22.44.222:36   10.1.1.222:36      172.16.2.1:36      172.16.2.1:36

 

SOURCE 172.16.2.1 (R2) – DESTINATION 10.22.44.222 (R1)

R2#ping 10.22.44.222 source 172.16.2.1

Packet sent with a source address of 172.16.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/53/112 ms

All ICMP testing gave positive results and policy-based NAT on the Cisco router is working perfectly.

Configurations:

Layer 2 security

I attended the session layer 2 security, because I had some discussions about layer 2 security with one of my colleagues. We were discussing about using layer 2 security and especially implementing it in the environments from our customers.

Looking at my/our customers, I don’t see environments where layer 2 threats would be immediate. But in my opinion, you will never know when it will be immediate. I prefer to implement as much layer 2 security (and security in general) as possible. Maybe I am a little paranoia ;-).

I was very interested in the countermeasures used in active networks and the caveats to these countermeasures. Looking at layer 2 networks, the following topics these are the most common attacks.

VLAN HOPPING

Connections between two switches are mostly configured as trunk ports (IEEE 802.1Q). All VLAN travel these trunk connections. Cisco switches have the capability to dynamically negotiate a trunk port. This means that all edge ports can become trunk ports. When an attacker can spoof to be switch, he could configure a trunk connection with the switch. By configuring a trunk connections with the switch, the attacker has access to all VLAN configured on the trunk. You have to disable the DTP (Dynamic Trunking Protocol) on the edge ports to mitigate these attacks. DTP is disabled with the command switchport nonegotiate. When tagging VLAN’s to a trunk it is preferred to use VLAN allowed lists on the trunks. This prevents that all VLAN’s have access to the trunk, only the specified VLAN’s will have access to the trunk.

MAC ADDRESS ATTACKS

Flooding the CAM table with bogus entries makes a hub out of a switch. When the CAM table is full, all traffic without an entry in the CAM table will be flooded out every port on the switch. This means that an attacker can intercept all traffic from the switch. Flooding the CAM table of a switch can also resultant in full CAM tables on adjacent switches. Countermeasures against CAM flooding attacks is the use of port security. To fill the CAM table an attacker will send a lot of different bogus MAC address to the switch. By limiting the allowed MAC address on a switch port, this attack can be prevented. When limiting the number of allowed MAC addresses on a port, you should pay attention to the number of MAC address you configure. Think of features like CDP, LLDP (Link Layer Discovery Protocol), IP Phones, VMware and so one. These features could generate additional MAC entries on the specific switch port. An example configuration for port security is shown below:

switchport port-security
switchport port-security maximum 1 vlan voice
switchport port-security maximum 1 vlan access
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity

DHCP ATTACK

DHCP is used in networks to dynamically assign IP addresses and other options to clients. A DHCP scope contains a range of IP addresses and options, which can be assigned to clients. A known attack against DHCP is DHCP starvation. During a DHCP starvation attack an attacker tries to lease all different IP addresses. Most of the tools on the Internet for DHCP starvation use one MAC address for every lease. This means that an attacker uses multiple MAC addresses on the switch port where he connects to the network. Knowing this, you already know the solution to this attack. Just like the MAC address attacks, the solution lies in only allowing a predefined number of MAC addresses on the switch port. There are tools which use the same MAC address, but change Client Hardware Address (CHADDR) in an IPv4 DHCP Packet. This kind of attacks are mitigated by using DHCP Snooping.

Another DHCP attack is adding an untrusted or rogue DHCP server to the network. This way an attacker can assign the “wrong” IP addresses and options, like gateway and DNS servers. This kind of attacks is also mitigated by using DHCP snooping. When turning on DHCP snooping all switch ports will become untrusted. It is important to trust the port to the real DHCP server. The next snippets show examples for configuring DHCP snooping.

GLOBAL CONFIG

ip dhcp snooping vlan 1,10,100

no ip dhcp snooping information option

ip dhcp snooping

UNTRUSTED CLIENT INTERFACE CONFIG

no ip dhcp snooping trust

ip dhcp snooping limit rate 10

TRUSTED SERVER OR UPLINK INTERFACE CONFIG

ip dhcp snooping trust

By enabling DHCP snooping the switch starts building a DHCP snooping binding table. The DHCP snooping binding table is crucial when using DHCP snooping. This table contains the mappings of MAC, IP address, lease time, type of packet, VLAN and snooped interface, like the example below.

DHCP Snooping

The most clients do another DHCP request in the event of a link down and link up event, but not all clients to. For example some Linux systems won’t re-DHCP in the event of link down and link up. When a switch reboots, the DHCP snooping binding table will be lost. If a client doesn’t re-DHCP, the client is denied access to the network, because there is no entry in the DHCP snooping binding table. This means that it is important to backup the DHCP snooping binding table in the event of a switch failure. The DHCP snooping binding table can be written to bootflash, ftp, rcp, slot0 and tftp, like the example shows.

ip dhcp snooping database tftp://10.10.1.1/tftpboot/dhcp-snooping-table

ip dhcp snooping database write-delay 60

Entries in the DHCP snooping binding table stay there until the lease timer expires. When you can a real mobile network it is advised to tune the DHCP lease timers.

ARP ATTACKS

An ARP entry maps a MAC address to an IP address. An attacker can claim, by poisoning the ARP table, to be for example the default gateway of the subnet. This is achieved by replying and poisoning the network by “telling” that the attackers MAC address should be mapped to the default gateway IP address. This way the attacker receives all the traffic designated to the default gateway, which gives the attacker the possibility to perform a man-in-the-middle attack.

An ARP attack can be mitigated by the use of Dynamic ARP Inspection. By using Dynamic ARP Inspection (DIA) the switch checks the IP/MAC mappings in the DHCP snooping binding table. This implies that DHCP snooping is needed for DIA. Another method of mitigating ARP attacks is by checking the source and/or destination MAC addresses and/or IP addresses.

GLOBAL CONFIG

ip dhcp snooping vlan 4,104
no ip dhcp snooping information option
ip dhcp snooping
ip arp inspection vlan 4,104
ip arp inspection log-buffer entries 1024
ip arp inspection log-buffer logs 1024 interval 10

UNTRUSTED CLIENT INTERFACE CONFIG

no ip dhcp snooping trust

ip dhcp snooping limit rate 10

no ip arp inspection trust

TRUSTED SERVER OR UPLINK INTERFACE CONFIG

ip dhcp snooping trust
ip arp inspection trust

ENABLE ALL VALIDATION COMMANDS

ip arp inspection validate src-mac dst-mac ip

SPOOFING ATTACKS

In an spoofing attack the attacker uses the MAC address or IP address of a “real” networking component. Spoofing attacks are performed for the following reasons:

MAC SPOOFING

  • when using MAC authentication on the network the attacker can gain access to the network;
  • the attacker takes over the identity of someone already known on the network;

IP SPOOFING

  • Ping of death attack;
  • ICMP unreachable storm;
  • SYN floods on the network;
  • the attacker takes over the identity of someone already known on the network;

The countermeasure for spoofing attacks is the use of IP Source Guard. IP Source Guard can be compared with Dynamic ARP Inspection, the difference lies in the fact that IP Source Guard checks every packet and not only ARP packets.

These are the most common layer 2 attacks known today. There are some more, like attacks on the Spanning Tree Protocol. These attacks can be mitigated with techniques like BPDUGuard and RootGuard.

I will definitely start using more of the techniques mentioned above in customer environments. It will be a real challenge to implement some of the techniques without disrupting the daily work on the network.