How do I disable some cipher suites in Webserver Protection?

I have chased these issues, and what follows below are from my notes.  The current settings vary with the UTM release.   The new settings are suggestions, which you should be able to tailor to your preference by mimicking the examples.

HIGH, MEDIUM, and LOW are OpenSSL keywords which correspond to a bundle of ciphers.   Only HIGH ciphers are considered acceptable anymore.

To test the cipher results for any given keyword combination, you can use this command from the shell

openssl ciphers keywordlist

Except that not (like !MD5 ) commands, you need to add an escape from the shell, 

for example: 

openssl ciphers HIGH:\!MD5:\!SHA1

-------------------------------------------------

Applies to: WebAdmin, User Portal, Mail Manager, SPX Reply Portal

cd /var/sec/chroot-httpd/etc/httpd/

vi httpd.conf
--- Current -----
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AES:!ADH:!AECDH:!MD5:!DSS:!3DES
SSLProtocol +TLSv1.1 +TLSv1.2
--- New -----
SSLCipherSuite HIGH:!MD5:!SHA1
SSLProtocol +TLSv1.2
-------------

/etc/init.d/httpd restart

*** completed **** still have cert issue
==================================================================

Applies to: WAF ReverseProxy

cd /var/chroot-reverseproxy/usr/apache/conf/

vi httpd.conf
--- Current -----
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:ECDH+3DES:DH+3DES:RSA+3DES:!aNULL:!MD5:!DSS
SSLProtocol all -SSLv2 -SSLv3
--- New -----
SSLCipherSuite HIGH:!MD5:!SHA1
SSLProtocol +TLSv1.2
-------------

/var/mdw/scripts/reverseproxy restart

Excellent, Doug - thanks for holding on to that!

In newer versions, things are a little different for WAF.  Instead of making those changes in httpd.conf, they must be made in reverseproxy.conf which is now an Include in httpd.conf.

Before looking at reverseproxy.conf, I set "TLSv1.2" as the 'Minimum TLS version' on the 'Advanced' tab.  Instead of SSLProtocol all -SSLv2 -SSLv3, I found SSLProtocol -all +TLSv1.2, which meant that can be changed in the GUI.  BenediktWehr has suggested allowing a separate TLS setting in each Virtual Server definition;  I could find no place where the SSLCipherSuite could be permanently changed, so there's a risk that such a manual change might be overwritten.

Since there's an httpd.conf-default in /var/sec/chroot-httpd/etc/httpd/, I assume configuration changes in the GUI might also overwrite any manual changes.

Let's hope that one of the Sophos folks visits this thread.

Cheers - Bob

Those look more like they're related to IPsec.  I've not seen that in a PCI scan before.  Who's the PCI scanner?

Cheers - Bob

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?

Wow!  Did support agree to escalate this?