Discussion:
Firewall -> ipfw vs. GUI Frontend
(zu alt für eine Antwort)
Thomas Wildgruber
2012-09-11 08:57:07 UTC
Permalink
Hi Group,

ist das GUI Frontend der Onboard Firewall (hier im Beispiel in 10.8) kein
Frontend der aus BSD stammenden ipfw, welche über das CLI konfiguriert
wird? Ich versuche gerade die Regeln nachzuvollziehen, welche durch die GUI
angelegt werden aber das 'ipfw list' Kommando zeigt mir immer nur noch die
Standardregel '65535 allow ip from any to any' an, obwohl ich in der GUI
die Option 'Alle eingehenden Verbindungen blockieren' aktiviert habe.
Scheinbar sind das zwei paar Stiefel...

Gibt es dann für die Apple eigene GUI Firewall auch CLI Kommandos? Kann man
sich das Regelwerk der GUI-basierten Firewall auch irgendwie so anzeigen
lassen? Auch finde ich keine Möglichkeit nach dem aktivieren der Option
'Alle eingehenden Verbindung blockieren' selektiv wieder einzelne Ports zu
öffnen; das wäre ja idR die Standardprozedur.

Thx & Bye Tom
--
"Manches Gewissen ist nur rein, weil es nie benutzt wurde" (Robert Lembke)
Daniel K®ebs
2012-09-11 12:45:37 UTC
Permalink
Post by Thomas Wildgruber
ist das GUI Frontend der Onboard Firewall (hier im Beispiel in 10.8) kein
Frontend der aus BSD stammenden ipfw, welche über das CLI konfiguriert
wird?
nein
Ipfw wird schon seit 10.5 nicht mehr per default genutzt.
Kannst Du aber gern machen.
Daniel
--
'Nur Dienstboten müssen ständig erreichbar sein!'

theos Vater
Thomas Wildgruber
2012-09-11 13:28:02 UTC
Permalink
Post by Daniel K®ebs
Post by Thomas Wildgruber
ist das GUI Frontend der Onboard Firewall (hier im Beispiel in 10.8) kein
Frontend der aus BSD stammenden ipfw, welche über das CLI konfiguriert
wird?
nein
Ipfw wird schon seit 10.5 nicht mehr per default genutzt.
Kannst Du aber gern machen.
War das jetzt ironisch gemeint? ;-)

Gut aber wir können demnach festhalten, dass die Apple-Firewall kein so
einfach einzusehendes Regelwerk anlegt, wie man es von Iptables oder auch
ipfw gewohnt ist. In irgendeiner plist wird es vermutlich schon stehen aber
das wird man vermutlich nicht als Referenz zB zum Debuggen heranziehen.
Zumindest habe ich diesbzgl. nicht wirklich etwas gefunden.

Da hier im Azubi Programm zZ Paketfilter an der Reihe sind, scheidet die
Apple Firewall erstmal sowieso aus, denn das scheint wohl gar kein
Paketfilter zu sein, zumindest nicht im klassischen Sinne einer der die
TCP/IP Header auswertet. Da scheint es wohl eher um Programme bzw deren
PIDs zu gehen.

BTW: Ist launchd auch so etwas wie ein TCP-Wrapper? Wenn ich SSH in der
Systemsteuerung -> Freigabe unter 'entfernter Anmeldung' freigebe, läuft
der Deamon noch nicht aber der Port 22 ist bereits als geöffnet markiert?

Ist jedoch die Apple-Firewall eingeschaltet ist der Port 22 nicht mehr
verfügbar, der sshd-Prozess läuft logischerweise immer noch nicht. Da
könnte man dann ja auf die Idee kommen, dass die Apple-Firewall einfach
hergeht und den SSH-Dienst aus der launchd-Konfiguration zu nehmen und
diesen somit am Starten zu hindern. Nur mal so ins Blaue getippt, ein
schneller Blick in die Ausgabe von 'launchctl list' hat das erstmal nicht
bestätigt.

Thx & Bye Tom
--
"Sie wissen, wir leben im Zeitalter der Abkürzungen. Ehe ist die Kurzform
für lateinische "errare humanum est" ("Irren ist menschlich")." (Robert
Lembke)
Thomas Kaiser
2012-09-16 07:08:22 UTC
Permalink
Post by Thomas Wildgruber
Gut aber wir können demnach festhalten, dass die Apple-Firewall kein
so einfach einzusehendes Regelwerk anlegt, wie man es von Iptables
oder auch ipfw gewohnt ist.
Das Regelwerk kannst Du schon einsehen:

/usr/libexec/ApplicationFirewall/socketfilterfw -i
/usr/libexec/ApplicationFirewall/socketfilterfw --listapps

Allerdings vergleichst Du grad Äpfel (ALF) mit Birnen (ipfw/iptables).
Du kannst ipfw natürlich parallel zur ALF nutzen, bei MacOS X Server ist
in Form von "Server Admin" auch ein GUI beigefügt, um die ipfw-Regeln zu
bearbeiten. Diesbzgl. und auch um zu kapieren, wie ipfw "gestartet"
wird, würde ich Dir das da empfehlen:

http://www.peachpit.com/articles/article.aspx?p=1573022&seqNum=2

Gruss,

Thomas
Thomas Wildgruber
2012-09-16 09:51:15 UTC
Permalink
Post by Thomas Kaiser
Post by Thomas Wildgruber
Gut aber wir können demnach festhalten, dass die Apple-Firewall kein
so einfach einzusehendes Regelwerk anlegt, wie man es von Iptables
oder auch ipfw gewohnt ist.
/usr/libexec/ApplicationFirewall/socketfilterfw -i
/usr/libexec/ApplicationFirewall/socketfilterfw --listapps
Sehr schön, mal schauen, ob das dann auch brauchbar ist. Microsoft hat in
Windows 7 auch ein CLI für seine Firewall aber übersichtlich ist die
Ausgabe des Regelwerks nicht wirklich...
Post by Thomas Kaiser
Allerdings vergleichst Du grad Äpfel (ALF) mit Birnen (ipfw/iptables).
Schon klar, ich arbeite mich gerade nur mit einem Azubi durch
Firewallkonzepte und da waren wir bei Paketfilter unter Linux/Netfilter
(Iptables) stehen geblieben und wollten uns dann noch IPFW unter Mac OS
anschauen. Da ich aber stark mit der Frage rechne, was der Unterschied
zwischen IPFW und der GUI-basierten Variante in Mac OS ist (und ich das
jetzt auch nicht so genau weiß), wollte ich mich darauf vorbereiten.

Interessant sind vor allem die Grenzen eines Paketfilters auf Netzwerkebene
(Protokolle, Ports und Flags; Layer 4 eben) und die Möglichkeiten nach
Anwendungen zu filtern. Microsoft geht da scheinbar einen ähnlichen Weg wie
Apple. Wobei ich aber davon ausgehe, ohne mich jetzt schon tiefer
eingearbeitet zu haben, doch wieder Unterschiede zu "echten" Layer-7
Firewalls deutlich werden.

Letztere können zB einzelne "Dialekte" eines Protokolls verstehen und
filtern (zB MIME-Typen im HTTP Protokoll). Wobei das zumindest bei uns auch
nicht wirklich zuverlässig klappt, so erinnere ich mich daran, wie ich
erfolglos in unserem TMG den MIME-Typ Audio sperren wollte um
Internetradios zu unterbinden. Da gibt es offensichtlich wieder zig
Unterdialekte, denn manche blieben draussen, manche kamen aber dennoch
durch. Ich habs dann aufgegeben, zumal ich selbst Radio höre ;-)
Post by Thomas Kaiser
Du kannst ipfw natürlich parallel zur ALF nutzen, bei MacOS X Server ist
in Form von "Server Admin" auch ein GUI beigefügt, um die ipfw-Regeln zu
bearbeiten. Diesbzgl. und auch um zu kapieren, wie ipfw "gestartet"
Mac OS Ser4ver haben wir hier nicht aber wir brauchen auch keine GUI. Wo es
möglich ist, lasse ich die Azubis im CLI "zu Fuss gehen", später können sie
sich dann eine GUI zulegen, wenn sie das Prinzip verstanden haben und es
dann noch wollen. IdR bleiben sie dann aber im CLI.

Starten bzw. Initialisieren tun wir hier übrigens die IPFW mit einem
normalen Launchd Startskript in /Library/LaunchDaemons
Post by Thomas Kaiser
http://www.peachpit.com/articles/article.aspx?p=1573022&seqNum=2
Gute Lektüre, kling spannend, nach dem ich es jetzt grad mal überflogen
habe, auch die beiden anderen Links. Damit bin ich erstmal beschäftigt...

Thx & bye Tom
--
"Ich weiß nicht, was der französische Staatspräsident Mitterand denkt, aber
ich denke dasselbe." (Helmut Kohl)
Thomas Kaiser
2012-09-16 12:37:16 UTC
Permalink
Post by Thomas Wildgruber
Post by Thomas Kaiser
Allerdings vergleichst Du grad Äpfel (ALF) mit Birnen (ipfw/iptables).
Schon klar, ich arbeite mich gerade nur mit einem Azubi durch
Firewallkonzepte und da waren wir bei Paketfilter unter Linux/
Netfilter (Iptables) stehen geblieben und wollten uns dann noch IPFW
unter Mac OS anschauen.
Da würde ich ihn ja eher Richtung pf stubsen und ihm pfSense in einer VM
zum Spielen kredenzen (http://www.pfsense.org).
Post by Thomas Wildgruber
Da ich aber stark mit der Frage rechne, was der Unterschied zwischen
IPFW und der GUI-basierten Variante in Mac OS ist (und ich das jetzt
auch nicht so genau weiß), wollte ich mich darauf vorbereiten.
Guter Plan. Und genau dafür taugt Apples ALF-Ansatz (und das ganze
Drumherum wie bspw. Code Signing als auch Ansätze wie "geschlossene
Plattform" -- siehe [Mac] App Store -- sehr gut). Paketfilter haben ja
so ihre Grenzen und sind an manchen Stellen (bspw. an beiden Seiten
einer DMZ) sinniger als an anderen (bspw. einem typischen mobilen
Arbeitsplatz, den ein in in Sicherheitsfragen völlig unbeleckter
Anwender mit sich rumschleppt).
Post by Thomas Wildgruber
Interessant sind vor allem die Grenzen eines Paketfilters
Ja und das ganz generell. Daß in MacOS X Server eine GUI für ipfw2
eingebaut ist oder auch der depperte "Stealth Modus" der ALF dürfte wohl
der Erwartungshaltung der Kunden geschuldet sein, die Paketfilter als
auch "Unsichtbarkeit" fälschlicherweise 1:1 mit Sicherheit gleichsetzen.
Das Beste, was Du Deinem Azubi in dem Kontext beibiegen kannst, sind die
Grenzen des Konzepts und die Notwendigkeiten, jegliches "so machen wir
das schon immer" kritisch zu hinterfragen als auch sich als Admin ein
Leben lang weiterzubilden.
Post by Thomas Wildgruber
Letztere können zB einzelne "Dialekte" eines Protokolls verstehen und
filtern (zB MIME-Typen im HTTP Protokoll).
Ist doch alles Lalilü bzw. Augenwischerei und hat wenig bis gar nichts
mit Sicherheit zu tun. Bei allen größeren Kunden, die eine eigene "IT
Security"-Abteilung haben, stehen die Netze offen wie Scheunentore, weil
die Herren Admins sich auf Filterei nach Adressen und Ports kaprizieren
und sich davon allen Ernstes Schutz versprechen. Mir erschwert das
völlig unnötigerweise nur die Arbeit (weil man sich diverse Systeme bzw.
Dienste auf anderen Kisten erstmal hertunneln muß oder ZIP-Attachments
in .zap-Attachments umbenennen muß, damit diese den "Content-Filter"
passieren) und an Sicherheit ist rein gar nichts gewonnen, weil bei der
ganzen Fokussierung auf den Filter-Quatsch völlig übersehen wird, daß
Einfallstore ganz anderer Dimension die komplette IT-Infrastruktur
verwundbar machen.
Post by Thomas Wildgruber
Starten bzw. Initialisieren tun wir hier übrigens die IPFW mit einem
normalen Launchd Startskript in /Library/LaunchDaemons
Ja, logo. Launchd als eierlegende Wollmilchsau taugt ja nicht nur dazu,
init, cron, at, inetd/xinetd, etc. zu ersetzen sondern bspw. auch noch
intelligenter anhand der WatchPaths-Direktive auf Ereignisse zu
reagieren (bspw. indem man /etc/resolv.conf bzw. /var/run/resolv.conf
überwacht, um ein Skript triggern zu lassen, das bei jeder Änderung
dieser Datei -- gleichbedeutend mit Änderung der Netzwerk-Umgebung bzw.
relevanter Parameter wie anderes WLAN/Netzwerk -- die Firewall-Settings
anpaßt oder ALF und/oder ipfw2 einfach nur an-/abschaltet). Ändert aber
alles nix dran, daß die ipfw2 im Kernel verankert ist und Du mittels
/sbin/ipfw rumfuchteln kannst wie Du willst und sich genau nix tun wird,
solange ein

sysctl net.inet.ip.fw.enable

nicht "1" ausspuckt ;-)

Gruss,

Thomas

Thomas Kaiser
2012-09-16 07:01:11 UTC
Permalink
Post by Thomas Wildgruber
Gibt es dann für die Apple eigene GUI Firewall auch CLI Kommandos?
Wenn Du nach bspw. »apple firewall cli« googlest, landest Du sehr
schnell hier

http://krypted.com/mac-os-x/command-line-alf-on-mac-os-x/

und hier

http://support.apple.com/kb/HT1810

HTH,

Thomas
Loading...