Re: source-mac filtering

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 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

[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

Packet injection

[Scott MacKay]

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

ether source/dest from userspace?

[Scott MacKay]

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

Packet injection

[conder000]

Hello, is packet injection on ath10k in development? If so, whats the
status of it please? Thanks for reply.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Packet Injection

[Oliver Korpilla]

Hello!

I'm new to the list, and what I've found in the list archives regarding
packet injection is somewhat lacking in detail.

What I want to do:

I want to write a tool that sends and receives packets within the kernel
context. It's generates traffic on one interface and receives the result
of some blackbox modification to it on another interface.

So I need both packet filtering / netfilter like capabilities and packet
injection capabilities.

While the way to go for the receiving end of the application is pretty
straightforward, my question is: How to inject packets inside the kernel?

One idea was to create the packets externally, store them in kernel RAM,
and use netfilter hooks to inject them. The injection would be done by a
linux kernel module or rather by a periodic tasklet registered by that
module.

Can you comment whether this is a feasible approach?

Or could you come up with a better one, that fulfills the requirement of
being in-kernel?

Thanks and with kind regards,
Oliver Korpilla