[121208] in North American Network Operators' Group
RE: I don't need no stinking firewall!
daemon@ATHENA.MIT.EDU (Brian Johnson)
Wed Jan 13 10:08:31 2010
Date: Wed, 13 Jan 2010 09:07:52 -0600
In-Reply-To: <97113335-6535-4B1D-9C77-EB4E61704B49@ndsu.edu>
From: "Brian Johnson" <bjohnson@drtel.com>
To: "NANOG list" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> -----Original Message-----
> From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu]
> Sent: Tuesday, January 12, 2010 5:14 PM
> To: NANOG list
> Subject: Re: I don't need no stinking firewall!
<SNIP>
> >>
> >> IMO you're better off making sure only the services you intend to
> >> provide are listening, and that those services are hardened
> >> appropriately for public exposure.
> >
> > OK. This is obvious to anyone with experience in these things. But I
> > also believe in a layered approach. It never hurts to add more
layers
> to
> > prevent human error or even internal breaches as the different
> systems
> > are under the control of different equipment (servers, routers,
> > switches, security devices). It's like two supports holding up
> something
> > without knowing if the other one is doing its job. Both need to pull
> the
> > full weight in case the other fails.
>=20
>=20
> I disagree. "Never" is pretty absolute. If that were true there
> would be no limit to the number of layers.
I'm with you, but you get my sentiment without being too literal. :)
>=20
> Realistically I have experienced the harm from having firewalls in
> the network path.
I've experienced harm from routers in the network path. If you use the
tool correctly and with full knowledge of its limitations, then you will
be able to avoid "harm" and add functionality/security/value... whatever
the goal is.
>=20
> I have witnessed too many video sessions that either couldn't be
> started or had the sessions dropped prematurely because of firewalls.
So putting a firewall that can't handle your traffic in your network
path sounds like a bad idea FOR YOU. :)
>=20
> When the worms were infecting machines a couple of years ago our
> network was robust and stable and I identified and blocked infected
> machines quickly. Other universities shut down their residence halls
> or large portions of their network because their firewalls rolled over
> and died otherwise from all of the scanning from inside their network.
I remember hearing about this type of thing. I'm sorry for this learning
lesson, but that doesn't mean that firewalls are "bad" or that stateful
inspection is "bad". It means that it was a bad choice for your
environment.
> I have talked to universities who consider the firewall the canary
of
> the network world, its the first box in the network to cease
> functioning when there is a problem.
I think this type of assertion is just folly. I would say that some
universities (full of all those really smart people ;) should be able to
discern that a monkey wrench was being used to do the job of a hammer,
or vice versa. The problem was not the tool, but the person who used the
wrong tool for the job at hand.
=20
>=20
> Others have already mentioned the troubleshooting nightmares that
> firewalls generate, I would consider that a harm also.
>=20
I've had one of those "troubleshooting nightmares" before. It was due to
MY IGNORANCE of what I was doing. The firewall is not causing the
nightmare. Ignorance is.
My last statement on this thread is that if you use a tool in the wrong
way, you will either break the tool, or the item you are using it on. If
you don't know how to use a tool, learn before you try. If you try
first, you will learn later (Here comes that nightmare) how the tool
does/doesn't work. Specific examples of failure are not failures of the
device, but failures of the implementer(s) to correctly use the tool
with the obvious exception of vendors not being truthful about the tools
capabilities.
Please no more examples of specific failures of firewalls. We all know
that they were designed by Satan himself to destroy our networks and
bring about the Antichrist. ;)
- Brian
CONFIDENTIALITY NOTICE: This email message, including any attachments, =
is for the sole use of the
intended recipient(s) and may contain confidential and privileged =
information. Any unauthorized review,
copying, use, disclosure, or distribution is prohibited. If you are not =
the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the =
original message. Thank you.
