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

  • In reply to Michael Dunn:

    - I agree with pretty much everything you said. 

    However here are some questions.  In my original support case two years ago (case numbers above) this file apparently was used as your tech support people said it was and said I had to manually change it.  I'm assuming you can look up that case and verify this.  Since then I have had to do this for every firmware update, throughout 16.* and 17.*.  At what point did it stop getting used and reverse proxy take its place?  Could the fact mine was edited mess something up during a firmware update?  I doubt it based on you saying it gets overwritten each time.  Why would it even exist if its not used?

    Or better yet how is my system still using it and how do I, and others with this issue, fix it.  has the same issue on a XG450 that came pre-installed with 17 and exhibits the exact same issues.  He has since upgraded to 17.5 but it didn't help.

    Whats the next step?

  • In reply to AllanD:

    I've upgraded to 17.5 and the issue still happens.  I purchased the XG450 with 17.x pre-loaded.  I had to follow the steps for my XG450 to pass trustwave PCI scan. 

  • In reply to AllanD:

    Hi AllanD,

    Things change over the years and this is not my area of expertise.  Support sometimes also comes up with their own "solutions" which are really workarounds.  So I (myself) do not know exactly how it works nor when it changed.  I do not think that the fact you edited the file makes a difference, however I do suspect that there is something in your configuration causing this.  It might be a combination of features and configuration that can be done in WebAdmin, or it is a byproduct of a change that was made by you/support on the backend.

    An example (and I'm not saying this is the issue, I'm just throwing darts) would be that XG uses the Zones (WAN, LAN, DMZ) to help control what traffic can flow in what direction.  If you somehow had a port in the LAN zone exposed and serving out your traffic on the WAN I could see that it could fail PCI scans.

    If you turn off WAF completely, does this problem go away?  I presume that turning off WAF will make it so that no apache is listening anywhere on that external port, so there is no web access at all.  That would prove that WAF is the key part to this issue (which is only a presumption at this point).

    knows more about this area than I, though he's actually a manager not a low level techie.  He knows the people who should know.  I'm not sure if he is back from winter holidays.  :)  You could send the configuration to me, but I can only do a cursory glance at him.  AFAIK you have sent it to Alan, and I think the next step is seeing what he says.

  • In reply to Michael Dunn:

    No, can't think of ever exposing any LAN ports out.  Plus again changing the config fixes it.

     

    I can attempt to turn off WAF and rescan.  The issue with this is we host Outlook Anywhere, OMA, OWA, and a couple websites so they would be down during this time.  Also our PCI compliance scans usually take upward of a hour or so to complete.  I'll see if I can do it Sunday when usage is low.  Whats the easiest way to do this?  Disable all business application rules going to 80/443?

  • In reply to AllanD:

    Agreed re LAN, but the underlying point is that sometimes configuration can have unintended consequences.  We've seen customers who create an ANY/ANY/ANY rule as a temporary workaround, and then forget about it and leave it in place for a year.  Ugh!

     

    Did you also see this when doing the ssllabs.com scan?  That should be much quicker.

    I would turn off all incoming business rules for 80/443, scan, and confirm that nothing comes through.

    Then turn on a single rule (eg your "main" one) and scan again.  If it is still good, turn on more rules.  Maybe we hit the jackpot and find out that the problem is associated with a particular rule.

  • In reply to Michael Dunn:

    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.

  • In reply to Michael Dunn:

    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?

  • In reply to AllanD:

    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,

  • In reply to FloSupport:

    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.

  • In reply to AllanD:

    AllanD

    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!