DHCP server was getting continuous requests from a client {EBtables}

I've had the following issue today:

while I was looking at logs of the dns/dhcp server it was being flooded by the frequent dhcp request from a client therefore we decided to block the requests using ebtables which are similar to iptables but works on layer 2 and can block all traffic from a mac address. So installed and configured ebtables { ebtables only works on bridges it doesn't work on ethernet interfaces but a bridge can be created which consists of single ethernet interface } then that blocked the mac address of the client which was flooding dhcp server with frequent requests. Big Boss also suggested that it can be done via switches as well and these will be generally caused either by apple MAC's or a Virtual servers such as vmware esx which are not bound properly.

I've used the following example from :::

http://ebtables.sourceforge.net/examples/real.html#all


the example from that site is:

This setup and description was given by Ashok Aiyar. The original website where he posted this setup is no longer available but the website is archived here. The contents were edited to bring the original text, which dates from the Linux 2.4 days, up-to-date.

Why filter AppleTalk?

There are many situations where it is appropriate to filter AppleTalk. Here's one of them. We tunnel/route AppleTalk between five networks using netatalk. There are very similarly named Tektronix Phaser printers in two of these networks, and often print jobs intended for one are unintentionally sent to the other. We would prefer for each of these Phasers to be visible only in the network in which it is located, and not in all five networks. Unlike CAP, netatalk does not support filtering. Therefore, on this page I describe one method to add external filters to netatalk, on the basis of the MAC address associated with an AppleTalk object or node.

There are pros and cons to filtering on the basis of MAC addresses. They have the advantage of being more robust because AppleTalk node numbers can change with every reboot, while the MAC address will not. They have the disadvantage of not being fine-grained; MAC-based filtering will block all the services associated with the filtered AppleTalk node. In general, AppleTalk nodes in our networks are associated with a single service.

Iptables versus Ebtables

The Linux netfilter code supports filtering of IPV4, IPV6 and DECnet packets on the basis of MAC addresses. However such filters do not apply to any other type of ethernet frame. So, an iptables rule such as:

iptables -I INPUT -m mac --mac-source TE:KP:HA:SE:R8:60 -j DROP

results in only IPV4, IPV6 and DECnet packets from that source address being dropped. More to the point, DDP and AARP packets from the same source address are not dropped. Ebtables appeared to be perfectly suited to filter Ethernet frames on the basis of MAC address as well as ethernet protocol type. However, it only supports bridge interfaces, and not regular Ethernet interfaces. Bart De Schuymer, the author of ebtables brought to my attention that a Linux bridge interface can have just a single Ethernet interface. Thanks to Bart's generous advice, a working Ethernet filtering setup is described below.

Setting up Ebtables

To setup a bridge with a single interface, first create the bridge interface (br0). Then add the relevant ethernet interface to the bridge. Finally, assign to the bridge the IP address previously assigned to the ethernet interface. The commands to do this are detailed below:

brctl addbr br0             # create bridge interface
brctl stp br0 off           # disable spanning tree protocol on br0
brctl addif br0 eth0        # add eth0 to br0
ifconfig br0 aaa.bbb.ccc.ddd netmask 255.255.255.0 broadcast aaa.bbb.ccc.255
ifconfig eth0 0.0.0.0
route add -net aaa.bbb.ccc.0 netmask 255.255.255.0 br0
route add default gw aaa.bbb.ccc.1 netmask 0.0.0.0 metric 1 br0

Now network traffic will be routed through the br0 interface rather than the underlying eth0. Atalkd can be started to route AppleTalk between br0 and any other desired interfaces. Note that atalkd.conf has to be modified so that the reference to eth0 is replaced with br0. For example, the atalkd.conf for PC1 shown on my AppleTalk tunneling page is modified to:

br0  -seed -phase 2 -net 2253  -addr 2253.102  -zone "Microbio-Immun"
tap0 -seed -phase 2 -net 60000 -addr 60000.253 -zone "Microbio-Immun"
tap1 -seed -phase 2 -net 60001 -addr 60001.253 -zone "Microbio-Immun"
tap2 -seed -phase 2 -net 60002 -addr 60002.253 -zone "Microbio-Immun"
tap3 -seed -phase 2 -net 60003 -addr 60003.253 -zone "Microbio-Immun"

Verify that AppleTalk routing is working, and then proceed to set up Ethernet filters using ebtables. For this the MAC addresses of the AppleTalk nodes that are not to be routed must be known. One simple method of discovering the MAC address is to send the AppleTalk object a few aecho packets, and then read the MAC address from /proc/net/aarp. A sample ebtables filter is shown below:

ebtables -P INPUT ACCEPT
ebtables -P FORWARD ACCEPT
ebtables -P OUTPUT ACCEPT
ebtables -A INPUT -p LENGTH -s TE:KP:HA:SE:R8:60 -j DROP

Currently, ebtables doesn't support filtering of 802.2 and 802.3 packets such as the DDP and AARP packets used by AppleTalk. However all such packets can be dropped on the basis of the length field – if I understand Bart de Schuymer's explanation correctly. Therefore in the example above, all ethernet 802.2, 802.3 packets from the node with the MAC address TE:KP:HA:SE:R8:60 are dropped. This includes AppleTalk packets, but not IPV4, and ARP packets. This node is left visible in the network in which it is located, but not in any networks to which AppleTalk is routed.

Acknowledgements, Final Comments and Useful Links:

Bart de Schuymer's advice and patient explanations are greatly appreciated. In my experience atalkd bound to the br0 interface is as stable as atalkd bound to the eth0 interface. In addition the MAC address based filters described here work well for their intended purpose. While this works, there is a performance penalty associated with receiving all IP traffic through br0 and not eth0. This is because traffic destined for the bridge is queued twice (once more than normal) – that's a lot of overhead. The ebtablesbroute table can be used to circumvent this and directly route the traffic entering the bridge port. This way it will be queued only once, eliminating the performance penalty. In the example above:

brctl addbr br0
brctl stp br0 off
brctl addif br0 eth0
ifconfig br0 0.0.0.0
ifconfig eth0 a.b.c.d netmask 255.255.255.0 broadcast a.b.c.255

The following two ebtables BROUTE table rules should be used:

ebtables -t broute -A BROUTING -p IPv4 -i eth0 --ip-dst a.b.c.d -j DROP
ebtables -t broute -A BROUTING -p ARP -i eth0 -d MAC_of_eth0 -j DROP

Atalkd should still be bound to br0, thus allowing AppleTalk to be filtered by ebtables. As best as I can tell this configuration eliminates the performance penalty on IP traffic throughput. Because we tunnel AppleTalk through IP, this configuration removes any throughput penalties in using a bridge interface and ebtables to route AppleTalk.