Transparenter Proxy / MIME-Type Blocklist / greift nicht

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
csg
Beiträge: 193
Registriert: Di 08.03.2011, 10:55
Kontaktdaten:

Transparenter Proxy / MIME-Type Blocklist / greift nicht

Beitrag von csg »

Hallo zusammen,

seit heute treffen bei uns Mails ein, welche im Body einen Link ohne Dateinamen und Dateierweiterung enthalten, dann aber ein .doc o.Ä. herunterladen wollen.

Siehe dazu als Beispiel: https://www.virustotal.com/#/url/ad9fd611ee67d3f83139bbacc87b95060fd814263f38a86522d535dc597e5402/details 

Nun konnten wir bei bisherigen Mails mit Dateinamen und Dateierweiterung diese bereits im Spamfilter oder das Aufrufen des links spätestens über eine UTM-Webfilterregel abfangen. Das klappt nun nicht mehr.

Gemäß https://www.securepoint.de/fileadmin/securepoint/downloads/utm/howto-filterung-officedokumente.pdf (Seite 9) haben die MIME-Type Blocklist natürlich gefüllt. Aber leider greift diese nicht. Dass der transparente Proxy funktioniert haben wir mit einem eicar-Testvirus bereits überprüft.

Es wird die UTM-Version 11.7.4 eingesetzt.

Kann da jemand weiterhelfen?

VG

Jan

Bjoern
Securepoint
Beiträge: 685
Registriert: Mi 03.07.2013, 10:06

Beitrag von Bjoern »

Hallo,

das Problem ist hier HTTPS. Um dies auch zu blocken/filtern ist die SSL-Interception zwingend notwendig.


Gruß Björn

csg
Beiträge: 193
Registriert: Di 08.03.2011, 10:55
Kontaktdaten:

Beitrag von csg »

Hallo Björn,

übersehe ich da was mit https:// ?
Bei meinem Link (und auch den unzähligen von heute Morgen) handelt es sich um http://-Links.
Das meine ich auch aus dem virustotal-Link so ablesen zu können.

Gruß

Jan

Bjoern
Securepoint
Beiträge: 685
Registriert: Mi 03.07.2013, 10:06

Beitrag von Bjoern »

Hallo,

bei reinen HTTP anfragen kommt es immer darauf an was die Webseite bei solchen Dateien wiedergibt. Sie können zusätzlich im Webfilter *.doc etc. filtern.

Gruß Björn

csg
Beiträge: 193
Registriert: Di 08.03.2011, 10:55
Kontaktdaten:

Beitrag von csg »

Hallo Björn,

wie ebenfalls im Virustotal-Link zu erkennen ist: die finale URL ist auch ein http://-Link.
Also sollte der MIME-Filter greifen!
Der Webfilter greift nur, wenn das .doc direkt aufgerufen wird. Der ist nämlich gesetzt und funktioniert in der aktuellen Situation dann aber eben nicht.

Ergänzung:
Hier noch ein gutes Virustotal-Beispiel: https://www.virustotal.com/#/url/bad0d9 ... 2a/details
Die finale URL ist eine http://-URL.
Download ist ein "Angebot-BFJ-63231.doc".
MIME-Type ist "application/msword" .
UTM blockt es nicht trotz aktivem Webfilter (wie oben erwähnt greift der ja hier nicht; warum auch immer) und MIME-Blockliste greift ebenfalls nicht.
UTM schützt also aktuell nicht.
Zuletzt geändert von csg am Mi 04.10.2017, 09:53, insgesamt 1-mal geändert.

Bjoern
Securepoint
Beiträge: 685
Registriert: Mi 03.07.2013, 10:06

Beitrag von Bjoern »

Hallo,

bei reinen HTTP anfragen kommt es immer darauf an was die Webseite bei solchen Dateien wiedergibt.
Nur dann kann das auch geblockt werden. Wenn Sie zum Beispiel application/octet-stream filtern wird auch google nicht mehr funktionieren da dies von der Webseite zurück gegeben wird.

Gruß Björn

kennethj
Beiträge: 408
Registriert: Di 25.04.2017, 10:17
Wohnort: Lüneburg
Kontaktdaten:

Beitrag von kennethj »

Hallo Jan,

eventuell wurde hier die Antwort von Björn missverstanden:
Der HTTP Proxy wertet den Antwort Header des Webservers aus (dieser gibt einen Content-Type an)

Sagt der Webserver nun im Content-Type: Das ist ein pdf, aber es ist in Wirklichkeit eine .doc - geht es am Proxy vorbei,
 
Laut Virustotal gibt der Webserver allerdings den richtigen Content-Type zurück "content-type: application/msword".
Ist dieser geblockt? 
Wenn Ja: Wurde der Eintrag damals manuell eingetragen oder von irgendwas copy &pasted. Könnte nämlich sein, dass sich dann ein Leerzeichen eingeschlichen hat. 

Gruß
Zuletzt geändert von kennethj am Mi 04.10.2017, 09:57, insgesamt 1-mal geändert.

csg
Beiträge: 193
Registriert: Di 08.03.2011, 10:55
Kontaktdaten:

Beitrag von csg »

Also ich bringe seit Öffnen des Beitrages das Beispiel.
Und darin ist ja ersichtlich, dass der Webserver "application/msword" zurückgibt.
Und das steht in den Filterregeln drin.
Und es wird eben nicht geblockt.

Ich entferne jetzt alle Einträge im MIME-Filter und füge diesen einen hinzu, um es dann zu testen.

csg
Beiträge: 193
Registriert: Di 08.03.2011, 10:55
Kontaktdaten:

Beitrag von csg »

So, ich habe alle Einträge entfernt.
Dann die Einstellung gespeichert.
Dann nur aus der Auswahlliste (kein Drag/Drop) "application/msword" hinzugefügt und gespeichert.
Download von http:// markmoskovitz . com/Lastschrift/ ist weiterhin möglich.
Und Virustotal sagt: http:// mit application/mswordhttps://www.virustotal.com/#/url/c6757b35f8e2d027278d28972e5964c4dd7224d69debc15c33acd124e72dc999/details

Ergänzung:
eicar-Test mit http://www.eicar.org/download/eicar.com.txt erfolgt und wird geblockt. Proxy also aktiv.

Ergänzung 2:
Weiteres Beispiel: https://www.virustotal.com/#/url/8dcc5b38f3d7639e1063b5c3f56cff36338ec0958467e0310c939670ac509e62/details
Und das lädt man sich damit runter: https://www.virustotal.com/#/file/934d902a998a021b565ac20dc246397b59febc4201d8c5771a9aa0979320b4d7/details
Schutz somit beinahe 0, da hier weder die UTM greift noch aktuelle Virenscanner anschlagen (bis auf zum aktuellen Zeitpunkt 2 Exoten).

Benutzeravatar
Christian E.
Securepoint
Beiträge: 238
Registriert: Do 05.07.2012, 16:19
Wohnort: Lüneburg

Beitrag von Christian E. »

Hallo zusammen,

dass die Firewall die Antwort des Webservers auswertet stimmt so nicht mehr. Die UTM prüft die Datei mittlerweile selbst.
Hier werden aber nur die ersten Zeilen betrachtet in denen i.d.R. der Content Type angegeben ist. Bei Microsoft kann dieser aber auch
am Ende stehen und wird daher nicht erkannt. Sie können diese Dateien mit folgenden MIME-Type blockieren:

Code: Alles auswählen

application/CDFV2-corrupt
Beste Grüße
Christian

csg
Beiträge: 193
Registriert: Di 08.03.2011, 10:55
Kontaktdaten:

Beitrag von csg »

OK, klappt im ersten Moment.
Wir beobachten mal, ob es zu Kollateralschäden führt.

VG

Jan

Antworten