Emotet Erkennung mit Icinga / Nagios und EmoCheck

In diesem Artikel beschreibe ich, wie man das Monitoringsystem Icinga bzw. Nagios in Verbindung mit EmoCheck nutzen kann um in einem Unternehmensnetz Emotet-Infektionen frühzeitig erkennen zu können und sich gegebenenfalls aktiv warnen zu lassen.

Neulich wurde bei Heise (https://heise.de/-4652554) über ein interessantes Tool berichtet, mit dem geprüft werden kann, ob ein PC bereits mit der Schadsoftware „Emotet“ infiziert ist. Dies erledigt das Tool „EmoCheck“ (https://github.com/JPCERTCC/EmoCheck/releases) indem es den Rechner auf Prozesse untersucht, die typisch für eine Emotet-Infektion sind. In dem Artikel wird darauf hingewiesen, dass sich ein mit Emotet infizierter Rechner nicht zwangsläufig sofort auffällig verhält. In dem genannten Artikel heißt es: „[…] typischerweise vergehen zwischen der ersten Emotet-Infektion in einem Firmennetz und dem Verteilen des Erpressungs-Trojaners Ryuk ein bis zwei Wochen.

Es gibt einige Diskussionen über die Funktionsweise dieses Tools. So regt sich einiges an Kritik am Umstand, dass EmoCheck nach statischen Prozessnamen sucht. Ich teile diese Bedenken dahingehend, dass Emotet seinen Prozessen jederzeit anderslautende Namen geben könnte. Allerdings bin ich der Meinung, dass dieses Werkzeug einen installierten Virenschutz sicherlich sinnvoll ergänzen kann und es in Anbetracht des doch erheblichen Schadenpotentials von Emotet sicherlich nicht schlecht ist, sich nicht nur auf einen Prüfmechanismus zu verlassen.

Voraussetzungen und Anmerkungen

In diesem Beispiel gehe ich von folgendem Setup aus. Mir ist bewusst, dass das Windows 7- End-of-life erreicht ist und auch Icinga 1 nicht mehr auf dem Stand der Dinge ist. Allerdings ist dieses Setup (Stand 02/2020) wohl nicht sehr realitätsfern. Die Domäne wird zur Zeit umgestellt, das Upgrade der Clients auf Windows 10 Enterprise ist ebenfalls in Arbeit. Es muss eben alles sorgfältig getestet werden, das braucht seine Zeit. Und gewisse Sachzwänge (Lizenzfragen, inkompatible Randsysteme, etc.) waren und sind eben auch gegeben.

Icinga 1 funktioniert einwandfrei und führt ca. 400 unterschiedliche Checks durch. Hier sehe ich keinerlei Veranlassung, auf Version 2 zu gehen.

Das Setup

  • Windows Domäne
  • ca. 100 Windows 7 Professional Clients
  • Icinga 1 auf einem Ubuntu 18.04.03 Host

Auf dem Ubuntu 18.04-Host läuft Samba mit einer Share „emocheck“, mit schreibendem Zugriff für alle („guest ok“). Der Pfad dieser Share ist „/opt/emocheck

Ablauf

Auf den Windows Clients wird im Verzeichnis C:\program files\emocheck das Programm emocheck_x64.exe (zu beziehen unter https://github.com/JPCERTCC/EmoCheck/releases) abgelegt.


Überprüfung beim Rechnerstart

Mithilfe eines Registry-Eintrags unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run sorgen wir dafür, dass das Emocheck-Tool bei jedem Rechnerstart automatisch ausgeführt wird. Indem wir einige Parameter mitgeben sorgen wir dafür, dass das Tool sein Testergebnis im Json-Format in die Samba-Share auf dem Icinga-Host schreibt.
Untenstehender Code kann genutzt werden, um den Eintrag zu erzeugen. Einfach in eine Datei schreiben und per Doppelklick ausführen.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"emocheck"="C:\Program Files\Emocheck\emocheck_x64.exe /quiet /json /output \\icinga\emocheck"

Das Icinga/Nagios Check Command

Für Icinga definieren wir ein Check Command, welches das Perl-Skript „check_emotet“ ausführt. Dies ist, abhängig von der Anzahl der von Icinga/Nagios ausgeführten Checks, alle paar Minuten der Fall.
Untenstehender Code sollte in die Icinga/Nagios-Config (z.B. „checkcommands.cfg“) eingefügt werden um das Check Command zu definieren.

define command {
                command_name                          check_emotet
                command_line                          $USER1$/check_emotet
}

Der Check „check_emotet“

Das Perl-Skript check_emotet ließt alle von den Windows-Clients zurückgelieferten Ergebnisdateien, die seit dem letzten Icinga-Lauf im Verzeichnis „/opt/emocheck“ gesammelt wurden, und überprüft den Wert von „is_infected„. Ist dieser Wert „no“, gibt das Skript den Returncode „0“  (OK) an Icinga zurück. Falls eine Infektion in einer der Dateien vermerkt wurde, gibt das Skript den Returncode „2“ (CRITICAL) zurück. Nach der Verarbeitung durch das Skript werden die Ergebnisdateien in das Verzeichnis „/opt/emocheck/processed“ verschoben.
Untenstehendes Skript in die Datei „/libexec/check_emotet“ schreiben und mit chmod +x ausführbar machen.

#!/usr/bin/perl
use strict;
use warnings;
use File::Copy;
binmode STDOUT, ":utf8";
use utf8;
use JSON;
use experimental qw( switch );
use feature qw(switch say);
# Declare infection pointer
my $infected = 0;
my $infected_host = "";
my $dir = '/opt/emocheck';
foreach my $fp (glob("$dir/*.json")){
        my $json;
        {
                local $/; # This enables 'slurp' mode
                open my $fh, "<", $fp;
                $json = <$fh>;
                close $fh;
        }
        my $data = decode_json($json);
        if ($data->{'is_infected'} eq 'yes'){
                # Infection found! Set $infected to 1 and set/concatenate affected hostnames delimited by '/'
                $infected = 1;
                if ($infected_host eq ""){
                        $infected_host = $data->{'hostname'};
                }else{
                        $infected_host .= "/" . $data->{'hostname'};
                }
        }
        move($fp, $dir. "/processed");
}
given ($infected) {
    chomp($infected);
    when ($infected lt '1') { print "OK - No infection found."; exit(0);      }
    when ($infected eq '1') { print "CRITICAL - One or more infections suspected. ($infected_host)"; exit(2); }
    default { print "UNKNOWN - UNCERTAIN STATE"; exit(3); }
}

Definition des Advanced Service

Als nächstes benötigen wir in Icinga/Nagios einen Advanced Service, dem das oben definierte Check Command zugeordnet wird und der außerdem die Konfiguration für Benachrichtigung und andere wichtige Aspekte enthält. Dieser Advanced Service wird dann unserem Icinga-Host zugeordnet womit der Check nun letztendlich eingebunden wird.
Untenstehender Code muss der Icinga-/Nagios-Konfiguration hinzugefügt werden (z.B. „advanced_services.cfg“).
Kurze Beschreibung der Konfiguration, sofern nicht selbsterklärend:

SchalterWertBeschreibung
max_check_attempts1Sollte auf '1' stehen, damit sofort nach der ersten
Rückmeldung eines "CRITICAL"-Wertes die Benachrichtigung
durchgeführt wird.
notification_optionsc,rNur bei 'critical' und 'recovery' benachrichtigen.
notification_enabled1Nur wenn dieser Wert auf '1' steht werden Benachrichtigungen
durchgeführt.
host_namez.B. icinga.mein.netzHostname der Maschine, auf der Icinga läuft.
contact_groupsz.B. adminsKontaktgruppen, die die Email-Adressen der gewünschten
Benachrichtigungsempfänger enthalten. Hier werden keine Email-
Adressen eingetragen!
define service {
                service_description                   Check Emotet Infection
                max_check_attempts                    1
                first_notification_delay              0
                notification_interval                 0
                notification_options                  c,r
                notifications_enabled                 1
                event_handler_enabled                 1
                check_command                         check_emotet!
                check_period                          24x7
                notification_period                   24x7
                host_name                             icinga.mein.netz
                contact_groups                        +admins,ProductionAdmins
                use                                   generic-service
}

Wichtige Hinweise zum Schluss

  1. Das vorgestellte Verfahren ist nicht perfekt und der Einsatz per „copy/paste“ ist nicht unbedingt sinnvoll. Es soll eher als Anregung zur Erarbeitung eines eigenen Konzeptes dienen.
  2. Ich übernehme keinerlei Gewährleistung, Haftung oder Sonstiges für Schäden, die aus dem Einsatz meiner Beispiele resultieren.
  3. Es muss bedacht werden, dass Icinga im Erkennungsfall den Status auf „CRITICAL“ setzt und dann die Ergebnisdateien verschiebt. Beim nächsten Lauf wird die ursächliche Datei nicht mehr geprüft, der Status wechselt dann also in Icinga/Nagios wieder auf „OK“ zurück. Man darf sich also keinesfalls nur auf den augenblicklichen Zustand im Icinga/Nagios-Dashboard verlassen. Die durch den Check versandten Benachrichtigungen per Email sind hier zu beachten!

Suchgeschwindigkeit in Roundcube erhöhen

Mal so nebenbei eine schnelle Lösung für ein nerviges Problem mit Roundcube.

Ich persönlich nutze hauptsächlich den Roundcube Webmailer. Er ist sehr flexibel, überall nutzbar und „eigentlich“ auch recht schnell. Mein Postfach habe ich mittels Ordnern strukturiert, die Datenmenge ist mit ca. 5 GB beachtlich.

Warum aber „eigentlich“ schnell? Sofern man Mails liest, schreibt und versendet ist der Webmailer wahrlich schnell. Benutzt man jedoch die Suchfunktion von Roundcube ist es mit der Geschwindigkeit schnell vorbei. Dies ging bei meinen System soweit, dass der Apache Webserver gelegentlich einen Fehler 500 zurückgab. Die Ursache war, dass der entsprechende PHP-Prozess in ein Timeout gelaufen war.

Wenn ich etwas such, dann erledigte ich dies bislang zumeist über den Mozilla Thunderbird Mailclient. Da dieser einen lokalen Suchindex aufbaut, bekommt man hier extrem schnell die gewünschten Suchergebnisse präsentiert. Was zuhause gut funktioniert, war mit Roundcube eben bisher ein wirkliches Problem.

Eine logische Erklärung brachte mir ein Beitrag im Plesk-Forum. Sobald man in Dovecot die Volltextsuche aktiviert, läuft die Suche mit bisher ungeahnter Geschwindigkeit. Hier die Lösung:

Auf dem Mailserver die Datei /etc/dovecot/conf.d/99-fts.conf anlegen und mit folgendem Inhalt befüllen:

protocol imap {
mail_plugins = "quota imap_quota fts fts_squat"
}
plugin {
fts = squat
fts_squat = partial=4 full=10
fts_autoindex = yes
}

Danach den Dovecot-Prozess neu starten, das Mail-Log sicherheitshalber auf Fehler untersuchen und die nun deutlich verbesserte Suchgeschwindigkeit genießen.

Der Beitrag, dem ich diese Information entnommen habe, ist unter der URL https://support.plesk.com/hc/en-us/articles/115000532574-The-search-speed-is-slow-in-Roundcube zu finden.

Raspberry Pi – Kernel Upgraden/Downgraden

Wie in meinem Artikel Tvheadend – Aussetzer beim Streaming erwähnt, kann es unter bestimmten Umständen notwendig sein, den Raspberry Pi mit einem anderen, als dem in der jeweiligen Raspbian-Version enthaltenen Kernel zu betreiben. Bekanntschaft habe ich mit diesem Problem bereits im Zusammenhang mit Tvheadend und Node-Red gemacht.

Ich werde nun beschreiben, wie der Kernel up- oder downgegraded werden kann. Hierfür setze ich voraus, dass der Raspberry Pi unter Raspbian läuft. Zunächst sollte man (sofern noch nicht geschehen) herausfinden, welcher Kernel aktuell läuft. Mit dem Befehl

uname -r

wird die momentan laufende Kernel-Version angezeigt. In meinem Fall war dies die 4.9.70-v7+.

Möchte man nun ein Downgrade auf die Version 4.4.50-v7+ durchführen, muss man sich den git-Hash des entsprechenden Commits heraussuchen. Dies erledigt man im Git-Repository von Hexxeh unter der Adresse https://github.com/Hexxeh/rpi-firmware . Mit einem Klick auf den Knopf „<soundsoviele> Commits“ bekommt man eine Übersicht über alle vorhandenen Kernel-Versionen angezeigt.

Nun wird bis zur gewünschten Version herunter gescrollt. Relevant sind hier die Einträge „kernel: bump to x.x.xx“. Im rechten Bereich der Ansicht können wir den entsprechenden Hash in die Zwischenablage nehmen.

Um nun die eigentliche Installation der gewünschten Version vorzunehmen gehen wir wieder in die Console und geben nun (beispielsweise für die 4.4.50) folgenden Befehl ein:

rpi-update 52241088c1da59a359110d39c1875cda56496764

Nun läuft die Installation an, die den Kernel, die Kernelmodule und die Firmware-Files installiert.

Im Anschluß muss der Raspberry Pi neu gebootet werden.

 

 

Tvheadend – Aussetzer beim Streaming

Wie man Probleme mit Aussetzern bei Tvheadend bei der Nutzung auf dem Raspberry Pi löst, erkläre ich in diesem Beitrag. Ich werde hier keine Anleitung zur Einrichtung von LibreELEC, Kodi, Tvheadend, etc. bereitstellen, da das Internet voll solcher Anleitungen ist.

Vor einem guten Jahr habe ich meinen konventionellen SAT-Receiver, eine „Volksbox“, in Rente geschickt. Sie lief mir nicht stabil genug und war mir im Handling etwas, naja, unbequem. Ich bin verwöhnt von einer DreamBox 7025, die ich jahrelang genutzt habe.LibreELEC

Länger schon wollte ich mich mit Kodi beschäftigen – einem Mediacenter für Fernsehen und so ziemlich alle anderen medialen Anforderungen, die man sich vorstellen kann. Mit LibreELEC (https://libreelec.tv/) habe ich eine Lösung gefunden, die man nur auf die SD-Karte packen muss, diese Karte in den Raspberry Pi stecken, booten und los geht’s…

Einen geeigneten Raspberry Pi hatte ich zur gleichen Zeit zu einem guten Preis als Bundle (Raspberry + Gehäuse + Netzteil + SD-Karte) irgendwo im Netz gefunden und bestellt.

Möchte man nur Filme, die man auf einem NAS liegen hat, ansehen oder Online-Mediatheken diverser Fernsehsender nutzen, dann muss man nur noch die entsprechenden „Apps“ im LibreELEC-Image installieren und kann dann sofort diese Dienste nutzen. Möchte man zusätzlich Satelliten-TV nutzen, wird es etwas komplizierter, da man nun einen SAT-Receiver dazu bringen muss, den jeweiligen per Kodi gewählten Sender ins Netzwerk zu streamen.

Aufbau

Bei mir kommt folgende Hardware zum Einsatz:

  1. LG 42″ Fernseher mit u.A. HDMI-Anschluss
  2. Ein Raspberry Pi 3 mit 16 GB SD-Karte (libreELEC installiert), angeschlossen am Fernseher
  3. Ein Raspberry Pi 2 als zentraler Server für interne NextCloud, DHCP, DNS, Node-RED-Host, etc.
  4. Ein an den zentralen Raspberry Pi 2 angeschlossener USB-Satreceiver (TechnoTrend TT-connect S2-4600), Tvheadend

Tvheadend steuert den Satreceiver, stellt also den vom sog. PVR-Client auf der LibreELEC-Maschine angeforderten Transponder ein und streamt somit das entsprechende Programm über’s LAN zu Kodi schickt. Nach einem Problem mit der SD-Karte am zentralen Raspberry Pi 2 habe ich diese Maschine neu installiert. Fortan hatte ich Probleme – das Fernsehbild zeigte oft Klötzchen, blieb hängen, schien puffern zu müssen und hatte Ton-Ausfälle. Im Syslog fand ich plötzlich folgende Meldungen:

Sep 30 23:35:07 raspberrypi tvheadend[696]: htsp: 192.168.5.200 [ Kodi Media Center ]: Identified as user 'xxxx'
Sep 30 23:35:08 raspberrypi tvheadend[696]: mpegts: 11347V in Astra - tuning on Montage Technology M88DS3103 : DVB-S #0
Sep 30 23:35:08 raspberrypi tvheadend[696]: subscription: 0001: "scan" unsubscribing
Sep 30 23:35:10 raspberrypi tvheadend[696]: mpegts: 11347V in Astra - tuning on Montage Technology M88DS3103 : DVB-S #0
Sep 30 23:35:11 raspberrypi tvheadend[696]: subscription: 0006: "epggrab" subscribing to mux "11347V", weight: 4, adapter: "Montage Technology M88DS3103 : DVB-S #0", network: "Astra", service: "Raw PID Subscription"
Sep 30 23:35:11 raspberrypi tvheadend[696]: tbl-eit: eit: 11347V in Astra: invalid checksum (len 1067, errors 1)
Sep 30 23:35:11 raspberrypi tvheadend[696]: tbl-base: sdt: 11347V in Astra: invalid checksum (len 306, errors 1)
Sep 30 23:35:14 raspberrypi tvheadend[696]: tbl-base: bat: 11347V in Astra: invalid checksum (len 136, errors 1)
Sep 30 23:35:15 raspberrypi tvheadend[696]: tbl-base: pat: 11347V in Astra: invalid checksum (len 28, errors 1)
Sep 30 23:35:17 raspberrypi tvheadend[696]: tbl-eit: viasat_baltic: 11347V in Astra: invalid checksum (len 174, errors 1)
Sep 30 23:35:17 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD Transport error indicator (total 1)
Sep 30 23:35:18 raspberrypi tvheadend[696]: tbl-base: pmt: 11347V in Astra: invalid checksum (len 138, errors 1)
Sep 30 23:35:18 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Sat Sep 30 23:35:48 2017 [try http://www.rsyslog.com/e/2007 ]
Sep 30 23:35:18 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: H264 @ #6710 Continuity counter error (total 1)
Sep 30 23:35:18 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: MPEG2AUDIO @ #6723 Continuity counter error (total 1)
Sep 30 23:35:18 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: TELETEXT @ #6730 Continuity counter error (total 1)
Sep 30 23:35:18 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: MPEG2AUDIO @ #6721 Continuity counter error (total 1)
Sep 30 23:35:18 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: AC3 @ #6722 Continuity counter error (total 1)
Sep 30 23:35:18 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: MPEG2AUDIO @ #6720 Continuity counter error (total 1)
Sep 30 23:35:19 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: H264 @ #6710: Invalid start code 58:ee:70
Sep 30 23:35:20 raspberrypi tvheadend[696]: tbl-base: pmt: 11347V in Astra: invalid checksum (len 138, errors 1)
Sep 30 23:35:20 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD Transport error indicator (total 1)
Sep 30 23:35:21 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: H264 @ #6710 Continuity counter error (total 1)
Sep 30 23:35:21 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: MPEG2AUDIO @ #6723 Continuity counter error (total 1)
Sep 30 23:35:21 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: AC3 @ #6722 Continuity counter error (total 1)
Sep 30 23:35:21 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: TELETEXT @ #6730 Continuity counter error (total 1)
Sep 30 23:35:21 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: MPEG2AUDIO @ #6721 Continuity counter error (total 1)
Sep 30 23:35:21 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: MPEG2AUDIO @ #6720 Continuity counter error (total 1)
Sep 30 23:35:21 raspberrypi tvheadend[696]: tbl-eit: eit: 11347V in Astra: invalid checksum (len 1410, errors 122)
Sep 30 23:35:22 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: MPEG2AUDIO @ #6720: Invalid start code 4f:94:9b
Sep 30 23:35:23 raspberrypi tvheadend[696]: tbl-base: sdt: 11347V in Astra: invalid checksum (len 306, errors 10)
Sep 30 23:35:23 raspberrypi tvheadend[696]: TS: Astra/11347V/ZDFinfo HD: AC3 @ #6722: Invalid start code f5:20:e8

Diese „Continuity Counter Errors“ bereiteten mir wirklich Kopfzerbrechen. Die Last auf dem zentralen RPI hatte sich durch die Neuinstallation nicht vergrößert. Da ich die Schüssel nur mit einem sehr rudimentären Messgerät ausgerichtet hatte, bestellte ich sogar einen Fachbetrieb für SAT-Installationen um nachzumessen. Es sei alles perfekt eingestellt, bestätigte der Techniker, an der Ausrichtung der Schüssel konnte es also nicht liegen. Heute konnte ich nun das Problem eingrenzen und schließlich erfolgreich lösen.

Nach der Neuinstallation lief mein zentraler RPI mit dem Kernel v4.9.35. Unter der URL https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=2 erhielt ich den finalen Hinweis. Es handelt sich um ein bekanntes Fehlerbild, dass Tvheadend unter dem v4.9-Kernel dieses Verhalten zeigt. Ich habe nun den Kernel, wie in der genannten URL beschrieben, auf die v4.4 zurückgedreht, wodurch es nun wieder wunderbar funktioniert.

Node-RED – Installation unter Ubuntu

Was ist Node-RED?

Node-RED LogoNode-RED ist ein grafisches Entwicklungswerkzeug, dass vor allem von Leuten benutzt wird, die sich mit IoT (Internet of Things – Internet der Dinge) auseinandersetzen. In erster Linie kann Node-RED dafür genutzt werden, Geräte (sowohl netzwerkfähiges Equipment als auch Geräte, die seriell, per Bluetooth, 1-wire, i²c, etc. angebunden sind) miteinander zu vernetzen, Daten per Sensor oder aus Cloud-Diensten zu empfangen, auszuwerten und weiter zu verarbeiten. Node-RED bietet hierfür eine hervorragende grafische Oberfläche an um dies visuell zu erledigen. Hochinteressant ist die Möglichkeit, auf Ereignisse, die von bzw. durch ein angeschlossenes Gerät (oder einen eingebundenen Dienst) erzeugt werden, eine weitere Aktion auslösen zu können.

WeiterlesenNode-RED – Installation unter Ubuntu

Eine eigene SSL Zertifizierungsstelle (Root CA) für die Nutzung im LAN erstellen – Teil II

Interne Zertifikate erzeugen

Im ersten Teil haben wir ein Root-Zertifikat für unsere eigene SSL Zertifizierungsstelle erzeugt. Wir sind nun in der Lage, nach Belieben SSL-Zertifikate zu erzeugen, denen unser Browser vertrauen wird (nachdem wir unsere Zertifizierungsstelle innerhalb unseres Netzwerks bekannt gemacht haben).

Wir werden uns nun Schritt für Schritt an die Erzeugung eines Zertifikates für einen Apache Webserver machen und uns ansehen, wie der Virtual Host konfiguriert werden muss.

WeiterlesenEine eigene SSL Zertifizierungsstelle (Root CA) für die Nutzung im LAN erstellen – Teil II

Eine eigene SSL Zertifizierungsstelle (Root CA) für die Nutzung im LAN erstellen – Teil I

Vertrauenssache – Interne SSL-Zertifikate

Im LAN werden oftmals SSL-Zertifikate zur Nutzung verschiedener  Dienste benötigt. Oft bleibt hier nichts anderes übrig, als selbstsignierte Zertifikate zu verwenden. Diese Zertifikate erfüllen zwar aus technischer Sicht ihren Zweck, den Anwender bzw. Administrator stellen sie aber immer wieder vor lästige Probleme.

WeiterlesenEine eigene SSL Zertifizierungsstelle (Root CA) für die Nutzung im LAN erstellen – Teil I