Firewall settings and MCX

[knowmad]

A buddy of mine asked me about this and my answer does not seem to have worked.
Is there a tested/proven way to set the firewall using MCX? I suggested pulling the appropriate Plists into workgroup manager and working with them there.
That apparently did not work.
So… anyone got experience with this? (Gneagle?)
knowmad

fyi the settings can be done as a one-off during build with the[code]
#change status of the firewall: 0=off 1=on for specific services and 2=on for essential services
sudo defaults write /Library/Preferences/com.apple.alf globalstate -int 1[/code] routine.

[tecnobabble]

knowmad beat me to it. But he’s right.

I’m importing the com.apple.alf.plist into Workgroup Manager and setting the following:

globalstate 1
loggingenabled 1
stealthenabled 1

They just don’t seem to have any effect on reboot; all the other mcx settings run fine.

Thought it might be something to do with the lack of an -int in the normal defaults write and that the system starts the firewall before the mcx settings are placed, but then you’d figure that it’d work after a second reboot.

Nada.

Thoughts?

p.s. I took the leap into mcx about 18 hours ago, and have not slept since… so bear with me.

[Patrick Fergus]

There are two firewalls in Leopard. The GUI-exposed “Application Firewall” and the non-GUI ipfw. “on for specific services” will likely be a problem if your users aren’t admins (Entourage, for example, tries to listen on a UDP port to hear when it receives new mail) because the user is going to be prompted occasionally to allow or deny apps. “on for essential services” would have to be highly tested (Apple [url=http://support.apple.com/kb/HT1810]says[/url] only configd, mDNSResponder, and racoon have outside access for that setting).

You may want to look at the discussion of ipfw in [url=http://images.apple.com/server/macosx/docs/Leopard_Security_Config_2nd_Ed.pdf]here[/url].

– Patrick

[tecnobabble]

Right, I know about the ipfw, the issue is that we need the application firewall due to the client management software that we’re running (or soon will be) on the machine. It depends on the signed app being recognized.

So any thoughts on why the com.apple.alf prefs aren’t being read? They’re being written, but don’t look like they’re enabled in the GUI, and from the limited testing, aren’t actually on. So the gui is reflecting what’s actually on the machine (no change to firewall on/off/limited, no loggining, no stealth), but the prefs show that all of it is turned on.

[Patrick Fergus]

Grasping at straws, but you may have an order of operations problem. MCX might be loading after socketfilterfw, causing your MCX setting to not be read because socketfilterfw is already running. But, I’m not an expert in this part of OS X.

What happens if you try the following:[code]sudo defaults read /Library/Preferences/com.apple.alf globalstate[/code]Does it return the desired setting? If it does, try:[code]sudo /usr/libexec/ApplicationFirewall/socketfilterfw -k[/code]and see if the firewall behaves as expected ([url=http://www.testplant.com/downloads/]Vine Server[/url] is a good simple test to see if the Application Firewall is paying attention).

If the Application Firewall appears to have the right setting (the first command above), but isn’t honoring the setting until you run the second command (restarting the firewall daemon) you probably need to set the firewall setting when you create your InstaDMG image instead of using MCX.

Love to be proved wrong though.

– Patrick

[tecnobabble]

So I have a kinda solution to this.

Using MCX, create a logout script that writes:

defaults write /Library/Preferences/com.apple.alf globalstate 1

this will ensure that it’s on when the system boots and before any users login. I’m getting mixed results with the other firewalls settings (stealthmode and enablelogging) and putting it in a login hook, but will report back later.

[aaronwyatt]

I am having the same problem (but didn’t realize it until I read this post, ironically).

So, for some reason, the global application firewall prefs are kept in /usr/libexec/ApplicationFirewall/com.apple.alf.plist.

The following solution works and holds between reboots:

[code]
/usr/bin/defaults write /Library/Preferences/com.apple.alf globalstate 1
/usr/bin/defaults write /usr/libexec/ApplicationFirewall/com.apple.alf globalstate 1
[/code]

aaron

[tecnobabble]

I’m not sure about the prefs sitting in /usr, there is a entry in there to read the old prefs, my guess is that it’s just reading the /Library/Preferences/com.apple.alf plist.

Speaking of which, I’m going crazy. I swear none of this worked over the past 3-4 weeks.

Adding the following to my logout hook works; but only reliably (I think, starting to imagine gremlins inside the OS) if you enable the firewall last.

[code]defaults write /Library/Preferences/com.apple.alf loggingenabled -int 1
defaults write /Library/Preferences/com.apple.alf stealthenabled -int 1
defaults write /Library/Preferences/com.apple.alf globalstate -int 1[/code]

I’m so confused, but it works so… 😛

[aaronwyatt]

[QUOTE][u]Quote by: tecnobabble[/u][p]I’m not sure about the prefs sitting in /usr, there is a entry in there to read the old prefs, my guess is that it’s just reading the /Library/Preferences/com.apple.alf plist.
[/p][/QUOTE]

i’m not sure about the prefs in /usr either (as in, “why are you breaking convention with your prefs Mr. Alf?”) but if you change the globalstate boolean in that plist, it fixes the issue and holds between reboots.

aaron

[Patrick Fergus]

I have a hazy recollection when messing with the Application Firewall (before I just decided to go with ipfw) that /usr/libexec/ApplicationFirewall/com.apple.alf.plist is the default set of Firewall preferences. In some situations (usually when you’re trying to mix CLI and GUI configuring-s of the firewall) I discovered that OS X overwrote the active set of preferences with the defaults for some usually logical reason that wasn’t entirely obvious when poking via the CLI. Unfortunately specifics escape me right now.

You may wish to try bouncing the firewall after configuring it or do your edits in the order of 1) disable, 2) configure, 3) enable. While the options are there to [i]configure[/i] the firewall via the CLI, I’d guess the GUI or some other process is stomping on your changes. You probably could set the Firewall options at InstaDMG runtime too.

Additional reading:

[url=http://images.apple.com/server/macosx/docs/Leopard_Security_Config_2nd_Ed.pdf]Leopard Security Configuration, Second Edition[/url]
[url=http://krypted.com/?p=3433]Command Line ALF on Mac OS X[/url]

– Patrick

P.S. If all else fails, blame [url=http://www.imdb.com/title/tt0090390/]an 80s TV star[/url].

[aaronwyatt]

Patrick-

I tried your suggestion: “You may wish to try bouncing the firewall after configuring it or do your edits in the order of 1) disable, 2) configure, 3) enable. ”

If you disable ALF, then only make edits to /Library/Preferences/com.apple.alf.plist, then reenable ALF, the settings get switched back to whatever is in /usr/libexec/ApplicationFirewall/com.apple.alf.plist and whatever you set in the /Library/Preferences/com.apple.alf.plist is reset (or at least, not applied).

I think you’re right about your first statement. There’s something disconnected between what the GUI is doing and what we expect on the CLI. What I don’t get is that when i manually set the firewall settings in the GUI, they stick. I’ve even done this while running fseventer and the ONLY file that gets modified is our standard /Library/Preferences/com.apple.alf.plist AND this holds between reboots.

[tecnobabble]

So, I’ve been up to my ears in white papers and documentation and from the Apple Leopard Security doc linked a few posts above, it has an appendix ( B ) with security scripts in it.

They list:

[code]defaults write /Library/Preferences/com.apple.alf loggingenabled 1
defaults write /Library/Preferences/com.apple.alf stealthenabled 1
defaults write /Library/Preferences/com.apple.alf globalstate -int 1[/code]

as the proper way to do it.

Enabling this in ONLY the logout script seems to hold between reboots etc. Through MCX there appears to be an issue of it reseting to the defaults if done via plist editing (on any setting, once, often or always) or in a login script.

My guess is that if you did something like:

To Stop:
[code]launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist[/code]

To start:
[code]launchctl load /System/Library/LaunchDaemons/com.apple.alf.agent.plist
launchctl load /System/Library/LaunchAgents/com.apple.alf.useragent.plist[/code]

Then we could get it to make those changes on login/logout and set those launch daemon/agent plists via MCX…

Though, in theory, a logout script makes sense though, because you’d want the machine to be protected on startup and sitting at login too; couple this with disabling fast user switching and you’re set. … right? 😀

Just don’t let your user’s be Admins, right knowmad?

[aaronwyatt]

I see what you mean, but this doesn’t address the fact that editing the plist will not hold a setting between reboots unless you re-enable each time you logout.

[Patrick Fergus]

I think the “disconnect” between the GUI and the CLI may arise because the firewall may be writing out its current configuration when it is quit. Mac admins who have been doing this too long may remember that OS 9 versions of Office and IE would compete for preferences in the same way. You could:

– Launch Entourage and IE
– Change IE prefs
– Quit IE
– Relaunch IE, prefs were still there
– Finish using IE, quit IE
– Quit Entourage
– Launch IE, prefs are gone

The solution there was to only have one of the apps running at a time when tweaking preferences. The solution here is to [i]not[/i] let the firewall daemon successfully write its prefs on exit. The following command:[code]sudo /usr/libexec/ApplicationFirewall/socketfilterfw -h[/code]will spit out options for socketfilterfw, which is the process that acts as Leopard’s firewall. Of interest is “-k”, which will “kill daemon” (launchd will fire it back up). On my computer, I just did the following:[code]sudo defaults write /Library/Preferences/com.apple.alf globalstate -int 1
sudo /usr/libexec/ApplicationFirewall/socketfilterfw -k[/code]I then visited Activity Monitor and observed that the “socketfilterfw” process now had a very large PID (70000+) when it usually has a PID (<100) at OS X startup. I then restarted my computer, visited the Firewall tab of the Security Preference Pane, and observed the firewall was set for "Set access for specific services and applications". It should hopefully work for you as well.

One more thing to circle this back to InstaDMG--killing socketfilterfw's daemon would not be necessary if the firewall settings were baked into the image at InstaDMG runtime. A payload-free CustomPKG that postflights the following:[code]#!/bin/bash

/usr/bin/defaults write "$3"/Library/Preferences/com.apple.alf loggingenabled 1
/usr/bin/defaults write "$3"/Library/Preferences/com.apple.alf stealthenabled 1
/usr/bin/defaults write "$3"/Library/Preferences/com.apple.alf globalstate -int 1[/code]Should turn on the Leopard firewall on a freshly imaged machine.

- Patrick

[Author]

Posts