Hide FreeBSD version?
-
I'm having an issue with my PCI compliance vendor. When scanning my servers, they see our PfSense box as a huge threat because of FreeBSD 8.3. I'm letting them know that this is a false positive, but I was wondering if it's possible to hide the OS version that is being advertised to the public? Seems like a good idea regardless.
-
[…] I was wondering if it's possible to hide the OS version that is being advertised to the public? […]
Public access to pfSense from the WAN ("public") is already blocked by default. If they are able to see version information you might actually have a serious misconfiguration.
The PCI failure report usually specifies how the data was obtained. Usually that type of information is gathered from service banners like SSH or FTP, or from HTTP services. The simplest way to prevent the public, or anybody, from accessing that data is lock down access to a specific group of IPs and/or VPN.
Also: https://www.google.com/search?q=pfsense+pci+compliance+site:forum.pfsense.org
-
Public access to pfSense from the WAN ("public") is already blocked by default. If they are able to see version information you might actually have a serious misconfiguration.
The PCI failure report usually specifies how the data was obtained. Usually that type of information is gathered from service banners like SSH or FTP, or from HTTP services. The simplest way to prevent the public, or anybody, from accessing that data is lock down access to a specific group of IPs and/or VPN.
Also: https://www.google.com/search?q=pfsense+pci+compliance+site:forum.pfsense.org
I see.
The information given by SecurityMetrics isn't very specific, but the crux is this:
Impact: According to its version, the remote Unix operating system is obsolete and is no longer maintained by its vendor or provider.
Lack of support implies that no new security patches will be released for it.
Data Received: FreeBSD 8.3 support ended on 2014-04-30. Upgrade to FreeBSD 10.0 / 9.3 / 9.2 / 9.1 / 8.4.
It lists the port as "none".
Lighttpd is just advertising its version in the HTTP headers…nothing about FreeBSD.
When using nmap, I see the following:
22/tcp open ssh OpenSSH 5.4p1_hpn13v11 (FreeBSD 20100308; protocol 2.0)
53/tcp open domain dnsmasq 2.68
80/tcp open http lighttpd 1.4.35
443/tcp open http-proxy Squid http proxy 3.1.22
8080/tcp open ssl/http lighttpd 1.4.35
So I suppose SSH is the guilty party here. We haven't changed any of the default SSH settings. How can I remove the FreeBSD info from the port info?
-
How can I remove the FreeBSD info from the port info?
To answer your question, can manually modify the banners for those services. (ex. https://forum.pfsense.org/index.php?topic=6087.0)
But, and I cannot stress this enough, the correct solution is to implement rules to prevent public access to the ports. If you don't have access to external static IPs and/or DDNS, then please consider at least implementing a VPN to reduce your profile. By leaving those ports wide open you are not only risking password bruteforce attacks but also exposing any bugs still in those services. I really can't stress this enough. If those ports are openly accessible by Security Metrics from outside your network and you did not intentionally unblock the ports, your firewall is massively misconfigured and possibly wide open to every available attack. :-\
-
To answer your question, can manually modify the banners for those services. (ex. https://forum.pfsense.org/index.php?topic=6087.0)
But, and I cannot stress this enough, the correct solution is to implement rules to prevent public access to the ports. If you don't have access to external static IPs and/or DDNS, then please consider at least implementing a VPN to reduce your profile. By leaving those ports wide open you are not only risking password bruteforce attacks but also exposing any bugs still in those services. I really can't stress this enough. If those ports are openly accessible by Security Metrics from outside your network and you did not intentionally unblock the ports, your firewall is massively misconfigured and possibly wide open to every available attack. :-\
Thank you very much. I'll be locking down public access to these ports as you suggested!
-
I just thought that I would add that, if you need remote access to these ports from the outside, the much safer way of doing this would be to set up openvpn. :) It's very easy to do and should give you all the access you need and more. Also, a very useful tool in finding out information about how the outside see's you based off of headers is the search engine shodan. ( shodanhq.com) You have to sign up or log in using facebook/twitter/etc.. , but you can type in net:{yourpublicip} to see all the headers as well as a wealth of other info that the outside world sees.
To see some examples and understand how it works, look here:
http://www.shodanhq.com/helpHere is an example ran on googles server.
http://www.shodanhq.com/host/view/74.125.239.34Another thing to note, is that if you see strings like \x03\x00\x00\x0b\x06\xd0\x00\x00\x124\x00 associated with services that the pfsense box is providing to the wan, try doing a oslookup based off of that string. That is often what gives away the OS.
-
You may have an issue here because PCI certifiers usually (always) require access to your machines. Closing the ports will not help in that case.
The real answer is that pfSense is not a vulnerable OS because it is still maintained by its provider. The pfSense team backport all the required security patches or otherwise correct known vulnerabilities in 8.3.Steve
-
You may have an issue here because PCI certifiers usually (always) require access to your machines.
Disclaimer: I'm NOT a PCI compliance expert, but only speaking from personal experience.
Stephenw10, I respect you and your knowledge, but I disagree with some of your statements. I've handled about twenty-five PCI compliance audits and in every case they were conducted via a remote scan that we were able to schedule and that appeared to be automated and that emailed the results to us. In each case we performed the recommended upgrades when it was appropriate or firewalled deprecated services (like pfSense) that were secure but triggered an audit failure. I've heard that they will sometimes ask to have their audit software installed locally but never had that occur. I've never once had a PCI compliance auditor request access to any systems. I can only assume that the audits are less stringent for micro and small business? Or maybe more stringent if the business was compromised in the past?
Closing the ports will not help in that case.
I suspect that it would help actually. While it's true that closing the ports will not "hide" the software version from an internal audit, it does satisfy the goal of the audit which is to secure the systems from the Internet. It was my understanding that systems and services which have been secured (i.e. behind a firewall or blocked port) are considered PCI compliant since they are defended against attack from the Internet. In JMac87 current situation, the concern is that his mis-identified "end-of-life FreeBSD 8.3 system" (vs. his actual "currently supported FreeBSD fork" pfSense system) is wide open to the entire Internet. Every Dutch, Russian, Chinese, and NSA hacker can now throw every possible attack against all of his exposed services. Once he properly secures his firewall, he is protected from attack and less importantly PCI compliance scanning as well. Never having experienced an audit conducted from inside the network take this statement with a grain of salt.
The real answer is that pfSense is not a vulnerable OS because it is still maintained by its provider. The pfSense team backport all the required security patches or otherwise correct known vulnerabilities in 8.3.
Agreed, but I've never been able to successfully alter the outcome of a PCI audit by requesting special exemptions. I suspect that we (the pfSense community) would have to submit pfSense to them (the PCI police) for "official acceptance" as a PCI compliant FreeBSD fork before it would pass an audit with wide open rules on the WAN port.
Again, these are just my experiences and opinions. If they are wrong I hope to learn more.
-
I appreciate your insight on this because I (and I should have declared this) am coming from a position of having never dealt with a PCI audit. My reply there was based on what I have read here and other places and that was seemingly incorrect. :-[
My own experience is almost exclusively at the SOHO level, I have very little real experience of enterprise networks. However I have been involved with security audits (not PCI) in which external auditors conducted scans both externally and internally and requested logins for various machines.
I stand by my comment on extended 8.3 support though. That will be moot when 2.2 is released of course. If the PCI scan is external only and based purely on the FreeBSD base version you could just run 2.2 alpha. ::) Not recommended though!Steve
-
If the PCI scan is external only and based purely on the FreeBSD base version you could just run 2.2 alpha. ::) Not recommended though!
Excellent point. The OP could try that if push came to shove.
-
See also https://redmine.pfsense.org/issues/3840
-
I think stephenw10 has a good point, assuming its true that the current release pfsense although based on a BSD version not current, is supported via the pfsense staff. I'd put the burden on the testers to show me that pfsense is not properly patched if that is their stance.
Their logic works for closed source stuff like XP, but not opensource as much.
