0. Technische Aspekte von Mac OS X und verwandte Themen Inhaltsverzeichnis

0.16 Firewall Nonsens

Jeder hat das Wort Firewall schon gehört und weiß, daß es mit Sicherheit zu tun hat. Die coolen Kids installieren sich Firewalls und wägen sich in Sicherheit. Tatsächlich wird ein System nicht sicherer durch eine Firewall, sondern unsicherer, denn es löst das zugrundeliegende Problem nicht, sondern fügt ein weiteres hinzu. Wie man das Problem an der Wurzel packt und wie es überhaupt zum Firewall-Hype kam und warum Firewalls nur selten sinnvoll sind, darum geht es in diesem Artikel.

Arten von Firewalls

Je nach Installations-Ort und nach Protokoll-Ebene lassen sich verschiedene Firewall-Typen unterscheiden. Das erste Unterscheidungs-Kriterium ist die physikalische Position der Firewall. Es gibt Firewalls, die sich auf dem Rechner selbst befinden und es gibt Firewalls, die sich zwischen dem Rechner und dem Internet befinden.

Eine Firewall, die sich auf dem Rechner selbst befindet, kann leichter kompromittiert werden. Jede andere Kernelerweiterung (Treiber) auf dem Rechner kann dazwischenfunken. Idealerweise befindet sich die Firewall zwischen dem Rechner und dem externen Netz. Eine Firewall innerhalb des Rechners ist ungefähr so sinnvoll wie ein Wassergraben innerhalb der Ritterburg anstatt außen davor.

Das zweite Unterscheidungskriterium ist die Netzwerk-Schicht, auf der die Firewall arbeitet. Typischerweise arbeitet die Firewall auf einer dieser drei Ebenen:

Da Sockets von einem Programm angefordert werden, können Socket-Firewalls sagen, welches Programm für den jeweiligen Netzverkehr zuständig ist. So kann man gezielt einzelnen Programmen den Netzwerkverkehr gestatten oder verwehren.

IP-Firewalls können Dir den Port nennen, auf dem kommuniziert wird. Daran kann man die Art der Kommunikation erkennen, weil die Ports unter 1024 eine definierte Bedeutung haben und auf Unix-Systemen aus Sicherheitsgründen normale User auf Ports unter 1024 keinen Server laufen lassen dürfen. Kommunikation auf Port 80 sind Webserver mit HTTP. SSH benutzt Port 22 und das verschlüsselte HTTPS läuft über Port 443. IP-Firewalls können folglich bestimmte Sorten von Netzverkehr erlauben oder unterbinden oder manipulieren. Unterbindet man Traffic auf Port 80, dann sind zum Beispiel alle normalen Webserver davon betroffen.

Interface-Filter greifen den Netzverkehr ab, bevor er die oberen Ebenen erreicht. Mit Interface ist hier so etwas wie en0 und en1 gemeint, hinter denen sich Ethernet oder WLAN verbirgt. Man kontrolliert damit also gezielt den Verkehr, der über eine bestimmte physikalische "Leitung" geht.

Firewalls auf den unteren Ebenen sind für den Endbenutzer wenig verständlich, bieten aber die stärkere Manipulationsmöglichkeit, weil sie unter dem Radar der höheren Ebenen "fliegen". Firewalls auf höherer Ebene sind nicht so maschinen-nah und ihre Funktion für den User eher verständlich. Informatiker können mit Paketen auf Interface-Ebene noch etwas anfangen, Administratoren und versierten Benutzern sagen Portnummern bei IP-Filtern etwas, aber nur Sockets, die pro Programm benannt werden können, sind etwas, womit der normale User etwas anfangen kann. Darum werden die "tieferen" Firewalls dem normalen Benutzer heute erst gar nicht mehr gezeigt.

Wer Firewalls programmieren möchte, kommt um Kernel-Erweiterungen nicht herum, und kann sich mit Apples Network Kernel Extensions Programming Guide einen Überblick verschaffen. Die coolen Kids sagen auch nicht Firewall, sondern Paket-Filter, weil Firewalls Netzwerk-Daten-Pakete filtern.

Firewalls in OS X

Im "Türsteher"-Artikel in Mac&i, Heft 3/2014, Seite 74 wurde über "die" Firewall von OS X geschrieben. Tatsächlich hat OS X aber mehrere Firewalls. iOS und OS X (seit Lion) benutzen den PF Packet Filter, der den ehemals favorisierten ipfw (IP Firewall) inzwischen ersetzt. Siehe dazu man pfctl (Handbuch von Packet Filter Control) im Terminal. In den System Settings macht sie sich mit der "Stealth-Mode"-Option bemerkbar; eine Option, die ich nicht aktivieren würde, weil sie Standard-Netzwerk-Funktionen abschaltet, die nötig sind, um reibungslosen Ablauf zu gewährleisten.

Dann gibt es noch die Application-Level-Firewall in /usr/libexec/ApplicationFirewall/socketfilterfw, zu der die Kernel-Erweiterung (Treiber) com.apple.nke.applicationfirewall gehört, die man mit kextstat sehen kann. In den System Settings ist diese für alle weiteren Einstellungen, die man unter Firewall findet, zuständig.

Installiert man die zusätzlichen diversen Server-Funktion für OS X, die mit der Server.app gesteuert werden und die vom File-Sharing bis zu Xcode-Entwickler-Diensten reichen, dann findet man darin noch eine weitere Firewall, die sogenannte Adaptive Firewall hier: /Applications/Server.app/Contents/ServerRoot/System/Library/CoreServices/AdaptiveFirewall.bundle. Sie besteht aus dem Firewall-Binary AdaptiveFirewall, dem Control-Utility afctl (Adaptive Firewall Control) und dem Tool hb_summary, das Statistiken über blockierte Hosts listet. Weitere Hinweise zur adaptiven Firewall in OS X Server finden sich hier.

Das Windows DCOM Problem

Windows hat eine Funktion zum verteilten Rechnen namens DCOM im System eingebaut. Dieses Distributed Component Object Model ist vergleichbar mit CORBA.

Mit DCOM kann man also Prozesse auf verschiedene Computer im Netz verteilen, Programme auf anderen Rechnern im Netz laufen lassen, diese Programme an einer gemeinsamen Aufgabe arbeiten lassen. Mit anderen Worten: DCOM ermöglicht Wurm-Programme.

Wurm-Programme sind ursprünglich nichts Böses (lokale Kopie) und wurden unter anderem vom Xerox Palo Alto Research Center (PARC) untersucht: Es sind Programme, die sich eigenständig nicht ausgelastetete Rechner im Netz suchen und auf diesen dann Kopien von sich selbst laufen lassen, die einen bestimmten Teil der Gesamtarbeit erledigen. Auf den verschiedenen Rechnern läuft dann ein Segment des Wurms.

Jede Technik kann für gute und für böse Zwecke verwendet werden. Anfang der 2000er Jahre tauchten verschiedene destruktive Windows-Würmer, also Malware auf, die DCOM benutzten.

Man kann DCOM zwar deaktivieren, aber davon rät Microsoft ab, weil das zu Problemen führen kann, denn: Es gibt viele integrierte Komponenten (von Windows) und Fremdanbieteranwendungen, die potenziell von einer Deaktivierung von DCOM betroffen sein können. Das Deaktivieren von DCOM zerbricht viele Features in Windows und verhindert das normale Arbeiten verschiedener Windows-Systemteile: In addition, mitigations, such as disabling RPC and/or DCOM on an intranet severely disrupts many features and prevents some parts of the system from operating normally.

Erfolgreiche Angriffe auf DCOM erlauben nicht nur die Fernkontrolle über Windows, sondern auch volle Systemrechte.

Nachdem in 2003 und 2004 Würmer wie Blaster und Sasser DCOM verwendeten, um Windows-Maschinen weltweit in wenigen Minuten zu übernehmen, war Microsoft gezwungen, etwas zu unternehmen. Sie konnten DCOM nicht deaktivieren, darum mußten sie es als Workaround von außen unerreichbar machen mit einer Firewall. Windows XP hatte zwar von Anfang an eine Firewall, die war aber nicht besonders alltagstauglich und aus Kompatibilitätsgründen deaktiviert. Mit Windows XP SP 2 wurde sie nun überarbeitet, verbessert und standardmäßig aktiviert.

DCOM wird bei Windows sowohl für lokale als auch für remote Kommunikation zwischen Programmen eingesetzt. Kein anderes Betriebssystem hat eine solche immer verfügbare, wurmfähige Netzwerkfunktion standardmäßig im System eingebaut. Das ist einer der Gründe, warum Windows bevorzugtes Angriffsziel ist. Es hat nichts mit Marktanteilen, sondern mit technischer Möglichkeit zu tun. Vergleichbare Wurm-Angriffe sind auf OS X beispielsweise nicht möglich, weil kein zu DCOM vergleichbarer Netzdienst existiert und standardmäßig sogar überhaupt gar kein Internet-geeigneter Dienst auf OS X aktiviert ist.

DCOM wurde von nun an von der Windows-Firewall nach außen abgeschirmt, was aber auch die normale gewünschte Netzwerkfunktion von DCOM stört.

Auf jeden Fall haben alle Windows-User auf diese Weise schmerzlich erfahren müssen, daß sie eine Firewall zum Überleben im Netz benötigen, weil sie eine zentrale gefährliche Netzfunktion ihres Betriebssystems nicht ohne große Nachteile abschalten können. Und seitdem ist alle Welt davon überzeugt, eine Firewall wäre prinzipiell nötig. Das ist sie aber nur bei einer vergeigten System-Architektur wie sie Windows hat. Gescheite Systeme haben entweder gar keine Netzfunktion aktiv oder können auch mit abgeschalteten Netzfunktionen problemlos laufen.

Angriffsoberfläche

Firewalls vergrößern die Angriffsoberfläche des Rechners, auf dem sie laufen. Sie fügen zusätzliche Verwundbarkeit hinzu. Der "Spirit" Jailbreak basierte zum Beispiel auf einem Bug in der PF Firewall, die von OpenBSD stammt und in iOS und OS X verwendet wird. Der Fehler erlaubte das Überschreiben von Kernel-Speicher. Apple hatte den Bug dann im Paket-Filter behoben und er wurde dann auch in OpenBSD gefixt. Wäre die Firewall in iOS nicht aktiv, könnte der Bug nicht genutzt werden.

Es gibt immer wieder Bugs in den verschiedenen Firewalls. Aufgrund der Rechte, die eine Firewall benötigt, ist sie ein extremes Risiko. Ihre Aufgabe, den Netzverkehr zu prüfen, macht sie außerdem für einen Angreifbar sehr leicht erreichbar. Beides zusammen ergibt eine zusätzliche Angriffsoberfläche, die man nicht ohne Nachdenken einschalten sollte. Es ist besser, unnötige Netzwerk-Dienste abzuschalten, als diese aktiv zu lassen und eine Firewall zu aktivieren. Mit dem Abschalten von Netzdiensten ist man definitiv nicht erreichbar und nicht angreifbar, während beim Anlassen von Netzdienste und Zuschalten der Firewall gleich zwei unnötige Programme für Probleme sorgen können: Netzdienst und Firewall.

Beispiel Little Snitch

Little Snitch installiert, um den Netzverkehr lesen zu können, eine Kernel-Erweiterung (kext). Dadurch hat Little Snitch root-Rechte. Little Snitch schaut sich jeden Netzverkehr an und ist darum durch jeden beliebigen Netzverkehr angreifbar. Die root-Rechte versprechen bei Erfolg fette Beute: Die volle Kontrolle über Little Snitch und den Rechner.

Wer sein System absichern will, sollte nicht dessen Angriffsoberfläche erhöhen, sondern reduzieren. Je weniger Software mit root-Rechten läuft, desto besser. Das ist ein ureigenes Unix-Prinzip. Wer sein System mit 3rd-Party-Kexts zusemmelt, kann gleich ein Einladungsschild außen anbringen, denn in jeder Software sind Fehler. Man kann das Risiko nur minimieren, indem man möglichst wenig unter root laufen läßt.

Hier sind zwei Beispiele dafür: Little Snitch machte Macs angreibar, weil es Malware Systemrechte verschafft zur Laufzeit. Und sogar der Little Snitch Installer konnte von Malware übernommen werden, um an Systemrechte zu kommen.

Kann Little Snitch wirklich allen Verkehr, der vom Rechner nach außen geht oder reinkommt kontrollieren? Prinzipbedingt: Nein! Warum? Jede Software auf dem Rechner kann kompromittiert sein. Little Snitch ist nicht das einzige Stück Code, was unter root auf dem Mac läuft. Eine Malware, die ebenfalls als Trojaner oder durch einen Bug oder sonstwie auf den Rechner kommt, und auch root-Rechte hat oder diese durch einen anderen Bug erlangt, kann Little Snitch einfach aushebeln, an den nötigen Stellen blind machen, täuschen, Netzverkehr vor Little Snitch verstecken, Litte Snitch völlig nutzlos machen.

Kann aber nicht eine andere Software vielleicht … ? Nein! Die einzige Möglichkeit, zuverlässig zu kontrollieren, was der Rechner mit dem Netz macht, ist, den Verkehr auf dem nächsten Router zum Internet zu untersuchen. Keine Firewall, keine Software auf dem Rechner selbst kann Dir sagen, welcher Traffic wirklich rein- oder rausgeht auf Deinem Computer.

Wozu ist Little Snitch überhaupt noch gut dann? Um gutmütige Software, die nichts verbergen will, zu überprüfen. Um bösartige Software damit zu checken, ist ein Ansatz, der auf dem Opfer-Rechner läuft, völlig untauglich. Ich weiß, daß viele von Euch Little Snitch lieben. Es tut mir leid.

Paranoia ohne echte Hilfe

Little Snitch zeigt nur an, welches Programm mit welchem Server kommuniziert. Völlig unklar bleibt dabei aber, was für Daten übermittelt werden. Das reicht nicht, um sich ein Urteil über den Traffic bilden zu können. Schlimmer noch: Das führt zu grundlegenden Fehleinschätzungen wie hier. Dort wurde gesehen, daß Contacts.app mit Gravatar kommuniziert und deshalb gleich vermutet, daß das ganze Adreßbuch übertragen würde. Das ist natürlich völliger Unsinn, denn Contacts.app fragt Gravatar nur, ob es ein Bild für den Hashwert einer Email-Adresse kennt. Gravatar ist ein globales, öffentliches Verzeichnis für User-Avatare. Damit kann man sein Nutzerbild zentral festlegen, so daß man es nicht in jedem Forum erneut hochladen muß.

Ich habe die Kommunikation zwischen Gravatar und Contacts.app mal untersucht. Kontakte, die kein Bild verfügbar haben, aber eine Email-Adresse aufweisen, erzeugen eine SSL-verschlüsselte Abfrage, die für mich selbst entschlüsselt dargestellt aus diesem Request besteht. Normalerweise sieht man noch nicht mal den Hashwert, sondern nur "https://secure.gravatar.com:443", da die Parameter verschlüsselt werden per SSL.

Um den Verkehr zu analysieren, habe ich den Analyse-Proxy Charles dazwischen gehängt. Außerdem mußte ich ein SSL-Zertifikat von Charles im System installieren, damit der SSL-Verkehrt aufgebrochen werden kann. Contacts.app schickt also nur einen Hashwert an Gravatar über eine verschlüsselte Ende-zu-Ende-Verbindung. Das ist mehr als weit weg vom "ganzen Adreßbuch".

Intrusion Detection / Prevention Systeme IDS/IPS

Intrusion Detection und Prevention Systeme IDS/IPS fallen auch in das Firewall-Thema, weil sie ebenfalls unbefugten Zugriff von außen verhindern oder entdecken sollen.

Für diese Software-Gattung gilt ebenso wie für Firewalls, daß sie nur wirklich alles mitbekommen kann, wenn sie mit Systemrechten, also unter root läuft. Das führt jedoch wieder zu zusätzlichen Sicherheitsrisiken, weil die Angriffsoberfläche schon wieder entscheidend und unnötigerweise vergrößert wird.

Beispiel: 4Shadow

Ein Leser fragte mich, ob ich etwas über 4Shadow sagen kann. Gehen wir die Features einmal durch, die dieses "Protect your computer and data from network threats" zu bieten hat:

SSH Login Versuche

Als erstes haben wir da "Remote Login Attempts". Angreifer könnten versuchen, sich über Netzwerk einzuloggen, indem sie versuchen, Dein Paßwort zu erraten. Was für ein Aufriß, denn standardmäßig ist SSH auf dem Mac gar nicht aktiv. Da kann sich niemand einloggen. Und die meisten User werden auch überhaupt nicht auf die Idee kommen, SSH zu aktivieren.

Wer es dennoch tut, ist Profi genug, Remote Login nur für bestimmte User zu erlauben und sichere Paßworte zu wählen. Es gibt immer Angreifer im Netz, die Wörterbuch-Attacken gegen beliebige IPs und bekannte Dienste wie SSH fahren. Es ist daher der Normalzustand, daß jemand versucht, einen aktiven SSH-Service auszunutzen.

Das bedeutet, daß dieses Feature von 4Shadow ziemlich nutzlos ist. Denn mit der Information, die 4Shadow liefert, kann man nichts nützliches anfangen: Wer kein SSH benötigt, ist per se sicher. Wer SSH einschalten muß, hat so oder so fortlaufend mit Angriffen zu rechnen. Ob mir 4Shadow das erzählt oder nicht, ist vollkommen belanglos, denn es ändert für mich nichts. Entweder ich brauche SSH oder nicht.

Man in the Middle

Hierzu schreiben sie "the network can be taken over to redirect your connection to an attacker's computer". Hier drücken sie sich etwas ungenau aus. Wenn damit gemeint ist, daß eine echte Man-in-the-Middle-Attacke passiert, dann erfolgt der Angriff im Netz und nicht auf dem Computer selbst. In dem Fall ist das sehr schwierig zu kontrollieren. Und das wenige, was man tun kann, ist schon in aktuellen Browsern eingebaut: Sie melden, wenn ein Zertifikat ungültig ist, was auf einen Fake-Server hindeuten kann.

Meinen sie jedoch nicht-standardmäßige Einträge in der /etc/hosts-Datei, mit denen man Servernamen auf Netzadressen zuordnen kann, dann hat man eh ein ganz großes Problem, denn der Zugriff darauf erfordert root. War das der Fall, ist eh man eh verloren.

Ich bezweifle also, daß sie dieses Feature halbwegs effektiv umsetzen können, denn es ist eine ziemlich unlösbare Aufgabe.

Privilege Escalation

Man soll benachrichtigt werden, wenn heimlich versucht wird, eine Aktion mit System-Rechten auszuführen. Das ist völliger Käse, denn dazu wird in der Regel ein Bug in System-Programmen ausgenutzt. Das kann man nicht kontrollieren. Sollte 4Shadow meinen, daß es um die Nutzung von sudo geht, dann ist es ebenfalls schon zu spät.

System Misconfigurations

Das ist das geilste Feature an dem Programm: Es sagt Dir Bescheid, falls Deine Firewall nicht eingeschaltet ist. Wir haben ja oben gelernt, daß es in der Regel so oder so eine dumme Idee ist, eine Personal Firewall als Sicherheits-Gewinn anzusehen. 4Shadow erzieht hiermit seine User zu paranoiden Falschklickern. Ein weiteres wertloses Feature.

Fazit

4Shadow hat nur einen Sinn: Den User etwas zu verunsichern und Features zu verkaufen, die nichts bringen bezüglich Sicherheit, wohl aber hinsichtlich Einnahmen für den Hersteller. Nein danke!

Valid XHTML 1.0!

Besucherzähler

Latest Update: 03. October 2022 at 11:24h (german time)
Link: macmark.de/osx_firewall_nonsens.php