Re: [Fed-Talk] Firewall
Re: [Fed-Talk] Firewall
- Subject: Re: [Fed-Talk] Firewall
- From: Michael <email@hidden>
- Date: Tue, 8 Apr 2008 09:59:53 -0400
On Apr 7, 2008, at 10:46 PM, Todd Heberlein wrote:
On Apr 7, 2008, at 7:38 PM, Boyd Fletcher wrote:
unfortunately Apple chose to degrade the firewall capability in
leopard from
the much better one in Tiger. I wish they would put back the port and
protocol setting capability instead of having to do it by hand
which is not
very user friendly :(
Everything is still there, it just isn't as easy to get to. I
suspect there already are free GUI-based applications to control the
packet-centric firewall system in Leopard.
Apple, for its GUI-controlled firewall, went to an application-
centric approach in which, as far as I can tell, the OS enforces
network activity at the system call level instead of the packet
level. They claim that it is easier for novices to use, but for
someone who has spent years and years configuring access based on
protocols, addresses, and ports, the Apple approach makes me
uncomfortable. It has taken me out of my comfort zone.
If you liked the GUI Firewall in OS X 10.3 and 10.4 then you didn't
understand how big the holes in it were. To deal with those holes you
either did by hand which you can still do in 10.5 or you used a third-
party GUI program to configure ipfw, i.e. Brickhouse. There is no
reason those programs shouldn't still work.
First flaw in the GUI version was that it didn't even enable the
stateful aspect of ipfw (actually ipfw2 in 10.4). Stateful means only
permit incoming packets in that match previously sent outgoing packets
for both tcp and udp (also for icmp). Unfortunately the stateful
aspect of ipfw2 is a bit buggy in that it manages to block some
packets that clearly have matching temporary rules for them, i.e.
temporary rules are created when a packet goes out (funny ipfw in 10.3
was better in that respect, not sure if this flaw still exists in
10.5.2's ipfw2, I stopped looking and learned to live with it).
Fortunately that was not too big of a problem as tcp packets get sent
again and udp packets are not required to all be received in a
properly designed program. At work this has not been much of an issue.
To get around that flaw the GUI Firewall permitted virtually all
incoming udp packets, so any program on your machine could listen on a
udp port and receive network traffic without your knowledge. The tcp
ports were tied down a bit better, I forget if there were any specific
flaws there. A number of critiques of the previous GUI Firewall exist
on the web, some are actually even correct, none are complete.
Just to take the simplest example, you install Office 2004, you launch
Word, Excel, and PowerPoint. First off all three applications just
broadcast onto the network via udp port 2222 and you also have three
udp ports open and listening to the network -- and in the first
release of Office 2004 you also had a remote exploit for those
servers. Anything that listens and responds to the network is a
server. If you write a ipfw rule to log incoming udp port 2222
packets you can identify every machine running Office 2004 on your
local network assuming the admin didn't either write a ipfw rule or
use a third-party product deal with those packets.
When dealing with some of these applications and OS X programs that
want to chat out onto the network you can't just block them all
directly or some of them get very unhappy and generate massive numbers
of errors, the trick there is to use a rule of the form "fwd 127.0.0.1
udp from me to any 2222 out". mdns is another one of the programs I
have issue with, if I don't want Bonjour traffic I have several rules
of the form "fwd 127.0.0.1 udp from me to 224.0.0.251 out".
That said it is extremely difficult to configure a firewall for
everyone. The closest I have seen to a workable solution is where
when you install a program that program's installer asks the operating
system if it can open holes in the firewall for specific outgoing and
incoming tcp & udp port ranges for it and only it and then the
operating system asks you -- you have that in Windows XP SP2 based on
my experience, but it took a while before the developers added the
support into their installers and I don't know the flaws in the XP
design.
The application based Firewall in 10.5 and programs like Little Snitch
are mostly workable in a work environment but not a home environment
were you have games that take over the full screen. In my experience
even when turned off Little Snitch blocks some local traffic thereby
disabling some game functions and a few OS X functions that I tried to
use in a work environment (trying to analyze the flaws for a bug
report started taking all my time and I had to stop). I have not had
experience with NetBarrierX but no software is perfect, only issue is
whether or not the flaws/features affect you.
Personally I'd recommend the OS X 10.5 application based firewall at
the highest level backed up by the ipfw firewall configured by a third-
party app if hand editing rules is too much for you. Or pick your
favorite third party application based firewall.
If you want to learn about the incoming and outgoing traffic on your
machine, I'd learn the basic ipfw rules syntax, turn on logging for
all packets and then while watching the logs (tail -f) create rules to
not log the traffic you want to permit and not log the traffic you
definitely want to block. Obviously this is not for everyone, but if
you want to learn there is no substitute for real practice. If you
are studying a full screen program, typically games, then you need to
ssh into your machine from another machine and then write a rule to
not log the traffic for that ssh connection.
Also you can learn a bit about your machine using "sudo lsof -i -P" to
learn about all currently open ports but some of those are local
only. If you disable your firewall and launch all programs and turn
on any server type functions in them (iTunes, iPhoto, games, Adobe
products) and then use another machine to scan your machine using nmap
with a complete 0-65535 scan in udp and tcp you can get a good idea
what ports are open.
Of course keeping good notes is important and that is where I tend to
fall behind.
Michael
ps. there are about 100 lines in my custom ipfw firewall for work, I
restrict outgoing and incoming traffic based on what I know I need,
even then I have a couple remaining issues that I have not had time to
iron out, mostly with Zeroconif/Bonjour traffic -- seems that I have
not grouped all the related rules so that I can turn that traffic on
and off as usually I don't need most of it. For debugging an issue I
disable my hand written firewall and see if the problem remains,
usually is does.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden