source-mac filtering

source-mac filtering

[Håkan Engblom]

Hi,

I've run in to a strange problem. I have a dhcp-server on a 2.4.22 kernel 
with a 1.2.8 iptables. The dhcp-server is configured only to offer 
IP-addresses to one single mac-address (it is a single host on a private 
network)

However I'd like to block all other mac-addresses on this interface since I 
plan to have a W-LAN here as well. (to prevent attackers from using 
potential exploits in the dhcp-server)

The mac-filter works fine for http, telnet, ssh aso, I can see the 
drop-counter increasing and no traffic is let through (when I change the 
mac-address in the iptables-config to something else than what I have on my 
"dhcp-client-host"). BUT the dhcp-server keeps sending offers and ack's 
evethough the incoming discover/request is blocked by iptables.

What makes this even more strange is that the "DROP-counters" when using 
"iptables -L -v" increases, and at the same time the dhcp server responds to 
the requests.

I'm using Internet Software Consortium DHCP Server V3.0.1rc11

The machine has only one physical interface whith two IP's one private and 
one for public. The IP-address offered by the dhcp-server is private (as 
seen below)

Does anyone have a clue ?

br Håkan Engblom

Some "logs" :

00:30:88:00:63:10 is my DSL-connection (having to accepted packets during 
this test)

X.X.X.X is my public IP.

(This is not the complete iptables, but it is teh interesting part for this 
matter)

00:08:29.540872      0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - 
Transaction ID 0xae749e48
00:08:29.541303 X.X.X.X -> 10.0.0.217   DHCP DHCP Offer    - Transaction ID 
0xae749e48
00:08:29.542117      0.0.0.0 -> 255.255.255.255 DHCP DHCP Request  - 
Transaction ID 0xae749e48
00:08:29.542299 X.X.X.X -> 10.0.0.217   DHCP DHCP ACK      - Transaction ID 
0xae749e48



# date
Sun Jan 11 00:08:08 CET 2004
# iptables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               
destination
    0     0 mactable   all  --  eth0   any     anywhere             anywhere
    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
    0     0 DROP      !icmp --  any    any     anywhere             anywhere 
           state INVALID
    0     0 eth0_in    all  --  eth0   any    !10.0.0.0/24          anywhere
    0     0 eth0_1_in  all  --  eth0   any     anywhere             anywhere
    0     0 common     all  --  any    any     anywhere             anywhere

Chain mactable (2 references)
pkts bytes target     prot opt in     out     source               
destination
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere 
           MAC 01:01:01:01:01:01
    0     0 RETURN     all  --  any    any     anywhere             anywhere 
           MAC 00:30:88:00:63:10
    0     0 RETURN     all  --  any    any     anywhere             anywhere 
           MAC 00:90:D0:AF:A3:F1
    0     0 LOG        all  --  any    any     anywhere             anywhere 
           LOG level info prefix `Shorewall:mac:DROP:'
    0     0 DROP       all  --  any    any     anywhere             anywhere

# date
Sun Jan 11 00:08:36 CET 2004
# iptables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               
destination
    4   948 mactable   all  --  eth0   any     anywhere             anywhere
    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
    0     0 DROP      !icmp --  any    any     anywhere             anywhere 
           state INVALID
    2   288 eth0_in    all  --  eth0   any    !10.0.0.0/24          anywhere
    0     0 eth0_1_in  all  --  eth0   any     anywhere             anywhere
    0     0 common     all  --  any    any     anywhere             anywhere

Chain mactable (2 references)
pkts bytes target     prot opt in     out     source               
destination
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere 
           MAC 01:01:01:01:01:01
    2   288 RETURN     all  --  any    any     anywhere             anywhere 
           MAC 00:30:88:00:63:10
    0     0 RETURN     all  --  any    any     anywhere             anywhere 
           MAC 00:90:D0:AF:A3:F1
    2   660 LOG        all  --  any    any     anywhere             anywhere 
           LOG level info prefix `Shorewall:mac:DROP:'
    2   660 DROP       all  --  any    any     anywhere             anywhere
#

_________________________________________________________________
Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/

Re: source-mac filtering

[Antony Stone]

On Saturday 10 January 2004 11:20 pm, Håkan Engblom wrote:

> Hi,
>
> I've run in to a strange problem. I have a dhcp-server on a 2.4.22 kernel
> with a 1.2.8 iptables. The dhcp-server is configured only to offer
> IP-addresses to one single mac-address (it is a single host on a private
> network)
>
> However I'd like to block all other mac-addresses on this interface since I
> plan to have a W-LAN here as well. (to prevent attackers from using
> potential exploits in the dhcp-server)
>
> The mac-filter works fine for http, telnet, ssh aso, I can see the
> drop-counter increasing and no traffic is let through (when I change the
> mac-address in the iptables-config to something else than what I have on my
> "dhcp-client-host"). BUT the dhcp-server keeps sending offers and ack's
> evethough the incoming discover/request is blocked by iptables.

DHCP operates at a rather "lower level" than normal TCP/IP services - as it 
must do, if you think about the fact that the clients involved in the 
communications do not have IP addresses until the protocol is complete.

Therefore you find that the DHCP server binds itself to the networking stack 
rather lower down than netfilter / iptables (which is IP-based, after all, 
and therefore doesn't see traffic which communicates purely between ethernet 
addresses), and you cannot block (or log) DHCP activity using netfilter.

I can think of two choices for doing what you want:

1. Configure the DHCP server to respond only to selected MAC address/es.

2. Use ebtables to manage the ethernet layer in the way you are trying to use 
iptables at present.

Regards,

Antony.

-- 
Perfection in design is achieved not when there is nothing left to add, but 
rather when there is nothing left to take away.

 - Antoine de Saint-Exupery

                                                     Please reply to the list;
                                                           please don't CC me.

Re: source-mac filtering

[Pawel Staszewski]

Hello

Maybe try to block broadcast to the "blocked" client....
"-m pkttype --pkttype broadcast ........."

I use it and this work fine...

----- Original Message ----- 
From: "Håkan Engblom" <cynic_0@hotmail.com>
To: <netfilter@lists.netfilter.org>
Sent: Sunday, January 11, 2004 12:20 AM
Subject: source-mac filtering


> Hi,
>
> I've run in to a strange problem. I have a dhcp-server on a 2.4.22 kernel
> with a 1.2.8 iptables. The dhcp-server is configured only to offer
> IP-addresses to one single mac-address (it is a single host on a private
> network)
>
> However I'd like to block all other mac-addresses on this interface since
I
> plan to have a W-LAN here as well. (to prevent attackers from using
> potential exploits in the dhcp-server)
>
> The mac-filter works fine for http, telnet, ssh aso, I can see the
> drop-counter increasing and no traffic is let through (when I change the
> mac-address in the iptables-config to something else than what I have on
my
> "dhcp-client-host"). BUT the dhcp-server keeps sending offers and ack's
> evethough the incoming discover/request is blocked by iptables.
>
> What makes this even more strange is that the "DROP-counters" when using
> "iptables -L -v" increases, and at the same time the dhcp server responds
to
> the requests.
>
> I'm using Internet Software Consortium DHCP Server V3.0.1rc11
>
> The machine has only one physical interface whith two IP's one private and
> one for public. The IP-address offered by the dhcp-server is private (as
> seen below)
>
> Does anyone have a clue ?
>
> br Håkan Engblom
>
> Some "logs" :
>
> 00:30:88:00:63:10 is my DSL-connection (having to accepted packets during
> this test)
>
> X.X.X.X is my public IP.
>
> (This is not the complete iptables, but it is teh interesting part for
this
> matter)
>
> 00:08:29.540872      0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover -
> Transaction ID 0xae749e48
> 00:08:29.541303 X.X.X.X -> 10.0.0.217   DHCP DHCP Offer    - Transaction
ID
> 0xae749e48
> 00:08:29.542117      0.0.0.0 -> 255.255.255.255 DHCP DHCP Request  -
> Transaction ID 0xae749e48
> 00:08:29.542299 X.X.X.X -> 10.0.0.217   DHCP DHCP ACK      - Transaction
ID
> 0xae749e48
>
>
>
> # date
> Sun Jan 11 00:08:08 CET 2004
> # iptables -L -v
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source
> destination
>     0     0 mactable   all  --  eth0   any     anywhere
anywhere
>     0     0 ACCEPT     all  --  lo     any     anywhere
anywhere
>     0     0 DROP      !icmp --  any    any     anywhere
anywhere
>            state INVALID
>     0     0 eth0_in    all  --  eth0   any    !10.0.0.0/24
anywhere
>     0     0 eth0_1_in  all  --  eth0   any     anywhere
anywhere
>     0     0 common     all  --  any    any     anywhere
anywhere
>
> Chain mactable (2 references)
> pkts bytes target     prot opt in     out     source
> destination
>     0     0 ACCEPT     all  --  any    any     anywhere
anywhere
>            MAC 01:01:01:01:01:01
>     0     0 RETURN     all  --  any    any     anywhere
anywhere
>            MAC 00:30:88:00:63:10
>     0     0 RETURN     all  --  any    any     anywhere
anywhere
>            MAC 00:90:D0:AF:A3:F1
>     0     0 LOG        all  --  any    any     anywhere
anywhere
>            LOG level info prefix `Shorewall:mac:DROP:'
>     0     0 DROP       all  --  any    any     anywhere
anywhere
>
> # date
> Sun Jan 11 00:08:36 CET 2004
> # iptables -L -v
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source
> destination
>     4   948 mactable   all  --  eth0   any     anywhere
anywhere
>     0     0 ACCEPT     all  --  lo     any     anywhere
anywhere
>     0     0 DROP      !icmp --  any    any     anywhere
anywhere
>            state INVALID
>     2   288 eth0_in    all  --  eth0   any    !10.0.0.0/24
anywhere
>     0     0 eth0_1_in  all  --  eth0   any     anywhere
anywhere
>     0     0 common     all  --  any    any     anywhere
anywhere
>
> Chain mactable (2 references)
> pkts bytes target     prot opt in     out     source
> destination
>     0     0 ACCEPT     all  --  any    any     anywhere
anywhere
>            MAC 01:01:01:01:01:01
>     2   288 RETURN     all  --  any    any     anywhere
anywhere
>            MAC 00:30:88:00:63:10
>     0     0 RETURN     all  --  any    any     anywhere
anywhere
>            MAC 00:90:D0:AF:A3:F1
>     2   660 LOG        all  --  any    any     anywhere
anywhere
>            LOG level info prefix `Shorewall:mac:DROP:'
>     2   660 DROP       all  --  any    any     anywhere
anywhere
> #
>
> _________________________________________________________________
> Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/
>
>
>
>

Re: source-mac filtering

[Antony Stone]

On Sunday 11 January 2004 12:13 am, Pawel Staszewski wrote:

> Hello
>
> Maybe try to block broadcast to the "blocked" client....
> "-m pkttype --pkttype broadcast ........."
>
> I use it and this work fine...

You can use a rule with this match in it to stop your DHCP server giving out 
addresses?

I thought DHCPD caught the packets before they ever got to netfilter, 
therefore you couldn't block the traffic with any sort of rule.

Antony.

-- 
Ramdisk is not an installation procedure.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: source-mac filtering

[Pawel Staszewski]

----- Original Message ----- 
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Sunday, January 11, 2004 1:25 AM
Subject: Re: source-mac filtering


On Sunday 11 January 2004 12:13 am, Pawel Staszewski wrote:

> Hello
>
> Maybe try to block broadcast to the "blocked" client....
> "-m pkttype --pkttype broadcast ........."
>
> I use it and this work fine...

You can use a rule with this match in it to stop your DHCP server giving out
addresses?

I thought DHCPD caught the packets before they ever got to netfilter,
therefore you couldn't block the traffic with any sort of rule.

Antony.

-- 
Ramdisk is not an installation procedure.

                                                     Please reply to the
list;
                                                           please don't CC
me.

Hmm...
iptables -t raw ??
Maybe this helps...

Paol

Re: source-mac filtering

[Unknown, Alistair Tonner]

On January 10, 2004 06:20 pm, Håkan Engblom wrote:
> Hi,
>
> I've run in to a strange problem. I have a dhcp-server on a 2.4.22 kernel
> with a 1.2.8 iptables. The dhcp-server is configured only to offer
> IP-addresses to one single mac-address (it is a single host on a private
> network)
>
>
> Does anyone have a clue ?
>
> br Håkan Engblom
>
> Some "logs" :

	<relevant info snipped, since it has been through the list several times>

	Can I think out loud for a moment???

	have dhcpd listen on a *different* port than normal
	have iptables grab relevant mac address broadcasts and redirect to appropriate port?

	drop anything not in relevant mac address range?

	Perhaps this might work??? 
	anyone care to try?? --my personal net is static ... thankgod its only 5 boxen 
	
	Alistair Tonner

Re: source-mac filtering

[Ramin Dousti]

dhcpd takes and puts packets by netlink sockets which bypass the whole
IP stack. So in short, you cannot filter the requests nor the response.

Ramin

On Sun, Jan 11, 2004 at 12:20:06AM +0100, Håkan Engblom wrote:

> Hi,
> 
> I've run in to a strange problem. I have a dhcp-server on a 2.4.22 kernel 
> with a 1.2.8 iptables. The dhcp-server is configured only to offer 
> IP-addresses to one single mac-address (it is a single host on a private 
> network)
> 
> However I'd like to block all other mac-addresses on this interface since I 
> plan to have a W-LAN here as well. (to prevent attackers from using 
> potential exploits in the dhcp-server)
> 
> The mac-filter works fine for http, telnet, ssh aso, I can see the 
> drop-counter increasing and no traffic is let through (when I change the 
> mac-address in the iptables-config to something else than what I have on my 
> "dhcp-client-host"). BUT the dhcp-server keeps sending offers and ack's 
> evethough the incoming discover/request is blocked by iptables.
> 
> What makes this even more strange is that the "DROP-counters" when using 
> "iptables -L -v" increases, and at the same time the dhcp server responds 
> to the requests.
> 
> I'm using Internet Software Consortium DHCP Server V3.0.1rc11
> 
> The machine has only one physical interface whith two IP's one private and 
> one for public. The IP-address offered by the dhcp-server is private (as 
> seen below)
> 
> Does anyone have a clue ?
> 
> br Håkan Engblom
> 
> Some "logs" :
> 
> 00:30:88:00:63:10 is my DSL-connection (having to accepted packets during 
> this test)
> 
> X.X.X.X is my public IP.
> 
> (This is not the complete iptables, but it is teh interesting part for this 
> matter)
> 
> 00:08:29.540872      0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - 
> Transaction ID 0xae749e48
> 00:08:29.541303 X.X.X.X -> 10.0.0.217   DHCP DHCP Offer    - Transaction ID 
> 0xae749e48
> 00:08:29.542117      0.0.0.0 -> 255.255.255.255 DHCP DHCP Request  - 
> Transaction ID 0xae749e48
> 00:08:29.542299 X.X.X.X -> 10.0.0.217   DHCP DHCP ACK      - Transaction ID 
> 0xae749e48
> 
> 
> 
> # date
> Sun Jan 11 00:08:08 CET 2004
> # iptables -L -v
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source               
> destination
>    0     0 mactable   all  --  eth0   any     anywhere             anywhere
>    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
>    0     0 DROP      !icmp --  any    any     anywhere             anywhere 
>           state INVALID
>    0     0 eth0_in    all  --  eth0   any    !10.0.0.0/24          anywhere
>    0     0 eth0_1_in  all  --  eth0   any     anywhere             anywhere
>    0     0 common     all  --  any    any     anywhere             anywhere
> 
> Chain mactable (2 references)
> pkts bytes target     prot opt in     out     source               
> destination
>    0     0 ACCEPT     all  --  any    any     anywhere             anywhere 
>           MAC 01:01:01:01:01:01
>    0     0 RETURN     all  --  any    any     anywhere             anywhere 
>           MAC 00:30:88:00:63:10
>    0     0 RETURN     all  --  any    any     anywhere             anywhere 
>           MAC 00:90:D0:AF:A3:F1
>    0     0 LOG        all  --  any    any     anywhere             anywhere 
>           LOG level info prefix `Shorewall:mac:DROP:'
>    0     0 DROP       all  --  any    any     anywhere             anywhere
> 
> # date
> Sun Jan 11 00:08:36 CET 2004
> # iptables -L -v
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source               
> destination
>    4   948 mactable   all  --  eth0   any     anywhere             anywhere
>    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
>    0     0 DROP      !icmp --  any    any     anywhere             anywhere 
>           state INVALID
>    2   288 eth0_in    all  --  eth0   any    !10.0.0.0/24          anywhere
>    0     0 eth0_1_in  all  --  eth0   any     anywhere             anywhere
>    0     0 common     all  --  any    any     anywhere             anywhere
> 
> Chain mactable (2 references)
> pkts bytes target     prot opt in     out     source               
> destination
>    0     0 ACCEPT     all  --  any    any     anywhere             anywhere 
>           MAC 01:01:01:01:01:01
>    2   288 RETURN     all  --  any    any     anywhere             anywhere 
>           MAC 00:30:88:00:63:10
>    0     0 RETURN     all  --  any    any     anywhere             anywhere 
>           MAC 00:90:D0:AF:A3:F1
>    2   660 LOG        all  --  any    any     anywhere             anywhere 
>           LOG level info prefix `Shorewall:mac:DROP:'
>    2   660 DROP       all  --  any    any     anywhere             anywhere
> #
> 
> _________________________________________________________________
> Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/
> 

Re: source-mac filtering

[Tarek W.]

On Sun, 2004-01-11 at 18:37, Ramin Dousti wrote:
> dhcpd takes and puts packets by netlink sockets which bypass the whole
> IP stack. So in short, you cannot filter the requests nor the response.
> 
> Ramin
> 
<snippage>

this is slightly off... iirc, some of the negotiation happens that way,
further negotiation does not... what I'm sure of however is that if u
don't explicitely allow dhcpd traffic server-side, negotiation does not
work client-side... which means that not all traffic if any bypasses
netfilter... don't have the time to investigate further server-side...
sorry...

Re: source-mac filtering

[Unknown, Alistair Tonner]

On January 11, 2004 02:05 pm, Tarek W. wrote:
> On Sun, 2004-01-11 at 18:37, Ramin Dousti wrote:
> > dhcpd takes and puts packets by netlink sockets which bypass the whole
> > IP stack. So in short, you cannot filter the requests nor the response.
> >
> > Ramin

	I'll accept that .. but I have a question ... is ARP routing not 
	related?? 
	Are ARP queries not ethernet broadcasts on a similar level to 
	DHCP broadcasts??

	(okay .. thats mighty off topic ..but perhaps its something we can 
	consider network related)

	Alistair

>
> <snippage>
>
> this is slightly off... iirc, some of the negotiation happens that way,
> further negotiation does not... what I'm sure of however is that if u
> don't explicitely allow dhcpd traffic server-side, negotiation does not
> work client-side... which means that not all traffic if any bypasses
> netfilter... don't have the time to investigate further server-side...
> sorry...

Re: source-mac filtering

[Ramin Dousti]

On Mon, Jan 12, 2004 at 01:10:08AM -0500, netfilter-admin@lists.netfilter.org wrote:

> 	I'll accept that .. but I have a question ... is ARP routing not 
> 	related?? 
> 	Are ARP queries not ethernet broadcasts on a similar level to 
> 	DHCP broadcasts??

I don't understand the question.

ARP as in do_arp() is being called by IP stack itself. DHCP broadcasts
are application invoked calls.

Now, can you rephrase the question again?

Ramin

> 
> 	(okay .. thats mighty off topic ..but perhaps its something we can 
> 	consider network related)
> 
> 	Alistair

Re: source-mac filtering

[Håkan Engblom]

Yes I can try that.

However I do managed to get the DHCP-discovery packets dropped (and logged 
as dropped) by a general DROP-rule after having matched on vaild source-mac 
addresses. But even if iptables consider the packets to be dropped, they are 
still forwarded to the dhcpd. This could be seen using "iptables -L -v"

I think it's more likely that the dhcp-server listens on a very low layer.

I'll try it anyway.

/Håkan E.


>From: Antony Stone <Antony@Soft-Solutions.co.uk>
>To: <netfilter@lists.netfilter.org>
>Subject: Re: source-mac filtering
>Date: Sun, 11 Jan 2004 00:25:25 +0000
>
>On Sunday 11 January 2004 12:13 am, Pawel Staszewski wrote:
>
> > Hello
> >
> > Maybe try to block broadcast to the "blocked" client....
> > "-m pkttype --pkttype broadcast ........."
> >
> > I use it and this work fine...
>
>You can use a rule with this match in it to stop your DHCP server giving 
>out
>addresses?
>
>I thought DHCPD caught the packets before they ever got to netfilter,
>therefore you couldn't block the traffic with any sort of rule.
>
>Antony.
>
>--
>Ramdisk is not an installation procedure.
>
>                                                      Please reply to the 
>list;
>                                                            please don't CC 
>me.
>
>

_________________________________________________________________
Hitta rätt köpare på MSN Köp & Sälj http://www.msn.se/koposalj

Re: source-mac filtering

[Håkan Engblom]

I've tried with blocking broadcasts, but the result is the same, iptables 
says the packets are  dropped, and yet the dhcpd is responding.

Could it make any difference with another dhcpd ?

/Håkan E.


>From: Håkan Engblom <cynic_0@hotmail.com>
>To: netfilter@lists.netfilter.org
>Subject: Re: source-mac filtering
>Date: Sun, 11 Jan 2004 01:43:30 +0100
>
>Yes I can try that.
>
>However I do managed to get the DHCP-discovery packets dropped (and logged 
>as dropped) by a general DROP-rule after having matched on vaild source-mac 
>addresses. But even if iptables consider the packets to be dropped, they 
>are still forwarded to the dhcpd. This could be seen using "iptables -L -v"
>
>I think it's more likely that the dhcp-server listens on a very low layer.
>
>I'll try it anyway.
>
>/Håkan E.
>
>
>>From: Antony Stone <Antony@Soft-Solutions.co.uk>
>>To: <netfilter@lists.netfilter.org>
>>Subject: Re: source-mac filtering
>>Date: Sun, 11 Jan 2004 00:25:25 +0000
>>
>>On Sunday 11 January 2004 12:13 am, Pawel Staszewski wrote:
>>
>> > Hello
>> >
>> > Maybe try to block broadcast to the "blocked" client....
>> > "-m pkttype --pkttype broadcast ........."
>> >
>> > I use it and this work fine...
>>
>>You can use a rule with this match in it to stop your DHCP server giving 
>>out
>>addresses?
>>
>>I thought DHCPD caught the packets before they ever got to netfilter,
>>therefore you couldn't block the traffic with any sort of rule.
>>
>>Antony.
>>
>>--
>>Ramdisk is not an installation procedure.
>>
>>                                                      Please reply to the 
>>list;
>>                                                            please don't 
>>CC me.
>>
>>
>
>_________________________________________________________________
>Hitta rätt köpare på MSN Köp & Sälj http://www.msn.se/koposalj
>
>

_________________________________________________________________
Hitta rätt på nätet med MSN Sök http://search.msn.se/

Re: source-mac filtering

[Håkan Engblom]

Hi,

Tried this (REDIRECT to another non-dhcp-standard udp-port) as well now, and 
the test indicates the same thing as before.
Started the dhcp deamon at udp/54356 and redirected everything coming in to 
the machine on upd/67 (normal dhcp) to port 54356.
What happaned was that the dhcp-server did not respond. When using strace 
one could see that there in nothing coming in on the socket.

The redirect-rule seems to work fine, pkts increasing every time something 
is received on port 67 :
# iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 11 packets, 756 bytes)
pkts bytes target     prot opt in     out     source               
destination
   27  8856 REDIRECT   udp  --  *      *       0.0.0.0/0            
0.0.0.0/0          udp dpt:67 MAC 00:B0:D0:BF:27:E8 redir ports 54356


However, when starting the dhcpd on port 67 again (still with the 
redirect-rule in the nat-table) the dhcp server responds, indicating (as far 
as I can see, I'm a tester not a designer) tha the dhcpd is somehow 
"listening on a lower level" than the iptables are working.

I'll try with another dhcpd.

br Håkan E.



>From: Alistair Tonner <>
>To: Håkan Engblom <cynic_0@hotmail.com>,  netfilter@lists.netfilter.org
>Subject: Re: source-mac filtering
>Date: Sun, 11 Jan 2004 00:55:44 -0500
>
>On January 10, 2004 06:20 pm, Håkan Engblom wrote:
> > Hi,
> >
> > I've run in to a strange problem. I have a dhcp-server on a 2.4.22 
>kernel
> > with a 1.2.8 iptables. The dhcp-server is configured only to offer
> > IP-addresses to one single mac-address (it is a single host on a private
> > network)
> >
> >
> > Does anyone have a clue ?
> >
> > br Håkan Engblom
> >
> > Some "logs" :
>
>	<relevant info snipped, since it has been through the list several times>
>
>	Can I think out loud for a moment???
>
>	have dhcpd listen on a *different* port than normal
>	have iptables grab relevant mac address broadcasts and redirect to 
>appropriate port?
>
>	drop anything not in relevant mac address range?
>
>	Perhaps this might work???
>	anyone care to try?? --my personal net is static ... thankgod its only 5 
>boxen
>
>	Alistair Tonner
>

_________________________________________________________________
Hitta rätt på nätet med MSN Sök http://search.msn.se/

Re: source-mac filtering

[Håkan Engblom]

Yes, I've come to realize that.

Is it technically necessary for the dhcp-server to do so, or could it be 
that some other dhcpd behaves different ?

A work with test normally, so I don't know very much about the internal 
structure in Linux.

br Håkan E.


>From: Ramin Dousti <ramin@cannon.eng.us.uu.net>
>To: Håkan Engblom <cynic_0@hotmail.com>
>CC: netfilter@lists.netfilter.org
>Subject: Re: source-mac filtering
>Date: Sun, 11 Jan 2004 11:37:56 -0500
>
>dhcpd takes and puts packets by netlink sockets which bypass the whole
>IP stack. So in short, you cannot filter the requests nor the response.
>
>Ramin
>
>On Sun, Jan 11, 2004 at 12:20:06AM +0100, Håkan Engblom wrote:
>
> > Hi,
> >
> > I've run in to a strange problem. I have a dhcp-server on a 2.4.22 
>kernel
> > with a 1.2.8 iptables. The dhcp-server is configured only to offer
> > IP-addresses to one single mac-address (it is a single host on a private
> > network)
> >
> > However I'd like to block all other mac-addresses on this interface 
>since I
> > plan to have a W-LAN here as well. (to prevent attackers from using
> > potential exploits in the dhcp-server)
> >
> > The mac-filter works fine for http, telnet, ssh aso, I can see the
> > drop-counter increasing and no traffic is let through (when I change the
> > mac-address in the iptables-config to something else than what I have on 
>my
> > "dhcp-client-host"). BUT the dhcp-server keeps sending offers and ack's
> > evethough the incoming discover/request is blocked by iptables.
> >
> > What makes this even more strange is that the "DROP-counters" when using
> > "iptables -L -v" increases, and at the same time the dhcp server 
>responds
> > to the requests.
> >
> > I'm using Internet Software Consortium DHCP Server V3.0.1rc11
> >
> > The machine has only one physical interface whith two IP's one private 
>and
> > one for public. The IP-address offered by the dhcp-server is private (as
> > seen below)
> >
> > Does anyone have a clue ?
> >
> > br Håkan Engblom
> >
> > Some "logs" :
> >
> > 00:30:88:00:63:10 is my DSL-connection (having to accepted packets 
>during
> > this test)
> >
> > X.X.X.X is my public IP.
> >
> > (This is not the complete iptables, but it is teh interesting part for 
>this
> > matter)
> >
> > 00:08:29.540872      0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover -
> > Transaction ID 0xae749e48
> > 00:08:29.541303 X.X.X.X -> 10.0.0.217   DHCP DHCP Offer    - Transaction 
>ID
> > 0xae749e48
> > 00:08:29.542117      0.0.0.0 -> 255.255.255.255 DHCP DHCP Request  -
> > Transaction ID 0xae749e48
> > 00:08:29.542299 X.X.X.X -> 10.0.0.217   DHCP DHCP ACK      - Transaction 
>ID
> > 0xae749e48
> >
> >
> >
> > # date
> > Sun Jan 11 00:08:08 CET 2004
> > # iptables -L -v
> > Chain INPUT (policy DROP 0 packets, 0 bytes)
> > pkts bytes target     prot opt in     out     source
> > destination
> >    0     0 mactable   all  --  eth0   any     anywhere             
>anywhere
> >    0     0 ACCEPT     all  --  lo     any     anywhere             
>anywhere
> >    0     0 DROP      !icmp --  any    any     anywhere             
>anywhere
> >           state INVALID
> >    0     0 eth0_in    all  --  eth0   any    !10.0.0.0/24          
>anywhere
> >    0     0 eth0_1_in  all  --  eth0   any     anywhere             
>anywhere
> >    0     0 common     all  --  any    any     anywhere             
>anywhere
> >
> > Chain mactable (2 references)
> > pkts bytes target     prot opt in     out     source
> > destination
> >    0     0 ACCEPT     all  --  any    any     anywhere             
>anywhere
> >           MAC 01:01:01:01:01:01
> >    0     0 RETURN     all  --  any    any     anywhere             
>anywhere
> >           MAC 00:30:88:00:63:10
> >    0     0 RETURN     all  --  any    any     anywhere             
>anywhere
> >           MAC 00:90:D0:AF:A3:F1
> >    0     0 LOG        all  --  any    any     anywhere             
>anywhere
> >           LOG level info prefix `Shorewall:mac:DROP:'
> >    0     0 DROP       all  --  any    any     anywhere             
>anywhere
> >
> > # date
> > Sun Jan 11 00:08:36 CET 2004
> > # iptables -L -v
> > Chain INPUT (policy DROP 0 packets, 0 bytes)
> > pkts bytes target     prot opt in     out     source
> > destination
> >    4   948 mactable   all  --  eth0   any     anywhere             
>anywhere
> >    0     0 ACCEPT     all  --  lo     any     anywhere             
>anywhere
> >    0     0 DROP      !icmp --  any    any     anywhere             
>anywhere
> >           state INVALID
> >    2   288 eth0_in    all  --  eth0   any    !10.0.0.0/24          
>anywhere
> >    0     0 eth0_1_in  all  --  eth0   any     anywhere             
>anywhere
> >    0     0 common     all  --  any    any     anywhere             
>anywhere
> >
> > Chain mactable (2 references)
> > pkts bytes target     prot opt in     out     source
> > destination
> >    0     0 ACCEPT     all  --  any    any     anywhere             
>anywhere
> >           MAC 01:01:01:01:01:01
> >    2   288 RETURN     all  --  any    any     anywhere             
>anywhere
> >           MAC 00:30:88:00:63:10
> >    0     0 RETURN     all  --  any    any     anywhere             
>anywhere
> >           MAC 00:90:D0:AF:A3:F1
> >    2   660 LOG        all  --  any    any     anywhere             
>anywhere
> >           LOG level info prefix `Shorewall:mac:DROP:'
> >    2   660 DROP       all  --  any    any     anywhere             
>anywhere
> > #
> >
> > _________________________________________________________________
> > Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/
> >

_________________________________________________________________
Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/

Re: source-mac filtering

[Antony Stone]

On Sunday 11 January 2004 5:39 pm, Håkan Engblom wrote:

> Yes, I've come to realize that.
>
> Is it technically necessary for the dhcp-server to do so, or could it be
> that some other dhcpd behaves different ?

It is technically necessary, because DHCP clients do not have IP addressing 
information when they begin the communication; everything is done using 
ethernet broadcasts.   Such packets cannot be acquired using a standard 
socket bind, so the server application needs to listen at a lower level than 
the TCP/IP stack allows.

Regards,

Antony.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

                                                     Please reply to the list;
                                                           please don't CC me.

Re: source-mac filtering

[Ramin Dousti]

On Sun, Jan 11, 2004 at 05:50:52PM +0000, Antony Stone wrote:

> On Sunday 11 January 2004 5:39 pm, Håkan Engblom wrote:
> 
> > Yes, I've come to realize that.
> >
> > Is it technically necessary for the dhcp-server to do so, or could it be
> > that some other dhcpd behaves different ?
> 
> It is technically necessary, because DHCP clients do not have IP addressing 
> information when they begin the communication; everything is done using 
> ethernet broadcasts.   Such packets cannot be acquired using a standard 
> socket bind, so the server application needs to listen at a lower level than 
> the TCP/IP stack allows.

I guess he's asking why dhcp-server uses NETLINK. Your answer is for the
clients, right?

Ramin

Re: source-mac filtering

[Ramin Dousti]

On Sun, Jan 11, 2004 at 06:39:53PM +0100, Håkan Engblom wrote:

> Yes, I've come to realize that.
> 
> Is it technically necessary for the dhcp-server to do so, or could it be 
> that some other dhcpd behaves different ?

No, isc uses AF_LINK, if avalable.

Ramin

> 
> A work with test normally, so I don't know very much about the internal 
> structure in Linux.
> 
> br Håkan E.

Re: source-mac filtering

[Håkan Engblom]

OK, thanks for the support.

br Håkan E.


>From: Antony Stone <Antony@Soft-Solutions.co.uk>
>To: netfilter@lists.netfilter.org
>Subject: Re: source-mac filtering
>Date: Sun, 11 Jan 2004 17:50:52 +0000
>
>On Sunday 11 January 2004 5:39 pm, Håkan Engblom wrote:
>
> > Yes, I've come to realize that.
> >
> > Is it technically necessary for the dhcp-server to do so, or could it be
> > that some other dhcpd behaves different ?
>
>It is technically necessary, because DHCP clients do not have IP addressing
>information when they begin the communication; everything is done using
>ethernet broadcasts.   Such packets cannot be acquired using a standard
>socket bind, so the server application needs to listen at a lower level 
>than
>the TCP/IP stack allows.
>
>Regards,
>
>Antony.
>
>--
>A: Because it messes up the order in which people normally read text.
>Q: Why is top-posting such a bad thing?
>A: Top-posting.
>Q: What is the most annoying thing on usenet and in e-mail?
>
>                                                      Please reply to the 
>list;
>                                                            please don't CC 
>me.
>
>

_________________________________________________________________
Hitta rätt på nätet med MSN Sök http://search.msn.se/