Add a header to webConfigurator server
-
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.
-
^ 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?
-
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.
-
That is great but that is not a PCI compliance scan - that is just a ssl scan..
-
.. 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 ?
-
"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 ;)
-
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.
-
"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..
-
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…
-
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.
