Re: [fw-wiz] Layer 2 (stealth) firewalls - PBR?


This would not be Layer 2 PBR. This would be Layer 2 NAT of MACs.
E.g. a frame hits the MAC-NAT with a destination MAC of
X, and your rule says if X is dest then rewrite the frame
so it has dest MAC of Y instead.

--p

-----Original Message-----
From: firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxx
[mailto:firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of Sami
Ghourabi
Sent: Tuesday, April 01, 2008 11:28 AM
To: 'Firewall Wizards Security Mailing List'; 'Firewall Wizards Security
Mailing List'
Subject: Re: [fw-wiz] Layer 2 (stealth) firewalls - PBR?


Hi Darren,

I had the same question a while ago during a firewall (Juniper Networks one)
deployment for a customer. He had a proxy-cache and wanted to make it
transparent to its user. I thought to use PBR to redirect internet traffic
to the caching box, but it was impossible as the firewall was set as a
bridge, the only solution I found was to put the proxy-cache inline.

I think it would be useful to have some PBR at layer 2 (or PB Forwarding)
for situations like this, where you have to redirect content to caching or
inspection engine, perhaps some constructors have already implemented same
mechanisms in their firewalls ?

Regards,

Sami.

-----Message d'origine-----
De : firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxx
[mailto:firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxx] De la part de Darren
Reed
Envoyé : mardi 1 avril 2008 05:49
À : Firewall Wizards Security Mailing List
Objet : [fw-wiz] Layer 2 (stealth) firewalls - PBR?

If I can interrupt the usual questions for some product requirements
discovery....

Over in the networking community on OpenSolaris.org, a couple of
us are pondering the question of what it means to do policy based
routing (PBR) at the ethernet (MAC) layer.

For IP, the use case is well understood and people everywhere do
it with firewall software, if only to make up for the inadequacies of
their routing tables however when it comes to ethernet, we're kind
of scratching our heads....so, some questions....

Does running a stealth (bridging) firewall remove the need for PBR?

Do people still do strange, quirky, things to packets even when they
don't want them to go through IP?

If you're using bridging to support your firewall (that still filters
packets using IP header information), can you shed some light on
why/when you want to send packets out a specific NIC regardless
of what the forwarding table for the bridge says?

Thanks,
Darren

_______________________________________________
firewall-wizards mailing list
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

Relevant Pages

  • Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet
    ... Among other things, there are race conditions such that the lookup could return one pcb in the input path and use that for the check, but another pcb during TCP-layer delivery. ... One idea that I'd been pondering was having the inpcb code in the TCP/UDP/SCTP/etc layers invoke event handlers as bindings/connections are made, making credentials and other information available to firewall packages, which could then cache information under their own locks. ... In Mac OS X Leopard, many of the traditional "firewall" sorts of checks are now performed at the socket layer using this sort of approach -- this provides greater application context, allows control of things like binding/listening, not just packet transmission and receipt, and provides access to the data as received at the application layer rather than at the datagram layer, avoiding the need for normalization. ...
    (freebsd-arch)
  • Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet
    ... Among other things, there are race conditions such that the lookup could return one pcb in the input path and use that for the check, but another pcb during TCP-layer delivery. ... One idea that I'd been pondering was having the inpcb code in the TCP/UDP/SCTP/etc layers invoke event handlers as bindings/connections are made, making credentials and other information available to firewall packages, which could then cache information under their own locks. ... In Mac OS X Leopard, many of the traditional "firewall" sorts of checks are now performed at the socket layer using this sort of approach -- this provides greater application context, allows control of things like binding/listening, not just packet transmission and receipt, and provides access to the data as received at the application layer rather than at the datagram layer, avoiding the need for normalization. ...
    (freebsd-current)
  • Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet
    ... Among other things, there are race conditions such that the lookup could return one pcb in the input path and use that for the check, but another pcb during TCP-layer delivery. ... One idea that I'd been pondering was having the inpcb code in the TCP/UDP/SCTP/etc layers invoke event handlers as bindings/connections are made, making credentials and other information available to firewall packages, which could then cache information under their own locks. ... In Mac OS X Leopard, many of the traditional "firewall" sorts of checks are now performed at the socket layer using this sort of approach -- this provides greater application context, allows control of things like binding/listening, not just packet transmission and receipt, and provides access to the data as received at the application layer rather than at the datagram layer, avoiding the need for normalization. ...
    (freebsd-net)
  • Re: [fw-wiz] Layer 2 (stealth) firewalls - PBR?
    ... Layer 3 PBR doesn't change layer 3 addressing, ... If you do layer 2 PBR you must change the MAC address (unless for some ...
    (Firewall-Wizards)
  • RE: Firewall: a basic question
    ... A firewall is just a term that is commonly applied to layer 3 (and ... use of non-router VLAN implementations and MAC address filtering. ...
    (Security-Basics)