Table of Contents
Building an OpenBSD Firewall is based on the Packet Filter Engine pf(4) and is well documented in manpages, with additional project documentation in the PF FAQ. There are even Tutorial Sessions at various conferences.
These notes assist in the maintenance, monitoring of PF.
At this point, do not be ashamed to purchase a book on Packet Filtering and OpenBSD. You can learn from your own mistakes, and make your own investigations on the Internet and on these pages, but you can also save yourself a lot of grief by buying the knowledge of those who’ve spent some quality effort to document real-life use of PF, with experience in diverse applications.
What ever you do from here, you really do need to read a series of free resources published by Daniel Hartmeier on Undeadly:
Packet Filter (from here on referred to as PF) is OpenBSD’s system for filtering TCP/IP traffic and doing Network Address Translation. PF is also capable of normalizing and conditioning TCP/IP traffic and providing bandwidth control and packet prioritization. PF has been a part of the GENERIC OpenBSD kernel since OpenBSD 3.0. Previous OpenBSD releases used a different firewall/NAT package which is no longer supported.
– PF FAQ
To verify that PF is operational, use pfctl such as:
sudo pfctl -s info
Status: Enabled for 453 days 00:57:16 Debug: Urgent ...
This in no way tells us whether we’ve configured it correctly, just that the PF Engine is running.
Before we can verify our firewalls performance, we need a measure of the “expected behaviour.”
The design and performance characteristics can be documented in the Firewall Policy Document. One approach to writing a Policy Document is with the following outline:
The filtering policy is an informal specification of what the firewall is supposed to do. A ruleset, like a program, is the implementation of a specification, a set of formal instructions executed by a machine. In order to write a program, you need to define what it should do.
Daniel Hartmeier’s PF: Testing your Firewall
A Policy, is a generalised statement whereas the regulations and controls are more specific.
In our context the Policy document serves as a communications tool:
In practise, our Firewall Policy document is divided into these major groups:
As a communications tool, the Policy Document will many times sit in front of non-technical people with little or no technology background, let alone understanding of what a Firewall does.
A brief, broad description, at the beginning of each of our Policy Documents draws a generalised overview of the the function and purpose of a firewall for the benefit of non-technical staff.
The description covers the non-technical overview of a firewall, as well as outlining the major categories of source and destination traffic.
blurb … diagram … blurb
The Firewall blocks and logs all traffic by default. Only explicitly approved traffic is allowed to enter or leave the firewall. Approved traffic is labelled for the purpose of its approval.
The below Regulations and Controls describe which IP Traffic is allowed through the firewall, and the rationale for it’s approval.
Regulations describe the generalised restrictions and the Controls provide more specific implementation requirements.
As per Daniel’s recommendations above, the text is descriptive and sufficient to develop firewall rulesets, without being a full syntax.
All network traffic entering and exiting from the Internal interface is regulated.
Traffic exiting through the Internal Interface must be previously accepted with an incoming filter (administered at the “incoming” interface) and is tagged with a label that ends with “_LAN”.
Only approved network traffic is allowed to enter the Firewall, and is labelled with a tag beginning with “LAN_” which designates it has been approved from the LAN facing interface.
Traffic destined for the Demilitarised Zone is labelled with the tag: LAN_DMZ
Control: Allow from Exchange Server to MX Proxies on the smtp port (tcp)
Rationale: Allow mail submission to the MX Proxy from the Corporate Microsoft Exchange Server. This is required to get our e-mail out.
Note: We have explicitly specified the protocol and port in our Control documents to prevent ambiguity in this specific event. You may differ in your determination on how explicit to be with your control statement.
Required by our Change Management Process, good for keeping us on our toes that we are actually keeping track of changes (per why and not necessarily what.)
The actual ruleset, periodically downloaded from the live server.
For example, a rule that implements the above controls may look something like the below.
pass in on $lan_if inet proto tcp from <ms_exchange> to <mx_proxies> port smtp
Our Control explicitly specifies the protocol (tcp) and port (smtp) as per document requirements.
If your Policy Document is involved in a “Change Committee” process, that it may benefit you to clearly highlight operational activities that can be pre-approved changes for the Firewall Rules. You don’t want to always have to go back to a “Change Committee” for trivial changes that do not diminish from the regulations and controls set in the above document.
From the above Regulation and Control example, our organisation expands to using 2 Exchange Servers, or 2 MX Proxies. There is no change in controls or regulations, and you should be able to add more hosts (ip addresses) to either the table <msexchange> and <mx_proxies> without having to wait for another Change Committee meeting.
A Policy Document regulates the number of external sites accessible by FTP.
The Controls are implemented through use of a table <ext_ftpsites>
Another FTP site is requisitioned by the company for some purpose.
Without needing to go to a Change Committee, we can add the new
FTP site to the approved list (no change in policy, regulation, or
control is made) and we log with the change record of the firewall
document the business case (job #) that prompted the additional
IP address in the table
These notes evolve our experience evolving a deployment that is verifiable for policy and performance compliance.
With a good Policy Document in place, and a ruleset implemented to the document, we are now ready to generate some traffic to verify confirm compliance to the document, and likewise find any deficiencies in our knowledge or the requirements documentation.
Our Traffic Flow expands more into the specific traffic flows, and how to generate and monitor traffic to ensure our understanding of the ruleset and policy document is accurate.
The following links expands further on how to verify and maintain your rulesets.