Mailing List Archive

Hi!

On Wed, 22 Mar 2006, Martin Skarda wrote:
> I'm trying to protect my dhcp server with some rules within iptables
> against some DoS, and I see all the "hopefully dropped" packages in my log
> target. But the drop doesn't really work: the packages are still going
> through my firewall to my dhcp server.
>
> Here is my simple ruleset:
>
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source destination
> 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
> 0 0 MSK_DHCP udp -- * * 0.0.0.0/0 0.0.0.0/0
> udp dpt:67
>
>
> Chain MSK_DHCP (1 references)
> pkts bytes target prot opt in out source destination
> 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
> LOG flags 0 level 6 prefix '**DHCP-Flood**'
> 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
>
>
> All my default policies are set to drop.

Your description tells me that your packetfilter is not on the
same host as your DHCP server.

Assuming your DHCP server is seperate, I'd suggest putting your
DHCP rules into the FORWARD chain. Back with ipvsadm (and
ipchains, too, IIRC), routed packets traversed the INPUT and
OUTPUT chains. With Netfilter, that isn't the case anymore.

If, however your network setup is entirely different, we'd need
to know that before doing more guessing.

Regards & HTH,
Tobias

--
You don't need eyes to see, you need vision.
--
gentoo-security@gentoo.org mailing list

Hi,

On Wed, 22 Mar 2006, Tobias Klausmann wrote:

>
> Your description tells me that your packetfilter is not on the
> same host as your DHCP server.

Sorry if I did not describe the installation correctly.

The DHCP server is on the same box which I try to protect with iptables.
The packets could not traverse the forward chain, because all my default
policies are set to drop and forwarding generally is disabled. Even all
packet counters on the forward chain will stay to zero when I'm sending
some udp packets with a simple hping. There is no bridging, routing, NAT
or something else defined on my box, insomuch the packets could not run
eg. into the prerouting chain or jump into another target. The only rules
in my iptables are shown below.

In the following output you see exactly the seven packets I sent are
matched by the MSK_DHCP target within the INPUT chain:

**snip**
persil ~ # iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
7 196 MSK_DHCP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:67

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain MSK_DHCP (1 references)
pkts bytes target prot opt in out source
destination
7 196 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix '**DHCP-Flood**:'
7 196 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

persil ~ # tail -f /var/log/messages

Mar 23 14:22:24 persil dhcpd: ip length 28 disagrees with bytes received 46.
Mar 23 14:22:24 persil dhcpd: accepting packet with data after udp payload.
Mar 23 14:22:25 persil **DHCP-Flood** :IN=eth0 OUT= MAC=00:11:2f:9e:a8:25:00:0d:61:45:4a:1e:08:00 SRC=192.168.9.22
DST=192.168.9.213 LEN=28 TOS=0x00 PREC=0x00 TTL=64 ID=60607 PROTO=UDP SPT=68 DPT=67 LEN=8

Mar 23 14:22:25 persil dhcpd: ip length 28 disagrees with bytes received 46.
Mar 23 14:22:25 persil dhcpd: accepting packet with data after udp payload.
Mar 23 14:22:26 persil **DHCP-Flood** :IN=eth0 OUT= MAC=00:11:2f:9e:a8:25:00:0d:61:45:4a:1e:08:00 SRC=192.168.9.22
DST=192.168.9.213 LEN=28 TOS=0x00 PREC=0x00 TTL=64 ID=57557 PROTO=UDP SPT=68 DPT=67 LEN=8

**snap**

here is my hping from the _external_ host:
**snip**
msk ~ # hping -s 68 -p 67 --keep --udp 192.168.9.213
HPING 192.168.9.213 (eth0 192.168.9.213): udp mode set, 28 headers + 0
data bytes

--- 192.168.9.213 hping statistic ---
7 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
***snap**


I would be much obliged if you could point out my mistake,

kindly Martin
--
gentoo-security@gentoo.org mailing list

Hi,

On Thu, 23 Mar 2006 15:10:31 +0100 (CET) Martin Skarda
<skarda@uni-freiburg.de> wrote:

> > Your description tells me that your packetfilter is not on the
> > same host as your DHCP server.
>
> Sorry if I did not describe the installation correctly.

You did. But it doesn't matter much, because the problem is that the
dhcpd brings its own set of IP operations (yuck!) and handles
interfaces in packet mode. So you probably have to go to ethernet level
in order to effectively manage that... Googling showed up this in
Shorewall's DHCP how-to:

---snip
Note

For most operations, DHCP software interfaces to the Linux IP stack at
a level below Netfilter. Hence, Netfilter (and therefore Shorewall)
cannot be used effectively to police DHCP. The “dhcp” interface option
described in this article allows for Netfilter to stay out of DHCP's
way for those operations that can be controlled by Netfilter and
prevents unwanted logging of DHCP-related traffic by
Shorewall-generated Netfilter logging rules.
---snip

So shorewall basically only offers the option to keep out of dhcpd's
way completely.

Maybe you can reach your goal by setting up a filtering bridge to a
dummy device on which dhcpd can listen. Or you just rely on QoS/Traffic
shaping, if that's possible...


-hwh
--
gentoo-security@gentoo.org mailing list

On Thu, 23 Mar 2006, Hans-Werner Hilse wrote:

> Hi,
>
> On Thu, 23 Mar 2006 15:10:31 +0100 (CET) Martin Skarda
> <skarda@uni-freiburg.de> wrote:
>
>>> Your description tells me that your packetfilter is not on the
>>> same host as your DHCP server.
>>
>> Sorry if I did not describe the installation correctly.
>
> You did. But it doesn't matter much, because the problem is that the
> dhcpd brings its own set of IP operations (yuck!) and handles
> interfaces in packet mode. So you probably have to go to ethernet level
> in order to effectively manage that... Googling showed up this in
> Shorewall's DHCP how-to:
>
> ---snip
> Note
>
> For most operations, DHCP software interfaces to the Linux IP stack at
> a level below Netfilter. Hence, Netfilter (and therefore Shorewall)
> cannot be used effectively to police DHCP. The ÿÿdhcpÿÿ interface option
> described in this article allows for Netfilter to stay out of DHCP's
> way for those operations that can be controlled by Netfilter and
> prevents unwanted logging of DHCP-related traffic by
> Shorewall-generated Netfilter logging rules.
> ---snip
>
> So shorewall basically only offers the option to keep out of dhcpd's
> way completely.
>
> Maybe you can reach your goal by setting up a filtering bridge to a
> dummy device on which dhcpd can listen. Or you just rely on QoS/Traffic
> shaping, if that's possible...


yes, meanwhile I also found the shorewall howto. I assumed, that the dhcpd
does not use the normal stack. But I did not understand this behavior,
because when I look into the RFC regarding bootp/dhcp I found that this
service is "defined to use the udp protocol"....

thank you for your assistance,
Martin

> yes, meanwhile I also found the shorewall howto. I assumed, that the dhcpd
> does not use the normal stack. But I did not understand this behavior,
> because when I look into the RFC regarding bootp/dhcp I found that this
> service is "defined to use the udp protocol"....
>
> thank you for your assistance,
> Martin
>


You should be able to block this traffic at the Ethernet level using
ebtables with something like this:

ebtables [-t filter] -A INPUT -i eth0 -p ipv4 --ip-protocol 17
--ip-destination-port 67 -j DROP

This drops incoming ethernet traffic to eth0 with an IPv4 protocol of
17 (UDP) destined for IP port 67.

--
gentoo-security@gentoo.org mailing list

Dne sreda, 22. marec 2006 17:32 je Martin Skarda napisal(a):
| Hi All,
|
| I'm trying to protect my dhcp server with some rules within iptables
| against some DoS, and I see all the "hopefully dropped" packages in my log
| target. But the drop doesn't really work: the packages are still going
| through my firewall to my dhcp server.
|
| [...]

While trying out LTSP I observed very similar behaviour (X-Terminals were
getting their IPs through iptables even though they shouldn't) I Googled out
this thread:

http://lists.netfilter.org/pipermail/netfilter/2002-May/034302.html

which gave me my answer to why this is so... In short, here is a quote:

"Derrik Pates touched on this earlier in the thread, but I'll try and
clarify a bit.

The DNCP server of the ISC (Internet Software Consortium,
http://www.isc.org) uses a different type of network access in Linux,
so to speak. Normally, when programs need network access, they open
up an Internet socket of the correct protocol (TCP/UDP), which gets
any packets destined for it and can send packets after the kernel has
applied all IP Tables rules to them. So if you have a policy of
DROP/REJECT or you have a rule that matches a packet to.from this
socket that DROP/REJECTs it, the socket will not receive or be able to
send that packet.

However, the ISC DHCP server uses an Internet Socket of protocol Raw
instead of TCP or UDP. This facility, naturally, is only available to
root (uid 0, really), and receives packets before the IP Tables
processing. It also receives all Internet packet headers as well, so
it gets to do additional processing.

But because Raw sockets get packets before the IP Tables processing,
the ISC DHCP server is able to obtain an IP address through DHCP.

More information (possibly not in a useful state) can be found in the
man pages for socket, ip, tcp, udp,
http://nodevice.com/sections/ManIndex/man1275.html, and, of course,
the source code."

Cheers,
Ziga B.
--
gentoo-security@gentoo.org mailing list

On Thu, 23 Mar 2006, Matt Drew wrote:

> You should be able to block this traffic at the Ethernet level using
> ebtables with something like this:
>
> ebtables [-t filter] -A INPUT -i eth0 -p ipv4 --ip-protocol 17
> --ip-destination-port 67 -j DROP
>
> This drops incoming ethernet traffic to eth0 with an IPv4 protocol of
> 17 (UDP) destined for IP port 67.
>

thanks for that juicy idea :-)

rgds,
Martin
--
gentoo-security@gentoo.org mailing list