Currently Being ModeratedMay 3, 2013 8:17 PM (in response to Gerben Wierda)
ALF is not a packet filter. It blocks executables, not ports. Add the executable to the whitelist.
Currently Being ModeratedMay 3, 2013 11:55 PM (in response to Linc Davis)
As I understand it, the firewall in OS X is an adaptive firewall based on packet filtering. One of the ways it is adaptive is that if an 'allowed' app starts listening to a port, that port is opened up in the firewall (roughly). Or, if a process is started as soon as a connection to a port is tried, at that time it is checked if the process is allowed to accept the connection (listen to the port).
In other words, as i understand it ALF makes use of the packet filter setup to adaptively accept connections for certain executables.
That system (packetfilter) or PF is rather poorly documented on OS X. And it must be possible to add just an open port to it.
Anyway, I am ok with another route as well. If I can find out which executable to add to ALF so that 'appleugcontrol' works. This is the application that handles the ssh-link that mobile home syncing uses when 'server-side file tracking' is turned on.
Currently Being ModeratedMay 4, 2013 8:30 AM (in response to Gerben Wierda)
The adaptive firewall in OS X Server is not the same as the application firewall. I don't know how they're related internally, but the configuration of one has no effect on the other.
You probably don't need the application firewall at all. It's useful when you have a portable computer that sometimes connects to a trusted network, where you want to provide services, and sometimes to untrusted networks, where you don't. Instead of turning the services on and off every time you change networks, you turn the firewall on and off.
Another scenario in which the application firewall might be used is when you're providing Bonjour services on dynamic ports, and for security reasons you want to make sure that the processes listening on those ports are the right ones.
If "appleugcontrol" is codesigned, then check the box to allow all signed software to receive connections. If not, you should be prompted to allow or deny connections when it tries to bind a port. The setting will be saved.
Currently Being ModeratedMay 4, 2013 2:47 PM (in response to Gerben Wierda)
Currently Being ModeratedMay 5, 2013 3:29 AM (in response to infinite vortex)
I read that article, but it is about afctl, which does nothing more than work as a (temporary) blacklist/whitelist creator in the real firewall for connections as a protection against brute force attacks. This is not going to help me as it has nothing to do with the application firewall.
What is really funny is that the help text from your link says it uses ipfw which is officially deprecated in OS X 10.8.
afctl was already there in 10.6, so it probably indeed interfaces with ipfw (or used to and now interfaces with PF and the documentation is out of date). [UPDATE: I checked inside Server.app and it seems indeed that afctl now interfaces with PF and not with ipfw. They forgot to update the docs]
I would really love to read a decent overview on the whole firewall setup in Mountain Lion Server
Currently Being ModeratedMay 5, 2013 5:06 AM (in response to Linc Davis)
Linc, thatnks for the reply. I dived into this a bit more and studied the setup of the ALF. I find it confusing, on the one hand it is mentioned in the packet filter firewall setup in /etc/pf.anchors/com.apple:
# Application Firewall anchor point.
OTOH, such an entry is nowhere to be found on my system and the ALF command socketfilterfw somehow seems to suggest it is a socket filter and not a packet filter and that it is indeed working at a different level, namely the level that decides which executable is allowed to listen on which socket (port).
I am trying to find out what program is being started when I connect to port 2336 (service appleugcontrol according to /etc/services) so I can enable it with socketfilterfw. But I can't find out which program I have to enable.
I can turn off my ALF altogether, but I am used to running a firewall on my system, even if it is behind a NAT and ports are not as easily reached from the outside. I want my internal network to have some security too. In the 10.6 days, that was ipfw. Now it is PF which is off by default. I tried IceFloor to manage the PF firewall (so I can turn the ALF off) but the result was negative. Whatever I put in the settings, it blocked about everything.
The reason I want to open this port is that without it server-side file tracking for mobile home sync does not work and mobile home syncing by clients becomes very slow. Server-side file tracking for mobile home syncing requires that the FileSyncAgent on the client is able to create a SSH connection to port 2336 on the server. But as it stands now, ALF is blocking that.
Currently Being ModeratedMay 5, 2013 6:03 AM (in response to Gerben Wierda)
Well, it has started working and I know partly why, but I am still in the dark about the specifics.
What happened was that at some point with the ALF turned off I did a reboot. Then, when I turned ALF on, I got the following panel:
After clicking "Allow" it works for now. Some funny bits though:
- The app can be found as /System/Library/CoreServices/FileSyncAgent.app/Contents/Resources/FileSyncAgent _sshd-keygen-wrapper (or so it seems)
- It is not listed in System Preferences nor with "socketfilterfw --listapps"
- You cannot add this app by hand in System Preferences to the ALF because it lives inside an app wrapper and you cannot navigate inside. You can also not navigate by typing /System/Library/CoreServices/FileSyncAgent.app/Contents/Resources when trying to select an app to allow.
So, the situation is that it works, but I have no idea why it works now and if that state of affairs is persistent and where this is stored.
I have a guess why it wasn't added before. I might not have been logged in at the server when I enabled server-side file tracking. As a result, I never got the 'allow' panel for FileSyncAgent's ssh.
Currently Being ModeratedMay 27, 2013 1:53 PM (in response to Gerben Wierda)
And three weeks later, mysteriously, it has stopped working again. With ALF on the Server turned on, server-side file tracking fails again. Trying when logged in to an administrator on the server does not give me the panel again, so I'm going to try to find out if I can set FileSyncAgent_sshd_keygen-wrapper to allowed from the CLI.
Currently Being ModeratedJun 15, 2013 12:55 AM (in response to Gerben Wierda)
sudo /usr/libexec/ApplicationFirewall/socketfilterfw -s /System/Library/CoreServices/FileSyncAgent.app/Contents/Resources/FileSyncAgent _sshd-keygen-wrappersudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /System/Library/CoreServices/FileSyncAgent.app/Contents/Resources/FileSyncAgent _sshd-keygen-wrapper
now it works (for now again).
vanroodewierda:~ sysbh$ /usr/libexec/ApplicationFirewall/socketfilterfw --listapps
ALF: total number of apps = 3
3 : /System/Library/CoreServices/FileSyncAgent.app/Contents/Resources/FileSyncAgent _sshd-keygen-wrapper
( Allow incoming connections )
Now I only have to wait until ALF drops it again for some reason
Currently Being ModeratedJun 20, 2013 6:03 AM (in response to Gerben Wierda)
It worked, until I logged the system administrator out form the server. There is something fishy going on here. When th esystem administrator is logged in, ALF passes the ssh stuff for the FileSyncAgent, but when nobody is logged in, home syncing progresses without server-side file tracking info.