ArticleStorageFS: Artikelinhalte doppelt (DB und FS)

[jtvogt]

Hallo,

ich habe folgendes Problem (OTRS 4.0.7, ITSM, KIX4OTRS 7) nach der Umstellung von ArticleStorageDB auf ArticleStorageFS
(Ticket::StorageModule auf ArticleStorageFS gesetzt und anschließend "otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS"):

neue Tickets/Artikel können angelegt, Attachments hinzugefügt werden etc., alles OK

Aber: Für jeden neuen Article eines Tickets wird der Textbody sowohl in der DB (Tabelle article, Spalte a_body) als
auch über 2 Files auf dem Filesystem abgelegt (z.B. file-2 und file-2.content_type).
Führt das nicht zu Konsistenzproblemen ?

Wird noch ein Attachment hinzugefügt,kommen nochmal 3 Files dazu (<file>, <file>.disposition, <file>.content_type).

Bei der Umstellung unseres Produktivsystems mit > 20.000 Tickets, > 100.000 Articles, > 100.000 Attachments sind das
schnell > 1 Mio Files !!
Laut OTRS-Doku bin ich davon ausgegangen, daß nur Attachments und nicht der Textbody auf dem Filesystem abgelegt werden.

Hat jemand ähnliches schon beobachtet bzw. Tipps wie man die Duplizierung des Textbodies verhindern kann ?
Wie führt man bei ArticleStorageFS eine Konsistenzprüfung durch (z.B. sind für alle Articles mit Attachments auch alle Files vorhanden etc.)

Danke !

[Hazet]

Hier: 164000 Tickets, davon ca 1000 offen.
405000 Artikel
täglich ca. 100 neue Tickets.

Im FS habe ich dazu insgesamt ca. 1,1 Mio Dateien unter $OTRS_HOME/var/article.

Performance-Probleme: Derzeit keine.
Maschine: VM, 6GB Ram, 2 Core, Ubuntu 12.04

Einen Verlust von Dateien konnte ich bisher nicht feststellen (Produktivsetzung 2008).

[jtvogt]

Sind dort auch die Article-Textbodies doppelt vorhanden ?

Probleme sehe ich auch beim konsistenten Backup/Restore: OTRS muß bei mir in
einer 3-Tier-Umgebung (Webfrontend, AppServer mit OTRS + Article-FS, DB-Server mit OTRS-DB) laufen,
d.h. ein konsistentes Backup bekomme ich damit nicht mehr hin.
Auch dauert der Restore via TSM von > 1 Mio Files deutlich länger als der Restore der DB.

Grund für die Umstellung auf ArticleStorageFS ist eigentlich die Notwendigkeit, alle Attachments
mit einem Virusscanner zu prüfen. Meines Wissens gibt es im OTRS keine Möglichkeit,
beim Upload/Download von Attachments z.B. ein externes Script o.ä. aufzurufen.
Solange wie bisher die Attachments alle in der DB verwaltet werden, bleibt ein Virusscanner auf FS-Ebene
immer außen vor.

[schulmann]

Grund für die Umstellung auf ArticleStorageFS ist eigentlich die Notwendigkeit, alle Attachments
mit einem Virusscanner zu prüfen.

Solange das Attachment in OTRS liegt ist es unkritisch weil es ja nicht ausgeführt wird.
Sobald jemand das Attachment herunterlädt prüft es der Virenscanner, der auf dem PC läuft, automatisch.
Dann wird doch gar kein Virenscanner auf FS-Ebene benötigt.
Oder verstehe ich da etwas falsch?

[jtvogt]

im Prinzip schon richtig, allerdings sind die Securityvorgaben bei mir derart, daß jede Applikation, die
einen Datenaustausch via File-Upload/Download anbietet, zwingend selbst einen Virusscan durchführen muß.
Macht ja eigentlich schon Sinn, damit die Applikation nicht als Verbreitungsmedium verwendet werden kann.

[schulmann]

Abgesehen davon, dass zum einen ein Virenscanner nicht alle Schadsoftware erkennt und zum anderen vermutlich nicht alle MIME-Attachments (ich denke da speziell an den Content-Type multipart/alternative) erfasst werden: Du könntest per cron-Job alle neuen Artikel aus der DB extrahieren und auf Schädlichkeit prüfen lassen.
Dann wären die Attachments weiterhin in der DB.

[jtvogt]

An sich eine wirklich gute Idee, allerdings befürchte ich aus meinen bisherigen Erfahrungen
mit dem Penetration-Test-Team, daß die Jungs direkt hintereinander versuchen, ein File hoch- und wieder herunterzuladen.
Dann wird es mit dem Timing über einen Cronjob schwierig.

[schulmann]

An sich eine wirklich gute Idee, allerdings befürchte ich aus meinen bisherigen Erfahrungen
mit dem Penetration-Test-Team, daß die Jungs direkt hintereinander versuchen, ein File hoch- und wieder herunterzuladen.

Prüfen die Penetrationstester auch ob schädliche HTML-Mails erkannt werden?
Falls ja, was macht ihr mit solchen Mails?

Und was wird getan falls ein Attachment als problematisch eingestuft wird?
Automatisch gelöscht?
Was passiert dann beim Öffnen des Tickets?

Wenn es beim Scannen keine Zeitverzögerung geben darf würde ich einen Event-gesteuerten Generic Agent einrichten der beim Erstellen von Artikeln die Prüfung anstößt.
Aber auch da gilt:
Was tun bei echtem oder vermeintlichem Schadcode?
Ich würde versuchen, das betroffene Ticket in eine Queue zu verschieben in der niemand irgendwelche Rechte hat und in der das Ticket bei Bedarf auch per Generic Agent gelöscht werden kann.

[jtvogt]

Die Mailinfrastruktur inkl. Virenprüfung liegt - auch von der Zuständigkeit her - außerhalb der OTRS-Infrastruktur, OTRS ist nur ein via fetchmail angebundener Client, die ausgehenden Mails gehen auch über den zentralen Mailserver inkl. Virenscanning.

Im RichText-Editor von OTRS (CKeditor) habe ich schon diverse andere mögliche Einfallstore abgeschaltet (Image-Upload, Links, Quellcode-Umschaltung), da auch OTRS 4.0.9 noch die "alte" CKEditor Version 4.4.5 bundled (siehe Securityhinweise auf http://ckeditor.com/blog/category/releases).

Am liebsten wäre mir, daß beim Hinzufügen jedes einzelnen Attachments zu einem Article ein entspr. Event generiert wird, in dem
noch zu erstellenden aufgerufenen Modul müsste dann der Binary-Stream o.ä. des Attachments landen, den könnte man dann
als temp. File speichern und versuchen es wieder zu lesen. Bei einem pos. Fund kann das File nicht mehr gelesen werden (On-Access-Scanner).
Der Aufruf des On-Demand-Scanners dauert zu lange (ca. 10 sec).
Das hätte den Vorteil, daß der Anwender eine direkte Rückmeldung bekommen könnte und man nicht erst nach dem
Speichern des Articles (u.u. mit mehreren Attachments) eine Entscheidung bzgl. Löschen des gesamten Articles, Verschieben des Tickets
treffen muß.
Ich habe allerdings bis jetzt in der OTRS-Doku nichts gefunden mit dem sich das erreichen läßt.

[schulmann]

Da sind wir aber jetzt weit weg vom ursprünglichen Thema: ArticleStorageFS: Artikelinhalte doppelt (DB und FS)

Funktioniert eigentlich der On-Access-Scanner wenn die Anhänge auf dem Filesystem abgelegt werden oder ist der On-Access-Scanner eine Sache die bei der Gelegenheit möglichst auch gleich mit erledigt werden soll?

Für das weitere Vorgehen gibt es mehrere Denkansätze:

• Man könnte prüfen wann ein Event-gesteuerter Generic Agent aktiv wird, also ob vor oder nach dem Speichern des Artikels. Vermutlich erst nach dem Speichern, aber prüfen sollte man es trotzdem weil es eine einfache Möglichkeit wäre.
• Man könnte prüfen ob man vor das OTRS einen HTTP-Proxy schalten kann welcher die Daten während der Übermittlung scannt, also ein Web Gateway wie z. B. von McAfee, Sophos oder Symantec.
• Man könnte prüfen ob eine OTRS-Code-Modifikation an der Stelle, an der ein Anhang hochgeladen wird, möglich ist.
• Man könnte prüfen ob ein Eingriff über einen Trigger in der OTRS-DB weiterhilft.

Die beiden letzten Ansätze haben allerdings den Nachteil der OTRS-Update-, Upgrade- und Support-Problematik.

[jtvogt]

stimmt, vielleicht sollte ich einen neuen Thread aufmachen.

Ich hatte meine OTRS-Testumgebung mal von ArticleStorageDB auf ArticleStorageFS umgestellt:
- es werden einfach zuviele Files erzeugt, Backup und v.a. Restore würden viel zulange dauern, scheidet also aus
- das Verhalten bei ArticleStorageFS mit On-Access-Scanner und dem eicar-Testvirus als Attachment ist:
- Attachments und Articles/Tickets werden ohne Fehlermeldung gespeichert, war zu erwarten da der On-Access-Scanner erst beim Lesen greift.
- Öffnen des Attachments liefert nichts zurück, nicht mal eine Fehlermeldung und das obwohl ein perl-open-Call "Operation not permitted"
zurückliefert.

zu den Denkansätzen:
- Zeitpunkt des Events: werde ich testen und meine Ergebnisse mitteilen
- HTTP-Proxy: wird vom Betreiber des RZ/Servers nicht angeboten und ich muß die angebotene Infrastruktur,d.h. auch den Virenscanner verwenden
- ich werde mal versuchen, den Ansatz von KIX4OTRS (habe ich ja im Einsatz) nachbilden, in dem ich das für das Upload zuständige Core-Modul durch
ein Custom-Modul erweitere/ändere. Damit müsste man die Support/Update-Problematik umgehen können. Seitdem der Packagemanager
ja die Checksums aller Files prüft, kann man eh keine direkten Änderungen mehr machen (Fehlermeldungen im Packagemanager und im OTRS-Log)
- der DB-Trigger-Vorschlag ist auch gut, vielleicht läßt sich das mit dem Postgres-Listen/Notify-Konstrukt ohne Performancenachteile implementieren

[Ebebalf]

Die Mailinfrastruktur inkl. Virenprüfung liegt - auch von der Zuständigkeit her - außerhalb der OTRS-Infrastruktur, OTRS ist nur ein via fetchmail angebundener Client, die ausgehenden Mails gehen auch über den zentralen Mailserver inkl. Virenscanning.

Das klingt für mich jetzt so, als wäre alles bereits auf Viren überprüft, bevor es ins OTRS kommt. Wozu dann im OTRS nochmal prüfen?

[schulmann]

Die Mailinfrastruktur inkl. Virenprüfung liegt - auch von der Zuständigkeit her - außerhalb der OTRS-Infrastruktur, OTRS ist nur ein via fetchmail angebundener Client, die ausgehenden Mails gehen auch über den zentralen Mailserver inkl. Virenscanning.

Das klingt für mich jetzt so, als wäre alles bereits auf Viren überprüft, bevor es ins OTRS kommt. Wozu dann im OTRS nochmal prüfen?

Die Anhänge könnten auch über das Webinterface (Agenten- und/oder Kunden-Zugang) hochgeladen werden. Davon sieht der Mailserver (und der dort laufende Virenscanner) natürlich nichts.

Ein anderer Punkt kann sein: Die Sicherheitsrichtlinien geben das so vor, auch wenn es evtl. nicht sinnvoll ist.
Der Verstoß gegen Sicherheitsrichtlinien - und seien sie noch so abwegig - kann u. U. den Verlust des Arbeitsplatzes zur Folge haben.