Blocking DHCP with ebtables

Blocking DHCP with ebtables

[Eddie]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

I have a network bridging two offices using OpenVPN. I am running a DHCP 
server on both sides so if the tunnel goes down, both sides will still 
have internet access. (Both sides run Slack/Shorewall/OpenVPN)

I have the obvious problem with stopping DHCP packets from crossing the 
bridge. I use the below ebtables example, but something is wrong. Under 
testing, it appeared to work, but I  under deployment, am seeing windows 
host on the main office side getting dual gateways, and/or the dns 
server from the remote side. It's really strange stuff.

Here is the ebtables rules I use on the remote side only. I am not sure 
if I need anything on the main side since I figure if this blocks all 
dhcp traffic across the bridge, then all should be good.


# Clear ebtables
ebtables -F
ebtables -X

# Drop everything and build up Input and Output to accept IP and ARP
ebtables -P FORWARD DROP
ebtables -P INPUT DROP
ebtables -P OUTPUT DROP
ebtables -A INPUT -p IPv4 -j ACCEPT
ebtables -A INPUT -p ARP -j ACCEPT
ebtables -A INPUT --log-level info --log-ip --log-prefix EBFW
ebtables -A OUTPUT -p IPv4 -j ACCEPT
ebtables -A OUTPUT -p ARP -j ACCEPT
ebtables -A OUTPUT --log-level info --log-ip --log-arp --log-prefix EBFW 
-j DROP

#drop DHCP broadcast
ebtables -A FORWARD -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 
--ip-prot udp --ip-dport 67:68 --log-level info --log-ip --log-prefix 
EBFWbc -j DROP
ebtables -A FORWARD -p ipv4 --ip-proto tcp --ip-destination-port 67:68 
--log-level info --log-ip --log-prefix EBFWtcp -j DROP
ebtables -A FORWARD -p ipv4 --ip-proto udp --ip-destination-port 67:68 
--log-level info --log-ip --log-prefix EBFWudp -j DROP


# Let the rest of the Packets through
ebtables -A FORWARD -p IPv4 -j ACCEPT
ebtables -A FORWARD -p ARP -j ACCEPT


But this is what I see in the logfile on the remote side..

Sep 12 19:05:09 firewall kernel: EBFWbc IN=tap0 OUT=eth1 MAC source = 
00:10:dc:e3:2e:64 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP 
SRC=192.168.8.22 IP DST=255.255.255.255, IP tos=0x00, IP proto=17 SPT=68 
DPT=67
Sep 12 19:05:09 firewall dhcpd: DHCPINFORM from 192.168.8.22 via br0
Sep 12 19:05:09 firewall dhcpd: DHCPACK to 192.168.8.22 
(00:10:dc:e3:2e:64) via br0

Sep 12 19:14:37 firewall kernel: EBFWbc IN=tap0 OUT=eth1 MAC source = 
00:13:72:2b:37:47 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP 
SRC=192.168.8.24 IP DST=255.255.255.255, IP tos=0x00, IP proto=17 SPT=68 
DPT=67
Sep 12 19:14:37 firewall dhcpd: DHCPREQUEST for 192.168.8.60 from 
00:13:72:2b:37:47 (ws02) via br0
Sep 12 19:14:37 firewall dhcpd: DHCPACK on 192.168.8.60 to 
00:13:72:2b:37:47 (ws02) via br0

ebtables seems to want to block the packets, but dhcpd gets them anyway 
and responds.  Note that on both sides of the connection have dhcpd 
running on br0, on with different ranges. (both eth1 and tap0 are 
bridged to br0)

So why are the packets not blocked from dhcpd? What am I missing?
Thanks for any help.





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: Blocking DHCP with ebtables

[Pascal Hambourg]

Hello,

Eddie a écrit :
[...]
> # Drop everything and build up Input and Output to accept IP and ARP
> ebtables -P FORWARD DROP
> ebtables -P INPUT DROP
> ebtables -P OUTPUT DROP
> ebtables -A INPUT -p IPv4 -j ACCEPT
> ebtables -A INPUT -p ARP -j ACCEPT
> ebtables -A INPUT --log-level info --log-ip --log-prefix EBFW
> ebtables -A OUTPUT -p IPv4 -j ACCEPT
> ebtables -A OUTPUT -p ARP -j ACCEPT
> ebtables -A OUTPUT --log-level info --log-ip --log-arp --log-prefix EBFW 
> -j DROP

Why log IP and ARP info after accepting IP and ARP packets ? Obviously,
only non-(IP or ARP) packets would reach the log rules, so there is no
IP or ARP information to log.

> #drop DHCP broadcast
> ebtables -A FORWARD -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 
> --ip-prot udp --ip-dport 67:68 --log-level info --log-ip --log-prefix 
> EBFWbc -j DROP

What is this rule for ? The second rule below already matches all DHCP
traffic.

> ebtables -A FORWARD -p ipv4 --ip-proto tcp --ip-destination-port 67:68 
> --log-level info --log-ip --log-prefix EBFWtcp -j DROP

What is this rule for ? DHCP uses only UDP, not TCP.

> ebtables -A FORWARD -p ipv4 --ip-proto udp --ip-destination-port 67:68 
> --log-level info --log-ip --log-prefix EBFWudp -j DROP

[...]
> Sep 12 19:05:09 firewall kernel: EBFWbc IN=tap0 OUT=eth1 MAC source = 
> 00:10:dc:e3:2e:64 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP 
> SRC=192.168.8.22 IP DST=255.255.255.255, IP tos=0x00, IP proto=17 SPT=68 
> DPT=67
> Sep 12 19:05:09 firewall dhcpd: DHCPINFORM from 192.168.8.22 via br0
[...]
> ebtables seems to want to block the packets, but dhcpd gets them anyway 
> and responds.  Note that on both sides of the connection have dhcpd 
> running on br0, on with different ranges. (both eth1 and tap0 are 
> bridged to br0)

As in iptables, the FORWARD chain sees only bridged packets. Packets
received by the local host go through the INPUT chain, and
locally-generated packets go through the OUTPUT table.

The broadcast DHCP request is both bridged through the FORWARD chain and
received locally through the INPUT chain. Your ruleset drops only the
copy in the FORWARD chain, not the one in the INPUT chain which is
received by the local dhcpd. The locally-generated DHCP reply is sent
through the OUTPUT chain and is not dropped either.

Bottom line : you must drop DHCP traffic on the TAP interface in the
INPUT and OUTPUT chains too. Or drop it on the "main side".