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

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.
  • 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.  

  • 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.

     

  • Switching to XG's wouldn't make sense when we've already invested over $4k in RED devices.  Literally have spent more on RED's then the XG310 they are connecting to.

    I understand the uploading certificates part but there should be a way to assign a SSL certificate on the XG box for RED device use then when one comes online the Sophos servers check the XG, see the certificate, and use that for the RED devices.  So there is no uploading to Sophos manually and it gets by this issue "properly".

     

    Self signed certificates shouldn't be used on anything externally facing and that is what is causing me to fail the PCI compliance scan.  And again the work around is not usable when IP addresses can and will change.

     

    I'll keep working with my scanning company...