Isilon ICAP-AV with c-icap + clamAV

[Pedro Pagan]

Hello all,

I'm trying to get our Isilon to work with a c-icap server running clamAV, as I've heard this is done regularly. My c-icap server is running fine and responded to AV requests from its own internal client, but OneFS shows "ICAP server is not responding" when I try to connect to it. I installed a trial version of a known-compatible ICAP AV scanner (Symantec Protection Engine) on the same machine and OneFS recognized it immediately. A packet capture shows that both the c-icap and Symantec servers respond with a "200 OK", but the overall response from Symantec's server is clearly different. My guess is that the Isilon is looking for something that c-icap isn't offering.

Has anyone gotten this Isilon/c-icap/clamAV setup to work? I've pasted the packet capture output below in case it'll help.

GOOD RESPONSE (From Symantec Protection Engine)

==========================

ICAP/1.0 200 OK

Date: Fri Mar 13 16:25:27 2015 GMT

Methods: RESPMOD, FILEMOD

Service: Symantec Protection Engine/7.5.1.5

Service-ID: Respmod AV Scan

ISTag: "D7E253A5E8AABF8B92ACCEF578FD980C"

X-Definition-Info: 20131021.001

Max-Connections: 128

X-Allow-Out: X-Outer-Container-Is-Mime, X-Infection-Found, X-Definition-Info, X-AV-License

X-Allow-Out: X-Violations-Found

Allow: 204

Options-TTL: 3600

Preview: 4

Transfer-Preview: *

X-AV-License: 0

Encapsulated: null-body=0

BAD RESPONSE (From c-icap running clamAV)

==========================

ICAP/1.0 200 OK

Methods: RESPMOD, REQMOD

Service: C-ICAP/0.3.5 server - Antivirus service

ISTag: CI0001-iM8tHylmHLKu14yvEQ+5IgAA

Transfer-Preview: *

Options-TTL: 3600

Date: Fri, 13 Mar 2015 16:27:11 GMT

Preview: 1024

Allow: 204

Encapsulated: null-body=0

Thanks.

[Jamie Ivanov]

Pedro,

That looks like an incomplete ICAP header. Some of the data elements that we look for are:

100 const struct icap_header_string icap_hdr[] = {
101 {"ISTag:", 6, ICAP_OPTIONS_ISTAG,
102     offsetof(struct icap_server_info, istag), false},
103    {"Methods:", 8, ICAP_OPTIONS_METHOD,
104        offsetof(struct icap_server_info, method), false},
105    {"Service:", 8, ICAP_OPTIONS_SERVICE_PROVIDER,
106        offsetof(struct icap_server_info, service_provider), false},
107    {"Service-ID:", 11, ICAP_OPTIONS_SERVICE_ID,
108        offsetof(struct icap_server_info, service_provider_id), false},
109    {"Options-TTL:", 12, ICAP_OPTIONS_TTL,
110        offsetof(struct icap_server_info, ttl), true},
111    {"X-Definition-Info:", 18, ICAP_OPTIONS_DEFINITION_INFO,
112        offsetof(struct icap_server_info, definition_info), false},
113    {"Max-Connections:", 16, ICAP_OPTIONS_MAX_CONNECTIONS,
114        offsetof(struct icap_server_info, max_connections), true},
115    {"Preview:", 8, ICAP_OPTIONS_PREVIEW_SIZE,
116        offsetof(struct icap_server_info, preview_size), true},
117    {"Transfer-Preview:", 17, ICAP_OPTIONS_TRANSFER_PREVIEW,
118        offsetof(struct icap_server_info, transfer_preview), false},
119    {"Transfer-Ignore:", 16, ICAP_OPTIONS_TRANSFER_IGNORE,
120        offsetof(struct icap_server_info, transfer_ignore), false},
121        {"Transfer-Complete:", 18, ICAP_OPTIONS_TRANSFER_COMPLETE,
122        offsetof(struct icap_server_info, transfer_complete), false},
123        {"Allow:", 6, ICAP_OPTIONS_ALLOW,
124        offsetof(struct icap_server_info, allow), false}

And seeing some of the application data is missing from the c-icap response, OneFS doesn't alter the ICAP server status to online seeing it can't process the header. Looking at the c-icap project documentation (http://sourceforge.net/p/c-icap/wiki/clamavtechnical/) I would recommend looking at the c-icap documentation.

While OneFS does boast compatibility with RFC 3507 compliant ICAP servers, there is still data that OneFS needs in order to understand what the server is capable of and ensure it has appropriate data back.

More detailed information from the pcaps may be helpful as well as debug information from the c-icap server to see if that reports anything specific.

Jamie Ivanov
Mobile: 608.399.4252
http://www.linkedin.com/in/jamieivanov
-- -- -- -- -- -- -- -- -- -- -- --
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jerry Uanino]

Does anyone have clam a/v working with another icap server other than c-icap?

[Jamie Ivanov]

Jerry,

Sounds like I have a weekend project. ;)

Pedro,

On the other hand, I heard that ClamAV support is going to be worked on in the future. That seems a little contradictory to the boasting: "OneFS supports anti-virus scan applications that follow the Internet Content Adaptation Protocol, or ICAP (ICAP RFC 3507), standard".

I think a case with Isilon support should be opened so they can investigate and file an escalation if necessary.

Jamie Ivanov
Mobile: 608.399.4252
http://www.linkedin.com/in/jamieivanov
-- -- -- -- -- -- -- -- -- -- -- --
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

[Scott Owens]

Pedro,

It appears the c-icap is not adhering to the RFC3507 for the ISTag output.

. Per RFC3507, the return should be

   The syntax of an ISTag is simply:
      ISTag = "ISTag: " quoted-string

In looking at the output from c-icap, the output is not quoted, which is different than the products that are working and would seem to be a deviation from the RFC3507 spec.

Kaspersky
--------------------------
ISTag: "KAVPROXY"

Symantec
--------------------------
ISTag: "3A30802306E6FCA2416679010E77FAE1"

c-icap
--------------------------
ISTag: CI0001-NgJDaXzq7eNcJYIO4MFnugAA


As a test, I updated the following 2 lines in the service.c file and recompiled
     strcpy(srv_xdata->ISTag, "ISTag: ");
     strcat(srv_xdata->ISTag, ISTAG "-XXXXXXXXX");

to
     strcpy(srv_xdata->ISTag, "ISTag: \"");
     strcat(srv_xdata->ISTag, ISTAG "-XXXXXXXXX\"");


Afterward, I was able to connect my cluster to the /echo service. A similar change would appear to be needed to allow connection to the /avscan or /virus_scan services of c-icap

Regards,
-Scott

[Pedro Pagan]

Wow, I would not have caught that just from looking at the pcaps. Good catch.

I'm going to edit the code and give it a try. I'll report back on how that goes.

[Pedro Pagan]

I edited the code and got it to reply via the echo service, but that's as far as it goes. I tried running an actual scan and the pcaps suggest that the isilon and c-icap don't speak the same dialect. We gave up and went with a known-supported icap-av solution. I'm planning to use this as an excuse to learn C - I'll try to modify c-icap to be isilon compatible. If anything ever comes of it, I'll let you guys know.