PC-BSD 9.0 Isotope Firewall Manager breaks pf firewall

When editing default pf firewall rules through the Firewall Manager GUI in PC-BSD 9.0 Isotope from "pass" to "block" there is a syntax error that prevents rules from being loaded, which in effect disables the firewall.


Default rules in the PC-BSD 9.0 Firewall Manager are set to pass traffic:

Code:

pass in quick on fxp0 proto udp from any to (fxp0) port 137 keep state

When a default pass rule is changed through the Firewall Manager GUI to block a service it changes the rule to block:

Code:

block in quick on fxp0 proto udp from any to (fxp0) port 137 keep state

But does not change the "keep state" flag, the rule doesn't make sense, and firewall rules aren't loaded:

Code:

keep state on block rules doesn't make sense
skipping rule due to errors
rule expands to no valid combination
pfctl: Syntax error in config file: pf rules not loaded

This is an image of the syntax error that occurs when changing the default PC-BSD 9.0 NetBIOS rules from "pass" to "block" though the Firewall Manager GUI:

http://s166.photobucket.com/albums/u101/jitte_nusumi/syntaxerror02.jpg

An Nmap scan from the LAN returns it responding to ping and 1000 ports closed, which is the same results you get when the pf firewall isn't enabled through the /etc/pf.conf file.


This left me to wonder if the PC-BSD 9.0 Isotope implementation of the OpenBSD pf firewall worked at all, so I conducted a series of Nmap scans on a machine with a fresh install of PC-BSD 9.0 Isotope from another FreeBSD machine on the LAN.

Without altering the default PC-BSD 9.0 ruleset in any manner I conducted an intense Nmap scan with the pf firewall disabled, the firewall enabled utilizing the default PC-BSD 9.0 ruleset, and the firewall enabled with my own ruleset in place, /etc/pf.conf.new, consisting of the following 2 basic pf firewall rules:

Code:

block in all

pass out all keep state

-------------------------------------------------------------

#pf firewall off - default PC-BSD ruleset

# Enable the firewall
pf_rules="/etc/pf.conf"
pf_enable="NO"
pf_flags=""

nmap -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 172.16.1.35

Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-04-28 10:37 CDT
NSE: Loaded 63 scripts for scanning.
NSE: Script Pre-scanning.
Initiating Ping Scan at 10:37

*snip scan progress data to save space*

Nmap scan report for TESTBOX (172.16.1.35)
Host is up (0.096s latency).
All 1000 scanned ports on TESTBOX (172.16.1.35) are closed
Device type: firewall|general purpose|storage-misc|proxy server|specialized
Running: Cisco AsyncOS 7.X, DEC OpenVMS 7.X, FreeBSD 6.X|7.X|8.X, IronPort AsyncOS 6.X, McAfee embedded, VMware ESX Server 4.X
Too many fingerprints match this host to give specific OS details

-------------------------------------------------------------

#pf firewall on - default PC-BSD ruleset

# Enable the firewall
pf_rules="/etc/pf.conf"
pf_enable="YES"
pf_flags=""

nmap -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 172.16.1.35

Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-04-28 10:02 CDT
NSE: Loaded 63 scripts for scanning.
NSE: Script Pre-scanning.
Initiating Ping Scan at 10:02

*snip scan progress data to save space*

Nmap scan report for TESTBOX (172.16.1.35)
Host is up (0.094s latency).
All 1000 scanned ports on TESTBOX (172.16.1.35) are closed
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: FreeBSD 6.X|7.X, PC-BSD
OS details: FreeBSD 6.2-RELEASE-p2 (pf with scrub enabled), FreeBSD 7.1-PRERELEASE, PC-BSD 1.3

-------------------------------------------------------------

#pf firewall on - pf.conf.new ruleset

# Enable the firewall
pf_rules="/etc/pf.conf.new"
pf_enable="YES"
pf_flags=""


nmap -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 172.16.1.35

Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-04-28 10:55 CDT
NSE: Loaded 63 scripts for scanning.
NSE: Script Pre-scanning.
Initiating Ping Scan at 10:55
Scanning 172.16.1.35 [8 ports]
Completed Ping Scan at 10:55, 2.01s elapsed (1 total hosts)
Nmap scan report for 172.16.1.35 [host down]
NSE: Script Post-scanning.
Read data files from: /usr/pbi/zenmap-i386/share/nmap
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.06 seconds
Raw packets sent: 16 (640B) | Rcvd: 0 (0B)


nmap -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 172.16.1.35 -Pn

Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-04-28 10:56 CDT
NSE: Loaded 63 scripts for scanning.
NSE: Script Pre-scanning.
Initiating Parallel DNS resolution of 1 host. at 10:56
Completed Parallel DNS resolution of 1 host. at 10:56, 0.01s elapsed
Initiating SYN Stealth Scan at 10:56
Scanning TESTBOX (172.16.1.35) [1000 ports]
SYN Stealth Scan Timing: About 29.50% done; ETC: 10:58 (0:01:14 remaining)
SYN Stealth Scan Timing: About 59.15% done; ETC: 10:58 (0:00:42 remaining)
Completed SYN Stealth Scan at 10:58, 101.21s elapsed (1000 total ports)
Initiating Service scan at 10:58
Initiating OS detection (try #1) against TESTBOX (172.16.1.35)
Retrying OS detection (try #2) against TESTBOX (172.16.1.35)
Initiating Traceroute at 10:58
Completed Traceroute at 10:58, 9.12s elapsed
NSE: Script scanning 172.16.1.35.
Initiating NSE at 10:58
Completed NSE at 10:58, 10.00s elapsed
Nmap scan report for TESTBOX (172.16.1.35)
Host is up.
All 1000 scanned ports on TESTBOX (172.16.1.35) are filtered
Too many fingerprints match this host to give specific OS details



An explanation from the Nmap site of relative port states returned by Nmap scans:

closed

A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it. They can be helpful in showing that a host is up on an IP address (host discovery, or ping scanning), and as part of OS detection. Because closed ports are reachable, it may be worth scanning later in case some open up. Administrators may want to consider blocking such ports with a firewall. Then they would appear in the filtered state, discussed next.

filtered

Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several times just in case the probe was dropped due to network congestion rather than filtering. This slows down the scan dramatically.

EDIT:

I have also discovered that only 2 days after I made my initial inquiry asking why PC-BSD 9.0 returned a closed port state when scanned that an entry was made in the PC-BSD Wiki about projected changes to be made in PC-BSD 9.1 regarding the Firewall Manager being replaced with fwbuilder:

http://wiki.pcbsd.org/index.php/PC-BSD_9.1_TODO
.
.
PC-BSD Administrators have known since 4-6-12 that their implementation of the OpenBSD pf firewall was broken and declined to put out a patch, or at the very least a Security Advisory so their users could put the pf firewall into a working state, as can be easily accomplished by the steps I have laid out.

Instead, they have chosen to remain silent on the issue and leave their users potentially vulnerable to exploit, with a false sense of security in believing their firewall is protecting them when in fact it is not.

Something that might have been expected from Microsoft in the Windows98 era but not something that you would expect to happen in the UNIX world.

 

The bug that occurs when changing default pass rules to block thought the Firewall Manager GUI was patched approximately 90 minutes ago.

http://trac.pcbsd.org/changeset/16938

I don't have it installed on any of my machines to see if it still responds to ping and returns a closed port state when scanned and don't plan on reinstalling it to find out,