Applikations Firewall - warum nicht?

BrainPain

Well-Known Member
Hallo Leute,

anlässlich der aktuellen Diskussion um die online Durchsuchungen muss ich mich wieder fragen warum eigentlich im BSD/Linux-Umfeld immer alle gegen die von Windows bekannten Firewalls hetzen die auf Applikationsebene blocken. Ich glaube es handelt sich nur um eine Wissenslücke meinerseits, da ich momentan die Idee eigentlich garnicht so schlecht finde. Kann mich jemand aufklären?

Viele Grüße
 
Weil sie keinen Sicherheitsgewinn bringen. Wenn du 5 mal die Meldung 'Applikation {kryptischer Name} möchte auf das Internet zugreifen...' gesehen hast, dann blockierst du entweder alles (nichts funktioniert mehr) oder klickst nur noch stoisch auf erlauben. → Hat also nichts gebracht.
 
Weil sie keinen Sicherheitsgewinn bringen. Wenn du 5 mal die Meldung 'Applikation {kryptischer Name} möchte auf das Internet zugreifen...' gesehen hast, dann blockierst du entweder alles (nichts funktioniert mehr) oder klickst nur noch stoisch auf erlauben. → Hat also nichts gebracht.

Nur mal langsam mit den jungen Pferden....
Vergleichbares gibt es auch unter Unix und im Kontext der angesprochenen Threads mehr als nur zu entfehlen!

Die Rede ist von Tripwire

http://www.dfn-cert.de/dfn/berichte/db078/firewall/node12.html

oder

http://www.luug-hn.org/artikel/tripwire/tripwire.html

gruss rudy
 
Weil sie keinen Sicherheitsgewinn bringen. Wenn du 5 mal die Meldung 'Applikation {kryptischer Name} möchte auf das Internet zugreifen...' gesehen hast, dann blockierst du entweder alles (nichts funktioniert mehr) oder klickst nur noch stoisch auf erlauben. → Hat also nichts gebracht.

kann ich nicht nachempfinden, ich habe seit jahren unter windows die personal fw von kerio und bin glücklitsch und zufrieden. was reden darf darf, was nicht eben nicht und gut ist. kann man ja alles wieder erlauben wenn mans mal geblockt hat. der mensch ist ein gewohnheits tier und wenn er halt drei mal am tag accept oder deny klicken muss bringt ihn das nicht um. ausserdem solte er nach ner weile wissen was auf seiner kiste läuft.

wer sich mit kryptischen namen nicht auseinandersetzen will hat sowieso verloren und eigentlich keine berechtigung nach sicherheit zu schreien.

mittlerweile weiss jeder 0815 user das sicherheit ein grosses thame ist und wenn er sich weigert sich damit auseinander zu setzen hat er es verdient, das mit seinem pc schindluder getrieben wird.

ausserdem finde ich so sachen wie "fubbsidubbsi will blablubb.exe ausführen, darf es das?" sehr nützlich. sowas unter *bsd währe auch ganz nett.
 
Last edited:

Ich habe es zwar nur grob überflogen aber so wie ich das sehe läuft es doch letztendlich auf Windows- oder PersonalFirewall- Sicherheitslücken hinaus.

heise said:
Ohne irgendwelche Warnungen der Personal Firewall nimmt ein Programm dabei Kontakt mit seinem Heimat-Server auf und könnte auch gleich beliebige Daten übermitteln. Der Trick: Das Programm erstellt eine HTML-Datei mit einem IFRAME, die es als Active-Desktop installiert. Dabei ruft das System die im IFRAME-Tag angegebene URL auf.
Das würde doch garnicht auf *BSD funktionieren, oder? Klar das jedes zusätzliche Programm ein zusätzliches Sicherheitsrisiko darstellt aber das ist ja nicht nur bei PFs der Fall.

Könnte man nicht einfach pf oder ipfw um ein optionales Applikations-Attribut erweitern so dass man festlegen kann das z.B. Applikation A über http kommunizieren darf und Applikation B nicht? Oder ist das ne total blöde Idee?

Viele Grüße
 
PF kann keinen Traffic von localhost filtern, bloß die Antworten aus dem Netz können soweit ich weiß blockiert werden.
 
PF kann keinen Traffic von localhost filtern, bloß die Antworten aus dem Netz können soweit ich weiß blockiert werden.

Oh mein Gott, du meinst doch wohl hoffentlich nicht den Packet Filter mit dieser Aussage ...

PF-Handbuch

Du musst schon "set skip on lo0 all" setzen, um den localhost zu ignorieren.
 
Ist das dein Ernst? Warum kann ich dann kein redirect von localhost machen:

rdr on lo0 proto tcp from 127.0.0.1 to any port 80 -> 127.0.0.1 port 3128
 
Wenn du wirklich willst, dass der gesamte Traffic auf localhost geleitet wird, dann solltest du das richtige Interface angeben. Ich bezweifle nämlich, dass ein Zugriff auf zum Beispiel google.de auf lo0 entlangläuft. Stattdessen musst du das Netzwerkinterface angeben. Und du kannst dann auch gleich die richtige IP-Adresse vom ausgehenden Verkehr verwenden:

Code:
rdr on fxp0 proto tcp from (fxp0) to any port 80 -> 127.0.0.1 port 3128
 
Die Pakete kommen doch von localhost, was bringt mir das da einen Redirect auf 'ne Netzwerkkarte einzurichten?
 
Die Daten kommen von localhost, ja. Aber sie kommen nicht von lo0. In der Routingtabelle steht doch ganz genau, wo welches Paket langlaufen soll. Wie gesagt ist auf meinem System fxp0 das LAN-Interface, über das ich auch meinen Gateway anspreche. Das heißt Pakete für zum Beispiel google.de werden das System über fxp0 verlassen. Ausgabe von "route show":

Code:
$ route show
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu  Interface
default            router             UGS         1 16057411      -   fxp0
[...]

Ich muss also auf fxp0 filtern, wenn ich solche Pakete abfangen will.

Deine zuerst genannte Regel würde greifen, wenn du auf localhost:80 zugreifst, denn:

Code:
loopback           localhost          UGRS        0        0  33224   lo0
localhost          localhost          UH          0   185592  33224   lo0

Und im Übrigen kannst du auch deine IP-Adresse angeben, denn die wird auch über lo0 geleitet. Aber keine externen!
 
Paldium das funktioniert wirklich mit PF nicht, deswegen funktioniert der schöne FTP-Proxy auch nicht local :(

IPFW Bleibt halt doch noch eine weile leben (zum glück) ;-)
 
Hm ... interessant und gut zu wissen.

Wobei man jetzt haarspalterisch sein könnte und sagen müsste, dass rdr auch in die Sektion NAT und nicht in die Sektion Filtern fällt. Das kann PF zumindest auch mit lokalem Traffic, noch dazu auf Benutzer/Gruppen-Ebene.
 
fuer mein verstaendnis ist eine app level fw nicht zwingend eine windows personal fw. wenn man fuer alle verwendeten dienste einen proxy finden wuerde, so dass man das ip forwarding abstellen koennte, hat man imho auch eine app level fw (vorrausgesetzt, die proxies erlauben auch das manipulieren des traffics).
 
So gesehen könnten damit Proxys wieder an Wert gewinnen :)
"Kein Zugriff?" -> "Kein Proxy eingetragen!"
 
Ist das dein Ernst? Warum kann ich dann kein redirect von localhost machen:

rdr on lo0 proto tcp from 127.0.0.1 to any port 80 -> 127.0.0.1 port 3128

Diese Regel funktioniert nur für Verbindungen, die vom Host auf sich selbst gemacht werden, und auch nur, wenn Du IPv4 benutzt. In FreeBSD-GENERIC-Land wird für solche Verbindungen zunächst IPv6 verwandt, IPv4 nur als Fallback, falls der Service z.B. nicht für IPv6 konfiguriert ist.

Die Pakete kommen doch von localhost, was bringt mir das da einen Redirect auf 'ne Netzwerkkarte einzurichten?

Da liegt der Denkfehler. Wenn Du eine TCP-Verbindung von Deinem Rechner zu z.B. 212.204.60.79, Port 80 initiierst, dann wird zunächst in der Routing-Tabelle nachgeschlagen, welches Interface einen Weg zur Adresse kennt. Das kannst Du auch selbst nachschauen, indem Du `route get 212.204.60.79` an der Shell eintippst.

Beim Verbindungsaufbau, im ersten SYN-Paket, wird als Absenderadresse die Adresse des ausgewählten Interfaces eingetragen, bei mir im Moment z.B. 192.168.1.34. Die Antwort, das SYN-ACK der Gegenstelle, ist an 192.168.1.34 adressiert.

Ich denke, Du kannst Dir nun selbst denken, weshalb Deine pf-Regel nicht funktioniert. Der Vollständigkeit halber hier trotzdem ein paar Tipps:
  • Würde als Absender 127.0.0.1 eingetragen, wohin würde die Gegenstelle ihre Antwort schicken?
  • Wer würde die Antwort empfangen?
  • Was zeigt `tcpdump -i lo0` an, wenn Du versuchst, die o.g. Verbindung aufzubauen?
 
Unabhängig vom Sinn oder Unsinn lassen sich ein Filter für ausgehende Verbindungen von lokalen Prozessen unter *BSD mit systrace erstellen.
 
Back
Top