[177929] in North American Network Operators' Group
Re: Dynamic routing on firewalls.
daemon@ATHENA.MIT.EDU (Patrick Tracanelli)
Mon Feb 9 08:54:14 2015
X-Original-To: nanog@nanog.org
From: Patrick Tracanelli <eksffa@freebsdbrasil.com.br>
In-Reply-To: <364F7CA4-9630-44E8-8494-28F786092965@delong.com>
Date: Mon, 9 Feb 2015 11:54:04 -0200
To: Owen DeLong <owen@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On 08/02/2015, at 22:48, Owen DeLong <owen@delong.com> wrote:
>=20
>>=20
>> On Feb 8, 2015, at 06:02 , Patrick Tracanelli =
<eksffa@freebsdbrasil.com.br> wrote:
>>=20
>> Hello,
>>=20
>>>=20
>>> Some Juniper models actually do a very good job of being both.
>>>=20
>>> In reality, a Firewall _IS_ a router, even if it's a bad one. =
Anything that moves packets from one interface to another is a router.
>>=20
>> Technically it=E2=80=99s quite not a precise assumption. While =
routing is much likely an IP core need and OSI Layer 3 related =
mechanism, a firewall does not have to basic L3 forwarding. It can be a =
bridged/bright firewall, may fit in front of a router, protecting it, =
and carrying. Not routing anything. In fact in a fail-safe scenario =
(from availability perspective) a bridged firewall may be shut down =
completely and a Bypass por pair taking place will keep traffic flowing, =
=E2=80=9Cmoving packets from one port to another=E2=80=9D without =
actually ever been a router.
>=20
> Technically true, but bridged firewalls are pretty much passe these =
days in the real world. As a general rule, when the firewall is shut =
down, one usually doesn=E2=80=99t want the packets flowing past =
un-hindered. The fact that this is kind of the default of what happens =
with bridged firewalls is just one of the many reasons hardly anyone =
still uses such a thing.
Hello Owen,
I didn=E2=80=99t get your point.
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. =
Dropping everything if packet is down. Combining bypass ports + STP you =
can have the set of availability you wish better for your scenario, from =
simply bypassing everything like you have no box there, if a software or =
power failure occurs, or having an active failover bridged together on =
the bypass port, allowing for full firewalling redundancy if the primary =
box fails. So you are no leaking options if you are doing it on L2 =
instead of L3. You have additional ease, redundancy won=E2=80=99t =
require VRRP or similar stuff since it=E2=80=99s not L3 related.
To clarify, I am not saying a bridged firewall is a better option for =
every sort of scenario. Usually I do L3 firewall with the box being an =
extra hop on the topology, doing CARP for IP reduncancy, etc. But back =
to the point that a firewall doesn=E2=80=99t need to L3 forward, I like =
the idea of having a L2 firewall whenever an extra routing hop is not =
desired, and still won=E2=80=99t lack features and redundancy options.
>> I have recently added netmap-ipfw in front of BGP routers protecting =
=E2=80=98em from DDoS attacks, adding line-rate firewalling capabilities =
to a commodity x86/64 box or a T5 card for 10GbE/40GbE, and netmap-ipfw =
itself acts like mentioned, passing packets back and forth between =
interfaces without ever routing anything.
>=20
> Sure, there are all kinds of things one can do. Some of them are good =
ideas, many of them are not. If it works in your environment and =
you=E2=80=99re OK with the failure modes and other tradeoffs, then more =
power to you.
I=E2=80=99m still missing what you are pointing as failure modes or =
tradeoffs.
IPFW does a pretty decent job on L2 filtering, with a particular =
exception of =E2=80=9Cipfw fwd=E2=80=9D which won=E2=80=99t work by =
default under this setup. I can drop unwanted L2 traffic - in fact I =
like to only allow IPv4,v6 and ARP by default on LLC, cisco discovery =
and RARP when needed, everything else dropped on L2. Therefore whenever =
I decide to add it bright, I still don=E2=80=99t miss anything.
>>> Of course, the support for routing protocols is a useful feature in =
a router and one of the areas where firewalls often fall short.
>>>=20
>>> Where you want to put things (in front, behind, etc.) really depends =
on your topology and the problem you are trying to solve.
>>>=20
>>> Personally, I like to keep the firewalls as close to the end hosts =
as possible. This tends to greatly simplify security policies and make =
them MUCH easier (and more reliable) to audit.
>>=20
>> I agree. A firewall belongs better closer to the end hosts being =
protected. Maybe protection of the router is the only exception when =
RTBH will not fit the task (or just won=E2=80=99t be enough).=20
>=20
> DDoS mitigation on site is a questionable and usually losing =
proposition at best. Other than DDoS mitigation, any good router should =
be perfectly capable of protecting itself. For protecting a router from =
DDoS that it cannot properly protect itself, one needs to be able to =
control or alter the delivery of packets across the upstream link from =
the upstream side anyway. That is best done by an off-site service such =
as Akamai=E2=80=99s Prolexic.
Sadly true just in theory. On real world, people still run weak and low =
power boxes as routers, ranging from old Cisco boxes to Routerboards, =
Edgerouters and x86 boxes without any special card or technologies such =
as DNA, DPDK, Netmap, and therefore boxes that can=E2=80=99t hardly =
protect themselves against simple DDoS, while they still can route and =
do their job on calm water, won=E2=80=99t behave well on storms. We are =
not always talking about big telcos and people who can rely on an =
efficient and well dimensioned Juniper box.
Frequently, the =E2=80=9Crouters vs firewall=E2=80=9D or =E2=80=9Cstateful=
vs stateles on the same box=E2=80=9D confusion discussed on other =
recent threads in this group, just happens, and we get relatively big =
companies adding stuff like sonicwalls, fortinets, with BGP + a mix of =
security features on the same box, and certainly those boxes can=E2=80=99t=
hardly protect itself (but people still believe they can protect the =
whole network behind it). So, whether it=E2=80=99s caused by low power =
boxes or bad projects, the need for router protection is more often than =
it should.
>> Therefore, close to the end host usually means far from the core =
routers. Unless one is really considering a CPE device doing poorly jobs =
of =E2=80=9Ca router and a firewall=E2=80=9D=E2=80=A6
>=20
> Depends on the nature of your network. I know lots of datacenter =
networks where the end hosts are not more than one or two hops removed =
from the core routers. I would hardly refer to those networks as a CPE =
device doing a poor job of =E2=80=9Crouter and firewall=E2=80=9D.
Yes, I may refer to a linux box, a VyOS, Endian, OpenBSD PF or a =
sonicwall box 2 hops after the core router a bad option for accumulating =
router+firewall functions if they are not protected on upper hops. Not =
due to any kind of feature or scalability miss (except for OpenBSD=E2=80=99=
s kernel and therefore firewall not scaling beyond CPU0). But due to =
their default behavior ranging from not protecting data plane from =
simple problems like ARP storm, up to the fact they will, by default, =
waste state entries for ordinary stuff like filtering. So, yes, they are =
usually doing poor jobs of being a router and a firewall. We see it very =
often, co-location setups failing due to exhaustion of resources or =
inability to self protect when uncalm packet flows reach their racks on =
data centers, but still the whole DC and previous hops still run =
perfectly up, available and unaffected. Sure it=E2=80=99s when they will =
earn/charge extra by adding firewall services=E2=80=A6 because customer =
boxes where doing their poor jobs of being both. So, back to the point, =
unless very well projected or engineered, they will need earlier =
protection.
I have just recently run into a situation where a Fortigate box that =
should add protection and balancing on a data center colo, just died =
exhausted by simple memory starvation. No matter the real cause (people =
tend to use those boxes doing everything they can do at once, and =
expecting it to work under uncontrolled circumstances), for the customer =
it was their core node. For the datacenter it was an end host. For me it =
was just a box doing bad jobs of being more than it should at once, and =
it had to be protected.
A couple months ago I have run into another scenario where a Juniper MX5 =
box was suffering from UDP DDoS with low packet size. It=E2=80=99s still =
not clear for me why Juniper was not sustaining the attack traffic, if =
it was a bad configuration or because the pps rate was close to 1GbE =
ports line rate limit, and the company in question didn=E2=80=99t want =
to pay for MX series upgrade to have 10G ports just for attack =
contention. We added a netmap-ipfw in front of the Juniper box with T5 =
10GbE ports filtering the profiled packet sized, and filtering other UDP =
patterns, which lead the Juniper box to do it=E2=80=99s routing job =
again without ever being upgraded to 10G licensed MX versions.
Sure an off-site protection would do the job before upstream. But no =
need for that many gun powder to kill such a small sized animal :) And =
just like most DDoS, it didn=E2=80=99t least forever.
And again, it was a non L3 forwarding firewall; no extra hop or relevant =
change in the topology. Sure L3 firewalls are more usual, it=E2=80=99s =
always been, it=E2=80=99s not a =E2=80=9Cnowadays=E2=80=9D momentum. But =
a bright firewall still have its relevant place in the network, and =
it=E2=80=99s a firewall with no missing piece of functionality, IMHE.
--
Patrick Tracanelli
