IT Security Empfehlungen für Administrator_innen

Allgemeines

Die Absicherung der Client Infrastruktur stellt IT Abteilungen weltweit vor große Herausforderungen. Immer wieder werden Unternehmen auf Grund fehlender Sicherheitsvorkehrungen kompromittiert. Oft hätten aber einfache Konfigurationsänderungen diese initialen Einfallstore verhindern können.

In diesem Dokument werden einige der wichtigsten Absicherungsmaßnahmen – zugeschnitten auf die Infrastruktur der TU Wien – dokumentiert.

Als Grundlage dieser Maßnahmen dient das Dokument „IT Security Empfehlungen für Anwender_innen“

1. Passwort Policy

Passwörter sichern unsere digitalen Identitäten ab. Ohne eine entsprechende technische Passwort Policy nutzen Endanwender_innen aber oft unsichere Kombinationen. Beispielsweise können so qualitativ schlechte, sowie sehr kurze Passwörter (z.B.: 12345) vergeben werden. Diese sind ausserdem nicht vor Bruteforce Angriffen geschützt. Daher  wird (auch basierend auf dem NIST Digital Identity Guidelines[1] und der aktuell gültigen Richtlinie zu Datenschutz und Informationssicherheit[2]) empfohlen, eine Mindestpasswortlänge von 8 Zeichen, sowie ein Account Lockout (z.B.: 3 Versuche; dann 10 Minuten Sperre) zu implementieren.

Gibt es in der Infrastruktur ein zentrales Active Directory, können die dazu notwendigen Änderungen dort umgesetzt werden. Anleitungen dazu finden Sie unter:

• Password Policy: https://activedirectorypro.com/how-to-configure-a-domain-password-policy/
• https://ldapwiki.com/wiki/Active%20Directory%20Account%20Lockout

Falls es kein Active Directory gibt, wird empfohlen die entsprechenden Einstellungen im Standardimage vorzunehmen, so dass zumindest künftige Endgeräte entsprechend abgesichert werden. Die Konfiguration bezieht sich in diesem Fall auch auf lokale Benutzer_innenkonten. Im folgenden Microsoft Dokument wird beschrieben, wie lokal Gruppenrichtlinien umgesetzt werden können:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn789197(v=ws.11)

Vorteil: Die Passwörter der Endbenutzer_innen müssen den Mindest-Qualitätsanforderungen entsprechen und sind vor Bruteforce Angriffen geschützt.

2. PowerShell Sicherheit

Das Programm „PowerShell“ ist ein mächtiges Werkzeug in Windows-Umgebungen und dafür gedacht Administrator_innen die tägliche Arbeit zu erleichtern. „PowerShell“ ist aber auch das Tool der Wahl für Angreifer_innen. Daher sollte es, soweit möglich, abgesichert werden.

2.1 Powersehell V2 deaktivieren

Besonders die veraltete Version 2.0 ist bei Angreifer_innen sehr beliebt, da diese relativ wenige Sicherheitsoptionen beinhaltet, weshalb empfohlen wird, diese zu deinstallieren. Im normalen Betrieb sollte dies in der Regel keine Auswirkungen mit sich bringen, da  Skripte in der Regel auch mit neueren PowerShell Versionen ausgeführt werden können.

Das folgende Kommando erlaubt die Deinstallation der veralteten Version ohne Neustart:

Gibt es in der Infrastruktur ein zentrales Active Directory, kann ein Scheduled Task verwendet werden, um das obige Kommando (als SYSTEM) auf allen Clients und Servern auszuführen: https://www.windowspro.de/wolfgang-sommergut/geplante-aufgaben-ueber-gruppenrichtlinien-anlegen-loeschen

Falls es kein zentrales Active Directory gibt, wird empfohlen PowerShell Version 2 im Standardimage (mit dem hier dokumentierten Befehl) zu deaktivieren.

Vorteil: Wird Powershell v2 deaktiviert, können Angreifer_innen diese Version nicht mehr nutzen, wodurch viele Attacken ins Leere laufen.

2.2 Powershell Constrained Language Mode

Nachdem, wie im vorherigen Kapitel beschrieben, Powershell Version 2.0 deaktiviert wurde, kann der Constrained Language Mode[3] eingeführt werden. Über diesen ist es Angreifer_innen nicht mehr möglich Powershell zu verwenden.

Zur Umsetzung wird die Verwendung von AppLocker empfohlen. Das folgende Tutorial auf TenForums zeigt eine entsprechende Umsetzung über das Active Directory (für Windows 10 Enterprise bzw. Education). Diese kann aber auch in ein Standardimage implementiert werden. https://www.tenforums.com/tutorials/124016-use-applocker-allow-block-script-files-windows-10-a.html

Der Vorteil dieser Lösung liegt vor allem darin, dass die eigenen Skripte explizit von dieser Einschränkung ausgenommen werden können.

^{Abb. 1: Local Security Policy}

Als Alternative dazu kann in Ausnahmefällen die Umgebungsvariable __PSLockDownPolicy gesetzt werden. Siehe dazu https://itfordummies.net/2015/06/01/powershell-constrained-mode/. Alle Skripte die den vollen Powershell Funktionsumfang benötigen, können mittels Remove-Item Env:_PSLockdownPolicy diesen explizit anfordern.

Vorteil: Durch die Nutzung des Constrained Language Mode, wird der Missbrauch von Powershell erheblich erschwert.

3. MakroSicherheit

Office Makros sind ein häufig verwendetes Einfallstor für die initiale Infektion. Mit Office 2016 wurde durch Microsoft eine neue Gruppenrichtlinie mit dem Namen „Block macros from running in Office files from the Internet[4]“ veröffentlicht, die zusätzliche Absicherungsmaßnahmen ermöglicht. Wird diese aktiviert, können grundsätzlich keine Makros mehr in Dokumenten aus dem Internet (heruntergeladen oder per Mail) ausgeführt werden.

^{Abb. 2: Makrosicherheit}

Der_die Benutzer_in hat dennoch die Option, wichtige Dokumente selbst und damit sofort freizuschalten. Intern gespeicherte Dateien mit Makros (z.B.: auf Fileservern) sind von dieser Einstellung unberührt und funktionieren wie bisher (sofern der interne Fileserver als „Intranet“ eingestuft wird[5]).

Endanwender_innen können über die Funktion „Dateieigenschaften“ das „Mark-of-the-Web“ entfernen und so der Makroausführung explizit zustimmen.

^{Abb. 3: Ansicht Dateieigenschaften}

Der folgende Link beschreibt wie die Einstellung über ein Active Directory ausgerollt werden kann: https://www.microsoft.com/security/blog/2016/03/22/new-feature-in-office-2016-can-block-macros-and-help-prevent-infection/

Ist kein Active Directory vorhanden, wird empfohlen gemeinsam mit dem_der Benutzer_in zu besprechen, ob diese_r die Möglichkeit zur Makroausführung benötigt. Wenn nicht, ist diese – wie im Dokument „IT Security Empfehlungen für Anwender_innen“ beschrieben – zu deaktivieren.

4. Gefährliche Dateitypen

Unter Windows können gewisse Skriptdateien direkt mit einem einfachen Doppelklick ausgeführt werden. Diese Standardkonfiguration wird durch eine Vielzahl von Schadsoftware missbraucht. Aktuell setzen vor allem Cryptolocker auf diese Technik. Daher wird empfohlen, die Windows Dateizuordnung so anzupassen, dass statt der Ausführung der Skriptdatei, diese beispielsweise in Notepad geöffnet wird.

Kritische Dateitypen: .hta, .vbs, .js, .jse, .vbe, .reg

Ist ein Active Directory vorhanden, kann die folgende Anleitung verwendet werden, um die Konfiguration für alle Endnutzer_innen automatisch auszurollen.: 

https://community.webroot.com/general-140/disable-execution-of-script-files-303074

Falls kein AD vorhanden ist, kann die Einstellung bereits im Standardimage mit dem kostenlosen Tool FileTypesMan (https://www.nirsoft.net/utils/file_types_manager.html) umgesetzt werden.

^{Abb. 4: Ansicht FileTypesMan}

Vorteil: Die Konfiguration erschwert dem_der Angreifer_in das Ausführen von gefährlichem Code.

5. Festplattenverschlüsselung

Viele wichtige Unternehmensdaten befinden sich nicht nur auf zentralen Fileshares sondern auch auf den Geräten von Endanwender_innen. Da derzeit noch nicht alle PCs eine Festplattenverschlüsselung  einsetzen, können diese Daten im Fall eines Gerätediebstahls sehr leicht ausgelesen werden. Dazu reicht es, die jeweilige Festplatte auszubauen und an ein anderes Gerät anzuschließen.

Um diesen Angriff zu verhindern, wird empfohlen eine Festplattenverschlüsselung mit TPM Unterstützung, für alle Endgeräte einzuführen. Sowohl Windows (Microsoft Bitlocker) als auch die meisten Virenscanner bieten einfache Möglichkeiten, um Geräte einfach und transparent verschlüsseln zu können.

Besteht ein Active Directory, kann das Deployment vollständig automatisiert werden: https://www.der-windows-papst.de/wp-content/uploads/2017/11/Windows-Bitlocker-einsetzen.pdf

Wird kein AD eingesetzt, muss über den Deploymentprozess neuer Endgeräte die BitLocker Konfiguration sichergestellt werden. Dies ist auch aus Sicht des Datenschutz als essenziell einzustufen.

Vorteil: Geht ein Rechner verloren oder wird er gestohlen kann nicht unautorisiert auf wichtige Daten zugegriffen werden.

6. Bildschirmsperre

Verlässt ein_e Mitarbeiter_in ihren_seinen Arbeitsplatz, sollte sich der jeweilige PC nach einer gewissen Inaktivitätsperiode automatisch sperren. Es wird empfohlen das Limit auf 5 – 10 Minuten zu setzen.

Für alle Active Directory Umgebungen kann die Einstellung über die Gruppenrichtlinie „Interactive logon: Machine inactivity limit“ relativ einfach und schnell ausgerollt werden. Siehe dazu: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit

^{Abb. 5: Local Security Policy}

In Stand-Alone Infrastrukturen sollte die Konfiguration im Standardimage (ebenfalls über die obige Policy) integriert werden.

Vorteil: Geräte laufen nicht (teilweise stundenlang) ungesperrt. Dies verhindert unautorisierte Zugriffe auf die darauf gespeicherten Daten.

7. Lokale Administrator_innen

Moderne Schadsoftware, wie beispielsweise Trickbot, kann gleiche administrative Zugangsdaten von lokalen Benutzer_innen mit sogenannten „Pass the Hash“ – Angriffen für die Verbreitung im Netzwerk missbrauchen. Kann die Schadsoftware auf einem Rechner den Hash des Administrator_innenpassworts auslesen und setzen alle bzw. viele Rechner das gleiche Kennwort ein, ist eine infrastrukturweite Ausbreitung sehr wahrscheinlich. Daher ist es entscheidend, auf allen Endgeräten unterschiedliche Passwörter für die lokalen Admin-Benutzer_innen einzusetzen.

In Active Directory Umgebungen kann dazu Microsoft LAPS eingesetzt werden. Mit diesem kostenlosen aber von Microsoft unterstütztem Tool werden in weiterer Folge die Passwörter des lokalen Administrationskontos randomisiert. LAPS sollte sowohl auf Clients als auch auf Servern installiert werden. Eine entsprechende Implementierung ist in ca. 1 – 4 Stunden umsetzbar. Im Hintergrund wird dazu eine Client Side Group Policy Extension auf allen Geräten (per z.B. GPO) installiert. Anschließend generieren die Rechner automatisch in gewissen Abständen ein neues Administrator_innenpasswort und speichern dieses im AD Computerobjekt ab. Entsprechend berechtigte Admins können dieses bei Bedarf auslesen.

Für alle nicht zentral verwalteten Geräte könnte beispielsweise im Zuge des Deployments ein zufälliges Passwort generiert (net user Administrator /random) und an einem sicheren Ort (z.B.: abgeschirmter Fileshare) abgelegt werden.

Vorteil: Wird ein System kompromittiert, ist über den_die lokale_n Administrator_in keine Weiterverbreitung mehr möglich.

[1] https://pages.nist.gov/800-63-3/sp800-63b.html (zuletzt abgerufen am 27.09.2020).

[2]https://www.tuwien.at/index.php?eID=dms&s=4&path=Richtlinien%20und%20Verordnungen/Datenschutz%20und%20Informationssicherheit.pdf (zuletzt abgerufen am 27.09.2020).

[3] Siehe dazu: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/ (zuletzt abgerufen am 27.09.2020).

[4] Siehe dazu: https://www.microsoft.com/security/blog/2016/03/22/new-feature-in-office-2016-can-block-macros-and-help-prevent-infection/ (zuletzt abgerufen am 27.09.2020)

[5] Siehe dazu: https://blog.thesysadmins.co.uk/group-policy-internet-explorer-security-zones.html (zuletzt abgerufen am 27.09.2020).