Die Verwaltung von Linux-Servern oder Docker-Containern erfordert grundlegende Kenntnisse des Terminals, auch bekannt als Kommandozeile. Windows-Benutzer können beispielsweise das Programm PuTTY verwenden, um über Secure Shell (SSH) Fernzugriff auf einen Linux Server zu erhalten. SSH ist eine sichere Fernverbindung, die eine verschlüsselte Terminalverbindung zu einem Linux-Rechner herstellt. SSH bietet zwei grundlegende Zugriffsarten auf ein entferntes System: die nicht empfohlene Methode mit Benutzername/Passwort und die sicherere Variante mit einem bereitgestellten RSA-Schlüsselpaar.
Per Definition sind „Terminal“ und „Shell“ nicht dasselbe, werden aber oft synonym verwendet. Im Allgemeinen ist das Terminal die Kommandozeilenschnittstelle (CLI), die Tastatureingaben von Benutzern empfängt. Die Shell ist ein Interpreter, der innerhalb des Terminals ausgeführt wird, um Programme zu starten. Bei den meisten Linux-Distributionen ist BASH (Bourne Again Shell) die Standard-System-Shell. Neben BASH gibt es weitere Shell-Varianten wie KornShell (ksh) oder C Shell (csh).
Beim Zugriff auf einen Rechner, sei es über eine Reverse Shell oder SSH, kann sich das Terminal ungewöhnlich verhalten. Häufige Probleme sind die Unfähigkeit, Text zu löschen, Strg+C oder Strg+L zu verwenden, und die fehlerhafte Textdarstellung. So verbessern Sie die Terminalnavigation.
Schritte für ein besseres Terminalerlebnis
1. Temporäres Skript starten
script /dev/null -c bash
Dies startet ein Skript, das sich automatisch löscht, da es auf /dev/null verweist.
2. Reverse Shell in den Hintergrund verschieben
Drücken Sie STRG+Z. Dadurch wird der Reverse-Shell-Prozess in den Hintergrund verschoben.
3. Prozess fortsetzen und stty konfigurieren
stty raw -echo; fg
Dies führt Sie zurück zum Prozess und passt das Terminal für Rohdateneingabe ohne Echo an.
4. Terminal zurücksetzen
reset xterm
Verwenden Sie diesen Befehl auch dann, wenn der Text nicht korrekt angezeigt wird oder ungewöhnliche Einrückungen vorhanden sind.
5. Umgebungsvariable TERM konfigurieren
export TERM=xterm
Überprüfen Sie die Variable $TERM vor und nach diesem Schritt mit echo $TERM.
Ersetzen Sie [tatsächliche Konsolenzeilennummer] und [tatsächliche Konsolenspaltennummer] durch die entsprechenden Werte, die Sie mit dem Befehl stty size in einer normalen Konsole ermitteln.
Sicherheitshinweis: Linux-Server, die über das Internet erreichbar sind, sollten weder die Anmeldung per Root-Benutzer noch per Benutzerpasswort ermöglichen. Das Problem besteht in verteilten Brute-Force-Angriffen von Botnetzen, die darauf abzielen, eine administrative Shell zu erlangen und das System zu kapern. Moderne, gehärtete Linux-Server deaktivieren daher das Root-Konto und stellen Administratoren lediglich den Befehl sudo zur Verfügung.
Administratoren, die mehrere geöffnete Shells verwalten müssen, um verschiedene Rechner zu warten, nutzen gerne das praktische Tool TMUX [1]. Es ist aktuell in Version 3 verfügbar und lässt sich einfach über die Shell installieren:
apt-get install tmux
TMUX ermöglicht die Nutzung mehrerer Terminal-Sitzungen in einem einzigen Terminal. Für die korrekte Verwendung konsultieren Sie bitte die offizielle Handbuchseite [2]. Die Bedienung des Programms ist etwas komplex und erfordert etwas Einarbeitungszeit. Eine kurze Einführung würde den Rahmen dieses Beitrags sprengen und einen eigenen Artikel füllen, der möglicherweise in Zukunft veröffentlicht wird. Um Ihnen einen Eindruck von den Möglichkeiten von TMUX zu vermitteln, sehen Sie sich den folgenden Screenshot an.
Wer sich als Entwickler ein wenig mit Netzwerktechnik auskennt, weiß, dass man anhand der IP Adresse des Users einige spannende Details herausfinden kann. Diese Details sind neben Informationen zum Ursprungsland und der Stadt, aus der der Request kommt, auch der Provider. Es lassen sich also auf diese Art und Weise wirkungsvoll die mittlerweile beliebten Proxy Server erkennen und blockieren. Natürlich ist die Geolocation nur ein Baustein in der langen Kette, Nutzer eindeutig zu erkennen.
Die aktuelle Version von GeoIP ist 2 und hat damit die veraltete Version 1 komplett abgelöst. GeoIP2 ist ein Dienst der Firma MaxMind [1] für die es auch eine kostenfreie Community Variante gibt. Wer beispielsweise ein selbstgehostetes Analytics wie Matomo betreibt, sollte um die vollständige Funktionalität des Werkzeugs auch auf eine korrekte GeoIP2 Konfiguration des Webservers achten.
Um GeoIP2 auf dem eigenen Server zu integrieren, gibt es zwei Möglichkeiten. Variante 1 ist die einfacher umzusetzende Option als PHP Modul. Variante 2 ist leistungsfähiger, erfordert aber auch mehr Kenntnisse aus dem Bereich Serveradministration. Bei dieser Lösung verwenden wir GeoIP2 als Apache2 Modul.
Wer auf dem eigenen Server bereits Fail2Ban [2] korrekt laufen hat, überlegt möglicherweise, ob es sinnvoll ist, Fail2Ban mit GeoIP2 zu verknüpfen. Diese Möglichkeit besteht durchaus, hat allerdings mehr Vorteile als Nachteile, denn Fail2Ban operiert direkt auf den Apache Logdateien. Dies ist der Grund, wieso Fail2Ban erst beim zweiten Request von einer IP Adresse aktiv werden kann. Um GeoIP2 in Fail2Ban zu aktivieren, muss ein entsprechender Filter gesetzt werden, was sich bei Servern mit hoher Nutzerlast schnell negativ auf die Performance auswirken kann. Daher ist es besser, die Requests zum Server zu monitoren und gezielte spezielle Länder bei vermuteten Angriffen direkt über den Request zu blockieren. Dazu muss allerdings GeoIP2 als Apache Modul installiert und konfiguriert sein.
Bevor wir allerdings loslegen können, müssen wir uns bei MaxMind einen kostenfreien Account zulegen und für unser Beispiel die kostenfreien GeoIP2 (Lite Version) Datenbanken herunterladen.
Nachdem die erste Hürde genommen ist, können wir auch gleich loslegen. Um GeoIP2 in PHP Anwendungen nutzen zu können, benötigt man eine entsprechende Bibliothek. Mit Composer als Abhängigkeitsmanagement lässt sich die Bibliothek geoip2/geoip2 in einer aktuellen Version einbinden.
Wie man sieht, muss bei der Initialisierung auch das Verzeichnis zu MaxMind GeoLite Datenbank angegeben werden. Diese Variante eignet sich besonders für all diejenigen, die auf einem Managed Server oder Webspace unterwegs sind und keinen Einfluss auf die installierte Umgebung haben. Von der Nutzung von PECL (PHP Extension Community Library) sollte man wiederum Abstand nehmen, da diese als veraltet markiert wurde und künftig durch PIE (PHP Installer for Extensions) [4] ersetzt ist.
Um GeoIP2 global für alle PHP-Applikationen einzubinden, ist etwas mehr Aufwand notwendig. Hierzu haben wir als Grundvoraussetzung eine funktionierende Apache 2/ PHP-Installation auf einem Linux-Betriebssystem. Ist das gegeben, sind nur wenige Schritte durchzuführen:
Installieren der maxminddb Bibliothek
Herunterladen der PIE PHAR Bibliothek
Für PIE maxminddb installieren & Extension in der php.ini aktivieren
Die GeoLite Datenbanken auf dem Server bereitstellen
Bevor man aber diesem Weg folgt, sollte man sich überlegen, ob man nicht lieber gleich MaxMindDB als Apache Modul bereitstellt. Der gravierendste Vorteil dieser Variante ist die hohe Geschwindigkeit, die auch bei hoher Nutzerlast den Server nicht gleich in die Knie zwingt. Das Apache Modul stellt dafür Umgebungsvariablen bereit, die bereits in der Apache Konfiguration zur Filterung verwendet werden können. Die größte Herausforderung, welche es zu meistern gilt ist das Kompilieren des Apache 2 Moduls.
In Zeile 13 kopieren wir die zuvor von GitHub [5] heruntergeladene mod_maxminddb in der Version 1.3.0 in den Container, um diese im nachfolgenden Schritt zu kompilieren. Wichtig ist der Zusatz in Zeile 16, der die Fehlermeldung unterdrückt: dass automake in der Version 1.6 vorliegen muss. Anschließend kann das Modul aktiviert werden und die von MaxMind heruntergeladenen Datenbanken sind ebenfalls in den Docker Container zu kopieren. Zu guterletzt ist noch die Modulkonfiguration für den Apache in der Datei geoip.conf vorzunehmen und zu aktivieren. Der Inhalt der Konfigurationsdatei lautet wie folgt:
Eines der wichtigsten Erkenntnisse zum Softwaretesting stammt von dem viel zitierten Artikel „The Humble Programmer“, den Dijkstra 1972 veröffentlichte. Sinngemäß besagt dies, dass durch Testen lediglich Fehler nachgewiesen werden können, aber es ist unmöglich, die Fehlerfreiheit des Programms nachzuweisen. Das bedeutet im Umkehrschluss, dass eine hohe Testqualität bereits möglichst viele Fehler aufdeckt und damit die Wahrscheinlichkeit sinkt, dass im Programm weitere Fehler vorhanden sind.
Nun stellt sich zuerst die Frage, was eine ‚gute‘ Testqualität ausmacht. Ein sehr wichtiger Faktor ist die Performance. Dauert die Testausführung länger als 5 Minuten, stört dies den Entwickler im Arbeitsfluss. Dauert die Testausführung länger als 10 Minuten, ist die Akzeptanz der Entwickler verloren, die Tests automatisiert im Buildprozess durchlaufen zu lassen. Das führt dazu, dass die Testausführung lokal deaktiviert wird, damit das Prinzip, möglichst schnell im Fehlerfall zu scheitern, verletzt wird. Das Prinzip des schnellen Scheiterns ist einer der wichtigen Grundpfeiler automatisierter Softwaretests, denn so kann man sich zeitnah dem Problem widmen und es beheben. Diese schnelle Reaktion, ist es welche den Arbeitsfluss des Entwicklers unterstützt und dadurch den sogenannten Kontextwechsel vermeidet. Je weniger man sich auf eine neue Situation einstellen muss, umso produktiver kann man arbeiten, was als Konsequenz eine erhebliche Senkung der Entwicklungskosten ausmachen kann. Wir können sagen, dass nicht die Anzahl der Tests relevant ist, sondern es darauf ankommt, die richtigen, also relevanten Tests zu schreiben.
Eine Idee davon, wie viele Testfälle man benötigt, gibt die Arbeit von McCabe, welcher 1976 ein Maß für die Komplexität formulierte. Die Komplexitätszahl einer Funktion oder Methode stellt einen Orientierungspunkt für die Menge der benötigten Testfälle dar. Allerdings bedeutet eine hohe Anzahl von Testfällen nicht automatisch, dass diese eine Relevanz für die Korrektheit der Methode beziehungsweise Funktion haben. Der Nutzen oder, auch anders ausgedrückt, die Ausdruckskraft der vorhandenen Testfälle ergibt sich aus der Tatsache, wie gut diese den vorhandenen Code überdecken. Nur eine vollständige Coverage stellt sicher, dass auch alle Bereiche einer Funktion ausgeführt wurden und somit durch einen Festfall abgedeckt sind. Bei der Testcoverage unterscheiden wir zwei Metriken, die Abdeckung aller Codezeilen und die Abdeckung aller Verzweigungen. Sicher kann man vor allem in sogenannten Legacy-Projekten nur sehr schwer eine hohe Testabdeckung erreichen. Um den Aufwand aussagekräftiger Tests auf ein überschaubares Maß zu begrenzen, ist es notwendig, ausschließlich bei neu hinzugefügten Funktionen eine Line- und Branch Coverage von 100 % zu erreichen. Kann die 100 % nicht erreicht werden, ist dies ein Indikator für ein Refactoring, um die Testbarkeit der hinzugefügten Funktionalität zu gewährleisten.
Gehen wir nun vom optimalen Fall aus und betrachten ein sogenanntes Greenfield-Projekt, dessen Anzahl der Testfälle auch dem Komplexitätsmaß nach McCabe entspricht und für das wir bereits eine 100 % Testabdeckung für Zeilen und Verzweigungen nachweisen können, stehen wir immer noch vor dem Problem, das Dijkstra formuliert hat. Denn es muss uns bewusst sein, dass wir zwar nachweisen, alle Codbereiche durch einen Testfall betreten zu haben, aber ob die von uns getroffenen Annahmen über das Verhalten des Quellcodes korrekt sind, können wir nicht belegen. Im Kontext der xUnit Tests geht es um die verschiedenen Assert-Funktionen, welche eine Funktion gegen einen Erwartungswert testen. Dazu ein klassisches Beispiel für Java Collections, das sich auch auf andere Programmiersprachen projezieren lässt.
Listen, genauer gesagt: Die in Java implementierte ArrayList speichert die Elemente der Liste nicht als Wert in der Liste, sondern nutzt das sogenannte Call-by-Reference, welches lediglich die Speicheradresse des Listenelements referenziert. Führt man nun Operationen auf bestehenden Listen aus, manipuliert man stets die originale Liste. Vergleicht man dann in einem Testfall die originale Liste mit der manipulierten Liste, sind diese immer identisch, da es sich um dieselbe Liste handelt. Erst wenn man beispielsweise mit einem Copy-Konstruktor eine wirkliche Kopie des Originals erstellt, welche man manipuliert, um Vergleichstests durchzuführen, sind die getroffenen Annahmen korrekt. Überspitzt ausgedrückt, kann man eine 100 %-Testabdeckung erreichen, ohne ein wirkliches Sicherheitsnetz zur Fehlererkennung aufzuspannen.
Um solche logischen Fehler, wie gerade beschrieben, in den Tests zu entdecken, können wir uns des sogenannten Mutationstestings bedienen. Auch das Konzept des Mutationtesting hat seine Ursprünge bereits in den 1970er Jahren. Mit dem Artikel „Fault Diagnostics of Computer Programms“ beschrieb Richard Lipton 1971 die Idee zu Mutation-Testing, welches zahlreiche weitere Forschungsarbeiten nach sich zog.
Die Idee für Mutationstests ist sehr einfach, wie so viele bahnbrechende Errungenschaften. Gehen wir davon aus, das im Quellcode ein Ausdruck if(var > 0) enthalten ist und zu diesem Ausdruck auch ein entsprechender Test formuliert wurde. Wenn wir nun hergehen und die Bedingung in der IF Anweisung verändern, sollte der zugehörige Test fehlschlagen. Nun gibt es verschiedene Möglichkeiten, wie die IF-Anweisung verändert werden kann. Eine Variante ist die Umkehrung des Operators von > nach <. Aber auch die Verwendung anderer Operatoren wie = oder ! ist möglich. Eine andere Variante wäre, den Vergleichswert 0 abzuändern. Die erreicht man durch das Erhöhen oder Reduzieren um 1. Alle diese Variationen stellen sogenannte Mutationen des Originalausdrucks dar, weswegen man diese auch als Mutanten bezeichnen kann. Das Ziel ist, dass möglichst viele Mutanten den vorhandenen Testfall fehlschlagen lassen. Jeder Mutant, der den Testfall fehlschlagen lässt, wird als Kill bezeichnet.
Wenn keiner der erzeugten Mutanten den Testfall fehlschlagen lässt, ist die Korrektheit des Testfalls anzuzweifeln und muss überprüft werden. Idealerweise lassen alle Mutanten den Testfall fehlschlagen, was eher als Ausnahme zu werten ist. Aussagekräftige Testfälle sollten einen Mutationsscore von mindestens 70 % erreichen. Die Berechnung des Mutation Scors, oder auch der Kill Rate lautet wie folgt: Um den Mutationswert zu berechnen, teilt man die Anzahl der abgetöteten Mutanten (Mutanten, die zu einem Fehlschlag der Tests geführt haben) durch die Gesamtzahl der erzeugten Mutanten und multipliziert das Ergebnis mit 100, um einen Prozentsatz zu erhalten. Wenn beispielsweise 7 von 10 Mutanten abgetötet werden, beträgt der Mutationswert 70 %.
Manche Mutanten verhalten sich funktional identisch zum Originalcode. Diese äquivalenten Mutanten können durch keinen Test eliminiert werden, da sie keine eigentlichen Fehler darstellen. Damit haben wir ein Entscheidungskriterium, das bei niedrigem Mutations-Score und bei einer Bewertung der Situation weiterhelfen kann.
Auch wenn das hier beschriebene Konzept sehr leicht verständlich ist, liegt wie so oft der Teufel im Detail. Zum einen müssen sinnvolle Mutationsoperatoren ausgewählt und zum anderen sollte die Anzahl der generierten Mutanten aus Gründen der Testausführungsdauer begrenzt werden. Da je nach Größe der Codebasis die Ermittlung des Mutation Scores sehr langwierig sein kann, sollten Mutation-Tests nicht über den Standard Buildprozess ausgeführt werden und als eigenständige Testprozedur laufen. Grundsätzlich kann man allerdings sagen, dass Entwickler mit einem guten Verständnis für testgetriebene Softwareentwicklung sich auch zügig in das Thema Mutation Testing einfinden. Aber auch für die Bewertung seitens des Projektmanagements ist Mutant Testing in Kombination mit einer hohen Testcoverage ein sehr mächtiges Mittel, ohne den Quelltext zu lesen. Abschließend ist als sehr wichtiger Punkt anzumerken, dass die hier beschriebene Prozedur keine Aussage zu Fragestellungen der Sicherheit beantworten kann. Um sicherzustellen, dass die Anwendung gegen Hackerangriffe wie SQL Injections geschützt ist, sind auf Sicherheit spezialisierte Audits unvermeidlich.
Wer sich ernsthaft mit dem Thema Computersicherheit auseinandersetzt, kommt schnell zu dem Bereich Passwortsicherheit. Horrorgeschichten und Mythen lassen einen dann schnell glauben, man würde wie Don Quijote gegen Windmühlen kämpfen. Ganz unheikel ist der korrekte Umgang natürlich nicht, aber ganz so hilflos gegen potenzielle Angreifer, wie es auf den ersten Blick erscheinen mag, sind wir allerdings auch nicht.
Bevor wir in die Details eintauchen, ist es notwendig, dass uns eine wichtige Grundregel bewusst wird. Sicherheit und Komfort sind sich ausschließende Eigenschaften. Je besser das Sicherheitskonzept umgesetzt und auch erzwungen wird, umso unhandlicher wird es in der täglichen Benutzung. Deswegen ist es unausweichlich, einen sinnvollen und praktizierbaren Kompromiss aus Schutz und Anwendbarkeit umzusetzen. Also nähern wir uns dem Thema schrittweise, um mit falsch interpretiertem Halbwissen aufzuräumen.
Grundsätzlich unterscheiden wir zwei Anwendungsfälle. Authentifizierung soll sicherstellen, dass ich auch die Person bin, für die ich mich ausgebe. Autorisierung stellt sicher, dass ich nur die Aktionen durchführen darf, für die ich berechtigt bin. In diesem Artikel beschäftigen wir uns ausschließlich mit der Authentifizierung, also die Anmeldung auf einem Gerät oder zu einem Dienst.
Wenn wir einen Dienst oder auch ein Gerät, das wir benutzen, vor ungewolltem Zugriff schützen möchten, bringen wir sozusagen ein digitales Schloss an. Der Schlüssel für dieses Schloss ist unser Passwort. Wie im echten Leben gibt es auch in der digitalen Welt viele Analogien. Wenn wir Besuch von Freunden bekommen und diesen eine Kopie unseres Wohnungsschlüssels überlassen, hätten diese theoretisch die Möglichkeit, unbemerkt eine Kopie des Schlüssels anzufertigen, um unser Zuhause auch ohne unsere Zustimmung betreten zu können. Deswegen geben wir nur vertrauensvollen Menschen unseren Schlüssel. Mit dem Passwort, das wir für die Nutzung digitaler Dienste wie Streaming, Computerspiele oder sozialer Medien verwenden, ist es ähnlich. Stellen wir uns einmal vor, wir möchten eine Homepage und beauftragen jemanden, dies für uns umzusetzen. Damit die Homepage auch im Internet erreichbar wird, müssen einige Verträge für Server, Domain und möglicherweise auch zusätzliche Softwarelizenzen abgeschlossen werden. Wenn ich nun nicht das technische Wissen habe, diese Dinge selbst umzusetzen, benötige ich eine Person, der ich vertraue, die diese Aufgaben für mich übernimmt. Damit das auch gelingt, muss ich dieser Person meine Zugangsdaten für die technischen Systeme mitteilen. Solange ich mich mit dieser Person gut verstehe, ist das in aller Regel auch kein Problem. Kompliziert wird es erst dann, wenn aus irgendeinem Grund die Zusammenarbeit nicht mehr klappt. Dann sollte ich zumindest das technische Wissen besitzen, um meine Accounts zu kontrollieren und die Zugangsdaten zu ändern.
In diesem Beispiel sieht man auch ein anderes Problem. Hat man für alle Dinge, die man im Internet benutzt, dieselben Zugangsdaten, könnte nun diese Person auch mein E-Mail Postfach öffnen oder andere Dinge in meinem Namen in der digitalen Welt tun. Deswegen lautet die wichtigste Grundregel in der Computersicherheit: Benutze niemals dasselbe Passwort für mehrere Dienste. Es gibt natürlich noch viele andere Verhaltensregeln, die im Umgang mit Passwortsicherheit eingehalten werden sollten. Ich habe mir zu eigen gemacht, zwischen beruflichem und privatem Umfeld nicht zu unterscheiden. So wird mein Verhalten zu einer Gewohnheit und ich minimiere die Möglichkeit, Fehler zu machen.
Bevor wir uns aber überlegen, was überhaupt ein vernünftiges Passwort mit ausreichendem Schutz ist, müssen wir ein wichtiges Konzept kennenlernen. Und zwar geht es um die Möglichkeit, alle Kombinationen durchzuprobieren, bis man den richtigen Schlüssel gefunden hat. Dieses Konzept des schematischen Durchprobierens nennt man im IT-Jargon Brute Force. Wer also sein Fahrrad an einem unbeobachteten Ort mit einem Zahlenschloss, das ‚nur‘ vier Stellen hat, anschließt, schützt es nicht wirklich. Ein potenzieller Dieb muss nur beginnend mit 0000 alle Kombinationen der Reihe nach durchprobieren, bis das Schloss sich öffnet. Selbst wenn man sich Zeit damit lässt, dauert ein Durchtesten aller möglichen Kombinationen bis maximal 9999 nicht länger als 30 Minuten. Dieses Beispiel führt uns allerdings zu zwei Erkenntnissen. Steht das Fahrrad an einem gut frequentierten Ort, an dem es auffällt, wenn jemand am Schloss länger als 5 Minuten umherprobiert, ist dieser Schutz ausreichend. Die zweite Erkenntnis ist, dass die Zeitspanne, alle Nummern durchzuprobieren, mit jeder zusätzlichen Stelle erhöht wird. Die technische Umsetzung kann je nachdem, wie hoch der tatsächliche Schutz sein muss, extrem komplex werden.
Eine Maßnahme, die Webseitenbetreiber nutzen, nennt sich Informationssparsamenkeit. Macht man einen Fehler beim Login, erhält man nur die Rückmeldung, dass die Anmeldung nicht korrekt war. Das heißt, wir erfahren nicht, ob der Benutzer, unter dem wir uns anmelden, der richtige ist oder das Passwort falsch ist. Denn die Kombination aus Benutzeranmeldung und Passwort muss korrekt sein.
Auch die Menge der Versuche, sich bei einem bestehenden Nutzerkonto anzumelden, ist limitiert. In aller Regel ist es so, dass man 3 Versuche hat, das korrekte Passwort einzugeben. Tippfehler oder Feststelltaste können hier schnell zu Fehlversuchen führen. Gibt man nun ein viertes Mal das Passwort falsch ein, wird eine Zeitsperre aktiv und man muss zum Beispiel 5 Minuten warten, bis man das Passwort erneut eingeben kann. Jeder weitere Fehlversuch verdoppelt die Zeitspanne. Damit man als Webseitenbetreiber mehr Informationen zum Angreifer sammeln kann, werden bis zu 100 Fehlversuche zugelassen, die entsprechend protokolliert werden. Habe ich mich inzwischen aber erfolgreich eingeloggt, wird der Zähler mit den Fehlversuchen wieder zurückgesetzt. Hier ist es wichtig, dass der Betreiber diese Dinge beobachtet und beim Erkennen von Angriffen Maßnahmen zum Schutz des Nutzeraccounts einleitet. Das kann bisweilen zu einer zeitweiligen Deaktivierung des Accounts führen. Wir sehen, dass eine essenzielle Maßnahme die Beschränkung von Ressourcen ist, damit man nicht beliebig lang alle möglichen Passwortvarianten durchprobieren kann.
Natürlich ist es auch wichtig, ein ‚starkes‘ Passwort zu wählen. Wie wir bereits sehen konnten, ist die Anzahl der Stellen ein wichtiges Detail. Die Menge der möglichen Kombinationen erhöht sich aber auch, wenn man den Zeichensatz erweitert. Bei den Zahlen 0 bis 9 haben wir pro Stelle genau 10 Möglichkeiten. Hat unser Passwort nun 4 Stellen, sind das genau 9999 Kombinationen. In vielen Fällen, wie bei der Bankkarte, ist das ausreichend, denn nach 3 Fehlversuchen ist Schluss und die Karte ist gesperrt. Versucht man sein Glück am Bankautomaten, wird die Karte sogar eingezogen.
Erweitern wir unseren Zeichensatz der Zahlen mit großen und kleinen Buchstaben plus einiger Sonderzeichen, haben wir schnell pro Passwortstelle eine Kombinationsanzahl von über 60 Zeichen erreicht. Je nach Sprache variiert die Menge der Zeichen. Die deutsche Sprache hat noch die Buchstaben ä, ö, ü und ß zu bieten, die im englischen ABC nicht vorkommen. Wir sehen es gibt für Passwörter kulturelle Unterschiede. Die Zeichen a-z, A- Z und 0-9 bieten bereits 62 Kombinationen an. Ein Passwort, das 4 Stellen besitzt, hat also (62 * 62 * 62 * 62) = 624 = 14776336 Kombinationen. Hier ist ein Mensch, der das der Reihe nach durchprobieren soll, schon eine sehr lange Zeit beschäftigt. Ein Computer benötigt hierfür nur wenige Minuten. Deswegen ist es für ein sicheres Passwort notwendig, möglichst viele unterschiedliche Zeichen zu mischen, also Zahlen, Groß- und Kleinbuchstaben etc., und zusätzlich mindestens 15 Stellen zu verwenden. Solche Passwörter sind natürlich nicht gut zu merken. Schwieriger wird es, wenn man nun eine Vielzahl solcher unterschiedlicher Passwörter im Griff haben muss. Hier sorgen sogenannte Passwort Manager wie KeePass mit entsprechenden Browser Plugins für optimale Unterstützung. Lösungen, die vorschlagen, das Passwort in der Cloud, bei einem Unternehmen zu sichern, mögen durchaus gute Absichten haben, sind aber auch beliebte Angriffsziele von Hackern. Eingrund wieso für mich nur ein Offline-Passwortsafe auf meinem eigenen Rechner infrage kommt.
Mit all der Erkenntnis könnte man nun zu dem Schluss kommen, dass Passwörter keine gute Schutzfunktion besitzen und man besser auf andere Mechanismen ausweichen sollte. Tatsächlich gibt es genügend etablierte Lösungen, von denen die meisten auf dem Konzept der Biometrie beruhen. Wir kennen aus der Kriminalarbeit der Polizei das Konzept der Bestimmung von Fingerabdrücken. Wir gehen also davon aus, dass unser Körper biometrische Merkmale aufweist, die kein anderer Mensch besitzt, und so unsere Identität zweifelsfrei bestätigt werden kann. Seit vielen Jahren besitzen Geräte wie Laptops die Möglichkeit, den Fingerabdruck zu scannen und damit den Zugriff auf das Gerät freizugeben. Neben Fingerabdrücken zählen der Iriscan oder die Gesichtserkennung ebenfalls zu den eindeutigen Biometriemerkmalen.
Was auf den ersten Blick als sehr clever erscheint, könnte allerdings im Praxistest schnell als Sicherheitslücke bewertet werden. Das populärste Beispiel ist die FaceID, mit der man unter anderem über die Kamera das eigene Smartphone freischalten kann. Stellen wir uns die unschöne Situation vor, dass man uns das Telefon gewaltsam entwendet und bevor der Räuber erwischt wird, schaltet er das Telefon einfach frei, indem er es mir vors Gesicht hält, um sämtliche Sicherheitsüberprüfungen im Gerät zu deaktivieren. Wer nun argumentiert, dass in solch einer Raubsituation die Möglichkeiten durch Stress sehr eingeschränkt sind, mag durchaus recht haben, aber ausschließen kann man sie nicht. Es ist nur eine Beschreibung einer denkbaren Situation, wie sich Fremde unerlaubten Zugriff auf ein geschütztes Gerät durch Biometrie verschaffen können. Deswegen kann Biometrie ausschließlich eine Ergänzung des bestehenden Sicherheitskonzepts sein und nicht die zentrale Maßnahme. Zudem ist auch nicht geklärt, wie und wo die biometrischen Daten gespeichert werden, um sie vor Missbrauch zu schützen.
Moderne Sicherheitskonzepte basieren auf mehreren Komponenten, die ineinandergreifen. Bei der Anmeldung an Systemen kommen neben einem Passwort nun verschiedene weitere Faktoren zur Anwendung. Weit verbreitet ist die Zwei-Faktor Authentifizierung, bei der neben dem Passwort der zweite Faktor etwas darstellt, das man persönlich besitzt, auf das niemand anderes so einfach Zugriff hat. Momentan wird als zweiter Faktor das Telefon mit SMS oder E-Mail verwendet. Hier versendet die Anwendung an die hinterlegte Telefonnummer oder E-Mail Adresse einen einmaligen Code, der nur wenige Minuten gültig ist und dann verfällt. Nach erfolgreicher Verifizierung des Log-ins mit Passwort muss dann der Sicherheitscode eingegeben werden. Solange sichergestellt werden kann, dass niemand Zugriff auf den zweiten Faktor bekommt, also beispielsweise das Telefon entwendet wird, ist diese Methode sehr sicher. Jedem, dem das Telefon allerdings einmal abhanden gekommen ist und man nicht zeitnah eine Ersatz-SIM-Karte mit der Telefonnummer bekommen konnte, hat die Schwachstelle dieses Sicherheitskonzeptes bereits am eigenen Leibe erfahren. Das aber macht ein robustes und starkes Sicherheitskonzept aus, das es auch in schwierigen Situationen zuverlässig Schutz bietet und dennoch einen berechtigten Reset zulässt.
Ein Sicherheitskonzept lässt sich durch neue Schichten mit zusätzlichen Faktoren, die wie eine Kette aufgebaut sind, erweitern. Daher kommt die Bezeichnung N-Faktor. Das N ist ein Platzhalter der eingebauten Schichten. Allerdings muss man auch sagen, dass, je mehr Schichten zum Tragen kommen, die angestrebte Lösung immer unpraktikabler für die Nutzer wird. Schauen wir uns daher kurz einmal an, welche möglichen Faktoren zum Tragen kommen können.
Wissen (Knowledge): Passwort, Pin
Besitz (Ownership): E-Mail, Token, Telefon
Biometrie: Fingerabdruck
Standort (Location): GPS, IP
Zeit (Time): Authentifizierungscodes mit Ablaufzeit
Verhalten (Behavioral): Tippgeschwindigkeit
Gerät (Device): Laptop, Smartphone, Tablet
Wenn wir diese Liste genauer betrachten, erkennen wir viele Fragmente, die in unterschiedlichen Kombinationen in modernen Webdiensten genutzt werden. Das Ziel ist es den Passwortschutz so zu verstärken, dass auch unvorsichtige Nutzer nicht zum Einfallstor für Missbrauch werden können. Denn auch in der IT-Sicherheit gilt der Grundsatz, dass eine Kette nur so stark ist wie das schwächste Glied.
Natürlich haben wir das Thema in diesem Artikel nur streifen können und es gäbe noch viel mehr zu erwähnen. So haben wir den Bereich der Kryptografie vollständig ausgeblendet. Das sind aber Themen, die vor allem für IT-Profis bzw. Programmierer relevant sind. So kann man auf diesem Blog hier unteranderem einen Artikel lesen, der sich mit der sicheren Speicherung von Passwörtern in Datenbanken beschäftigt. Seit ich mich im Rahmen des aktuellen KI Trends intensiver mit dem Rekonstruieren gestohlener Passworthashes beschäftige, ist mir durchaus bewusst, wie wichtig die in diesem Artikel beschriebenen Konzepte und deren Beachtung sind. Denn mit geschickter Wahl von möglichen Kombinationen lassen sich die zu durchsuchenden Möglichkeiten massiv reduzieren, wodurch man erhebliche Rechenpower einsparen kann. Sicher darf man in absehbarer Zukunft einen sehr technischen Artikel aus der Kategorie Pentesting über die Möglichkeiten zum Knacken von Passwörtern geben.
Die Prophezeiung, dass Programmierer obsolet werden, weil sich Computer quasi selbst programmieren, hat mittlerweile einige Jahrzehnte auf dem Buckel. Bisher ist das Berufsbild Programmierer aber noch nicht ausgestorben. Dennoch hat sich in den letzten Jahren einiges grundlegend verändert. Die Leistungsfähigkeit aktueller K. I. Systeme weckt unterschiedlichste Emotionen. Die einen hassen es, die anderen lieben es. Allerdings ist es wie so immer im Leben: Nicht alles ist schwarz oder weiß. Daher möchte ich meine Erfahrungen mit K. I. unterstützendem Programmieren zum Besten geben und eine Einschätzung der Gesamtsituation wagen.
Meine ersten Berührungspunkte mit künstlicher Intelligenz und Machine Learning liegen schon sehr weit zurück, sodass mich die Leistungsfähigkeit von ChatGPT und Co. bei der Markteinführung um das Jahr 2024 nicht wirklich beeindrucken konnte. Die ersten Versionen waren eher zur Gewöhnung gedacht und in ihrem Können sehr eingeschränkt. Dieser Umstand hat sich mittlerweile erheblich verändert und ist noch lange nicht am Scheitelpunkt angekommen.
Die Entwicklung erfolgt exponentiell. Grob kann gesagt werden, dass die Leistungsfähigkeit sich mit jedem Sprung in der Hälfte der Zeit zum vorhergehenden Sprung verdoppelt.
Aktuell befinden wir uns in der dritten Iteration. Die darauffolgende Iteration wird mit doppelter Leistungsfähigkeit keine 18 Monate mehr benötigen, sondern maximal 9 Monate. Meine Quintessenz für den Bereich Softwareentwicklung lautet: K. I. kann fähige Programmierer und Administratoren in ihrem Schaffen massiv unterstützen und deren Performance erheblich anheben. Allerdings hat wie so alles im Leben auch dieser Umstand seine Schattenseiten. In diesem Artikel nehme ich mir die Zeit und beleuchte zu dem Thema ein wenig den Hintergrund.
Vor einiger Zeit traf ich in meiner Timeline in den einschlägigen Social Media Plattformen immer wieder auf Nachrichten, wie Juniorentwickler über Vibe Coding schwärmten. Zuerst dachte ich, es ginge um die optimale Atmosphäre beim Arbeiten. Also Sachen wie die richtige Musik und ätherische Öle, um in den perfekten Arbeitsflow zu kommen. Aber nein. Das war nicht, worum es ging. Leute, die nichts vom Programmieren wussten, konnten auf einmal Code erzeugen, der augenscheinlich das gemacht hat, was die Ersteller beabsichtigt haben. Klingt im ersten Moment auch ganz toll. Die Realität ist aber eine andere.
Copy-Paste-eh kennen wir schon etwas länger. Dazu brauchten wir keine K. I. nicht so lang ist es her, dass man Codeschnipsel gegoogelt hat und dann auf Internetseiten wie Stack Overflow fündig wurde. Schnell wurden Fragmente von vermeintlichen Empfehlungen in die eigene Codebase kopiert, und wenn es funktioniert hat, blieb alles ungeprüft so stehen, wie man es übernommen hatte. Die vermeintlichen Schlauberger waren auch nicht in der Lage, die kopierten Codefragmente zu verstehen und geschweige denn, diese an das eigene Projekt korrekt anzupassen. Daher hat sich der Ausdruck >Copy-passt-eh< etabliert. Dass dieses Codefragment aber in Produktionsumgebungen für massive Probleme sorgen konnte, wurde von den vermeintlichen Experten gern ignoriert. Das Spektrum der Störungen reichte von schlechter Performance bis hin zu sicherheitskritischen Schwachstellen. Diese Situation hat sich mit der Verfügbarkeit von K. I. für die breite Masse nicht verändert. Daher habe ich die Prognose, dass in den nächsten Jahren eine Schwemme von qualitativ schlechter Software um die Gunst der Anwender buhlen wird.
Hier kann ich nur wieder Grady Booch zitieren: „A fool with a tool is still a fool.“ Denn meine Beobachtungen, in eigenen Projekten LLM zur Programmierung zu verwenden, sind eher verhalten. In meiner Wahrnehmung sind es eher Projektleiter und Leute, die nicht programmieren können, die in den sozialen Medien die Leistungsfähigkeit von K. I. Modellen massiv überbewerten.
Grundsätzlich bin ich ein skeptischer Mensch und habe natürlich die üblichen Verdächtigen, KI-Modelle, für meine tägliche Arbeit versucht einzusetzen. Ich war explizit bei den Community-Varianten, ohne Bezahlung. Denn mit diesen Versionen wird die Welt künftig mit schlechter Software überflutet. Auch hier kann ich massiv abkürzen. Sämtliche Ergebnisse von Grok im Bereich Programmierung/Scripting und Konfiguration waren unterdurchschnittlich. Es hat sich ein wenig wie in alten Foren angefühlt. Anstatt diese nervigen Fragen, wieso und warum zu stellen, gelang es Grok nicht, zum Punkt zu kommen. Geschweige denn, eine funktionsfähige Lösung zu präsentieren. Dafür brillierte das Modell mit sinnbefreiten Motivationssprüchen à la „Teamleiter auf Steroiden“. Es erinnert mich ein wenig an Aussagen von Joseph Weizenbaum über virtuelle Gespräche und seinen Eliza Chatbot.
Etwas besser ging es mit Deep Seek. Zumindest kamen da nutzbare Resultate heraus. Die waren auch sofort einsetzbar und haben augenscheinlich auch das gemacht, wofür sie angedacht waren. Hat man sich den Code aber richtig angeschaut, war dieser mit allem möglichen Zeug überfrachtet, das mindestens unnötig war. Ich hatte in diesen Fällen keine weitere Analyse gemacht, ob eventuell sicherheitskritische Probleme aufgetreten sind. Statistisch kann man davon ausgehen, dass je mehr Code vorhanden ist, umso höher die Wahrscheinlichkeit ist, dass Fehler enthalten sind. Opus wiederum nervte permanent damit, dass selbst bei minimalen Anfragen ein Abo notwendig ist. Die besten Ergebnisse habe ich tatsächlich mit ChatGPT erzielen können. Obwohl die Antworten auch teilweise widersprüchlich oder redundant waren.
Wer die Idee hat, mit einem der freien KI Modelle eine lokale Instanz zum Beispiel mit LM Studio aufzusetzen und dafür eine sündhaft teure Grafikkarte kauft, dem sei gesagt: Das Geld kann man sich sparen. Die frei verfügbaren Modelle sind bei weitem nicht so leistungsfähig, wie ihre kommerziellen Versionen. Es wäre auch nicht gerade geschäftsfördernd, sich seine eigene Konkurrenz zu etablieren. Es stellt sich daher die Frage, wann es tatsächlich Sinn ergibt, mit KI Programmiermodellen zu arbeiten, um wirklich eine Beschleunigung des eigenen Outputs zu erfahren. Meiner Erfahrung nach geht es weniger um das Was oder Womit, sondern um das Wie. Dazu brauchen wir ein paar wichtige Abgrenzungen.
Ein K. I. Agent der direkt in die IDE eingebunden ist und alle Freiheiten hat, ist keine gute Idee. Oft hört man, dass diese K. I. Dinge tut, die sie nicht tun sollte, und Anweisungen, die Aktivitäten einzustellen, haben wenig Auswirkung. Wer es dennoch unbedingt versuchen möchte, ist sehr gut beraten, ein sauberes Branch Modell mit entsprechenden Zugriffseinschränkungen für den Agenten zu etablieren. Obwohl ich in kommerziellen Entwicklungsteams Pull Requests ablehne, ist diese Strategie beim Einsatz von K. I. Agenten unabdingbar. Auch der Zugriff auf die Build Logik wie zum Beispiel die Maven POM oder Gradle Projektdatei ist für die Agenten tabu. Es gilt auch hier der bewährte Sicherheitsansatz: So wenig wie möglich, so viel wie nötig. Die Sperrung der Build Logik verhindert, dass der K. I. Agent beliebig nach Gutdünken eine eigene Version von Abhängigkeiten definieren kann.
Auch ist darauf zu achten, dass die Codeänderungen überschaubar bleiben und iterativ vonstattengehen. Obwohl es etwas holprig erscheinen mag, nutze ich K. I. um Funktionen oder Klassen zu generieren. Die vorgeschlagenen Codefragmente kopiere ich dann in meine IDE und schaue zeilenweise durch, was mir da vorgeschlagen wird. Entsprechend meinen Qualitätskriterien modifiziere ich dann den Code und prüfe über selbsterstellte Testfälle, ob alles so funktioniert, wie ich es beabsichtige. Die Generierung umfangreicher Testdaten für Lattests ist ein ideales Beispiel dafür, welche Aufgaben man problemlos an K. I. übergeben kann und auch sollte. Natürlich ist es unverzichtbar, stetig die Testqualität zu monitoren, wozu die Testabdeckung ein wichtiger Indikator ist. Auch wenn der gerade beschriebene Ansatz etwas mehr Zeit kostet, hat er mehr Vorteile gegenüber den schnellen Lösungen. Ich bin in der Lage, die Codeänderungen zu verstehen, und kann sie den entsprechenden Anforderungen zuordnen. Ein weiterer nicht zu unterschätzender Faktor ist, dass diese Methode dafür sorgt, dass ich meine Programmierfähigkeiten weiterentwickle. Schnelles Überfliegen und unreflektiertes Akzeptieren der vorgeschlagenen Lösung sorgen eher dafür, dass meine Fähigkeiten über einen längeren Zeitraum verkümmern und dadurch auch meine Performance kontinuierlich sinkt. Dadurch wird sich der Arbeitsplatz langfristig nicht sichern lassen.
Das bringt mich auch gleich zu einem weiteren Punkt im Umgang mit LLM. Wie kann man effiziente Prompts, also Arbeitsanweisungen an das Modell, formulieren? Da die Kommunikation mit dem Modell über natürliche Sprache erfolgt, ist es notwendig, die eigenen Gedanken gut zu strukturieren, um sie dann auch verständlich formulieren zu können. Es ist also nicht förderlich, einen Kurs für Promptengineering zu besuchen. Wenn er oder sie die eigenen Ideen und Vorstellungen anderen Menschen nicht sauber vermitteln kann, wird mit K. I. ebenfalls wenig Erfolge erzielen. Worauf kommt es also wirklich an? Die Antwort ist fast so einfach, dass man sie übersehen kann. Klare Kommunikation mit prägnanten, kurzen und verständlichen Sätzen. Keine komplizierten Verschachtelungen, um das eigene Ego zu befriedigen. Natürlich benötigt man auch eine konkrete – zu Ende gedachte – Vorstellung von dem, was man erwartet. Vage Formulierungen können (zu viel) Raum für Interpretation lassen. Wer seine Absichten einem Vorschulkind in wenigen Minuten erklären kann, wird auch mit K. I. gute Ergebnisse erzielen. Damit möchte ich es auch belassen und einen weiteren Aspekt diskutieren.
Oft werde ich gefragt, wie ich die Qualität der durch LLM generierten Quelltexte beurteile. Hier ist die Antwort nicht so einfach. Denn es gibt verschiedene Kriterien, auf die es zu achten gilt. Alles, was UI betrifft, ist ein eigenes Kapitel. Denn UI / UX unterliegt Modeerscheinungen und hat gegenüber der Geschäftslogik eine höhere Änderungsfrequenz. In meinen Schulungen zu Java Testautomatisierung rate ich insbesondere komplett von der Erstellung von UI Tests ab. Der Grund ist, dass in diesem Bereich der Kosten Nutzen Faktor einfach nicht ausgewogen genug ist. Das bedeutet für generierten UI-Code, dass ich lediglich die Funktion und Optik anschaue und es dabei belasse. Bei der Geschäftslogik für Backendsysteme ist die Situation eine völlig andere. Hier habe ich festgestellt, dass der durch LLM produzierte Code in Aspekten der Sicherheit teilweise besser ist als der von so manchem Programmierer. Die üblichen Prüfpunkte wie SQL Parameter, Eingabevalidierung und Filterung werden berücksichtigt und umgesetzt. In den Bereichen Performance und Lesbarkeit beziehungsweise Verständlichkeit ist allerdings noch Luft nach oben. Hier erwarte ich in circa zwei weiteren Iterationen erhebliche Verbesserungen. Das ist auch ein markanter Grund, wieso LLM Optimierungen einer bestehenden Codebasis nie abgeschlossen sind und bei jeder neuen Generation von LLM erneut durchgeführt werden sollten.
Mein stärkster Kritikpunkt gegenüber Unternehmen, aber auch Entwicklern und Administratoren, die exzessiv LLM in ihren täglichen Projekten einsetzen, ist, dass diese schnell die Kontrolle über ihre Produkte/Dienstleistungen verlieren könnten. Das gesamte Thema lässt sich nicht in Schwarz oder Weiß einteilen, denn die Menge an Variationen der Zwischentöne ist zu umfangreich. Deswegen ist es an uns, dem Motto der literarischen Aufklärung nach Immanuel Kant – habe Mut, dich deines eigenen Verstandes zu bedienen – zu folgen.
Abschließend möchte ich noch den Kostenfaktor für leistungsfähige KI Modelle besprechen. Denn hier kann es schnell zu bösen Überraschungen kommen. Gehen wir einmal davon aus, wir haben eine Person mit einer tollen Startupidee, die auch die Fähigkeit hat, korrekte und sinnvolle Anforderungen verständlich zu formulieren. Im besten Fall sind sogar rudimentäre Programmierfähigkeiten vorhanden, um Quelltext lesen, verstehen und leicht modifizieren zu können. Diese Person entschließt sich, nur die Idee eigenständig ohne Programmierer umzusetzen. Selbst wenn man das Projekt in kleine Stücke zerlegt und diese Projekte an Freelancer vergibt, kommen schnell ein paar tausend Euro zusammen, je nach Umfang der Arbeitspakete. Verteilt man nun diese Aufgaben an KI Agenten, greifen die üblichen Tarife von 20 bis 50 Euro monatlich nicht mehr. Es wird eine tokenbasierte Abrechnung notwendig. Je nach Umfang des Prompts verbraucht dann eine Anfrage an die KI ein bis mehrere Token. Ein Token hat oft den Wert von einem Euro / US Dollar. Setzt man hier kein Limit, können in wenigen Stunden mehrere tausend Euro verbraucht sein. Zudem kann man vorher auch nicht sagen, wie gut der generierte Quelltext sein wird, den man erhält. Denn jede Nachbesserung kostet wiederum Token, die zu bezahlen sind. Ein Kostenfaktor, der bei Menschen so in der Form nicht entsteht. Auch wenn KI Agenten auf den ersten Blick keine Sozialversicherung und ähnliche Kosten verursachen, bedeutet es nicht, dass man günstigere Projekte umsetzen kann. Wichtiger ist, jemanden im Boot zu haben, der weiß, wie man Quelltext so strukturiert, dass dieser auch problemlos später erweitert werden kann.
Die Feuerwand (engl. Firewall), war zu Zeiten des Zirkus und der Schausteller immer ein spektakuläres Ereignis. Menschen oder Tiere sprangen hindurch und wurden von der Menge bejubelt. So pathetisch eine solche Vorführung auch immer auf die Zuschauer wirkte, so kalkulierbar war das Spektakel für den Akrobaten. Denn wir wissen, dass Feuer eines der gewaltigsten Urelemente ist, das durch die Menschheit bezwungen wurde.
In der Cybersecurity ist die Firewall einer der elementarsten Schutzmechanismen für vernetzte Computersysteme. Das gilt sowohl für den Heimcomputer, als auch für den Großrechner im Rechenzentrum. Allerdings ist die Vorstellung, einen oder mehrere Feuerringe um den Computer zu entzünden, eher vergleichbar mit einem Zirkusspektakel, das gern melodramatisch in Kinofilmen aufgegriffen wird. Aussagen wie „Die erste Firewall ist gefallen und die zweite bereits zu 70 % überwunden“, sind perfekt für die Leinwand, haben mit der Realität aber nichts gemein.
Bevor wir in die Details gehen, betrachten wir kurz, wie Computersysteme miteinander zu einem Netzwerk verbunden werden. Das entscheidende Detail, welches wir benötigen, lautet IP Adresse. Allgemein ausgedrückt ist die IP Adresse die Telefonnummer des Computers beziehungsweise des Gerätes im Netzwerk. Damit man sich also mit einem anderen Computer verbinden kann, muss man dessen IP-Adresse kennen. Analog wie beim Telefon und der Telefonnummer. Wenn die Verbindung dann steht, kann man Informationen, also Daten, zwischen diesen beiden Geräten austauschen. Diese Informationen werden von den verschiedenen Internetprotokollen in kleine, handhabbare Pakete zerlegt. Ein Protokoll ist eine festgelegte Ablaufsteuerung, an die sich alle Teilnehmer halten müssen. Das lässt sich problemlos mit dem Versenden eines Briefes oder Päckchens mit der Post vergleichen.
Schreibe den Brief
Packe den Brief in einen Umschlag und klebe den Umschlag zu.
Schreibe die Empfängeradresse auf die Vorderseite des Umschlages.
Schreibe den Absender auf die Rückseite des Umschlages.
Klebe eine ausreichende Briefmarke auf den Umschlag und werfe ihn in den Briefkasten.
Ohne zu wissen, wie die internen Abläufe der Post sind, können wir davon ausgehen, dass der Brief beim Empfänger ankommt, wenn wir das Protokoll korrekt einhalten. Genauso verhält es sich mit dem Internet. Je nach der Art der Daten wählt der Computer ein geeignetes Programm aus, welches das zu verwendende Protokoll für uns umsetzt. Basierend auf dem Internet Protokoll (IP) welches die Verbindung zwischen Computern für uns regelt, gibt es weitere Protokolle, die sich um die Daten kümmern. Bekannte Protokolle sind HTTP(s) für Internetseiten oder FTP, um Dateien zu versenden.
Kommen wir nun zum eigentlichen Thema. Was also ist eine Firewall überhaupt und wozu wird sie verwendet? Stellen wir uns am besten einen sehr langen Flur vor mit unzählig vielen Türen, genauer gesagt 65.536 Türen. Diese Türen kann man nach innen oder außen öffnen. Wir können also aus dem Flur nach außen (outgoing Traffic) gelangen oder von außen in den Flur hinein (incoming Traffic).
Ein Browser Game, mit freundlicher Genehmigung von (c) mediasinres.tv
Diese Türen nennt man in Fachchinesisch Ports, die eine festdefinierte Nummer haben. Installiert man nun auf dem Rechner spezielle Programme, die mit anderen Computern kommunizieren können, wird dieses Programm üblicherweise fest an solch einen Port gebunden. Dazu ein kleines Beispiel. Lange vor WhatsApp und Co. gab es den Internet Relay Chat, kurz IRC. Hat man auf seinem Computer den IRC installiert, so hat sich dieser hinter der Tür 194 verborgen. Eine wichtige Eigenschaft zu Ports ist auch, dass, wenn bereits ein Programm an einen Port gebunden ist, kein anderes Programm diesen Port benutzen kann.
Mit einer Firewall kann man nun diese Türen in das Internet und aus dem Internet sehr gezielt blockieren. Grundsätzlich bestehen vier verschiedene Optionen für eine Tür zur Auswahl:
Vollständig blockiert,
Eingang blockiert,
Ausgang blockiert und
Vollständig offen.
Greifen wir dazu wieder unser Beispiel IRC auf. Ist die Tür vollständig blockiert, können wir keine Nachrichten senden oder empfangen, obwohl sich das Programm auf unserem Computer starten lässt. Es kann also keine Verbindung in das Netzwerk aufbauen. Ist der Eingang blockiert, können wir keine Nachrichten empfangen, aber senden. Ist der Ausgang blockiert, empfangen wir Nachrichten, können aber selbst keine senden. Die letzte Option hat keinerlei Einschränkungen.
Das größte Problem bei der Benutzung von Firewalls ist, dass diese oft nicht korrekt eingestellt (konfiguriert) sind. Hier unterscheiden wir zwei Möglichkeiten. Die verbreitetste Variante nennt sich Blacklist und reguliert nur die in der Liste angegebenen Ports. Wenn wir uns überlegen, dass es 65 536 Ports gibt, kann das eine sehr lange und unübersichtliche Liste werden. Das Risiko, etwas zu vergessen, ist hier sehr hoch. Der Vorteil dieser Option ist, dass sie sehr robust für unerfahrene Nutzer ist. Die andere Option ist die sogenannte Whitelist. Die funktioniert exakt entgegengesetzt der Blacklist. Per se sind nun erst einmal alle Ports geschlossen und der Nutzer muss explizit angeben, welche Ports geöffnet werden dürfen. Wie man sich jetzt leicht vorstellen kann, erfordert der Betriebsmodus Whitelist einiges an Erfahrung des Nutzers. Man muss wissen, welcher Port zu welchem Programm gehört und wie man diese Regeln in der Firewall einträgt.
Wie wir sehen, ist die Vorstellung, einen Feuerring um den Computer zu ziehen, keine geeignete Vorstellung davon, wie eine Firewall funktioniert. Wenn die Tür, also auf dem Computer, einmal blockiert ist, macht es auch wenig Sinn, noch eine andere Firewall auf dem Computer zu installieren. In diesem Fall gilt der Spruch „Doppelt hält besser“ nicht.
Angriffe auf Firewalls sind üblicherweise das Suchen nach offenen Türen, in die man dann eindringt. Dazu bedient man sich sogenannter Portscanner. Wer einmal einen solchen Protscanner ausprobieren möchte, darf das nicht so ohne Weiteres tun. Denn die Suche nach offenen Ports auf fremden Computern ist in Deutschland und vielen anderen Teilen der Welt bereits strafbar.
Ein anderes sehr fortgeschrittenes Angriffsszenario ist eine Attacke auf das Firewallprogramm selbst. Hier versucht man, mögliche vorhandene Programmierfehler der Firewall zu finden und auszunutzen.
Firewalls gibt es für jedes Betriebssystem in den verschiedensten Variationen. In professionellen Netzwerkgeräten wie Routern und Switches können bereits auch Firewalls integriert sein. Hier agiert der Router als Netzwerkcomputer und schützt alle an den Router angeschlossenen Geräte. Bevor man sich für ein konkretes Programm entscheidet, sollte man in Erfahrung bringen, dass es möglichst leicht zu bedienen ist und von einem seriösen Hersteller kommt.
Liste (unvollständig) der bekanntesten Standardports:
Photobomb ist eine Linux-Maschine für Einsteiger, die praktische Erfahrungen im Bereich Cybersicherheit ermöglicht. Mit dieser Konfiguration können Benutzer ihre Fähigkeiten im Identifizieren und Ausnutzen gängiger Sicherheitslücken anwenden, wobei der Fokus auf Authentifizierung, dem Umgang mit Anmeldeinformationen und der Untersuchung von Webanwendungsfunktionen liegt. Zusätzlich bietet sie die Möglichkeit, Techniken zur Rechteausweitung durch Systemskriptkonfigurationen zu erforschen. Diese Maschine bietet eine realistische und sichere Umgebung zum Erlernen von Cybersicherheit und Penetrationstests.
Reconnaissance
Ich begann mit einem Scan aller offenen TCP-Ports der Maschine mithilfe des folgenden Befehls:
> nmap -p- -sS --min-rate 5000 --open -vvv -n -Pn 10.10.11.182 -oG allPortsHostdiscoverydisabled (-Pn). All addresses will be marked 'up' and scan times may be slowerStartingNmap7.94 ( https://nmap.org ) at 2023-12-09 11:31 CSTInitiatingSYNStealthScanat11:31Scanning10.10.11.182 [65535 ports]Discoveredopenport22/tcpon10.10.11.182Discoveredopenport80/tcpon10.10.11.182CompletedSYNStealthScanat11:31,23.71selapsed (65535 totalports)Nmapscanreportfor10.10.11.182Hostisup,receiveduser-set (0.45s latency).Scannedat2023-12-0911:31:17CSTfor24sNotshown:35879closedtcpports (reset), 29654 filtered tcp ports (no-response) Some closed ports may be reported as filtered due to --defeat-rst-ratelimitPORTSTATESERVICEREASON22/tcpopensshsyn-ackttl6380/tcpopenhttpsyn-ackttl63Readdatafilesfrom:/usr/bin/../share/nmapNmapdone:1IPaddress (1 hostup) scanned in 23.93 secondsRawpacketssent:114608 (5.043MB) |Rcvd:36317 (1.453MB)
Anschließend habe ich das Skript extractPorts verwendet, um offene Ports in die Zwischenablage zu kopieren. Danach habe ich mit diesen neuen Informationen einen zweiten nmap-Scan durchgeführt:
Zur besseren Visualisierung nutzte ich bat (ein Alias für cat) mit dem Parameter -l, um die Ausgabe wie Java-Code hervorzuheben. Der Scan ergab, dass die TCP-Ports 22 (häufig für SSH verwendet) und 80 (was auf einen Webserver mit nginx hindeutet) geöffnet waren. Die Erwähnung von „Ubuntu“ in den Ergebnissen ließ auf ein Linux-System schließen.
Der Aufruf von http://10.10.11.182 leitete zu http://photobomb.htb weiter, die Seite war jedoch aufgrund von Virtual Hosting nicht erreichbar. Um das Problem zu beheben, habe ich einen Eintrag mit der IP-Adresse und der Domain in der Datei /etc/hosts hinzugefügt.
# Static table lookup for hostnames.# See hosts(5) for details.# IPV4127.0.0.1localhost127.0.0.1hack4u.localhosthack4u127.0.0.1hack4u.localdomainhack4u10.10.11.182photobomb.htb# <- this is the entry we have to add #IPV6::1 localhostip6-localhostip6-loopbackff02::1ip6-allnodesff02::2ip6-allrouters
Nach dieser Anpassung wurde die Website nach dem Aktualisieren des Browsers angezeigt. Beim Erkunden der Website stieß man auf ein Authentifizierungsformular, das durch Anklicken von „Hier klicken!“ aufgerufen werden konnte.
Bei der Überprüfung des Quellcodes (STRG+U) zeigte sich, dass dieser größtenteils aus einfachem HTML bestand, mit Verweisen auf ein CSS-Stylesheet und eine JavaScript-Datei namens photobomb.js.
<!DOCTYPEhtml><html><head><title>Photobomb</title><linktype="text/css"rel="stylesheet"href-"styles.css"media="all"/><scriptsre="photobomb.Js"></script></head><body><divid="container"><header><hl><ahref-"/">Photobomb</a></h1></header><article><h2>Welcome to your new Photobomb franchise!</h2><p>You will soon be making an amazing income selling premium photographic gifts.</p><p>This state of-the-art web application is your gateway to this fantastic new life. Your wish is its command.</p><p>To get started, please <ahref-"/printer"class-"creds">click here!</a> (the credentials are in your welcome pack) .</p><p>If you have any problems with your printer, please call our Technical Support team on 4 4283 77468377.</p></article></div></body></html>
Die Untersuchung des photobomb.js-Skripts ergab ein Datenleck.
functioninit(){// Jameson: pre-populate creds for tech support as they keep forgetting them and emailing me if (document.cookie.match(/”(.*;)?\s*isPhotoBombTechSupport\s*=\s*[~:}+(=¥)75/)) { document.getElement sByClassName('creds')[0].setAttribute('href',('http://pHOt0:bOMb! @photobomb.htb/printer'); }} window.onload=init;
Ich habe diese Zugangsdaten für eine mögliche zukünftige Verwendung gespeichert.
Exploitation
Mithilfe der gefundenen Zugangsdaten griff ich über das Authentifizierungsformular auf die Website zu. Die Website bot die Möglichkeit, ein Bild, ein Format und eine Größe zum Herunterladen auszuwählen. Ich fragte mich, wie die HTTP-Anfrage aufgebaut war.
Mithilfe von Burp Suite habe ich die Anfrage abgefangen und zur Bearbeitung an den Repeater weitergeleitet.
Die HTTP-500-Fehlermeldung (Interner Serverfehler) deutete auf eine mögliche Code-Injection hin. Um dies auszunutzen, erstellte ich einen URL-codierten Reverse-Shell-Einzeiler:
wobei ich IP-Adresse und Port durch meine Listener-Konfiguration ersetzte.
Durch das Einrichten eines netcat Listeners auf dem vorgesehenen Port und das Senden der modifizierten Anfrage über Burp Suite konnte eine erfolgreiche Reverse-Shell-Verbindung hergestellt werden.
Für ein besseres Terminalerlebnis habe ich ein TTY-Upgrade durchgeführt.
Privilege Escalation
Die Untersuchung potenzieller sudo-Berechtigungen mit
sudo -l revealed a script, /opt/cleanup.sh
das ohne Passwort ausgeführt werden konnte.
Das im folgenden Bild dargestellte Skript enthielt eine Zeile, die mit „find“ (nicht /usr/bin/find) begann, wodurch ich die PATH-Variable ausnutzen konnte. Ich erstellte eine Datei namens „find“, die „sh“ enthielt, um den Ausführungspfad des Skripts zu manipulieren.
Ich habe das Skript mit einem geänderten PATH ausgeführt, wodurch mein „find“-Skript anstelle der beabsichtigten Binärdatei ausgeführt wurde:
sudo PATH=$PWD:$PATH /opt/cleanup.sh
Dadurch erhielt ich eine Shell mit Root-Rechten, wie im letzten Bild zu sehen ist, wo ich auf die Root-Flag zugreifen konnte.
Fazit
Die Photobomb-Maschine bot eine umfassende Lernerfahrung im Bereich Web-Exploitation und Rechteausweitung. Durch methodische Aufklärung, Code-Injection und geschickte Manipulation von Systemkonfigurationen erlangte ich sowohl Benutzer- als auch Root-Zugriff. Diese Übung verdeutlichte die Wichtigkeit gründlicher Systemprüfungen und die potenziellen Gefahren übersehener Schwachstellen.
Für Entwickler ist das Thema Datenbanken ein Bereich der Anwendungsentwicklung, den man nicht auf die leichte Schulter nehmen sollte. In diesem Artikel widme ich mich der Frage, was geeignete Primärschlüssel für relationale Datenbanken wie MySQL oder PostgreSQL sein können. Doch bevor ich mich auf die technischen Details stürze, möchte ich kurz ein Szenario beschreiben, mit dem ich vor einer Weile wieder einmal konfrontiert wurde.
Für einen Auftrag sollte ich ein Shopsystem migrieren. Da dieses System bereits über 10 Jahre im produktiven Einsatz war, ging es nun darum, auf eine neue Majorversion zu aktualisieren. Da wir bereits 3 Major-Releases im Rückstand zur aktuellen Version waren, haben wir uns entschieden, diese Gelegenheit zu nutzen, auch einige Altlasten loszuwerden. Es sollte sozusagen ein neuer Shop mit neuem Design und aktualisierter Funktionalität so weit neu aufgesetzt werden, dass dann die vorhandenen Artikel, Bestellungen und natürlich auch Kundendaten auf den neuen Shop importiert werden. Soweit erst einmal ein klassischer Routineauftrag.
Die Komplikation entstand durch den Umstand, das natürlich das alte System so lange im Betrieb bleiben musste, bis es nahtlos durch die neue Version ersetzt werden konnte. Wie es nun auch immer so ist, entwickelt sich Software weiter. So gab es in der neuen Version auch erhebliche Veränderungen, die ein direktes Datenmapping verkomplizierten. Im Konkreten ging es darum, wie intern die Artikelattribute gespeichert werden. Das heißt, wenn wir zum Beispiel T Shirts verkaufen, dann gibt es möglicherweise ein Modell aus Baumwolle, in weißer Farbe mit V-Ausschnitt in unterschiedlichen Größen. Jetzt wird man bei der Katalogauswahl in der Shopdarstellung nicht jedes einzelne Shirt in seiner Größe präsentieren. Vielmehr gibt es bei dem Artikel dann eine Auswahlbox mit den verschiedenen Größen. Diese Artikeleigenschaften können je nach Shop durchaus extrem komplex werden.
Mittlerweile gibt es sehr leistungsfähige Werkzeuge, die nicht gleich den Preis eines Mittelklassewagens haben, um zwischen den Versionen des Datenbankschemas ein Mapping zu definieren und die Daten dann automatisiert in die neue Version zu übernehmen. Das Ganze wird dann zu einem sogenannten ‚Höllenritt‘, wenn die Primärschlüssel als generische Auto-Increment erzeugt werden. Das alte System bleibt ja weiter aktiv und erzeugt permanent neue Primärschlüssel, die möglicherweise im neuen System bereits vergeben sind. Diesen Effekt versucht man durch sogenannte Freezes zu minimieren. Das bedeutet, der Shopbetreiber kann, solange die Migration nicht abgeschlossen ist, keine neuen Artikel im Shop aufnehmen und auch bestehende Artikeleigenschaften nur unter sehr eingeschränkten Bedingungen ändern.
Damit die Datenmigration einerseits leichter wird, aber andererseits auch weniger fehleranfällig ist, ist es in kommerziellen Umgebungen eher verpönt, auto increment für die Generierung des Primärschlüssels zu nutzen. Professionelle Datenbankmanagementsysteme (DBMS) wie Oracle und PostgreSQL können sogar nicht ohne Weiteres ein auto increment erstellen. Will man das dennoch nutzen, ist das meist über das Persistenzframework implementiert und nicht wie bei MySQL oder MariaDB eine Funktion im SQL.
Woher kommt überhaupt die Idee, einen solchen generischen Primärschlüssel zu nutzen? Sicher ist es ein sehr einfacher Mechanismus, der durchaus bewährt ist und gut in der Praxis funktioniert. Jedenfalls solange man nicht die Absicht hat eine Migration durchzuführen. Ein anderer Aspekt ist natürlich historisch bedingt, als Festplattenspeicher nocht teuer war und nicht so üppig verfügbar war wie heute. Damals zählte noch jedes einzelne Bit, das man sparen konnte. Diese Argument wird durch den verfügbaren günstigen Speicher entkräftet. Im Gegenteil, die Nachteile, die man sich im Bereich Wartung für ein paar eingesparte Megabyte erkauft, wichten sogar mehr.
Was sind demzufolge gut geeignete Primärschlüssel für Datensätze in relationalen Datenbanken? Hier unterscheiden wir in zwei Kategorien: natürliche und generierte Schlüssel. Da der Primärschlüssel eineindeutig sein muss und daher nicht zweimal vorkommen darf, gibt es wenig natürliche Kandidaten. Das klassische Beispiel für einen Nutzeraccount als Primärschlüssel ist die E-Mail. Auch die Telefonnummer hat die gewünschte Eigenschaft.
Automatisch generierte Primärschlüssel sind unter anderem der bereits beschriebene Auto Increment, den wir besser vermeiden sollten. Stadessen sollte man besser auf den Universal Unique Identifier, kurz UUID, zurückgreifen. Alle Programmiersprachen haben dazu eine Implementierung. Allerdings gibt es mittlerweile mehrere Versionen der UUID. Nicht allzulang wurde Version 7 der UUID veröffentlicht. Daher schauen wir uns die Eigenschaften der jeweiligen Versionen einmal genauer an. Die KI Grok stellt die Versionen wie folgt dar.
Version 1 (Time-based, RFC 4122/9562):
Kombiniert einen hochpräzisen Timestamp (60 Bit, 100-Nanosekunden-Intervalle seit 15.10.1582), eine 14-Bit-Clock-Sequence (gegen Rückwärtsdrehen der Uhr) und eine 48-Bit-Node-ID (meist MAC-Adresse des Rechners).
Nachteil: Die MAC-Adresse kann die Hardware verraten (Datenschutz). Die Sortierung ist nicht optimal, weil die Timestamp-Bits nicht in zeitlicher Reihenfolge liegen.
Beleg: RFC 9562, Section 5.1.
Version 2 (DCE Security):
Ähnlich wie v1, aber mit zusätzlichen Feldern für POSIX UID/GID (Local Domain). Der Timestamp ist weniger präzise.
Status: Kaum verwendet, in den meisten Bibliotheken nicht implementiert und nur für sehr spezielle Legacy-DCE-Anwendungen gedacht.
Beleg: RFC 9562 erwähnt es als reserviert mit Verweis auf alte DCE-Spezifikationen.
Version 3 & 5 (Name-based):
Deterministisch: Aus einem Namespace und einem Namen wird per Hash (v3: MD5, v5: SHA-1) ein UUID erzeugt. Gleicher Input → gleicher UUID.
Unterschied: Nur der Hash-Algorithmus. MD5 ist gebrochen, SHA-1 gilt als schwach → v5 ist etwas besser, aber beide nicht für kryptografische Sicherheit geeignet.
Beleg: RFC 9562, Sections 5.3 und 5.5.
Version 4 (Random):
Die klassische „zufällige“ UUID. 122 Bit sind echt zufällig (oder kryptografisch sicher pseudo-zufällig). Keine Zeitinformation, keine Node-ID.
Vorteil: Maximale Unvorhersagbarkeit und Privatsphäre.
Nachteil: Nicht sortierbar → schlechtere Performance als Primärschlüssel in Datenbanken (Fragmentierung der Indexe).
Beleg: RFC 9562, Section 5.4 – gilt als sicherer Standard für viele Anwendungen.
Version 6 (Reordered Time-based, RFC 9562):
Technisch fast identisch mit v1 (gleicher Timestamp, gleiche Clock-Sequence, gleiche Node), aber die Bits des Timestamps sind neu angeordnet (most-significant zuerst).
Dadurch sind v6-UUIDs byteweise sortierbar nach Erstellungszeit – ideal für Datenbanken.
Empfehlung im RFC: Nur als Drop-in-Ersatz für bestehende v1-Systeme verwenden; ansonsten v7 bevorzugen.
Beleg: RFC 9562, Section 5.6 – „field-compatible version of UUIDv1“.
Version 7 (Unix Time-based, RFC 9562):
Moderne Variante: 48 Bit Unix-Timestamp in Millisekunden (seit 1970), gefolgt von 12 Bit „rand_a“ (kann für Sub-Millisekunden oder Counter verwendet werden) und 62 Bit „rand_b“ (Zufall).
Vorteile:
Sehr gut sortierbar (Zeit steht vorne).
Hohe Entropie (74 Bit random).
Keine MAC-Adresse → besserer Datenschutz.
Gut für verteilte Systeme und Datenbank-Indexes.
Der RFC empfiehlt explizit: „Implementations SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if possible.“
Beleg: RFC 9562, Section 5.7.
Die bisher verbreitetste Variante ist Version 4, die ich auch selbst nutze. Ein wichtiges Kriterium ist bereits aus den Hash Algorithmen bekannt. Bei Hash spricht man von Kollisionen, also wenn ein Hash auf zwei verschiedene Texte verweist. Ein ähnliches Problem haben wir bei der Generierung von UUIDs. Diese sollte im Produktivbetrieb auch bei großen Datenmengen nicht mehrfach erzeugt werden. Das würde einen Fehler im Datenbanksystem auslösen, da die Unique Bedingung verletzt wird. Problematischer ist die anschließende Fehlerbehandlung. Damit der Datensatz dennoch gespeichert werden kann, muss eine neue UIID erzeugt werden. Dieser Fall ist mir bei meiner bereits langjährigen Verwendung der UUID-Version 4 bisher nicht untergekommen.
Wieso sollte man nun auf UUID Version 7 zurückgreifen? Hier geht es um Sortierbarkeit. UUID 7 verspricht, dass neuere Einträge ein aufsteigendes Datum in den ersten Stellen berücksichtigen. Dadurch kann man ältere Einträge absteigend sortiert erkennen.
Um beispielsweise UUID 4 in Java zu benutzen, genügt der Aufruf UUID.randomUUID(). Der ORM Mapper Hibernate stellt über die Annotation @GeneratedValue auch andere Versionen der UUID bereit. Natürlich kann man auch zusätzliche Bibliotheken wie den uuid-creator unter der MIT Lizenz nutzen.
Damit soll es auch für heute genug sein. Ich hoffe, ich konnte mit diesem Artikel ein wenig Aufmerksamkeit in das Thema lenken und würde mcih sehr freuen, wenn es weitere Verbreitung findet.
Wer unter Linux ein Desktopprogramm nutzen möchte, ohne sein bestehendes System zu verändern, benötigt eine spezielle Umgebung, die in Fachkreisen Sandbox genannt wird. Natürlich kann man auch eine virtuelle Maschine mit VMWare oder dem freien VirtualBox von Oracle erstellen, die einen ganzen Computer samt Betriebssystem simuliert, und darin testweise Programme installieren, um zu sehen, wie diese sich verhalten. Diese Option verbraucht allerdings einiges an Ressourcen und ist auch ein wenig schwergewichtig.
Es gibt aber auch eine leichtgewichtigere Virtualisierungstechnologie unter Linux, die verschiedene Sicherheitsfunktionen anwendet, die unter Windows nicht verfügbar sind. Dazu gehört unter anderem das Berechtigungskonzept auf Datei- und Verzeichnisebene. Aber keine Sorge, wir steigen nicht zu tief in die vielen Details der einzelnen Lösungen ein, sondern kümmern uns vornehmlich um das Wie und Warum.
Auf der Serverseite gibt es bereits bewährte Virtualisierungsprogramme für abgegrenzte und sichere Umgebungen, wie beispielsweise LXC (Linux Container) und das vielbewährte Docker. Auf dem Desktop nutzt man eher Programme wie FireJail oder Bubblewarp um Programme mit grafischer Benutzeroberfläche in einem abgegrenzten Raum ausführen zu können. Bevor wir aber weiter in die Details des Wie vorstoßen, betrachten wir noch ein paar Szenarien, wieso der ganze Aufwand überhaupt sinnvoll sein kann.
Einer der ältesten Gründe für Sandboxing ist, eine Umgebung zu schaffen, dass man verschiedene Versionen einer Software zu Test- oder Entwicklungszwecken gleichzeitig installiert haben muss und die Installationsroutine das nicht zulässt. Typisches Verhalten ist dann, dass zuerst die alte Version einer Software deinstalliert wird, um die neue Version zu installieren, oder es wird einfach die vorhandene Version aktualisiert. Hier hilft das Einrichten einer Sandbox, also einer Spielwiese zum Ausprobieren.
Ein weiterer Grund, wieso man Sandboxen verwendet, ist, Programme aus Sicherheitsgründen zu isolieren. Hier ist das eigentliche Thema das Schützen der Privatsphäre. Man möchte verhindern, dass ein Programm auf andere Daten auf dem Computer Zugriff hat. Deshalb sprechen wir in diesem Kontext auch mehr von dem Errichten eines Gefängnisses (engl. jail). Der Klassiker, um den es hier geht, ist der Webbrowser. Meiner Meinung nach sehe ich für dieses Szenario eher das Smartphone als weitaus problematischer, wo dieser Datenabgriff durchaus für jeden User leicht zu beobachten ist. Ohne sarkastisch zu sein, beobachte ich aber regelmäßig Leute, die ihren Computer wie eine Festung ausbauen und alle Daten auf dem Smartphone sorglos in der Welt verteilen.
Das vor allem Webseiten der großen Techkonzerne alle möglichen Tricks einsetzen, um ihre Nutzer besser zu kennen, als diese sich selbst, ist in Fachkreisen ein offenes Geheimnis. Für Außenstehende wirken die Fachäußerungen oft unverständlich, was sich nicht selten in Resignation oder Gleichgültigkeit äußert. Um hier nicht zu tief in die Materie einzutauchen, möchte ich mit einem einfachen Beispiel aufzeigen, wie raffiniert die Möglichkeiten sind. Wer glaubt, dass eine VPN‑Verbindung der maximale Schutz der Privatsphäre darstellt, der unterliegt einem fatalen Irrtum. Nur weil man die eigene IP Adresse verschleiert, kann man dennoch Rückschlüsse auf auf den tatsächlichen Standort des Nutzers ziehen. Dazu muss man sich nicht einmal besonders anstrengen. Wer sich also angeblich aus Deutschland ins Internet einloggt, dessen Webbrowser aber als Spracheinstellung Russisch und als Zeitzone noch Moskau eingestellt hat, befindet sich vermutlich nicht in Deutschland. Natürlich greifen die Techkonzerne wie LinkedIn oder Facebook weitaus mehr Informationen zu ihren Nutzern ab. Jede einzelne Maßnahme mag isoliert eher trivial erscheinen, aber kombiniert man die verschiedenen Möglichkeiten, ändert sich die Situation grundlegend. Deswegen ist es absolut unerlässlich, Sicherheit als gesamtes Konzept zu denken.
Wir sehen, dass, um ein effizientes Gefängnis bauen zu können, durchaus viel mehr Spezialwissen und auch Erfahrung notwendig ist, als nur fix eine Software zu installieren. Ein Stichwort hierzu sei die Software AppAmor unter Linux. Zudem muss man sich auch im Klaren sein, dass, wenn man seinen Browser in eine Sandbox packt, dies auch Probleme mit sich bringt. Hier handelt es sich zum Beispiel um Zugriff auf Hardware wie Mikrofon und Kamera bei Videokonferenzen, oder das Herunterladen oder Hochladen von Dateien. Denn man hat ja den Browser vom Restsystem abgekoppelt und kann nun mal nicht eben schnell die Fotos auf Facebook posten. Wer also mit solchen Gedanken spielt, sollte sich die Zeit nehmen und diese Überlegungen auch zu Ende denken.
Nachdem ich sehr ausführlich das Warum erörtert habe, kommen wir nun zum Wie. Ich hatte bereits die beiden verbreitetsten Tools FireJail und BubbleWarp erwähnt. Da sich dieser Artikel an Power-User richtet, aber nicht an IT-Professionals mit Spezialwissen, steht für mich eine einfach benutzbare Lösung im Vordergrund. Deswegen fällt meine Wahl auf FireJail [1], das man zwar herunterladen und manuell installieren muss, dafür aber eine aktive Community besitzt und im Gegensatz zu BubbleWarp eine Dokumentation vorweisen kann.
Nach dem Download [2] von FireJail und FireTools für die entsprechende Distro können beide Programme auch leicht installiert werden. In meinem Fall handelt es sich um ein aktuelles Debian Linux, weswegen ich mir die deb Dateien von der Homepage geladen und diese mit einem einfachen Doppelklick problemlos über den Paketmanager installiert habe. Natürlich klappt das auch mit dem Standard-Paketmanager APT für Debian. Um allerdings aktuell zu bleiben, bevorzuge ich die erste Variante der Installation.
sudo apt-get install firejail firetool
ed:~$firejail--helpfirejailversion0.9.80FirejailisaSUIDsandboxprogramthatreducestheriskofsecuritybreachesbyrestrictingtherunningenvironmentofuntrustedapplicationsusingLinuxnamespaces.Usage:firejail [options] [program and arguments]
Über das Anwendungsmenü habe ich den Firejail-Configuration-Wizard gestartet.
Dadurch öffnet sich ein Wizard, mit dem Anwendungen als Sandbox konfiguriert werden. Dies unterscheidet sich von dem Konsolenbefehl insofern, das über die Kommandozeile alle durch FireJail unterstützten Programme in eine Sandbox gepackt werden. Das könnte allerdings die Funktionsweise so sehr einschränken, dass man damit die täglichen Aufgaben nicht mehr bearbeiten kann.
sudo firecfg
Damit kann man die Anwendungen in der Sandbox über die Icons des Windowmanagers-Menüs oder Dateiverlinkungen im Dateimanager starten. Diese automatisierte Variante unterstützt bisher die Desktop-Manager Mate, KDE, LXDE, Cinnamon und LXDE. Für Gnome3 und Unity gibt es nur rudimentäre Unterstützung. Es genügt ein Doppelklick auf das Desktopsymbol in Firetools oder auf der Bash der Befehl: firetools firefox. Alternativ kann auch FireTools gestartet werden. FirerTools ist ein grafischer Launcher für Anwendungen, die über FireJail in der Sandbox laufen.
In meinem Beispiel habe ich den Webbrowser Firefox über die von FireJail empfohlene deault Konfiguration eingerichtet. Es ist möglich, für jede installierte Anwendung entsprechende eigene Konfigurationen zu verwenden. Die zugehörigen Konfigurationsdateien befinden sich im Nutzerverzeichnis des angemedeten Users ~/.config/firejail/<app>.profile und /etc/firejail/<app>.profile.
# Firejail profile for firefox # Description: Safe and easy web browser from Mozilla # This file is overwritten after every install/update # Persistent local customizations include firefox.local # Persistent global definitions include globals.local
# Note: Sandboxing web browsers is as important as it is complex. Users might # be interested in creating custom profiles depending on the use case (e.g. one # for general browsing, another for banking, ...). Consult our FAQ/issue # tracker for more information. Here are a few links to get you going: # https://github.com/netblue30/firejail/wiki/Frequently-Asked-Questions#firefox-doesnt-open-in-a-new-sandbox-instead-it-opens-a-new-tab-in-an-existing-firefox-instance # https://github.com/netblue30/firejail/wiki/Frequently-Asked-Questions#how-do-i-run-two-instances-of-firefox # https://github.com/netblue30/firejail/issues/4206#issuecomment-824806968
# Note: Firefox requires a shell to launch on Arch and Fedora. # Add the next lines to firefox.local to enable private-bin. #private-bin bash,dbus-launch,dbus-send,env,firefox,sh,which #private-bin basename,bash,cat,dirname,expr,false,firefox,firefox-wayland,getenforce,ln,mkdir,pidof,restorecon,rm,rmdir,sed,sh,tclsh,true,uname private-etc firefox
Da die Konfiguration jeder einzelnen Anwendung schnell sehr komplex werden kann und man auch immer abwägen muss, was man mit einem Sandboxing erreichen möchte, verweise ich an dieser Stelle für weitere Informationen auf die Homepage [1].
Auf der Kommandozeile kann man sich sämtliche Anwendungen auflisten lassen, die aktuell über firejail gestartet wurden. Somit kann überprüft werden, ob die Sandbox für die entsprechende Anwendung funktioniert. Dazu stehen zwei Kommandos zur Verfügung: firejail –list und firejail –top. Der Parameter Top zeigt die Prozessauslastung in der Bash.
Eine Einschränkung habe ich bei meinem Test allerdings bemerkt: Besonders Browser in virtuellen Maschinen wollen unter Firejail nicht starten. Was natürlich auch etwas sinnfrei ist. Denn virtuelle Maschinen erzeugen bereits eine hervorragende Abschirmung der Anwendung zum Betriebssystem.
Fazit
Meiner Ansicht nach ist die Idee des Sandboxing durchaus reizvoll. Meine Kritik liegt eher an der Umsetzung. Ich würde das Thema Virtualisierung klassisch sehen, wie es beispielweise mit Docker oder PlayOnLinux umgesetzt wird. Eine Sandbox würde mir sozusagen im Desktop eine virtuelle Umgebung einrichten, in die ich isoliert Programme installieren kann, ohne dass dadurch das Betriebssystem verändert wird. Löscht man die Sandbox, so werden auch alle Dateien des installierten Programmes inklusive der Konfiguration rückstandslos entfernt. Die Funktionsweise von FireJail ist allerdings anders. FireJail erkennt unter den installierten Programmen, alle diejenigen, zu denen eine Jail-Konfiguration möglich ist, um diese in einem sogenannten Käfig auszuführen. Auch das Starten von AppImages in FireJail funktioniert in aller Regel nicht. Basierend auf meinen Erfahrungen im Thema Security und Penetration Testing bewerte ich den Kosten Nutzen Effekt speziell für FireJail als unzureichend und vertrete zudem die Meinung, dass die Art und Weise, wie FireJail arbeitet, den Anwendern ein falsches Gefühl von Sicherheit suggeriert. Denn ein Problem sind auch Updates, die oft vorgenommene sicherheitsrelevante Einstellungen wieder auf unerwünschte Standardeinstellungen unbemerkt zurücksetzen.
[EN] We use cookies to improve your experience on our site. By using our site, you consent to cookies.
[DE] Wir verwenden Cookies, um Ihre Erfahrungen auf unserer Website zu verbessern. Durch die Nutzung unserer Website stimmen Sie Cookies zu.
This website uses cookies
Websites store cookies to enhance functionality and personalise your experience. You can manage your preferences, but blocking some cookies may impact site performance and services.
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
These cookies are used for managing login functionality on this website.
Name
Description
Duration
wordpress_logged_in
Used to store logged-in users.
Persistent
wordpress_sec
Used to track the user across multiple sessions.
15 days
wordpress_test_cookie
Used to determine if cookies are enabled.
Session
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Matomo is an open-source web analytics platform that provides detailed insights into website traffic and user behavior.
![JCON 2022 [1]](https://elmar-dott.com/wp-content/uploads/2022-JCON-Mythos-Wiederverwendung.webp)
