I have a special case here:
BigIP Version 13
HTTPS VS (SharePoint Web App with adapt request/response profiles)
ICAP VS (Internal with an icap profile)
ICAP sever Bluecoat ProxySG with a Symantec scan engine
When I upload a file with a size less than 100 MB SharePoint upload page sends the file to the SharePoint server in a single block with the header content-type mutilpart.
LTM ICAP client sends the file to the ICAP Server (bluecoat) and the file gets scanned and we get back a response according to what we expect. Pass if clean and block is virus detected.
Now if I upload a file bigger the 100 MB SharePoint switches to REST API mode and sends the file in multiple chunks of 8MB.
The LTM ICAP client sends the files to the ICAP server (bluecoat) and the files get scanned and we get a response for the all the files scanned BUT the answer is always 'file is CLEAN' even if we test with a 110 MB zip file containing an eicar file or multiple eicar files or even a pack or 500MB of real deadly viruses 🙂
SharePoint sends the file chunks in a JSON payload with the header ACCPET: application/json
Anyone managed to make file uploads bigger than 100MB scannable with this type of setup?
Any configuration steps I'm missing to make the 110MB zip file scannable when it arrives in small chunks on the ICAP server.
I understand that this might be an issue with the ICAP server but I want to rule out the LTM configuration.
We are talking to talking to Broadcom/Symantec too.
It will not be possible to do anything on the SharePoint side unfortunately since this is the preferred method of uploading large files.
I don't have a solution for your issue. However, I have an opinion I'd like to share. From my experience, I would recommend to limit the file size sent to the ICAP server. You could do that with an iRule for example. Or not to use ICAP at all and check for alternative places to scan the uploaded files for viruses.
Last time I tcpdumped a LTM ICAP setup (June 2020, BIG-IP v15.1), the file was uploaded to F5, sent to the ICAP server, scanned, sent back to the F5, and finally sent to the destination (SharePoint). For 100 MB file this means it was sent around around 3 times before it arrived on SharePoint. That's a lot of traffic on the wire and subjective wait time for the user.
An alternative could be to use ICAP with ASM / AWAF. In that combination the file won't be sent around between F5 and ICAP server, because the ICAP server will answer to the AWAF with either a 204 Unmodified (no virus) or a 403 Forbidden (virus found, x-header).
In my opinion it would be a better solution to use AV on the SharePoint server. I think if you enable RBS you can scan the files on the disk, because they are no longer stored in the DB. Or maybe there are AV products for SharePoint.