Re: [Fed-Talk] Firewall
Re: [Fed-Talk] Firewall
- Subject: Re: [Fed-Talk] Firewall
- From: Boyd Fletcher <email@hidden>
- Date: Thu, 10 Apr 2008 00:31:17 -0400
- Thread-topic: [Fed-Talk] Firewall
On 4/8/08 5:17 PM, "Boyd Fletcher" <email@hidden> wrote:
>
>
>
> On 4/8/08 9:59 AM, "Michael" <email@hidden> wrote:
>
>> 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.
I understand them quite well. We use a considerable number of "non-native"
mac apps (i.e. unix apps) and being able to explicitly set ports and
protocols is much better. the 10.5 doesn't work with "non-native" apps.
>>
>> 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).
that is not a flaw in the GUI design that is a flaw in the implementation of
configuration of ipfw by the GUI app.
>> 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".
>>
interesting info, but again this is not a flaw in the design of the GUI its
a flaw in how the application implemented the firewall rules.
>> 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.
>>
my point is that you should not have to install a 3rd party app to configure
the firewall. apple should provide a suitable GUI that let's you do it.
I think a combination of the old flexible but more complex approach with the
new app approach would meet most users needs.
in the current approach I have to write a bunch of ipfw rules by hand and I
really have better things to be doing than writing firewall policies for my
boxes.
>> 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
_______________________________________________
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