Mac OS X Packet Filter and Adaptive Firewall
Although in years gone by, Apple’s adaptive firewall implementation was widely derided for incorrect counting of failed SSH login attempts — which could result in legitimate users being banned far more quickly than expected — most or all of these problems are behind it now. It’s hard to think of a reason not to use it.
If your server is exposed to the world, as it will be if you’re hosting publicly available websites, it’s probably worth planning early on to enable OS X Server’s adaptive firewall. It can save you from the otherwise steady onslaught of hacking attempts — in my experience, sometimes scores per second — emanating from botnets and every script kiddie with a laptop this side of the Urals (or the other side of the Urals, I guess).
Apple provides two knowledgebase documents with the basics, but these are just the tip of the iceberg:
What’s happening here is actually two different things. You are both enabling the packet filter pf
— the more modern successor to the venerable ipfw
— which is controlled with pfctl
, and enabling the adaptive firewall, which is controlled with afctl
. You can check the man page for afctl
to learn more about quickly adding or removing hosts from the blacklist. Using an example taken straight from the man page, to add 69.23.0.45 to the blacklist for at least 35 minutes:
/usr/libexec/afctl -a 69.23.0.45 -t 35
Except that to reach the Server version, we need to make this:
sudo /Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -a 69.23.0.45 -t 35
Back to the instructions which Apple provides for enabling the adaptive firewall and then fixing the rules problem; there are two extra things to know… First, there’s no need to panic when you see the following warnings, as these are normal:
No ALTQ support in kernel
ALTQ related functions disabled
But even more importantly for some people — and a long exercise in frustration if you happen to be me — is that if you have ever run the third-party pf
front-end IceFloor, and you have used IceFloor to switch pf
on and then off again, then as far as I can tell, IceFloor does not restore your system to the same state in which it began. Let me say that again, because it cost me hours: turning pf
on and then off again using IceFloor changes your system. Specifically, it removes lines from the com.apple
anchor set stored in /etc/pf.anchors/com.apple
. Among other things, like a complete inability to block brute-force attacks against your machine, this will make it impossible to apply the fix described in the second Apple document above — because the relevant lines in the file are gone. Note that I was using the version of IceFloor which was current at the time (1.2), but the software has been updated since then. I have no idea whether this occurs in later versions, or even whether it occurs consistently with the version I was using at the time; I can say only that it did occur.
Fortunately, in my case I was able to recover these botched files using Time Machine, but tracking down exactly what went wrong and when and why — with the help of logs showing the exact times and dates of pf
activity when I had briefly used IceFloor — was far more hassle than it should have been.
With the adaptive firewall enabled — and any necessary fixes applied — you should see a marked change in the data recorded to your logs about brute force attacks. Whereas before I was seeing hundreds of attempts per minute, enabling the firewall brought immediate relief, with offending hosts routinely barred for 15 minutes (and barred correctly, not just thousands of emond
log lines repeatedly saying the same host would be blocked without any corresponding afctl
lines saying it had been blocked).
You can see the results of ongoing blacklistings at /var/db/af/blacklist
.
In addition, you can get a summary of afctl
activity via:
sudo /Applications/Server.app/Contents/ServerRoot/usr/libexec/hb_summary
Finally, if you’re planning to provide VPN services from your OS X Server, you may need to dig a little deeper into pf
‘s innards and edit some rules for NAT and internal routing to keep everything running smoothly. There are pages upon pages of information about there about configuring pf
, but it’s beyond the scope of this article.
All material on this site is carefully reviewed, but its accuracy cannot be guaranteed, and some suggestions offered here might just be silly ideas. For best results, please do your own checking and verifying. This specific article was last reviewed or updated by Greg on .