Datenupdate cs:Plus schlägt fehl… Lizenzfehler?

Bei der Aktualisierung von cs:Plus 1/2017 kann es mitunter zu Problemen beim Datenupdate bezgl. der Lizenz kommen. Vermutlich kommt der Datenbankupdateassistent mit der Historie der lizenz.txt nicht klar.

Um das Problem zu lösen, wird die Datei lizenz.txt unter C:\Program Files (x86)\ADDISON\Akte_AT\Daten\ einfach umbenannt z.B. lizenz.txt_bck. Anschließend kopiert man die letzte verfügbare Lizenzdatei wieder in o.g. Verzeichnis. Dann sollte das Datenupdate wieder funktionieren.

Sophos UTM 9.409-9 Directory Services synchronization Bug

Die  aktuelle Firmware 9.409-9 der Sophos UTM enthält offenbar einen Bug bezgl. der Authentifizierungsserver.

Der Fehler bezieht sich anscheinend nur auf den Test eines Beispielbenutzers. Jedenfalls konnte ich noch keine Funktionseinschränkungen beim Kunden feststellen, was den Webfilter oder das Userportal etc. angeht. In der vorherigen Firmware war das Problem auch schon enthalten; nur dass dort der Servertest fehl schlug und nicht die Benutzerauthentifizierung.

Webserverzertifikat public SSL für Sophos UTM einrichten…

Als Beispiel wird die Domäne www.vpn.sult.eu verwendet, unter der eine Sophos UTM über das Internet erreichbar sein könnte. Sollte man über keine feste öffentliche Adresse verfügen, kann man dieses Konstrukt auch über einen C-Name realisieren, der z.B. auf eine dyndns-Adresse zeigt.

Zunächst installiert man sich Openssl; ist frei im Internet für viele OS zum Download verfügbar. In diesem Beispiel machen wir es unter Windows.

Nach der Installation von Openssl navigiert man mittels der Eingabeaufforderung zum \bin Verzeichnis von Openssl (C:\Openssl\bin\) und generiert sich eine .key-Datei mit:

openssl genrsa -des3 -out www.vpn.sult.eu.key 2048

Beim Erzeugen der .key-Datei muss eine Passphrase angegeben und bestätigt werden. Die .key-datei wird im Verzeichnis C:\Openssl\bin\ abgelegt.

Nun erstellt man eine Zertifizierungsanfrage; also eine .csr-Datei mit:

openssl req -new -key www.vpn.sult.eu.key -out www.vpn.sult.eu.csr

Nachdem man den Befehl abgesetzt hat, wird die Passphrase der zuvor erstellen .key-Datei benötigt. Dann trägt man die Zertifikatsinformationen ein. Wichtig ist, dass bei „Common Name“ die Domäne eingetragen wird, auf die das Zertifikat ausgestellt werden soll. In diesem Beispiel also www.vpn.sult.eu:

„challenge password“ und „optional company name“ können leer gelassen werden.

Die .csr-Datei unter C:\Openssl\bin\ kann mit einem Editor geöffnet werden und sieht so ähnlich aus wie unten angegeben:

Ihr Inhalt wird einfach markiert, kopiert und bei einer Zertifizierungsstelle Eurer Wahl eingereicht. Wie das genau geht, hängt von Eurer gewählen Zertifizierungsstelle ab.

Bekommt man das entsprechende Zertifikat von der Zertifizierungsstelle zurück, erhält man eine .crt-Datei; speichert man am besten direkt unter C:\Openssl\bin\.

Die Sophos benötigt das Zertifikat mit privatem Schlüssel als .p12-Datei. Dieses wird erstellt mit:

openssl pkcs12 -export -in www_vpn_sult_eu.crt -inkey www.vpn.sult.eu.key -out www.vpn.sult.eu.p12

Auch hier wird wieder die Passphrase der .key-Datei benötigt. Anschließend muss ein Exportkennwort angegeben und bestätigt werden. (Achtung! www_vpn_sult_eu.crt mit Unterstrichen!)

Das Zertifikat im .p12-Format kann auf der Sophos unter Webserver Protection -> Zertifikatsverwaltung hinzugefügt werden. Beim Hinzufügen des Zertifikats die Methode „Hochladen“ auswählen und das Exportkennwort angeben.

Dann unter Verwaltung -> WebAdmin-Einstellungen das hinzugefügte Zertifikat anwählen und übernehmen – fertig.

Winplausi startet nicht mehr…

Sollte das Programm zur Datenerfassung und Plausibilitätsprüfung Winplausi nicht mehr starten, ohne dass eine Fehlermeldung erscheint, liegt das daran, dass die Anwendung zuvor nicht korrekt geschlossen wurde. Das Profil kann dann beschädigt sein.

Um den Fehler zu beheben, muss lediglich der Inhalt unter C:\Users\Benutzername\.plausi\ entfernt werden. Das Profil wird nach dem Start von Winplausi wiederhergestellt.

ebackup.exe verursacht hohe CPU Auslastung…

Das mit Escan gelieferte ebackup erzeugt, wie der Name schon sagt, Backups von Daten, die es auf lokale Partitionen schreibt. Zum Beispiel auf C:\escanbackup\.

Sinn dieser tollen Funktion ist es, Daten nach einem potentiellen Verschlüsselungs- oder Löschungsvorgang durch Schadsoftware wiederherstellen zu können; soweit klar!

Unsinnig ist jedoch, dass die Daten lokal gesichert werden und die CPU Nutzung von ebackup.exe das System stark auslastet.

Das passiert natürlich auch auf einem Fileserver, auf dem Escan installiert ist. Der Speicherplatz ist dann natürlich auch schnell aufgebraucht, wenn ebackup die ganzen Daten auf Systempartitionen sichert.

Hier hat ebackup auch nichts zu suchen, da Server durch hoffentlich andere/bessere Backupsoftware gesichert werden.

Der Hersteller hat es leider versäumt, ebackup in die Administrationskonsole zu integrieren, weshalb man die Funktion auf jedem Client/Server von Hand einstellen muss.

Die Konfigurationschnittstelle findet man unter C:\Program Files (x86)\eScan\ebackup.exe.

Da, wo ebackup nicht benötigt wird, kann der Job inaktiv gesetzt oder gleich gelöscht werden.

Ausgesperrt…

Dass die Sophos UTM mit einem Active Directory und anderen Verzeichnisdiensten gekoppelt werden kann ist schon eine tolle Sache. Viele Next-Generation Firewallhersteller haben an dieser Stelle wirklich das Nachsehen.

So lassen sich unter anderem für den Fernzugriff z.B. mit SSL-VPN Berechtigungen setzen, die die Admins nur noch über das AD per Gruppenzuweisung steuern.

Was ist aber, wenn der Domaincontroller nicht mehr verfügbar ist? Beispielsweise in kleinen Unternehmen mit einem SBS.

Ein lokal eingerichteter User auf der Sophos, der einem SSL-Profil zugeordnet ist, spart die Fahrt zum Kunden.

Scan to Email liefert Timeout…

Bei der Verwendung eines Journalempfängers zur Archivierung von ein- und ausgehenden Emails mittels Mailstore kann es nach einiger Zeit zu ungewöhnlichem Verhalten kommen. Zumindest dann, wenn der Archivierungsjob nicht stetig kontrolliert wird.

Die Archivierung des Journalpostfachs wird so eingerichtet, dass das Postfach anschließend geleert wird. Schlägt der Vorgang allerdings seit längerer Zeit fehl, ist die logische Konsequenz, dass das Postfach irgendwann zu voll wird.

Sind nun Grenzwerte für das Postfach eingestellt, verweigert der Mailserver die Annahme neuer Emails für den Journalempfänger, was dazu führt, dass er seine Queue nicht abarbeiten kann. Somit wird die Warteschlange immer voller und voller.

Das Ganze fällt dann auf, wenn z.B. berichtet wird, dass Drucker bei der Funktion Scan2Email einen Timeout liefern; das eingescannte Dokument jedoch verzögert zugestellt wird.

Die Prüfung des Mailservers zeigt sehr deutlich, dass man auf  „250 2.0.0 Ok: queued“ gefühlt 2 Minuten warten muß.

Anmeldeproblem Datev usrlogon.cmd

Unter bestimmten Voraussetzungen kommt es beim Anmelden an Terminalservern, auf denen Datev installiert ist zu Problemen mit der Abarbeitung des Scriptes usrlogon.cmd. Und zwar beim Einhängen des Laufwerks w:\.

Zwar wird das Laufwerk w:\ lt. der Datev nicht mehr benötigt, es sollte jedoch bei älteren Installationen beibehalten werden.

Das Script ist zu finden unter c:\windows\system32\. Um den Fehler nach dem Schema „quick & dirty“ zu beheben, reicht es aus, das Script um eine Zeile zu erweitern.

Die Einbindung eines „net use w: /delete /yes“ an der korrekten Stelle lässt das Script wieder sauber abarbeiten.

Wenn SPX-Emailverschlüsselung, dann bitte auch richtig…

Die Verschlüsselung von Emails via Sophos SPX ist eine feine Sache. Zumindest dann, wenn der Emailempfänger nicht selbst mit PGP oder S/MIME verschlüsselt.

Eigentlich sollte die Verschlüsselung von Emails dem Kunden gegenüber eine gewisse Sicherheit suggerieren. Grundsätzlich macht die SPX-Verschlüsselung das auch…

…aber nichts wirkt unseriöser, als wenn Unternehmen eine Sicherheitskomponente einsetzen und deren Klienten eine dicke Zertifikatsfehlermeldung erhalten, beim Versuch sich im SPX-Portal zu registrieren.

Das Geld für ein positiveSSL-Zertifikat sollte bei einer Implementierung der SPX-Verschlüsselung nicht fehlen.

Sophos Contentfilter blockiert alles

Ein Klient meldete sich, dass keine Webseiten aufgerufen werden konnten. Im Livelog des Webfilters der Sophos UTM war ersichtlich, dass die „default block“ Richtlinie greift. Was war die Ursache des Problems?!

Neustart des Webfilters brachte nicht das gewünschte Ergebnis; hätt ja sein können. Das Livelog zeigte noch immer an, dass die „default block“ Richtlinie greift…

… und die greift immer dann, wenn die Nutzer nicht authentifiziert werden können…

Also schnell mal die Authentifizierungsserver in der Sophos getestet und siehe da, der Servicebenutzer zur Kommunikation mit dem AD kann sich nicht authentifizieren.

Keine Kommunikation zum AD, keine Abfrage der Sicherheitsgruppen aus dem AD, ergo „default block“.

Was war passiert? Der Servicebenutzer im AD wurde versehentlich in eine andere OU geschoben. Die Bind-DN wird auf der Sophos allerdings fest eingetragen. Also schnell die Bind-DN angepasst und alles wurd gut.