Linux gilt als weitgehend sicher, aber Sorglosigkeit ist dennoch gefährlich. Die Sicherheit eines OpenSuse-Systems lässt sich gegenüber dem Auslieferzustand verbessern.

Die Linux-Kernel-Entwickler um Linus Torvalds liefern einen stabilen, professionell aktuell gehaltenen Systemkern. Linux-Anwender haben seltener mit ungebetenen Gästen zu kämpfen als ihre Windows-Kollegen, wozu allerdings auch die geringe Verbreitung beiträgt. Im Vergleich zur schieren Anzahl der von Laien oft mehr schlecht als recht gewarteten Windows-Installationen bleibt Linux ein Exot. Zudem gibt es nicht das eine Linux. Die Distributionen differieren in den Versionsständen der enthaltenen Software, sodass Angriffstechniken oft nur für eine geringe Anzahl von Rechnern funktionieren.

Doch auch unter Linux hängt viel vom umsichtigen Verhalten des Anwenders ab: Das sicherste System nutzt wenig, wenn ein Login aus dem Internet mit einem leicht zu erratenden Passwort möglich ist. Zudem weist auch Linux-Software oft genug Sicherheitslücken auf, wenngleich sie dank des Open-Source-Prinzips oft schneller entdeckt und beseitigt werden. Sich auf die Grundsicherheit von Linux und der Router-Firewall (Abbildung 1) zu verlassen, geht zwar meist lange gut, aber nicht immer.

Abbildung 1: Heute geben die für die Internetverbindung zuständigen Router standardmäßig keinerlei Ports frei. Alle angeschlossenen Rechner sind gegen von außen initiierte Verbindungen vollständig abgeschottet.

Vertrauenskette

Wer unter Linux Software installiert, vertraut auf zwei Dinge: Dass sein Distributor die Sicherheit im Auge behält und sich bei Bekanntwerden von Lücken zügig um Fixes kümmert. Hinter OpenSuse steht die im Enterprise-Umfeld erfolgreiche Firma Suse. Ein guter Teil der Pakete in Leap entstammt direkt der Enterprise-Distribution SLES und erbt deren Sicherheit.

Die auf dem Suse-spezifischen Libzypp [1] basierende Softwareverwaltung garantiert per Signatur, dass die Pakete trotz Übertragung über das unsichere Medium Internet in unkompromittierter Form beim Anwender ankommen. Voraussetzung ist, dass die Schlüssel, anhand derer Zypper die Pakete prüft, authentisch sind. Die originalen OpenSuse-Keys stammen ursprünglich vom Installationsmedium, dessen Unverfälschtheit sich anhand von Prüfsummen verifizieren lässt (Abbildung 2). Die Paketverwaltung fragt beim Einbinden neuer Paketquellen stets, ob sie dem Repository-Schlüssel vertrauen soll (Abbildung 3).

Abbildung 2: Der Aufruf von Sha256sum muss für das heruntergeladene ISO-Image dieselbe Zeichenfolge liefern wie die nach einem Klick auf den Pfeil des Download-Buttons erscheinende Seite Checksum.

Abbildung 3: Beim Hinzufügen eines neuen Repositorys fragt YaST, ob es dem noch unbekannten GnuPG-Schlüssel vertrauen soll. Sie sollten dem nur zustimmen, wenn Sie sicher sind, dass der Schlüssel wirklich diesem Eigentümer gehört.

Es kostet wenig Mühe, die in der Paketverwaltung hinterlegten Schlüssel mit den im Internet veröffentlichten Schlüssel-Fingerprints abzugleichen. Das auf GPG-Technik [2] setzende Verfahren garantiert, dass sich Schlüssel mit einem gegebenen Fingerprint nicht gezielt erzeugen lassen. Stimmen die lokalen Fingerprints mit den online recherchierbaren Versionen überein, können Sie davon ausgehen, dass die Schlüssel unverfälscht sind.

Alle von der Paketverwaltung genutzten Schlüssel lassen sich im YaST-Modul Softwarerepositorys einsehen (Button GPG-Keys unten rechts). Die Fingerabdrücke des seit 2024 eingesetzten Schlüssels für die Standard-Repositorys [3] und des Schlüssels für das Packman-Repository [4] mit unbeschnittenen Multimedia-Codecs können Sie aus dem Netz herunterladen. Auch allen Build-Service-Repositories ist ein eigener GPG-Schlüssel zugeordnet, beim Hinzufügen eines neuen Repos erscheint die Abfrage aus Abbildung 3. Auf der Webseite des Build-Service finden Sie den Fingerprint nach einem Klick auf den blauen Link zum OBS-Projekt ganz oben links unter Home im Reiter Signing Keys (Abbildung 4).

Abbildung 4: Für jedes Projekt auf dem OpenSuse-Build-Service, sei es das Home-Projekt eines externen Accounts oder ein offizielles OpenSuse-Projekt, gibt es einen eigenen Schlüssel für die Signatur der dort erstellten Repositories.

Das von Suse genutzte Paketsystem RPM gestattet es zu prüfen, ob sich in den Paketen enthaltene Dateien seit der Installation verändert haben. Das wäre etwa der Fall, hätte ein Virus eine Programmdatei infiziert. Das Kommando aus der ersten Zeile von Listing 1 liefert eine Liste von Dateien, die sich vom Inhalt des Pakets unterscheiden. Bei vielen davon sind allerdings Veränderungen zu erwarten, und sie stellen keinen Hinweis auf eine Manipulation dar.

Der Befehl aus der zweiten Zeile von Listing 1 siebt durch den ersten Grep-Aufruf alle Konfigurations- und Ghost-Dateien aus. Bei letzteren handelt es sich um zur Laufzeit entstehende Dateien, die die Installation nicht einspielt, die ein Entfernen des Pakets aber löscht. Die zweite Grep-Stufe filtert aus den verbleibenden alle Dateien heraus, deren Dateigröße (S), Inhalt (5) oder Erstellungszeit (T) sich nachträglich verändert hat.

Die Ausgabe des Gesamtaufrufs sollte leer bleiben, nicht ausgefilterte Veränderungen wären unerwartet. Es lässt sich im Zweifelsfall jedoch nicht erkennen, ob eine bewusste Manipulation oder ein Fehler des Speichergeräts zu einer Abweichung geführt hat. Auf jeden Fall sollten Sie alle von Modifikationen betroffenen Pakete neu installieren. Der Befehl aus der letzten Zeile von Listing 1 zeigt, um welche es sich handelt.

$ rpm -Va
$ sudo rpm -Va| grep -Ev " c | g "|grep -E "S\.|\.5|\.T"
$ rpm -Qf /Pfad/GeänderteDatei

Dezentral

Ob die inzwischen verbreiteten distributionsübergreifenden Flatpak-Pakete ebenso sicher sind wie die von den Distributionen mitgelieferten Pakete, ist Gegenstand anhaltender Diskussionen. Flatpaks beziehen zwar verbreitete Abhängigkeiten wie Gnome- oder KDE-Komponenten aus gut gepflegten Laufzeitumgebungen, jedes Flatpak bringt aber alle spezifischen Abhängigkeiten separat mit.

Das lässt Erinnerungen an das als “DLL hell” bekannte Bibliothekschaos unter Windows aufkommen. Windows-Programme liefern mangels eines zentralen Versionsmanagements traditionell eigene Versionen von Bibliotheken mit, die dann parallel in verschiedenen Fassungen auf dem System vorliegen und bei Sicherheitslücken schwer zuverlässig auszutauschen sind.

Gibt es eine Sicherheitslücke in einer nicht von den Laufzeitumgebungen abgedeckten Bibliothek, muss jeder einzelne Flatpak-Autor aktiv das in seinem Paket genutzte Hilfsprogramm aktualisieren. Bei vielen installierten Flatpaks steigt die Wahrscheinlichkeit, dass eine ungepatchte Version auf dem System verbleibt.

Als Sicherheitsplus gilt die Kapselung von Flatpak auf Basis des Containersystems Bubblewarp [5]. Doch das Unterbinden des Dateizugriffs auf das System außerhalb des Containers ist eher eine theoretisch bestehende technische Möglichkeit als eine flächendeckend zum Zuge kommende Praxis (Abbildung 5). Anwender erwarten schlicht, dass sie die Daten eines Programms an einer beliebigen Stelle im Home-Verzeichnis speichern können. Darum gewähren ihnen die Flatpak-Autoren per Paketeinstellungen diesen Schreibzugriff auf das gesamte Benutzerverzeichnis.

Abbildung 5: Die meisten Flatpaks auf Flathub sind potenziell unsicher und für vollen Lese- und Schreibzugriff auf das Dateisystem des Rechners konfiguriert.

Wer Pakete auf Flathub.org veröffentlichen will, dem Standard-Repository für Flatpaks, muss einen Antrag stellen. Der, so schreiben die Betreiber [6], zieht eine Überprüfung der Pakete nach sich. Zusätzlich finden laufend automatisierte Scans nach Sicherheitsproblemen statt. Dennoch dürfte es weitaus schwieriger sein, verdächtige Aktivitäten unter Tausenden Paket-Maintainern auszumachen als in einem Distri-Team mit vielleicht zweistelliger Mitgliederzahl.

Zugriffe regeln

Sie können die Flatpak-Sicherheit durch ein Beschränken der Berechtigungen selbst erhöhen. KDE-Anwender brauchen dazu nur das Modul Flatpak-Berechtigungen in der KDE-Systemsteuerung zu öffnen. Anwender anderer Desktop-Umgebungen installieren dafür das Programm Flatseal vom OpenSuse Build Service. Die Version des Build-Service-Benutzers Dead_Mozay [7] hat im Test einwandfrei funktioniert. Zur Gegenkontrolle nennt die Paketverwaltung den Fingerprint des GPG-Schlüssels zum Repository beim Hinzufügen der Quelle.

Flatseal und die KDE-Systemsteuerung erlauben es unter anderem, Programmen einen im Flatpak-Paket eigentlich vorgesehenen Schreibzugriff für das gesamte /home nachträglich zu entziehen und die Freigabe auf bestimmte Ordner einzuschränken.

Flathub signiert alle Pakete mit einem gemeinsamen Schlüssel und sichert genau wie das Suse-Paketsystem die Dateiübertragung per Internet. Der Anwender bekommt den Schlüssel allerdings nie zur Prüfung zu Gesicht, es sei denn, er ruft per Hand nach Aktivieren des Flathub-Repositorys (Listing 2, erste Zeile) ein entsprechendes Kommando auf (zweite Zeile). Der Referenzschlüssel [8] lässt im Browser herunterladen und ebenfalls per gpg --show-keys auf seinen Fingerprint prüfen.

$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
$ gpg --show-keys --with-fingerprint /var/lib/flatpak/repo/flathub.trustedkeys.gpg
$ flatpak remote-add --if-not-exists --subset=verified flathub-verified https://flathub.org/repo/flathub.flatpakrepo

Zur Gewährleistung der Sicherheit müssen Sie Flatpaks genau wie gewöhnliche Pakete stets aktuell halten. Für OpenSuse-Packages signalisiert ein Taskleisten-Icon das Bereitstehen von Updates, bei Flatpaks ist das unter Suse nicht der Fall: Die grafischen Softwaremanagement-Apps KDE Discover und Gnome Software unterstützen Flatpak, nicht jedoch die Suse-Softwareverwaltung. Am einfachsten lassen sich daher die installierten Flatpaks inklusive der Runtimes per sudo flatpak update aktuell halten.

Wie erwähnt, steht die Publikation eigener Pakete auf Flathub jedermann frei. Bei mit einem blauen Häkchen als verifiziert ausgewiesenen Paket (Abbildung 6) hat die Überprüfung ergeben, dass es sich beim Veröffentlicher um den eigentlichen Entwickler der Software handelt. Projekte und Firmen veröffentlichen immer häufiger ein für alle Linux-Distributionen verwendbares Flatpak. So können Sie ihre Software unabhängig von den Aktualisierungszyklen der Distributionen in einer aktuellen Version verteilen. Möchten Sie nur verifizierte Flatpaks installieren, erreichen Sie das mit dem Kommando aus der letzten Zeile von Listing 3. Nur Suchtreffer aus dem Repository flathub-verified erfüllen die darin gestellte Bedingung.

Abbildung 6: Viele Pakete auf Flathub tragen inzwischen den Verified-Haken, der besagt, dass die Entwickler der Software selbst das Flatpak erstellt haben.

Eingehegt

Bei per Flatpak installierter Software handelt es sich meist um Programme wie Bitmap-Editoren oder Textverarbeitungen, die Angriffen aus dem Internet weniger ausgesetzt sind als ein Webbrowser. Doch das kann sich ändern, sobald Sie damit Dateien aus einer unbekannten Quelle öffnen: Bei Anwendungen mit Fehlern in der Speicherverwaltung (die sich manchmal in Abstürzen äußern) ist es potenziell möglich, durch präparierte Dateien eigenen Code mit Benutzerrechten auszuführen.

Angreifer können so zwar keine Systemdateien verändern oder bösartigen Code in den Kernel einschleusen. Doch es ist für Schadsoftware ein Leichtes, bei jedem Anmelden startende Skripte in den dafür vorgesehenen Verzeichnissen zu installieren. Die loggen dann selbst ohne Root-Zugriff unter X11 alle Tastatureingaben mit. Bei Wayland-Programmen funktioniert das nicht so leicht. Im Verzeichnis ~/.config/autostart/ finden sich die Starter für bei jedem Login aufgerufene Programme. KDE führt außerdem vor jedem Login noch Skripte unter ~/.config/plasma-workspace/env/ aus, zum Beispiel, um Umgebungsvariablen zu setzen.

Zum Glück gibt es einige Schutzmaßnahmen, um Schadsoftware auf Benutzerebene das Leben schwerer zu machen: Die Mount-Option noexec weist den Linux-Kernel an, aus einer damit eingehängten Partition keinen Programmcode auszuführen. Es ist generell keine schlechte Idee, die Home-Partition so zu mounten. Das System bringt ausführbare Dateien nicht ohne Grund vor Schreibzugriffen mit Benutzerrechten geschützt in eigenen Verzeichnissen unter. Das Standard-Partitionslayout von OpenSuse listet auch /var als separates Btrfs-Volume, das sich mit Ausführsperre einhängen lässt.

Um Ihr Home-Verzeichnis auf diese Weise zu schützen, fügen Sie der entsprechenden Zeile in /etc/fstab einfach die noexec-Option hinzu (Abbildung 7). Dabei darf weder vor noch nach dem Komma hinter home ein Leerzeichen stehen, sonst startet der Rechner nicht mehr. Unter Leap 15.6 lässt sich auch /tmp auf diese Weise in Fstab modifizieren, ein Verzeichnis, in das jeder Anwender schreiben darf. Tumbleweed erzeugt unter Systemd das /tmp-Verzeichnis dynamisch. Hier legen Sie stattdessen die Datei /etc/systemd/system/tmp.mount.d/override.conf mit dem Inhalt aus Listing 3 an.

Abbildung 7: Das simple Hinzufügen der Option noexec in der für das Home-Verzeichnis zuständigen Zeile der /etc/fstab unterdrückt das Starten von im Home abgelegten Binaries.

[Mount]
Options=noexec

Die noexec-Option verhindert zudem den direkten Start von Shell-Skripten, zum Beispiel durch einen Klick im Dateimanager. Sie lassen sich dann nur noch in der Shell via sh /Pfad/zum/Skript.sh ausführen. Da es sich bei den Desktop-Dateien der Autostart-Einträge in ~/.config/autostart/ nicht um ausführbare Dateien handelt, funktionieren sie trotz noexec weiter. Nichts hindert also einen Angreifer daran, Schreibzugriffe auf das Home dort in einem Shell-Skript abzulegen und es per Autostart-Eintrag zu starten.

Die Ausführungsprävention mit noexec verhindert also das Starten von gewöhnlichen ausführbaren Dateien aus dem Home, jedoch nicht den Aufruf von Shell-Skripten. Sie sind dann in der Lage, Dateien im Home zu löschen oder mit den auf den meisten Systemen installierten Tools zu verschlüsseln.

Autostart-Skripte, die Schadsoftware bei jedem Anmelden am System aktivieren, lassen sich relativ leicht entdecken. Das gilt jedoch nicht für Bedrohungen, denen der Webbrowser ausgesetzt ist. Er steht direkt mit dem Internet in Kontakt, ist komplex und stellt in Form von Javascript und Wasm sogar Programmiersprachen bereit.

Eine im Browser eingebaute Sandbox soll das System vor Angriffen bösartiger Webseiten schützen. Doch Bugs, die einen Ausbruch aus dieser Schutzhülle gestatten (“Sandbox Escape”) gab es schon häufiger [9]. Vorsichtige Anwender umgeben den Browser mithilfe des einfach zu benutzenden Tools Firejail mit einem zusätzlichen Schutzcontainer. Das funktioniert prinzipiell bei jedem Programm. Es genügt dafür, dem Aufruf auf der Konsole firejail voranzustellen, zum Beispiel firejail firefox.

Firejail richten Sie mit den Kommandos aus Listing 4 ein und starten dann das System neu. Das Tool bringt Profile für eine Reihe gängiger Programme mit. Im Fall von Firefox gestattet es den Schreibzugriff auf das Profilverzeichnis unter ~/.mozilla/firefox, ohne den der Browser nicht funktioniert. Außerdem darf der Anwender heruntergeladene Dateien im Verzeichnis ~/Downloads ablegen.

$ sudo zypper in firejail
$ sudo usermod -a -G firejail Benutzer

Brandmauer

Die bildhafte Bezeichnung Firewall suggeriert maximale Sicherheit, obwohl sie unter Linux eher ein Behelfspflaster für Lücken darstellt, die es gar nicht geben müsste.

Das Eindringen in fremde Computer von außen gelingt nur über Serverdienste, die entweder Befehle ausführen, ohne die Berechtigungen zu prüfen, oder die aufgrund von Speicherlücken das Einschleusen von fremdem Code ermöglichen. Netzwerkdienste, die von vorneherein nicht laufen, sind in Sachen Sicherheit per Firewall abgeschirmten unsicheren Diensten vorzuziehen. Wenn Sie kein Remote-Login nutzen, deaktivieren Sie den zugehörigen SSH-Dienst mit dem Befehl aus der ersten Zeile von Listing 5. Das Kommando aus der zweiten Zeile aktiviert ihn bei Bedarf wieder.

$ sudo systemctl disable sshd --now
$ sudo systemctl enable sshd --now

OpenSuse verfährt dennoch seit Jahren nach der Devise, dass eine zusätzliche Schutzschicht nicht schadet, und aktiviert die Firewall standardmäßig. Schon bei der Installation dürfen Sie hier aber den Port für SSH und den Remote-Login-Dienst schließen (Abbildung 8), den SSH-Dienst deaktivieren oder die Firewall ganz ausschalten. Ist der entsprechende Port in der System-Firewall und im Internet-Router freigegeben, lässt sich der Rechner auch aus dem Internet erreichen, wie es sich viele Anwender wünschen.

Abbildung 8: Die Voreinstellungen bei der OpenSuse-Installation bezüglich Firewall und Remote-Login per SSH lauten: Die Firewall ist mit geöffnetem SSH-Port aktiv, der Remote-Login-Dienst läuft.

In der Standardkonfiguration hält nur ein simples Passwort Eindringlinge fern, die zahlreich und automatisiert an erreichbare SSH-Ports anklopfen. Das Kommando sudo journalctl -u sshd -g "Failed password" fördert die zugehörigen Einträge im Systemjournal zutage. Ist das Passwort sicher, besteht also nicht aus in einem Wörterbuch zu findenden Bestandteilen, kommen Angreifer nicht weit.

Dennoch stellen Sie den Zugang von außen besser per VPN her und halten alle Ports in der Router-Firewall geschlossen [10]. Zudem empfiehlt es sich, SSH auf schlüsselbasierte Authentifikation umzustellen. Ein Passwort genügt dann nicht mehr für das Login. Nur wer eine passende Schlüsseldatei vorzeigt, deren Länge Zufallstreffer ausschließt, darf passieren. Solche Schlüsseldateien lassen sich zusätzlich noch durch ein Passwort sichern, sodass Angreifern der Besitz des Schlüssels allein nicht genügt.

Erstellen Sie zuerst einen SSH-Schlüssel auf einem der Rechner, von dem aus Sie sich aus dem Internet einloggen möchten (der Client), während er sich im Heimnetz befindet. Das Ausführen von ssh-keygen genügt dafür. SSH fordert zum Bestätigen des Schlüsseldateinamens und -pfads und zur zweimaligen Eingabe eines Passworts auf. Kopieren Sie dann den generierten Schlüssel mit dem Befehl ssh-copy-id IP-Adresse auf den Rechner, auf den Sie sich remote einloggen möchten (Server). Die aus vier dreistelligen Zahlen bestehende IPv4-Adresse im Heimnetz finden Sie per ip a auf dem Zielrechner heraus. Ein Login per SSH auf diesen Computer muss dabei möglich sein, sprich: Der SSH-Dienst muss dort laufen und der Firewall-Port offen sein.

Testen Sie das Login von dem Rechner aus, zu dem Sie gerade den Schlüssel übertragen haben. Das Kommando ssh IP-Adresse sollte nun mit der Aufforderung Enter passphrase for key ... antworten. Wichtig ist das Schlüsselwort key, das darauf hinweist, dass ein Schlüssel für die Authentifizierung zum Einsatz kommt.

Noch ist das schlüsselbasierte Login nicht die einzige Möglichkeit zur Anmeldung. Drücken Sie die Eingabetaste, statt das Schlüsselpassworts zu tippen, erscheint die Aufforderung, das Benutzerpasswort einzugeben. Das ändert sich, nachdem Sie als Root auf dem Server im Verzeichnis /etc/ssh/sshd_config.d/ die Datei 20-force_publickey_auth.conf mit dem Inhalt aus Listing 6 angelegt haben.

PasswordAuthentication no
AuthenticationMethods publickey

Um die Konfigurationsänderung scharfzuschalten, starten Sie den SSH-Daemon mit sudo systemctl restart sshd neu. Danach sollte beim SSH-Login mit ssh IP-Adresse nach Drücken der Eingabetaste ohne Passworteingabe nicht länger eine zweite Aufforderung erscheinen, sondern die Meldung Permission denied (publickey). Das SSH-Login ist nun gegen Brute-Force-Attacken per Durchprobieren des Passworts geschützt. Es klappt nur noch von Rechnern aus, deren Login-Schlüssel Sie mit ssh-copy-id auf den Server übertragen haben.

Ausblick

Ein jüngeres Beispiel für eine über offizielle Distributionspakete ausgelieferte Bedrohung war die äußerst kritische Backdoor in der Kompressionsbibliothek Xz Anfang 2024 [11]. Der SSH-Server lud diese Bibliothek auch unter Tumbleweed [12] über einen nicht nur von Suse eingesetzten Patch und verschaffte so einem Eindringling ohne Authentifizierung Root-Rechte. Wäre diese Backdoor per Paket-Upgrade in großer Anzahl auf Produktivsystemen mit Debian Stable oder SLES gelangt, hätte auf ihnen ein Scheunentor für Angriffe offengestanden.

Dass das nicht in großem Stil passierte, ist der Aufmerksamkeit des PostgreSQL- und Microsoft-Entwicklers Andres Freund zu verdanken. Er wollte sich nicht damit abfinden, dass auf seinem Debian Unstable nach einem Update beim Einloggen per SSH eine ungewöhnlich hohe CPU-Last auftrat. Letztlich wendeten er und die schnelle Reaktion der Linux-Distributionen großen Schaden gerade noch ab.

Zwei Dinge lassen sich daraus ableiten: Wer sein System kennt, entwickelt ein Gefühl dafür, wenn es sich plötzlich unerwartet verhält. Kommandozeilenwerkzeuge wie Top und Htop oder der unter KDE mit [AltGr]+[Esc] zu öffnende grafische Systemmonitor informieren jederzeit über die CPU-Last sowie die Speicherbelegung und zeigen, wie sie sich auf einzelne Prozesse mit bestimmten Namen verteilt. Im Internet tauchen in Foren oft Fragen bezüglich des hohen Speicherverbrauchs oder der exzessiven CPU-Last bestimmter Prozesse auf. Solche Fragen zu stellen, ist richtig, auch wenn ein Bug die wahrscheinlichere Erklärung dafür ist als ein böswilliger Angriff.

Wichtig sind für Suse-Anwender das Tool Zypper-log beziehungsweise der Menüpunkt Extras/Verlauf anzeigen im YaST-Modul Software. Beide zeigen eine History aller Aktionen des Paketmanagements wie Installationen und Upgrades, die Auslöser eines veränderten Verhaltens sein könnten.

Auch der grafische Netzwerkmonitor Etherape (Abbildung 9), der Netzwerkdatenverkehr im Heimnetz und im Internet je nach Datenmenge als unterschiedlich dicke Balken darstellt, empfiehlt sich für Benutzer als diagnostisches Werkzeug. Er macht verdächtige Datenströme direkt sichtbar, ohne dass man sich in die Interna der Netzwerkprotokolle einarbeiten muss. (uba/jlu)

Abbildung 9: Etherape visualisiert, zwischen welchen Rechnern im lokalen Netz und welchen Internetadressen Daten fließen. Die Dicke der Linien entspricht der Übertragungsgeschwindigkeit.