IP and MAC filtering

Oskar Andreasson blueflux@koffein.net
Tue, 9 Oct 2001 10:25:37 +0200

Hash: SHA1

Look below, this was just posted to the list by James Morris.

Have a nice day,

On Tuesday 09 October 2001 09:31, Enrico Pelletta wrote:
> Hi!
> I'm newby in this list, so I apologize you if my problem will be not
> well formulated.
> I'm trying to configure a firewall that filter packets upon their source
> IP and MAC addresses.
> In order to implement such kind of firewall/gateway I'm using a PC
> running RedHat 7.1 linux but with 2.4.9 kernel and iptables-1.2.2. To
> show the iptables configuration I use I write the command I run.
> iptables  -P FORWARD DROP
> iptables -A FORWARD -d -j ACCEPT //the firewall works in
> only one direction
> iptables -A FORWARD -s -m mac --mac-source 00:AA:BB:CC:DD:EE -j
> This configuration looks fine and seems to work fine. Only packets with
> the right IP and MAC address can pass through as  I want. However, I got
> a lot of troubles. What it seems to happen is that not all the right
> packets are correctly forwarded. Small packets are dropped and big IP
> packets, that are fragmented, are not correctly forwared in case one of
> the fragment is smaller than a certain threshold (of course little
> fragments are dropped) . The value of the threshold change with the
> specific ethernet interface you are using! On 100baseTX as Intel Express
> 100 (e100 driver) or 3COM 3c59x I can ping devices behind the firewall
> with a IP packet bigger then 32 bytes (ping -s 4 XXX). My firewall
> should works on  fiber connections, when I used 3Com 1000baseFX (acenic
> driver), the behaviour was the same as for the 100baseTX. When  I used
> an Intel NIC (driver e1000) I got a minimum packet dimension of 45 bytes
> (ping -s 17 XXX). This last case is the worste, you cannot really work!
> Before asking you I looked around to get some tips and I have tried
> different kernel configurations without getting any change. Why the
> small packets are dropped? There is a way to solve this problem? I could
> image problems for the fragmented IP packets, but not for little IP packet.
> Thanks for helping!
>    Enrico.

- ---------- Forwarded message ----------
Date: Mon, 8 Oct 2001 10:50:58 +0100 (BST)
From: Chris Wilson <chris@netservers.co.uk>
To: bugtraq@securityfocus.com
Subject: Bug in Linux 2.4 / iptables MAC match module

     __  _    _  ___
- --[ |  \| |__| |/ _/ __ __ _ _  __ __ __  ]--
- --[ | \ \ /o_| _\_ \/o_| _| | |/o_| _|_ \ ]--
- --[ |_|\__\__|__|__/\__|_| \_/ \__|_|___/ ]--
- --[ netservers security advisory 01-09-26 ]--

SUBJECT  : Bug in Linux 2.4 / iptables MAC match module
SUMMARY  : MAC match module does not match small packets
EFFECTS  : Malicious users may bypass MAC-based DROP rules
           pcAnywhere does not function correctly if allowed by MAC address
SOLUTION : Apply the attached patch from Harald Welte, Netfilter core
           developer, or wait for the next release of the Linux kernel.
CREDITS  : Harald Welte, Erick C. Jones, Netfilter team and users

- -------
The Linux 2.4 kernel includes a new and very powerful firewalling, NAT and
packet mangling architecture called Netfilter. The main component of
Netfilter is iptables, a generic structure for allowing firewall rules to
perform NAT, mangle packets, and access custom extensions for packet
matching and mangling.

One of the extensions supplied by default is the MAC module, which matches
packets travelling through the firewall on the basis of their MAC
(ethernet hardware) address. This module offers administrators some
protection against malicious internal (or directly connected) users who
spoof or change their IP address.

The MAC module does not correctly match very small packets. For example,
small ping packets can be generated by the Unix command 'ping somehost -s 4',
or similarly under Windows with 'ping somehost -l 4'. Netcat with the -u
option can generate small UDP packets which exhibit the same problem.

- ------------
To reproduce the problem, you will need 2 machines:

- - Victim, which runs iptables.
- - Attacker, which can generate small ICMP or UDP packets.

We have used the DNS names 'Victim' and 'Attacker' to represent the IP
addresses of these machines, and AT:TA:CK:ER:00:00 as the MAC address of
the attacker. Please substitute real values if attempting to reproduce
this problem.

On Victim, at a root prompt:

  victim# iptables -P INPUT ACCEPT
  victim# iptables -F INPUT
  victim# iptables -I INPUT -p icmp -m mac --mac-source AT:TA:CK:ER:00:00
    -j DROP
  victim# iptables -L INPUT -v
  Chain INPUT (policy ACCEPT xxxx packets, xxxxxxx bytes)
   pkts bytes target     prot opt in     out     source               
      0     0 DROP       icmp --  any    any     anywhere             anywhere
       MAC AT:TA:CK:ER:00:00

  [note that the packet and byte counters are zero]

On Attacker (assuming Attacker runs Linux or similar)

  attacker# ping -s 8 -c 1 Victim
  PING Victim (xx.xx.xx.xx) from xx.xx.xx.xx : 8(36) bytes of data.

  --- xx.xx.xx.xx ping statistics ---
  1 packets transmitted, 0 packets received, 100% packet loss

  [the ping packets were dropped, correctly]

On Victim again:

  victim# iptables -L INPUT -v
  Chain INPUT (policy ACCEPT 231 packets, 39475 bytes)
   pkts bytes target     prot opt in     out     source               
      1    36 DROP       icmp --  any    any     anywhere             anywhere
       MAC 00:03:47:87:BA:C5

  [note that the packet and byte counters have increased, the packet
   counter is showing 1 packet which is correct]

Now back to Attacker:

  attacker# ping -s 4 -c 1 Victim
  PING Victim (xx.xx.xx.xx) from xx.xx.xx.xx : 4(32) bytes of data.
  12 bytes from xx.xx.xx.xx: icmp_seq=0 ttl=255

  --- xx.xx.xx.xx ping statistics ---
  1 packets transmitted, 1 packets received, 0% packet loss

  [note that this time, the ping packet was replied to, not dropped by the

And finally, back to Victim:

  victim# iptables -L INPUT -v
  Chain INPUT (policy ACCEPT 231 packets, 39475 bytes)
   pkts bytes target     prot opt in     out     source               
      1    32 DROP       icmp --  any    any     anywhere             anywhere
       MAC AT:TA:CK:ER:00:00

  [note that the packet counters have not increased, the packet did not
   match the drop rule]

- ------------
- From a security point of view:
- - Malicious internal users may evade restrictions placed on their MAC
  address in some cases. For example, they might ping internal or external
  hosts to determine whether they are running, even though firewall rules
  disallow this.
- - They may also use small ICMP or UDP packets to leak information through
  the firewall, if no other rule prevents them from doing so.
- - Several applications use small ICMP or UDP packets, for example ping,
  netcat, and Symantec pcAnywhere. Administrators will not be able to
  restrict the use of these programs to certain known MAC addresses,
  because of this bug. This may result in lower overall security
  (especially as we know no complete workaround as yet).

- --------
Harald Welte, Netfilter core developer, has released a patch which we have
verified to have fixed the problem in our case. The patch is very small
and can be applied by hand (the patch may be wrapped by your mail client,
so I have attached it as well).

- --- linux-2.4.9/net/ipv4/netfilter/ipt_mac.c    Tue Oct  2 18:50:56 2001
+++ linux-2.4.9-ipt_mac-fix/net/ipv4/netfilter/ipt_mac.c        Tue Oct  2
19:32:20 2001
@@ -20,7 +20,7 @@

     /* Is mac pointer valid? */
     return (skb->mac.raw >= skb->head
- -           && skb->mac.raw < skb->head + skb->len - ETH_HLEN
+           && (skb->mac.raw + ETH_HLEN) <= skb->data
            /* If so, compare... */
            && ((memcmp(skb->mac.ethernet->h_source, info->srcaddr, ETH_ALEN)
                == 0) ^ info->invert));

Harald Welte writes:

> the patch has been submitted to David Miller just one minute ago.

- ----------
The simplest, but least secure, workaround is to avoid matching by MAC
address, but only match on IP address. This is common practice, but less
secure than matching by MAC address.

Another workaround is to use the latest version of iptables (1.2.3) from
http://netfilter.samba.org. This includes a modules called "length" which
can be used to match small packets. Some administrators might like to
allow ICMP and/or UDP packets below a certain size with a command like
this (UNTESTED):

  iptables -I INPUT -p icmp -m length --length 0:4 -j ACCEPT

Note that using such a command will reduce the security of your
iptables-protected hosts.

In any case, a new version of iptables should be available soon which
fixes this bug.

- -------
Although we discovered this bug independently, James Morris of Netfilter
was quick to point out that we were not the first. It appears that the bug
was reported to Netfilter by Erick C Jones on 01/08/29. However, neither
netfilter nor the Linux kernel was patched at this point.

- - http://lists.samba.org/pipermail/netfilter-devel/2001-August/002050.html
- - http://lists.samba.org/pipermail/netfilter-devel/2001-September/002278.html
- - http://lists.samba.org/pipermail/netfilter-devel/2001-September/002283.html

We would like to thank:
- - The Netfilter team, both core and non-core, and Netfilter users for
  developing and testing this excellent packet filter system;
- - Harald Welte from Netfilter for his quick development of a patch and his
  generally friendly nature;
- - My boss, John McEleney, for discovering the bug.

- --------
This advisory is RFpolicy compliant
(http://www.wiretrip.net/rfp/policy.html). The bug was acknowledged by the
Netfilter team within 5 days and quickly fixed. Thanks guys! Yet again
open source beats closed source for rapid response.

- ---------
This advisory is copyright (C) 2001 Netservers.co.uk. Redistribution is
permitted provided the contents and text of the advisory are not modified
in any way.

This advisory has been modified and updated since its original
distribution to the netfilter users list on 01/09/25.

Ciao, Chris.
- -- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |

- -- 
|Oskar Andreasson                   |
|Multisoft Education AB             |
|http://www.libendo.com             |
|phone: +46-8-6635555               |
|mailto: o.andreasson@libendo.com   |
BOFH excuse #185:

system consumed all the paper for paging
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org