A different kind of firewall
A different kind of firewall
- Subject: A different kind of firewall
- From: "Peter Sichel" <email@hidden>
- Date: Wed, 3 Sep 2003 16:57:34 -0400
On Sep 3, 2003, at 2:10 PM, Joshua Graessley <email@hidden> wrote:
>
I'm not suggesting that everyone should buy a firewall. My point is
>
that a personal firewall is worse than no firewall. Developers
>
constantly ask about how they can figure out if their product will work
>
when the personal firewall is enabled. This implies that a personal
>
firewall breaks legitimate products.
Or more accurately, taking a firewall that was originally designed
to protect UNIX servers, slapping a GUI on it, and calling that
a "personal firewall" was not such a great idea.
>
It is not clear that any benefit is derived from having a personal
>
firewall.
From my perspective, there are lots of benefits that can be derived from
having a personal firewall but UNIX ipfw doesn't provide many.
A firewall is typically used to: (1) Limit outside access to certain
users or services; (2) Block unwanted or harmful traffic that could
disrupt network services; (3) Keep a record or log of interesting
network events including possible threats or inappropriate traffic;
and (4) do all this without interfering with normal use.
Apple's current implementation is weak at (1), (2), and (3),
and fails at (4). The basic approach of blocking all inbound ports
except those services explicitly authorized might be appropriate
for a dedicated server, but is lousy for a personal computer
network client or "digital hub".
In fairness to Apple, this first effort was more of a selling
point than aimed at the real needs of network users and administrators.
>
It seems the right way to solve this problem is to use the
>
authorization framework and require authorization for operations such
>
as bind, connect, sendto, etc. Instead of filtering at the packet layer
>
on the local machine, which is fraught with problems, including no
>
feedback to applications, filter at the API layer. If a customer is
>
worried about traffic to and from their machine, a setting could be
>
modified to require authorization to open an outbound connection or
>
incoming connection. A user could choose to always allow certain
>
applications to perform these operations. The authorization framework
>
already has functionality for most of this. It wouldn't necessary
>
require typing a password, just the user accepting the applications
>
request to perform a network operation.
Notice that filtering at the DLIL interface layer is the most consistent
way to examine all network traffic. Filtering at the protocol
or socket API layer does not support Classic applications or forwarded
traffic if the machine is being used as a NAT gateway. [That's not
to say these techniques aren't also useful.]
The issue of "poor feedback" is just as big or bigger for external
firewall devices. I've written more about "a different kind of
firewall" here:
<
http://www.sustworks.com/site/prod_sentryx_overview.html>
<
http://www.sustworks.com/site/prod_sentryx_appnotes.html>
In the real world, undesirable traffic can and does occur.
A firewall can be a useful tool for detecting and dealing with it.
How does this relate to Mac Programming?
Before defining a firewall API or writing off personal
firewalls completely, it would be good to consider what
problems they are trying to solve.
- Peter
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.