ssh version causing PCI scan failures
Any roadmap on when SSH is going to be updated to version 8.1 to address CVE-2020-15778 and CVE-2019-16905? One of my clients is failing their PCI scan for these CVEs even though they have no public facing SSH allowed.
NogBadTheBad last edited by
@jvcomputers That would be down to FreeBSD rather than Netgate.
Any reason why you're not blocking SSH access from all bar a management PC address locally.
Gertjan last edited by Gertjan
@jvcomputers That would be down to FreeBSD rather than Netgate.
Any reason why you're not blocking SSH access from all bar a management PC address locally.
I'm with @NogBadTheBad here.
I didn't even read these two "CVE's" as I do presume 'pf' isn't broken.
So, the SSH access should be enabled (should it ?) on a trusted LAN. You can even lock it down further so it accepts only connections from one IP trusted only.
Now, there will be no "PCI scan" on planet earth finding and signalling "SSH".
If SSH access is needed over WAN, use OpenVPN.
One of my clients is failing their PCI scan for these CVEs even though they have no public facing SSH allowed.
Then they are doing the scan wrong.. Unless ssh is part of the process for their PCI - the path that being scanned being it external or from the internal side should never see pfsense ssh..
The devices involved that would be scanning should never be able to see that pfsense has ssh running. Adjust the firewall rules on pfsense. Devices involved with pci should not be on the normal lan of pfsense with the antilock out rule..
@nogbadthebad I have no SSH allow rules except on the main LAN. I have no rules allowing SSH through on the WAN side and didn't think I needed a rule specifically blocking it since pfSense blocks by default on the WAN interface. I'll add a block rule just to see if that will satisfy the scanner.
There is not rule needed if you have nothing on the wan - because yes the default is deny..
You sure this scan is seeing pfsense ssh? And not something in front of it, or where your forwarding too..
Did you put in a rule maybe on the floating tab?
@johnpoz I agree they're likely doing the scan wrong, but trying to convince them of that is nearly impossible as communication is limited to a dispute process through their PCI scanning portal. I have only allowed their scanning IPs and IP blocks through the WAN to "this firewall" and not to the LAN. I have no public facing SSH allow rules and only allow SSH on the main LAN to the firewall. No other VLANs have SSH access to the firewall.
This it would not be possible for them to see the ssh then.
So something missing from the puzzle..
If the device they are scanning from internally or externally does not have access to ssh on pfsense - how would they be seeing it? So either you have rules wrong, or they are scanning from somewhere they shouldn't be - ie like your lan..
Or they are seeing ssh that is not actually pfsense - say a device in front of pfsense? Or between pfsense and where they are scanning from.
The scanning of all IPs in the path is valid and part of pci, and yes meant to catch something like services open in the path or from the devices that should not be. While one way to correct is make sure the service(s) that are seen are up to whatever spec and security that is called for, the correct solution is also just make sure that service is not available from where being scanned from be it internal or external. This also meets criteria.. Its not that services can not be run on devices in the path.. Its just that these services can not be available from anything in the path, etc.
Example - while you might have a webgui say to admin a switch, that does not even support ssl.. This would clearly violate pci, but just need to make sure that anything in the path and used for pci can not access that service - and that service is only available from a device that is outside the scope of the pci validation - ie a managment vlan/pc only, etc.
@johnpoz I'll have to review the rules again. The only thing in front of the pfSense is a bridged cable modem. I've added a specific block port 22 rule from WAN just in case that helps, but I'll also try locking down 22 to a specific IP on the LAN. The weird thing is, I forced a scan when I first put in the pfSense and it passed. Then, when they did their regularly scheduled scan three days later, it failed because of the CVEs I posted above. I put in the pfSense so we'd have better control over what is going on because their descriptions of failures were so random and vague. It's like they're trying anything they can to get their failure fees.
@heper That is what they require, or at least what they describe. Is there another way? I tried locking it down further before but we failed the scan because they couldn't see anything at all and that wasn't good enough for them.
KOM last edited by
Well you can not block them from everything - yeah that is failure... They should be able to see the services that are open to the public - ie the stuff available for pci, etc.
Unless those are locked to only the IPs that are used in the pci - for example your stores..
But yeah a specific block from their IPs to block everything would lead to a failure..
so basically you created an allow-all on WAN for their scanners?
Yeah that is also a freaking FAIL!! The point of scan is to validate you are setup securely.. So they should be scanning your normal firewall rules.. If you create a rule that allows them unfettered access to your firewall wan IP.. That would be fail right there for doing such a thing..
If you have your rules setup that only allow pci IP to access stuff, then proper setup would be to add their scanning IP(s) to these existing rules. And let them know that you needed to do this - because your normal rules lock to only specific IPs used in the pci process.
@johnpoz I just tried only allowing the PCI scanners through to the two IPs on the LAN that process credit cards and it failed because it said the scanners weren't allowed, so it seems it must be allowed to scan "This Firewall (self)" or the scan will fail. It would help if the PCI rules were a bit more explicit about what they want to scan, but the entire world of PCI is almost as bad as HIPAA with its vagaries and contradictions.
The only thing that should be open on your firewall is the stuff that is needed for pci to function.. The point of the scan is to find stuff that shouldn't be open.. Or if what your using for PCI is not up to specs for security - say for example you had a website on 80/443 used for pci - and the you were using say sslv3, or the httpd was not current, or was not patched for a specific vulnerability.
Modification of the rules to allow scan everything that "could" be open on the firewall invalidates the freaking test in the first place.
Nobody in their right mind would for example allow pfsense web gui access to the public internet.. If you open it up for them to scan - you should fail for even doing such a thing..
Where they would be justified in saying hey your ssh is not up to specs for security, is if you had that open to the public internet..
@johnpoz Okay, but I don't have SSH open to the public internet. That's what I don't understand. The only things I have allowed through the firewall are the credit card company's processing IPs which are only allowed to the LAN IPs that process cards.
If I allow their scanners to only the same LAN IPs, they fail me because they have no access to scan the firewall. If I allow their scanners to access the firewall, they fail me because of the two SSH CVEs mentioned in my original post even though I don't have port 22 open to the public. Clearly, I don't understand some portion of this equation, but I don't know which.
If anyone has an example of how a successful setup for PCI scanning has been implemented, it would helpful. I'm sure there are thousands of CardPointe/CardConnect customers out there and someone must be successfully using pfSense other than this client.
The only things I have allowed through the firewall are the credit card company's processing IPs which are only allowed to the LAN IPs that process cards.
You need to allow the company that is doing the scanning - which would be a "Approved Scanning Vendor (ASV)" access to the same stuff you are forwarding for your pci stuff..
Ie these rules
the credit card company's processing IPs which are only allowed to the LAN IPs that process cards.
Need to allow the IPs the scanning company will be coming from, or you need to temp open them up to all.. If the scanning company will not provide you the IPs.. So they can scan - they will need to see the stuff your doing with pci. If they can not see anything then clearly they will fail you.
But you don't need to allow them to scan EVERYTHING on the firewall that could be open.. I thought I clearly went over that already ;)
Post your wan rules and your port forwards - I take it your using an alias to allow the CC companies to access, in that alias add the ASV companies IPs
example: Qualys is an ASV.. These are the IPs they would be scanning from
"The scanner IP addresses are 126.96.36.199/20 (188.8.131.52-184.108.40.206). Depending on your network, it may be necessary to add the scanner IPs to your list of trusted IPs, so the service can send probes to the IP addresses in your account during scan processing. "
@johnpoz I will post the rules shortly, but as I mentioned, I already tried allowing the ASV IPs access to the specific LAN IPs for CC processing and they didn't like that because they couldn't see the firewall. It seems the only time they don't fail me for not being able to scan is when they have their ASV IPs getting full access to "This firewall (Self)" and then they find the non-existent port 22 vulnerability.
Thanks for sticking with me on this. I'm sure it's just as monotonous for you as it is me.
See my edit above.. I have no idea who your using for your ASV.. But they sure and F do not need to see every service that is possible on your firewall.. They only need access to the stuff used for PCI.. Or that is generally open on your firewall on your external IPs..
See the FAQ I just linked to as an example.
Show them your rules where their IPs have been allowed.. If they have problems with what they are seeing..
@johnpoz CardPointe owns CardConnect (the credit card processing company) and CardPointe does their own PCI scanning - we have no choice in that.
Ok - that is fine.. But there is NOTHING in the pci docs that say you have to lower your security stance to allow for such a scan.. Opening up ssh, when it is NOT open is not part of pci compliance..
Be like saying hey here eat this shrimp we are testing if you are allergic - but I don't eat shrimp! When I ate it I got sick.. So yeah if I eat it again I will get sick, so I don't eat it!! So why should I open up ssh to the internet for you to scan.. When I do not allow ssh -- scan me!! Do you see ssh open.. NO!! ;)
Your rules only allow specific IPs to use your port forwards.. Then add their IPs to those rules - that is all that is required to do..
Where you could get in trouble.. Is if you had ssh open, but you specifically blocked their IPs.. Show them your rules that only allow the trusted IPs, and that their scanning IPs have been added to the rules. And there are no other rules allowing stuff from other trusted IPs or that they have been blocked from, etc.
@johnpoz They never specified specific ports to forward, so I just have rules set up to allow their processing IPs full access to the LAN IP that does the card processing - not port forwards, just an allow rule. It sounds like that is the problem?
so I just have rules set up to allow their processing IPs full access to the LAN IP
Well then yeah they could hit you on some service that is not part of pci when they scan those IPs.. Ie if you have ssh open on one of these IPs they are scanning.. But again this would not be pfsense ssh service. But if you a rule open to IP X, that allows everything then sure anything on X is fair game to have to be secure.
Your rules should be set to only allow the ports required to do whatever it is your doing.. This is security 101.. If I am running a FTP server on IP 220.127.116.11, I sure do not also allow ssh, and httpd and snmp, and telnet and whatever else.. But if that is what you have is an any any rule to 18.104.22.168 then sure anything open on 22.214.171.124 is open to scrutiny.
If you have a rule that allows access to IP 126.96.36.199 and ssh is on 188.8.131.52, then yes ssh needs to meet their security requirements.. But that would not be pfsense ssh.
pci requires that they scan all your public facing IPs.. So yeah if you had ssh open on 184.108.40.206 while your pci stuff using 220.127.116.11 that would be a problem. But if you don't have anything open on 18.104.22.168 then its not a problem - they scanned it and no services are open..
This very common setup.. Where company owns public space, and .X is used for outbound traffic only, and .Y is used for inbound.. While they will scan both .x and .y - its fine if nothing shows as open on .x..
@johnpoz They're just Windows 10 boxes, they don't have 22 open. I don't think Windows even has SSH server installed unless it's done so intentionally and it's not on either of these machines. Here's a shot of the rules I have in place.
The "CardPointe_DataCenter" alias is the one used for regular processing and consists of two domains: fts.cardconnect.com, cardpointe.com
CardPoint_Trustwave_24 is their block of IPs used for some of the scanning (22.214.171.124/24)
And the CardPoint_Trustwave_Others is a bunch of other IPs they use for scanning
The rules that allow "this firewall" are BAD!!! Why would you ever put those in..
What rules did you have when your CC stuff works? The DC one? That is allowed to Mel_office.. This is the rule you want to add their scanning IPs to.. the DC alias..
And also the campworks external.. There should NEVER be a need to create specific rules to allow for pci scanning.. Only possible edit of existing rules to allow them to scan what you have open.
I take it your lan net is public space then, since otherwise that rule really would never work..
edit: BTW windows can easy run ssh these days.. Its as simple as clicking install on a feature.. So it would be possible for windows to be running ssh server very easy.
@johnpoz Okay, so, again, I've tried adding the scanning IPs to the same rule with the Data Center and they fail me because they can't see the firewall. That's why I put in the "this firewall" ruleset - It seems to be the only way they will not fail the scan completely. Anything less than that and they fail the scan stating they don't have access to the public IP and can't scan anything. I thought they had to be able to have unfettered access to "this firewall" in order to be able to check all the firewall rules and find out what ports are open and where they're going.
We've got VLANs set up for a few different Wi-Fi networks, but now that you've got me thinking more about this, I do still have all the switches and access points on the main LAN (VLAN1) and they've all got SSH capability, so it could be any one of them causing the error. I'll have to move them all to a management VLAN. Something I was planning to do anyway, but never got around to.
I'm going to start logging everything to do with the Data Center rule and find out exactly what ports are being used so I can set up a port forward rule for only those ports to the Mel_Office alias and try adding those scanning IPs to the same port forward and hope that works.
Regarding Windows and SSH - yeah, I know it can run it, but not by default and the machine in question doesn't have port 22 open, either.
Thanks for your help with all this. I think I'm on the right track now.
they can't see the firewall.
Then they are freaking IDIOTS! There is NOTHING!!! I MEAN NOTHING in the PCI requirements that they need too see anything of the sort - PERIOD!!
These are the rules you have on your firewall.. That is ALL they should ever see! What you have open for PCI to function.
Have them show you in the pci requirements where you are suppose to open up traffic.. That is NOT already open..
Its in requirements 11 (scanning) of the standard if they need help finding where to look - have them point out in that standard where is says to expose something that is not normally exposed.
Step 1 is firewall controls.. And states "and should restrict all untrusted traffic except in cases where that communication protocol is required to process cardholder data."
How is scanning every port, that is NOT allowed do that? How is ssh to your firewall, that is not allowed via your firewall controls part of protocol that processes card holder data? Please ask them to explain that to you - in details and in writing specifically state where in the compliance regulations it says to modify your firewall rules to open a port that is not used for card holder data.. And per your company policy is not open to the the internet in the first place.
The most they can do is require a scan after firewall changes - to validate you do not have stuff open to the internet or have opened up anything else in your pci rules that would be an issue.
Your firewall not having ssh open is good thing! And directly is involved in step 1 of compliance where you create firewall rules to restrict traffic only the protocols required for pci.
To be honest - per the requirements. You could prob get away with sorry our firewall policies only allow access to pci from these IPs.. But in the spirit of checking the devices that actually are involved in the pci stuff. I will add your ips to the rules that are used for access to pci stuff.
I have gone through hundreds of security audits... If your firewall controls do not allow access to X, then that is the policy.. You do not change your policy to look for something that is not accessible. Part of the scanning is also a pen test.. When they will check if they can bypass your controls that restrict access.. But no you are not required, and should not be opening up your controls for them to scan.. Other than what is directly used for pci..
The point of scanning your external IPs is looking for stuff that should be restrictive - if it can not be restricted.. Then it needs to meet specific requirements for security.. Like version 2 of service vs 1, or turn 2fa or restrict to these ciphers or algorithms, etc.. No where in any firewall scan or security test for compliance should you be opening up services that are not used by your company in normal operation. If you had ssh open to the internet as part of your company services than yes it could be in question. So you would either need to stop access to it, or make sure it met security settings for use.
@johnpoz I'll have to continue fighting with them, then. We changed firewalls because the first time we went through this issue where they stated "Verify your Scan Setup for correct IP Address and Domain Name information. Configure your network to allow access from Trustwave scanners." We made sure nothing was open that shouldn't be and disputed the failure, stating that our network is "hidden" (which is also part of their acceptance so long as you tell them that's the case) and they let us pass. But, when we tried that again on the next scan, they wouldn't allow it and started charging us $150 a month for failure. I didn't think we should have to dispute this every quarter, anyway, and deal with getting charged and having to deal with refunds and the bookkeeping that goes along with all that. So, I convinced the client to switch to pfSense and the first scan went through fine. Then they started trying to charge a $50 a month compliance fee for something else, so I started looking into it and here I am.
If I ever figure this out, I'll post here to help others decipher this maze of insanity.
Gertjan last edited by
Just for my own curiosity, you have to do what with credit cards to merit such a scan ?
I'm not a bank, just a hotel, and we deal with credit cards for .... they day they showed up, something like 1988 here in France.
These days, credit card equipment is just jacked into a local switch with 'Internet' access. Done. No other questions asked.
Your not the one processing the CC @Gertjan your just an end user.. You don't store card holder data, etc. If the pci data never touches your companies network, then you do need to meet the requirements.
Sounds like a scam to me to be honest. There is NOTHING in the requirement that you need to open services to be scanned that are not part of pci, and not open to the internet in general.
As stated before - filtering traffic to ssh on purpose block them, while its open to others could be seen as failure. But show them the rules - you do not allow traffic to ssh to anyone, you do not allow access to any firewall services to anyone, etc..
If they are saying they are not seeing the firewall - which is how it should be setup! Allow ping.. There you go - you see the firewall, that is the only service we allow that can talk to the firewall at all.
Another part of the compliance is segmentation, you are on purpose suppose to segment the pci devices so that they can not see anything they do not need to see. While you might need to show that only specific users have admin access to the firewall and that they are using their own unique IDs, and you limit where they can access the firewall from, and that access is logged, etc. Opening up ssh to the scan is not part of the requirement.. Since it can only be accessed via a secure location (your network management vlan) and from specific individuals, with unique login controls and logging of said access.
You might want to take a look at this thread - same subject as yours, just with web gui vs ssh. I linked to the ASV document guide.. Ie guidelines that ASVs are suppose to use when scanning.
Clearly stated in that doc..
"Temporary configuration changes do not require that the scan customer “white list” or provide the ASV a higher level of network access."