Als Tools wie Office 365 die Zusammenarbeit mehrerer Nutzer über das Internet an einem Dokument ermöglicht haben, war „Kollaboration“ das Buzzword der Stunde. Mittlerweile gehören kollaborative Features fast zum Standard von moderner Software: Mehrere Nutzer können standortunabhängig, oftmals unabhängig vom genutzten Endgerät und dem Betriebssystem, einfach nur über das Internet, miteinander an einem Ergebnis arbeiten. Was im Internet und im Browser normal geworden ist, betritt nun langsam die nächste und damit dritte Dimension.
Meinen Blog gibt es nun schon seit fast 10 Jahren, verrückte Sache. Und obwohl ich grob über 300 Tutorials und How-To’s geschrieben habe, ist es wie so oft: Der Schuster hat gerne mal die schlechtesten Leisten. Wartung und Pflege des eigenen Systems geraten bei viel Stress und wenig freier Zeit in den Hintergrund. So kommt es, dass mich die Firma Enginsight letztens kontaktiert hat. Der Inhalt war ein weniger positiv – man übergab mir einen Sicherheitsbericht meines Blogs. Dieser enthielt Bewertungen in mehreren Kategorien und leider nicht nur gute, dazu später mehr. Das war der Anlass, dass ich mich mit der Sicherheits-Suite von Enginsight und der Sicherheit meines Blogs detaillierter auseinandergesetzt habe.
Erster Eindruck
Die Suite von Enginsight möchte mit ihren Tools die Sicherheit und Verfügbarkeit von IT-Netzwerken erhöhen und den Aufwand der Wartung und Überwachung verringern. Das Netzwerk kann hier beliebig verschieden und groß sein – von 1 Webseite, einem PC oder Server bis hin zu einem aus mehreren Nodes und Netzwerkkomponenten bestehenden Netzwerk.
Dank des 14-tägigen Probeaccounts lässt sich die Suite auch direkt selbst ausprobieren. Nach dem Login lande ich auf einem sehr übersichtlichen Dashboard, in dem mir meine eingerichteten Assets (in diesem Moment natürlich noch keine) angezeigt werden. Über eine Menüleiste habe ich schnellen Zugriff auf die wichtigsten Funktionen: Umgebungen, Hosts, Endpunkte, Alarme, Einstellungen, Suche, mein Profil sowie einigen weiteren Kleinigkeiten.
Übersichtliches Enginsight Dashboard mit ersten angelegten Assets
Detaillierte Analysen
Ich habe hier direkt meinen Blog als einen Endpunkt angelegt. Endpunkte sind Webseiten oder Webapplikationen, für die verschiedene Funktionen zur Verfügung gestellt werden: Webseite (Verfügbarkeitstests aus EU/USA), SSL/TLS, Web Thread Intelligence, Portscan, HTTP-Headers und Redirects. Die Funktionen können flexibel hinzugefügt werden. Anschließend starten direkt die ausgewählten Untersuchungen auf das eingegebene Ziel und nur wenige Sekunden später erhalte ich eine ausführliche Analyse meiner Seite:
Endpunkte erstellen und gewünschte Funktionen aktivieren
Übersicht aller Berichte eines Endpunktes mit ersten Details
Schnell ist klar: Hier muss was gemacht werden! Ich gehe mal kurz die Features durch und was jeweils untersucht wird:
Webseite: Stündliche Verfügbarkeitstests von Servern aus Frankfurt (EU) oder East-Virginia (USA), Analyse der Verbindungszeiten (wieviel Millisekunden Lookup, Connect, Transfer usw.)
HTTP-Headers: Analyse der Antwort-Header-Eigenschaften und speziell der Security-Header. Dazu mehr im Kapitel weiter unten
SSL/TLS: Untersuchung des verwendeten SSL-Zertifikats, der unterstützten Protokolle und Chiffren sowie möglicher Sicherheitslücken bzgl. SSL
Redirects: Weiterleitungen der Domain
Web Threat Intelligence: Prüfung von Sicherheitslücken beim Server, benutzten Anwendungen, der Webseite, benutzter Frameworks und Errechnung eines Scores
Portscan: Offene Ports und deren Service, ggf. Informationen zu eingesetzter Software und Version hinter einem Port
Bei der dauerhaften Verwendung von externen Dienstleistern, vor allem wenn (personenbezogene) Daten der eigenen Plattform dort verarbeitet werden, müsst ihr darauf achten, das Verzeichnis von Verarbeitungstätigkeiten zu ergänzen. Ansonsten wäre das im worst-case ein Datenschutzverstoß.
Ein Bericht hat mir dabei besonders wenig gefallen: Die Bewertung F bei den HTTP-Header. Also habe ich hier mal einen detaillierteren Blick geworfen:
Crashkurs HTTP-Headers
HTTP-Header sind Anweisungen, die vom Server- oder Webseitenbetreiber konfiguriert werden, um die Sicherheit des Webangebots sowie der Besucher zu erhöhen. Die Anweisungen können, je nach Hosting Setup, recht einfach über die .htaccess (empfohlen beim Shared Webhosting) gesetzt werden. Im folgenden nenne ich zwei beispielhafte Security-Header, es gibt jedoch noch mehr:
HTTP Strict Transport Security (HSTS)
HSTS gibt vor, dass und für welchen Zeitraum in der Zukunft alle Anfragen über HTTPS/SSL vom Client zum Server geschickt werden müssen. Anfragen über HTTP werden innerhalb dieses Zeitfensters dann komplett geblockt. Eine Beispielkonfiguration wäre:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>
Anzupassen: max-age als Zeitangabe in Sekunden, wie lange der Zugriff in Zukunft für diesen gerade aufrufenden Client ausschließlich über SSL erfolgen muss. Der Wert 31536000 steht demnach für 1 Jahr. includeSubDomains erweitert dieses Verfahren auf alle Subdomains. Weitere Informationen und Details zu HSTS und die preload-Eigenschaft in meinem separaten Artikel zum Thema HSTS und XSS-Protection hier.
Content-Security-Policy (CSP)
Der Content-Security-Policy Header überprüft die Art und Herkunft von Daten und Anfragen während des Ladens und kann darauf reagieren. Damit wird verhindert, dass unerwünschte, fremde oder gefährliche Inhalte geladen und ausgeführt werden. Das ist für gewöhnlich das Ziel von XSS-Angriffen und Code-Injections, schädliche Inhalte in vertrauenswürdige Seiten einzubinden.
Die Kontrolle der Inhalte wird hierbei in unterschiedliche Kategorien (auch Direktiven genannt) aufgeteilt und jeweils können erlaubte Datenquellen definiert werden. Beispielsweise gibt die Direktive script-src an, von welchen Domains und Quellen Skripte in die geschützte Seite eingebunden werden dürfen. Ein CSP-Beispiel:
Diese CSP definiert erlaubte Datenquellen für die Direktiven default-src, img-src, script-src, font-src und definiert einen Bericht-Endpunkt mit report-uri. Die Angabe ’self‘ erlaubt Daten von der eigenen Domain, in der die CSP benutzt wird. Zusätzlich wurden für Bilder die Domains von gravatar.com und wordpress.org sowie die Einbindung von data-uri Bildern als Ausnahmen definiert. Ebenso das Laden von Schriften vom Google Repository. Wenn ein Angreifer nun versucht, beispielsweise über einen Kommentar ein Skript von seiner Angreiferdomain einzubetten, würde die CSP dies blocken, da nur die eigene Domain Skripte einbinden darf.
Sicherheit von Hosts auch mit Künstlicher Intelligenz überwachen
Zurück zur Enginsight-Suite, denn hier gibt es noch viel mehr zu entdecken! Aus Gründen der Komplexität reiße ich die folgenden Features nur grob an.
Wie eingangs erwähnt, lassen sich auch Computer und Server in das System einfügen und durchleuchten. Dafür wird ein Client auf den Geräten eingerichtet und schon werden etliche Systemkomponenten untersucht: Auslastung von CPU, RAM, SWAP, integrierte Partitionen, Netzwerkschnittstellen, installierte Software und Updates sowie laufende Prozesse. Daran erkennt Enginsight dann mögliche Sicherheitsrisiken und gibt Handlungsempfehlungen.
Außerdem wacht eine auf Neuralen Netzwerken basierende Künstliche Intelligenz über die erfassten Daten. Auf Wunsch erkennt diese beispielsweise wenn personenbezogene Daten das Netzwerk verlassen oder bestimmte Metriken wie CPU oder RAM ihre Normalwerte verlassen. Basierend auf den gelernten Daten erkennt die KI Anomalien und alarmiert den Admin. Dieser kann den Vorfall dann einstufen und die KI lernt für zukünftig Entscheidung aus diesem Handeln. Somit wird die KI immer intelligenter und der Admin hat weniger Verwaltungsaufwand.
Im Peacemaker werden die Systemupdates aller angelegten Hosts in einer Übersicht angezeigt und können direkt verwaltet werden. So lassen sich beispielsweise unter Linux Updates direkt aus Enginsight heraus installieren.
Unter dem Menüpunkt Umgebung versteckt sich ein Visualisierungstool, mit dem die angelegten Assets miteinander in Verbindung gebracht werden können. Außerdem lassen sich hier auch Notizen oder ganze Dokumentationen für jedes Asset hinzufügen. So fehlt nie der Überblick bei komplexen Infrastrukturen.
Übersicht der Eigenschaften eines gescannten Hosts
Alle Systemupdates aller Hosts in einer Übersicht
Host-Übersicht mit Hardware-Details
Mit der Funktion „Umgebung“ lassen sich mit den hinzugefügten Assets IT-Netzwerke visualisieren
Automatisierung über Alarme und Plugins
Zwei weitere Funktionen lassen sich gut kombinieren, um eine Automatisierung von Maßnahmen im Problemfall zu realisieren: Alarme können erstellt werden, um regelmäßige Überprüfungen durchzuführen und im Problemfall Maßnahmen zu ergreifen. Mögliche Überwachungen bei einem Endpunkt: Response Time, Tage bis Zertifikatsablauf, Webseite nicht erreichebar, Neue Sicherheitslücke, Datenschutzverstoß. Für Hosts gibt es noch mehr, hier nur ein paar: Temperatur, neue oder entfernte Programme, Verdächtiger Netzwerkverkehr. Natürlich lassen sich hier Benachrichtigungen einstellen, aber als besonderes Extra gibt es auch Plugins, die im Problemfall ausgeführt werden können.
Plugins sind im Skripte, die selbst geschrieben werden können. Zur Verfügung stehen die drei Sprachen: Bash, Powershell und Python. Plugins können per Cronjob regelmäßig ausgeführt oder eben von Alarmen getriggert werden. Dem Troubleshooting sind mit diesen drei Sprachen kaum Grenzen gesetzt. Beispielsweise könnten per SSH im Falle des Ausfalls bestimmter Webseiten die Netzwerksettings vom Server geändert oder repariert werden.
Erstellen eines Alarms für einen Endpunkt
Vorlage für eigene Plugins, die per Cronjob oder Alarm ausgeführt werden
Fazit
Die Enginsight-Suite bietet eine große Palette an Sicherheits- und Überwachungsfeatures (nicht alle konnte ich in diesem Artikel vorstellen), mit denen sich einzelne Assets oder ganze Netzwerke analysieren und steuern lassen können. Dank KI-Metrik-Überwachung, Alarmen, Plugins und anderen kombinierbaren Lösungen ist hier eine großes Potential für Automatisierung, wenn alles richtig eingerichtet wird. Das Produkt ist immernoch stark in der Entwicklung und der Kontakt zum Enginsight-Team war äußerst angenehm – hier steckt viel Herzblut im Produkt.
Auf meinem Tisch steht heute ein ganz besonderer PC! Groß und schwer?Keinesfalls! Lüfter und laut? Im Gegenteil! Denn ich teste heute den PrimeMini4 – ein lüfterloser, nachhaltiger und superrobuster Mini PC mit Style. Prime Computer ist der Hersteller dieses kleinen Technikmeisterwerks. Das 2013 gegründete Schweizer Unternehmen hat sich auf nachhaltige IT-Technik spezialisiert und bietet mittlerweile drei unterschiedliche Produkte an. Diese sind: Mini PCs in unterschiedlichen Versionen, einen Mini Server und einen Amplifier. Bis auf den Amp sind alle Produkte komplett anpassbar, was die interne Hardware angeht und somit sehr flexibel auf die benötigte Leistung anpassbar. Das Konzept klingt stimmig und passend in die aktuelle Zeit. Weiterlesen
Linus Sebastian ist ein – und er freut sich bestimmt über dieses Lob – Vorzeige-Nerd der Extraklasse! In mehreren Youtube Kanälen vermittelt er technische Themen unterschiedlicher Art.
In Techquickie werden kurze IT-Erklärbär-Videos über Grundlagen-Wissen/-Begriffe oder Vergleiche von Technologien und Technik gepostet:
Mit Linus Tech Tips deckt er mit seiner Crew der Linus Media Group eine große Bandbreite verschiedenster technischer Themen ab, da findet jeder Nerd was zu Gucken:
Nachdem ich Ende 2016 noch das Deployment von Adobe Reader DC mit der alten AIP-Methode beschrieben hatte, gibt es jetzt ein Update, eine neue Deployment-Methode, die super schnell und einfach ist und viel weniger Schritte benötigt. Statt wie bisher das gewünschte Adobe Update direkt in die primäre Installation zu slipstreamen (einzubinden), wird der Patch jetzt per Befehl an die msiexec Installation übergeben und mitinstalliert. Damit entfällt die komplette AIP-Erstellung, was Zeit und CMD-Getippe spart.
Download & Vorbereitung
Ihr benötigt natürlich immernoch die aktuellste Reader DC Version als .exe Download von der Adobe Download Seite. Die .exe Datei dann einfach in einen Ordner entpacken und ihr erhaltet die typischen MSI-Deployment Daten.
Anpassung
Wenn ihr zusätzlich die Sprache der Verteilung festlegen wollt, öffnet die setup.ini und ergänzt dort einige Zeilen:
Ändert hier und in der setup.msi den Namen der .mst in eure .mst Datei und passt auch wieder die Pfade am Anfang des Deployment-Skripts an. Für das Cleanup braucht ihr auch ein paar zusätzliche Cleanup-Tools von Adobe, die ihr ggf. noch herunterladen und im Ordner ablegen müsst.
@echo on & Color 9f & setlocal
set wd=\\server\Deployment\Software\Reader
set log=%wd%\reader-log.txt
set tools=\\server\Deployment\Sonstiges\tools
set readerEL=999
set retry=0
set forcecleanup=yes
:: set deactivateToolsSidebar=yes
set exepath=none
set instversion=0.0
REM:: ******************
set version=18.009
REM:: ******************
REM:: Clientfilter: nur die Computer aus der allowedPCs.txt dürfen installieren
::for /f %%f in (%wd%\allowedPCs.txt) do if "%computername%"=="%%f" goto start
::goto end
REM:: Clientfilter: die Computer aus der deniedPCs.txt dürfen nicht installieren
for /f %%f in (%wd%\deniedPCs.txt) do if "%computername%"=="%%f" goto end
:start
if exist "c:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" set exepath="c:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe"
if exist "c:\Program Files\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" set exepath="c:\Program Files\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe"
if %exepath%==none goto install
goto checkversion
:checkversion
for /f "tokens=1-3" %%i in ('%tools%\sigcheck %exepath%') do ( if "%%i %%j"=="File version:" set instversion=%%k )
%tools%\VersionCompare.exe %instversion% %version%
set versionEL=%errorlevel%
if "%versionEL%"=="-1" goto beforeinstall
if "%versionEL%"=="0" echo %date% %time:~0,8% - %computername% hat bereits %instversion% installiert >> %log%
if "%versionEL%"=="1" echo %date% %time:~0,8% - %computername% hat bereits %instversion% (neuer) installiert >> %log%
goto end
:beforeinstall
if "%forcecleanup%"=="yes" goto cleanup
goto install
:cleanup
echo %date% %time:~0,8% - %computername% deinstalliert alle Reader Versionen... >> %log%
REM:: uninstall all reader versions
taskkill /im acrord32.exe /t /f
taskkill /im acrord64.exe /t /f
ping localhost -n 3
::start /w %wd%\cleaner\reader-cleaner-9.exe /silent /product=1
::start /w %wd%\cleaner\reader-cleaner-10.exe /silent /product=1
start /w %wd%\cleaner\reader-cleaner-dc.exe /silent /product=1
echo %date% %time:~0,8% - %computername% hat alle Reader Versionen deinstalliert... >> %log%
goto install
:install
echo %date% %time:~0,8% - %computername% (%instversion%) startet die Installation... >> %log%
::start /w "" "%wd%\deploy\%version%\setup.exe"
msiexec /i "%wd%\deploy\%version%\AcroRead.msi" PATCH="%wd%\deploy\%version%\AcroRdrDCUpd1800920044.msp" TRANSFORMS="LEAP.mst" /qb
set readerEL=%errorlevel%
if %readerEL%==1618 goto retry REM:: msiexec process in use, installation already in progress
if %readerEL%==1602 goto retry REM:: user canceled installation
if %readerEL%==1603 goto retry REM:: fatal error, some use it for "already installed" (eg. java)
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%... >> %log%
if %readerEL%==0 md %wd%\deploy\%version%\complete\%computername%
goto end
:retry
if %retry%==1 goto retryfailed
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%, retry in 5min... >> %log%
set retry=1
ping localhost -n 300 > nul
goto beforeinstall
:retryfailed
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%, retry failed, end >> %log%
goto end
:end
endlocal
exit
Die Anweundung von Active Directory Gruppenrichtlinien lässt eine Filterung und Steuerung über verschiedene Techniken zu:
Verknüpfung mit OUs (die Voraussetzung ist gewissermaßen die erste Filterebene), Verknüpfungen aktivieren/deaktivieren
Sicherheitsfilterung mit Gruppen und Rechten
WMI-Filterung
Die ersten beiden sind gewissermaßen schon die Voraussetzung für das Erstellen und Anwenden einer Gruppenrichtlinie. Mit einer guten OU- und Gruppenstrukturen lassen sich bereits viele „Filter“ realisieren. Allerdings sind Rechte, Gruppen und OUs oftmals auch aufwändig in der Pflege.
Negativbeispiel: Mit einer „Windows10Clients“-Gruppe kann eine Filterung auf Sicherheitsebene vollzogen werden. Dazu muss die „Windows10Clients“-Gruppe jedoch händisch von den Admins gepflegt werden – neue Clients rein, alte Clients raus. Ebenso eine „SalesPCs“-Gruppe. In größeren Strukturen ist das nicht umsetzbar und geht auch einfacher.
Erweiterte Gruppenrichtlinienfilterung mit WMI
Hier kommen WMI-Filter ins Spiel. WMI, Windows Management Instrumentation, ist praktisch eine Schnittstelle zum Windows System, welches über Abfragen in einer Art SQL (WQL genannt) bedient wird und Informationen über das abgefragte System liefert. Solche Abfragen können ebenfalls für die Filterung von GPOs verwendet werden.
Beispiel: Wenn eine GPO nun also nur für Windows 10 Clients oder nur für Clients älter als Windows 10 übernommen werden soll, lassen sich die Clients super easy über WMI herausfiltern. Keine OU, keine Gruppen, nur 1 WMI-Objekt, im Endeffekt nur eine Zeile Code.
Mit Google oder Tools wie dem WMI Code Creator von Microsoft lassen sich somit schnell die benötigten Abfragen erstellen:
Codebeispiele
Die Möglichkeiten sind vielseitig, hier ein paar Beispiele:
/* 32bit / 64bit */
SELECT * FROM Win32_OperatingSystem WHERE OSArchitecture = '32-Bit'
SELECT * FROM Win32_OperatingSystem WHERE OSArchitecture = '64-Bit'
/* Computername beginnt mit "vpc-" */
SELECT * FROM Win32_ComputerSystem WHERE Name LIKE 'vpc-%'
/* Sprache des Betriebssystems ist Deutsch */
SELECT * FROM Win32_OperatingSystem WHERE CountryCode = '49'
/* Internetexplorer ist in Version 8 installiert */
SELECT * FROM CIM_DataFile WHERE Filename = 'iexplore' AND version > '8.0' AND (path = '\\programme\\Internet Explorer\\' OR path = '\\program files\\Internet Explorer\\' )
Zum Erkennen des Betriebssystems eignen sich einige Variablen; von BuildNumber über Caption bis zu Version. Letztere ist einfach zu benutzen, da Microsoft für jede Betriebssystemversion plus dazu passende Servervariante die gleiche Version benutzt, weitere Infos dazu auf dieser Microsoft Seite.
/* Wählt alle Clients mit Windows Vista/7/8/8.1 (Nicht-Windows-10) */
SELECT * FROM Win32_OperatingSystem where Version like '6.%' and ProductType='1'
/* Windows 10 Clients only */
SELECT * FROM Win32_OperatingSystem where Version like '10.%' and ProductType='1'
Vorsicht: BuildNumber
Etwas nerviger ist die Abfrage der Windows Version anhand der BuildNumber, da diese nicht als Zahl sondern als String im System steht und somit einfache BuildNumber >= X Abfragen nicht funktionieren. Microsoft thematisiert das hier und wählt den Regex-ähnlichen Ansatz über die Anzahl der Ziffern in Kombination mit der BuildNumber. Auch Marc von gruppenrichtlinien.de verwendet WHERE BuildNumber > '5000' – das alles lief bei mir nicht zuverlässig. BuildNumber scheint mir ein schlechtes Werkzeug zu sein und ich gehe daher über die Betriebssystem Caption, die sehr standardisiert ist:
/* Windows 10 Clients */
SELECT * FROM Win32_OperatingSystem WHERE Caption LIKE '%10%' AND BuildNumber LIKE '[123456789][0123456789][0123456789][0123456789][0123456789]'
/* Alle Clients vor Windows 10 */
SELECT * FROM Win32_OperatingSystem WHERE NOT Caption LIKE '%10%' AND BuildNumber LIKE '[123456789][0123456789][0123456789][0123456789]'
Das hat bei Win7 und Win10 funktioniert wie erwünscht.
Ich habe in letzter Zeit auf Arbeit mit einigen Rechnern gekämpft, die die AD-Gruppenrichtlinien nicht mehr ausführen wollten, genau genommen gar keine AD-Verbindung mehr hatten. Die Anzahl der Geräte, die sich bei meinem Deployment-Manager gemeldet haben, sank immer weiter. Mit den PCs schien ansonsten alles in Ordnung: Domänenmitgliedschaft, Internet, Intranet, Serververbindung mit Netzlaufwerken, alles da. Wie kommt’s? Weiterlesen
