Wie signalisiert ein ICAP-Virenscanner einen Virenfund? Vollständige Übersicht mit konkreten Werten.

Question

Wie signalisiert ein ICAP-Virenscanner einen Virenfund? Vollständige Übersicht mit konkreten Werten.

Antwort

Verwandte Fragen

Warum antwortet ein Virenscanner über ICAP mit 'ICAP/1.0 200 OK', auch wenn ein Virus gefunden wurde?

Kann man über ICAP einen Ping an einen Virenscanner senden und wie sieht die Antwort im Response aus?

Wird bei der Kommunikation mit Virenscannern via ICAP häufiger REQMOD oder RESPMOD genutzt, und gibt es Ausnahmen von dieser Methode?

Wie sieht ein ICAP-Request im RESPMOD-Modus aus, wenn ein binäres Byte-Array unbekannter Länge zur Virenprüfung gesendet wird? Bitte vier Beispiele geben und die Request-Elemente sowie den Encapsulated-Header erläutern.

Wie sieht ein ICAP-Request im RESPmod aus, wenn ein Byte-Array mit Binärdaten zur Virenprüfung gesendet wird? Gib 4 Beispiele mit Arrays zwischen 4 und 30 Bytes.

Wie sieht ein ICAP-Request im respmod aus, bei dem ein Byte-Array zur Virenprüfung gesendet wird? Gib 8 Beispiele.

Welche bekannten Implementierungen für Virenscanner-Schnittstellen mit ICAPS-Protokoll gibt es?

Was kann im ICAP Allow-Header stehen und wie ist er aufgebaut? Gib 9 vielfältige, ausführliche Beispiele.

Accepted Answer

Ein ICAP-Virenscanner (z. B. Kaspersky, Sophos, McAfee, Symantec, Avira, ClamAV) kommuniziert Virenfunde über das ICAP-Protokoll an den ICAP-Client (z. B. einen Proxy wie Squid). Die Signalisierung erfolgt dabei über den HTTP-Statuscode und spezifische Header im ICAP-Response. Die genaue Ausgestaltung kann je nach Hersteller leicht variieren, aber es gibt typische und weit verbreitete Standards. **Typische Signalisierung eines Virenfunds durch einen ICAP-Virenscanner:** 1. **ICAP-Statuscode:** - `ICAP/1.0 200 OK` (Der Request wurde verarbeitet, aber das bedeutet nicht, dass kein Virus gefunden wurde! Die eigentliche Information steht in den HTTP-Headern.) 2. **HTTP-Statuscode im encapsulated HTTP-Response:** - `HTTP/1.1 403 Forbidden` (Oft bei Virenfund, um dem Client mitzuteilen, dass der Zugriff verweigert wird.) - Alternativ: `HTTP/1.1 200 OK` mit zusätzlichem Hinweis im Body oder Header. 3. **ICAP-spezifische Header:** - `X-Virus-ID: <Name des Virus>` (z. B. `X-Virus-ID: Eicar-Test-Signature`) - `X-Infection-Found: <Details>` (z. B. `X-Infection-Found: Type=0; Resolution=2; Threat=Eicar-Test-Signature`) - `X-Virus-Status: Infected` (Manchmal auch: `X-Virus-Status: Clean`) 4. **Body/Content:** - Der Body kann eine HTML-Seite mit einer Warnung enthalten, z. B. „Access Denied – Virus Found: Eicar-Test-Signature“. **Konkret sieht ein ICAP-Response bei Virenfund oft so aus:** ``` ICAP/1.0 200 OK Date: Fri, 07 Jun 2024 12:00:00 GMT Server: Example-ICAP-Server/1.0 Connection: keep-alive ISTag: "ICAPServer-123456" Encapsulated: res-hdr=0, res-body=234 HTTP/1.1 403 Forbidden Content-Type: text/html X-Virus-ID: Eicar-Test-Signature X-Infection-Found: Type=0; Resolution=2; Threat=Eicar-Test-Signature <html> <head><title>Virus Found</title></head> <body> <h1>Access Denied</h1> <p>Virus detected: Eicar-Test-Signature</p> </body> </html> ``` **Zusammenfassung der wichtigsten Werte:** | Header/Status | Typischer Wert bei Virenfund | |------------------------ |---------------------------------------------| | ICAP-Status | 200 OK | | HTTP-Status | 403 Forbidden (oder 200 OK mit Warnung) | | X-Virus-ID | Name des Virus (z. B. Eicar-Test-Signature) | | X-Infection-Found | Details zum Fund | | X-Virus-Status | Infected | **Herstellerspezifische Dokumentation:** - [Kaspersky ICAP](https://support.kaspersky.com/KICS/3.7/en-US/198670.htm) - [Sophos ICAP](https://docs.sophos.com/nsg/sophos-firewall/19.5/help/en-us/webhelp/onlinehelp/AdministratorHelp/WebProtection/ICAP/index.html) - [ClamAV ICAP](https://github.com/ehlers/clamav-icap) Die tatsächlichen Header und Werte können je nach eingesetztem Scanner und Konfiguration abweichen, aber die oben genannten sind branchenüblich.

Accepted Answer

Die Antwort „ICAP/1.0 200 OK“ bedeutet im ICAP-Protokoll nicht, dass die übertragene Datei virenfrei ist, sondern lediglich, dass die ICAP-Anfrage technisch erfolgreich bearbeitet wur... [mehr]

Accepted Answer

Die Antwort „ICAP/1.0 200 OK“ bedeutet im ICAP-Protokoll nicht, dass die übertragene Datei virenfrei ist, sondern lediglich, dass die ICAP-Anfrage technisch erfolgreich bearbeitet wurde. Das Protokoll trennt die technische Verarbeitung (Transportebene) von der inhaltlichen Bewertung (z. B. Virenfund). **Hintergrund:** - **ICAP (Internet Content Adaptation Protocol)** ist ein Protokoll, das von Proxy-Servern genutzt wird, um Inhalte (z. B. Dateien) an externe Dienste wie Virenscanner zu senden. - Die Antwort „200 OK“ signalisiert, dass der ICAP-Server (z. B. der Virenscanner) die Anfrage empfangen und verarbeitet hat – unabhängig vom Scan-Ergebnis. **Wie wird ein Virenfund signalisiert?** - Das eigentliche Scan-Ergebnis wird im Body der ICAP-Antwort oder in speziellen Headern (z. B. X-Virus-ID, X-Infection-Found) übermittelt. - Bei einem Virenfund kann der ICAP-Server z. B. die Datei ersetzen (mit einer Warnmeldung), einen Header setzen oder die Datei löschen/blockieren. - Nur bei einem technischen Fehler (z. B. Server nicht erreichbar, ungültige Anfrage) wird ein anderer Statuscode wie „500 Server Error“ oder „400 Bad Request“ zurückgegeben. **Fazit:** „ICAP/1.0 200 OK“ bedeutet, dass die Anfrage erfolgreich bearbeitet wurde – nicht, dass die Datei virenfrei ist. Das Scan-Ergebnis muss immer im Body oder in den Headern der ICAP-Antwort ausgewertet werden. Weitere Infos zum ICAP-Protokoll findest du z. B. hier: https://datatracker.ietf.org/doc/html/rfc3507

Accepted Answer

Ein klassisches „Ping“ im Sinne eines ICMP-Pings gibt es im ICAP-Protokoll nicht. ICAP (Internet Content Adaptation Protocol) ist ein Protokoll, das hauptsächlich dazu dient, HTTP-Anf... [mehr]

Accepted Answer

Ein klassisches „Ping“ im Sinne eines ICMP-Pings gibt es im ICAP-Protokoll nicht. ICAP (Internet Content Adaptation Protocol) ist ein Protokoll, das hauptsächlich dazu dient, HTTP-Anfragen oder -Antworten an externe Dienste wie Virenscanner oder Content-Filter weiterzuleiten, um diese zu modifizieren oder zu analysieren. **Möglichkeiten, einen ICAP-Server zu „pingen“:** 1. **OPTIONS-Request:** Das ICAP-Protokoll sieht den `OPTIONS`-Request vor, mit dem ein Client (z.B. ein Proxy) die Fähigkeiten und die Erreichbarkeit eines ICAP-Servers abfragen kann. Dies ist die gängige Methode, um zu prüfen, ob ein ICAP-Server (z.B. ein Virenscanner) erreichbar ist und welche Dienste er anbietet. **Beispiel für einen ICAP OPTIONS-Request:** ``` OPTIONS icap://icap-server.example.com/avscan ICAP/1.0 Host: icap-server.example.com User-Agent: MyICAPClient/1.0 ``` **Typische Response:** ``` ICAP/1.0 200 OK Methods: RESPMOD, REQMOD Service: MyAVScanner/1.2.3 ISTag: "AV123456" Options-TTL: 3600 Allow: 204 Date: Wed, 12 Jun 2024 10:00:00 GMT ``` Diese Antwort zeigt, dass der Server erreichbar ist und welche Methoden (z.B. REQMOD, RESPMOD) unterstützt werden. 2. **204 No Content:** Viele ICAP-Server unterstützen die Option, auf einen Request mit einem `204 No Content` zu antworten, wenn keine Modifikation notwendig ist. Dies kann auch als eine Art „Lebenszeichen“ interpretiert werden, ist aber kein klassischer Ping. **Fazit:** Ein dedizierter „Ping“ existiert im ICAP-Protokoll nicht, aber der `OPTIONS`-Request ist die standardisierte Methode, um die Erreichbarkeit und Fähigkeiten eines ICAP-Servers (z.B. Virenscanner) zu prüfen. Die Antwort enthält Statusinformationen und gibt Auskunft über die unterstützten Methoden und Dienste. **Weitere Informationen:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [Wikipedia: ICAP](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol)

Accepted Answer

Für die Kommunikation mit Virenscannern via ICAP (Internet Content Adaptation Protocol) wird in der Praxis überwiegend die **RESPMOD**-Methode verwendet. Das liegt daran, dass Virenscanner i... [mehr]

Accepted Answer

Für die Kommunikation mit Virenscannern via ICAP (Internet Content Adaptation Protocol) wird in der Praxis überwiegend die **RESPMOD**-Methode verwendet. Das liegt daran, dass Virenscanner in der Regel den **Antwortinhalt** (z.B. heruntergeladene Dateien, Webseiten) auf Viren oder Malware prüfen sollen, bevor dieser an den Client ausgeliefert wird. RESPMOD (Response Modification) ist dafür konzipiert, die Serverantwort zu modifizieren oder zu prüfen. **REQMOD** (Request Modification) wird seltener für Virenscanner eingesetzt, da hier die Anfrage des Clients an den Server modifiziert oder geprüft wird – was für Virenscanner meist weniger relevant ist, da sich Viren und Malware typischerweise im Antwortinhalt befinden. **Ausnahmen:** Es gibt jedoch Szenarien, in denen auch REQMOD genutzt werden kann, z.B. wenn Uploads (Dateien, die vom Client zum Server geschickt werden) auf Viren geprüft werden sollen. In diesem Fall wird die Anfrage (mit der hochgeladenen Datei) über REQMOD an den Virenscanner geschickt. **Zusammenfassung:** - **Standardfall:** RESPMOD für das Scannen von Downloads und Webseiten. - **Ausnahme:** REQMOD für das Scannen von Uploads. Weitere Informationen zu ICAP findest du z.B. bei [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507).

Accepted Answer

Ein ICAP-Request im RESPMOD-Modus (Response Modification) dient dazu, HTTP-Antworten (z.B. von einem Proxy) an einen ICAP-Server zu senden, etwa zur Virenprüfung. Das binäre Byte-Array (z.B.... [mehr]

Accepted Answer

Ein ICAP-Request im RESPMOD-Modus (Response Modification) dient dazu, HTTP-Antworten (z.B. von einem Proxy) an einen ICAP-Server zu senden, etwa zur Virenprüfung. Das binäre Byte-Array (z.B. ein Download) wird dabei als HTTP-Body im Encapsulated-Teil übertragen. Die Länge des Bodys ist durch Chunked-Encoding oder Content-Length geregelt. **Wichtige Request-Elemente:** - **Request-Line:** `RESPMOD icap://icap-server/virusscan ICAP/1.0` - **Header:** z.B. `Host`, `Encapsulated`, `Allow`, `Preview` - **Encapsulated:** Gibt die Offsets der eingebetteten HTTP-Nachrichten an (z.B. `res-hdr=0, res-body=...`) - **HTTP-Response-Header:** Die Original-HTTP-Antwort (z.B. `HTTP/1.1 200 OK`) - **HTTP-Body:** Das binäre Byte-Array, meist chunked übertragen --- ### Beispiel 1: ICAP-RESPMOD mit vollständigem Body (Content-Length bekannt) ``` RESPMOD icap://icap-server/virusscan ICAP/1.0 Host: icap-server Encapsulated: res-hdr=0, res-body=137 Allow: 204 Preview: 0 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 1024 <1024 Bytes binärer Datenstrom> ``` **Erläuterung:** - `Encapsulated` gibt an, dass die HTTP-Response-Header bei Offset 0 beginnen, der Body bei Byte 137. - Der Body ist 1024 Bytes lang. --- ### Beispiel 2: ICAP-RESPMOD mit Chunked-Encoding (unbekannte Länge) ``` RESPMOD icap://icap-server/virusscan ICAP/1.0 Host: icap-server Encapsulated: res-hdr=0, res-body=137 Allow: 204 Preview: 0 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 4 abcd 6 123456 0 ``` **Erläuterung:** - Body wird in Chunks übertragen, Länge ist nicht im Voraus bekannt. - `Encapsulated` wie oben. --- ### Beispiel 3: ICAP-RESPMOD mit Preview (Teilvorschau) ``` RESPMOD icap://icap-server/virusscan ICAP/1.0 Host: icap-server Encapsulated: res-hdr=0, res-body=137 Allow: 204 Preview: 128 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 1024 <128 Bytes Preview-Daten> ``` **Erläuterung:** - `Preview: 128` fordert, dass der Server nach 128 Bytes entscheidet, ob er mehr Daten braucht. - Nach dem Preview kann ein `100 Continue` oder ein `204 No Content` folgen. --- ### Beispiel 4: ICAP-RESPMOD mit nur Header (z.B. HEAD-Request) ``` RESPMOD icap://icap-server/virusscan ICAP/1.0 Host: icap-server Encapsulated: res-hdr=0 Allow: 204 Preview: 0 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 0 ``` **Erläuterung:** - Kein Body, nur Header werden übertragen. - `Encapsulated` enthält nur `res-hdr`. --- **Encapsulated-Header:** Der `Encapsulated`-Header ist entscheidend, da er die Offsets der eingebetteten HTTP-Header und -Bodys angibt. Beispiel: `Encapsulated: res-hdr=0, res-body=137` Das bedeutet: - Die HTTP-Response-Header starten bei Byte 0 nach den ICAP-Headern. - Der Body beginnt bei Byte 137. **Weitere Infos:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [ICAP-Server Beispiel: C-ICAP](http://c-icap.sourceforge.net/) **Zusammenfassung:** Ein ICAP-RESPMOD-Request kapselt HTTP-Antworten (Header + Body) ein, wobei der Body (z.B. ein binäres Byte-Array) per Content-Length oder Chunked-Encoding übertragen wird. Der `Encapsulated`-Header gibt

Accepted Answer

Ein ICAP-Request im RESPmod-Modus (Response Modification) wird verwendet, um z. B. HTTP-Antworten (inklusive deren Body) an einen ICAP-Server zu senden, etwa zur Virenprüfung. Die Daten werden da... [mehr]

Accepted Answer

Ein ICAP-Request im RESPmod-Modus (Response Modification) wird verwendet, um z. B. HTTP-Antworten (inklusive deren Body) an einen ICAP-Server zu senden, etwa zur Virenprüfung. Die Daten werden dabei im ICAP-Protokoll eingebettet, meist als encapsulierte HTTP-Response mit Chunked-Encoding. Binärdaten (z. B. ein Byte-Array) werden dabei als HTTP-Body übertragen, wobei die Chunks hexadezimal angegeben werden. Hier sind vier Beispiele für ICAP-Requests im RESPmod-Modus mit Byte-Arrays zwischen 4 und 30 Bytes. Die Beispiele zeigen jeweils den relevanten Ausschnitt (ICAP-Header, encapsulierte HTTP-Response, Chunked-Encoding mit Binärdaten). **Beispiel 1: 4 Bytes (0x01 0x02 0x03 0x04)** ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 4 \x01\x02\x03\x04 0 ``` **Beispiel 2: 8 Bytes (0xDE 0xAD 0xBE 0xEF 0xCA 0xFE 0xBA 0xBE)** ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 8 \xDE\xAD\xBE\xEF\xCA\xFE\xBA\xBE 0 ``` **Beispiel 3: 16 Bytes (0x00 bis 0x0F)** ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 10 \x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0A\x0B\x0C\x0D\x0E\x0F 0 ``` **Beispiel 4: 30 Bytes (0x41 bis 0x5E, also ASCII A bis ^)** ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked 1E \x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x5B\x5C\x5D\x5E 0 ``` **Hinweise:** - Die Chunk-Größe steht in Hexadezimal (z. B. `4` für 4 Bytes, `8` für 8 Bytes, `10` für 16 Bytes, `1E` für 30 Bytes). - Die Binärdaten werden im echten Request als rohe Bytes übertragen, nicht als `\x..`-Notation. Die Notation dient hier nur der Veranschaulichung. - Nach dem letzten Chunk (`0`) folgt ggf. noch ein CRLF. **Weitere Infos:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [ICAP Wikipedia](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol)

Accepted Answer

Ein ICAP-Request im `RESPMOD`-Modus dient dazu, Inhalte (z. B. HTTP-Antworten) an einen ICAP-Server zu senden, etwa zur Virenprüfung. Das Byte-Array, das geprüft werden soll, wird dabei als... [mehr]

Accepted Answer

Ein ICAP-Request im `RESPMOD`-Modus dient dazu, Inhalte (z. B. HTTP-Antworten) an einen ICAP-Server zu senden, etwa zur Virenprüfung. Das Byte-Array, das geprüft werden soll, wird dabei als Teil des HTTP-Bodys (z. B. als Dateiinhalt) im ICAP-Request eingebettet. Die Übertragung erfolgt meist chunked und kann beliebige Binärdaten enthalten. Hier sind 8 Beispiele für ICAP-Requests im `RESPMOD`-Modus, bei denen jeweils ein Byte-Array (hier als Hex-Darstellung) zur Virenprüfung gesendet wird. Die Beispiele zeigen jeweils den ICAP-Header, den eingebetteten HTTP-Response-Header und den Body (das Byte-Array als Chunk). **Hinweis:** - Die Byte-Arrays sind beispielhaft und kurz gehalten (jeweils 4 Bytes). - Die Chunk-Größe ist hexadezimal angegeben. - Die Zeilenenden sind mit `\r\n` markiert. --- ### Beispiel 1: Byte-Array `01 02 03 04` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \x01\x02\x03\x04\r\n 0\r\n \r\n ``` --- ### Beispiel 2: Byte-Array `DE AD BE EF` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \xDE\xAD\xBE\xEF\r\n 0\r\n \r\n ``` --- ### Beispiel 3: Byte-Array `FF EE DD CC` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \xFF\xEE\xDD\xCC\r\n 0\r\n \r\n ``` --- ### Beispiel 4: Byte-Array `00 11 22 33` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \x00\x11\x22\x33\r\n 0\r\n \r\n ``` --- ### Beispiel 5: Byte-Array `AA BB CC DD` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \xAA\xBB\xCC\xDD\r\n 0\r\n \r\n ``` --- ### Beispiel 6: Byte-Array `12 34 56 78` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \x12\x34\x56\x78\r\n 0\r\n \r\n ``` --- ### Beispiel 7: Byte-Array `FE DC BA 98` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1.0 Host: icap-server.example.net Encapsulated: res-hdr=0, res-body=137 HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 4 4\r\n \xFE\xDC\xBA\x98\r\n 0\r\n \r\n ``` --- ### Beispiel 8: Byte-Array `CA FE BA BE` ``` RESPMOD icap://icap-server.example.net/respmod ICAP/1

Accepted Answer

Bekannte Implementierungen für eine Virenscanner-Schnittstelle mit ICAP-Protokoll sind: 1. **Symantec Protection Engine (SPE)** [Symantec Protection Engine](https://www.broadcom.com/product... [mehr]

Accepted Answer

Bekannte Implementierungen für eine Virenscanner-Schnittstelle mit ICAP-Protokoll sind: 1. **Symantec Protection Engine (SPE)** [Symantec Protection Engine](https://www.broadcom.com/products/cyber-security/information-protection/protection-engine) bietet eine ICAP-Schnittstelle zur Integration in Proxy-Umgebungen. 2. **Kaspersky Anti-Virus for Proxy Server** [Kaspersky Security for Internet Gateway](https://www.kaspersky.com/small-to-medium-business-security/internet-gateway) unterstützt ICAP zur Anbindung an Proxy-Server. 3. **McAfee Web Gateway** [McAfee Web Gateway](https://www.trellix.com/en-us/products/web-gateway.html) kann als ICAP-Server fungieren und Virenscans über ICAP anbieten. 4. **Sophos Web Appliance** [Sophos Web Appliance](https://www.sophos.com/en-us/products/web-appliance.aspx) unterstützt ICAP für die Kommunikation mit Proxy-Servern. 5. **Avira AntiVir WebGate** [Avira AntiVir WebGate](https://www.avira.com/en/antivir-webgate) bietet ICAP-Unterstützung für die Integration in Proxy-Umgebungen. 6. **ClamAV mit c-icap** [c-icap](http://c-icap.sourceforge.net/) ist ein Open-Source-ICAP-Server, der mit [ClamAV](https://www.clamav.net/) kombiniert werden kann, um Virenscans über ICAP bereitzustellen. Diese Lösungen werden häufig in Kombination mit Proxy-Servern wie Squid oder Blue Coat eingesetzt, um Web-Traffic auf Viren und Malware zu prüfen.

Accepted Answer

Der **ICAP Allow Header** (`Allow`) gibt an, welche HTTP-Methoden ein ICAP-Server für eine bestimmte Ressource unterstützt. Er ist analog zum HTTP-`Allow`-Header und wird in ICAP-Antworten v... [mehr]

Accepted Answer

Der **ICAP Allow Header** (`Allow`) gibt an, welche HTTP-Methoden ein ICAP-Server für eine bestimmte Ressource unterstützt. Er ist analog zum HTTP-`Allow`-Header und wird in ICAP-Antworten verwendet, um dem Client mitzuteilen, welche ICAP-Methoden (z. B. `REQMOD`, `RESPMOD`, `OPTIONS`) für die angeforderte Ressource zulässig sind. **Aufbau:** ``` Allow: <Methode1>, <Methode2>, ... ``` Jede Methode wird durch ein Komma getrennt aufgelistet. **Beispiele:** 1. **Nur REQMOD erlaubt:** ``` Allow: REQMOD ``` *Der Server akzeptiert nur die Modifikation von HTTP-Anfragen.* 2. **Nur RESPMOD erlaubt:** ``` Allow: RESPMOD ``` *Nur die Modifikation von HTTP-Antworten ist möglich.* 3. **REQMOD und RESPMOD erlaubt:** ``` Allow: REQMOD, RESPMOD ``` *Sowohl Anfragen als auch Antworten können modifiziert werden.* 4. **Nur OPTIONS erlaubt:** ``` Allow: OPTIONS ``` *Nur die OPTIONS-Methode (zum Abfragen der Fähigkeiten) ist erlaubt.* 5. **Alle Standardmethoden erlaubt:** ``` Allow: REQMOD, RESPMOD, OPTIONS ``` *Der Server unterstützt alle gängigen ICAP-Methoden.* 6. **REQMOD und eine nicht standardisierte Methode:** ``` Allow: REQMOD, X-ARCHIVEMOD ``` *Neben REQMOD wird eine proprietäre Methode `X-ARCHIVEMOD` unterstützt.* 7. **RESPMOD und OPTIONS, Methoden in gemischter Groß-/Kleinschreibung:** ``` Allow: respmod, OPTIONS ``` *Methodennamen sind laut Spezifikation case-insensitive, aber meist werden sie groß geschrieben.* 8. **REQMOD, RESPMOD und eine hypothetische Methode:** ``` Allow: REQMOD, RESPMOD, X-LOGMOD ``` *Zusätzlich zu den Standardmethoden wird eine benutzerdefinierte Methode `X-LOGMOD` unterstützt.* 9. **Leerer Allow-Header (theoretisch, aber selten sinnvoll):** ``` Allow: ``` *Keine Methoden sind erlaubt – dies signalisiert, dass keine Operationen zulässig sind (praktisch selten verwendet).* **Hinweis:** Die Methoden `REQMOD` und `RESPMOD` sind die beiden Standard-ICAP-Methoden. `OPTIONS` ist für die Abfrage der Fähigkeiten des Servers vorgesehen. Proprietäre oder nicht standardisierte Methoden beginnen oft mit `X-`. Die Groß-/Kleinschreibung ist laut RFC 3507 nicht relevant, aber Konvention ist Großschreibung. **Weitere Informationen:** - [RFC 3507 – ICAP-Protokoll](https://datatracker.ietf.org/doc/html/rfc3507#section-4.5) - [ICAP-Methoden (Wikipedia)](https://en.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol#ICAP_methods)