Dynamic routing on firewalls.

Patrick Tracanelli eksffa at freebsdbrasil.com.br
Mon Feb 9 14:56:37 UTC 2015


> On 09/02/2015, at 12:14, Valdis.Kletnieks at vt.edu wrote:
> 
> On Mon, 09 Feb 2015 11:54:04 -0200, Patrick Tracanelli said:
> 
>> On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but the box still up.
> 
> Owen's point is that passing packets if the firewall is down is really poor
> security-wise.   If you run in that configuration, I simply DoS your firewall
> (probably from one set of IP addresses), and then once it has fallen over and
> is being bypassed, I send my *real* malicious traffic from some other IP
> address, totally uninspected and unhindered.  Much hilarity, hijinks, and
> pwnage ensues.

Hello Valdis,

If this is really the point, I don’t know what system you are talking about, that will behave like that. If I run a closed firewall, kernel-path, and it’s unable process, and therefore “allow” the traffic, it will drop. If I run it netmap-ipfw and it’s unable to move the packet from one port to the other, it will drop. So there’s no point where a bridge implicits traffic bypass upon starvation/exaustion, unless this is your option to do so, or a default system behavior, in this case a system that should not act for this purpose.

If I remember well (and I remember some effusive expressions like “L2 functions easily enabled at scale on a Junos Trio system”), on a Juniper box bridging is processed on Trio chip - even without IRB set up, as well as firewall (limited matching conditions in a bridged domain). If you can exhaust TRIO from your DoS approach (and the idea is that you can’t exhaust it without exhausting line rate first), you will have no bridging anyway, since L2 learning and forwarding will also be resource starved.

But this is just all theoretical, as I mentioned you will probably reach line rate limit first if the box is not configured wrong or wrongly planned.

--
Patrick Tracanelli




More information about the NANOG mailing list