Add a header to webConfigurator server

[rock99x]

I’m getting failures from Qualys security scans of my pfSense boxes for missing this header in the connection to the webConfigurator

HTTP Security Header Not Detected

X-XSS-Protection HTTP Header missing on port 443.

They want this in the output of the server connection.

X-XSS-Protection “1; mode=block”

I made the change to the /etc/inc/system.inc file so it was included.

Is there a way to make this change permanent or will that be something pfSense will have to include in their updates?

Thanks,
Chuck

[Gertjan]

Hi,

You got it backwards.
The GUI should be visible from LAN only - as it has been setup when you installed. Not from WAN. The GUI should never never be exposed on WAN, it isn’t build for that.
If you need to access the GUI from the WAN side, use the VPN facilities build into pfSense.

https://www.ssllabs.com/ssltest/ is a tool to test public web sites. The GUI is everything but a public web site.

[johnpoz]

While I agree completely the web gui should not be exposed to the public, and really should be limited to admin access from a secure network anyway.

Why would you not follow current practice for specific headers.

There are many headers that are recommend to be set… Along with the X-XSS-Protection I don’t see either

Content-Security-Policy
Referrer-Policy

set as well.

I am not too worried about it since you can only access my gui from my secure network anyway… From my trusted machine - but again why not set recommended security headers?

You can view the headers easy with simple curl to your pfsense gui from your secure lan side - no reason to expose it to the public for some test site to hit.

[jimp]

@johnpoz:

Content-Security-Policy

There’s a ticket open for this one: https://redmine.pfsense.org/issues/6647

Not sure about the others. Probably due for a review in general, when that ticket gets addressed. Might drop a comment on there with the others.

[johnpoz]

Thanks Jimp Will take a look and add comment as appropriate

[rock99x]

In a perfect circumstance, we would limit the admin panel to only known addresses.

This may still be an option, but either way, we are being required by one of our customers to scan our firewall IP externally through Qualys with a PCI compliance scan.

We’re failing the Qualys PCI scan and this problem is one on my to-do list to figure out.

Blocking the IP of the firewall from these scans is not an option to keep the customer.

I just need to address this failure with a response and try to come up with a fix that will satisfy Qualys and the customer. We’re working on it is fine for now. I will probably come up with some kind of cron job or file change detection to edit the system.inc file when it changes to keep the scan compliant.

This will still leave a window of opportunity for the scan to find the problem.

On another note… just my opinion, it’s a firewall. If it isn’t designed to be directly connected to the Internet, then it probably shouldn’t be called a firewall.

Thanks,
Chuck

[Gertjan]

@rock99x:

….
But, ok, I’m curious now. I’ll open up tomorrow my WAN on port 443 for GUI access, and test the access with ssllabs.com.
I’m not an nginx expert, but I guess I can come up with a small edit that will make the GUI comply.

Done.

It took me some time to setup my DNS, so pfsense.brit-hotel-fml.n*t point to my WAN IP.
Opened WAN GUI access and launched the test : (see image).

My conclusion : The nginx web server used by pfSense is ok - nothing to add or remove.
An A+ out of the box.

PS : I’ll throw in a CAA record for even more green

[johnpoz]

“Blocking the IP of the firewall from these scans is not an option to keep the customer.”

Huh??  Your customer seems like they don’t understand what is going on here.  While I agree putting in special rule that blocked the scanning IP would be wrong and reason to fail pci compliance.  But where in the pci compliance documentation does its say that you have to OPEN up a port to the outside to scan it when that service is never meant to be open to the internet… That is just stupid…

That is like complaining that your pin on your door to bathroom in the building is only 4 digits when the only way to get access to the bathroom is to get into the building first where you have a key to the outside door, which you also have to have a 12 digit pin and also pass a bio security check, and get past the security ninja that guards the door. Because some doc says pins on doors have to be a min 6 digits… Think for 2 seconds…

They are complaining about a header that will never ever be open to the public internet anyway…

Open up the ports you need to forward through pfsense and let them scan… They should not be scanning pfsense web gui on the public interface for pci compliance…  It makes ZERO sense!!!

Yes you need to do a pentest against your firewalls public IP… But specifically opening up the gui just so you can scan it is not what a pentest is at all…  Did you have the gui open to the public for some reason when they did your first scan?  If so the solution to the problem is that that port has since been closed - the web gui to the firewall is no longer available to the public internet… See here is the scan to prove it, their is no specific firewall rule blocking anyone from scanning anything…

While There is a redmine about what headers could be set, etc.  And I agree some should be set just out of best practices - but doing so has little to do with a pentest or pci compliance scan.

[rock99x]

I totally agree, it makes no sense to me either. If the IP is not open for traffic inbound, then it’s secure right?

Sounds like it should pass the test to me too.

Unfortunately, I was told this isn’t the case with the scan we are required to get.

I’m even having an issue with an IP that is not assigned to a firewall, but is in fact a NAT IP address on a Cisco router. There is no way to make that IP ping. That is not how NAT works on those devices. So they are requiring me to port forward to a reachable host on that IP.

To me that sounds like to opposite of securing the IP, doesn’t it?

If I have to guess, it looks like it comes from the “scanning procedures” section in the PCI requirements doc.
https://www.pcisecuritystandards.org/pdfs/pci_scanning_procedures_v1-1.pdf

“The ASV must scan all filtering devices such as firewalls or external
routers (if used to filter traffic). If a firewall or router is used to establish a
demilitarized zone (DMZ), these devices must be scanned for
vulnerabilities”

So technically, if the IP isn’t available to scan, it fails the scan… ?

I don’t know, I’m just trying to get the PCI scan to pass for the boss.

Thank you for all the help guys.

Chuck

[jimp]

Sounds like someone who doesn’t know how to run a scanner. Some default to skipping an address if ping fails. OpenVAS would do that, but it’s a simple flag to switch in the scan config.

[johnpoz]

^ Yup I bet that is the case for sure - what should never open anything special for a scan… Just because an IP doesn’t answer ping, doesn’t mean that 443 is not open, etc.  But yeah out of the box typical nmap scan even unless you tell it NOT too will ping first before running the rest of the scan, etc.

Which is funny is then prob be hit for answering ping   If you open that up to allow for icmp echo.

Are you kicking off the scan… Or is the customer or 3rd party running the qualys scan?

[Gertjan]

Oops, instead of replying I edited an old message.
Anyway, the results are here : https://forum.pfsense.org/index.php?topic=144026.msg784950#msg784950 (surprise !!)

edit : I’ll leave my WAN IP open for some a couple of hours. So everybody can “test”.

Also : pretty nice result actually for a connected-device GUI. What was the question again, because now I think I didn’t understood the question.

[johnpoz]

That is great but that is not a PCI compliance scan - that is just a ssl scan…

[Gertjan]

… as I just figured out.
And these scans are not for free of course.

Any company that accepts, processes, or stores credit card information needs to comply with the requirements set by the Payment Card Industry Security Standards Council. Merchants passing a free PCI Scan will receive the official certification they need to submit to their acquiring bank.

What has the pfSense WEB GUI to do with money transactions ?

[johnpoz]

“What has the pfSense WEB GUI to do with money transactions ?”

Nothing   But the PCI scan looks for specific things at the target IP. Pfsense web gui would never come into play - but their might be some web server that is part of the transaction, etc.  Say something you port forwarded on pfsense to something behind it.

Since the OP opened up the webgui to the scan, the it would have to meet those requirements.  Our point has been that pfsense as you correctly stated the web gui should not be under scan since it should/would never be available in path of compliance…

My take away from this whole mess is there are some best practice headers that can be added, even when the web gui is never open to the internet or would need to pass a pci scan.  It is a good thing to use best practices from security standpoints for headers, etc.  I am sure they will get to it - but pretty sure there are more pressing matters to be sure since as I think we all agree the pfsense web gui should never be opened up to the public internet for any reason.  Let a lone pci.

Its great to see that its getting an A+ from a ssl point of view.

nice to see pfsense.org getting an A+ as well - but they should prob add the CAA entry in dns as well.  Which is currently missing

[Gertjan]

And what about getting the GUI out of the way - moving it from 443 to another port xyz.
This is still a GUI “all open in the wild” but PCI scans would see this port anymore.
Or is PCI some sort of nmap scan ?

Anyway, I still don’t understand why a web interface to control a device should be visible to the Internet - and should be related to money transactions, and thus should comply with these scans. Even if I do not have any answers, I still like to understand the question.

[johnpoz]

“I still don’t understand why a web interface to control a device should be visible to the Internet”

It shouldn’t be… The OP for whatever reason opened up to the scan.  Now its listed on the report and he was looking to get it to pass the scan.  It should of never been in play at all…

To me the correct answer to the hit on the scan would be that web gui is no longer available to the public internet, etc.  Done work on any other issues seen on the pci scan to pass.  I think where the OP might be having a problem is the customer has seen the results of these scans and wants it to pass - even though it should of never been scanned as part of the process in the first place.  So I do not see why the correct answer to the customer is see that is no longer available to the public net - so no longer a hit on the scan.

Sure changing the port might pass the scan - might not, I have not had to look into the details of what is scanned in many many years.  It might hit every port… But doesn’t matter if it does or not since the web gui should not be available to the public net on any port… And if they just changed the port but left it open then to be compliant it would have to pass the scan, etc.

This is just my guess - but I am guess that they set the wan rule to any any for the scan… Which is NOT what the point of a pci or pentest scan…  The scan should be checking for the services that are available on that IP… The web gui should not ever be available on that IP…

[rock99x]

The pfsense IP is considered in scope of the PCI scan since it is the path the transaction information takes to reach the processor.

Basically the network path of the card reader to the clearing house for the transaction is all in-scope for the PCI scan.

As I understand it…

[johnpoz]

Yes the IP is in scope - but the firewall gui which should never be available on that IP should not be… You turn on pfsense out of the box there is NOTHING open on the wan, ZERO services available - shoot it does not even answer a ping.

Any traffic you allow inbound would be involved in the scan,not services that would never be available on that public IP…

You creating a firewall that allows access to the gui from the wan is what would put it in scope - why would you do that… There is ZERO anything pci compliance that would suggest you would open up a devices admin gui to the public internet…

A pentest against this IP would be in scope… They can pentest all day - but you opening up the web gui to the public should of never happened.  If they can access the webgui via a pentest when you have not allowed it then that would be in scope - and would be a whole shitcan of worms… But you creating a specific firewall rule that allows access to the gui or any any to the wan IP is just not correct way to do this sort of scan or any sort of pentest or compliance test at all.

Like saying hey we want to test the lock of your door… Unlock it please - oh yeah that lock doesn’t do shit, it opened right up…

A pentest or compliance test is against service that would be open or finding stuff that is open and should not be.

auditor: Hey you have ntp open on port 123
user:  Yeah we need that
auditor: Ok it must meet xyz if your going to have it open.
user: Ok we will do xyz
auditor:  Ok scanning, yup its version X, it doesn’t allow that or this - your good
user: thanks.

auditor: Hey you have ntp open on port 123
user: Oh shit really -  we don’t need that.  Closed
audiotr: Ok let me check - yup no ntp anymore your good.