Hochladen bestimmter PDF-Dateien (und anderer?) scheitert

[Rüdiger Kupper]

Bestimmte Dateien lassen sich über SOGo nicht als Anhang verschicken: Die Datei wird offenbar zum Server geschickt, dann erscheint aber die Fehlermeldung »Hochladen der Datei gescheitert«.
Der Fehler ist für die betreffenden Dateien reproduzierbar. Versand über IMAP (via VPN) klappt problemlos.

Betroffen sind viele Kollegen, siehe CC-Liste.

Geprüfte Fehlerquellen

• der Fehler hängt nicht vom Dateinamen ab (Umlaute oder Whitespace)
• der Fehler hängt nicht von der Dateigröße ab
• die Dateien sind virenfrei (geprüft an Beispieldateien mit ​ClamAV)

[Rüdiger Kupper]

Gerade beobachte ich etwas, was uns vielleicht weiter bringt:
Ich wollte zwei Dateien, die ich von bad erhalten habe und bei denen das Problem auftritt, an dieses Ticket anhängen. Und siehe: es geht nicht! Fehlermeldung:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, webmaster@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Ein anderes PDF ließ sich problemlos anhängen.
Das Problem ist also nicht spezifisch für SOGo, sondern der Upload dieser Dateien zu unserem Server scheitert generell.

[Rüdiger Kupper]

@bau

Auf welchem Weg gelangen die Dateien denn zu Trac und SOGo? Trac läuft auf dem paedml, SOGo nicht, oder?

[Rüdiger Kupper]

@bau

Demnach könnte es an der Apache-Konfiguration liegen.

[bau]

Trac läuft direkt im Apache des paedml, SOGo wird von genau demselben Apache auf den internen Server (per Proxy-Modul) weitergeleitet. Auch möglich ist, dass das in der Firewall hängenbleibt - wenn du mal von INNEN das PDF versuchst an den TRAC zu hängen geht es nicht über den IPFire.

[Rüdiger Kupper]

Hochladen funktioniert auch von innen nicht, weder mit SOGo, noch mit Trac. Im Apache-Log taucht beide Male folgende Fehlermeldung auf:

Trac

Fri Jul 03 14:40:47 2020] [error] [client 10.16.112.226] ModSecurity: Access denied with code 44 (phase 2).
Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required. [file "/etc/modsecurity/modsecurity.conf"] [line "91"] [msg "Multipart parser detected a possible unmatched boundary."]
[hostname "paedml.kg-fds.de"] [uri "/trac/attachment/ticket/3507/"] [unique_id "Xv8nTwogAQEAADhD7kMAAAAH"]

SOGo

[Fri Jul 03 14:44:17 2020] [error] [client 10.16.112.226] ModSecurity: Access denied with code 44 (phase 2). 
Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required. [file "/etc/modsecurity/modsecurity.conf"] [line "91"] [msg "Multipart parser detected a possible unmatched boundary."]
[hostname "paedml.kg-fds.de"] [uri "/SOGo/so/kup/Mail/0/folderEntwurf/newDraft1593780225-1/save"] [unique_id "Xv8oIQogAQEAADvcBa8AAAAO"]

Demnach ist das MIME-Format der hochgeladenen Datei defekt…?

[Rüdiger Kupper]

@bau

Googeln nach der Logmessage hat ergeben, dass das Problem im Apache-Modul mod_security liegt (eine Web-Firewall, die verschiedene Angriffe abwehren soll). Offenbar reicht es, das Modul zu aktualisieren. Ob wir das auf dem alten Server aber noch tun wollen?

• ​https://github.com/SpiderLabs/ModSecurity/issues/1804
• ​https://github.com/SpiderLabs/ModSecurity/pull/1747
• ​https://github.com/SpiderLabs/ModSecurity/issues/2021

Zur Not kann man das Modul auch deaktivieren, das ist aber eine eher schlechte Idee:

• ​https://support.plesk.com/hc/en-us/articles/213961065-Unable-to-attach-files-or-import-emails-in-Horde-or-upload-files-to-a-website-when-ModSecurity-is-enabled
• ​https://sourceforge.net/p/mod-security/mailman/message/31205650/

Maßnahmen

Versuchen, ob wir den Apache bzw. nur das Modul mod_security auf dem paedml aktualisieren können. Wenn nicht, deaktivieren(?) und möglichst schnell zum neuen Server wechseln.

[bau]

Weitere Alternative:
SOGo per Firewall auf proxmoxLS auf den internen Server weiterleiten lassen.
Dann läuft es eben nicht auf Port 443 sondern eben auf z.B. 20443, den iptables nach intern weitergibt.

[bau]

mod_security lässt sich auf paedml nicht wirklich sinnvoll upgraden (Branch 3 wäre nötig).

[Rüdiger Kupper]

Deaktivieren ist keine Option, vermute ich. Dann wäre Dein Vorschlag in comment:7 die Maßnahme.

Wie schnell können wir den neuen Server in Betrieb nehmen?

[Rüdiger Kupper]

Man kann statt es ganzen Moduls auch nur diese bestimmte Regel deaktivieren, die hier fehlläuft.

[Rüdiger Kupper]

Würde die direkte Weiterleitung vom proxmoxLS nicht auch alle Sicherheitsprüfungen umgehen? In dem Fall wäre ich dafür, die einzelne Regel zu deaktivieren.

[bau]

Die Weiterleitung würde auf einen Apache2 auf dem SOGo-Server laufen, der hat ja sein eigenes mod_security.
Von dort wird es per mod_proxy auf den SOGo-Daemon auf port 20000 geleitet.

[Rüdiger Kupper]

Dann würde ich sagen, wir machen es so und überlegen uns dann für den neuen Server ein geeignetes Setup.

[Rüdiger Kupper]

Anbei: Es sind noch knapp drei Wochen im Schuljahr. Über die Sommerferien setzen wir hoffentlich den neuen Server auf. Aufwands-Nutzen-Abschätzung.

[Rüdiger Kupper]

Die meisten Anhänge gehen raus. Für den Rest haben die Kollegen Ausweichmöglichkeiten.

[bau]

Ich habe für SOGo nun eine Route am paedml vorbei gebaut.
Probier bitte mal aus, ob man solcherlei PDF (also solche, die Probleme machten) hochladen kann:

​https://paedml.kg-fds.de:20000/SOGo

[Rüdiger Kupper]

Erfolg.
Der neue Link funktioniert, dort kann ich die PDFs verschicken, die über den alten Link abgelehnt werden.
(Der neue Link funktioniert lediglich nicht über das VPN, wie Du aber sicher weißt.)

TODO:: Den üblichen SOGo-Link auf die neue Adresse weiterleiten, dann dieses Ticket schließen.

[bau]

ToDo:

1. Port 20000 auch intern im Schülernetz und Lehrernetz hinbiegen (muss von paedml.kg-fds.de weitergehen: 10.32.1.1 oder 10.16.112.4)
2. Port 20000 wird von ProxMoxLS an 10.16.112.9:443 weitergeleitet

[lehm]

Done?

[Rüdiger Kupper]

Ja.

[Stephan Richter]

Kann es sein, dass das gleiche Problem nun auf den Tablets im MobileDevices-WLAN auftritt?

Zumindest scheitere ich gerade daran, eine PDF zu verschicken.

[bau]

Problem ist das von Rüdiger oben beschriebene mod_security.
Wir wollten das auf keine Fall für alle ausschalten, nach ​https://sysadminde.com/questions/57210/disable-modsecurity-for-a-specific-directory kann man es aber auch für einzelne Verzeichnisse ausschalten, das habe ich nun gemacht:

<Location "/SOGo">
    SecRuleEngine Off
</Location>

Bitte testen!

[Stephan Richter]

Klappt! Vielen Dank :)