• Bewerte uns auf OMR Reviews: Klick

  • NSP Forum als App inkl. Push Nachrichten (iOS): Klick

  • Wichtige Information für alle, die noch nicht auf v14.0.5.39 sind:

    Cyren Antimalware kann nicht mehr verwendet werden. Unsere Lizenz ist endgültig deaktiviert, so dass der Dienst nicht mehr nutzbar ist.
    Bitte stellt sicher, dass ihr schnellstmöglich auf die aktuelle Version aktualisiert. Bis es so weit ist, empfehlen wir die Cyren Antimalware Aktion zu deaktivieren und mindestens den lokalen Virenscanner zu aktivieren. Sollte kein anderer Scanner als Cyren aktiv sein, kommt es unweigerlich zur Abweisung von E-Mails.

    Zusätzlich raten wir dazu, die Cyren Filter zu deaktivieren, hier ist der Einfluss zwar geringer, solange alle anderen Filter korrekt durchlaufen, aber im Problemfall kommt es ebenfalls zur Abweisung.

     

    Unser Blogbeitrag wird in Kürze ebenfalls aktualisiert.

    Beste Grüße
    Euer NoSpamProxy Team

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

Skript "Get-NspTlsReport" funktioniert mit 14.x nicht mehr

mabu

Well-known member
Hallo.

Seit dem Update von 13.2 auf 14.0.5 funktioniert das Powershellskript https://github.com/noSpamProxy/Reports/tree/master/Get-NspTlsReport bei uns nicht mehr.

So sah Ergebnis des Reports am Abend vor dem Update aus
Anhang anzeigen 9

Seit dem Update ist es täglich leer
Anhang anzeigen 8

Habe auch in GitHub geschaut, ob es evtl. eine neuere Version gibt. Aber das scheint das gleiche zu sein, was wir nutzen. Ich füge unsere Version hier mal bei. Ich meine, dass ich bei der erzeugten HTML-Datei ein paar Anpassungen gemacht habe.

Das Skript mit HTML-Datei der geblockten Mails des Tages in einer Liste funktioniert weiterhin.

Hoffe, Ihr könnt das TLS-Skript wieder zum Laufen bringen. Ich brauche die Ergebnisse für die Entscheidung, ob ich Mails ohne TLS-Verschlüsselung generell ablehne (und evtl. mit Ausnahmen arbeiten muss - falls das überhaupt möglich ist).

Gruß,
Martin
 

Anhänge

  • Get-NspTlsReport_ps1.txt
    23.9 KB · Aufrufe: 3
  • nach.jpg
    nach.jpg
    21 KB · Aufrufe: 5
  • vor.jpg
    vor.jpg
    31.4 KB · Aufrufe: 7
Hallo Martin,

dein hier angehangenes Skript ist älter.
Lad dir bitte einmal die neue Version von Github und schaue ob es dann immer noch nicht funktioniert und gib noch einmal Bescheid =)

LG
Jan
 
Hallo Jan.

Das ist mir jetzt etwas unangenehm. Hatte auf der GitHub-Seite geschaut - aber irgendwie nur auf den Teil mit ab 13.0...." geschaut und das sah in der Datei genauso aus. Und darüber steht was von "v14 Support added".

Gleich getestet. Ergebnis kommt wieder ... aber nun habe ich eine fast 100% Trefferquote für unverschlüsselt.


Ich starte das File per Skript mit diesen Parametern:
-NumberOfDaysToReport 1 -ReportFileName "TLS-Report" -ReportRecipient empfaenger@abc.de -ReportSender mailgateway@abc.de -ReportSubject "TLS-Report" -SMTPHost internerRelay.intern 

Schaue ich mir verschiedene Mails in der Nachrichtenverfolgung an, wird für den Weg zwischen externem Mailserver und dem NSP eine verschlüsselte Verbindung angezeigt. Und auch für die interne Weitergabe an dortige Mailserver ist eine verschlüsselte Verbindung angezeigt.
 

Anhänge

  • ergebnis.jpg
    ergebnis.jpg
    35.9 KB · Aufrufe: 5
Guten Morgen Martin,

danke für das Feedback.
Ich habe grade einmal nachgeschaut:
Deine Beobachtung ist korrekt. Das bisher ausgewertete Attribut existiert in neuen Messagetracks nicht mehr.

Für einen Kurztest / Quickfix für eingehende E-Mails könntest du in Zeile 170 "SenderConnectionSecurity" durch "TlsCipherSuite" ersetzen.
Für ausgehende E-Mails könntest du Zeile 172 von "ConnectionSecurity" auf "TlsCipherSuite" setzen.

Ich werde schauen, dass wir das Skript zügig auf den aktuellen Stand bringen.


Gruß
Jan
 
Moin,
wäre es möglich vielleicht im Skript eine Funktion einzusetzen,
die prüft ob auf der github Seite eine neuere Version vor liegt.
Einen Hinweis dazu gibt ?

Weil wie oft kommt es vor das man ein Script nutzt aber die Aktualität nicht prüft, eigentlich nur dann bei Fehlern :)
 
Morgen.

Auch mit den beiden Änderungen bekomme ich eine "100% unverschlüsselt"-Quote.

Ich warte mal auf Eure neue Version
 
Hallo zusammen,
ich hatte nun endlich Zeit mir das Thema noch einmal im Detail anzuschauen.
In der aktuellen 14.0.5 ist übergangsweise etwas anders als in der bevorstehenden 14.1.
Damit sind mehr oder weniger zwei Anpassungen im Skript notwendig.
Ich habe mal eine Anpassung für v14.0.5 gemacht - lasst mich wissen ob diese bei euch ebenfalls die korrekten Daten liefert :)

LG
Jan
 

Anhänge

  • Get-NspTlsReport_v14.0.5.txt
    16.2 KB · Aufrufe: 10
Zuletzt bearbeitet:
Hallo Jan.

Aufgrund eines anderen Themas bezüglich NSP kam mir das TLS-Report-Skript wieder in den Sinn. Und da ist mir Deine Antwort komplett durchgerutscht.

Eben getestet und es funktioniert wieder :) Danke Dir.
 
Hallo Jan,

leider gibt das Skript keine Statistik aus, welche TLS-Versionen (TLS1.0, TLS1.1 ..... TLS1.3) eingesetzt wurden.
Meist Du, es gibt eine Chance, ein Skript mit genaueren Informationen über die benutzen TLS-Versionen zu bekommen.


Gruss
 
Hallo Postamt ^^

Jap die chance gibt es 😊
Ich schaue gerne mal wie aufwändig es ist das bestehende Datum zu erweitern. In der Datenbank sind die Daten definitiv drin und ich glaube im PowerShell bekommen wir die auch problemlos zurück gegeben ;)

Gruß
Jan
 
Guten Morgen Stefan =)

Ich habe grade einmal geschaut. Leider geht das in der aktuellen Version nicht per Powershell. Grund ist hier die Umstellung des Backends, die Daten werden erst in einer neueren Version mit ausgegeben :(
Aber ab dann können wir das sauber einbauen.

Gruß
Jan
 
Hallo Jan,

die Hoffnung stirbt zuletzt....
Gibt es da aktuell eine Timeline?

Gruß
Das Postamt (Stefan)
 
Hallo Stefan,

die v14.1 soll nach den Sommerferien in NRW veröffentlicht werden.
Ab dann sollten die Daten sauber da sein.
Ich werde die Tage mein System mal updaten, dann kann ich das mit Sicherheit sagen. (Lebe hier mit ein paar mehr Versionen als man sich vorstellen kann ^^)

Gruß
Jan
 
Hallo Jan,

och.... verdammt.... :) ......
Dann wird es eben kein Eilbrief, sondern Standardversand.
Da muss der Empfänger eben warten.....


Aber vielen Dank für dein Feedback(y).

Gruß
Das Postamt (Stefan)
 
Wir wollen jetzt mal nicht überdrehen.... wenn es mit v14.1 dann veröffentlicht wird, ist es schon ok.....!

Gruß
Das Postamt (Stefan)
 
Hallo Jan,

der doch ungeduldige Mensch im Postamt wartet auf seine Paketzustellung:cool:.... Sommerferien in NRW sind ja jetzt vorbei.....:giggle:
Mir fehlt echt diese Analyse / Auswertung mit den TLS Versionen....


Ne jetzt mal normal gefragt: habt ihr schon ein Termin für die v14.1 im Auge?

Gruß
Das Postamt (Stefan)
 
leider gibt das Skript keine Statistik aus, welche TLS-Versionen (TLS1.0, TLS1.1 ..... TLS1.3) eingesetzt wurden.
Gibt es noch Mail-Server, welche TLS 1.0 und 1.1 zum Versand verwenden und auch solche die es auch noch annehmen?! Ist mir in den letzten 3 Jahren nicht mehr untergekommen. TLS 1.0 und 1.1 sind offiziell als unsicher eingestuft worden. Von daher würde ich hier eher die harte Linie fahren.
 
Gibt es noch Mail-Server, welche TLS 1.0 und 1.1 zum Versand verwenden und auch solche die es auch noch annehmen?! Ist mir in den letzten 3 Jahren nicht mehr untergekommen. TLS 1.0 und 1.1 sind offiziell als unsicher eingestuft worden. Von daher würde ich hier eher die harte Linie fahren.
ja gibt es, die Quote liegt zwischen 1 und 3%

Das mit den TLS 1.0 und 1.1 ist aber nur die halbe Wahrheit, auch TLS 1.2 kann unsicher sein, sofern statische DH Keys genutzt werden oder wenn statt GCM das angreifbare CBC genutzt wird, welches beides in TLS 1.2 noch vorhanden ist.

Die größte Schwachstelle bei TLS 1.0 und 1.1 und in Teilen auch 1.2: ist das PFS fehlt. Bedeutet, hat ein Akteur jahrelang Traffic mitgeschnitten und kommt dann irgendwie an den private Key des Servers, kann der komplette Traffic decrypted werden.

Fazit, alles böse was kein PFS nutzt und noch auf CBC setzt. Einfach nur TLS 1.0 und 1.1 stupide deaktivieren bringt erstmal nichts.
 
Zurück
Oben