Firewall opinions wanted please

Mailman List Mirror (Read Only)
1

No. Quite apart from the fact that you mean "authorized", not
"authenticated", the primary purpose of a firewall is to keep the bad
guys away from the buggy code. Firewalls are the networks' response to
the host security problem.

Put in a NANOG0-friendly way, they're a scalable security mechanism
that can *help* defend you. Think of the endorsement on most tubes of
(American) toothpaste:

   ... has been shown to be an effective decay-preventive
   dentifrice that can be of significant value when used as directed
   in a conscientiously applied program of oral hygiene and
   regular professional care.

If all you want to do is say "no" to all incoming connections on a
single machine, you don't need a separate box labeled "firewall"
-- assuming, of course, that your host is properly configured. Most
systems aren't configured that way; worse yet, it takes a lot of
knowledge to understand how to block things, and when it's ok to do so.
(It's an amusing exercise to run ZoneAlarm on a new, out-of-the box
Windows machine and see how many different programs think they need to
talk to the network, or (worse yet) act as servers.) But it's a lot of
work to configure a machine to be that safe, and if you have a hundred
or a thousand of them you can't do it; entropy will open up new holes
-- that is, open up new sockets for buggy applications -- faster than
you can close them down. Add to that that you don't really know what's
safe or unsafe, and that you have some services that are convenient for
insiders but don't have adequate, scalable authentication on which you
can build an authorization mechanism, and you see why firewalls are
useful.

Perfect? No, of course not. A good idea? Absolutely.

    --Steve Bellovin, http://www.research.att.com/~smb

2

No. Quite apart from the fact that you mean "authorized", not
"authenticated", the primary purpose of a firewall is to keep the bad
guys away from the buggy code. Firewalls are the networks' response to
the host security problem.

No. let's imagine, that I have 4 hosts, without ANY security problems in
software, and I'd like to provide WEB service. Firewall
protects other services from outside access. Without it, you can slogin to
me, if you know my password, even if host have not any bugs. (Of course,
SecureID, hand scan etc... decreases a need for this.)

Second. Not ANY network require FireWall. If network (grandma) do not allow
any ACCESS fron Internet (grandma's netword do not allow access because it
does not expose any IP device to outside network, using NAT for outgoing
connections), it can live withourt any ACl and any firewall attributes - and
be as secure as production network with expansive firewall(s).

Key word is _ACCESS_. No ACCESS - no FireWall (cut wires). One Way Access -
many different devices plays role of firewall (PNAT translator, for example,
makes 99.9% of the work). More ACCESS required - mode COMPLICATED firewalls
are required.

So, key word is not PROTECTION but ACCESS.

3

OK, I've tried to stay out of this, but...

No. let's imagine, that I have 4 hosts, without ANY security problems in
software,

Exactly how do you *prove* there are zero security problems with any of
this software? I hate to say it, but a lot of the security issues we are
faced with today is because people thought they could build secure
software without worrying about a secure architecture. That's exactly
what you are doing here.

Firewall protects other services from outside access.

A good firewall *should* be doing a whole lot more than that. It should
also be giving you a good level of detail about what crosses your
perimeter. It should also be doing some level of content checking to
protect the servers behind it. It should also be stopping and alerting
you if that Web server one day tries to TFTP out to the Internet. Etc.
etc. etc.

Second. Not ANY network require FireWall. If network (grandma) do not allow
any ACCESS fron Internet (grandma's netword do not allow access because it
does not expose any IP device to outside network, using NAT for outgoing
connections), it can live withourt any ACl and any firewall attributes

<sarcasm>
Absolutely, because who cares if someone drops a call home Trojan on
Grandma's system (via e-mail or nasty URL) which turns the system into a
spam relay or a DDoS zombie. That would *never* happen, right?
</sarcasm>

Oh wait, I seem to remember that both of these problems are discussed on
at least a weekly basis in this forum. A firewall can't prevent the
above attacks, but it can give you a heads up that they happened.

- and
be as secure as production network with expansive firewall(s).

Dude, *please* don't take this as a slam, but you really need to come
more up to speed on this technology.

Key word is _ACCESS_. No ACCESS - no FireWall (cut wires).

Agreed, but in both of your examples were you say a firewall is not
needed, you include some level of access.

Now if you are going to cut the wires and ensure there are no 802.11 or
dial-in access points, I'll agree so long as physical security is up to
snuff.

One Way Access -
many different devices plays role of firewall (PNAT translator, for example,
makes 99.9% of the work).

Hey has anyone tested this lately? I beat up on a number of NAT only
firewalls about 3 years ago and found that approximately half could be
defeated by simply using loose source routing. Has anyone tested the
latest round up of products for this "functionality"?

HTH,
Chris

4

> Firewall protects other services from outside access.

A good firewall *should* be doing a whole lot more than that. It should

Do not overestimate. Firewall can make a little more than just restrict
access and inspect few (very limited) protocols.
It can not protect you from slow scans; it can not protect you from SSL /
SSH / (any other encrypted protocol) volnurabilities,
it can not protect your users from viruses in e-mail, etc etc. Proxy
firewall (device which terminates _ALL_ protocols) can
help in some cases (management access to your network by ssh) but can not
with others (SSL site hosting , for excample).

also be giving you a good level of detail about what crosses your

Very good level of details - 200 Mb of daily logs (IP, IP protocol = https).
Any network statistics system can do it. Unfortunately, all this logs are
99% useless until you need forensics.

perimeter. It should also be doing some level of content checking to

In reality, I can count all useful things firewall can do. I can not count
(it is infinite) numbers of things it can not do.

In real life, protocol inspection is useful for SMTP and DNS. Sometimes, for
http (but not https), SIP, few other _open_ protocols. That's all.
Sometimes, it can recognize unusual behaviour of _your_ server and notify
you (esp. if you maintain _default deny_ for some protocols).

You are right about _checking outbound connections_ - firewall can help, if
properly configured. Unfortunately, you can spend days, configuring your
home firewall for outbound connections, even if you maintain a proxy. I do
not think, that you will do it for grandma...

You are right about possibility of weaknesses in some PNAT devices. This is
a very big potencial for a problem / holes here. I'd like to see such tests
you are talking about (security tests for PNAT devices).

5

> A good firewall *should* be doing a whole lot more than that. It should
Do not overestimate. Firewall can make a little more than just restrict
access and inspect few (very limited) protocols.

If this concerns you, just use a proxy instead of stateful inspection.
Even better, use both to leverage the speed of the packet filtering and
the application control of the proxy. Defense in-depth and all of that.

It can not protect you from slow scans;

If a firewall can't stop a scan because its slow, then the firewall is
broken. If you are talking about detecting a port scan, then its a
matter of how you parse the data. I can easily detect port scans as slow
as 1 port/4 hours with Netfilter. I can push this out to 1 port/week if
the source IP is on my "potentially hostile" list.

it can not protect you from SSL /
SSH / (any other encrypted protocol) volnurabilities,

All depends on what you need. For example if you want to inspect
payload, terminate the tunnel at the firewall or some external device
(like an SSL accelerator) and then run the payload through a reverse
proxy. If its outright blocking you want, just inspect for the initial
handshake and drop as required. You only need to check the first couple
of ACK's to do this correctly.

it can not protect your users from viruses in e-mail, etc etc.

I don't remember saying it would. What I do remember saying is that the
firewall could be used to help detect outbound activity if the internal
host becomes a zombie due to e-mail based viruses.

Very good level of details - 200 Mb of daily logs (IP, IP protocol = https).
Any network statistics system can do it. Unfortunately, all this logs are
99% useless until you need forensics.

I guess its a matter of what you do with them. I personally find my
firewall logs *very* useful and can ID a wide range of suspicious
activity, even a few that are payload based despite the fact that the
firewall does not log the payload. As for review time, 200 MB takes me
maybe 20 minutes with my parsing script unless I find something *really*
interesting that I want to drill in on. Then the time factor comes down
to when my obsessive compulsive personality will let it go. :wink:

But then again I'm one of *those* geeks that finds log review to be a
fun way to spend a week night. I expect if I found it to be more of a
chore I would also find them to be less than useful.

> perimeter. It should also be doing some level of content checking to
In reality, I can count all useful things firewall can do. I can not count
(it is infinite) numbers of things it can not do.

So basically your argument is "its good at some things but not others so
why bother?". Given that line of thinking, why bother with IDS because
it can't detect Ethernet CRC errors? Why bother running a virus scanner
because it can't keep your system patched. Why bother patching your
systems because that does not help add the fabric softener during the
rise cycle.

A firewall is a tool, no more no less. The capability of that tool is
90% dependent on the person wielding the tool. If you can only find a
limited number of applications for a firewall, I'm not surprised that
you don't find it all that useful. That does not mean the same is true
for the rest of us.

HTH,
C