Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • +9 person also asked this people also asked this
  • Locked Locked
  • Replies 105 replies
  • Answers 1 answer
  • Subscribers 23 subscribers
  • Views 15535 views
  • Users 0 members are here
Options
Suggested
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

WAF issues after updating to 9.709-3

FrancWest

Hi,

anyone else noticed that after updating to 9.709-3 Exchange Web Services is not working anymore? We get HTTP Error 500 when connecting to EWS published trhrough WAF. Also, the virtual server changes to orange when this error occurs. Accessing EWS through the browser shows the service page after authentication, but when interacting with EWS by using the Exchange Remote Connectivity Analyzer or EWS Editor generates the HTTP 500 error and the WAF rule turns orange.

When directly connecting to EWS and bypassing UTM works fine and we can interact with EWS.

Before the update everything worked fine.

Franc.



This thread was automatically locked due to age.
  • 0 in reply to FrancWest

    Exactly this! This is unacceptable.

    Basically the answer from support means, that they won't fix NUTM-13425 because they would have to rewrite the WAF code, however they converted this issue into a feature request...because...you know...it is UTM...and we listen to your needs and requests....lulz

    Clearly there was no further development since years and therefore implementing this "feature request" will never happen.
    Support playing funny games right here!

    But, I think I did not miss a notice about retiring the UTM until now. So it still is a fully supported device.
    And this device got crippled with an update.
    So you should get your hands dirty rewriting that code.

    EWS functionality is part of UTM as stated in KB support.sophos.com/.../KB-000038003

  • 0 in reply to FrancWest

    What custom data was this Sophos?, sounds like a fob to me as all other firewalls running Apache seem to be OK.  Do you have the specifics?  When did Microsoft start using this customer extension 2010/2013/2016 or 2019?   where is this documented as I can't find anything on the internet.  Well it was nice whilst it lasted, now have to go fully over to Pfsense now.  Will be letting all my customers know this won't be fixed so more revenue lost.

  • 0 in reply to M Fuller

    No, I don’t have any more details. The statement I posted was the only one we got.

  • 0 in reply to M Fuller

    Classic Sophos, reply was (sadly) as expected

  • +1

    Sophos support came around and they opened a second case. Last week they implemented a patch for the issue and everything is working again now for us. I don't know the specifics of the fix. They created a development reference number for it: NUTM-13540

    Franc.

  • 0 in reply to FrancWest

    Great news! Thanks for the update....It´s been a while.

    Hopefully they will release the fix soon.

  • +1 in reply to FrancWest

    We have published the workaround in this KBA: Sophos UTM: WAF Not Working - [proxy_http:error] read less bytes of request body than expected

    Our team is also actively working in integrating this fix in a future release. 

    Best,

  • 0 in reply to Karlos

    Thanks!

    Are there any (negative) side effects after changing this option in Apache?

  • 0 in reply to FrancWest

    @FrancWest The KB article mentions newer apache version not compatible with non-standard protocols used newer MS products. Is more specific information available?   What nonstandard protocols?  Thank you.

  • 0 in reply to Karlos

    I just wanted to chime in that I've added this along with a fix for slash encoding (described here: https://community.sophos.com/utm-firewall/f/general-discussion/92242/utm-9-reverse-proxy-configuration/436406#pi2353filter=answers&pi2353scroll=false)

    Ultimately this is (part) of my current reverseproxy script with all the custom modifications:

    log() {
    ${APACHE2CTL_LOG}
}

apache_allowslashes() {
 grep -q 'PATH "/AllowEncodedSlashes/"' ${CHROOT}/usr/apache/conf/reverseproxy.conf
 MYRESULT=$?

 if [ ${MYRESULT} -eq 0 ]; then
 echo "AllowEncodedSlashes found - fixing" | log
 sed -i 's|WAFExceptions PATH "/AllowEncodedSlashes/" SkipAntiVirus|AllowEncodedSlashes On|g' ${CHROOT}/usr/apache/conf/reverseproxy.conf
 else
 echo "AllowEncodedSlashes not found - skipping" | log
 fi
}

apache_disable100continue() {
    grep -q 'PATH "/Disable100Continue/"' ${CHROOT}/usr/apache/conf/reverseproxy.conf
    MYRESULT=$?

    if [ ${MYRESULT} -eq 0 ]; then
      echo "Disable100Continue found - fixing" | log
      sed -i 's|WAFExceptions PATH "/Disable100Continue/" SkipAntiVirus|Proxy100Continue Off|g' ${CHROOT}/usr/apache/conf/reverseproxy.conf
    else
      echo "Disable100Continue not found - skipping" | log
    fi
}

apache_nocanon() {
 grep -q '/ProxyPassNocanon/' ${CHROOT}/usr/apache/conf/reverseproxy.conf
 MYRESULT=$?

 if [ ${MYRESULT} -eq 0 ]; then
 echo "ProxyPassNocanon found - fixing" | log
 sed -i 's|/ProxyPassNocanon/" lbmethod|/" nocanon lbmethod|g' ${CHROOT}/usr/apache/conf/reverseproxy.conf
 sed -i 's|/ProxyPassNocanon/|/|g' ${CHROOT}/usr/apache/conf/reverseproxy.conf
 else
 echo "ProxyPassNocanon not found - skipping" | log
 fi
}

    This permits changes to the Apache config on a per-webserver-basis and lets me use encoded slashes and disable the "100 continue" (whatever it actually is) for our on-prem DevOps server.

    Any chance you could permit some other settings for selected web servers in an official capacity (so custom scripts don't have to be used)? Like the "AllowEncodedSlashes On" setting showcased above?