30. August 2020, 15:30

Homeoffice Arbeitsplätze - Teil II

Terminalserver - Ein Blick zurück

Der zweite Teil der Homeffice-Serie dreht sich um Terminalserver. Dabei ist das Konzept alt, sehr alt. Wir kommen um einen kurzen Ausflug in die Vergangenheit nicht herum:

Es geht zurück zu den Anfängen der Computergeschichte Ende in die 40er und 50er Jahre des letzten Jahrhunderts. Rechnerzeit auf den damaligen VN-Großrechnern1 war als Ressource knapp, teuer und oft geheim. Ohne zu sehr ins Detail gehen zu wollen, empfehle ich das Buch von Kai Schlieter “Die Herrschaftsformel”2, der die Entwicklungsstränge von Computertechnologie, Wehrtechnik, Kybernetik und Public-Relations aufzeigt.

Für uns wichtig ist die Erkenntnis der 50er Jahre, dass nur Multi-User und Multitasking-Systeme wirtschaftlich sinnvoll zu betreiben waren. Mehrere Programme wurden auf einem zentralen Großrechner in kurzen Zeitfenstern nacheinander ausgeführt damit mehrere Anwender mit Ihren Anwendungen an jeweils Ihren Ein- und Ausgabegeräten, einem Terminal, arbeiten konnten. Dieses “time-sharing” Prinzip3 bildet die Grundlage eines jeden modernen Betriebssystems.

Doch mit dem Mikrochip ab 19714, spätestens mit der explosionsartigen Verbreitung der Home- und Personal-Computer in den 70er und Anfang der 80er Jahre verlagerte sich das Paradigma auf die Single-User-Mode5 Computer. Betriebssysteme wie CP/M ab 19746 oder dessen dreist kopierter Klon MSDOS ab 19817 sind die bekannteren Vertreter dieser Entwicklung. Mein erster PC aus dem Jahr 1988, ein Schneider EURO-PC mit MSDOS 3.3 entspringt aus genau dieser Zeit.

Mein erster PC mit MSDOS 3.3 und GW-BASIC

Es waren diese günstigen Single-User-Mode Geräte, die zusammen mit grafischen Oberflächen Einzug in Mainstream und Unternehmen fanden. Und wie in den 50er Jahren wusste jeder: Nur mit geteilten Multi-Usern und vor allem Multitasking Systemen funktioniert auch ein ernsthaftes und wirtschaftliches Arbeiten. Es ist ein Fakt, dass ein Rechner die meiste Zeit seines Daseins im idle8 verbringt.

Aus diesem Grund begann ab 1984 in der Unix-Welt die Entwicklung des X Window-Systems9, einer Abstraktionsschicht zum Übermitteln von grafischen Bildschirminhalten und Steuerbefehlen an lokale und entfernte Terminals. Anders als bei den Großrechnern, kann dieses auch über ein Netzwerk erfolgen. Ein kleines Start-Up mit dem Namen Citrus kopierte und optimierte ab 1989 dieses Prinzip auf MSDOS basierte Systeme. Die Independent Computing Architecture, das ICA-Protokoll10 war geboren. Kurze Zeit später erfolgte die Umbenennung des Unternehmens in den heutigen Markennamen Citrix11. Microsoft lizenzierte diese Technologie rasch, integrierte es als Terminal Services12 in seiner Windows NT Produktfamilie und nannte es seinerseits Remote-Desktop-Protokoll13.

Eine Frage der Perspektive

Citrix und Microsoft teilen sich den Markt der Windows-basierten Terminalserver auf. Lange Zeit galt Citrix als das schlankere und performantere Protokoll und profitierte von seiner Stellung als Technologievorreiter. Der “seamless” Fenstermodus und die nahtlose Integration mit lokalen Apps war ein Killer-Feature. Spätestens mit der 2016er Servergeneration hat Microsoft aber gleichgezogen.

Citrix hat auch früher als Microsoft einen Technologievorsprung im Bereich der Virtualisierung geschaffen. Auch hier hat Microsoft meiner Meinung nach gleichgezogen. Doch ist die Frage der Virtualisierung ein anderes Thema, das sich hier nicht stellt.

Ich vermag nicht zu sagen, welche Seite besser ist. Es ist eine Frage der Perspektive und woher jemand mit seinem Netzwerk kommt. Solche A/B Fragen werden ohnehin oft evidenzfrei wie Glaubensfragen entschieden und gehen selten auf spezifische Ausgangsprobleme ein. So gibt es neben Microsoft und Citrix auch Thinstuff14. Meine persönliche Präferenz, wenn es “mal eben” gilt ältere Fachanwendungen auf teilweise noch älteren Serversystemen netzseitig zu segmentieren und als Terminalserver erreichbar zu machen.

Die bessere Fragestellung sollte sein: Was genau soll ein Terminalserver bringen? Immer wenn ich vollständige Desktops in Terminals mit allen Anwendungen, Webbrowser und Email-Anwendung sehe, frage ich mich, welche Gedankengänge hinsichtlich Informationssicherheit wohl dahinter stecken. Und dann werden diese Systeme in aller Regel für jeden aus dem Internet erreichbar gemacht, ohne Portknocking15, GeoIP-Blocking16 oder IDS/IPS Systemen mit Snort-Regeln17 davor.

Citrix hatte unlängst mit einer ungepatchten Sicherheitslücke zu kämpfen gehabt, die auf einen Schlag alle aus dem Internet erreichbaren Systeme verwundbar machte. Sogar das BSI musste warnen18, da über 5000 Unternehmen alleine in Deutschland davon betroffen waren. Eine Recherche mit diesem netten Skript19 offenbarte mir ein halbes Jahr später im Juli 2020 noch dutzende, ungepatchte Systeme in Shodan20.

Die Sicherheitslage bei Microsoft ist nicht besser. Es war und ist weiterhin das bevorzugte Einfallstor für Hacker21. Bei Entdeckung der “Bluekeep” Schwachstelle letztes Jahr, einem fundamentalen Designfehler bei der Implementierung, sah sich Microsoft sogar genötigt die längst nicht mehr unterstützten Windows-Versionen XP und 2003 Server zu patchen22. Doch auch ohne Bluekeep gehörten FBI-Warnungen beinahe zum wiederkehrenden Ritual23.

Es bleibt festzuhalten:

  • Ohne zusätzliche Schutzmechanismen stellen aus dem Internet zugängliche Terminalserver ein erhebliches Risiko dar.
  • Sowohl Citrix als auch Microsoft Terminalserver sind proprietäre Blackboxen. Evidenzbasierte Aussagen zur Sicherheit können nicht getroffen werden. Beide operieren nach dem Prinzip “Security by obscurity”24.

Lösungswege

Wenn Technologien oder Systeme inhärente Sicherheitsrisiken haben stellt sich die Frage, welche risikomindernde Maßnahmen helfen, diese auf ein akzeptabeles Risiko zu bringen. Diese Liste stellt nur einen Ausschnitt an Möglichkeiten dar:

  • Mehr-Faktor-Authentifizierungen z.B. TOTP
  • Managed SSO25 mit Einbruchserkennungen und Heuristiken
  • Isolierung durch z.B. Verzicht auf eine AD-Integration
  • Nutzung von IDS/IPS Systemen
  • Beschränkung auf feste IPs z.B. mit VPNs
  • Nutzung von kontrollierten Übergangspunkten (Gateways oder Proxies)
  • Anwendungsinterne Sicherheitsfunktionen und Berechtigungskonzepte

Terminalserver - Ein Blick nach vorne

Ein entfernter Homeoffice-Arbeitsplatz kann über das Internet auf zwei Arten Verbindung mit einem Terminalserver aufnehmen:

  • mit einer proprietärem Client-Software
  • im handelsüblichen Webbrowser

Das eindeutig flexiblere Konzept ist eine Webbrowser-Integration mit gängigen Internettechnologien. So werden auch nicht von einer eigenen IT verwaltete Fremdsysteme in die Lage versetzt auf Ressourcen zugreifen zu können. Wer seine Infrastruktur in den letzten Jahren herstellerunabhängig auf das Bring-your-own-Device Prinzip26 vorbereitet hat, verfügt heute über eine bessere Ausgangslage bei der Integration von Homeoffice-Arbeitsplätzen.

Als besonders traurig erachte ich den Umstand, dass im Jahr 2020 von vielen Unternehmen und Ihren Personalabteilungen es noch immer nicht verstanden wird, dass Fragen nach Homeoffice, Arbeitsumgebung und Betriebssystem harte Einstellungskriterien für qualifiziertes Personal darstellen. Schließlich kommt ja auch niemand auf die Idee Baggerfahrer einzustellen nur um diesen zum Ausheben einer Grube Schaufeln in die Hand zu drücken.

Jeder sollte in genau der Systemumgebung arbeiten, mit der er am besten vertraut ist und seine Arbeit effektiv erledigen kann.

Für mich sind Terminalserver mit freien HTTPS-Gateways unverzichtbarer Bestandteil einer zukunftsfähigen Entwicklung.

Apache Guacamole

Zugegeben, Guacamole27 ist ein Zungenbrecher. Als freie Software unter dem Dach der Apache Foundation stellt es aber ein um so besseres Gateway für RDP-, VNC- und SSH-Verbindungen über HTTPS zur Verfügung. Ich möchte hier zeigen, wie diese Lösung einem mittelständischen Unternehmen geholfen hat seine Mitarbeiter im Corona-Lockdown mit Ihren Desktop-Arbeitsplätzen im Büro zu verbinden.

Das ist durchaus wortwörtlich gemeint. Jeder Windows Desktop-Arbeitsplatz lässt sich mit einem Mausklick zum Terminalserver umfunktionieren. Ein so angemeldeter Benutzer arbeitet mit seiner gewohnten Arbeitsumgebung und Profileinstellungen. Guacamole dient als Gateway zwischen den Welten und wandelt das RDP-Signal auf Port 3389 aus dem internen Netz in ein TLS verschlüsseltes HTTPS auf Port 443 um.

Auf Anwenderseite im Homeoffice reicht ein handelsüblicher Webbrowser, zur Not auch auf dem heimischen Privat-PC. Es werden keine Anpassungen, Plugins oder zusätzliche Software-Client-Installation benötigt. Integriert als externe Anwendung in einer Nextcloud28 findet ein Mitarbeiter alles in einer vertrauten und vor allem einheitlichen Oberfläche vor. Kalender, Emails und der Büro-Desktop in unterschiedlichen Browser-Tabs sind nicht nur technisch elegant sondern auch praktisch zum Hin- und Herswitchen.

RDP Anwendung via Guaucamole in Nextcloud Umgebung

Guacamole kann gegen OpenID, SAML oder wer es unbedingt möchte auch gegen ein LDAP authentifizieren. Aus Sicherheitsgründen empfehle ich letzteres ausdrücklich nicht. Ich habe bewusst die interne datenbankgestützte Authentifizierung gewählt, da ich gerade im Internet davon ausgehe, dass Anmeldedaten früher oder später verloren gehen.

Was Microsoft für sein RDP/RDS nur umständlich, undokumentiert und proprietär über Azure-Cloud29 jenseits von Internetstandards kann, das bietet Guacamole von Haus an: Eine TOTP Mehr-Faktor-Authentifizierung. Standardkonform und sicher nach RFC 623830. Wer bereits eine Nextcloud mit TOTP nutzt und auf einem Smartphone die benötigte FreeOTP31 App sein eigen nennt, wird sich sofort zurecht finden. Erfreulich aus Adminsicht ist der fertige Jail in Fail2Ban32 und auch die übersichtliche Reverse-Proxy Konfiguration33.

Funktional mag das alles nichts anderes sein, was Microsoft nicht auch mit seinem HTML5 RD Web Paket anbietet. Wenn man von der kruden Mehr-Faktor-Authentifizerung jenseits aller Internetstandards absieht. Der fundamentale Fehler bei Microsoft ist jedoch die zwingende Integration auf einem im AD integrierten Server mit dem IIS. Aus meiner bescheidenen Sicht eine komplette Fehlkonzeption! Welchen Sicherheitsgewinn bringt ein derart vorgelagertes System wenn ein Angreifer bei Überwindung des Webservers mit einem Bein genau dort steht, wo er auch hin will? Einem Tool wie mimikatz34 ist es egal, wo es sein “Golden Ticket” erzeugt solange es auf einem AD-Mitgliedsrechner ist.

Linux-Terminalserver

Ein Blog-Beitrag zu Terminalservern ohne gezeigt zu haben, wie einfach ein Terminalserver unter Debian eingerichtet ist? Für beliebig viele Anwender und frei von Lizenzkosten oder Abo-Fallen? Nein das geht nicht und deshalb zeige ich zum Abschluss eine Kurzanleitung. Als Anregung und Motivation zum selbst Ausprobieren. Ideal auch als Ersatzsystem oder als vorbereitende Maßnahme zur Migration. Als Hardware kann alles vom Raspi4 bis zum leistungsstarken Server genommen werden, je nachdem wie viele Benutzer gleichzeitig an diesem System arbeiten sollen. Es ist selbstredend, dass dieser Host netzwerktechnisch eine feste IP-Zuweisung oder zumindest über einen erreichbaren DNS-Namen verfügen sollte.

  1. Eine Debian Standard-Server Installation ohne grafische Oberfläche und nur mit SSH als einzige ausgewählte Installationsoption.

  2. Installation einer minimalen GNOME Oberfläche und einiger essentieller Desktop-Tools:

# apt install file-roller gthumb seahorse gnome-core gnome-dictionary 
ffmpeg gnupg hunspell-de-de firefox-esr-l10n-de webext-ublock-origin 
cifs-utils ssl-cert ca-certificates apt-transport-https
  1. Installation von xrdp30. Das ist der die Software, die eine X11 Session in das RDP-Format umwandelt und dank Komprimierung und Caching dieses über ein Netzwerk besser übertragbar macht:
# apt install xrdp
  1. Anpassung von Polkit, damit ein Benutzer mit jeweils seinem spezifischen Bildschirm nicht bei jeder Anmeldung nach Rootrechten gefragt wird. Dazu wird mit dem Texteditor der freien Wahl eine neue Regel-Datei erstellt:
# nano /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf

mit diesem Inhalt:

polkit.addRule(function(action, subject) {
if ((action.id == “org.freedesktop.color-manager.create-device” || 
action.id == “org.freedesktop.color-manager.create-profile” || 
action.id == “org.freedesktop.color-manager.delete-device” || 
action.id == “org.freedesktop.color-manager.delete-profile” || 
action.id == “org.freedesktop.color-manager.modify-device” || 
action.id == “org.freedesktop.color-manager.modify-profile”) 
&& subject.isInGroup(“{group}”))
{
return polkit.Result.YES;
}
});

Jetzt fehlen nur noch Benutzer zum Ausprobieren. Mit “adduser” einfach mehrere Benutzer erstellen und sich mit diesen von anderen Rechnern aus über RDP auf Port 3389 verbinden. Unter Windows kann hierfür mstsc.exe verwendet werden. Unter Linux nutze ich Remmina35, da es über eine übersichtliche Verbindungsliste verfügt.

Remmina

Wie ein Windows-Terminalserver kann auch dieser Linux-Terminalserver hinter einem Guacamole betrieben werden. Das RDP-Protokoll kann im Gegensatz zu Windows-Hosts aber auch sicher über SSH getunnelt werden.

Es gilt wie so oft Risiken abzuwägen. Wie, das verrät der nächste und dritte Teil dieser Blogserie.

Bis dahin viel Erfolg!
Tomas Jakobs


  1. https://en.wikipedia.org/wiki/Von_Neumann_architecture ↩︎

  2. https://www.westendverlag.de/buch/die-herrschaftsformel-2/ ↩︎

  3. https://en.wikipedia.org/wiki/Time-sharing_system_evolution ↩︎

  4. https://www.computerhistory.org/siliconengine/microprocessor-integrates-cpu-function-onto-a-single-chip/ ↩︎

  5. https://en.wikipedia.org/wiki/Single-user_mode ↩︎

  6. https://en.wikipedia.org/wiki/CP/M ↩︎

  7. https://en.wikipedia.org/wiki/MS-DOS ↩︎

  8. https://de.wikipedia.org/wiki/Leerlaufprozess ↩︎

  9. https://en.wikipedia.org/wiki/X_Window_System ↩︎

  10. https://en.wikipedia.org/wiki/Independent_Computing_Architecture ↩︎

  11. https://en.wikipedia.org/wiki/Citrix_Systems#Early_history ↩︎

  12. https://news.microsoft.com/1998/06/16/microsoft-releases-windows-nt-server-4-0-terminal-server-edition/ ↩︎

  13. https://en.wikipedia.org/wiki/Remote_Desktop_Protocol ↩︎

  14. https://www.thinstuff.com/products/xpvs-server/ ↩︎

  15. https://en.wikipedia.org/wiki/Portknocking ↩︎

  16. https://en.wikipedia.org/wiki/Geo-blocking ↩︎

  17. https://en.wikipedia.org/wiki/Snort_(software) ↩︎

  18. https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2020/Citrix_Schwachstelle_160120.html ↩︎

  19. https://github.com/aqhmal/CVE-2019-19781 ↩︎

  20. https://shodan.io ↩︎

  21. https://www.heise.de/hintergrund/Remote-Desktop-RDP-Liebstes-Kind-der-Cybercrime-Szene-1-4-4700048.html ↩︎

  22. https://en.wikipedia.org/wiki/BlueKeep ↩︎

  23. https://www.ic3.gov/media/2018/180927.aspx ↩︎

  24. https://en.wikipedia.org/wiki/Security_through_obscurity ↩︎

  25. https://en.wikipedia.org/wiki/Single_sign-on ↩︎

  26. https://de.wikipedia.org/wiki/Bring_your_own_device ↩︎

  27. https://guacamole.apache.org/ ↩︎

  28. https://apps.nextcloud.com/apps/external ↩︎

  29. https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks ↩︎

  30. https://tools.ietf.org/html/rfc6238 ↩︎

  31. https://freeotp.github.io/ ↩︎

  32. https://www.fail2ban.org/wiki/index.php/Main_Page ↩︎

  33. https://guacamole.apache.org/doc/gug/proxying-guacamole.html ↩︎

  34. https://github.com/gentilkiwi/mimikatz ↩︎

  35. https://remmina.org/ ↩︎

© 2020 Tomas Jakobs - Impressum und Datenschutzhinweis