Connecting the world…

mac

Aruba WPA2 with MAC authentication

Configuring an SSID with WPA2 Pre-Shared key or Enterprise authentication and encryption is very common. Sometimes you would like to add an extra authentication method. Although this method isn’t very secure, MAC authentication is still used as an extra method to strengthen the level of security of a wireless or wired network.

These days I have been configuring a Aruba Networks wireless network with one master en two local controllers. The customer is using WPA2 security and wanted to add MAC authentication as extra authentication method. The configuration of MAC authentication for Aruba Mobility Controllers is very straightforward. This blog provides an example of the MAC authentication configuration. The configuration of a MAC Authentication Profile and the definition the MAC database are key in the solution.

While testing I noticed that MAC authentication only worked when I configured the parameter “Max Authentication Failures = 1” of the MAC Authentication Profile. The MAC address of the client is blacklisted if it’s unknown. When blacklisted, the client cannot associate with any SSID for at least one hour. This wasn’t exactly what I wanted to happen.

The following log contains the user-debug information during the authentication process, when the parameter is still set to 0.

Dec 14 09:01:20 :522005: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP=192.168.129.3 User entry deleted: reason=essid change
Dec 14 09:01:20 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=N/A User data downloaded to datapath, new Role=authenticated/54, bw Contract=0/0,reason=Station resetting role
Dec 14 09:01:20 :522042: <NOTI> |authmgr| User Authentication Failed: username=cc:08:e0:5e:2c:7b MAC=cc:08:e0:5e:2c:7b IP=0.0.0.0 auth method=MAC auth server=Internal
Dec 14 09:01:22 :522026: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP=192.168.129.3 User miss: ingress=0x1200, VLAN=666
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=0.0.0.0 User role updated, existing Role=WA-Test_role/none, new Role=WA-Test_role/WA-Test_role, reason=First IP user created
Dec 14 09:01:22 :522006: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP=192.168.129.3 User entry added: reason=Sibtye
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=192.168.129.3 User role updated, existing Role=WA-Test_role/WA-Test_role, new Role=WA-Test_role/WA-Test_role, reason=User not authenticated for inheriting attributes
Dec 14 09:01:22 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=192.168.129.3 User data downloaded to datapath, new Role=WA-Test_role/59, bw Contract=16385/16385,reason=New user IP processing

To me it looked like the authentication was using an OR statement instead of and AND statement. Eventually, with the help of cjoseph from Airheads Social, I noticed that after WPA2 authentication, the user gets the initial role of the AAA profile. I configured this profile as authenticated (allow all). Next MAC authentication is performed. If MAC authentication fails, the user still has the initial role from the AAA profile. If MAC authentication succeeds, the client is elevated to the MAC authentication role from the AAA profile.

I want both authentication methods to be successful before the client is granted access to the network. The only thing to change was, changing the initial role from the AAA profile to deny all.

aaa profile "WA-Test_aaa_prof"
   initial-role "denyall"
   authentication-mac "MAC_auth_prof"
   mac-default-role "WA-Test_role"
   mac-server-group "MAC-auth_srv"
   authentication-dot1x "default-psk"
   enforce-dhcp

Cacti and HP Procurve

Finding a template for HP Procurve switches wasn’t that hard. I needed to find a template for HP Procurve 2510G switches. The place to look for templates is forums.cacti.net. I searched the forums on the key word “procurve”, which resulted in many hits. I used the template from the article HP procurve 2600 series.

After importing all template you have the ability to monitor the MAC count on the switch and the memory usage. You also have the option to monitor the CPU usage, but you have to do some extra configuration. The zip file only contains a data template for the HP switches, but no graph template. I created my own graph template by duplicating the Cisco CPU graph template and changed the data source to the HP data template.

Graph Template Data Source

I changed the data source for the first 4 Items in the Graph Template to the HP procurve CPU data source. Next I created a device for the HP switches and added the appropriate “Associated Graph Templates” for HP procurve CPU, MAC count and memory usage. Now you only need to create a graph for the template and you are set to go.

Cacti - HP Procurve graphs

MAB and MDA in an IP Phone environment

I blogged before about the MAC Authentication Bypass (MAB) feature in network environments. MAC Authentication Bypass can be used to secure the wired network by verifying MAC addresses to a central database. By using a radius server, like Microsoft IAS or FreeRadius, you can also redirect verified MAC addresses to a specific VLAN.

Lately I had a new challenge with configuring MAB. These time a single switch port is shared by an IP phone and a workstation. The IP phone is used as a kind of switch. The backend switching network is build on Cisco Catalyst switches. All IP phone traffic is handled by the voice VLAN and all data traffic is handled by  the an access VLAN. The IP phones used in this situation are Mitel 5330 phones. These phones support CDP and also LLDP, which is perfect when using a voice VLAN.

The customer would like the MAC addresses of both devices verified against a central database. In this situation I used Microsoft IAS, because the customer is using Microsoft Active Directory as central database. In Active Directory I created an OU structure with an unique OU and security group for every logical group. So I created an OU voice and a security group voice, and I created a group data and an OU data. The MAC addresses of the components need to be added to Active Directory as users. The account name and the password are exactly the same and equal to the MAC address, like 001f22d712ef. I made the account for the IP phone member of the voice group and the account of the workstation member of the data group.

I started with just connecting a single workstation to the switch and configured IAS to verify the MAC address and automatically redirect the workstation to the correct access VLAN. The configuration of IAS is straightforward. First I installed IAS and registered the service in Active Directory. I added the switch as radius client and configured a radius policy for the data connections. The radius policy checks if the MAC address is member of the data group and returns the access VLAN if the MAC address is positively verified. This works without any problems. The screenshots below show the most important configuration of this policy.

data-radius-match data-radius-authentication data-radius-attribute

Next you see the switch configuration so far.

aaa new-model
!
aaa authentication dot1x default group radius
aaa authorization network default group radius
!
dot1x system-auth-control
!
interface FastEthernet0/35
switchport access vlan 102
switchport mode access
switchport nonegotiate
switchport voice vlan 150
authentication control-direction in
authentication port-control auto
authentication periodic
authentication timer restart 900
authentication timer reauthenticate 5400
mab
spanning-tree portfast
spanning-tree bpduguard enable
end

I configured another policy, exactly the same, for the voice components. I disconnected the workstation and connected the IP phone to the network. This also works without any problems. The IP phone is authenticated and allowed access to the network. Next I connected the workstation to the IP phone and booted the workstation. I noticed that the IP phone lost his power and checked the switch port status. The switch port went in err-disable state with the following message:

Feb  5 08:54:50.095 GMT+1: %AUTHMGR-5-SECURITY_VIOLATION: Security violation on the interface FastEthernet0/35, new MAC address (0080.647f.c590) is seen.
Feb  5 08:54:50.095 GMT+1: %AUTHMGR-5-SECURITY_VIOLATION: Security violation on the interface FastEthernet0/35, new MAC address (0080.647f.c590) is seen.
Feb  5 08:54:50.095 GMT+1: %PM-4-ERR_DISABLE: security-violation error detected on Fa0/35, putting Fa0/35 in err-disable state

This is a big problem, because both network components aren’t able to communicate with the network. I did some research and found the Multiple Domain Authentication (MDA) feature. Multiple Domain Authentication (MDA) allows both a data device and a voice device, such as an IP phone (Cisco or non-Cisco), to authenticate on the same switch port, which is divided into a data domain and a voice domain. This feature is configured with the authentication host-mode commands and is very useful when combining IEEE 802.1x and/or MAB in an IP phone environment. The following host-modes can be used:

Single-host mode should be configured if only one data host is connected. Do not connect a voice device to authenticate on a single-host port. Voice device authorization fails if no voice VLAN is configured on the port.

Multi-domain mode should be configured if data host is connected through an IP Phone to the port. Multi-domain mode should be configured if the voice device needs to be authenticated.

Multi-auth mode should be configured to allow up to eight devices behind a hub to obtain secured port access through individual authentication. Only one voice device can be authenticated in this mode if a voice VLAN is configured.

Multi-host mode also offers port access for multiple hosts behind a hub, but multi-host mode gives unrestricted port access to the devices after the first user gets authenticated.

I tested the multi-host configuration and it did exactly as explained above. Only one device is authenticated and all next device are allowed without authentication. In my situation I have to use multi-domain. I added the configuration line authentication host-mode multi-domain to the interface configuration above. After this I had a new problem. Both devices are authenticated correctly, but the Mitel IP phone got stuck at DHCP Discovery, while the workstation is working correctly.

After some sniffing I saw the Mitel phone sending its DHCP Discovery to the data VLAN, but the phone didn’t receive any DHCP Offer from a DHCP server. Back to the drawing table and I found the solution in the radius configuration. I configured the radius attribute cisco-av-pair in order to tell the switch that the IP phone is allowed on the voice VLAN, see the picture.

MAB-MDAThe following steps are taken during the process:

  1. 1. The IP Phones learns the voice VLAN ID from CDP;
  2. 2. The switch learns the MAC address of the phone and sends an Accept-Request for the phones MAC address to the radius server;
  3. 3. The radius server responds with an Access-Accept and adds the Vendor-Specific Attribute (VSA) Cisco-AV-pair with the value device-traffic-class=voice;
  4. 4. All traffic from the IP Phone is allowed in the voice VLAN and the DHCP process works flawlessly;
  5. 5. The workstation is also authenticated by the radius server and all data traffic is allowed in the data VLAN;

The radius policy for the voice VLAN is almost equal to the radius policy for the data/access VLAN. The only difference is in the radius attributes. Below you see the attributes for the voice radius policy.

voice-radius-attributeI did some testing and the environment is working perfectly. Both devices are authenticated separately from each other. The final configuration of the switch port looks like this:

interface FastEthernet0/35
switchport access vlan 102
switchport mode access
switchport nonegotiate
switchport voice vlan 150
authentication control-direction in
authentication host-mode multi-domain
authentication port-control auto
authentication periodic
authentication timer restart 900
authentication timer reauthenticate 5400
mab
spanning-tree portfast
spanning-tree bpduguard enable
end

Below you see some output from the show authentication sessions command. You can clearly see the domain where the device is authenticated in.

ONLY IP PHONE IS AUTHENTICATED SUCCESSFULLY

switch#show authentication session interface fa 0/35
Interface:  FastEthernet0/35
MAC Address:  0800.0f46.874a
IP Address:  Unknown
User-Name:  08000f46874a
Status:  Authz Success
Domain:  VOICE

Oper host mode:  multi-domain
Oper control dir:  in
Authorized By:  Authentication Server
Session timeout:  5400s (local), Remaining: 5397s
Timeout action:  Reauthenticate
Idle timeout:  N/A
Common Session ID:  0A0A421B00000065C2FF71B0
Acct Session ID:  0x0000014A
Handle:  0x04000065

Runnable methods list:
Method   State
mab      Authc Success

IP PHONE AND WORKSTATION ARE AUTHENTICATED SUCCESSFULLY

switch#show authentication session interface fa 0/35
Interface:  FastEthernet0/35
MAC Address:  0080.647f.c590
IP Address:  Unknown
User-Name:  0080647fc590
Status:  Authz Success
Domain:  DATA

Oper host mode:  multi-domain
Oper control dir:  in
Authorized By:  Authentication Server
Vlan Policy:  102
Session timeout:  5400s (local), Remaining: 5364s
Timeout action:  Reauthenticate
Idle timeout:  N/A
Common Session ID:  0A0A421B00000068C304A7C5
Acct Session ID:  0x0000014D
Handle:  0x56000068

Runnable methods list:
Method   State
mab      Authc Success

—————————————-
Interface:  FastEthernet0/35
MAC Address:  0800.0f46.874a
IP Address:  Unknown
User-Name:  08000f46874a
Status:  Authz Success
Domain:  VOICE

Oper host mode:  multi-domain
Oper control dir:  in
Authorized By:  Authentication Server
Session timeout:  5400s (local), Remaining: 5340s
Timeout action:  Reauthenticate
Idle timeout:  N/A
Common Session ID:  0A0A421B00000067C3043675
Acct Session ID:  0x0000014C
Handle:  0xE2000067

Runnable methods list:
Method   State
mab      Authc Success

IP PHONE IS AUTHENTICATED SUCCESSFULLY, WORKSTATION ISN’T

switch#show authentication session interface fa 0/35
Interface:  FastEthernet0/35
MAC Address:  0080.647f.c590
IP Address:  Unknown
User-Name:  UNRESPONSIVE
Status:  Authz Failed
Domain:  DATA

Oper host mode:  multi-domain
Oper control dir:  in
Session timeout:  N/A
Idle timeout:  N/A
Common Session ID:  0A0A421B00000066C300CB6C
Acct Session ID:  0x0000014B
Handle:  0xEB000066

Runnable methods list:
Method   State
mab      Failed over

—————————————-
Interface:  FastEthernet0/35
MAC Address:  0800.0f46.874a
IP Address:  Unknown
User-Name:  08000f46874a
Status:  Authz Success
Domain:  VOICE

Oper host mode:  multi-domain
Oper control dir:  in
Authorized By:  Authentication Server
Session timeout:  5400s (local), Remaining: 5261s
Timeout action:  Reauthenticate
Idle timeout:  N/A
Common Session ID:  0A0A421B00000065C2FF71B0
Acct Session ID:  0x0000014A
Handle:  0x04000065

Runnable methods list:
Method   State
mab      Authc Success

Juniper SA – Host Checker

Security is getting more and more important for people. I notice that especially IT manager would like to implement some kind of security measurements to improve the safety of their network and data. Lately I have been busy with configuring a Juniper SA solution. The customer wants to publish different kind of services through the Juniper SA to his employees or suppliers. Example of these services are file sharing and full IPSec tunnels. When using file sharing and full IPSec tunnels, the use of a virus scanner is arbitrary for all workstations connecting to the customers network through the Juniper. Juniper provides an option to configure a Host Checker to check if the client has a (specific) virus scanner. This kind of predefined check only works with Windows clients.

I wanted to configure a predefined Host Checker for all the Windows clients connecting to the Juniper SA box. The configured policy checks all Windows clients on a, by Juniper supported, virus scanner. This works perfectly, but I noticed at all Linux and Mac OS X users weren’t able to connect anymore. When configuring a Host Checker policy for Windows, you also have to configure a policy for other OS-users, like Linux and Mac OS X.

I didn’t know which policy to configure for these users, because the outcome of the policy check should be positive at all times. I have the option to check the presence of a specific file. This gave me the idea to configure a dummy file check for Linux and Mac OS X clients. The dummy file check has the following properties:

Host Check

The policy checks the presence of the file mac_dummy_file. To pass the host checker test, the file should NOT be present of the client. I configured a similar rule for Linux clients. By configuring the policy like this, all Windows clients are checked on the presence of a virus scanner and the Linux and Mac OS X hosts are checked on the dummy file. Normally, the dummy file doesn’t exist on the specific Linux / Mac OS X clients, so they are always allowed access to the Juniper.

I guess it’s a nice workaround….

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.