PAW – Priviledged Admin Workstation

Diese Seite beschreibt die Überlegungen zur sicheren Administration über eine eigens dafür bereitgestellte Workstation, um die Angriffsmöglichkeiten auf die besonders schützenswerte privilegierte Konten von Administratoren u.ä. zu minimieren.

Früher war es einfacher

Als ich noch Administrator war, habe ich mich am PC und in der Domain mit einem Benutzer angemeldet, der zugleich auch Administrator war. So konnte ich den ganzen Tag meiner Hauptbeschäftigung, der Administration, nachgehen. Heute wäre so ein Vorgehen unverantwortlich, denn ohne Recherche im Internet, Kommunikation per Mail oder Chat, Downloads von Updates ist die Arbeit schwer vorstellbar.

Risiken

Diese Verbindungen setzen den Administrator aber auch einem Risiko aus, welches Sie sowohl technisch als auch organisatorisch reduzieren wollen. Denken Sie einfach einmal über die aktuelle Sicherheit des Clients nach, auf dem Sie jetzt gerade administrieren:

  • Sind sie sicher, dass alle Programme auf dem System „sauber“ sind?
    Ihr Windows Betriebssystem mag ja aktuell gepatched sein aber wie ist es mit Programmen, die sie für die Arbeit gerne nutzen und sogar kostenfrei sind. Ich denke da an z.B. 7-ZIP, MRemote u.a. Ich bin sehr sicher, dass Sie die Programme nicht selbst kompilieren oder einer Prüfung unterziehen und selbst dann wäre es vermessen zu behaupten, man könnte das. Solche Open Source Projekte sind aber natürlich beliebtes Ziel, um Schadcode einzuschmuggeln und wenn nicht direkt, dann über die Libraries, die von diesen prominenten Programmen genutzt werden.
  • PowerShell-Module
    Viele Funktionen lassen sich nur per PowerShell verwalten. Die Exchange On-Premises Module installieren Sie in der Regel aus den Installationsquellen. Viele andere Module werden aber mittels „Install-Module“ direkt z.B. aus PSGallery installiert. Den wenigsten Administratoren ist bewusst, dass hier quasi jeder Entwickler eigene Module veröffentlichen kann.
  • Andere Repositorien
    Die Welt der Administration ist aber vielfältig und es gibt noch viel mehr „Paketmanager“ wie Winget, NPM, PIP etc., die alle aus verschiedenen Repositorien Programme mehr oder minder ungeprüft auf einem Client installieren und vom Administrator genutzt werden.
  • Browser/Cookies
    Natürlich „surfen“ sie als Administrator auch im Internet und nicht immer sind sie dabei auf vertrauenswürdigen Seiten und leider sind die meisten Seiten mit aktivierten Schilden (JavaScript off, 3rd Party Cookies:Off, etc.) kaum nutzbar. Aber JavaScript kann durchaus mehr als nur Formulareingaben verifizieren. Wenn Sie dann im gleichen Browser auch eine Webseite als Admin nutzen, können die Zugangsdaten wohl einfach abgefischt und ausgeleitet oder gleich missbraucht werden. Das gilt übrigens auch für Browser-AddOns wie Popup-Blocker, Kennwort-Speicher etc., die in der Regel vollen Zugriff auf die geladenen Webseiten haben und diese sogar ändern können. Siehe dazu auch Session Cookie Security
  • Speicherzugriff
    Lokale Dienste, die nur lokal entsprechende Rechte haben, können einen DUMP eines Prozesses eines anderen Benutzers ablegen und da drin nach Kerberos-Tickets, Kennworten o.ä. suchen. Das stellt das Konzept von "Terminal Servern für Admins" auf einen Probe.

Das sind nur einige Punkte und dabei kann es einem schon sehr unangenehm werden, mit dem Wissen auf dem regulären PC noch privilegierte Berechtigungen zu nutzen.

Admin-Client

Wenn ich nun auf meinen regulären Arbeitsplatz nicht mehr administrieren soll, dann brauche ich einen anderen Client, der nur für die Aufgabe genutzt wird. Hierzu gibt es nicht nur eine Option und jede hat ihre individuellen Vor- und Nachteile:

  • lokaler PC mit "run as Admin"
    Davon sollten wir uns langsam verabschieden. Es mag ein legitimer Weg sein, wenn ich auf meinem lokalen PC auch mal lokaler Admin sein muss, um z.B. etwas zu installieren oder analysieren. Aber dann wird mein Domain Benutzer mittels "User Account Control" halt mal Administrator auf diesem einen PC aber nicht gleich im Netzwerk.
  • Lokale VM
    Eine Zeit lang habe ich wirklich auf meinem PC mehrere virtuelle Systeme mit VMWare, VirtualPC, HyperV oder VirtualBox betrieben. Zum einen waren das dann Windows und Linux-Systeme zum Testen aber eben auch um Admintools zu nutzen, die ich nicht in meiner regulären Umgebung installieren wollte. Es ist ein Weg aber der PC muss natürlich entsprechend leistungsfähig sein und jeder Admin muss "seine" VMs auch immer aktuell halten
  • Admin Terminal Server
    Viele meiner Kunden haben in der Vergangenheit einen Terminal Server für die Administration bereitgestellt. Die Administratoren haben sich dann per RDP in der Firma oder auch über VPN angemeldet und konnten so "nahe" am Server arbeiten. Abbrechende VPN-Verbindungen oder langsame WAN-Verbindungen verlieren so ihren Schrecken und es lassen sich sogar langlaufende Jobs gut nutzen, wenn der Disconnect-Timeout lang genug ist. Oft wurde so ein Server auch gleich al "Job/Cron-Server" missbraucht, auf dem regelmäßige Aufträge gleich mit ausgeführt werden.
    Kritisch wird es aber spätestens, wenn die Administratoren auch auf dem Terminal Server zum Admin werden können, denn dann können Sie relativ einfach die Sitzung eines "Mit-Admins" kapern oder aus dem Benutzerprofil des anderen Administrators interessante Dateien, z.B. Browser Cache, auslesen. Natürlich ist das verboten aber würden Sie es auch bemerken?
  • Server-VM
    Anstatt sich mit mehreren Administratoren einen Terminal Server zu teilen, können sie natürlich auch für jeden Administrator eine eigene Windows-VM auf einem HyperV/VMWare-Server bei bedarf starten. Das könnte sogar eine immer neue VM aus einem Image sein, so dass der Administrator immer eine frische aktuelle VM nutzt, die beim Abmelden auch wieder zerstört wird. Natürlich muss das Master-Image dann entsprechend "clean" und aktuell sein und die Administratoren müssen wissen, dass nach dem Ende der Sitzung alle Daten wieder weg sind, wenn sie diese nicht woanders ablegen.
  • Windows 365 / Cloud VM
    In der Cloud gibt es natürlich vergleichbare Lösungen, mit denen eigentlich Anwender mit ThinClients ein Windows aus der Cloud bekommen. Aber was sollte Sie daran hindern, diese Technik auch für Admin-Workstations zu nutzen?
  • Administration auf dem Server
    Warum eine eigene VM oder Admin-Workstation nutzen, wenn Sie per RDP auch direkt auf dem Server arbeiten können? Es klingt verlockend und mag für kleinere Firmen oder Sonderfälle sogar der einzige Weg sein, wenn z.B. eine Software keine Remote-Verwaltung kennt. Dennoch kann dann natürlich eine Malware komplett die Netzwerkfirewall etc. umgehen.
  • Kein VM - Provisioning - Automatisierung
    Der radikalste Ansatz ist es natürlich, dass sie gar nicht mehr als Administrator mit privilegierten Berechtigungen arbeiten, sondern für alle regelmäßigen Aufgaben eine Automatisierung oder Provisionierung bereitstellen. Dann hat ein Dienstkonto, dessen Zugangsdaten niemand alleine kennt, die Berechtigungen und führt im Auftrage des Administrators die Aktionen aus. Exchange RBAC ist eine einfache Variante, damit Administratoren z.B. über den Exchange Server Aktionen an Empfängern vornehmen, die sie per direkten LDAP-Zugriff nicht nutzen können. Allerdings ist so eine Lösung aufwändig und muss kontinuierlich nachgepflegt werden. Entsprechend muss der "Provisioning-Admin" geschützt werden.

Ich bin gar nicht nicht sicher, ob ich nun alle verschiedenen Varianten damit aufgezählt habe. Eine Bewertung überlasse ich ihnen.

Bei einer Krankenkasse hatte jeder Administrator sogar drei physikalische Computer für die Arbeit als "Benutzer", die Arbeit als "Admin" und zum Surfen im Internet. Downloads mussten vom Internet-PC dann auf einen USB-Stick kopiert werden, der dann in eine "Scanstation" eingesteckt werden musste. So wurde mit mehreren Scannern auf Schadsoftware geprüft und zum protokolliert, welcher Mitarbeiter, welche Datei ins interne Netzwerk gebracht hat. Bei einer Firma mit auch militärischen Produkten hatten die Mitarbeiter dann einen PC im "roten" und einen zweiten PC im "blauen" Netzwerk. Die Trennung von Computern beschränkt sich also nicht nur auf Administratoren.

Client härten

Unabhängig von der Ausprägung sollten Sie die genutzt Windows-Instanz und das Benutzerprofil zusätzlich sichern. Es gibt hier einige Ansatzpunkte, von denen ich aber nur einige aufzähle.

  • Windows Updates/Produkt-Updates
    Es versteht sich von selbst, dass bekannte und vom Hersteller gefixte Lücken und Probleme umgehend installiert werden sollten.
  • Antivirus mit Verhaltenskontrolle
    Auch wenn Virenscanner meist nicht die aktuellste Schadsoftware oder individuelle Malware erkennt, so sollten Sie dennoch nicht darauf verzichten.
  • Desktop Firewall/Netzwerkfirewall
    Es versteht sich von selbst, dass so eine Admin-Workstation im Netzwerk keine oder nur absolut notwendige Dienste anbieten sollte. Ich denke nicht, dass eine Admin-Workstation z.B. per SMB oder HTTP erreichbar sein sollte. Prüfen Sie einmal die offenen Ports und ob sie diese Systeme vielleicht in ein eigenes Subnetz verschieben und die Verbindungen beschränken. Vielleicht bauen Sie sogar auf IPSEC-Verbindungen, so dass sich die Teilnehmer beim Zugriff auf als Computer vorab authentifizieren müssen.
  • AppLocker
    Wenn Sie die Arbeitsmittel des Administrators gut kennen und benennen können, dann kann eine AppLocker-Richtline das Schlimmste verhindern und vor allem eine "mal eben"-Installation eines Tools unterbinden.
  • Code Signing
    Das gleiche gilt für Skripte und Programme. Sie sollten alle vom Hersteller oder notfalls ihrer eigenen PKI signiert sein, damit Sie jegliche Ausführung von unsignierten Code unterbinden können
  • Kerberos Tickets, Kein NTLM, keine Kerberos Delegation/Impersonation
    Über die Mitgliedschaft der Admin-Konten in der "Protected User"-Gruppe können sie ihre Admin-Konten schon besser sichern, weil z.B.: NTLM unterbunden wird
  • Verschlüsselung und Signierung
    Kennworte, Cookies und andere Daten sollten nie unverschlüsselt übertragen werden. HTTPS und Co sollten zwingend sein und natürlich auch mit entsprechend starken Cipher-Suiten und Hashverfahren.
  • Datensparsamkeit
    Prüfen Sie, welche Informationen in ihrer Sitzung vorgehalten und eventuell in Dateien abgespeichert werden. Vielleicht könnten Sie die Gültigkeit von OAUTH-Tokens verkürzen oder an die IP-Adresse des Clients binden. Es kann sinnvoll sein, beim Beenden des Browsers alle gespeicherten Cookies und Caches zu leeren oder sie nutzen gleich den Gast-Mode zu nutzen.
  • Profil/VM komplett löschen
    Die nächste Steigerung ist natürlich das Löschen des Windows Profil beim Abmelden oder ein Rollback oder Löschen der VM, damit Sie bei der nächsten Anmeldung immer wieder neu starten und vor allem niemand ihre Zugangsdaten abgreifen könnte

Letztlich hängt es von ihrer Sicherheitsbetrachtung und Risikoeinschätzung ab, wie umfangreich sie die PAW absichern wollen.

Level 0/1/2 oder PIM

Genaugenommen muss ich nun sogar noch die verschiedenen Berechtigungen unterscheiden. Wer das Tier-0/1/2-Modell verfolgt, hat nur nur einen Administrator sondern gleich mehrere Konten. Oder sie nutzen die Möglichkeiten einer dynamischen Berechtigung wie Sie Privileged Identity Management (PIM) z.B. in Azure erlaubt.

Ich selbst haben habe nämlich mehr als mein reguläres Domainkonto und einem Admin-Konto. Genau genommen habe ich sogar noch Admin-Konten bei Kunden und in meinen unterschiedlichen Tenants. Spätestens da wird es dann unhandlich, für jeden Admin eine eigene VM zu starten. Zum Glück sind die meisten Tenants ehr nur Spiel-/Lab-/Test-Tenants und hier behelfe ich mich mit mehreren Browser-Profilen.

Aber wenn ich bei Kunden als Admin arbeite, dann orientiere ich mich natürlich an den Vorgaben des Kunden, wie die Verwaltung erfolgen soll. Vor Ort nutze ich in der Regel einen Arbeitsplatz des Auftragsgebers. Da ich aber keine Kontrolle über diese Gerät habe, werde ich auf diesem System natürlich keine fremde Zugangsdaten verwenden. Dann starte ich lieber zusätzlich meinen Notebook, über den ich hoffentlich immer selbst bestimme, um mich an Test-Tenants anzumelden.

Seit COVID19 hat der Anteil der "Remote Arbeit" natürlich extrem zugenommen. Die meisten Einsätze erfolgen als Teams Meeting, bei dem der Kunde seinen Desktop freigibt oder ich über Programme wie TeamViewer unterstütze. In allen Fällen, insbesondere bei Kunden mit einem Cyber-Vorfall, muss ich natürlich darauf achten, dass ich mich auch selbst schütze und nicht während einer Fernwartung selbst geschädigt werde. Auch das kann ein Grund sein, dass Dienstleister z.B. eigene "Fernwartungs-Systeme" nutzen oder vom Kunden gestellt bekommen.

Keine Empfehlung

Natürlich müssen auch reguläre Benutzerkonten ausreichend geschützt sein, denn auch ihre Mitarbeiter arbeiten mit Daten, bei denen ungewünschte Veränderungen schnell ins Geld gehen können. Damit meine ich nicht nur die Prokuristen die Geld an eine falsche Kontoverbindung überweisen sondern auch Sachbearbeiter, Personalwesen, Konstrukteure u.a. deren Arbeit ein hohes Schadenspotential hat. Aber administrative Konten müssen noch einmal besonders geschützt werden, denn sie könnten sich all die Rechte einräumen oder Konten übernehmen. Daher sollten sie sich überlegen, ob ihre Administratoren aktuell gut genug geschützt sein oder sie weitere Hürden für Angreifer aufbauen müssen.

2FA alleine ist ein Schutz gegen eine Übernamen mit einem irgendwie erlangten Kennwort aber wenn der Angreifer nach der Anmeldung auch noch involviert ist, dann kann er mit den Kerberos-Tickets, OAUTH-Tokens und Cookies einen großen Schaden anrichten.

Allerdings kann es keine allgemeingültige Empfehlung geben, wie umfangreich ihr PAW-Deployment aussehen muss. Dazu müssen Sie sich ihre aktuelle Berechtigungsstrukturen anschauen, den Schutzbedarf ermitteln und die richtigen Schlüsse daraus ziehen. So sicher wie nötig aber auch möglich. Es wird immer auf einen Kompromiss hinauslaufen.

Unterstützung durch Net at Work:
Wenn Sie Unterstützung wünschen, können meine Security-Kollegen ihnen sicher helfen. https://www.netatwork.de/microsoft-365-security/, https://www.netatwork.de/security-workshop/

Weitere Links