Die PowerShell war für die Administration schon immer ein sehr wichtiges Werkzeug. Doch heute nehmen die Virtualisierungs-, Cloud- und Multicloud-Technologien, “software defined datacenter” haben im professionellen IT-Umfeld die Überhand. Da ist die PowerShell als eine Automationssprache gefragter denn je. Nicht zu vergessen, dass die PowerShell auch auf Linux und MacOS läuft.

Und natürlich sind die vor nicht all zu langer Zeit eingeführten Verbesserungen ganz nett: Strg+C, Strg+V können endlich mal auch in der Konsole benutzt werden; farbige Gestaltung der Konsole, das Einstellen von Transparenzen ist ebenfalls möglich.

PowerShell – Cmdlets

Die “Cmdlets” sind die nichts anderes als PowerShell-Befehle. Ausgesprochen wird es übrigens mit “Commandlets”. Neben den Basis-Befehlen, die jede PowerShell Installation mit sich bringt, gibt es zahlreiche PowerShell Erweiterungen. Diese Erweiterung bieten wiederum eine ganze Menge spezialisierter Cmdlets an, zum Beispiel für:

• Exchange Server
• SQL Server
• Azure
• SharePoint
• und vieles mehr und zwar in unterschiedlichsten Versionen…

Die Syntax eines Cmdlets ist in der PowerShell sehr konsequent: es besteht aus einen Verb und einem Nomen. Das Verb bestimmt, was gemacht werden sollte, zum Beispiel: “Set” oder “Get”. Das Nomen ist demnach der Bereich auf das sich das Verb bezieht: sprich womit etwas gemacht werden sollte. Das wären beispielsweise: “ComputerInfo”, “Service”, “Date” und so weiter.

Beispiel:

Get-ComputerInfo

Dieses Cmdlet gibt uns die Informationen über den Computer und zwar ziemlich detailliert.

Wenn man sich nicht sicher ist, welches PowerShell Cmdlet man benutzen sollte, schafft der Befehl “Get-Command” oft Abhilfe. Mehr zum den Strategien, um richtige Befehle zu finden gibt es in diesem Beitrag: PowerShell Befehle finden

Praktischer Tipp

Powershell Parameter

Wenn wir jedoch nur bestimmte Eigenschaften “Properties” sehen wollen, können wir die sogenannten “Parameter” nutzen:

Get-ComputerInfo -Property "*Processor*"

Dieser, doch schon recht ordentlich, spezifizierter Befehl zeigt uns nur eine Eigenschaft: den Prozessor:

Das ist auch der Hauptsinn der Parameter: mit einem Parameter passen wir die Cmdlets an unsere Bedürfnisse an. Die Powershell Cmdlets sind auf einen bestimmen Bereich spezialisiert. Dabei gehen sie sehr tief und/oder liefern oft eine (sehr) große Menge an Informationen. Um die Tiefe beziehungsweise die Vollständigkeit, mit der die Commandlets arbeiten, setzen wir die Parameter ein. Und davon gibt es ebenfalls einige. Die PowerShell hilft und dabei mit der Autovervollständigung.

PowerShell Cmdlets und Argumente

Wenn wir die PowerShell Hilfe aufrufen, sehen wir die Angaben zu der Syntax:

Get-Service -?

Hinter der eckigen Klammer “[-Name]”, die für Parameter steht, sehen wir den “<string[]>”. Hier können den Parameter mit weiteren Argumenten versehen. Das gibt uns wiederum die Möglichkeit das PowerShell Cmdlet noch genauer zu spezifizieren. Hierzu können wir die Argumente mit einem Komma getrennt hintereinander aufzählen:

Get-Service -Name Dhcp,dnscache

Folgendes sollte man jedoch beachten: fehlt die eckige Klammer [] hinter dem “string”, so ist nur ein Argument zulässig. Ein Beispiel hierfür wäre das Cmdlet “Get-EventLog”:

Get-EventLog -?

Unter Angabe der Parameter und Argumente lassen sich die PowerShell Cmdlets schon wesentlich einfacher aber auch effizienter handhaben. Hoffentlich diente dieser kurze Beitrag einer Übersicht über die Handhabe der Cmdlets. Weiterführende Informationen sind auf der Docs-Seite von Microsoft zu finden: https://docs.microsoft.com/de-de/powershell/scripting/developer/cmdlet/cmdlet-overview?view=powershell-7.1

Der Beitrag PowerShell – Cmdlets erschien zuerst auf Ilja Schlak InfoSec Blog.

WINDOWS SERVER ABSICHERN UND HÄRTEN – WEG MIT UNSICHEREN UND ALTEN PROTOKOLLEN UND DIENSTEN

Ein sehr wichtiger Punkt, wenn es um das Absichern und Härten von Windows Servern geht, ist das Deaktivieren unsicherer Protokolle. Das Deaktivieren alter und überholter Dienste.

SMB 1.0

Erstaunlich aber wahr! Wir reden darüber, ob und wie man die Windows Server absichert und härtet, doch es wird tatsächlich immer noch SMB 1.0 eingesetzt. Sogar Microsoft selbst versucht seit 2017 dieses völlig unsicher Protokoll zu meiden. Der großflächige WannaCry Angriff nutzte gerade diese Sicherheitslücke im Jahre 2017.

• Das Protokoll ist schlicht und ergreifend nicht effizient, die Versionen 3.ff. verfügen über viel mehr Performance-Vorteile im Vergleich zu ihrem Vorgänger, siehe Microsoft Docs
• SMB 1.0 hat schon längst EOS erreicht. Das bedeutet keine Updates mehr, keine Fixes. Das ist sicherlich ein wichtiger Grund, um SMB 1.0 nicht mehr zu benutzen.
• Keine Verschlüsselung, wie diese in älteren Protokollen gegeben ist. Auch andere Sicherheitsfeatures fehlen bei SMB 1.0.
• Keine Vorauthentifizierungsintegrität (pre-authentication integrity) und somit kein Schutz vor einem Man-in-the-Middle Angriff.

So findet man heraus, ob SMB 1.0 noch auf dem Windows Server eingesetzt wird

Serverseitig lässt sich das Protokoll mit der Powershell am bequemsten ausfindig machen (es gibt noch andere Wege, z.B. über die Registry und die GPOs):

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Ein Screenshot, an dem man die Ausgabe mit “False” gut sehen kann:

SBM 1.0 deaktivieren

Genau so lässt sich der Dienst mit der Powershell deaktivieren:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Selbstverständlich sollte man die Nutzung des Protokolls im Vorfeld auditieren. Denn falls das Protokoll noch benutzt wird und es zu einer Deaktivierung kommt, kompromittiert es die Produktivität des (Firmen)Netzes.

SMB-Protokolle mit erhöhter Sicherheit

SMB-Protokolle können digital signiert werden. Das hilft enorm beim Vorhaben unsere Windows Server abzusichern und zu härten. Die Signierung hilft das Risiko eines Man-in-the-Middle Angriffes zu minimieren. Zumal

Am einfachsten aktiviert man die Signierung über die Gruppenrichtlinienobjekte – GPO.

Im Grunde genommen gibt es hierfür vier Richtlinien:

• a: Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer),
• b: Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt),
• c: Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer),
• d: Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Serverzustimmt).

Um die Signierung einzurichten sollte man alle vier Richtlinien in Angriff nehmen. Um die Windows Server abzusichern und zu härten müsste man die Einrichtung sowohl server- als auch clientseitig vornehmen. Wenn man nur die Richtlinien mit dem Zusatz “immer” aktiviert, wird folgerichtig die Kommunikation mit den Clients, die die Pakete nicht signieren, nicht stattfinden können. Die Variante “wenn Client zulässt” würde die nicht signierte Kommunikation als eine Art “fallback” nutzen.

Auch bei diesem Schritt sollte man vorher gut überlegen, ob das Produktivnetz die Protokolle benutzt und nicht noch auf SMB 1.0 läuft. Vorherige Sicherung der Einstellungen oder Erstellung von Snapshots wären sicherlich nicht verkehrt.

SMB – Verschlüsselung

Die Kommunikation via SMB lässt sich verschlüsseln. Auch hier gibt es mehrere Möglichkeiten die Verschlüsselung zu aktiveren.

Zum einen ist es natürlich die Powershell:

Set-SmbServerConfiguration -EncryptData $true -Force

Genau so lässt sich die Verschlüsselung in der GUI aktivvieren. Klickt man mit der rechten Maustaste auf eine Freigabe, kann man die Eigenschaften von dieser aufrufen. Im Unterpunkt “Einstellungen” kann die Verschlüsselung aktiviert werden:

Ist die Verschlüsselung aktiviert?

Der schnellste Weg herauszufinden, ob die Verschlüsselung bereits aktiviert ist, bietet die Powershell.

Mit dem Befehl

Get-SmbServerConfiguration

kriegt man die SBM-Einstellungen des Servers recht übersichtlich zu sehen:

Fazit – Windows Server Absichern und härten – SMB

Das Protokoll ist wichtig und wird für den Zugriff auf die Netzwerkfreigaben eingesetzt. Es ist jedoch sehr wichtig die Nutzung des Protokolls zu auditieren. SMB 1.0 wird von Microsoft nur bei wirklich gravierenden Sicherheitsrisiken oder -lücken mit Updates versorgt. Wie lange die Updates für SMB 1.0 überhaupt noch geben wird, ist eher unklar. Die Tendenz geht in die Richtung, dass diese bald eingestellt werden.

Das Protokoll ist darüber hinaus nicht mehr fester Bestandteil des Betriebssystems. Sollte jemand noch SMB 1.0 brauchen, muss das Protokoll als Feature installiert werden.

SMB 1.0 ist ein ernst zu nehmendes Sicherheitsrisiko. Auf die Nutzung des SMB 1.0 zu verzichten, ist ein wichtiger Schritt, um die Windows Server abzusichern und zu härten.

Der Beitrag Windows Server absichern und härten – SMB erschien zuerst auf Ilja Schlak InfoSec Blog.

Viele Klein- und Mittelstandsunternehmen setzen in ihren Produktivnetzen die Windows Server Standard Edition ein. Doch seit der Einführung von Windows Server 2016 macht es durchaus Sinn sich mit anderen Versionen zu beschäftigen. In diesem Artikel geht es um den Windows Server 2019 – Editionen und Lizenzierung.

Windows Server 2019 Standard und Datacenter

Wie bereits in der Einleitung erwähnt, wird die Standard Edition üblicherweise in vielen Unternehmen eingesetzt. Einerseits ist die Standard Edition um einiges günstiger als Datacenter. Viele Firmen sind froh, wenn sich eine Möglichkeit bietet die EDV-Kosten gering zu halten. Ferner verfügt die Standard Edition über alle wichtigen Rollen und Features, um einen sicheren, performanten und nach oben skalierbaren Betrieb zu gewährleisten.

Der größte und wichtigste Unterschied zwischen der Standard und Datacenter Version ist die Anzahl der virtuellen Maschinen (VMs). Windows Server 2019 Standard lässt den Betrieb von nur zwei virtuellen Maschinen gleichzeitig zu. Windows Server 2019 Datacenter lässt hingegen eine unlimitierte Anzahl der VMs zu. 

Viele Betriebe, die Hyper-V im Einsatz haben, werden diese starke Limitierung von der Standard Version sicherlich zu spüren bekommen. 

Server Core – Nano Server – Desktopdarstellung 

Weiterhin unterscheiden sich die Server Varianten in der Darstellungsart. Wenn man Windows Server 2019 installiert, wird standardmäßig die Edition ohne GUI (ohne Desktopdarstellung (Desktop Experience)) angewählt.

Server Core

Microsofts Gedanke ist dabei, dass der Server Core viele Vorteile gegenüber der grafischen Oberfläche hat. Zum einen ist der Server Core schlanker und somit schneller. Der Server Core verbraucht ausserdem weniger Ressourcen. 

Ein weiterer und ebenfalls wichtiger Vorteil der Windows Server Core Edition ist der höhere Sicherheit. Dadurch, dass der Server Core “schlanker” ist, bietet er unter dem Strich weniger Angriffsfläche als die Desktop Edition. Die Anzahl der Bugs, die mit der grafischen Benutzeroberfläche im Zusammenhang stehen, verringert sich demzufolge ebenfalls.

Bei der Wahl der Server Edition sollte man wissen, dass der Wechsel von der Desktopdarstellung auf die Server Core Version und umgekehrt nicht ohne weiteres realisierbar ist.

Verständlicherweise erfordert die Administration des Server Core mehr Kenntnisse und vor allem sicheren Umgang mit der Kommandozeile als die Desktopdarstellung. Gute Powershell Kenntnisse sind hier nahezu unerlässlich.

Nano Server

Diese Edition des Windows Servers 2019 benötigt vergleichsweise kaum Ressourcen und benötigt sehr weniger Speicher. Der Einsatz des Nano Servers wird in Umgebungen, die mit Containertechnologien arbeiten, empfohlen. Eigentlich ist der Nano Server kaum für etwas anderes einsetzbar. Ab der Windows Server 2019 Version 1803 ist der Nano Server nur noch als Basis-Betriebssystemimage für Container zu verwenden. 

Windows Server 2019 mit LTSC oder SAC?

Erstmal zur Begriffsklärung:

LTSC steht für Long Term Services Channel und SAC steht für Semi-Annual Channel. Das sind die Servicing Channels (Wartungskanäle) für die Windows Server.  Im Grunde genommen sind es Update-Release Modelle.

LTSC – Long Term Services Channel

Beim LTSC handelt es sich vereinfacht gesagt um das Update-Modell, wie man es von “früher” kennt: man installiert eine Software oder ein Betriebssystem – zum Beispiel Windows Server 2019 Standard Edition – und bekommt in bestimmten Abständen oder nach Bedarf Updates und Fixes, Security-Patches. Wenn eine neue Version erscheint oder das “End-of-Life” erreicht wurde, geht das das Ganze von vorne los. Die Server mit der Desktopdarstellung sind immer mit dem LTSC unterwegs. Genau so kann der Server Core mit dem LTSC gewartet werden. Bei vielen Serversystemen, die für längere Zeit eingerichtet werden – und in vielen Fällen ist es der Fall – macht der LTSC auch durchaus Sinn. Denn man möchte schließlich ein stabiles System, das regelmäßig mit Sicherheitsupdates und Bug-Fixes versorgt wird.

SAC – Semi-Annual Channel

Das wohl bekannteste Bespiel für SAC ist Windows 10: die großen Updates mit neuen Features werden halbjährlich herausgebracht. Diese Variante ist für alle interessant, die hohen Wert auf Neuerungen und moderne Features legen. Hier wird das Betriebssystem mit dem vierstelligem Zusatz versehen: 2004. Die ersten zwei Ziffern sind stellen das Jahr und die letzten zwei den Monat, in dem das Update erschienen ist, dar. 

Bei Windows Server 2019 Editionen gibt es SAC nur bei Windows Core und Nano. Die Desktop Experience Editionen werden nicht mit dem SAC-Modell gewartet.

Windows Server im Semi-Annual Channel sind oft im DevOps bereich anzutreffen. Hier gilt es nämlich mit der Zeit zu gehen und neuste Features schneller oder zumindest mit der Konkurrenz auszuprobieren oder zu implementieren.

Windows Server 2019 Lizenzierung

Selbstverständlich müssen die unterschiedlichen Windows Server 2019 Editionen vernünfige und gültige Lizenzierung bekommen. Hierbei gilt es immer zu beachten, dass neben der eigentlichen Serverlizenz auch die auf den Server zugreifende Clients oder die Geräte (Devices) lizenziert werden müssen.

CAL – Client Access Licence

Diese sogenannten Clientzugrifflizenzen nennt man CALs (Client Access Licence). Für welche Variante man sich entscheidet hängt vom Netzwerkdesign, Anzahl der Geräte, Anzahl der User etc. ab. Es ist oft günstiger, wenn man Geräte-CALs im Umfeld einsetzt, in dem an einem Arbeitsplatz abwechselnd mehrere User arbeiten. 

Die CAL-Lizenzen müssen nicht ins System eingetragen werden, diese müssen lediglich vorweis- und beweisbar vorhanden sein. 

Remotedesktop-CALs

Ganz anderes ist es mit den Remotedesktop-CALs. Diese müssen im Remotedesktoplizenzierungs-Manager eingepflegt werden und werden bei Bedarf an User oder Geräte ausgestellt.

Arten der Lizenzierung/Aktivierung

Es gibt zwei grundsätzliche Möglichkeiten die Windowssysteme zu lizenzieren respektive zu aktivieren.

MAK – Multiple Activation Key

MAKs – die Multiple Aktivation Keys verwenden hauptsächlich die KMUs (kleine und mittlere Unternehmen). Sie verfügen über einen Volumenlizenzvertrag, der günstigere Konditionen hat. Der MAK wird im System eingetragen und entweder selbst oder über einen Aktivierungsproxydienst aktiviert. 

KMS – Key Management Server

Die Volumenkeys kann man auch mit dem KMS (Key Management Server) aktivieren beziehungsweise verwalten. Hierfür installiert man die Serverrolle “Volumenaktivierungsdienste”.

Der Beitrag Windows Server 2019 – Editionen und Lizenzierung erschien zuerst auf Ilja Schlak InfoSec Blog.