Wer sich auf die System-Firewall und seine Fritzbox verlässt, um Angriffe abzuhalten, fährt vielleicht jahrelang gut damit. Das heißt aber nicht, dass der Rechner jemals sicher vor Angriffen war.

Auch Linux-Systeme bleiben nicht von kritischen Sicherheitslücken verschont [1]. Es lässt sich keineswegs ausschließen, dass solche Schwachstellen Schadsoftware wie Erpressungstrojanern Tür und Tor öffnen, auch wenn es bisher noch keine konkreten Fälle gibt.

Verbreitete falsche Vorstellungen, wie Angriffe auf Computersysteme ablaufen und wie man sie am besten abwehrt, führen einerseits leicht zu einem trügerischen Gefühl der Sicherheit – man verwendet ja Linux. Andererseits fehlen vielen Linux-Einsteigern die Kenntnisse darüber, welche Sicherheitsmaßnahmen das neue System bereitstellt.

Sichere Burg?

Computeranwendern fällt als Schutzmaßnahme gegen Eindringlinge aus dem Netz häufig zuerst der Begriff Firewall ein. Die Vorstellung, dass eine stabile Mauer um den Rechner Angreifer abwehrt, bildet jedoch die Realität nur oberflächlich ab: Um einen Schutzwall zu überwinden, schlägt der Angreifer Breschen. Angriffe auf Computer finden also häufig über Lücken im System statt.

Im Grunde genommen bildet eine Firewall eigentlich nur eine sekundäre Maßnahme, die die eigentlichen Lücken kaschiert. Darum deaktiviert der OpenSuse-Installer in der Standardeinstellung als primäre Sicherheitsmaßnahme alle Server-Dienste, die sich aus dem Netz ansprechen lassen. In dieser Systemkonfiguration passiert gar nichts, wenn Angreifer an der Netzwerkschnittstelle anklopfen. Software, die nicht läuft, lässt sich von außen nicht attackieren und antwortet auch nicht.

Halten wir fest: Der sicherste Zustand für Computersysteme liegt immer dann vor, wenn möglichst wenig Programme mit Daten aus dem Netzwerk in Berührung kommen. Das erreichen Sie unter Linux auf Systemebene, indem Sie nicht gebrauchte Dienste mit Netzwerkexposition abschalten (siehe Kasten “Netzwerkdienste”).

Abbildung 1: Das YaST-Verwaltungsmodul zeigt, dass es unter Linux ähnlich viele Hintergrunddienste gibt wie unter Windows. Allerdings handelt es sich bei den wenigsten um Server-Dienste, die auf Anfragen aus dem Internet reagieren.

Eine auf dem Rechner selbst laufende Personal Firewall bedeutet eine Anwendung mehr, die mit Daten aus dem Netz in Berührung kommt. Allerdings übernimmt unter Linux der Kernel das Filtern des Netzwerkverkehrs (Abbildung 2). Die in Anlehnung an ihre Windows-Pendants ebenfalls Firewall genannten Programme stellen unter Linux bloß ein handliches Frontend für die auf Experten zugeschnittene Kernel-Schnittstelle zur Verfügung [3]. Die Sicherheitsbilanz des Linux-Kernels fällt zum Glück besser aus als die so mancher Security-Software unter Windows.

Abbildung 2: Es kommt der Sicherheit unter Linux zugute, dass Firewall-Programme (hier das gleichnamige YaST-Modul) dort nur ein Frontend für die im Kernel integrierte Firewall bereitstellen und sich nach dem Senden der Einstellungen wieder beenden.

Das erklärt, warum OpenSuse nach einer Installation mit übernommenen Grundeinstellungen (Abbildung 3) die Firewall-Lösung Firewalld [4] aktiviert lässt, auch wenn sie ohne laufende Netzwerkdienste die Systemsicherheit eigentlich nicht erhöht. Sie springt aber dann ein, wenn eine Softwareinstallation einen potenziell riskanten Netzwerkdienst aktiviert oder ein Anwender unwissentlich eine gefährliche Konfiguration vornimmt. Die Firewall arbeitet so, dass sie mit Ausnahme des SSH-Dienstes alle Dienste von außerhalb des Rechners unsichtbar macht.

Abbildung 3: In der Standardeinstellung aktiviert der OpenSuse-Installer die Firewall und verzichtet auf das Aktivieren des SSH-Dienstes. Ein Klick auf die grünen Links genügt, um die konservative Vorauswahl zu ändern.

Allerdings kommen nicht nur Systemdienste mit dem Internet in Kontakt, sondern auch normale Desktop-Programme, allen voran der Webbrowser. Ein heutiger Browser versteht HTML, CSS, Javascript und einiges mehr. Er bindet das Mikrofon und die Webcam ein, nutzt die Grafikkarte als Beschleuniger und installiert Addons aus dem Internet nach (Abbildung 4). Dass er per GPU-Beschleunigung Zugriff auf den im Kernel mit maximalen Rechten laufenden Grafiktreiber erhält, erhöht das Gefährdungspotenzial noch einmal.

Abbildung 4: Addons in Firefox passen den Browser den Wünschen des Benutzers an, bergen aber immer auch das Risiko, unentdeckten Schadcode zu enthalten.

Die größte Verringerung der Angriffsfläche beim Browser erzielen Sie durch Deaktivieren von Javascript (Abbildung 5), das den Browser von einer reinen Anzeige-Engine zur Laufzeitumgebung für Webanwendungen macht. Die wenigsten Anwender möchten Javascript aber komplett abschalten und die Einstellung javascript.enabled auf der Einstellungsseite http://about:config auf false setzen, da zu viele Seiten sonst nicht mehr wie gewohnt funktionieren.

Abbildung 5: Javascript unter http://about:config in Firefox ganz zu deaktivieren wäre das Sicherste, schränkt aber das Surf-Erlebnis auf aktuellen Webseiten stark ein.

Dagegen bewährt sich das Addon Disable JavaScript [5]. In der Standardeinstellung startet es mit eingeschaltetem Scripting, erlaubt aber auch umgekehrt, Javascript erst nach expliziter Aktivierung zuzuschalten. Ein Knopf in der Symbolleiste aktiviert oder deaktiviert es für die aktuelle Domain. Eine Blacklist gestattet, Sites schon vor dem ersten Besuch zu entschärfen (Abbildung 6). Alternativ existiert ein reiterbezogener Modus, der einen gewählten Status für ein bestimmtes Tab beibehält.

Abbildung 6: Das Firefox-Addon Disable Javascript merkt sich die Domains, für die Sie Javascript ausschalten.

Die Hardwarebeschleunigung schalten Sie unter Einstellungen im Hamburger-Menü rechts oben in der Sparte Leistung ab. Zunächst gilt es, Empfohlene Leistungseinstellungen verwenden zu deaktivieren, dann die Option Hardwarebeschleunigung verwenden, wenn verfügbar. Komplexe Webseiten scrollen dann allerdings spürbar weniger glatt.

Schadensbegrenzung

Nicht mit Root-Privilegien laufende Anwendungen fehlen unter Linux die Rechte, Systemkomponenten zu überschreiben, also sie mit Malware zu infizieren. Allerdings dürfen Sie zum Beispiel Programme in den Ordner ~/.config/autostart/ eintragen, die bei jedem Hochfahren der grafischen Umgebung starten. Dabei könnte es sich um ein im Heimatverzeichnis abgelegtes Skript handeln, das sich entsprechend nach einem Reboot wieder aktiviert. Unter X11 können solche Schadprogramme Tastatureingaben abfangen, während unter Wayland nur noch die Anwendung mit Fokus Zugriff erhält.

Linux kennt einen Mechanismus, um das Starten von Programmen auf einer bestimmten Partition zu verbieten. Es liegt nahe, die meist nur für Daten genutzte Home-Partition und das für Benutzer beschreibbare Verzeichnis /tmp so zu schützen. Allerdings lassen sich dann dort abgelegte Skripte immer noch starten, wenn Sie sie der Shell als Parameter übergeben. So startet der Aufruf /bin/bash /home/user/skriptXYZ.sh das skriptXYZ.sh unabhängig von der aktivierten Noexec-Option.

Da das Blockieren der Programmausführung im Home aber in der Regel nur Steam-Anwender mit lokaler Wine-Installation beeinträchtigt und immerhin den Start von komplexerer Schadsoftware unterbindet, empfehlen wir dennoch, die mit Benutzerrechten beschreibbaren Partitionen /home und /tmp so zu schützen.

Bearbeiten Sie dazu die Datei /etc/fstab mit Root-Rechten, zum Beispiel mit dem Kommandozeileneditor Nano (Listing 1, erste Zeile). Suchen Sie die Zeilen mit /tmp und /home in der zweiten Spalte und fügen in der vierten Spalte nach der subvol-Option ,noexec an. Achten Sie darauf, dass die Anweisung ohne Leerzeichen auf das Komma folgt (Abbildung 7). Wenden Sie die Änderungen dann durch einen Remount an (letzte Zeile).

$ sudo nano /etc/fstab
[... Noexec-Flag setzen ...]
$ sudo mount -o remount /tmp/ /home/

Abbildung 7: Zwei kleine zusätzliche Einträge in der Datei /etc/fstab verhindern, dass sich im Heimatverzeichnis oder unter /tmp mit Benutzerrechten abgelegte Programmdateien starten lassen.

Mit Firejail [6] existiert zudem eine Lösung, um Programme in eine sogenannte Sandbox [7] zu sperren, die die Kommunikation mit anderen Programmen und vor allem das Schreiben auf die Festplatte beschränkt. Speziell beim Browser, dem im Internet exponierten Programm mit der größten Angriffsfläche, entspannt das die Sicherheitssituation. Installieren Sie dazu das Paket firejail und fügen Sie Ihr Benutzerkonto der Gruppe firejail hinzu (Listing 2). Melden Sie sich danach erneut am System an und starten Sie Firefox auf der Konsole durch Eingabe von firejail firefox. Jetzt besitzt das Programm nur noch Zugriff auf das Verzeichnis ~/Downloads/. Was immer Sie dort ablegen, es startet auf jeden Fall nicht unaufgefordert.

$ sudo usermod -a -G firejail User

Viele Programme lassen sich durch ein vorangestelltes firejail auf der Konsole ebenso absichern. Das Tool bringt etwa 1200 auf einzelne Programme zugeschnittene Profile mit, die zum Beispiel LibreOffice (firejail soffice) einen weitgehend ungehinderten Zugriff auf die Dateien im Home gewähren, damit es sich überhaupt sinnvoll nutzen lässt. Unter KDE macht es die Option Anwendung bearbeiten nach einem Rechtsklick auf das Firefox-Icon zum Kinderspiel, den Browser ohne Rückgriff auf die Konsole zu starten. Schreiben Sie im so geöffneten Dialog im Reiter Programm genau wie auf der Konsole firejail an den Beginn des Befehls zum Starten des Programms (Abbildung 8).

Abbildung 8: Um Firefox auch aus dem Startmenü in einer Sandbox zu starten, brauchen Sie wie auf der Konsole nur firejail vor den Programmaufruf zu schreiben.

Aus der Schusslinie

Auf den ersten Blick scheint ein E-Mail-Client weniger Angriffspotenzial zu bieten als ein Webbrowser. Das täuscht, denn das Programm bindet zur Anzeige von HTML-Mails eine vollständige Browser-Engine ein (Abbildung 9). Dieses Feature lässt sich aber abschalten: Thunderbird lässt Ihnen unter Ansicht | Nachrichteninhalt die Wahl zwischen Original HTML, dem weniger gefährlichen Vereinfachtes HTML und Reiner Text.

Abbildung 9: Mails sind bis heute ausschließlich als reiner Text standardisiert. Die bunten, in vielerlei Hinsicht problematischen HTML-Mails verdanken wir Microsoft.

Bei Gnome Evolution finden Sie die Option unter Bearbeiten | Einstellung in der Kategorie E-Mail-Einstellungen | HTML-Nachrichten. Ganz unten finden Sie für den HTML-Modus die sicherste Variante Immer als einfachen Text anzeigen, die selbst als reine HTML-Mails verschickte Nachrichten zu einfachem Text vereinfacht. KDE Kontakt führt die entsprechende Einstellung unter Einstellungen | KMail einrichten | Sicherheit Lesen.

Weniger prädestiniert als Einfallstor für Malware scheinen Programme, die ausschließlich lokal arbeiten. Doch E-Mail-Anhänge damit zu öffnen, ist ebenso gefährlich, als würde die Software selbst Daten aus dem Netz beziehen. Microsoft Word, an sich eine “harmlose” Textverarbeitung, erlangte durch die Unterstützung unsicherer Makros sogar den Status des größten Einfallstors für Schadsoftware in Firmen.

Hier verhält sich die LibreOffice-Ausgabe der aktuellen OpenSuse-Version weniger fahrlässig. Sie führt in der Standardeinstellung Makros nur dann aus, wenn sie eine vertrauenswürdige Signatur von einer allgemein (durch Firefox) akzeptierten Zertifizierungsstelle aufweisen oder in einem als vertrauenswürdig eingestuften Dateiordner starten (Abbildung 10). Jedoch schadet es in einer Mehrbenutzerumgebung nicht, wenn nur der Administrator in den Ordner schreiben darf, in dem zum Beispiel die Templates für Geschäftsvorgänge liegen.

Abbildung 10: Aktuelle LibreOffice-Versionen führen nicht mehr alle Makros aus, sondern per Voreinstellung nur noch solche mit gültiger Signatur oder aus einem speziell dafür festgelegten Verzeichnis.

Schadpotenzial

PDFs gelten landläufig nur als passive Dokumente – ebenfalls ein Irrtum. Der PDF-Standard umfasst auch Javascript für interaktive PDFs. Als nützlich erweisen sich Javascript-Funktionen beim Prüfen der Gültigkeit von Eingaben in Formulare oder bei PDFs, die Daten nach dem Ausfüllen per Knopfdruck an den Empfänger schicken.

Offensichtlich unterstützt unter Linux nur das zu KDE gehörige Okular (Abbildung 11) eingebetteten Scripting-Code. Abschalten lässt sich dieses Feature jedoch nicht. Wer in solchen Komfortfunktionen vor allem ein Gefährdungspotenzial sieht, sollte einen anderen PDF-Viewer verwenden.

Abbildung 11: Der PDF-Viewer Okular aus dem KDE-Umfeld unterstützt bei Weitem nicht den gesamten Umfang der PDF-Spezifikation. Gerade das sicherheitskritische Ausführen von eingebettetem Javascript setzt er jedoch um.

Auch unter Linux sollten Sie E-Mail-Attachments aus einer unbekannten Quelle nicht öffnen. Zwar verpuffen praktisch alle auf Windows-Systeme zugeschnittenen Angriffe unter Linux. Viele nach dem Schema last_holiday_jpg.exe benannte Dateien versuchen allerdings, mithilfe der Windows-Emulationsschicht Wine zu starten, die EXE-Dateien standardmäßig verknüpft.

Allerdings sehen Linux-Anwender die tatsächliche Dateiendung, und ob die Software unter Wine ihre konkrete Schadwirkung tatsächlich zu entfalten vermag, bleibt fraglich. Um zu unterbinden, dass Windows-EXEs per Klick starten, öffnen Sie in den KDE-Systemeinstellungen den Punkt Anwendungen. Dort suchen Sie in den Dateizuordnungen bei den Dateiendungen exe und x-ms-dos-executable nach dem zugeordneten Anwendungsprogramm Wine Windows-Programmstarter und löschen den Eintrag oder setzen ihn in der Reihenfolge nach unten. Auf der Konsole lassen sich die Windows-Executables immer noch mit wine Datei.exe ausführen.

Auf Linux zugeschnittene Exploits sind technisch keineswegs undenkbar: Präparierte PDFs könnten bei jedem Systemstart ausgeführte Skripte installieren, Anhänge könnten eine der regelmäßig auftretenden Schwachstellen in Bibliotheken und Anwendungen ausnutzen. Über diese Schwachstellen in C/C++-Programmen lässt sich im schlimmsten Falls durch Speicherkorruption Schadcode einschleusen und ausführen. Da der unter X bereits Zugriff auf Tastatur und Bildschirm erlangt, birgt ein solcher Exploit auch ohne Root-Rechte schon erhebliches Schadpotenzial. Außerdem könnte die Malware selbst mit Benutzerrechten alle Daten im Home löschen oder verschlüsseln.

Vermutlich hielt in der Vergangenheit nur die Tatsache, dass das Verhältnis zwischen Aufwand und Einnahmen bei Windows-Exploits günstiger ausfällt, Kriminelle davon ab, Linux-Desktops ins Visier zu nehmen. Das liegt zum einen an der relativ geringen Verbreitung von Linux und zum anderen daran, dass die Systeme meist auch inhomogener sind, womit sie sich nur selten mit demselben Exploit angreifen lassen. Welche Rolle die in der Open-Source-Welt meist schneller bereitstehenden Fixes tatsächlich in Bezug auf die Sicherheit spielen, lässt sich dagegen nur schwer einschätzen.

Sichere Schleuse

Die angesprochenen Speicherverwaltungsfehler in C- oder C++-Programmen sowie überlistbare Checks der Authentifizierung und viele weitere typische Programmierfehler erweisen sich bei mit Root-Rechten laufenden Systemdiensten als besonders gefährlich: Sie ermöglichen es Schadsoftware, beliebige Systemdateien zu verändern. Darum aktiviert der OpenSuse-Installer wie erwähnt den SSH-Dienst erst nach expliziter Anforderung und öffnet auch den zugehörigen Firewall-Port nur auf ausdrücklichen Wunsch.

Andererseits handelt es sich bei Linux nun einmal um ein netzwerktransparentes Mehrbenutzersystem, dessen Eigenschaft auch viele Linux-Anwender nutzen möchten. Immerhin hält SSH auf unzähligen Systemen mit kritischer Infrastruktur erfolgreich Angriffen stand. Das Absichern per Passwort gilt in der Server-Administration allerdings als unzureichend.

Möchten Sie einen SSH-Zugriff aus dem Internet auf Ihren Rechner ermöglichen, sollten Sie von der Authentifizierung per Benutzername und Passwort auf eine Authentifizierung per Schlüsseldatei umsteigen (siehe Kasten “SSH-Zugang aus dem Internet”). Dann ist ein Login nur noch mithilfe einer kleinen Datei und eines zusätzlichen Passworts möglich. Weder ein Verlust des Passworts noch der Schlüsseldatei allein gewähren dann einem Eindringling Einlass. Beim Verdacht, der Schlüssel könnte kompromittiert worden sein, lässt sich dieser leicht deaktivieren und durch einen neuen ersetzen.

Es bedarf nur weniger Kommandozeilenaufrufe, um ein schlüsselbasiertes SSH-Login einzurichten. Stellen Sie zunächst sicher, dass auf dem Rechner, dessen Login Sie absichern möchten, der SSH-Daemon läuft und die Firewall den SSH-Zugang nicht blockiert. Dafür melden Sie sich zunächst wie gewohnt per ssh User@Ziel-IP an. Die IP-Adresse eines Rechners finden Sie entweder über Ihren Internet-Router heraus oder indem Sie auf dem Rechner selbst ip a eingeben.

Schließen Sie dann die Verbindung mit exit und tippen Sie in die Konsole des lokalen Rechners cd ~/.ssh. Sollte das Verzeichnis nicht existieren, legen Sie es mit mkdir ~/.ssh an. Um den Lesezugriff einzuschränken, tippen Sie danach chmod 700 ~/.ssh. Nun führen Sie ssh-keygen aus (Abbildung 12). Damit legen Sie ein Schlüsselpaar an, das aus einem öffentlichen und einem privaten Key besteht.

Abbildung 12: Der Befehl ssh-keygen erzeugt eine persönliche Schlüsseldatei, die sich nach dem Übertragen auf einen Rechner per ssh-copy-id zur Remote-Anmeldung nutzen lässt.

Danach genügt es, wenn Sie ssh-copy-id User@Ziel-IP eingeben, um den öffentlichen Schlüssel auf dem Zielrechner zu installieren. Dabei fragt SSH nach dem Passwort für den angegebenen Nutzernamen, ganz wie bei der normalen passwortbasierten Authentifizierung. Heißt Ihr aktiver lokaler Benutzer-Account ebenso wie der auf dem Zielrechner, dürfen Sie den Nutzernamen bei der Anmeldung weglassen.

Ohne Hintereingang

Testen Sie nun das Login mit dem gerade installierten Schlüssel via ssh User@Ziel-IP. Statt der Aufforderung zur Eingabe eines Passworts erhalten Sie die Frage nach der passphrase for key xxx. Das zeigt, dass nun die Schlüsseldatei beim Login zum Einsatz kommt, nicht mehr das Benutzerkonto. Schlägt die schlüsselbasierte Anmeldung allerdings fehl, dann geht der Rechner zur passwortbasierten über. Ein Sicherheitsgewinn ergibt sich erst, wenn Sie diese Option abschalten.

Funktioniert das Login per Key, editieren Sie auf dem Zielrechner die Konfigurationsdatei /etc/ssh/sshd_config des SSH-Diensts. Darin suchen Sie die Parameter PasswordAuthentication sowie ChallengeResponseAuthentication und entfernen jeweils das Kommentarzeichen (#) am Anfang der Zeile. Dann setzen Sie die Parameterwerte nach dem Leerzeichen von yes auf no und speichern die Datei. Zu guter Letzt starten Sie den SSH-Server mit sudo systemctl restart sshd neu.

Wenn Sie sich nun abmelden, klappt das erneute Login nur noch von dem Rechner aus, auf dem sich die SSH-Schlüsseldatei befindet. Den Erfolg Ihrer Änderungen testen Sie mit der dreimaligen Eingabe eines falschen Passworts. Anstatt einer erneuten Aufforderung zur Passworteingabe erscheint jetzt die Meldung Permission denied (publickey).

Der einfachste Weg, den Zugang zu Ihrem Rechner für mehrere Geräte einzurichten, besteht darin, die beiden Dateien id_rsa und id_rsa.pub aus ~/.ssh/ an dieselbe Stelle auf einen anderen Rechner zu kopieren. Achten Sie darauf, ein eventuell manuell angelegtes .ssh-Verzeichnis noch mit chmod 700 für andere Anwender zu sperren, anderenfalls verweigert SSH aus Sicherheitsgründen den Dienst. Auch darf kein Unbefugter die Datei id_rsa zu Gesicht bekommen.

Prinzipiell stellt es kein Sicherheitsrisiko dar, einen Schlüssel auf mehrere Geräte zu verteilen. Wäre einer von mehreren gesonderten Schlüsseln samt Passphrase nach außen gedrungen, so könnte ihn der Angreifer ohnehin auf ein beliebiges Gerät kopieren. Auf dem Server lässt sich ein Schlüssel leicht löschen, was allerdings nicht garantiert, dass ein Angreifer nicht schon weitere Backdoors ins System integriert hat.

Beim Befehl ssh-copy-id geben Sie einen Benutzernamen an, was dazu führt, dass er im Home des entsprechenden Users den Schlüssel in der Datei ~/.ssh/authorized_keys einträgt. Das File enthält in der Regel mehrere Blöcke mit kryptischen Zeichenfolgen (Abbildung 13), die jeweils mit der Angabe User@Rechner für den Benutzer- und Rechnernamen enden, unter dem Sie den Schlüssel erstellt haben. Entdecken Sie in dieser Datei einen kompromittierten Schlüssel, dann löschen Sie den entsprechenden Block.

Abbildung 13: Die Datei ~/.ssh/authorized_keys enthält im Beispiel Schlüssel, die jeweils mit peter@gloria5 enden.

Im Zweifelsfall ist es sinnvoller, die ganze Datei zu löschen und alle Schlüssel neu zu erstellen, als einem Angreifer ungewollt Zugang zu gewähren. Um Zeit zu gewinnen, stoppen Sie in so einem Fall als Erstes den SSH-Dienst mit sudo systemctl stop sshd.

Fazit

Dass Linux-Desktops bisher von der Flut der Viren und Erpressungstrojaner verschont blieben, liegt möglicherweise an der geringeren Verbreitung und der Uneinheitlichkeit der Linux-Systeme. Warum sollten Kriminelle einen Exploit für eine im Vergleich zur Windows-Welt verschwindend geringe Anzahl an potenziellen Zielen entwerfen, solange es genügend niedriger hängende Früchte gibt?

Dennoch sollte man seinem Linux-System, der Firewall und auch einem Internet-Router mit bisher gutem Ruf niemals zu weit trauen. Maßnahmen wie das Abschalten nicht benötigter Server-Dienste, der Betrieb des Webbrowsers ohne Javascript-Unterstützung und eventuell in einer Sandbox sowie das Absichern von SSH per Schlüsseldatei statt nur per Passwort minimieren das Restrisiko deutlich. (tle)