MAC Verification

Tom Eastep

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

2016/02/16


All traffic from an interface or from a subnet on an interface can be verified to originate from a defined set of MAC addresses. Furthermore, each MAC address may be optionally associated with one or more IP addresses.

Important

MAC addresses are only visible within an Ethernet segment so all MAC addresses used in verification must belong to devices physically connected to one of the LANs to which your firewall is connected.

This means what it says! MAC addresses are only used within a LAN and never go outside of that LAN so please don't post on the mailing list asking how to use MAC addresses of computers connected to remote networks. The only MAC address that your firewall is going to see from these hosts is the MAC address of your upstream router.

Important

Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC - module name ipt_mac.o).

Important

MAC verification is only applied to new incoming connection requests.

Important

DO NOT use MAC verification as your only security measure . MAC addresses can be easily spoofed. You can use it in combination with either IPSEC or OpenVPN.

Components

There are six components to this facility.

  1. The maclist interface option in /etc/shorewall/interfaces. When this option is specified, all new connection requests arriving on the interface are subject to MAC verification.

  2. The maclist option in /etc/shorewall/hosts. When this option is specified for a subnet, all new connection requests from that subnet are subject to MAC verification.

  3. The /etc/shorewall/maclist file. This file is used to associate MAC addresses with interfaces and to optionally associate IP addresses with MAC addresses.

  4. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables in /etc/shorewall/shorewall.conf. The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and determines the disposition of connection requests that fail MAC verification. The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection requests that fail verification are to be logged. If set the empty value (e.g., MACLIST_LOG_LEVEL="") then failing connection requests are not logged.

  5. The MACLIST_TTL variable in /etc/shorewall/shorewall.conf. The performance of configurations with a large numbers of entries in /etc/shorewall/maclist can be improved by setting the MACLIST_TTL variable.

    If your iptables and kernel support the "Recent Match" (see the output of "shorewall check" near the top), you can cache the results of a 'maclist' file lookup and thus reduce the overhead associated with MAC Verification.

    When a new connection arrives from a 'maclist' interface, the packet passes through the list of entries for that interface in /etc/shorewall/maclist. If there is a match then the source IP address is added to the 'Recent' set for that interface. Subsequent connection attempts from that IP address occurring within $MACLIST_TTL seconds will be accepted without having to scan all of the entries. After $MACLIST_TTL from the first accepted connection request from an IP address, the next connection request from that IP address will be checked against the entire list.

    If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not be cached).

  6. The MACLIST_TABLE variable in /etc/shorewall/shorewall.conf. Normally, MAC verification occurs in the filter table (INPUT and FORWARD) chains. When forwarding a packet from an interface with MAC verification to a bridge interface, that doesn't work.

    This problem can be worked around by setting MACLIST_TABLE=mangle which will cause MAC verification to occur out of the PREROUTING chain. Because REJECT isn't available in that environment, you may not specify MACLIST_DISPOSITION=REJECT with MACLIST_TABLE=mangle.

/etc/shorewall/maclist

See shorewall-maclist(5).

Examples

Example 1. My MAC Validation configuration at a point in the past

/etc/shorewall/shorewall.conf:

MACLIST_DISPOSITION=REJECT
MACLIST_LOG_LEVEL=info

/etc/shorewall/interfaces:

#ZONE   INTERFACE       BROADCAST       OPTIONS
net     $EXT_IF         206.124.146.255 dhcp,routefilter,logmartians,blacklist,tcpflags,nosmurfs
loc     $INT_IF         192.168.1.255   dhcp
dmz     $DMZ_IF         -
vpn     tun+            -
Wifi    $WIFI_IF        -               maclist,dhcp
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

/etc/shorewall/maclist:

#DISPOSITION            INTERFACE               MAC                     IP ADDRESSES (Optional)
ACCEPT                  $WIFI_IF                00:04:5e:3f:85:b9                       #WAP11
ACCEPT                  $WIFI_IF                00:06:25:95:33:3c                       #WET11
ACCEPT                  $WIFI_IF                00:0b:4d:53:cc:97       192.168.3.8     #TIPPER
ACCEPT                  $WIFI_IF                00:1f:79:cd:fe:2e       192.168.3.6     #Work Laptop
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

As shown above, I used MAC Verification on my wireless zone that was served by a Linksys WET11 wireless bridge.

Note

While marketed as a wireless bridge, the WET11 behaves like a wireless router with DHCP relay. When forwarding DHCP traffic, it uses the MAC address of the host (TIPPER) but for other forwarded traffic it uses its own MAC address. Consequently, I listd the IP addresses of both devices in /etc/shorewall/maclist.


Example 2. Router in Wireless Zone

Suppose now that I had added a second wireless segment to my wireless zone and gateway that segment via a router with MAC address 00:06:43:45:C6:15 and IP address 192.168.3.253. Hosts in the second segment have IP addresses in the subnet 192.168.4.0/24. I would have added the following entry to my /etc/shorewall/maclist file:

ACCEPT                  $WIFI_IF                    00:06:43:45:C6:15       192.168.3.253,192.168.4.0/24

This entry would accommodate traffic from the router itself (192.168.3.253) and from the second wireless segment (192.168.4.0/24). Remember that all traffic being sent to my firewall from the 192.168.4.0/24 segment will be forwarded by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15) and not that of the host sending the traffic.


Documentation


Frequently Used Articles

- FAQs - IPv4 Manpages - IPv6 Manpages - Configuration File Basics - Beginner Documentation - Troubleshooting

Shorewall 4.0/4.2 Documentation


Current HOWTOs and Other Articles

- 6to4 and 6in4 Tunnels - Accounting - Actions - Aliased (virtual) Interfaces (e.g., eth0:0) - Anatomy of Shorewall - Anti-Spoofing Measures - AUDIT Target support - Bandwidth Control - Blacklisting/Whitelisting - Bridge/Firewall - Building Shorewall from GIT - Commands - Compiled Programs - Configuration File Basics - DHCP - DNAT - Dynamic Zones - ECN Disabling by host or subnet - Events - Extension Scripts - Fallback/Uninstall - FAQs - Features - Fool's Firewall - Forwarding Traffic on the Same Interface - FTP and Shorewall - Helpers/Helper Modules - Installation/Upgrade - IPP2P - IPSEC - Ipsets - IPv6 Support - ISO 3661 Country Codes - Kazaa Filtering - Kernel Configuration - KVM (Kernel-mode Virtual Machine) - Limiting Connection Rates - Linux Containers (LXC) - Linux-vserver - Logging - Macros - MAC Verification - Manpages (IPv4) (IPv6) - Manual Chains - Masquerading - Multiple Internet Connections from a Single Firewall - Multiple Zones Through One Interface - My Shorewall Configuration - Netfilter Overview - Network Mapping - No firewalling of traffic between bridge port - One-to-one NAT - Operating Shorewall - OpenVPN - OpenVZ - Packet Marking - Packet Processing in a Shorewall-based Firewall - 'Ping' Management - Port Forwarding - Port Information - Port Knocking (deprecated) - Port Knocking, Auto Blacklisting and Other Uses of the 'Recent Match' - PPTP - Proxy ARP - QuickStart Guides - Release Model - Requirements - Routing and Shorewall - Routing on One Interface - Samba - Shorewall Events - Shorewall Init - Shorewall Lite - Shorewall on a Laptop - Shorewall Perl - Shorewall Setup Guide - SMB - SNAT - Split DNS the Easy Way - Squid with Shorewall - Starting/stopping the Firewall - Static (one-to-one) NAT - Support - Tips and Hints - Traffic Shaping/QOS - Simple - Traffic Shaping/QOS - Complex - Transparent Proxy - UPnP - Upgrade Issues - Upgrading to Shorewall 4.4 (Upgrading Debian Lenny to Squeeze) - VPN - VPN Passthrough - White List Creation - Xen - Shorewall in a Bridged Xen DomU - Xen - Shorewall in Routed Xen Dom0

Top of Page