Cannot POST files >60KB via BIGIP LTM
Hi, My Customers are facing an issue wherein the users not able to POST files >60KB to an application abc.xyz.com hosted on BIGIP. Below is the error they see, {"errors":["errors.adt.ci.metainfo.provider.not.found "]} However, they are able to send directly to the backend server without any issues. For the above VS on BIGIP, the default HTTP profile has been attached wherein the Maximum Header Size is as around 32KB. Is there anyway to increase this file limit or solve this issue ??? Thanks in advance, MSK
Unable to Upload File Through iControl REST Interface
I am attempting to upload a file through the iControl REST interface using iControl BIG-IP v12 getting a response code 400 with a response body of: {"remainingByteCount":0,"usedChunks":{"0":5},"totalByteCount":5,"localFilePath":"/var/config/rest/downloads/test.txt","temporaryFilePath":"/var/config/rest/downloads/tmp/test.txt","generation":0,"lastUpdateMicros":1475011484946186} I am using token auth. I am at a loss as to why this is giving back a 200, any help would be greatly appreciated. I can answer any questions that will help give us clues. Here are the headers that I have: Content-Type: "text/plain" Content-Range: "0-4/5" Content-Length: "5" Transfer-Encoding: "chunked" And the response debug data: server: "com.f5.rest.common.RestRequestSender" x-frame-options: "SAMEORIGIN" pragma: "no-cache" cache-control: "no-store, no-cache, must-revalidate" expires: "-1" content-length: "231" content-type: "text/plain; charset=ISO-8859-1" content-range: "0-4/5" local-ip-from-httpd: "xxx.xxx.xxx.xxx" accept-encoding: "gzip;q=1.0,deflate;q=0.6,identity;q=0.3" x-forwarded-server: "localhost.localdomain" x-forwarded-proto: "http" x-forwarded-host: "xxx.xxx.com" x-content-type-options: "nosniff" x-xss-protection: "1; mode=block" content-security-policy: "default-src 'self' 'unsafe-inline' 'unsafe-eval'" strict-transport-security: "max-age=16070400; includeSubDomains" connection: "close"
ASM Blocking Image Uploads
Hello We have a Rest API using JSON which accepts an image as part of the payload. The image is Base64 Encoded and generally works well however we have had some instances where the Base64 encoding contains a string that the ASM believes is an attack and blocks the payload. I have on a couple of these disabled the signature on the specific JSON profile however I would prefer not to have to do this. I was thinking of asking our Developers to consider a change to the API to accept the image as a file upload rather than Base64 Encoding it into the JSON payload. We control both the Client and Server side of the connection so I do not have to wait for clients to make changes to the API. There is also a self diagnostic Rest Service that takes debug information in and this too also experiences blocks on occasions, again I was thinking this too should be a file upload rather than a post of JSON formatted (the JSON is not always very well formatted due to the data within). Has anyone got any other suggestions that would help resolve this in a more simplistic way. James
Multiple violaions for File-upload behind ASM
Hello Folks, I am experiencing quite weird behavior with F5 ASM on 11.6.0 HF6 with one of the customers. The issue is, ASM is detecting file uploading as a malicious traffic and triggering multiple different signatures. Though I have created a file uploading parameter, which found from the HTTP REQUEST HEADER within "multipart/form-data". However it seems ineffective. Following is the complete HTTP REQUEST. POST /epublicsector_ara/start.swe?SRN=KLyBkgFt7u1DMFqJX4yyLqXNbSyceuTBcqcSB4KzKcgb HTTP/1.1 SWESession: TS01d3802b=011bd6b25032ca6b64b728506e93375f4851f91fa2362a319f7ff7390920ffb3781595bbf4ff1db9dd55f89a7367c3113fb808b1d410723dd3805ffe617641dcd661da8c82; SWEUAID=none; SGCRM-COOKIE=3935173898.20480.0000; TS0160d34b=011bd6b250cc5c5419ac4c3d1645b0be3eeda26635f3e94a2e94ba76915da8199f08ec69d177fcca8a8938559fa14b5b3940f9c495 Content-Type: multipart/form-data; boundary=------------------------------1453093530 Content-Length: 88852 Connection: Keep-Alive User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3) Host: 1gov.abudhabi.ae Cache-Control: no-cache Cookie: _sn=OQ0ZDiRGueyA88dyhdKGs6B4gHCYXPRHfrMe6zxEYnLS.JwbT1OMP8iVOAg1ZaB7IYpcyX4IlQQxNAOTGpU7yqT0StvTXa6ssmT1YcV3ZU9wrDSMvchu6DPcDAzDPFDGLkZhsJmNzJh.Rp23kIB.N84iEdgjsExDoNe5GryIJzDcJypyYJaZuAQnhFZAXqs4alaabrpoH4Y_; TS01d3802b=011bd6b25032ca6b64b728506e93375f4851f91fa2362a319f7ff7390920ffb3781595bbf4ff1db9dd55f89a7367c3113fb808b1d410723dd3805ffe617641dcd661da8c82; SWEUAID=none; SGCRM-COOKIE=3935173898.20480.0000; TS0160d34b=011bd6b2504813b2ac7dbc505636fef65aa62b48dadbd2f087624e744621fcb2297ee21aaf7d873a84e117fc409408d273ef1a6af2 X-Forwarded-For: 10.113.0.25 ------------------------------1453093530 Content-Disposition: form-data; name="SWEView" HLS Case Note View ------------------------------1453093530 Content-Disposition: form-data; name="SWEApplet" HLS Case Attachment Applet ------------------------------1453093530 Content-Disposition: form-data; name="SWERowIds" SWERowId0=1-KUA4ND ------------------------------1453093530 Content-Disposition: form-data; name="SWECmd" InvokeMethod ------------------------------1453093530 Content-Disposition: form-data; name="SWEMethod" NewFileAttachment ------------------------------1453093530 Content-Disposition: form-data; name="SWERPC" 1 ------------------------------1453093530 Content-Disposition: form-data; name="s_SweFileName"; filename="C:%5cUsers%5cm.rashed%5cDesktop%5cNew%20folder%20(7)%5c%d8%a8%d9%82%d8%a7%d9%84%d8%a9.pdf" Content-Type: application/octet-stream %PDF-1.4 1 0 obj << /Creator (Oracle11gR1 AS Reports Services) /CreationDate (D:20151004082642) /ModDate (D:20151004082642) /Producer (Oracle PDF driver) /Title () /Author (Oracle Reports) >> endobj 5 0 obj <> ... ....... The File Uploading Parameter I have created is "s_SweFileName" , also followed the below article which I thought will be useful in this scenario, but that didn't help. https://devcentral.f5.com/articles/file-uploads-and-asm Can anyone help me fine-tuning / understanding what needs to be done to avoid this false positive? It is tedious job to keep on ignoring all the signatures and also relaxing security to that level is not acceptable, right? Looking for your help. Thank you, DarshanHow to block exe-File - uploads with extension unlike exe
It seems that ASM allows the upload of executables whose extension was changed from .exe to something different. If the extension is .exe, the request gets blocked as expected. Configuration: The the parameter was explicit declared as FileUplod - Type with the option enabled 'Disallow File Upload of Executables'. Furthermore the corresponding Learning and Blocking Setting: 'Disallowed file upload content detected' was also set to Learn / Alarm / Block.
Troubleshoot LTM file upload
I need assistance troubleshooting an LTM file upload problem: A web server allows browser based file uploads. However, when I move the server behind the LTM, the files are not passed. I don't see anything in the logs. I'm not running ASM or anything else that should be blocking/rejecting/stripping the files. I've never had an issue like this, so I'm not really sure where to begin. Appreciate any ideas. LTM v.11.3.x Standard Virtual Server using SSL termination (tried as Performance Layer 4 as well, no change) No iRules in place Test file is an blank .txt