Ein zweiter Blick auf die Firewall in Mac OS X Leopard

Sicherheit im Allgemeinen und die neue Firewall im Besonderen sind Features mit denen Apple die neueste Mac-OS-X-Version namens Leopard bewirbt. Doch bereits ein erster Funktionstest enthüllt Bedenkliches.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 10 Min.
Inhaltsverzeichnis

Die wichtigste Aufgabe einer Firewall ist es, ungebetenen Gästen Zugang zu verwehren. Das bedeutet vor allem, dass sie lokale Dienste vor Zugriffen aus potentiell feindlichen Netzen wie dem Internet oder Funknetzen abschottet.

Bereits ein Blick auf die Konfiguration der Firewall von Mac OS X Leopard zeigt, dass die das nicht leisten kann. Sie steht nämlich standardmäßig nach wie vor auf "Alle eingehenden Verbindungen erlauben", ist also abgeschaltet. Schlimmer noch: Selbst bei Anwendern, die die Firewall sicherheitshalber auf ihrem Mac bereits eingeschaltet hatten, startet Leopard nach dem OS-X-Upgrade wieder ohne Schutz.

Anders als beispielsweise Windows Vista unterscheidet Leopard bei den Firewall-Einstellungen auch nicht zwischen vertrauenswürdigen Netzen wie dem geschützten in der Firma und dem potentiell gefährlichen Funknetz am Flughafen oder gar einer direkten Internet-Verbindung. Leopard präsentiert sich erstmal offenherzig und bringt allen Netzen das gleiche Vertrauen entgegen.

Die Firewall findet sich unter Systemeinstellungen/Sicherheit.

Der erste Schritt nach der Inbetriebnahme von Leopard sollte also das Aktivieren der Firewall sein. Dazu bietet sich die Einstellung "Zugriff auf bestimmte Dienste und Programme festlegen" an, die mehr Kontrolle über den Netzwerkverkehr verspricht. In die Liste der freigeschalteten trägt Mac OS X selbstständig alle vom Anwender eingerichteten Freigaben wie etwa die "Entfernte Anmeldung" für den SSH-Server ein.

Doch bereits der erste Funktionstest erschütterte das Gefühl von mehr Sicherheit. Ein testweise gestarteter Server-Dienst ließ sich von außen problemlos ansprechen. Die Firewall protokolliert diesen Vorgang zwar mit

Oct 29 11:05:54 Qf98e Firewall[44]: Allow nc listening from 0.0.0.0:1414 uid = 501 proto=6
Oct 29 11:06:04 Qf98e Firewall[44]: Allow nc connecting from 193.99.145.XXX:37200 uid = 0 proto=6

sieht jedoch offenbar keine Veranlassung, ihn zu unterbinden. Denkbar, dass Apple der Ansicht ist, dass jeder vom Anwender gestartete Prozess automatisch in die Ausnahmeliste gehört. Das träfe dann allerdings auch auf ein Trojanisches Pferd zu, das beispielsweise heimlich eine Hintertür auf dem System einrichtet. Was da im einzelnen vorgeht, kann letztlich wohl nur Apple erklären.

Die Tests förderten noch weitere Ungereimtheiten zutage. Um nachzusehen, ob unerwünschte Dienste laufen, dürften die meisten Apple-User das grafische Frontend ("Systemeinstellungen/Sharing") konsultieren. Doch selbst wenn da nichts aktiviert ist, laufen im Hintergrund einige Dienste, die übers Netz erreichbar sein wollen. Sie lassen sich beispielsweise mit dem Kommandozeilen-Tools lsof aufspüren:

$ sudo lsof -i udp
COMMAND PID USER NODE NAME
mDNSRespo 37 _mdnsresponder UDP *:mdns
ntpd 46 root UDP *:ntp
nmbd 685 root UDP *:netbios-ns
nmbd 685 root UDP *:netbios-dgm
...

Da findet sich unter anderem ein Zeit-Server und die Netbios-Namensauflösung aus dem Samba-Paket (die Ausgabe des Befehls wurde gekürzt). Unter welchen Umständen Mac OS X welche Dienste startet, ist nicht ganz klar; der Zeit-Server lief jedoch bei unseren Tests immer. Direkt nach der Installation war auf dem Testsystem sogar ein Kerberos-Server aktiv, der allerdings bei weiteren Systemstarts dann nicht mehr gestartet wurde.

Obwohl keiner dieser Dienste in der Ausnahmeliste der Firewall auftaucht, konnten wir ungehindert mit ihnen sprechen. Der Zeit-Server gab uns sogar im Internet die Uhrzeit

$ sudo ntpdate 89.53.249.142
29 Oct 11:12:49 ntpdate[25731]: step time server 89.53.249.142 offset -0.776527 sec

und auch der Netbios-Dienst zeigte sich trotz Firewall auskunftsbereit:

$ nmblookup -U 192.168.69.21 -A 192.168.69.21
Looking up status of 192.168.69.21
LOCALHOST <20> - H <ACTIVE>
LOCALHOST <00> - H <ACTIVE>
LOCALHOST <03> - H <ACTIVE>
..__MSBROWSE__. <01> - <GROUP> H <ACTIVE>
WORKGROUP <1d> - H <ACTIVE>
WORKGROUP <1e> - <GROUP> H <ACTIVE>
WORKGROUP <00> - <GROUP> H <ACTIVE>

Eine Sonderrolle spielt Bonjour -- auch als MDNS oder Zeroconf bekannt. Es posaunt zwar weiterhin via Broadcast die Verfügbarkeit von Diensten wie SSH im lokalen Netz herum, doch eine Antwort auf eingehende Pakete konnten wir ihm ohne tiefergehende Kenntnis des Protokolls nicht entlocken.

Wer also auf Nummer sicher gehen will, schaltet die Firewall lieber richtig scharf und wählt die Option "Alle eingehenden Verbindungen blockieren" -- in der Hoffnung, dass dies auch wirklich alle eingehenden Anfragen an Netzwerkdienste abweist.

Die ersten Tests verliefen vielversprechend: Der testweise aktivierte SSH-Server und die primitive Demo-Hintertür waren von außen nicht mehr zu erreichen; selbst den Zugang zu einem Test-Server auf einem UDP-Port unterband die Firewall:

Oct 29 11:26:49 Qf98e Firewall[44]: Deny nc data in from 193.99.145.XXX:28524 uid = 0 proto=17

Doch schon ein einfacher Port-Scan weckte wieder erste Zweifel:

# nmap -sU 192.168.69.21
PORT STATE SERVICE
123/udp open|filtered ntp
137/udp open|filtered netbios-ns
138/udp open|filtered netbios-dgm
631/udp open|filtered unknown
5353/udp open|filtered zeroconf
MAC Address: 00:17:F2:DF:CD:B3 (Apple Computer)

Da waren also anscheinend die Ports der bereits entdeckten Systemdienste weiterhin erreichbar. Und in der Tat war es selbst bei dieser Firewall-Einstellung möglich, über eine Internet-Verbindung mit dem Zeit-Server ntpd zu kommunizieren:

$ sudo tcpdump -i ppp0
10:13:06.944735 IP XXX.heise.de.18099 > Qc39a.q.pppool.de.ntp: NTPv4, Client, length 48
10:13:06.945007 IP Qc39a.q.pppool.de.ntp > XXX.heise.de.18099: NTPv4, Server, length 48

Trotz Firewall antwortet die Namensauflösung.

Startet Mac OS X dann auch noch die Netbios Namensauflösung, kann man auch die unabhängig von der Firewall-Einstellung erreichen. Der Netbios-Dienst wird beispielsweise in verkabelten lokalen Netzen automatisch aktiviert.

Bei den Tests tauchten auch einige Merkwürdigkeiten auf. So verweigerte ein frisch gebootetes MacBook die Zeitsynchronisierung -- nur um sie wenig später dann ohne erkennbaren Grund doch zu gestatten. Die Sicherheitseinstellungen wurden in der Zwischenzeit jedenfalls nicht geändert. Des weiteren ist nicht klar, wann Mac OS X welche Dienste startet und wie es entscheidet, welche davon erreichbar sein sollten und welche nicht.

Konkret bedeuten die Ergebnisse, dass man sich nicht auf die Firewall verlassen kann. Selbst wenn man "Alle eingehenden Verbindungen blockieren" anwählt, können potentielle Angreifer weiterhin mit Systemdiensten wie dem Zeit-Server und unter Umständen auch mit der Netbios-Namensauflösung kommunizieren.