HCL Connections bietet die Möglichkeit, sowohl Upload- als auch Download über den IBM HTTP Server abzuwickeln. Das ist performancetechnisch aus verschiedenen Gründen sinnvoll: Grundsätzlich ist WebSphere für den Dateiupload nicht optimal geeignet, vor allem wenn es sich um größere Dateien handelt. Auf dem Server entsteht dabei eine hohe Last. Beim Download größerer Videos kam es dadurch bereits zu einer Überlastung, obwohl vergleichsweise wenige Nutzer sie heruntergeladen haben.
Als Lösung bietet sich mod_ibm_upload an: Es verschiebt den Upload auf den vorgelagerten IBM HTTP Server (IHS), einem Apache2-Fork. Dieser sendet lediglich Metadaten (Dateiname, Größe usw) an den WAS, um die Datei in Connections zu registrieren. Der Dateiinhalt, welcher vom Nutzer hochgeladen wird, muss hierbei nicht an WAS gesendet werden – Dies führt zu einer deutlichen Entlastung des WebSphere-Servers. Außerdem lässt sich das nicht mehr zeitgemäße Limit von 4GB pro Datei via IHS erhöhen.
Probleme mit dem Virenscan durch den IHS
Connections bietet eine Schnittstelle, um jegliche hochgeladene Dateien von einem externen Virenscanner prüfen zu lassen. Auf den Sinn und Unsinn von AVs möchte ich an dieser Stelle nicht weiter eingehen – es war in dieser Umgebung eine Anforderung, daher wurde der Scan über den bereits vorhandenen Virenscanner aktiviert. Bis zur Aktivierung des Uploads per IHS war dies auch weitgehend unauffällig im Hintergrund.
Nun haben die Nutzer in letzter Zeit aber zunehmend Fehlermeldungen beim Download erhalten, die vor einem fehlenden Virenscan warnten:
Weder in den Logs von Connections noch bei den Kollegen vom Virenscanner wurde ein Grund gefunden. Anfangs schien es alle Dateien zu betreffen. Nach einer ausführlicheren Analyse zeigte sich, dass besonders kleine Dateien keine Warnmeldung erhalten. Dies konnte auf 16 MB eingegrenzt werden. 16 MB war in der files-config.xml als Limit für die SimpleUploadAPI festgelegt. Das bedeutet: Alles unter 16 MB leitet der IHS an WAS weiter und agiert hier lediglich als Reverse-Proxy. Ab 16 MB wickelt der IHS den Upload selbst mithilfe von mod_ibm_upload ab. Es konnte reproduziert werden, dass der IBM HTTP Server den Virenscan nicht durchführt.
So speichert Connections den AV-Scanstatus einer Datei
In der Tabelle FILES.MEDIA der Dateien-Anwendung gibt es eine Spalte MALWARE_SCAN. Der Wert 1 steht für nicht gescannt. Dies hat in der Regel externe Ursachen, beispielsweise ein Timeout beim Virenscanner oder ähnliches. Ist MALWARE_SCAN gleich 1, erscheint obige Warnmeldung. Ansonsten gibt es nur noch den Status 2 für überprüfte Dateien. Ob der Virenscanner bei seiner Prüfung etwas gefunden hat, vermerkt Connections nicht in der Datenbank.
Das hängt wohl damit zusammen, dass Connections keine Dateien im System behält, die aus Sicht des AV infiziert sind. Testen lässt sich das mit einem Eicar-Testvirus. Darin ist eine spezielle Zeichenfolge enthalten, auf die Virenscanner anspringen. Im folgenden Beispiel habe ich eicar.zip mit diesem Testvirus in Connections hochgeladen und anschließend eicar_download.zip aus Connections wieder heruntergeladen:
$ sha256sum *.zip
88cacb01739eaa240517ea5c181789d5d7705b4b7c79f56e426b45e05818c946 eicar_download.zip
a2ff6af2c04d27f5890127a2b447e7bed80e1c34c1cf62215a193f0ce3b5ffa4 eicar.zipWie man sieht, wurde die Datei verändert. Schauen wir uns den Inhalt an, wird klar, was passiert ist:
$ unzip -l eicar
Archive: eicar.zip
Length Date Time Name
--------- ---------- ----- ----
68 2011-06-16 09:35 eicar.com
--------- -------
68 1 file
$ unzip -l eicar_download.zip
Archive: eicar_download.zip
Length Date Time Name
--------- ---------- ----- ----
123 2011-06-16 09:35 DELETED0.TXT
--------- -------
123 1 file
$ zmore *.zip
::::::::::::::
eicar_download.zip
::::::::::::::
File: no.file/eicar.com was infected with EICAR Test String (11101). File not submitted to quarantine. File was deleted.
::::::::::::::
eicar.zip
::::::::::::::
[...] EICAR-STANDARD-ANTIVIRUS-TEST-FILE[...]Die originale ZIP-Datei enthält eine Exe-Datei mit dem Testvirus. Den Inhalt am Ende habe ich zensiert, da gewisse Virenscanner hysterisch generieren und dann eine gesamte Domain als potenziell gefährlich betrachten. Dort stand die Zeichenkette, könnt ihr bei Bedarf selbst anschauen, in dem ihr die Datei mit einem Texteditor öffnet (ist nicht groß). In der heruntergeladenen Datei dagegen gibt es nur noch eine Textdatei DLETED0.TXT. Darin steht, was der AV gefunden hat.
Mit der Logik wird auch klar, warum es nur zwei Stati gibt: Aus Sicht von CNX gibt es keine Dateien mit bekannten Infizierungen im System. Somit bekommt auch eine als infiziert erkannte Datei wie eicar.zip den Status 2, da diese nach dem Scan unschädlich gemacht wurde.
Welche Dateien sind betroffen und wie können wir die Meldung entfernen?
Mit einer einfachen SQL-Abfrage:
Die Mehrheit sollte Status 2 haben. Je nachdem wie lange der IHS Upload aktiv war, mehr oder weniger mit Status 1. Um die oben gezeigte Meldung zu entfernen, müssen Dateien mit Scan-Status = 1 auf 2 gesetzt werden:
UPDATE files.MEDIA
SET MALWARE_SCAN = 2
WHERE MALWARE_SCAN = 1Diese Änderung wird sofort wirksam, d.H. ohne Neustart verschwindet die Meldung. Wer zuvor einen Virenscan benötigt, kann diesen auf dem SHARED_DIRECTORY von Connections laufen lassen.
Wie lösen wir das Problem nachhaltig?
Eine nachhaltige Lösung ist das aber ja nicht: Wenn nach Ausführen der Abfrage eine neue Datei per IHS hochgeladen wird, erhält diese wieder Status 1 und erzeugt damit eine Warnung. Außerdem ist der fehlende Virenscan wohl zumindest aus Compilance-Gründen ein Problem, wenn dort das Scannen auf Viren ausgehandelt wurde. Eine wirkliche Lösung gibt es derzeit nicht, ein Ticket dazu habe ich bei HCL eröffnet.
Als Workaround kann man in meinen Augen lediglich wie folgt verfahren: Das Limit für die SimpleUploadAPI entsprechend hochsetzen, damit möglichst alle Uploads über den WAS erzwungen werden. Der Download kann weiterhin über den IHS erfolgen, da dies keinen Einfluss auf den Virenscan hat. Und das ist meiner Erfahrung nach auch das Hauptproblem: Lädt ein Nutzer z.B. eine 2GB große Datei hoch, blockiert das einen Thread. Außerdem steigt der RAM-Verbrauch an. Im Regelfall werden aber mehr Nutzer anschließend diese Datei herunterladen – im schlechtesten Falle parallel. Es ist in meinen Augen also wesentlich wichtiger, per IHS zumindest herunterzuladen.
Für den Upload sollte man natürlich auch vorsorgen und dem App-Server genug Arbeitsspeicher zur Verfügung stellen. Vor allem bei größeren Dateien, sonst kann auch der reine Upload Probleme machen. 4-6 GB scheinen hier als Anhaltspunkt sinnvoll, im Zweifel lieber etwas mehr als zu wenig. Wobei man auch hier nicht vergessen darf, die VM entsprechend anzupassen, damit diese tatsächlich genügend RAM zur Verfügung stehen hat.