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 Reply Children
  • 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

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