Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 25 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 53291 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

PCI Scan failing due to RED Port 3400

Bill Roland

Hi all,

So my quarterly PCI scan completed overnight and I failed due to Port 3400 being open and in particular having the following problems:

SSL Self-Signed Certificate

SSL Certificate with Wrong Hostname

SSL DROWN Attack Vulnerability (Decrypting RSA with Obsolete and Weakened eNcryption)

SecurityMetrics will not allow me to ignore these to pass, so I have to do something.  I've read quite a bit about this problem over on the UTM forum, and the guidance seems to be that I need to create a DNAT rule to accept port 3400 from the IP of my RED, and then create a DNAT rule below that to route all other internet traffic to Port 3400 to a null interface.  Is that same guidance applicable to the XG?

Very surprised this is still a problem. 

Thanks in advance.



This thread was automatically locked due to age.
Parents
  • 0

    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-

  • 0 in reply to sachingurung

    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. 

  • +1 in reply to Bill Roland

    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. 

  • 0 in reply to Bill Roland

    , 

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

    This is a security issue that must be addressed.

    Regards

Reply Children
  • 0 in reply to lferrara

    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

  • 0 in reply to sachingurung

    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.

  • 0 in reply to Bill Roland

    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

  • 0 in reply to sachingurung

    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

     

    PM sent.  Thanks!

  • 0 in reply to sachingurung

    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.

  • 0 in reply to sachingurung

    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.

  • 0 in reply to AllanD

    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. 

  • 0 in reply to LuCar Toni

    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. 

     

    Can you speak more to this?  I implemented a workaround to essentially shield the RED from the PCI scanner, but I am very curious how they are passing PCI scans if they are using RED's without any kind of trickery.  I have used both SecurityMetrics and Trustwave and they both ding the RED.  

  • 0 in reply to Bill Roland

    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. 

  • 0 in reply to LuCar Toni

    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.