PCI Scan failing due to RED Port 3400

Hi Bill,

PCI compliance check has to be done with approved scanning vendors by PCI security standards council to comply with the latest PCI framework requirement. Hence non-approved external PCI scanners may not comply with PCI framework due to their lack of testing against known CVE in the deployed Sophos UTM.

Here is a link for approved scanning vendors:

https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors

RED functionality is similar in both the devices; XG and the UTM. Luk's suggestion of enforcing TLS 1.2 is something you must implement.  

Cheers-

Hi sachingurung,

In the first post I mentioned the vendor, SecurityMetrics, who did the scan.  They are an approved vendor on the list you posted, so it is not related to non-approved PCI scanning in this case. 

I have already implemented TLS 1.2 by turning it on in the RED configuration page.  The primary problem seems to be the fact that the XG/UTM uses weak ciphers.  The workarounds I have seen are for the UTM but I don't believe they will work in XG due to the way DNAT rules have to be written. 

I used this as a template:

http://xianclasen.blogspot.com/2016/02/sophos-red-and-pci-compliance.html

The difference is the XG doesn't seem to allow you to "do nothing" in the DNAT rule, you have to give it a destination or you can't create the rule.  So what I did was create a DNAT rule to allow from WAN, from the static IP my RED is on, and map port 3400 to the internal IP of the XG.  Then I cloned this rule, changed the allowed networks from the RED IP to Any, and then created a non-routable IP and sent the traffic to the black hole address.  So far it seems to be working, testing port scans from various places show the port as stealth, but the RED can connect just fine. 

sachingurung, 

I am more than sure what is Bill Roland saying is correct. Sachin, can you investigate internally and report it back ASAP?

This is a security issue that must be addressed.

Regards

Hi All,

Provide me some time to investigate and raise it internally. I will update with all the information that I can source.

Thank You

Hi All,

Provide me some time to investigate and raise it internally. I will update with all the information that I can source.

Thank You

Thanks.  Just to circle back, SecurityMetrics has completed a re-scan of us following the workaround I put in and we are now receiving a "passing" grade.  Still, this is something that needs to be addressed within the product itself obviously, and I hope that it will be in a future version.

Hi Bill, 

I raised it with the Dev Team. Can you please PM me the compliance report for Port 3400, we need to verify the ciphers on which the SSL tunnel is being negotiated and due to which weak ciphers the PCI compliance failed for the customer?

Thank you

sachingurung said:

Hi Bill, 

I raised it with the Dev Team. Can you please PM me the compliance report for Port 3400, we need to verify the ciphers on which the SSL tunnel is being negotiated and due to which weak ciphers the PCI compliance failed for the customer?

Thank you

 

This is still an issue!

Port: tcp/3400
An SSL certificate in the certificate chain does not validate with a wellknown
Certificate Authority (CA). Users may receive a security warning
when using this service. The certificate chain includes all intermediary
certificates, in addition to the root certificate, that is used to validate
your certificate.
CVSSv2: AV:N/AC:M/Au:N/C:P/I:P/A:P
Service: generic_ssl
Evidence:
Subject: /CN=<customer name> Remote Ethernet Device
CA/C=US/L=<city>/O=<customer name>/emailAddress=<Sophos account email>
Issuer: /CN=<customer name> Remote Ethernet Device
CA/C=US/L=<city>/O=<customer name>/emailAddress=<Sophos account email>
Certificate Chain Depth: 1
Reason: The certificate chain is complete; however, it is not trusted by
our root certificate store.

So what do you do when you have 15+ RED devices in remote users homes and they are all on standard consumer internet plans and their IP addresses are changing?

I am also failing PCI compliance scans and the solution sounds like a work around and not a actual solution.  The bigest issue is I have a valid GoDaddy certificate installed but it seems port 3400 doesn't respond with it.  What I mean by that is I have a SSL certificate called  vpn.mydomain.com installed and I have all the RED devices set to connect to vpn.mydomain.com.  If you try to go to the user portal at https://vpn.mydomain.com:4443/ it works perfectly, says its secure, and the certificate is valid.  But if you go to https://vpn.mydomain.com:3400/ you get a invalid certificate error and that is what I'm failing on.

But this is how RED works? We do not use customer certificates for RED Process. 

https://community.sophos.com/kb/en-us/126454

How does the "Magic" work in RED: You deploy a RED, XG will create a config and certificate and push it to the provisioning server and RED will download it and connect to the XG. 

This process uses a selfsigned certificate. as far as i know, we also uses this certificate in the "Offline provisioning process". https://community.sophos.com/kb/en-us/122099

As far as i know, there is no workaround but i have many customers with passed PCI Tests and using RED. I am not a auditor. 

LuCar Toni said:

 

As far as i know, there is no workaround but i have many customers with passed PCI Tests and using RED. I am not a auditor. 

 

Like mentioned in the KBA:

https://community.sophos.com/kb/en-us/126989

"However the self signed certificate can be flagged as a problem on some security audits that don't take the full context of it's use into account. If this is the case, the following steps can be used to ensure that RED server port is only accessible from the source IP addresses of the RED devices themselves."

Tools will flag them RED because they simply looking for self signed and flag them red. 

LuCar Toni said:

"However the self signed certificate can be flagged as a problem on some security audits that don't take the full context of it's use into account. If this is the case, the following steps can be used to ensure that RED server port is only accessible from the source IP addresses of the RED devices themselves."

Again this is not a answer for a company like ours which has multiple RED devices in users homes and the IP addresses can change at any time (and do).  Instead of publishing work arounds maybe they should fix the problem, allow us to install a actual SSL certificate properly, and use that. 

I have the same issue with the fact the user portal is only allowed per a entire zone so it shows up on every external IP address instead of just the one we would want to use.  It just seems lazy to not fix things properly.

Funny fact: This is the Astaro setup since day 1. 

The point is: You would have to upload your privat key to a Sophos Server to get this properly working. And this would cause a whole new discussion. 

If you want to have another approach - replace RED with XG and perform IPsec Tunnel. With Central Management, you could do so.