Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.

Teil II - 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ßrechnern¹ 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”², 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” Prinzip³ bildet die Grundlage eines jeden modernen Betriebssystems.

Doch mit dem Mikrochip ab 1971⁴, 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-Mode⁵ Computer. Betriebssysteme wie CP/M ab 1974⁶ oder dessen dreist kopierter Klon MSDOS ab 1981⁷ 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.

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 idle⁸ verbringt.

Aus diesem Grund begann ab 1984 in der Unix-Welt die Entwicklung des X Window-Systems⁹, 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-Protokoll¹⁰ war geboren. Kurze Zeit später erfolgte die Umbenennung des Unternehmens in den heutigen Markennamen Citrix¹¹. Microsoft lizenzierte diese Technologie rasch, integrierte es als Terminal Services¹² in seiner Windows NT Produktfamilie und nannte es seinerseits Remote-Desktop-Protokoll¹³.

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 Thinstuff¹⁴. 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 Portknocking¹⁵, GeoIP-Blocking¹⁶ oder IDS/IPS Systemen mit Snort-Regeln¹⁷ 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 warnen¹⁸, da über 5000 Unternehmen alleine in Deutschland davon betroffen waren. Eine Recherche mit diesem netten Skript¹⁹ offenbarte mir ein halbes Jahr später im Juli 2020 noch dutzende, ungepatchte Systeme in Shodan²⁰.

Die Sicherheitslage bei Microsoft ist nicht besser. Es war und ist weiterhin das bevorzugte Einfallstor für Hacker²¹. 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 patchen²². Doch auch ohne Bluekeep gehörten FBI-Warnungen beinahe zum wiederkehrenden Ritual²³.

Sicherheitsproblematik

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”²⁴.

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 SSO²⁵ 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 Prinzip²⁶ 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, Guacamole²⁷ 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 Nextcloud²⁸ 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.

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-Cloud²⁹ jenseits von Internetstandards kann, das bietet Guacamole von Haus an: Eine TOTP Mehr-Faktor-Authentifizierung. Standardkonform und sicher nach RFC 6238³⁰. Wer bereits eine Nextcloud mit TOTP nutzt und auf einem Smartphone die benötigte FreeOTP³¹ App sein eigen nennt, wird sich sofort zurecht finden. Erfreulich aus Adminsicht ist der fertige Jail in Fail2Ban³² und auch die übersichtliche Reverse-Proxy Konfiguration³³.

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 mimikatz³⁴ 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.

Eine Debian Standard-Server Grundinstallation ohne grafische Oberfläche und mit SSH-Server als einzige ausgewählte Installationsoption. Anschliessend installieren wir eine minimale GNOME Oberfläche mit nur den essentiellen Desktop-Tools und einem Firefox-Browser:

# 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 -y

Installation von xrdp³⁵. 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 -y

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:

cat <<EOF>> /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf
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;
}
});
EOF

Jetzt fehlen nur noch Benutzer mit Ihren unterschiedlichen Desktops zum Ausprobieren. Mit ‘adduser’ einfach mehrere erstellen, unterschiedliche Desktops z.B. mit anderen Hintergrundfarben erstellen und sich mit diesen von einem anderen Rechner aus über RDP auf Port 3389 verbinden.

Unter Windows kann hierfür mstsc.exe verwendet werden. Unter Linux nutze ich als bevorzugten Client Remmina³⁶, da es über eine übersichtliche Verbindungsliste und Speichermöglichkeit für mehrere Anmeldungen und Gegenstellen verfügt, ordentlich sortiert in Untergruppen.

Wie bei einem Windows-Terminalserver kann auch dieser Linux-Terminalserver hinter einem Guacamole-Gateway mit HTTPS betrieben werden, idealerweise zusätzlich abgesichert mit 2-Faktor-Authentifizierung. Wem dieses ein zu großes Risiko ist, der kann weiterhin den Zugriff von Außen über SSH oder VPN realisieren.

So bekommt frei von Lizenzfragen jeder Mitarbeiter eine Remote-Desktop Umgebung zum Arbeiten, unabhängig vom jeweiligen Rechner im Büro oder Homeoffice. Das alles als Impuls und mögliches Basislager für weitere Anpassungen und Integrationen.

Your milage may vary.