How do I disable some cipher suites in Webserver Protection?

Yes my apologies, in addition to the SSL VPN users they also have an IPSec tunnel built between two of their locations. The profile being used is the default Sophos AES-256 PFS (ACC) which is using DH group 5 and PFS group 5. The PCI scanner is Trustwave

I think all that is required is to delete the offending ciphers from the configuration at:   Site-To-Site VPN... IPSEc... Policies (tab). 

The Policies list seems to be one of the few places in UTM where a feature does not have an on/off switch.

I think your constraints are:

• Encryption algorithms:   Any variant of AES
• Hash Algorithm:   Any variant of SHA2
• DH And PFS groups:   Group 14 or higher

Remote Access SSL VPN can only be configured with one ciphersuite, so I would be troubled if UTM offered more options than what the GUI says it will offer.  Glad that it appears to have been a false alarm on this item, but please let us know if it reappears as a concern.

Thanks for the reply. That was my initial thought- just delete the policies. But in some cases I'm seeing policies that cannot be deleted (the ones that say "[(auto-generated by ACC)]")

I've attached an image to show an example of what I mean. I may be overlooking something obvious but I have no idea how those were created. The blue background and the text that says "acc-agent.plx" makes me think they were created by the SUM manager, but I've never pushed any IPSec policies using SUM and I'm pretty sure I've seen those policies exist on units that were fresh from the factory. How do I delete those?

I don't know.   I have only one option that is not removable:

L2TP-over-IPsec [Policy used for L2TP-over-IPsec]
Compression off, not using strict policy.
IKE Settings: 3DES / SHA1 / Group 14: MODP 2048 Lifetime: 28800 seconds
IPsec Settings: 3DES / MD5 / Null (None) Lifetime: 3600 seconds

However, L2TP-over-IPSEC is off, and I do not see anywhere that the ciphersuite can be configured.

Sounds like a good question for support.   We will eagerly await your findings, because lots of us have to worry about PCI.

I would make a config backup before deleting anything.  I don't think deleting the policies deletes the underlying ciphers and DH groups.  Note that deleting a policy doesn't change the ciphers and DH groups offered in the configuration of a policy.

If they're not using any IPsec-based remote access (L2TP/IPsec, IPsec or Cisco) and are just using Site-to-Site, blackhole DNAT all IPsec traffic except that from the other ends of the tunnels:

1. NoNAT : {IPs of desired connections} -> IPsec -> {Group of all "(Address)" objects on WAN interfaces}
2. DNAT   : Internet IPv4 -> IPsec -> {Group of all "(Address)" objects on WAN interfaces} : to {240.0.0.1}

Refer to #2 in Rulz.

Cheers - Bob

RE: "I don't think deleting the policies deletes the underlying ciphers and DH groups."

The system allows you to roll your own IPSEC policies from the component parts, and the components are fixed lists, so I cannot imagine that the components would be deleted either.  But the policies are what is available for offer to an IPSEC connection, so removing the policy should be sufficient for the PCI complaint, at least for the ones that the system will permit to be removed.

Some of those hits in the scan were for non-existent combinations in the policies I see here, Doug, e.g., 3DES/SHA/DH-Group-5.

Cheers - Bob

So the long story short is if you enable the 'Strict Policy' option on the IPSec policy it resolves the issue. Why that isn't by default, I have no idea. And why the Sophos will respond to IPSec policies that aren't even listed in profiles, and in fact claim to be disabled entirely in the config files under the hood, Sophos support doesn't know.

I did my own scanning to verify and found that without the 'Strict Policy' option enabled the Sophos will respond to and negotiate a SA with the following:

Wow!  Did support agree to escalate this?