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

Default httpd.conf for WAF enables insecure Protocols/Suites (TLS1, TLS1.1, 3DES) and enables Trace/Track on each firmware update

This is a continuation of https://community.sophos.com/products/xg-firewall/f/firewall-and-policies/109122/failing-pci-scans-because-of-outdated-jquery-in-user-portal---is-there-a-fix/391323#391323 but a new thread was requested by LuCar Toni here: https://community.sophos.com/products/xg-firewall/f/firewall-and-policies/109122/failing-pci-scans-because-of-outdated-jquery-in-user-portal---is-there-a-fix/392533#392533

 

 

On a fresh install of any firmware to a XG appliance the WAF settings allow insecure protocols and 3DES in addition to Trace/Track.  This has been a issue going back over two years (previous post: : https://community.sophos.com/products/xg-firewall/f/firewall-and-policies/84480/failing-pci-scans---how-do-i-disable-tls-1-0-and-block-des-3des/368398#368398 )

 

Demonstration of what is happening.  After any firmware upgrade I have a PCI compliance scan done and get the following results:

 

 

I highlighted the failures on 3DES and TLS 1.0.  So I telnet in and check the appache httpd.conf file and this is whats in it:

 

 

Sure enough all those protocols are reenabled on each firmware upgrade.  I then manually edit that file to remove 3DES, TLSv1, TLSv1.1, and TraceTrack so it looks like this:

 

 

and restart the services (per instructions support gave me and I blogged about here). I then rescan and I no longer fail due to those items:

 

 

This is happening to multiple people on this forum and who have commented on my blog post.  Settings within the UI (mainly the "TLS setting") do not affect this behavior.

 

This is happening on 3 seperate XG boxes, one XG310 and a pair of XG125w.  All three were installed at different times and the last XG125W shipped with v17, the other two started with v16.  All three exhibit the same behavior on each firmware upgrade, the "secure" settings get wiped out and replaced by a "insecure set".




[locked by: FloSupport at 7:33 PM (GMT -8) on 11 Jan 2019]
  • Yes, I posted a SSL Labs result above. It finds the exact same thing the PCI compliance scan finds. So you're right..... That would be much quicker.  I'll try that this Sunday and report back.  My feeling is it's any rule since I'm sure Jonathan's setup is different then mine but has the same issue.

    We'll see.

  • OK, did some testing that hopefully will help figure out whats going on:

    • Turned off all firewall rules for web servers at 80/443
    • Ran a SSL Labs assessment against our primary external IP (which resolves to vpn.mydomain.com).  Got "Assessment failed: Unable to connect to the server " which would be expected but I just wanted to have a baseline.
    • Switched my user portal from port 4443 over to 443.  It has a valid SSL certificate (same vpn.whgardiner.com)
    • Ran the SSL Labs assessment again.  Got a "A+" rating, TSL 1.0 and 1.1 were disabled as was 3DES.  Couple weak ciphers but overall great.
    • Switched the user portal back to 4443.  Did another scan just in case.  Go the same assessment failed as expected.
    • Turned on one of the firewall rules for a server at cloud.mydomain.com (different IP address then vpn.mydomain.com).  This site is a file sharing site that also has a valid SSL both on the XG and on the backend IIS server.
    • Ran the SSL Labs assessment again.  Got a "A" rating and it showed both TLS 1.0 and 1.1 are enabled as was 3DES.
    • Turned that rule off and turned on one of the Outlook rules which has Exchange 2013 on the backend
    • Ran the SSL assessment again.  Same thing, got a "A" rating and it showed TLS 1.0, 1.1 and 3DES all enabled.

     

    So User portal is correctly protected, TLS 1.0, TLS 1.1, and 3DES are all disabled.  But any of my web forwarding rules all are not unless I manually edit httpd.conf to disable those.  I also tried with all the firewall rules disabled switching the TLS setting (under web server -> general settings -> TLS version setting) to TLS 1.0, saving it, then back to 1.2, saving it, then reenabling all the rules thinking maybe it wouldn't enable if a rule was using it but it had no effect.

     

     

    - Based on the above if WAF is used for the firewall rules but NOT for the user portal then your assumption that's it's only WAF would be correct.  And it seems my system and apparently 's system is still pointing to httpd.conf and using its rules.  Whats the next step?

  • Hi  

    Thank you for following up with your investigation.

    I have located your support case and I am following up with your assigned engineer to discuss the next steps to further the investigation. Please don't hesitate to reach out to me via PM if you had any concerns or questions regarding your case.

    Regards,

  • After talking with support back and forth I upgraded to 17.5.0 GA and my TLS 1.0, 1.1, and 3DES issues went away both with my PCI compliance scan company and SSL Labs.  So good news for me, bad news for  (since he already upgraded and it didn't fix his issue).

    I still however am getting a "HTTP TRACE/TRACK Methods Enabled".  If I add "TraceEnable off" to the httpd.conf file it fixes this but that isn't a solution so waiting on support to get back to me and tell me how to fix that correctly without manually editing files.  Unless it ends up being another workaround.

  • AllanD said:

    I still however am getting a "HTTP TRACE/TRACK Methods Enabled".  If I add "TraceEnable off" to the httpd.conf file it fixes this but that isn't a solution so waiting on support to get back to me and tell me how to fix that correctly without manually editing files.  Unless it ends up being another workaround....

     

     

    Hi Community,

    Please see below for KB article on how to disable "HTTP TRACE/TRACK Methods" if you are using the WAF module.

    https://sophos.com/kb/133363

    Thanks!