Recently I have been tasked with expanding the firewall on OS X. By default the Application firewall is enabled on most devices as a standard safety procedure. Nothing is wrong with the Application firewall Apple included in OS X but, my infrastructure required something a bit more robust. If you would like more reading about the OS X: Application firewall, click this link, which is the official blurb from Apple.
I did not have a laundry list of settings,. If anything, my settings were based on the output of nmap scans. OS X now ships with PF, the OpenBSD Packet Filter. PF allows administrators to tightly control the packet firewall on a device however, it is primarily a terminal-based configuration. There is a GUI application for it but, I found it easier to work with terminal and vi for configuration.
When determining your firewall philosophy you should ask yourself whether your default allows everything or does you default block everything? If yous default allows everything then you must decide what to block. This list could be excruciating to navigate because there are 65,535 ports. If your default blocks everything then this allows an administrator to only open ports that are truly needed.
Personally, I choose to go with the default block route, only opening the specific ports that my organization and users need in order to conduct business. Before implementing my rules I researched and read information to ensure I had a strong grasp of PF. I Googled the topic and also read The Book of PF. I highly recommend the book if you are going to start utilizing PF. After reading this book I was able to build a proper rule-set.
The first thing to do is to learn how to turn on and off the pf firewall. It does need elevated or root privileges to enable and disable.
Enable PF
pfctl -e
Disable pf
pfctl -d
The next thing is to determine where to place your configurations. I would suggest not placing the file in the pf.conf file located in /etc/ but to create an anchor within the /etc/pf.anchor directory. I advise this because Apple update could undo your changes
If you look at the contents within that /etc/pf.anchors there is a com.apple. If you look at the contents of the pf.conf file it tells pf to read rules from the pf.anchor directory. Because of this I believe it is best to create an anchor and have pf.conf read my anchor.
As I stated earlier I decided to go with the default to block all traffic into the machine, while logging all blocked traffic.
block in log all
I wanted to allow certain types of traffic from certain hosts. I decided to utilize macros and tables within my anchor. OpenBSD documentation defines macros as " user-defined variables that can hold IP addresses, port numbers, interface names, etc. Macros can reduce the complexity of a PF rule-set and also make maintaining a rule-set much easier." In the same documentation a table is defined as " used to hold a group of IPv4 and/or IPv6 address. Looks against a table are very fast and consume less memory and processor time than lists." With a better understanding of how macros and tables are used I decided to use macros for ports and tables for hosts. A rule could potentially look like this:
table <host_list> persist { 123.4.456.789 }
Only add persist or const to your table if you need a persistent or constant connection.
When building my rule-set I defined each port which its on macro. I also created many different tables for my collection host. I explicitly labeled my macros and tables. I did this because I create in my anchor file each rule line corresponds to a single macro and a single table. This helps because when pf has a command where you can print out your rule-set in plain english. It tends to put everything in perspective and allows everyone to easily see what is being allowed and not allowed within your config.
Print plain English pf rules:
pfctl -sr
Here is an example:
pass in log proto tcp from <host> to any port = 5900 flags S/SA keep state
pass in log proto udp from <host> to any port = 5900 keep state
pass in log quick proto tcp from <otp> to any port = 22 flags S/SA keep state
pass in log proto tcp from <host> to any port = 22 flags S/SA keep state
pass in log proto udp from <host> to any port = 22 keep state
Lastly pf has a syntax parser. This parser will give you the line the error has occurred on and if the rule-set was loaded. I would highly recommend users run this command prior to trying to enable a rule-set.
Parse Rule-set:
pfctl -nvf /etc/pf.conf
Here is an example of the output of this command:
/etc/pf.conf:53: syntax error
Pf is a powerful tool, that admins can use to secure the workstations in their environment or secure there servers. I took about two days of reading and playing around within terminal to get a strong grasp on Pf. Logging in Pf is interesting because there is not logging. You must setup the logging which I will cover in a later post.
Does anyone in the community utilize Pf? If so in what way? If not, what is stopping you?
If you would like more in depth information about Pf please do not hesitate to contact me.