LARTC - Apr 2003 - modifying ethernet header dst mac with ebtables?

Hi,

Im working in a briding enviroment and i want to be
sure that my arp requests outgoing a bridge interface
will be hear by only one specific device (because of
security reason)

are there any way to re-write the ff:ff:ff:ff:ff:ff
on this arp request so they appears like a unicast?

Do de ip stack understand this "unicast" arp request?

Thanks in advance for your help
Victor

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Victor,

 : I´m working in a briding enviroment and i want to be sure that my arp
 : requests outgoing a bridge interface will be hear by only one specific
 : device (because of security reason)

Strange need!  Sounds interesting.

 : are there any way to re-write the ff:ff:ff:ff:ff:ff on this arp request
 : so they appears like a unicast?

I imagine that Julian will jump in here and reply to you, but I thought
I''d point you to ip arp, an add-on tool Julian has written for
iproute2.

  http://www.ssi.bg/~ja/#iparp

 : Do de ip stack understand this "unicast" arp request?

Er...um...I don''t know.  Good question.

-Martin

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Hello,

On Fri, 4 Apr 2003, Martin A. Brown wrote:
>  : I´m working in a briding enviroment and i want to be sure that my arp
>  : requests outgoing a bridge interface will be hear by only one specific
>  : device (because of security reason)
	Victor, what about trying something similar to the example
in the ebtables docs:

ebtables -t nat -A PREROUTING -d ff:ff:ff:ff:ff:ff -i eth0 -j dnat
--to-destination 54:44:33:22:11:00
>  : are there any way to re-write the ff:ff:ff:ff:ff:ff on this arp request
>  : so they appears like a unicast?
>
> I imagine that Julian will jump in here and reply to you, but I thought
> I''d point you to ip arp, an add-on tool Julian has written for
iproute2.
>
>   http://www.ssi.bg/~ja/#iparp
	iparp can not see these packets (layer 2) but for other
purposes probes can be originated with unicast dst MAC in this way:

ip arp add table output to 1.2.3.4 lldst 00:11:22:33:44:55
>  : Do de ip stack understand this "unicast" arp request?
	Yes but at MAC level the ARP code cares only for
unicast/broadcast, no matter the actual dst MAC of the received
packet.

Regards

--
Julian Anastasov <ja@ssi.bg>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Julian , Martin

Ive succesfully tested the ebtables experiment
doing dnat and writing specific mac instead of all
FFs to the arp querys

it works fine 

if some one want see the small cap file is available
at

http://megaserv.homeip.net/arp.cap

regards

and thanks again for your help


--- Julian Anastasov <ja@ssi.bg> wrote:
> 
> 	Hello,
> 
> On Fri, 4 Apr 2003, Martin A. Brown wrote:
> 
> >  : Im working in a briding enviroment and i want
> to be sure that my arp
> >  : requests outgoing a bridge interface will be
> hear by only one specific
> >  : device (because of security reason)
> 
> 	Victor, what about trying something similar to the
> example
> in the ebtables docs:
> 
> ebtables -t nat -A PREROUTING -d ff:ff:ff:ff:ff:ff
> -i eth0 -j dnat --to-destination 54:44:33:22:11:00
> 
> >  : are there any way to re-write the
> ff:ff:ff:ff:ff:ff on this arp request
> >  : so they appears like a unicast?
> >
> > I imagine that Julian will jump in here and reply
> to you, but I thought
> > I''d point you to ip arp, an add-on tool Julian has
> written for iproute2.
> >
> >   http://www.ssi.bg/~ja/#iparp
> 
> 	iparp can not see these packets (layer 2) but for
> other
> purposes probes can be originated with unicast dst
> MAC in this way:
> 
> ip arp add table output to 1.2.3.4 lldst
> 00:11:22:33:44:55
> 
> >  : Do de ip stack understand this "unicast" arp
> request?
> 
> 	Yes but at MAC level the ARP code cares only for
> unicast/broadcast, no matter the actual dst MAC of
> the received
> packet.
> 
> Regards
> 
> --
> Julian Anastasov <ja@ssi.bg>
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:
http://lartc.org/


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/