In my previous post, PF for me PF for you, I went over how to utilize PF in your environment. One thing that I did not discuss was logging with PF. When PF is enabled, it does not log any of the pass in or blocks for the system. You can obtain the statistics on how well your firewall rules are performing by utilizing the following command:

pfctl -s info

Here is an example of the output:

But, let's say you wanted to collect more data to output to your log aggregator or just to the internal syslog to investigate; how would you set this up? Essentially, we want to create a text file of traffic, things we block, or things we allow in - otherwise, we are flying blind. There are a few steps to set up logging on the system. (I have included the steps for set up on my Github as well.)

First, enable the syslogging of local2:

echo -e "# gather PF log data\nlocal2.*\t\t\t/private/var/log/pf.log" >> /etc/syslog.conf

Next, create the actual log file and change the permissions on the file:

touch /private/var/log/pf.log
chmod 640 /private/var/log/pf.log 
chown root:wheel /private/var/log/pf.log
killall -HUP syslogd

Next, set up a tcpdump from /dev/pflog0 to syslog:

cat >/usr/local/bin/pflog.sh <<END
#!/bin/sh
/sbin/ifconfig pflog0 create
/usr/sbin/tcpdump -lnettti pflog0 | /usr/bin/logger -t pf -p    local2.info
END

Then, change permissions on the the tcpdump logging:

chown root:wheel /usr/local/bin/pflog.sh
chmod 555 /usr/local/bin/pflog.sh

Next, create a launch daemon that will ensure pf is started at boot and is running:

cat >/Library/LaunchDaemons/name of.plist <

<key>Label</key>                <string>pflog</string>        <key>ProgramArguments</key>
            <array>
                    <string>/usr/local/bin/pflog.sh</string>
            </array>
    <key>Disabled</key>             <false/>
    <key>RunAtLoad</key>            <true/>
    <key>KeepAlive</key>            <true/>

END

Change Permissions:

chown root:wheel /Library/LaunchDaemons/nameof.plist
chmod 444 /Library/LaunchDaemons/nameof.plist

Finally, this step switches the pfctl launch Daemon to start fully rather than enabled on demand. Add in the -e option into the ProgramArguments array inside of /System/Library/LaunchDaemons/com.apple.pfctl.plist

<key>ProgramArguments</key>

 <array>
    <string>pfctl</string>
    <string>-ef</string>
    <string>/etc/pf.conf</string>

Once all of this is in place then check to see if pf is running:

launchctl list | grep pf

Load the pf log plist:

launchctl load -w /Library/LaunchDaemons/nameof.plist

Then, check to ensure that pf log is now running:

launchctl list | grep pf

There are plenty of open source projects out in the wild that are built on a variety of platforms. Github, BitBucket and Mercurial. Open source projects rely on these services because they are able to version control their code. Version control has some of the following benefits:

Archive successive versions of source-controlled items
Maintain detailed history and version information
Collaborate on projects
Recover from accidental deletions or errors

Deploying version control within an organization can a help staff produce efficient and stable code. It allows everyone to view, comment, and edit code before it hits production servers. Many times when people write code, normally the code works well on their system and maybe on a few of their test systems, but in an environment that has hundreds or thousands of nodes it is important to fully test every potential system your code will touch. This leads to the another important component of writing code Documentation.

Documentation is something that is lacking in most I.T. departments. Technicians deploying systems usually feel pressed to roll out a service or finish a project so they can move onto the next item on their agenda. Versioning will allow technicians to document every change. Co-workers can follow the logic that went into developing a code base. Documentation can also help save you when having to restore or update services. I.T. professionals move at a lightening pace and it helps if you store helpful hints for yourself or team. For those co-workers who need to motivation of why to document, Rich Trouton, gave a presentation at Mactech Conference about documentation that is worth a read.

Open source projects that utilize these tools allow anyone who is interested in a project to provide and enhance code. For example, the Autopkg project, is an automated preparation of software to be deployed to OS X clients. This project was created because there is a need to automate software updates for applications. The creators of the tool started a repository that users can pull updates for certain applications. However, they set up the application framework which enables anyone to create "recipes" and contribute to the project. Autopkg code lives all on Github, which allows for collaboration on a global scale.

Because of the popularity of Autopkg another open source project, based upon Github and version control, is Autopkgr. This open source project is a GUI wrapper for Autopkg. Due to version control the creators of Autopkgr are able to allow anyone to help modify the code to help benefit the community.

Lastly if you are looking to set up a code sync, the Client Platform Engineering (CPE) team at Facebook, has opened sourced some of their code sync tools. In addition users can use some of these other tools to help with versioning and checking code:

These are not the only or definitive list of versioning, editing, or checking code but just a start.

Here are some questions I have for you:

Do you version control your code?
What do you use to version control your code?
How to implement version control?
If you are currently not using version control do you see yourself implementing version control?

Just some food for thought.

Pf logging

Mic check 1, 2, 1, 2