Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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

413 Request entity too large

In the WAF configuration If an user upload a file greater than 1 Mb receives the error 
Request body no files data length is larger than the configured limit - 413 Request entity too large

 

I found in the UTM you can modify the squid.conf-default, but I didn´t fine anythig about th XG.

 

Someone will know how to increase the Mb??



This thread was automatically locked due to age.
  • Are you referring to a Web Application Firewall rule, I think you can make an exception in there, but you may have to do trial and error to see which protection is pull the 413 error.

    Respectfully, 

     

    Badrobot

     

  • Did you ever find anything out on this?

    Respectfully, 

     

    Badrobot

     

  • Nothing yet, i´m still trying.

    I´ll let you know

  • I have been working with Sophos on this very issue since 7/25/19 as well! what a strange small world we live in.

    So far I have been escalated through the tiers and I'm currently waiting for a developer to return a phone call. 

    I know this much so far, The error is pertaining to the setting defined for ModSecurity : SecRequestBodyNoFilesLimit.  

    The default setting is: 1048576bytes of course you already know that. 

    It seems apparent that the UTM machines and the XG get and store this information in very different ways and even the top level engineers aren't sure how to apply the tweak.

    The problem I see so far is this, older UTM KB documents tell the engineers to bump the tblwafsecurityprofile record item sec_request_body_no_files_limit ="<new value>" restart the WAF and call it good..

    This doesn't work on the XG.

    So for example lets say you update the db to the size you want, and then to trigger a regeneration of the /cfs/waf/reverseproxy.conf (Included to Apache via httpd.conf) file you add an exception(skip) to your policy from the GUI and click save, The page generates a new /cfs/waf/reverseproxy.conf file with the new exception and updates the database.

    But if you take a look at the record now, What you will see is that the db will revert back to the default size setting.

    The SecRequestBodyNoFilesLimit is defined in another file somewhere..and this is where the GUI is getting the default value for this setting that it uses to populate the /cfs/waf/reverseproxy.conf file that controls your WAF.

    I can see that /usr/apache/conf/waf/base.conf contains an entry defining SecRequestBodyLimit 1GB (1073741824) which is ironically the hard stop max size for this configuration directive but for us we need to find where to define SecRequestBodyNofilesLimit..

    I speculate that this is the file we're looking for.. I can only assume that if the configuration directives are not explicitly defined they will simply behave with their defaults.

    Perhaps a simple addition of the entry would override the defaults to our size of choice? i.e. "SecRequestBodyNofilesLimit 10485760" for a 10Mb limit

    The issue I'm dealing with is that we aren't permitted to browse the directory structure and make changes without the supervision of an engineer or you risk violating your service agreement, and since the XG doesn't have an ftp server enabled easy directory tree structure perusing isn't available.

    I'm hoping to have a developer on the line today.. if so I will update this post and this issue should be in their KB.

    If you hear anything let me know as well.

    Good luck.

  • Yes the same here.

     

    I also have a case, also waiting for the response.

     

    As soon as I know something I´ll let you know too.

     

  • Hi  &  

    My sincere apologies for this inconvenience, would it be possible to PM me with your support case number so that I can follow up accordingly?

    Regards,


    Florentino
    Director, Global Community & Digital Support

    Are you a Sophos Partner? | Product Documentation@SophosSupport | Sign up for SMS Alerts
    If a post solves your question, please use the 'Verify Answer' button.
    The Award-winning Home of Sophos Support Videos! - Visit Sophos Techvids
  • Hello.

    This asset has been scaled to GES team. We hope to have some update shortly.

    Cheers.

    Channel SE 

  • Thanks for that, although everyone I've spoken to right down to my vendor had told me the same thing.

    I am hoping that my findings are correct.. this would prove useful to so many others.

    So after looking a little more into it, It does seem plausible that the setting for SecRequestBodyNoFilesLimit NUMBER_IN_BYTES would in fact be placed in the /usr/apache/conf/waf/base.conf file just beneath the existing SecRequestBodyLimit entry.. I say this because according to the modsecurity docs by default ModSecurity defines the SecRequestBodyLimit as 134Mb here in the base.conf it's being set to 1GB (the hard limit).. I just want someone to call me back and get this applied.. 

    How am I expected to support a device that it's own support, can't seem to be able to support.. 

    Bring back the SG!!

  • This is interesting, I have worked with modsecurity before and I know it can be tricky, but this should just be a value setting.  This leads me to think there is some other aspect in WAF that is defining the limit.  

     

    Also I did look in my base.conf file as well, mostly curious and wanting to learn some more on the XG, but I see mine as set above 1GB-

    SecRequestBodyLimit 1073741824

    Which and I am assuming this value it bytes would represent 1073.741824 MB or 1.073741824 GB, which would put it past the hard limit????

     

    Respectfully, 

     

    Badrobot

     

  • Ok, so ModSecurity runs on Apache and Apache uses the ReverseProxy.conf file to define it.. the XG gui builds this file every time you click save after a change is made to the config.. 

    From what I'm gathering from the ModSecurity docs, If the configuration directives are not defined they will presumably just adhere their default settings.. This is why I believe that the value in the reverseproxy.conf file may be getting populated with the default value.

    As to if the value is passed to the parser as a query against the service or from another configuration file I cant say because I'm not going to reverse engineer the GUI.

    But by adding the definition to the base.conf might (if it's referenced during generation) update the environment variable that passes to the reverseproxy.conf and also the db.

    This method would also fall in line with the way that the old squid.conf-default update worked.

    While the XG is a very different animal under the hood than the UTM, ModSecurity 2.x still runs the same.. I honestly feel that it's just a matter of knowing where the directives are defined and make the change there.

    We shall see.

    There are tons of directives, it makes sense that they behave with defaults instead of having them all defined in a big cluttered file adding unnecessarily to environmental overhead.

    My suggestions have been sent over to the developers for review. we'll see if I'm on the right track.

    While I wouldn't suggest that anyone with a contract or device in production make these changes.

    If anyone with a spare device that is out of contract or in a lab environment and you go against the grain to try this, could you report back the results? That would be great.

     

    oh, btw...

    1 GiB = 1073741824 bytes (= 10243 B = 230 B).

     

    But you knew that...   ;-)