PC-BSD 9.0 Isotope Firewall Manager breaks pf firewall

Discussion in 'all things UNIX' started by jitte, May 20, 2012.

Thread Status:
Not open for further replies.
  1. jitte

    jitte Registered Member

    Joined:
    May 2, 2012
    Posts:
    67
    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.
     
    Last edited: May 21, 2012
  2. jitte

    jitte Registered Member

    Joined:
    May 2, 2012
    Posts:
    67
    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,
     
    Last edited: May 21, 2012
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.