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

  • 0 in reply to John Woodall

    So I believe we only need 1 rule - unless I have an issue in the future with another RED appliance.

    I just forwarded the WAN to LAN, port TCP 3400 to the dead-end IP and now it shows as stealth/closed.

    As someone said the Tunnel only uses UDP 3400 for traffic I think I should be okay when adding a new appliance or when one reboots.

  • 0 in reply to John Woodall

    Did you already use TLS1.2 for RED only? 

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

    As far as i know, this is enough for PCI. 

    But there is also a KBA for this (UTM). https://community.sophos.com/kb/en-us/126989

    What they do, and what you have to do is:

    Build up a DNAT rule from Branch office to your IP of WAN and DNAT Port 3400 to your local LAN IP.

    Then Clone this DNAT and use ANY instead your Branch office and DNAT this to nowhere. 

    Reason: The certificate chain is complete; however, it is not trusted by
    our root certificate store.

    If this is your reason to fail, it is kinda ... Yeah that is how RED works. Self Signed certificate is used by RED. 

    So basically you hide the RED for everybody else so only your branch office IP (if this is possible with static IP or DynDNS) can access the RED service of XG. 

  • 0 in reply to John Woodall

    Hi John,

    What I did was create two rules, although one may be enough (perhaps I'll experiment after this post).  My first rule is a DNAT Allow rule from WAN to LAN, my allowed network is the static IP of my RED device, and the protected server its mapped to is the XG's internal IP.  I then have a rule below that rule where I deny everything to port 3400 by routing it to a null IP, but since the RED hits the allow rule above it, it works.  

    This was enough to satisfy my PCI scans.  I tried appealing  the scan result but they denied my appeals, so, had to figure out a way to close it off.  

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

  • 0 in reply to AllanD

    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.

     

  • +1 in reply to LuCar Toni

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

Reply
  • +1 in reply to LuCar Toni

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

Children
No Data