* Re: source-mac filtering
@ 2004-01-11 17:39 Håkan Engblom
2004-01-11 17:50 ` Antony Stone
2004-01-12 16:06 ` source-mac filtering Ramin Dousti
0 siblings, 2 replies; 20+ messages in thread
From: Håkan Engblom @ 2004-01-11 17:39 UTC (permalink / raw)
To: netfilter
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-11 17:39 source-mac filtering Håkan Engblom
@ 2004-01-11 17:50 ` Antony Stone
2004-01-12 17:56 ` Ramin Dousti
2004-01-12 16:06 ` source-mac filtering Ramin Dousti
1 sibling, 1 reply; 20+ messages in thread
From: Antony Stone @ 2004-01-11 17:50 UTC (permalink / raw)
To: netfilter
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-11 17:39 source-mac filtering Håkan Engblom
2004-01-11 17:50 ` Antony Stone
@ 2004-01-12 16:06 ` Ramin Dousti
1 sibling, 0 replies; 20+ messages in thread
From: Ramin Dousti @ 2004-01-12 16:06 UTC (permalink / raw)
To: Håkan Engblom; +Cc: netfilter
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-11 17:50 ` Antony Stone
@ 2004-01-12 17:56 ` Ramin Dousti
2004-01-12 19:04 ` Packet injection Scott MacKay
2004-01-14 15:50 ` ether source/dest from userspace? Scott MacKay
0 siblings, 2 replies; 20+ messages in thread
From: Ramin Dousti @ 2004-01-12 17:56 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Packet injection
2004-01-12 17:56 ` Ramin Dousti
@ 2004-01-12 19:04 ` Scott MacKay
2004-01-14 15:50 ` ether source/dest from userspace? Scott MacKay
1 sibling, 0 replies; 20+ messages in thread
From: Scott MacKay @ 2004-01-12 19:04 UTC (permalink / raw)
To: netfilter
I was wondering, is there any sample code of injecting
new packets while userspace processing? I was looking
for something that could add a new packet in the QUEUE
target userspace program or to inject a packet back at
the start of the whole processing. I was looking to
inject with the hope of writing the entire packet
header structure, not just the IP contents. Any
samples or URLS?
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
^ permalink raw reply [flat|nested] 20+ messages in thread
* ether source/dest from userspace?
2004-01-12 17:56 ` Ramin Dousti
2004-01-12 19:04 ` Packet injection Scott MacKay
@ 2004-01-14 15:50 ` Scott MacKay
1 sibling, 0 replies; 20+ messages in thread
From: Scott MacKay @ 2004-01-14 15:50 UTC (permalink / raw)
To: netfilter
Hi,
When you get a packet to process in the userspace
QUEUE, is there any way to get the source and
destination ethernet addresses?
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
[not found] ` <200401120110.08378.Alistair Tonner <>
@ 2004-01-12 15:52 ` Ramin Dousti
0 siblings, 0 replies; 20+ messages in thread
From: Ramin Dousti @ 2004-01-12 15:52 UTC (permalink / raw)
To: netfilter-admin; +Cc: Tarek W., netfilter
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-11 19:05 ` Tarek W.
@ 2004-01-12 6:10 ` Unknown, Alistair Tonner
[not found] ` <200401120110.08378.Alistair Tonner <>
1 sibling, 0 replies; 20+ messages in thread
From: Unknown, Alistair Tonner @ 2004-01-12 6:10 UTC (permalink / raw)
To: Tarek W., netfilter
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...
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-11 16:37 ` Ramin Dousti
@ 2004-01-11 19:05 ` Tarek W.
2004-01-12 6:10 ` Unknown, Alistair Tonner
[not found] ` <200401120110.08378.Alistair Tonner <>
0 siblings, 2 replies; 20+ messages in thread
From: Tarek W. @ 2004-01-11 19:05 UTC (permalink / raw)
To: netfilter
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...
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
@ 2004-01-11 18:16 Håkan Engblom
0 siblings, 0 replies; 20+ messages in thread
From: Håkan Engblom @ 2004-01-11 18:16 UTC (permalink / raw)
To: netfilter
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
@ 2004-01-11 17:36 Håkan Engblom
0 siblings, 0 replies; 20+ messages in thread
From: Håkan Engblom @ 2004-01-11 17:36 UTC (permalink / raw)
To: netfilter
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-10 23:20 Håkan Engblom
` (2 preceding siblings ...)
2004-01-11 5:55 ` Unknown, Alistair Tonner
@ 2004-01-11 16:37 ` Ramin Dousti
2004-01-11 19:05 ` Tarek W.
3 siblings, 1 reply; 20+ messages in thread
From: Ramin Dousti @ 2004-01-11 16:37 UTC (permalink / raw)
To: Håkan Engblom; +Cc: netfilter
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/
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-10 23:20 Håkan Engblom
2004-01-10 23:37 ` Antony Stone
2004-01-11 0:13 ` Pawel Staszewski
@ 2004-01-11 5:55 ` Unknown, Alistair Tonner
2004-01-11 16:37 ` Ramin Dousti
3 siblings, 0 replies; 20+ messages in thread
From: Unknown, Alistair Tonner @ 2004-01-11 5:55 UTC (permalink / raw)
To: Håkan Engblom, netfilter
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
@ 2004-01-11 0:59 Håkan Engblom
0 siblings, 0 replies; 20+ messages in thread
From: Håkan Engblom @ 2004-01-11 0:59 UTC (permalink / raw)
To: netfilter
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
@ 2004-01-11 0:43 Håkan Engblom
0 siblings, 0 replies; 20+ messages in thread
From: Håkan Engblom @ 2004-01-11 0:43 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-11 0:25 ` Antony Stone
@ 2004-01-11 0:34 ` Pawel Staszewski
0 siblings, 0 replies; 20+ messages in thread
From: Pawel Staszewski @ 2004-01-11 0:34 UTC (permalink / raw)
To: netfilter
----- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-11 0:13 ` Pawel Staszewski
@ 2004-01-11 0:25 ` Antony Stone
2004-01-11 0:34 ` Pawel Staszewski
0 siblings, 1 reply; 20+ messages in thread
From: Antony Stone @ 2004-01-11 0:25 UTC (permalink / raw)
To: netfilter
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-10 23:20 Håkan Engblom
2004-01-10 23:37 ` Antony Stone
@ 2004-01-11 0:13 ` Pawel Staszewski
2004-01-11 0:25 ` Antony Stone
2004-01-11 5:55 ` Unknown, Alistair Tonner
2004-01-11 16:37 ` Ramin Dousti
3 siblings, 1 reply; 20+ messages in thread
From: Pawel Staszewski @ 2004-01-11 0:13 UTC (permalink / raw)
To: Håkan Engblom; +Cc: netfilter
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/
>
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: source-mac filtering
2004-01-10 23:20 Håkan Engblom
@ 2004-01-10 23:37 ` Antony Stone
2004-01-11 0:13 ` Pawel Staszewski
` (2 subsequent siblings)
3 siblings, 0 replies; 20+ messages in thread
From: Antony Stone @ 2004-01-10 23:37 UTC (permalink / raw)
To: netfilter
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* source-mac filtering
@ 2004-01-10 23:20 Håkan Engblom
2004-01-10 23:37 ` Antony Stone
` (3 more replies)
0 siblings, 4 replies; 20+ messages in thread
From: Håkan Engblom @ 2004-01-10 23:20 UTC (permalink / raw)
To: netfilter
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2004-01-14 15:50 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-11 17:39 source-mac filtering Håkan Engblom
2004-01-11 17:50 ` Antony Stone
2004-01-12 17:56 ` Ramin Dousti
2004-01-12 19:04 ` Packet injection Scott MacKay
2004-01-14 15:50 ` ether source/dest from userspace? Scott MacKay
2004-01-12 16:06 ` source-mac filtering Ramin Dousti
-- strict thread matches above, loose matches on Subject: below --
2004-01-11 18:16 Håkan Engblom
2004-01-11 17:36 Håkan Engblom
2004-01-11 0:59 Håkan Engblom
2004-01-11 0:43 Håkan Engblom
2004-01-10 23:20 Håkan Engblom
2004-01-10 23:37 ` Antony Stone
2004-01-11 0:13 ` Pawel Staszewski
2004-01-11 0:25 ` Antony Stone
2004-01-11 0:34 ` Pawel Staszewski
2004-01-11 5:55 ` Unknown, Alistair Tonner
2004-01-11 16:37 ` Ramin Dousti
2004-01-11 19:05 ` Tarek W.
2004-01-12 6:10 ` Unknown, Alistair Tonner
[not found] ` <200401120110.08378.Alistair Tonner <>
2004-01-12 15:52 ` Ramin Dousti
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.