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 53290 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.
  • 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 Bill Roland

    Bill (or Sophos),

    I'm probably over-thinking this and I know it's been a year+, but can you help me understand what you did here?:


    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

    I'm still showing the port is reporting as open.

    Rule 1:
    Source, zone = WAN
    Source, allowed clients = Any

    Destination Host, public IP
    Services = RED (TCP3400)

    Forward to
    Protected server = LAN IP of Sophos XG
    Protected zone = LAN

    Rule 2:
    Source, zone = LAN
    Source, allowed client = Sophos XG LAN IP

    Destnation host, public IP
    Services, RED

    Forward to
    Protected server = Dead-end (10.254.253.252) (non existent subnet on my network)
    Protected Zone = LAN

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