Wie ist der HTTP-Teil eines ICAP-Requests an einen Virenscanner aufgebaut, um binäre Daten direkt zur Überprüfung zu senden?

Question

Wie ist der HTTP-Teil eines ICAP-Requests an einen Virenscanner aufgebaut, um binäre Daten direkt zur Überprüfung zu senden?

Antwort

Verwandte Fragen

Wie ist der ICAP-Dialog mit einem Virenscanner, wenn die Preview-Größe größer als die Chunk-Größe ist, und welche Daten werden dabei an den Scanner gesendet?

Wie läuft der Dialog mit einem Virenscanner via ICAP ab, wenn ein Preview in mehreren Chunks gesendet wird, und welche Daten werden an den Scanner geschickt?

Wie erkenne ich bei einem Virenscan über ICAP anhand von 'ICAP/1.0 204' oder 'ICAP/1.0 200', ob die Daten virenbehaftet sind?

Accepted Answer

Um binäre Daten (z. B. eine Datei) direkt an einen Virenscanner über das ICAP-Protokoll zu senden, wird typischerweise der ICAP-Request mit einem eingebetteten HTTP-Request oder HTTP-Response aufgebaut, in dessen Body die zu prüfenden binären Daten enthalten sind. Die meisten Virenscanner erwarten dabei eine HTTP-Response mit einem Content-Body. **Beispiel für einen ICAP-Request (REQMOD oder RESPMOD) mit binären Daten:** Angenommen, du möchtest eine Datei prüfen lassen, dann wird meist das RESPMOD-Kommando verwendet. Der Aufbau sieht so aus: ``` RESPMOD icap://virenscanner.example.com/scan ICAP/1.0 Host: virenscanner.example.com Allow: 204 Encapsulated: res-hdr=0, res-body=xxx HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: <Länge der Datei in Bytes> <binäre Daten der Datei> ``` **Erklärung der wichtigsten Teile:** - `RESPMOD icap://... ICAP/1.0`: ICAP-Request-Zeile, gibt das Kommando und die Service-URL an. - `Encapsulated`: Gibt an, ab welchem Byte-Offset im ICAP-Request die jeweiligen HTTP-Teile beginnen. `res-hdr=0` bedeutet, dass die HTTP-Response-Header direkt nach den ICAP-Headern beginnen. `res-body=xxx` gibt den Offset an, ab dem der Body (also die binären Daten) beginnt. - Der eingebettete HTTP-Response-Header (`HTTP/1.1 200 OK` usw.) ist erforderlich, weil ICAP immer HTTP-Nachrichten kapselt. - Im Body folgt dann die Datei im Binärformat. **Chunked Encoding (optional):** Falls die Datei sehr groß ist oder die Länge nicht bekannt ist, kann auch Chunked Transfer Encoding verwendet werden. Dann sieht der Body so aus: ``` HTTP/1.1 200 OK Content-Type: application/octet-stream Transfer-Encoding: chunked <chunked binäre Daten> ``` **Wichtige Hinweise:** - Die genaue Implementierung kann je nach Virenscanner und ICAP-Server leicht variieren. Die Dokumentation des jeweiligen ICAP-Dienstes sollte beachtet werden. - Die ICAP-Spezifikation findest du hier: [RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - Beispielhafte Implementierungen und weitere Details findest du z. B. bei [C-ICAP](http://c-icap.sourceforge.net/) oder [Symantec ICAP](https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-network-security/proxySG/6-7/icap-and-icap-adaptation/Content/Topics/ICAP/icap_intro.htm). **Zusammengefasst:** Der HTTP-Teil im ICAP-Request besteht aus einem vollständigen HTTP-Response-Header (z. B. `HTTP/1.1 200 OK`), gefolgt von den binären Daten im Body. Die ICAP-Header geben an, wo die jeweiligen Teile beginnen.

Accepted Answer

Ein Dialog mit einem Virenscanner via ICAP (Internet Content Adaptation Protocol) läuft typischerweise so ab, dass ein ICAP-Client (z. B. ein Proxy) eine Anfrage an einen ICAP-Server (z. B. einen... [mehr]

Accepted Answer

Ein Dialog mit einem Virenscanner via ICAP (Internet Content Adaptation Protocol) läuft typischerweise so ab, dass ein ICAP-Client (z. B. ein Proxy) eine Anfrage an einen ICAP-Server (z. B. einen Virenscanner) sendet, um Inhalte prüfen oder modifizieren zu lassen. Dabei wird der zu prüfende Inhalt oft in Chunks (Teilstücken) übertragen. Die "Preview"-Funktion von ICAP erlaubt es, dem Server zunächst nur einen Teil der Daten zu schicken, damit dieser entscheiden kann, ob er den Rest benötigt. **Szenario:** Die Preview-Größe (z. B. 1024 Bytes) ist größer als die Chunk-Größe (z. B. 512 Bytes). Das bedeutet, dass der Client mehrere Chunks senden muss, um die gewünschte Preview-Größe zu erreichen. **Beispielhafter Ablauf und gesendete Daten:** 1. **OPTIONS-Anfrage (optional, zur Feature-Erkennung):** ``` OPTIONS icap://icap-server.example.com/scan HTTP/1.1 Host: icap-server.example.com ``` 2. **REQMOD/RESPMOD-Anfrage mit Preview:** ``` REQMOD icap://icap-server.example.com/scan ICAP/1.0 Host: icap-server.example.com Allow: 204 Preview: 1024 Encapsulated: req-hdr=0, req-body=... ``` 3. **HTTP-Header (z. B. bei REQMOD):** ``` GET /file.exe HTTP/1.1 Host: www.example.com ... ``` 4. **Body mit Chunks (ICAP verwendet HTTP/1.1 chunked encoding):** - **Erster Chunk (512 Bytes):** ``` 200 <512 Bytes Daten> ``` - **Zweiter Chunk (512 Bytes):** ``` 200 <weitere 512 Bytes Daten> ``` - **Preview-Ende (null chunk mit "ieof" für "End of Preview"):** ``` 0; ieof ``` **Gesamte gesendete Daten (vereinfacht):** ``` REQMOD icap://icap-server.example.com/scan ICAP/1.0 Host: icap-server.example.com Allow: 204 Preview: 1024 Encapsulated: req-hdr=0, req-body=... GET /file.exe HTTP/1.1 Host: www.example.com ... 200 <512 Bytes Daten> 200 <weitere 512 Bytes Daten> 0; ieof ``` **Erklärung:** - Die Preview-Größe ist 1024 Bytes, aber die Chunks sind nur 512 Bytes groß. - Der Client sendet also zwei Chunks à 512 Bytes, um die Preview zu erfüllen. - Nach dem zweiten Chunk wird mit `0; ieof` signalisiert, dass das Ende der Preview erreicht ist. - Der Server entscheidet nun, ob er den Rest der Daten benötigt (204 oder 100 Continue). **Weitere Infos:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [Beispiel für ICAP-Dialoge](https://www.openicaps.org/icap/icap_faq.html) **Zusammenfassung:** Wenn die Preview-Größe größer als die Chunk-Größe ist, sendet der Client mehrere Chunks, bis die Preview-Größe erreicht ist, und signalisiert das Ende der Preview mit `0; ieof`.

Accepted Answer

Ein Dialog mit einem Virenscanner via ICAP (Internet Content Adaptation Protocol), bei dem ein Preview in mehreren Chunks gesendet wird, läuft typischerweise wie folgt ab: **1. ICAP-REQMOD-Anfra... [mehr]

Accepted Answer

Ein Dialog mit einem Virenscanner via ICAP (Internet Content Adaptation Protocol), bei dem ein Preview in mehreren Chunks gesendet wird, läuft typischerweise wie folgt ab: **1. ICAP-REQMOD-Anfrage mit Preview-Header:** Der ICAP-Client (z. B. ein Proxy) sendet eine REQMOD- oder RESPMOD-Anfrage an den ICAP-Server (Virenscanner). Im Header wird die Größe des Previews angegeben, z. B. `Preview: 1024`. **Beispiel für die an den Scanner gesendeten Daten:** ``` REQMOD icap://virenscanner.example.net/scan ICAP/1.0 Host: virenscanner.example.net Allow: 204 Preview: 1024 Encapsulated: req-hdr=0, req-body=... [weitere Header] [HTTP-Anfrage-Header] [leere Zeile] [Body beginnt, falls vorhanden] ``` **2. Senden des Preview-Chunks:** Der Client sendet die ersten N Bytes (z. B. 1024) des Bodys als Preview. Die Daten werden im Chunked-Encoding übertragen. ``` 400 [1024 Bytes Preview-Daten] 0; ieof ``` - `400` ist die Hexadezimalzahl für 1024 (Größe des Chunks). - `0; ieof` signalisiert das Ende des Previews, aber nicht zwingend das Ende des gesamten Bodys. **3. Antwort des ICAP-Servers:** Der Server kann jetzt entscheiden: - **204 No Modification Needed**: Keine weitere Datenübertragung nötig. - **100 Continue**: Der Server benötigt mehr Daten. **Beispiel für 100 Continue:** ``` ICAP/1.0 100 Continue ``` **4. Senden weiterer Chunks:** Der Client sendet die nächsten Chunks des Bodys, jeweils im Chunked-Encoding-Format: ``` 400 [weitere 1024 Bytes] 400 [weitere 1024 Bytes] ... 0 ``` - Jeder Chunk beginnt mit der Größe in Hex, gefolgt von den Daten. - Das letzte Chunk ist `0`, was das Ende des Bodys signalisiert. **Zusammengefasst:** - **Header mit Preview-Angabe** - **Preview-Chunk (z. B. 1024 Bytes)** - **Warten auf 100 Continue** - **Weitere Chunks senden, bis der Body komplett ist** **Beispiel für die gesendeten Daten (vereinfacht):** ``` REQMOD icap://virenscanner.example.net/scan ICAP/1.0 Host: virenscanner.example.net Preview: 1024 Encapsulated: req-hdr=0, req-body=... [HTTP-Header] [leere Zeile] 400 [1024 Bytes Preview] 0; ieof [Warten auf 100 Continue] 400 [weitere 1024 Bytes] 400 [weitere 1024 Bytes] 0 ``` **Weitere Informationen:** - [ICAP RFC 3507](https://datatracker.ietf.org/doc/html/rfc3507) - [Wikipedia: ICAP](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol) Die genaue Struktur kann je nach Implementierung und verwendetem ICAP-Client leicht variieren.

Accepted Answer

Beim Einsatz von ICAP (Internet Content Adaptation Protocol) zur Virenprüfung gibt der ICAP-Server nach der Analyse einer Datei eine Antwort an den Client zurück. Die wichtigsten Statuscodes... [mehr]

Accepted Answer

Beim Einsatz von ICAP (Internet Content Adaptation Protocol) zur Virenprüfung gibt der ICAP-Server nach der Analyse einer Datei eine Antwort an den Client zurück. Die wichtigsten Statuscodes sind dabei: - **ICAP/1.0 200 OK**: Die Anfrage wurde erfolgreich bearbeitet und der Inhalt wurde möglicherweise verändert (z.B. weil ein Virus entfernt oder die Datei blockiert wurde). - **ICAP/1.0 204 No Content**: Die Anfrage wurde erfolgreich bearbeitet, aber der Inhalt wurde **nicht** verändert (d.h. die Datei ist sauber und musste nicht angepasst werden). **Wie erkennst du, ob die Daten virenbehaftet sind?** 1. **ICAP/1.0 204 No Content** Bedeutet: Die Datei ist **sauber**. Der ICAP-Server hat keine Bedrohung gefunden und den Inhalt nicht verändert. 2. **ICAP/1.0 200 OK** Bedeutet: Die Datei wurde **verändert** oder es gibt zusätzliche Informationen. Das kann verschiedene Gründe haben: - Die Datei wurde desinfiziert (Virus entfernt). - Die Datei wurde blockiert (z.B. durch einen Ersatzinhalt ersetzt). - Es wurden Warnhinweise hinzugefügt. **Ob die Datei virenbehaftet war, erkennst du an den ICAP-Headern und ggf. am Inhalt der Antwort:** - Prüfe die Header wie `X-Virus-ID`, `X-Infection-Found` oder ähnliche, die vom Virenscanner gesetzt werden. - Bei einer Blockierung oder Desinfektion enthält die Antwort oft einen Ersatzinhalt (z.B. eine HTML-Seite mit Warnung). - Die genaue Bedeutung und die verwendeten Header hängen vom eingesetzten ICAP-Virenscanner ab (z.B. [Symantec](https://www.broadcom.com/products/cyber-security/information-protection/advanced-threat-protection), [Kaspersky](https://www.kaspersky.com/enterprise-security/icap), [Sophos](https://www.sophos.com/en-us/products/web-appliance/icap-support.aspx)). **Zusammengefasst:** - **204** = Datei ist sauber. - **200** = Datei wurde verändert oder blockiert → Prüfe die spezifischen Header und den Inhalt, um zu erkennen, ob ein Virus gefunden wurde. **Tipp:** Die genaue Implementierung und die verwendeten Header solltest du in der Dokumentation deines ICAP-Virenscanners nachlesen, da es keine allgemeingültigen Standard-Header für Virenfunde gibt. Weitere Infos zu ICAP: - [RFC 3507 (ICAP-Standard)](https://datatracker.ietf.org/doc/html/rfc3507) - [Wikipedia: ICAP](https://de.wikipedia.org/wiki/Internet_Content_Adaptation_Protocol)