ubuntuusers.de

Personal Firewalls

Dieser Artikel wendet sich besonders an neue Benutzer von Ubuntu, die zu ihrer Sicherheit auf ihrem Desktop-Rechner eine sogenannte Personal Firewall installieren wollen. Presse und Medien erklären oft, dass ein ungesicherter Rechner im Internet rasch kompromittiert wird und der Einsatz von Personal Firewalls auf Desktop-Systemen überlebenswichtig sei. Selbst Linux-Fachzeitschriften springen hin und wieder auf diesen Zug auf und bescheinigen Ubuntu daher, seine User "den Gefahren des Internets schutzlos ausgesetzt" zu überlassen. (Linux User 03.2006, S. 56)

Tatsächlich sind solche Programme aber nur deswegen so populär, weil in gängigen Betriebssystemen durch fehlerhafte Designentscheidungen in der Vergangenheit oft große Sicherheitsprobleme entstanden sind, die durch Personal Firewalls notdürftig abgedeckt werden. Anstatt eine Anleitung für die Installation einer solchen "Firewall" auf einem Einzelbenutzersystem zu beschreiben, soll hier erklärt werden, warum Ubuntu standardmäßig keine solche "Firewall" installiert hat, und warum das auch gar nicht nötig ist.

Hinweis:

Dieser Artikel diskutiert nur Arbeitsplatzrechner (Desktop-Rechner) und keine Server ohne oder mit Desktop.

Sicheres Design

Den Gebrauch eines Paketfilters a.k.a. "Firewall" auf einem Desktoprechner unnötig zu machen, ist ein Designprinzip von Ubuntu. Schon bei der Auswahl der Software wird darauf geachtet, dass so wenig Serverdienste wie möglich aktiviert werden, die benötigten werden (durch Benutzung der Loopback-Schnittstelle) bevorzugt so konfiguriert, dass sie in der Grundeinstellung nur vom eigenen Rechner erreicht werden können.

Eine normal installiertes Ubuntu-Desktop-System startet nur wenige über das Netzwerk erreichbare Systemdienste. Diese sind für den vom Benutzer erwarteten Komfort hinsichtlich der Netzwerk-Konfiguration erforderlich und so konfiguriert, dass sie – wenn überhaupt – nur aus dem lokalen Netzwerk erreichbar sind und damit nur aus diesem ggf. angreifbar wären. Ein Paketfilter kann den Schutz des Rechners hier nur dann verbessern, wenn man auf diese Dienste verzichtet. Dies ist aber besser zu erreichen, indem man diese Dienste erst gar nicht startet bzw. deren automatischen Start im Betriebssystem deaktiviert.

Es handelt sich konkret um diese Systemdienste:

  • ein DHCPv4-Client (z.B. der interne des NetworkManagers) für IPv4 und ein DHCPv6-Client für IPv6

  • der Avahi-DAEMON für IPv4 und IPv6

  • der Browser-Dienst von CUPS für IPv4

Die vorstehenden Dienste auf dem lokalen Rechner sind über das lokale Netzwerk erreichbar, aber nicht von Rechnern jenseits des nächstgelegenen (und oft eigenem) Routers, da die verwendeten Protokolle nur auf dem jeweiligen Link (bei DHCP) oder nur im lokalen Netzwerk (lokales Multicast bei Avahi) funktionieren und nicht geroutet werden. Nachdem man den DHCPv4-Dienst deaktiviert hat, muss man IPv4-Adresse und DNS-Namensauflösung selber händisch konfigurieren. Ohne DHCPv6-Client funktioniert möglicherweise ebenfalls die automatische Konfiguration des Netzwerks nicht mehr. Ohne Avahi wird ebenfalls die Auflösung von Netzwerknamen zu IP-Adressen beeinträchtigt und ohne den Browser-Dienst von CUPS werden Netzwerkdrucker nicht mehr automatisch gefunden. Wenn man auf den Komfort von Avahi und Druckerbrowser verzichten möchte, kann man diese Dienste problemlos deaktivieren.

Zusätzlich werden noch zwei weitere Systemdienste automatisch gestartet, die jedoch nur vom Rechner selber aus erreichbar sind und damit keine Angriffsfläche für Außenstehende bieten:

  • der Druckserver CUPS für IPv4 und IPv6

  • der DNS-Cache systemd-resolved für IPv4 und IPv6

Das gilt natürlich nur für die Situation direkt nach Installation eines Ubuntu-Desktop-Systems. Wer dann zusätzliche Server-Dienste wie beispielsweise Samba, SSH, Apache auf dem Rechner installiert, der möchte im Allgemeinen auch den Zugriff von außen erlauben. Wer das nicht will (und bspw. den Apache-Webserver als Testumgebung für Webdesign nutzen möchte), der sollte dennoch keine "Personal Firewall" benutzen, sondern die jeweiligen Konfigurationsmöglichkeiten nutzen, um die Server-Dienste nur an die Loopback-Schnittstelle (127.0.0.1 bzw. ::1) zu binden. Das ist auch nicht schwieriger aber effektiver als eine "Personal Firewall".

Mythen entmystifiziert

"Ubuntu hat keine Firewall"

Es stimmt übrigens auch nicht, dass Ubuntu keinen Paketfilter mitliefern würde. Das Linux-Firewall-System Netfilter ist als integrale Komponente des Linux Kernels immer vorhanden und dessen Verwaltungsprogramm iptables wird bei allen Ubuntu-Systemen standardmäßig installiert. Es werden bloß nicht von vorneherein restriktive Regeln aufgestellt. Ebenso gibt es zur alternativen Konfiguration einer Ubuntu-Firewall z.B. das Programm ufw und dessen GUI-Bedienoberfläche gufw in den Standard-Paketquellen von Ubuntu. Diese Paket gehören bei manchen Ubuntu-Desktops sogar zur Standardinstallation.

"Attacken gegen Client"

Manche Leute glauben, eine "Firewall" würde sie beim Surfen im Internet oder Lesen von E-Mail schützen. Dazu Folgendes: Kein Client-Programm (Web-Browser, E-Mail-Programm, etc.) kann von Kriminellen aus dem Netz heraus direkt angegriffen werden. Niemals. Diese Programme sind nur dazu konzipiert, selbst Verbindungen aufzubauen und diese zu nutzen. Eine solche TCP/IP-Verbindung zu hijacken und als Außenstehender zu nutzen, ist zwar theoretisch möglich, aber eindeutig nicht-trivial und würde dann auch wohl von keiner Firewall entdeckt werden.

Angriffe gegen Client-Programme laufen deswegen immer über den Inhalt - das, was der Benutzer (oder das mit Benutzerrechten ausgeführte Programm) sich freiwillig herunterlädt. Es gibt zwar Firewall-Systeme, die unter Umständen auch gegen so etwas schützen, aber das sind dann nicht die Paketfilter, die so gerne liebevoll "Firewall" genannt werden, sondern inhaltsbezogene Proxy- und ähnliche Systeme (z.B. SquidGuard, Mailserver mit Virenscanner, Intrusion Detection/Prevention Systeme), deren Einrichtung Unerfahrenen eher nicht anzuraten ist. Wenn man da nicht genau weiß, was man tut, kann man leicht viel größere Lücken aufreißen, als man schließen möchte. Solche Maßnahmen lohnen sich nur, wenn man für die Verwaltung von einer mittleren bis größeren Anzahl Büroarbeitsplätze verantwortlich ist oder wenn man sich wirklich für IT-Sicherheit als Hobby entscheidet.

"Kaputte Pakete"

Auch die Behauptung, ein Paketfilter weise "kaputte Pakete" zurück und schütze dadurch das System, ist falsch. "Kaputte Pakete" werden auch ohne Filter vom Netzwerkstack verworfen und erreichen die Anwendung (den Server) nicht. Theoretisch könnte es natürlich Fehler im Netzwerkstack geben, die durch solche Pakete getriggert werden. Das könnte aber auch im netfilter-/iptables-Modul passieren, beides gilt jedoch als relativ sicherer Code. Die Zeiten, wo schlechte IP-Implementierungen reihenweise zu Denial-of-Service-Angriffen einluden, sind jedenfalls schon lange vorbei.

Im Internet "unsichtbar machen"

Das System "unsichtbar" zu machen, indem man Pakete nicht regelgerecht abweisen, sondern kommentarlos verwerfen lässt (DROP), ist ebenfalls nicht sinnvoll. Ein System, das keine Ports zum Internet offen hat, wie ein Standard-Ubuntu-Desktop, hat keinen einzigen Grund, "unsichtbar" zu sein. (Die wenigen Serverdienste eines Standard-Ubuntu-Desktops sind nur im lokalen Netzwerk (LAN/WLAN) erreichbar.) Im Gegenteil: Sendet ein System eine Verbindungsanfrage (bspw. weil es sich vor kurzem mit einem anderen System ausgetauscht hat, das zu dem Zeitpunkt diese IP-Adresse hatte) weiß es sofort, dass es dort keinen Dienst gibt, und bricht ab (wenn es sauber programmiert ist). Bei "unsichtbaren" Systemen versucht es dagegen noch eine halbe Ewigkeit, die Daten zuzustellen. Wenn ein Rechner aber sowieso einen Dienst offen hat, bspw. ssh, dann kann keine "Firewall" der Welt diesen Port "unsichtbar" machen.

Der Versuch sich "unsichtbar zu machen" kann sogar Probleme verursachen. Bspw. versuchen einige FTP- und IRC-Server, bei jedem Login eine ident-Abfrage zu machen (Port 113). Wenn dieser Port auf dem Client nun "unsichtbar" ist, wird der Login verzögert, bis der Timeout kommt. Andere Probleme kann man bekommen, wenn irgendeine Software wahllos ICMP-Pakete verwirft. Dann funktioniert nämlich unter Umständen die sogenannte Path MTU Discovery nicht mehr, und es kann zu "rätselhaften" Verbindungsproblemen kommen, die sich der Laie nicht erklären kann.

Personal Firewalls "vereinfachen" die Rechner-Verwaltung

Manche Leute denken, die Installation eines Paketfilters mit Hilfe eines grafischen Programms sei einfach, richte keinen Schaden an und bringe vielleicht doch mal irgendeinen Nutzen. Insbesondere vereinfache sich dadurch die Administration, da man bei der Installation von zusätzlichen Diensten in Bezug auf die Sicherheit sorgloser sein könne.

Tatsächlich macht eine Personal Firewall auf dem lokalen Rechner jedoch nichts einfacher, sondern erschwert dessen Verwaltung eher, weil bei jeder Serverinstallation erst einmal neue Regeln erstellt werden müssen. Das kann zu schwer durchschaubaren Fehlern führen, wenn man bspw. im Falle von Samba einen der vielen Ports vergisst freizugeben.

Wann ist ein Paketfilter doch sinnvoll?

Wer Serverdienste nur in seinem lokalen Netzwerk zulassen möchte, braucht in den allermeisten Fällen auch keinen Paketfilter, da er wohl meistens einen Router (Hardware oder PC) sein eigen nennt, der für ihn Network Address Translation (NAT) (siehe unten) durchführt. Der Server trägt dann eine lokale Adresse wie 192.168.0.5, die aus dem Internet überhaupt nicht zu erreichen ist, außer der Router führt Forwarding aus, dann dürfte das aber wohl beabsichtigt sein.

Wichtig wird eine Firewall erst, wenn man entweder eigene Serverdienste aus einer DMZ heraus im Netz anbietet, oder wenn ein internes Netz gar öffentliche IP-Adressen besitzt. Davon sollten allerdings Neulinge besser erst einmal die Finger lassen und sich informieren. Ein grafisches Tool könnte in dem Fall einem Profi vielleicht helfen, die Konfiguration schneller hinzukriegen, als manuell "iptables zu hacken", kann aber nicht die Kenntnisse über Netzwerksicherheit ersetzen.

Richtig sinnvoll auf einem Einzelplatzrechner ist ein Paketfilter nur, wenn man nicht die Ports, sondern die Herkunft der Pakete einschränken will. Zum Beispiel möchte man einem Kumpel ermöglichen, den eigenen FTP-Server zu benutzen, oder man will vom Arbeitsplatz aus ssh nach Hause benutzen. So etwas lässt sich oft mit iptables einfacher konfigurieren als über hosts.allow und hosts.deny oder dienst-spezifische Konfigurationsdateien. Besonders, wenn es sich um eine ganze Reihe Dienste handelt, die alle für denselben Zugang vorgesehen sind. Das ist allerdings auch nur dann praktikabel, wenn keine dynamischen IP-Adressen involviert sind. Da die Möglichkeit des Adress-Spoofing besteht, sollte das jedoch niemals starke Authentifizierungsmechanismen des betreffenden Dienstes ersetzen. Gute Passwörter (oder noch besser kryptographische Zertifikate) sind auch dann unverzichtbar, wenn "nur" der eigene Arbeitsplatzrechner freigegeben ist. Besser könnte es dann wohl sein, gleich auf VPN zu setzen. Es ist außerdem daran zu denken, dass man bei gelegentlichem Zugriff auf einen zu Hause befindlichen Testwebserver o.ä. auch ssh-Tunnel benutzen kann.

In seltenen Fällen mag es vorkommen, dass ein Dienst nicht die Möglichkeit bietet, ihn auf bestimmte Netzwerkschnittstellen zu begrenzen. Insbesondere könnte das bei Software der Fall sein, die von Ubuntu nicht unterstützt wird. In diesem Fall kann man versuchen, diesen Qualitätsmangel mit Filterregeln für eingehende IP-Pakete zu kompensieren. Es gibt allerdings Programm, die sogar speziell für die Umgehung solcher Firewall-Regeln vorbereitet sind und dazu beispielsweise Methoden wie Hole-Punching anwenden. Hierzu gehören VoIP-Programme, Bittorrent-Clients und manche Clients für Filesharing.

Eine sinnvolle Verwendung eines Personal Firewalls ist die Unterbindung von Kontaktaufnahmen der Anwendungssoftware des eigenen Rechners mit unerwünschten Gegenstellen im Internet. Hierzu kann man einen Paketfilter mit Filterregeln für ausgehende IP-Pakete verwenden oder das (besser aber anspruchsvoll) über Routing realisieren.

Der Wiki-Artitel zu iptables enthält auch ein Lehrbeispiel für eine rudimentäre Personal Firewall.

Anhang

Network Address Translation

Network Address Translation (NAT) ist eine Technik, die ursprünglich das Problem knapper IP-Adressen lösen sollte (und das auch hinreichend tut).

Wenn man sich bei einem "Dial-Up"-Provider einwählt, egal ob per DSL, ISDN, Analog-Modem oder wie auch immer, bekommt man im Normalfall genau eine IPv4-Adresse für die Dauer der Verbindung zugewiesen. Das wird zu einem Problem, wenn man den Zugang für mehrere Rechner gleichzeitig nutzen will, da nur ein Rechner gleichzeitig diese Adresse nutzen kann. Um dieses Problem zu lösen, braucht man NAT und private Adressbereiche.

Private Adressbereiche sind Bereiche von IP-Adressen, die für die private Nutzung ohne vorherige Registrierung vorgesehen sind. Jeder darf in seinem Netzwerk diese Adressen benutzen, ohne jemanden vorher fragen zu müssen. Da diese Adressen im Gegensatz zu herkömmlichen IP-Adressen also nicht einzigartig auf der Welt sind, gibt es im öffentlichen Internet keine Möglichkeit, Informationen an diese Adressen zu routen, also zu leiten - nicht einmal Antworten auf Anfragen. Die vorgesehenen Bereiche für die private Nutzung sind in einem Dokument festgelegt, dass "RFC-1918" heißt, und umfassen die Adressen 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255 und 192.168.0.0-192.168.255.255.

Um also diesen vielen Rechnern in privaten Netzwerken den Zugang zum Internet zu ermöglichen, wurde die Network Address Translation-, genauer gesagt: die Masquerading-Technik, erfunden. Hierbei nimmt ein NAT-Gerät, ein Router, Pakete an einer Schnittstelle zum lokalen Netzwerk entgegen und leitet sie über die "Dial-Up"-Verbindung ins Internet weiter, wobei die private Absenderadresse mit der offiziellen IP-Adresse des NAT-Routers überschrieben wird. Gleichzeitig merkt sich der Router, an welchen Rechner er die Antwortpakete für diese spezielle Verbindung zurückleiten muss.

Daraus folgt andererseits, dass der Router keine Möglichkeit hat, Pakete zuzustellen, die keine Antworten auf Verbindungsanfragen sind. Solche Pakete landen dann direkt beim Router, der normalerweise (haarsträubende Konfigurationsfehler mal ausgeschlossen) keine Dienste nach außen anbietet und diese Pakete deswegen zurückweist bzw. verwirft. So ganz nebenbei ist Masquerading also ein sehr wirksamer Sicherheitsmechanismus für lokale Netzwerke.

Es gibt auch noch andere Formen des NAT, bspw. das Port-Forwarding. Das dient dazu, dass Rechner hinter einem NAT-Gerät doch von außen zu erreichen sind, z.B. Server. Hierzu muss der NAT-Router so konfiguriert werden, dass Anfragen an bestimmte Ports doch in das interne Netz geroutet werden, auch wenn es keine "Antworten" sind. Der Rechner, an den diese Pakete geschickt werden sollen, muss allerdings vom Administrator explizit festgelegt werden. So kann man bspw. alle Pakete, die an Port 80 oder 443 gerichtet sind, an einen internen Webserver weiterleiten lassen.

Filesharing-Tools

Diese öffnen in den meisten Fällen auch Ports nach außen, wie ja schon die Bedeutung des Wortes "Sharing" suggeriert. Dass die meisten inzwischen auch hinter einer Firewall funktionieren, liegt an einem Trick. Systeme, die hinter einer Firewall liegen, fragen einfach in gewissen Abständen ihren Server nach, ob jemand etwas von ihnen haben will, und "pushen" diese Datei dann, indem sie selber eine Verbindung zum Tauschpartner ausführen. Wenn dieser allerdings auch hinter einer Firewall sitzt, funktioniert das nicht, so dass man als Filesharer hinter einer Firewall heutzutage doch ziemlich eingeschränkt ist. Man wird von BitTorrent dafür sogar mit geringerer Empfangsrate ("download rate") bestraft. Deswegen öffnen viele "Filesharer" die Ports absichtlich und explizit oder stellen Port-Forwarding auf ihrem Router ein. Sollte man also auf einem Einzelplatzsystem so eine Software einsetzen, aber der Qualität der Software nicht soweit trauen, dass es nur die freigegebenen Daten rausrückt, könnte man einen Paketfilter einsetzen wollen, der diese Ports für den Zugriff von außen sperrt. Oben beschriebene Nachteile sind dann allerdings unvermeidlich.

Diagnose

Wer sich dafür interessiert, welche Ports auf seinem System gerade offen sind, kann einen Befehl wie

sudo ss -4nOlp   # für IPv4
sudo ss -6nOlp   # für IPv6 

benutzen. (In den Optionen steht ein großes O für "oneline".) Man erhält eine Liste aller momentan auf dem eigenen Rechner über das jeweilige Netzwerk-Protokoll erreichbaren Serverdienste. Ähnliche Listen liefert auch der bei Linux veraltete Befehl netstat aus dem Paket net-tools, welches man allerdings bei Ubuntu erst installieren muss. (ss aus dem Paket iproute2 wird standardmäßig installiert.)

Zusätzlich zu den mit obigen Befehlen angezeigten Verbindungsendpunkten (sockets) auf Netzwerkprotokollebene 3 (Layer 3, L3) kann es auch noch solche auf Ebene 2 geben, die man mit diesem Befehl sieht:

sudo ss -0nOlp   # für Link-Protokolle wie z.B. Ethernet 

(In diesem Befehl gibt in den Optionen eine Null 0 und ein großes O.)

Um sicherzugehen, kann man ein System auch mit Hilfe eines Port-Scanners von außen testen, wenn man ein eigenes Netzwerk besitzt, oder auch über das Internet. Ein Portscan von ein- und demselben Rechner ist dagegen wenig aussagekräftig. "Profis" benutzen das Kommandozeilenprogramm nmap von insecure.org 🇬🇧, das unzählige Optionen bietet und ggf. dafür eine grafische Oberfläche wie z.B zenmap. Diese Programme gibt es in den Standard-Paketquellen von Ubuntu.

Diese Revision wurde am 26. Mai 2022 09:01 von kB erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Einsteiger, Netzwerk, Internet, Sicherheit, Firewall