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

Still struggling with this issue like AlanT was. 

Because i checked once again all my WAF XGs with TLS1.2 only, and it works fine with all my XGs without even change something in the config files at all. 

Used SSllabs to test my WAF. 

Also talked about this to some of my customers / partners. Nobody could relate to it. 

I assume, the config file / database got broken and rewrite all the time the "Use TLS1.0" back to your config. 

Can you post your (New) Sophos Support Case? So FloSupport can track it? 

PS: your screenshots are not readable. :) 

Sorry...copied the screen shots from the other thread and apparently they didn't size correctly.  I'll try to get them fixed.

As for a SSLLabs report with a non-edited httpd.conf file (I reset it) here are the results that I just ran (12/31/18 8:30 AM EST):

Again TLS 1.2 is enabled but it doesn't seem to care.  Only editing the httpd.conf file seems to fix this.  And my PCI compliance scans find the same thing so its not just them. Maybe I'll upgrade to 17.5 and see what happens if I don't hear anything back from AlanT in the near future.

Again, you need a Support Case. I honestly believe, your XG is rewritting something all the time because something was changed back in the days in your Database configuration. 

You could trigger the Support Case and giving the support all details, they need to check your log. 

I've entered a support case. Although I don't understand why I was asked for information if nothing is going to be done with it to try to solve this problem using it.  

As for writting all the time Again it is only after a firmware update. Something in the firmware update is rewriting that file. From what @AlanT said the file shouldn't be used at all but it obviously is based on the evidence. If I manually edit the file and then I don't update firmware again for 6 months then the system is secure for that 6 months. As soon as I update the firmware it is no longer secure until I edit the file again.

Do you use a HA? 

You opened a Case before (back in the days), did the Sophos Support maybe changed something on your system? 

I would say, there is something corrupt in your Backup file, which causes this behavior. That is my guess.

I highly suggest to open a Case to follow the correct process for this issue.

I do not use HA.

When I originally open the sport ticket, two years ago now, they said at the time the system didn't have an option for TLS 1.2 from the UI and that I needed to manually make the change through the councole. Which I did. I did nothing else other than follow their exact instructions to make the changes to httpd.conf.  and I have had to make the same changes with each firmware update since then. I'm not sure how that would be a corrupt backup file.

And again I opened up a new support case, explain what was happening, and provided a link to this thread.

After some back and forth this is what Support said:

"Version 17.5 GA has the settings for TLS version in WAF under General settings.  Kindly upgrade the device to latest version and after that if the issue persists then we can look into it further. "

I told them that setting has already been changed, change back, and changed again with no effect.  I pointed them to this thread but haven't gotten anything back.  Were my logs I sent to AlanT ever looked at?  Your support people don't seem to want to troubleshoot this until I upgrade but I shouldn't have to.  I am willing to upgrade if someone can tell me that the setting doesn't work prior to 17.5 but from what you and others have said it should.

Old support case #7105754.  New support case # 8551864.   And here is a copy and paste from the old support case and what they told me to do:

Hello Allan,

I have heard back from GES on this issue.  They have provided a workaround for now, below are the instructions to disable TLSv1.0 for WAF.

Workaround Solution :
# mount -no remount,rw /
# vi /usr/apache/conf/httpd.conf
-- Edit the following two lines with the lines in red color. before editing create a backup of the original file:

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

SSLCipherSuite 
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

# service apache:restart -ds nosync
#service WAF:restart -ds nosync
#mount -no remount,ro /


Please note this is only a workaround until the option to disable TLSv1.0 is included in the web admin of the XG. This will break an old legacy systems where DES and 3DES are the only supported ciphers "e.g. Windows XP clients or older versions of Windows Server.  This change will be overwritten by a software upgrade as well, every time you upgrade the firmware the workaround will need to be applied.

GES has informed me that the option to disable TLSv1.0 will be added in SFOS v17.


Regards,

Sophos Technical Support

Note the line that says this change will be overwritten by a software upgrade and need to be done each time?  That exactly what I've had to do for two years now.  Except changing the option in the UI doesn't fix it.

Again, i am not a Support Engineer. I can only rephrase my experience with other customers. None of my customers could reproduce this since V17.0 

All of them uses the Webadmin Option and it works fine. 

I cannot tell you, what was done with your Log files. But the basic process is, to talk to the Support people about this issue to get some information. 

There should be something wrong with your backup. You said back in the other Thread, you can reproduce this even after reinstalling your XG and restoring the config file, isnt it? 

I've never factory reset my XG and restored the backup, its on a production network and I don't really want to have to set it backup.  The problem is the httpd.conf gets reset with each firmware update to be insecure and it needs to be manually fixed.

As for your support people they just sent a reply and said I should update to 17.5 GA and once I do there should be a TLS 1.2 option under Web server -> General that will fix this.  However that setting is already there and doesn't fix anything.  I've told them this twice and they just keep repling with the same thing:

I have discussed this with my senior team and they have informed the same thing which I informed you. The version 17.5.0 GA has the feature to select the TLS version. You can manually set the TLS from there. TLS Version 1.2 you need to select and your issue with weak cipher should be resolved by selecting it.  After this selection when you upgrade the firmware further you should not be facing TLS version issue.

This setting has been around since 17.1?  At least for the last couple versions I've upgraded to but again it is not doing anything. 

Is there a bug fix that says 17.5 fixes this issue?  I haven't been able to find one.  I will upgrade if that's the fix but no one can tell me it is and I've already upgraded 10+ times with having to manually make the change each time.

This option is there since V17.0 GA. And it works for me and other customers. 

I am pretty sure, there is something broken in your config file (database). So the easy way to resolve this is: Update to the newest version ,set the flag to TLS1.2 and check, what is happening. If your WAF still uses TLS1.0, do not fix the config file, instead point to Support, this is broken, please fix it. 

Maybe you simply need to "resave" the configuration TLS1.2 and above and it will set the proper configuration. 

This option is there since V17.0 GA. And it works for me and other customers. 

I am pretty sure, there is something broken in your config file (database). So the easy way to resolve this is: Update to the newest version ,set the flag to TLS1.2 and check, what is happening. If your WAF still uses TLS1.0, do not fix the config file, instead point to Support, this is broken, please fix it. 

Maybe you simply need to "resave" the configuration TLS1.2 and above and it will set the proper configuration. 

I did try switching it to TLS 1.0, hitting save, waiting a few minutes, and switching back to 1.2.  Didn't make a difference.  And here is the problem with updating to 17.5:  Another user has the exact same issue as me and upgrading to 17.5 did not fix the problem (See this post and then he reconfirms all the same issues in this post).  I can try updating but if it didn't work for him and hes had the same issues then I don't see how it will work for me.  But again I can try.  When it doesn't work (not a lot of faith at this point) hopefully support can do something other then tell me it should work.   Hate to be "insecure" waiting for support to fix it properly instead of just editing the config myself but if that's what I have to do I will.

Also the real question is AlanT said in the other thread that the https.conf shouldn't be used at all anymore but it obviously is.  I know that not only by the TLS 1.0/1.1 and 3DES being enabled but I also fail on HTTP Trace Back which I fix by also editing that file. 

I feel like I'm just repeating the same stuff over and over. There is obviously a bug.  Its not affecting only me.  I've contacted support who is telling me its not a bug and I just need to change a setting which I've already done.  The then say I need to upgrade which another user already did and it didn't fix anything.  How do I get my case up to a higher level that can actually figure out whats wrong?  Or how do I get the logs that I already sent over three weeks ago looked at?

To be honest, i do not know, what i going on on your appliance. And i am not an engineer to be sure and giving a proper answer about which config file is be used. 

They could be some kind of fallback, if you edit something by yourself on CLI. 

Which logs did you send? Because, to be honest again, XG Logs are sometimes quite large without the proper point to be sure, what is going on. You need to enable some debug modes to see, what is going on. I would not be able to tell you, what was the issue, if i can not enable debug logging and using some switches. 

 I still guess, if you are editing something in the file, it is not the proper way to do it. But to confirm this, i would have to simply debug the system live, while the issue is active. You could also demand to schedule a remote session with support. They would remotely support your while doing the update and checking the Logs after the update. 

That is just my two Cents.

First of all, lets make sure that AlanT sees this post.  Next, this is the holiday season so we should all be patient with replies.

Next, can I summarize the problem as I see it?

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.  JonathanP 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?

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

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

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?

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.

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.

Michael Dunn - 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 JonathanP's system is still pointing to httpd.conf and using its rules.  Whats the next step?

Hi AllanD 

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,