Tiny Deathstars of Foulness

OS X Server 5 (El Capitan 10.11 or Yosemite 10.10) has an adaptive firewall built in, or a firewall that controls incoming access based on clients attempting to abuse the server. The firewall automatically blocks incoming connections that it considers to be dangerous. For example, if a client attempts too many incorrect logins then a firewall rule restricts that user from attempting to communicate with the server for 15 minutes. If you’re troubleshooting and you accidentally tripped up one of these rules then it can be a bit frustrating. Which is why Apple gives us afctl, a tool that interacts with the adaptive firewall.

The most basic task you can do with the firewall is to disable all of the existing rules. To do so, simply run afctl (all afctl options require sudo) with a -d option:

/Applications/ -d

When run, the adaptive firewall’s rules are disabled. To re-enable them, use the -e option:

/Applications/ -e

Turning off the rules seems a bit much for most troubleshooting tasks. To remove a specific IP address that has been blacklisted, use the -r option followed by the IP address (rules are enforced by IP):

/Applications/ -r

To add an IP to the blacklist, use the -a option, also followed by the IP:

/Applications/ -a

To permanently add a machine to the whitelist, use -w with the IP:

/Applications/ -w

And to remove a machine, use -x. To understand what is going on under the hood, consider this. The blacklisted computers are stored in plain text in /var/db/af/blacklist and the whitelisted computers are stored in the same path in a file called whitelist. The afctl binary itself is stored in /usr/libexec/afctl and the service is enabled by /System/LIbrary/LaunchDaemons/, meaning to stop the service outright, use launchctl:

launchctl unload


The configuration file for afctl is at /etc/af.plist. Here you can change the path to the blacklist and whitelist files, change the interval with which it is run, etc. Overall, the adaptive firewall is a nice little tool for Mac OS X Server security, but also something a number of open source tools can do as well. But for something built-in and easy, worth using.

There’s a nice little command called hb_summary located in /Applications/ that provides statistics for blocked hosts. To see statistics about how much the Adaptive Firewall is being used, just run the command with no options:


The output provides the following information (helpful if plugging this information into a tool like Splunk):

  • Date
  • Date statistics start
  • Number of hosts blocked
  • Addresses blocked
  • Number of times each address was blocked
  • Last time a host was blocked
  • Total number of times a block was issued

September 22nd, 2015

Posted In: Mac OS X Server

Tags: , , , , , , ,

Mountain Lion Server is now available on the OS X App Store and as with the last few updates there are some things missing that you might be expecting and depending on. First up, three major services are gone: Podcast Producer, RADIUS and dhcp. You can still do dhcp as you always did with OS X client as those features work on OS X Server, but the more granular controls available in OS X Server are now gone. The biggest impact of dhcp is probably in testing NetBoot services when there are network issues and you need to prove to network admins that it’s the network and not your server…

I had written an article before about FTP still being in OS X Server from the command line, but now it’s back in the GUI, which should make many an administrator happy. NAT is also gone from the GUI, but natd and natutil are still available from the command line. Might as well just use the Sharing System Preference pane for such things though… Server Admin is now gone (long live Server Admin!) and Workgroup Manager is now a download to be performed and installed following installation. Support for Managed Preferences is gone, even though most manifests technically still work.

Many services also got some pretty nice updates. These include:

  • Calendar – There are a few updates on the client side, but not on the server side. Most notably, the option to publish calendars is now gone. If you used that, it’s time to get used to manually exporting, copying to a share and then distributing links. This is going to likely cause more use of the Calendar server itself, to some degree. Also, it’s not iCal or iCal Server, it’s now Calendar and Calendar server. Seems to me that this isn’t obviously an Apple-centric naming structure as with most other things they do, but sometimes you’re gonna’ have that…
  • Contacts – Nope, it’s not called Address Book server, it’s the Contacts service. Same with the client side application.
  • DNS – DNS management is moved into the Server application. You can also now restrict who you do lookups for in the GUI. Under the hood very little changes.
  • File Sharing – Nothing really changes with file sharing, except the wiki integration described in the Wiki section in a little bit.
  • Firewall – The firewall option is gone, as is the ipfilter at the command line, but pf is easy to configure from the command line.
  • FTP – It’s a quick and easy single share solution from the GUI. Using the sharing command there’s still tons available to administrators.
  • Mail – Authentication mechanisms and domains are in the GUI, but very little changes otherwise.
  • Messages – The service name has changed from iChat to Messages in the GUI but is still jabber from the command line. The big change with this service is that the client side is now able to leverage iCloud to instant message mobile devices as well. Therefore, the text messaging component is client-side and has no impact on the jabber service itself.
  • NetInstall – The “NetInstall” service is NetBoot. It can host NetRestore or NetInstall images, but the heavy lifting for that stuff is done in System Image Utility. And the output of the SIU commands are now more scriptable through the automator command line interface. The NetInstall screen is now in Server app and is a good port from Server Admin in that it’s similar in look and feel to the NetBoot screen in Server Admin. A feature that isn’t in the GUI is diskless NetBoot, which is fine because I documented how to do it when I realized it would be an issue for a few customers.
  • Open Directory – Given that Server Admin is gone, something had to happen with Open Directory. The Open Directory screens have been moved to Server app where it’s fast to setup and tear down Open Directory. Open Directory based Users and Groups are also created through the Server App, although Workgroup Manager can be downloaded and used still. Immediately following upgrades, the add and remove users buttons are gone for previously stand-alone hosts. Also the Manage Network Accounts option is now gone from Server app, replaced with the traditional ON button supplied by Apple for other services.
  • Profile Manager – This deserves its own post, which is in the queue, but suffice it to say that while you can’t tell when looking in Server app, there are a number of upgrades to Profile Manager.
  • Software Update – Management of the service is moved from Server Admin to Server app. There are now fewer options in the GUI, but the same in the command line. Cascading is a little different.
  • Time Machine – Time Machine server is the same… The versions option from the Time Machine Server preference pane is gone and the layout is a little changed, but the server component is identical in functionality as well as look and feel.
  • VPN – Unless you add another supported VPN protocol there’s not much to do after fixing most issues in 10.7.4. Except fixing the last issue with search bases, seemingly resolved as it’s working for me pretty well.
  • Websites – There are more options in the GUI for new sites. The default site appears twice (once for 80 and once for 443), but there are more options, such as the Web App functionality that comes with a default Python “Hello World” app. Also the server is still called web from the serveradmin command line, but is now called Websites through the GUI.
  • Wiki – The wiki has themes again, although they’re just color schemes. And you can create your own custom banners and upload, which brings back two of the most common feature requests from people that hack the look and feel of the wiki in versions previous to Lion. But the most substantial aspect of the Wiki to change to me is the document management options, available to users in WebDAV or through the portal. This allows for a very mobile-friendly file management tool. Blogs and wikis for the most part stay the same and have a very clean upgrade process from Lion. The command line tools also feature some new options for indexing, etc., which many will find helpful.
  • Xsan – cvadmin, cvlabel, cvversions, etc are now stored in /System/Library/Filesystems/acfs.fs/Contents/bin/ and Xsan has its own entry in the Server app. Despite hearing people question its future, I’ve never seen as many questions flying around about how to do things with Xsan than I do now. Storage sales are up, monkey chatter on the web is up, deployments are being booked and Xsan looks here to stay. The Server app only really shows you a status of things, but the Xsan Admin app is now embedded in the Server app and available through the Server app Tools directory.

Configuring Websites in Server app

The Alerts options are much more robust in Mountain Lion than they were previously. You  can now get alerts on a myriad of things, incuding certs, disks, space, storage quotas, virus detection, network changes and software updates.

Configuring Alerts in Mountain Lion Server

The Server commands also moved and in fact the whole file and folder structure mostly fit nicely inside of the Server app. There are certain things that haven’t been dealt with in this regard such as NetBoot’s library, but for the most part Apple is getting Server to the point where it’s very self-contained. The ramification of which is that upgrades for future releases (and from Lion to Mountain Lion for that matter) are much simpler. Simply downloading a new version informs administrators that the app has been replaced and is good to go, service data in tact. In real world, this has been a little hit or miss but should prove to make our lives much easier in the future.

Reducing scope, aligning with better development practices and all the work to merge all of the remaining services into Server app are huge undertakings. I would fully expect no further support or updates to Workgroup Manager, no more testing of managed preferences in deference to profiles and a few other culture shifts that still need to shake themselves out. Most of us are going to seem underwhelmed (if that’s a word, no it’s not ’cause I looked it up -> awesome video below –> ’cause affection has 2 fs, especially when you’re dealin’ with me). But here’s the thing, with an incremental update, you’re not going to get massive changes. Instead we will get slow and steady updates hopefully continuing to build faster towards a better end goal. What’s important is that the foundation is actually better now, given changes to other parts of OS X and so Server is likely now better positioned than ever for great new features in subsequent releases.

Oh, and did I forget to mention that Xgrid is gone. I guess no one really noticed anyway…

July 26th, 2012

Posted In: Mac OS X Server

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

I’ve done plenty of writing on the Application Layer Firewall (ALF) and the IP FireWall (IPFW) in OS X over the years. There will be more on ALF coming in “July” but in the meantime, there’s something I hadn’t written much about in Lion and that’s the pf implementation.

To get started, let’s look at the /etc/pf.conf configuration file that comprises pf:

scrub-anchor "*"
nat-anchor "*"
rdr-anchor "*"
dummynet-anchor "*"
anchor "*"
load anchor "" from "/etc/pf.anchors/"

Here, you can see that pf is configured with a number of anchors. An anchor is a collection of rules and tables. Basically, the anchor file being loaded is /etc/pf.anchors/ In here, we see some rules (without comments):

scrub-anchor "100.InternetSharing/*"
scrub-anchor "300.NetworkLinkConditioner/*"
nat-anchor "100.InternetSharing/*"
rdr-anchor "100.InternetSharing/*"
anchor "100.InternetSharing/*"
anchor "200.AirDrop/*"
anchor "250.ApplicationFirewall/*"
dummynet-anchor "300.NetworkLinkConditioner/*"
anchor "300.NetworkLinkConditioner/*"
anchor "400.AdaptiveFirewall/*"
load anchor "400.AdaptiveFirewall/" from "/Applications/"

These are mostly just allowing the Apple services to work with services enabled in the Sharing system preference pane, etc. The scrub options are pretty cool as it cleans dirty packets prior to passing them to their destination. To see how the rules are interpreted, let’s run pfctl with the -sa option, which shows all information/stats:

sudo pfctl -sa

Here we see information like stats on timeouts, limits to rules, etc. Let’s look at the rules specifically:

sudo pfctl -sr

Now let’s load a line below the previously called anchors in the first file:

pass in quick on lo0 all
pass out quick on lo0 all

This is going to always allow local traffic, which we need for a few internal processes. Then let’s block some stuff (after all, if we’re not filtering, why use a packet filter). First add the following to the pf.conf file to block all otherwise allowed incoming sockets:

block in all

And this one for outbound traffic:

block out all

Or to knock the two above lines out with one:

block all

Then to do something pretty straight forward, like allow incoming icmp traffic for en0:

pass in quick on en0 proto icmp

One more rule, to show how we’re going to pass and log data for data coming into en0 for both tcp and udp from anyone to the IP on that interface running for port 548:

pass in log quick on en0 proto { tcp, udp } from any to port 548 keep state

Of the above, tables allow you to define ranges and basically alias IPs. Anything in this section of pf.conf in angled (<>) brackets is a table that has been defined. You can also build a list, which allows multiple criteria to be defined for a given rule and macros, which are essentially arrays of IPs, ports, etc, designed to reduce the amount of typing you have to do if you’re building out a big configuration file. Once we’ve edited our configuration file, let’s run a quick sanity check on it:

sudo pfctl -v -n -f /etc/pf.conf

Now, provided we don’t get any crazy errors, let’s load pf with our rules (which also loads the anchors):

sudo pfctl -f /etc/pf.conf

Then let’s set pf to be verbose while we’re testing (we’ll turn it off later):

sudo pfctl -v

Then let’s enable pf:

sudo pfctl -e

The return code should be something along the lines of the following:

pf enabled

You can also add information on the fly. For example, to add a table of call localsub:

sudo pfctl -t localsub -T add

If you want to flush your rules later:

sudo pfctl -Fa -f /etc/pf.conf

To clear your stats:

sudo pfctl -z ; pfctl -si

Once we feel good about the pf configuration, set it to be quiet to keep the logs small and make it a little quicker:

sudo pfctl -q

And to disable pfctl when you’re done tinkeratin’:

sudo pfctl -d

And to watch what it’s doing:

ifconfig pflog0

Followed by

sudo tcpdump -v -n -e -ttt -i pflog0

Overall, pfctl is pretty straight forward to use. There is a really good post (thanks to @sacrilicious for pointing it out) at for syncing the Emerging Threats anchor from And of course, OpenBSDs pf page is the best source of information on the project, available here. There are a few limitations. The pf command is limited to one processor, so running a dedicated pf host on an 8 core machine is pretty much overkill. RAM is important as pf doesn’t use swap space. The more you pay for a card, the better a card you get, for the most part. Check out the Small Tree cards as they’re pretty efficient…

A few things I haven’t gotten working, the logging is kinda’ wonky. The antispoof protection seems odd (see the antispoof docs on the pf page), osfp (which might be other devices in my walled garden) and dummynet integration (which I have working w/ ipfw)… If I can get them working I’ll put together another post for that in my infinite amounts of free time. I also didn’t end up figuring out the upper limit for packets/rule lookups/table lookups per second… As I write more efficient tables I do more lookups and can therefore process packets faster. It’s annoying when I realize ***I*** am the bottleneck…

July 2nd, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , ,