Firewall OS X - Das kann sie wirklich

[[TB]Lucky]

Naja im nachhinein ists ja ok. Bin heute etwas fertig.... :|

Hätte vielleicht dabei schreiben sollen, das ich keinen Plan von ipfw hab.


Und ja ich werde mich mal mit ipfw beschäftigen...

Björn

 

[maceis]

und weiter gehts

hallo zusammen,

nachdem der Fred ja anscheinend schon heftig gelesen wird, hier noch einige Ergänzungen.
Gestern hatte ich das mit dem "stateful" "inspection" je ziemlich stark vereinfacht.
Da kann man noch ein bischen tiefer einsteigen (so tief, bis jemand Aua schreit).

Zum Einen kann man sagen, dass unsere inzwischen heissgeliebte ipfw eine stateful paket inspection firewall ist im Gegensatz zu einer reinen paket filtering firewall.
Der Unterschied dürfte sich manchem noch nicht so ganz offensichtlich erschließen.

Einfach gesagt, untersucht die inspection firewall auch den Inhalt von IP Paketen, während die Filtering Firewall lediglich Quell- und Zieladressen und -ports, also die IP-Header berücksichtigen kann.
Etwas genauer ausgedrückt: bei der filtering firewall ist auf dem Layer 4 des ISO/OSI Schichtenmodels Schicht im Schacht. Anwendungsbezogene Informationen (bis hinauf in den Layer 7) werden nicht ausgewertet.

Einige Daten werden allerdings von beiden Typen untersucht.
Die liste ich hier mal eben auf (sagt mir, wenn ich was vergesse)
- Quell IP Adressen
- Ziel IP Adressen
- Quell Port
- Ziel Port

Hardware Adressen (= Layer 2) werden meines Wissens von derartigen Firewalls nicht ausgewertet, was nicht heisst, dass es garantiert keine gibt die das kann.

Allerdings können schon bessere Switche sowas schon kontrollieren.
Ich hab kein WLAN, aber ich denke da ist das echt ein Thema (sonst surft der Nachbar mit, und von der Parkbank gegenüber werden Firmennetze infiltriert; (am besten noch mit dhcp he he).

Interessanter wird es aber bei den stateful inspection firewalls.

Die können eine ganze Reihe weiterer Zustände (states) und Eigenschaften einer Verbindung auswerten, die dann auch - ja nach Protokoll - unterschiedlich sind.
Und genau da gehts dann (evtl.) nächstes mal weiter.

 

[usr]

Re: und weiter gehts

Original geschrieben von maceis

Einige Daten werden allerdings von beiden Typen untersucht.
Die liste ich hier mal eben auf (sagt mir, wenn ich was vergesse)
- Quell IP Adressen
- Ziel IP Adressen
- Quell Port
- Ziel Port

 

TCP flags, div. ICMP Typen usw.

Zum stateful: den Inhalt der Pakete untersucht selbst ne billige paket filt. fw. Allerdings werden nicht die Pakete im Kontext zueinander untersucht. Es werden also nicht die Verbindungszustände erkannt und entsprechend angewand.

"Etwas genauer ausgedrückt: bei der filtering firewall ist auf dem Layer 4 des ISO/OSI Schichtenmodels Schicht im Schacht."

Auch bei einer stateful. So lange du keine Proxies verwendest, ist da Ende.

"02060 allow tcp from any to any established
> Hier kommt die erste "stateful" Analyse;
> Sie sagt: erlaube tcp-traffic in beiden Richtungen, wenn eine Paket die Eigenschaft "established" aufweist.
> einfach gesagt: erlaube Traffic, wenn die Kommunikation von innen begonnen wurde
> Beispiele wären, das abrufen von email oder Surfen im Web"

Damit wird aber auch traffic erlaubt, der von außen aufgebaut wurde.


Das ist so nicht ganz richtig. Ich kann auch ein IDS mit entsprechenden Regeln aufsetzen. Einen Nachteil gegenüber einer "Hardwarefirewall" sehe ich da nicht. Generell verschmelzen Paketfilter, VPN-Gateway und IDS immer mehr.


1. Was ist noch erlaubt ???
Wie sieht deine default policy aus?

2. Welches Bedürfnis vieler User kann so niemals befriedigt werden ?
Nicht deken zu müssen und einfach immer schön "ja" drücken?

3. Wo ist der große Haken an der ganzen Sache?
Hmm, sag schon....


Firewall würde ich eher so definieren:
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html

 

[maceis]

hallo usr

Danke für Dein feedback.

TCP flags, div. ICMP Typen usw.

Ist richtig, außerdem noch Sequenznummern und div. andere Informationen.
Hab ich zur Vereinfachung weggelassen (gute Ausrede - gell )

Zum stateful: den Inhalt der Pakete untersucht selbst ne billige paket filt. fw. Allerdings werden nicht die Pakete im Kontext zueinander untersucht. Es werden also nicht die Verbindungszustände erkannt und entsprechend angewand.

Hab mich unsauber ausgedrückt: Mit Inhalt meinte ich die eigentlichen zu übertragenden Daten, aber auch das ist nicht ganz exakt.

"Etwas genauer ausgedrückt: bei der filtering firewall ist auf dem Layer 4 des ISO/OSI Schichtenmodels Schicht im Schacht."

Auch bei einer stateful. So lange du keine Proxies verwendest, ist da Ende

Du hast mich erwischt: Ich habe mich wieder unsauber ausgedrückt; die Terminologie ist auch nicht ganz einheitlich:
genau genommen muss man wohl unterscheiden zwischen stateful filtering und stateful inspection.

Soweit ich weiss (allerdings ohne praktische Erfahrung diesbezüglich) gibt es auch bessere stateful inspection firewalls, die den Inhalt von Paketen bis hinauf zum Application Layer untersuchen.
Das heisst, sie schauen in die Datenpakete hinein und erkennen dann z. B. ob es sich auch wirklich um ein pop3 Paket handelt, das da über den port 110 hereinkommt.
Ziel ist es, Tunneling-Versuche zu unterbinden.

"02060 allow tcp from any to any established
> Hier kommt die erste "stateful" Analyse;
> Sie sagt: erlaube tcp-traffic in beiden Richtungen, wenn eine Paket die Eigenschaft "established" aufweist.
> einfach gesagt: erlaube Traffic, wenn die Kommunikation von innen begonnen wurde
> Beispiele wären, das abrufen von email oder Surfen im Web"

Damit wird aber auch traffic erlaubt, der von außen aufgebaut wurde.

Nein, der traffic wurde von innen begonnen (innitiiert).
Du gibst im Browser ein: www.macuser.de .
Du sendest also eine Anfrage an den Zielport 80 eines Webserver im Internet: schicke mir die Webseite: www.macuser.de an meinen (Quell-)port 42150 (als Beispiel)
Die Antwort auf diese Anfrage ist erlaubt , wenn Sie vom (Quell-)port 80 auf den (Ziel-)port 42150 gesendet wird und wenn das entsprechende TCP Flag (entweder SYN_ACK oder ESTABLISHED) gesetzt ist.

zu 1. Die Regel Nr. 65535 ist die default Policy, diese kann AFAIK nur durch kompilieren eines neuen Kernels bzw. der entsprechenden Extension geändert werden.
Das ist hier aber nicht gemeint, erlaubt sind noch alle Pakete, die nicht "tcp" Pakete sind.

zu 3. der Haken ist, dass man mit der GUI nur ganz stark eingeschränkt steuern kann, was erlaubt und was verboten ist.
Darüber hinaus kann man mit der GUI kein Logging einrichten; für einzelne Regeln noch weder kann man es überhaupt aktivieren.
-------------
Das mit den Definitionen ist so eine Sache.
Ich möchte da keine Philosophie daraus machen; aber ich liefere hier noch eine weitere Definition (Quelle: RFC 2828):

"$ firewall
(I) An internetwork gateway that restricts data communication
traffic to and from one of the connected networks (the one said to
be "inside" the firewall and thus protects that network's system
resources against threats from the other network (the one that is
said to be "outside" the firewall))"

frei übersetzt:
Ein Netzwerk-Gateway, das den Datenverkehr an und von einem der angeschlossenen Netzwerke das sog. (internen Netzwerk) beschränkt und dessen Ressourcen vor Angriffen aus dem anderen (dem externen Netzwerk) schützt.

 

[usr]

Dann haben wir diese Unklarheiten auch noch beseitigt, gut

"allow tcp from any to any established"
Wenn ich allerdings z.B. einen Webserver betreibe, dann werden auch Pakete angenommen, die zu einer Verbindung gehören, die von außen auf mein Webserver aufgebaut wurde, richtig? Natürlich braucht auch noch eine Regel, die enue Verbindungen auf dem externen Interface auf einen speziellen destinationport erlaubt.

Mit der Syntax kenne ich mich nicht sonderlich gut aus. Ich bin eher bei den iptables zu Hause. Ich glaub deren Aufbau ist doch anders.

 

[maceis]

Original geschrieben von usr
Dann haben wir diese Unklarheiten auch noch beseitigt, gut

"allow tcp from any to any established"
Wenn ich allerdings z.B. einen Webserver betreibe, dann werden auch Pakete angenommen, die zu einer Verbindung gehören, die von außen auf mein Webserver aufgebaut wurde, richtig? Natürlich braucht auch noch eine Regel, die enue Verbindungen auf dem externen Interface auf einen speziellen destinationport erlaubt.

Mit der Syntax kenne ich mich nicht sonderlich gut aus. Ich bin eher bei den iptables zu Hause. Ich glaub deren Aufbau ist doch anders.

 

add 02080 allow tcp from any to any 80 in
oder besser:
02080 allow tcp from any to 192.168.1.1 80 in
Und dann noch dem Webserver beibringen, dass er genau auf diese IP Adresse hören soll, und diese als zweite IP Adresse auf die Ethernetschnittstelle geben.
ifconfig en0 192.168.1.1/24 alias
Ist in kleinen privaten Umgebungen aber nicht wirklich notwendig.

Die Grafische Oberfläche macht auch noch den Port 427 auf;
/etc/services sagt dazu:
svrloc 427/udp # Server Location
Wozu man den Port braucht weiss ich aber nicht.
Es geht auch ohne den.

 

[Rakor]

Original geschrieben von usr
Wenn ich allerdings z.B. einen Webserver betreibe, dann werden auch Pakete angenommen, die zu einer Verbindung gehören, die von außen auf mein Webserver aufgebaut wurde, richtig? Natürlich braucht auch noch eine Regel, die enue Verbindungen auf dem externen Interface auf einen speziellen destinationport erlaubt.

 

Wenn du nen Webserver betreibst musst du extra Port 80 nach aussen frei geben, so dass von extern Verbindungen auf den Port möglich sind. Da der Webserver aber nur über Port 80 kommuniziert ist der Rest egal.... Oder hab ich jetzt dein Anliegen falsch verstanden?

 

[Tiracon]

auf die gefahr hin zu weit abzuschweifen... aber würden nicht zusatzprogamme ala littlesnitch
die firewall relativ easy ergänzen?

grüsse
Tira

 

[Sternenwanderer]

Original geschrieben von Tiracon
auf die gefahr hin zu weit abzuschweifen... aber würden nicht zusatzprogamme ala littlesnitch
die firewall relativ easy ergänzen?

grüsse
Tira

 

Ähhh ja, genau, das wäre dann auch meine Frage gewesen, trotzdem verneig vor soviel Wissen und Support...

 

[maceis]

hallo zusammen,

@Raktor:

Wenn du nen Webserver betreibst musst du extra Port 80 nach aussen frei geben, so dass von extern Verbindungen auf den Port möglich sind. Da der Webserver aber nur über Port 80 kommuniziert ist der Rest egal..

Hab´ich doch:
add 02080 allow tcp from any to any 80 in
Man kann allerdings auch anderen Ports verwenden (z. B. wenn man möchte, dass nur Personen zugreifen können, die die richtige Portnummer wissen, oder um Exploits zu erschweren)

-------------------
ich habe mir Little Snitch nur mal ein wenig angesehen.
Ich trau der Sche nicht so ganz, zumal eindeutig manche Verbindungsaufbauten durchrutschen (kann auch an der Grundkonfigration liegen, die man evtl. anpassen kann)

Generell ist der Betrieb von zwei "Firewalls" auf einem System immer kritisch zu betrachten, weil unerwünschte, undokumentierte und vor allem unbemerkte Nebeneffekte auftreten können.

Was soll zum Beispiel passieren, wenn die eine Firewall traffic erlaubt, den die andere verbietet ?
Wie steuert man, welche Firewall zuerst filtert ?

Abgesehen sehe ich den Einsatz LittleSnitch weniger im Server Bereich , sondern da, wo User sich informieren wollen, welche Programme eine Verbindung aufmachen wollen und evtl. genau das steuern möchten.
Wie LittleSnitch das herausfindet weiss ich nicht (hab´ da nur ne Ahnung)
Aber das werd ich schon noch rausfinden.
Wäre enorm interessant, um sich da evtl. selber was zu basteln.

Ich bin mir jedenfalls ziemlich sicher, dass Little Snitch nichts mitbringt, was die Unix Basis nicht auch zu leisten vermag.

 

[Rakor]

Original geschrieben von maceis
@Raktor:
Hab´ich doch:
add 02080 allow tcp from any to any 80 in
Man kann allerdings auch anderen Ports verwenden (z. B. wenn man möchte, dass nur Personen zugreifen können, die die richtige Portnummer wissen, oder um Exploits zu erschweren)

 

Ich weiss.. oder wenn man mehrere Webserver nebeneinander laufen lassen will (oder muss z.B. Webinterfaces zur konfuguration..)

Sorry, aber als ich geantwortet hatte war deina Antwort noch nicht da Bin halt wohl kein so schneller Tipper

BTW: Schau mal links.... Mein Name ist Rakor (ohne "t") Irgendwie macht das jeder falsch.... Aber ich bin ja nicht nachtraged

Original geschrieben von maceis
Ich bin mir jedenfalls ziemlich sicher, dass Little Snitch nichts mitbringt, was die Unix Basis nicht auch zu leisten vermag.

 

Ich hab nicht viel Ahnung von der IPFW aus der BSD-Ecke, aber soweit ich weiss ist es ein Packetfilter der, wie eigentlich alle Packetfilter, auf Ebene 3-4 arbeitet und dabei nicht auf Anwendungsebene arbeiten kann (was die verbreiteten "grafischen Firewalls" machen. Meines Wissens ist es nicht möglich über einfache Wege eine Anwendunsgesteuerte Filterung mit einem Packetfilter zu erzeugen.

 

[Tiracon]

auf alle fälle scheints du echt plan davon zu haben *respekt*
littlesnitch ist wohl an den endanwender gedacht der relativ einfach ein "nachhausetelefonieren" verhindern möchte. ich habe allerdings noch kein programm gehabt das ohne meine aktivität eine verbindung aufbauen wollte.

grüsse Tira

 

[maceis]

Original geschrieben von Rakor
 
Ich hab nicht viel Ahnung von der IPFW aus der BSD-Ecke, aber soweit ich weiss ist es ein Packetfilter der, wie eigentlich alle Packetfilter, auf Ebene 3-4 arbeitet und dabei nicht auf Anwendungsebene arbeiten kann (was die verbreiteten "grafischen Firewalls" machen. Meines Wissens ist es nicht möglich über einfache Wege eine Anwendunsgesteuerte Filterung mit einem Packetfilter zu erzeugen.

 

Für die, die es ganz genau wissen möchten:
Das kann die ipfw von Mac OS X:

Each packet can be filtered based on the following information that is
     associated with it:

           Transmit and receive interface     (by name or address)
           Direction                          (incoming or outgoing)
           Source and destination IP address  (possibly masked)
           Protocol                           (TCP, UDP, ICMP, etc.)
           Source and destination port        (lists, ranges or masks)
           TCP flags
           IP fragment flag
           IP options
           ICMP types
           User ID of the socket associated with the packet

     Note that it may be dangerous to filter on the source IP address or
     source TCP/UDP port because either or both could easily be spoofed.

... und dabei nicht auf Anwendungsebene arbeiten kann..

Manche sollen das können; ich seh mal zu, ob ich was zu dem Thema finden kann - interessiert mich nämlich selber.

 

[usr]

maceis,
jop, ist klar dass ich den destinationport eingehend freischalten muss. Wie ist das eigentlich bei IPFW: reicht es, wenn man ein mal z.B. Port 80 eigehend auf dem externen interface freischaltet? Oder brauchts da auch noch established states wie bei den iptables?

 

[Rakor]

Original geschrieben von usr
maceis,
jop, ist klar dass ich den destinationport eingehend freischalten muss. Wie ist das eigentlich bei IPFW: reicht es, wenn man ein mal z.B. Port 80 eigehend auf dem externen interface freischaltet? Oder brauchts da auch noch established states wie bei den iptables?

 

Ich meld mich da mal einfach zu Worte...

Wieso brauchst du bei iptables ein established state? Das halte ich in diesem Falle für unnötig. Du willst ja deinen Dienst für alle eingehenden Verbindungen erlauben. Also gibst du den Port direkt frei.
Die established Funktionen sind nur dann sinnvoll wenn du Antworten auf (meistvon innen) aufgebaute Verbindungen erlauben willst.
Dein Webserver hat ja aber keine bereits aufgebaute Verbindung. Eher umgekeht... Wer deinen Server besuchen will muss erst eine Verbindung aufbauen. Und dafür muss der Port für alle offen sein.
Oder seh ich was falsch?

 

[maceis]

hallo zusammen,

kurze Zwischenfrage:

Was nützt es, wenn die Anfrage den (Web)-Server zwar erreicht, aber die Antwort des Servers (die Webseite) von der Firewall ge"drop"t wird ?

 

[Rakor]

Original geschrieben von maceis

Was nützt es, wenn die Anfrage den (Web)-Server zwar erreicht, aber die Antwort des Servers (die Webseite) von der Firewall ge"drop"t wird ?

 

Sag ich doch.. Der Port muss komplett offen sein

 

[maceis]

hallo Rakor,

nein, nicht wirklich;

allow tcp any to any 80 in

und

allow tcp any to any out established

würden auch genügen.

Die erste Antwort geht dann mit dem TCP Flag SYN_ACK nach außen.

Frei nach dem Motto:
So restriktiv wie möglich, so offen wie nötig

oder sogar als nur
allow tcp any to any 80 in
allow tcp any to any 80 out established
deny tcp any to any out
Wenn die User z. B kein Email und kein ftp oder gar filesharing können dürfen.

 

[Rakor]

Jo hast ja Recht....

Ich wusste ja nicht, dass du es so genau willst.

 

[usr]

Raktor,
den established state braucht man. Das erste Paket wird als state NEW behandelt, alle nachfolgenden als ESTABLISHED. Ich habe es getestet: default policy drop, Regel in der INPUT chain für einen Apache mit HHTPS auf Port 443 lauschend mit match state NEW. Ich konnte nicht auf die Kiste zugreifen, via Internet. Erst nach einem zusätzlichen state match ESTABLISHED für die INPUT chain konnte ich eine Verbindung aufbauen.