PC-BSD 9.0 nmap scan results question

[Weixiong]

Due to an unrelated matter I did a fresh install of PC-BSD 9.0 on the box I've been working with firewall rules on and took this opportunity to do further testing from my other PC-BSD box on the LAN.

It installed a default ruleset like it should, and without altering the default ruleset in any manner I conducted an intense nmap scan with the pf firewall disabled, the firewall enabled utilizing the default PC-BSD ruleset, and the firewall enabled with my own ruleset in place:

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

#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



Explanation 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.

[whitelightning777]

Have you tried linking the firewall rules to each network card? I'm not as familiar with BSD security, but in syslinux you can set different security rules for each network card.

Is there a file somewhere in your network card's configuration that says whether or not to impliment the firewall rules?

Also, you could try writing a script to change the rules and then run it every time you start up automatically. Its not "clean code" but that might be effective, crappy but effective.

[Weixiong]

That testing was done on a new install of one PC-BSD box connected to the router by Ethernet from another on the LAN using wifi to connect. There is no linking of network cards, switches, or firewall rules to be done. It's same as the scan results you would get from scanning one machine from another on the net. The bad part is getting the same closed port results from the firewall completely disabled and when the default rules are used, which show it's not working.

"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."

That's from the Nmap site, not something I came up with.

I'm trying to prevent a situation from occurring where somebody is using PC-BSD as a server, opens port 80 and it ends up being used as a proxy, or worse yet their IP appears on a proxy site, then coming back and ripping them a new one or posting another review online slamming PC-BSD. It's a potential disaster waiting to happen and ignoring it won't make it go away, but I seem to be the only one concerned about it other than you.

The syntax error occurs when you just modify existing rules through the Firewall Manager GUI from pass to block and that shouldn't happen.

Also, you could try writing a script to change the rules and then run it every time you start up automatically. Its not "clean code" but that might be effective, crappy but effective.

.
I've fixed my ruleset and am since behind a pfSense hardware firewall. I'm not the one who will be effected if it doesn't work.

[whitelightning777]

I guess that you have to make friends with someone that has a sonic wall or a Cisco PIX. Of course even a regular vanilla linksys router from Walmart should be up to the task.

I would consider letting Dru L. know about this, especially if 9.1 is a server.

Now I'm curious. I may put FreeBSD in another virtual machine to see what happens. I can't do it until Sunday, work + girlfriend on Saturday.

[Weixiong]

I guess that you have to make friends with someone that has a sonic wall or a Cisco PIX. Of course even a regular vanilla linksys router from Walmart should be up to the task.

I would consider letting Dru L. know about this, especially if 9.1 is a server.

Now I'm curious. I may put FreeBSD in another virtual machine to see what happens. I can't do it until Sunday, work + girlfriend on Saturday.

.
I have a photo of the syntax error I've already posted and guarantee you if you carry out the test I did above you'll get the same results, I wouldn't have said anything if I wasn't sure. I made a bug report about it 3 weeks ago and never got a response.



It's as simple a fix as bypassing the Firewall Manager by making your own ruleset and referencing it.
If you can get by without using SSH you can do it with 2 rules.

Log into a terminal as root then enter:

ee /etc/pf.conf.new

##Then make your rules

block in all 

pass out all keep state

##Save the new ruleset, exit the editor, 
##and reference the new ruleset:

ee /etc/rc.conf

##By changing this line

pf_rules="/etc/pf.conf"

##To this

pf_rules="/etc/pf.conf.new"

Then exit the editor and reboot.

The firewall will no longer respond to ping and will now show ports as being filtered,
where as before it responded to ping and returned a closed state.

[Weixiong]

It's been a full month now that after extensive testing I posted a bug report on 4-18-12 informing PC-BSD administrators that their implementation of the Firewall Manager in PC-BSD 9.0 Isotope breaks the OpenBSD packet filter firewall. I have even posted images of it not loading rules, which in effect disables the firewall, as a result of changing the 3 default NetBIOS rules from "pass" to "block" through the Firewall Manager GUI to back up my claim.
.
.

.
.
To date, not one word has been said by them about the issue to either confirm or deny my findings, or more importantly, to advise their users of the issue so that they might take steps to rectify the problem themselves, as can easily be accomplished by the steps I have laid out.

Instead they have chosen to remain silent, as if by ignoring the issue it would go away, and leave their users to erroneously believe their firewall was protecting them, when in fact it is not.

A security issue of this magnitude, wherein some users have even voiced an interest in using PC-BSD 9.0 Isotope as a server, is a very serious matter and by not putting out an advisory so that their users could put the firewall into a working state is something akin to abandonment and a betrayal of the trust it's users put into them by using their Operating System.

I have been a loyal PC-BSD user for 7 years and this incident has caused me to lose all trust and faith in PC-BSD, so much so that I've chosen to remove PC-BSD from my machines and replace it with FreeBSD, just as I replaced Windows with PC-BSD.

Even Microsoft puts out Security Advisories and patches once a month for their users. If PC-BSD doesn't care enough about their users to alert them of this serious security hole in PC-BSD 9.0 Isotope, I will, as I can no longer in good conscience remain silent on the issue and continue to wait for them to take steps to protect their users.

[Tigersharke]

Weixiong, I appreciate your efforts to get this firewall issue resolved/clarified. I agree with your assessment that it would be trouble later in some way. I don't know enough about pf firewalls and how best to configure them, plus I am not as concerned as I probably should be about my firewall/security stuff. However, in my favor is that I am not frequenting the shadier side of the Internet, so that in itself reduces my chances of running into trouble (and I am behind two routers with some security which may help). Really though, my own lack of understanding is mostly what prevents me from having taken on the task of resolving the firewall issue. Thanks again for your work.

[whitelightning777]

I had some problems getting freebsd up in the virtual box I had for it. It appears to have installed, but nothing works. Most servers in serious data centers have hardware firewalls so the servers don't have to fend off malware themselves. Someone who knows Dru well should let her know.

[Weixiong]

Weixiong, I appreciate your efforts to get this firewall issue resolved/clarified. I agree with your assessment that it would be trouble later in some way. I don't know enough about pf firewalls and how best to configure them, plus I am not as concerned as I probably should be about my firewall/security stuff. However, in my favor is that I am not frequenting the shadier side of the Internet, so that in itself reduces my chances of running into trouble (and I am behind two routers with some security which may help). Really though, my own lack of understanding is mostly what prevents me from having taken on the task of resolving the firewall issue. Thanks again for your work.

.
.
Shadier side of the internet? There is no "wrong side of the tracks" to the internet, in a sense you're virtually as close to China as your neighbor across the street, traceroute hops not withstanding.

The fact that a router stands between the internet and your machine is why I've stayed as quiet on the issue as I have till recently. When the poster voiced an interest in using PC-BSD 9.0 as a server it became another matter entirely.

I'm not going to lose sight of the issue and turn this into a tutorial about TCP-IP, firewalls, or computer security. There are already many fine books and articles on the subject and I respectfully suggest that for your own good you take the time to educate yourself on it.

And while you may not be versed in the subject there is no doubt in my mind that Dru is, as only 2 days after I made my initial post in this thread asking why PC-BSD returned a closed port state when scanned 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:

PC-BSD Wiki

New Features / Tools planned for 9.1

Feature
replace firewall GUI with fwbuilder and document how to use

Owner
dru

This page was last modified on 6 April 2012, at 07:56.

http://wiki.pcbsd.org/index.php/PC-BSD_9.1_TODO
.
.
It has now become an issue of PC-BSD Administrators leaving their users with a false sense of security and to believe their firewall is protecting them when it is not, which IMO is despicable and something on par with what Microsoft might have been expected to do in the Windows98 era.

I've already given irrefutable proof that the Firewall Manager breaks their implementation of the OpenBSD pf firewall in PC-BSD 9.0, how security conscious users can take steps to bypass said Firewall Manager and set the pf firewall to a working configuration, and they've shown they are aware of the matter, are not going to address it in PC-BSD 9.0 Isotope, and going to leave their users potentially vulnerable to exploit.

I don't know how to make it any clearer so will not be addressing the issue further in this forum. I have already removed PC-BSD from my machines and further discourse on the subject would be pointless.

[fluca1978]

Very interesting, thanks for you efforts!