JensD

Oh, and we were going to use the ICAP feature to scan data that our customers place in our own custom written document management software using our own ICAP-client - definitely not a NAS, but definitely something where we want to scan the data our customers tell us to store for them.

Yes, I quite agree. I tried to get through the support, and I was plain and simply told that what I wanted was not supported. The supporter wrote (over several back-and-forth mails): I have asked our developers about this. Our ICAP solution works with file servers as File Security. We support some other solutions, but in our product the HTTP request for files are blocked. This is to prevent using ESET Server Security as Gateway security, and this is by design. So in this case where you use telnet, it will be blocked and the output will be 405 forbidden. ... I have been told that the purpose of the ICAP service in ESET Server Security for Linux is for NAS scanning, as listed here: https://help.eset.com/efs/8.1/en-US/file-and-folder-structure.html(lib/icapd – ICAP service for NAS scanning) Which ICAP clients are supported are listed here: https://help.eset.com/efs/8.1/en-US/remote-scanning.html So there is no support for custom written solutions. In the end the "best" product that supportes ICAP for anything else but large enterprise NAS products was the Gateway Security product that was discontinued and EOL'ed in 2021 (https://support.eset.com/en/kb3592-is-my-eset-product-supported-eset-end-of-life-policy-business-products) and in the end they could not help me. In the end I ended up using c-icap and ClamAV since there seemed to be no way of getting any kind of sensible help getting the build in ICAP-service in EFS to work with anything else but those enterprise NAS products. I considered getting hold of Dell (we're a pretty large customer of theirs and they usually go a long way to help us) and get their help by way of tcpdumping or simply proxying a ICAP scanning request from Dell EMC Isilon and see what magic headers it sends along with the request so EFS is happy, but in the end c-icap and ClamAV (with variuos exclusions for EFS to allow those two systems to work without triggering EFS) was easier. Quite a pity if you ask me - and I have not enough clout with ESET to make someone help me there (and since every support request goes through a local reseller it's more or less impossible to get to talk to someone technical who could help..).

Hi I have written to support and I am waiting for a reply. Currently I am simply looking for a proof of concept for using ICAP for scanning fileuploads in a system. However I am quite surprised that it seems to be limited to a known list of clients, as my attempts so far has been via a simple telnet connection and no client is in play. This might be a dealbreaker for us (turning us away from everything ESET since nowhere has there been any mention of ONLY supporting some clients, but just a "yeah, turn on ICAP and point your client towards here - then we'll scan your data, no worries.."), but I'll take that with support. Regards, Jens Dueholm

Hi Running efs-8.1.813.0-1.x86_64 on RHEL8 I'm trying to get ICAP scanning to work, but I keep getting "405 Forbidden" on requests that should be correct in syntax and with correct lengths etc etc. For example: jedc@web14:/home/jedc>$ telnet 192.168.80.134 1344 Trying 192.168.80.134... Connected to 192.168.80.134. Escape character is '^]'. RESPMOD icap://192.168.80.134/av_scan ICAP/1.0 Host: "192.168.80.134" Encapsulated: req-hdr=0, res-hdr=137, res-body=296 GET /origin-resource HTTP/1.1 Host: www.origin-server.com Accept: text/html, text/plain, image/gif Accept-Encoding: gzip, compress HTTP/1.1 200 OK Date: Mon, 10 Jan 2000 09:52:22 GMT Server: Apache/1.3.6 (Unix) ETag: "63840-1ab7-378d415b" Content-Type: text/html Content-Length: 51 33 This is data that was returned by an origin server. 0; ieof ICAP/1.0 405 Forbidden Encapsulated: null-body=0 ISTag: "f358759c53de6188-1642286804" Connection closed by foreign host. What is happening here? Changing some of the lengths etc changes the response into "ICAP/1.0 400 Bad request", so my attempt must be close.. Do I need to use a particular User-Agent, set an Authorization-header or what is happening here? Regards, Jens Dueholm