Paketfilter mit User Authentifizierung?

I.MC

Watt soll denn hier hin?
Hi!

Ich habe gelesen, dass es Paketfilter gibt, die Userauthentifizierung ermöglichen, so wie es Proxies tun.
Also z.B. wenn du http nutzen willst, bitte erst authentifizieren.
Jedoch sind die selten und ich kenne keinen solchen.
Kennt ihr einen?


Gruss, Jochen
 
Ich denke, dass so etwas nur auf Applikationsebene funktioniert, so wie bei dem von dir erwähnten HTTP. Ein Paketfilter arbeitet auf einer viel tieferen Schicht (ist das layer 3 oder 4?) und ist von den Benutzerinformationen komplett entkoppelt (sprich wenn das Paket den Kernel erreicht weiss der nicht mehr "wer" (welcher Benutzer) es geschickt hat).

Vielleicht kannst Du uns mit mehr Informationen versorgen - was genau willst Du den erreichen?
 
Moin,
von reinen Paketfiltern mit Authetifizierung habe ich noch nie gehört und meines Wissens bieten weder ipfw noch pf dieses Feature, wie schon im anderen Threat erwähnt kenne ich das nur von transparenten Proxys.
Mal ganz abgesehen davon wie soll man sich auf TCP/IP Basis authetifizieren? Gibt's da einen Header für?

buebo
 
Original geschrieben von incmc
Hi!

Ich habe gelesen, dass es Paketfilter gibt, die Userauthentifizierung ermöglichen, so wie es Proxies tun.
Also z.B. wenn du http nutzen willst, bitte erst authentifizieren.
Jedoch sind die selten und ich kenne keinen solchen.
Kennt ihr einen?


Gruss, Jochen

Der kürzlich auf FreeBSD portierte PaketFilter pf von OpenBSD hat so eine Authentifizierung integriert. Sie heißt authpf.

Wenn ein User sich auf eine Maschine einloggt, die authpf (mit pf zusammen) laufen hat, dann wird z.B. ein bestimmter Regelsatz geladen und dem eingeloggten User werden bestimmte Rechte vergeben, wie z.B. ein Webbasierter Zugriff auf bestimmte Dienste (Webmin z.B.). Natürlich gibt es da noch mehr Möglichkeiten und ich möchte erst gar nicht anfangen, alle aufzuzählen :)

Aber hier habe ich einen Link unter dem du was über authpf und seine Features erfahren kannst und ich hoffe, dass diese auch auf FreeBSD portiert worden sind.

http://www.openbsd.org/cgi-bin/man....8&apropos=0&manpath=OpenBSD+Current&arch=i386

Gruß

CW
 
Original geschrieben von buebo
Moin,
von reinen Paketfiltern mit Authetifizierung habe ich noch nie gehört und meines Wissens bieten weder ipfw noch pf dieses Feature, wie schon im anderen Threat erwähnt kenne ich das nur von transparenten Proxys.
Mal ganz abgesehen davon wie soll man sich auf TCP/IP Basis authetifizieren? Gibt's da einen Header für?

buebo

Das wird eben nicht detailliert beschrieben. Glaube es war in einem Buch dass mir hier vor kurzen empfohlen wurde von kith (Building Internet Firewalls. Internet and Web Security)
Habe es jetzt nicht mehr genau nachgeschlagen, viel mir aber gerade ein, dass dort kurz davon geredet wurde. Da bin ich mir fast absolut sicher. Seitdem bin ich scharf drauf, da ich bis jetzt nicht so der fan von Proxies bin :-)

Wie das exakt funktionieren solll, mmh, könnte ich nur spekulieren. Muss erst noch den link zu authpf lesen, aber vermute dass es doch gehen sollte Verbindungen eine Userzugehörigkeit zu verpassen. Dann kann ich auch nach Protokollen Rechte vergeben, du darfst das, aber nicht das Protokoll nutzen. Würde es gar nicht an TCP knüpfen. Müsste doch allgemeiner gehen. Z.B. ganz stumpf ohne auf die eigentliche Verbindungsanfrage zu gucken, erst einmal auf mac Adresse und IP des Clienten gucken. Wenn ok, darf er das, was ich ihm erlaubt habe in den Rechten. Kein perfekter Schutz, sind Passwörter aber auch nicht.
Mit Applikationspezifischen Protokollen hat das für mich nichts zu tun bzw. so tiefgehend meinte ich es nicht. Wobei in dem Buch auch davon die Rede ist, dass es Paketfilter gäbe, die z.B. beim ftp Protokoll den usernamen testen können und z.B. alle Verbindungen mit username "doener" blocken. Ich weiss nicht, ob es hier noch um frei erhältliche Produkte geht. I'm just curious ;-)
Ein Paketfilter kann ja wenn er nicht zu den dümmsten gehört immerhin die mainstream Protokolle erkennen und auch deren Status überwachen, (mehr oder weniger) also sollte er doch auch in gewissem Maße diese Verbindungen mit weiteren Aktionen belegen können.

Evtl. irre ich ja auch :-) aber das Buch redet davon.

Gruss, incmc
 
@myself

Allerdings ist eine Authentifizierung aud IP Basis ja sowieso mit nem Paketfilter möglich. Nur ihm halt dann zu erlauben / verbieten gewisse Dinge machen zu dürfen oder nicht wird dann schwieriger. Und IP Adressen lassen sich sofort kopieren, wenn Admin Rechte da sind.

Jetzt frage ich mich gerade, welcher Paketfilter kann denn eigentlich soweit runter auf Applikationsprotokollebene?
IPF kann nicht mehr als TCP, UDP, ICMP, tiefer runter geht nicht oder irre ich (also Applikationsprotos)?
Kann man eigentlich mit ipf oder pf auch auf MAC Adresse prüfen?
Von welchen Paketfiltern reden die da im Buch eigentlich?
Das sind ja halbe Proxies oder wie?

@buebo

gute Frage. Irgendwie fällt mir da jetzt auch keine gescheite Lösung ein bezügl. der Auth.

Gruss, incmc
 
PaketFilter

Original geschrieben von incmc
Das wird eben nicht detailliert beschrieben. Glaube es war in einem Buch dass mir hier vor kurzen empfohlen wurde von kith (Building Internet Firewalls. Internet and Web Security)

Das Buch ist gut, wenn es darum geht, zu beschreiben wie z.B. die verschiedenen Firewall-Typen funktionieren, hat leder keine detaillierten Config-Beispiele.

Ansonsten, ein sehr gutes Buch.

Habe es jetzt nicht mehr genau nachgeschlagen, viel mir aber gerade ein, dass dort kurz davon geredet wurde. Da bin ich mir fast absolut sicher. Seitdem bin ich scharf drauf, da ich bis jetzt nicht so der fan von Proxies bin :-)

Bist nicht der einzige ;)

Wie das exakt funktionieren solll, mmh, könnte ich nur spekulieren. Muss erst noch den link zu authpf lesen, aber vermute dass es doch gehen sollte Verbindungen eine Userzugehörigkeit zu verpassen.

Das ist der Sinn der Sache bei authpf. Da legst du auf der Filter-Maschine ein authpf-Verzeichnis und in diesem für jeden User ein Unterverzeichnis an. Und in diesen stehen eben die entsprechenden Filter-Regeln. Dazu kannst du noch eine Banned-List setzen, Gruß-Message anbringen usw.

Dann kann ich auch nach Protokollen Rechte vergeben, du darfst das, aber nicht das Protokoll nutzen. Würde es gar nicht an TCP knüpfen.

Dies kann man machen. Jedoch musst du zuerst die pf-Manpage durchlesen, da du dich auch mit dem Filtern im Allgemeinen auskennen musst. Experimentiere ein bisschen rum :)

Hier ein Link unter dem du (fast) alles zu pf und authpf finden kannst: https://solarflux.org/pf/

Nebenbei enthält die Website auch viele vorgefertigte pf-Configs ;)

Müsste doch allgemeiner gehen. Z.B. ganz stumpf ohne auf die eigentliche Verbindungsanfrage zu gucken, erst einmal auf mac Adresse und IP des Clienten gucken.

Da vermischst du leider zwei verschiedene Sachen, da MAC-Adressen eine Schicht tiefer laufen als das IP-Protokoll.
Paket-Filter (pf eingeschlossen) können nicht nach MAC-Adressen filtern.

Wenn ok, darf er das, was ich ihm erlaubt habe in den Rechten. Kein perfekter Schutz, sind Passwörter aber auch nicht.

Nichts ist (leider) perfekt :)

Mit Applikationspezifischen Protokollen hat das für mich nichts zu tun bzw. so tiefgehend meinte ich es nicht.

Was du jetzt mit "applikationsspezifisch" gemeint hast, ist mir unklar. Ausserdem kannst du keine Applikationen filtern, sondern nur nach IP-Adresse, Protokoll & Interface.

Daher lese dich am besten erst einmal in die verschiedenen FAQs und Manpages (und das gute Buch von oben) ein.

Ohne dieses Hintergrundwissen, würde ich mich nicht trauen, solch komplexe Sachen zu machen. Es ist nicht bloß das stupide Verbieten & Erlauben. Es ist wirklich viel, viel mehr.

Das habe ich auch schon früh feststellen müssen, als ich anfing, mich mit solchen Sachen zu beschäftigen :)

Wobei in dem Buch auch davon die Rede ist, dass es Paketfilter gäbe, die z.B. beim ftp Protokoll den usernamen testen können und z.B. alle Verbindungen mit username "doener" blocken. Ich weiss nicht, ob es hier noch um frei erhältliche Produkte geht. I'm just curious ;-)

Klingt interessant, jedoch handelt es sich bei diesen PaketFiltern um (ich nenne sie mal so) "hybride PaketFilter", die auch auf höheren Schichten filtern können bzw. im Verbund mit anderen Applikationen dies bewerkstelligen.

Ist aber eine interessante Sache. Danke für den Tipp. Ich werde mal googeln ;)

Ein Paketfilter kann ja wenn er nicht zu den dümmsten gehört immerhin die mainstream Protokolle erkennen und auch deren Status überwachen, (mehr oder weniger) also sollte er doch auch in gewissem Maße diese Verbindungen mit weiteren Aktionen belegen können.

Es gibt werde dumme noch schlaue PaketFilter, sondern Stateful bzw. Stateless Filter. :)

Und "mainstream" Protokolle sind die drei: tcp, udp, icmp (die zumindest vom pf) gefiltert werden können.

Und die "weiteren Aktionen" sind nicht möglich, da das Filtern selber eine Aktion ist. Wenn du eine Verbindung gestattet hast, dann läuft sie eben. Und mit dem pf kannst du nichts mehr machen, es sei denn du lädst ein neues Regelwerk und mit diesem unterbrichst die Verbindung. Doch dies macht keinen Sinn. Die einzige Möglichkeit wäre, den pf mit einer anderen (auch einer höheren Schicht agierenden) Applikation laufen zu lassen. Denkbar wäre ein Application Level Gateway. Ob dies aber Performance-Einbußen mit sich bringt, kann ich dir nicht sagen.

Hört sich aber zumindest so an :)

Wenn jemand mehr weiß, dann bitte posten :)

Evtl. irre ich ja auch :-) aber das Buch redet davon.

Gruss, incmc [/B]

Ich glaube nicht, dass du irrst ... ich würde sagen, du lernst :)

Gruß und fröhliches Filtern

CW
 
Zuletzt bearbeitet:
Was du jetzt mit "applikationsspezifisch" gemeint hast, ist mir unklar. Ausserdem kannst du keine Applikationen filtern, sondern nur nach IP-Adresse, Protokoll & Interface.

Stimmt, etwas unglücklich ausgedrückt. Ich meinte damit höhere Protokolle, wie ftp, http, ssh, alles dieser Klasse halt.

Ohne dieses Hintergrundwissen, würde ich mich nicht trauen, solch komplexe Sachen zu machen. Es ist nicht bloß das stupide Verbieten & Erlauben. Es ist wirklich viel, viel mehr.
Das habe ich auch schon früh feststellen müssen, als ich anfing, mich mit solchen Sachen zu beschäftigen

Ich weiss doch bereits einiges, also so als den blutigen Anfänger bezeichne ich mich diesbezüglich nicht mehr so. Anfangs zig Monate zurück, erinnere mich noch, fast irre geworden, weil natürlich alles sofort hätte gehen sollen. Was mich dann aber doch zig Tage gekostet hat und viel viel lesen *g*.
Es gibt aber noch verammt vieles zu lesen, da hasse recht.
Interessiert mich aber brennend, hehe.

Zu den dummen und schlauen Paketfiltern. Richtig, stateful etc., aber ich dachte da mehr an die, die angeblich auch in der Lage sind höhere Protokolle zu "durchschnüffeln".

Aber nachdem ich nochmal drüber nachdachte, musste ich doch einsehen, dass in dem Posting, was ich danach ein wenig korrigiert, doch einiges nicht sooo korrekt war.
Erst denken, dann posten :-)

Was gibt es so an weiterführenden Büchern, die praktischer auf Unix Firewalls eingehen, wie ipf, pf? Finde da nicht so DAS Buch :-(

Gruss, incmc
 
Original geschrieben von incmc
Stimmt, etwas unglücklich ausgedrückt. Ich meinte damit höhere Protokolle, wie ftp, http, ssh, alles dieser Klasse halt.

Es sind Dienste (vom PaketFilter aus gesehen).

Aber natürlich hast du Recht, dass es Protokolle sind.

Für den PF sind Protokolle: tcp, udp und icmp.

Ich weiss doch bereits einiges, also so als den blutigen Anfänger bezeichne ich mich diesbezüglich nicht mehr so.

Fantastisch, dann kannst du ja so richtig mit pf durchstarten.

Die OpenBSD-FAQs sind ja sehr gut und die manpages sind auch nicht schlecht.

Anfangs zig Monate zurück, erinnere mich noch, fast irre geworden, weil natürlich alles sofort hätte gehen sollen. Was mich dann aber doch zig Tage gekostet hat und viel viel lesen *g*.
Es gibt aber noch verammt vieles zu lesen, da hasse recht.
Interessiert mich aber brennend, hehe.

Da kann ich nur sagen: in die FAQs, manpages und Bücher reihauen. Zu OpenBSD (pf mit einbezogen) erscheinen gleich zwei neue Bücher. Sieh bei amazon z.B. nach.


Zu den dummen und schlauen Paketfiltern. Richtig, stateful etc., aber ich dachte da mehr an die, die angeblich auch in der Lage sind höhere Protokolle zu "durchschnüffeln".

Dazu kann ich nicht viel sagen, da ich mich bis jetzt nur an die "normalen" PaketFilter gehalten habe und diese auch ausreichend waren.

Aber, wenn sie mehr Vorteile bringen und ausgereift sind, warum nicht?

Aber nachdem ich nochmal drüber nachdachte, musste ich doch einsehen, dass in dem Posting, was ich danach ein wenig korrigiert, doch einiges nicht sooo korrekt war.
Erst denken, dann posten :-)

Sag ich mir auch jedes mal, schon wenn es um Grammatik-Fehler geht ;)

Was gibt es so an weiterführenden Büchern, die praktischer auf Unix Firewalls eingehen, wie ipf, pf? Finde da nicht so DAS Buch :-(

Gruss, incmc [/B]

Wie ich schon sagte, OpenBSD wird in diesem Monat bzw. Anfang des nächsten gleich zwei Bücher verpasst bekommen. Eines davon beschäftigt sich sogar nur mit dem Entwurf von Firewalls.

Gruß

CW
 
Zuletzt bearbeitet:
Sch... kennt denn keiner einen Paketfilter von dem da geredet wird? Muss doch einer wissen.
Was ist eigentlich mit ipf Version 4, kommt die irgendwann, oder ist da nichts mehr?
Der Entwickler hat ja vor "geraumer" Zeit in der Openbsd mailinglist dickt auf die Ka... gehauen, dass in der Version 4 Features wären, die einfach genial wären. Mmh...
Zu den Büchern, mal gucken. Ich sitze eher auf der FreeBSD Schiene. Aber wenn es überwiegend um pf geht, sollte das ja ok sein. Mal gucken, kostet ja auch alles Kohle.

Rechtschreibfehler beherrsche ich auch sehr gut :-)

Gruss, incmc
 
Original geschrieben von incmc
Sch... kennt denn keiner einen Paketfilter von dem da geredet wird? Muss doch einer wissen.

Sorry :(

Was ist eigentlich mit ipf Version 4, kommt die irgendwann, oder ist da nichts mehr?
Der Entwickler hat ja vor "geraumer" Zeit in der Openbsd mailinglist dickt auf die Ka... gehauen, dass in der Version 4 Features wären, die einfach genial wären. Mmh...

Darren Reed labert viel, wenn der Tag lang ist.
Ausserdem macht er doch selber (mittlerweile) bei der Entwicklung von pf doch mit.

Die Infos darüber kannst du dir hier holen (einfach mal ins Archiv dort gehen) : http://www.deadly.org

Zu den Büchern, mal gucken. Ich sitze eher auf der FreeBSD Schiene. Aber wenn es überwiegend um pf geht, sollte das ja ok sein. Mal gucken, kostet ja auch alles Kohle.

Rechtschreibfehler beherrsche ich auch sehr gut :-)

Gruss, incmc [/B]

FreeBSD solltest du auch beibehalten. Es ist ein ausgezeichnetes System mit einem fantastischen TCP/IP-Stack.

Nur der Paket-Filter pf ist das, worum es geht, nicht OpenBSD. Es sei denn, du willst auch ein OpenBSD-System (aus welchem Grunde auch immer) fahren :)

Gruß und happy filtering

CW
 
Zuletzt bearbeitet:
Wobei in dem Buch auch davon die Rede ist, dass es Paketfilter gäbe, die z.B. beim ftp Protokoll den usernamen testen können und z.B. alle Verbindungen mit username "doener" blocken. Ich weiss nicht, ob es hier noch um frei erhältliche Produkte geht. I'm just curious ;-)

Das nennt sich "stateful inspection" und ist in kommerziellen Produkten wie Checkpoint FW-1 implementiert. Die haben intern eine richtige state-machine die die Pakete reassembliert und dann z.B. das ftp-Protokoll entschlüsseln kann und z.B. automatisch ports freigeben kann (für nicht-passives ftp) oder eben auch Benutzer aussperrt.

Dazu noch ein Link: http://www.sofaware.com/html/tech_stateful.shtm
 
Zuletzt bearbeitet:
Original geschrieben von current
Das nennt sich "stateful inspection" und ist in kommerziellen Produkten wie Checkpoint FW-1 implementiert. Die haben intern eine richtige state-machine die die Pakete reassembliert und dann z.B. das ftp-Protokoll entschlüsseln kann und z.B. automatisch ports freigeben kann (für nicht-passives ftp) oder eben auch Benutzer aussperrt.

Dazu noch ein Link: http://www.sofaware.com/html/tech_stateful.shtm

Stateful inspection ist auch mit pf möglich. Das passive FTP (beispielsweise) ist ebenfalls mit pf möglich.

Benutzer können ebenfalls mit dem authpf (nicht nur) augesperrt werden :)


Gruß

CW
 
Zuletzt bearbeitet:
Ein größeres HOWTO zu PF findet ihr unter
http://neo.magdeburg.de/cgi-bin/show.pl?such=pf

Da dürfte eigentlich das wesentlich erklärt sein. Zwar auf
Basis OpenBSD, aber pf ist ja kein reinrassiges OpenBSD
Produkt, sondern wird sicherlich auch auf FreeBSD portierbar
sein.

Eigentlich ist ja pf für die Absicherung von Wireless LAN
bestimmt, aber es interessiert die Firewall sicherlich nicht,
ob der traffic über Funkt oder Cat5 kommt :-)

Gruss
bnerft
 
Stateful inspection ist auch mit pf möglich.

Sagen wir mal so: in der pf Dokumentation findet sich auch das Stichwort "stateful inspection". Allerdings findest Du bei FW-1 weit mehr Funktionalität als bei pf. Ein Beispiel ist z.B. die Analyse des ftp-Protokolls "im Kernel" über die interne state machine. Du kannst das als Kombination von paket filter und application level firewall verstehen. Soweit ist pf (noch?) nicht.
 
Mmh, wireless Lan auch hier vorhanden. Damit ich auf den Klo surfen kann, lach :-)
Aber ich würde da eher mit Dingen wie IPSec rangehen, nen Paketfilter macht die Übertagung da nicht gerade sicherer.
Oder meintest du das anders...?

Gruss, incmc
 
Original geschrieben von current
Sagen wir mal so: in der pf Dokumentation findet sich auch das Stichwort "stateful inspection". Allerdings findest Du bei FW-1 weit mehr Funktionalität als bei pf. Ein Beispiel ist z.B. die Analyse des ftp-Protokolls "im Kernel" über die interne state machine. Du kannst das als Kombination von paket filter und application level firewall verstehen. Soweit ist pf (noch?) nicht.

Ich möchte mich jetzt nicht über die FW-1 unterhalten. Ausserdem neigen die Hersteller, ihr Produkt zu preisen, als ob es das einzige auf der Welt wäre. Sei es mir egal, soviel Geld habe ich leider nicht, um die FW-1 auszuprobieren. :)

Ausserdem ist pf ein integraler Bestandteil der OpenBSD-Kernels, sodass das Feature mit der "internen State-Machine" wohl als Besonderheit bei FW-1 entfallen dürfte. Natürlich möchte ich hier ein Produkt, das ich nicht kenne, nicht schlechtreden. Es geht mir einfach darum, incmc, so gut ich kann, zu helfen, die Lösung seiner Probleme zu finden :)

Mehr nicht.

Und was die Auswertung von States bei pf anbetrifft, so kannst du in dem von mir oben angegebenen Link (Solaflux.org) jede Menge Infos darüber finden. Und die Sache mit der Analyse des ftp-Protokolls kann mit einer IDS-Software genauso gut (oder genauso schlecht) erledigt werden.

Snort ist so ein Beispiel für die Analyse des übertragenen Traffics.


Gruß

CW
 
Original geschrieben von bnerft


Eigentlich ist ja pf für die Absicherung von Wireless LAN
bestimmt, aber es interessiert die Firewall sicherlich nicht,
ob der traffic über Funkt oder Cat5 kommt :-)

Gruss
bnerft

Ich würde mal ganz gerne wissen, woher du diese Information bekommen hast?

Auf der OpenBSD-Homepage finde ich nichts darüber.

Gruß

CW
 
Und die Sache mit der Analyse des ftp-Protokolls kann mit einer IDS-Software genauso gut (oder genauso schlecht) erledigt werden. Snort ist so ein Beispiel für die Analyse des übertragenen Traffics.

Ja klar - nur der snort meckert erst wenn es zu spät ist :-)

Aber die Analogie ist gut, ich denke snort macht es so ähnlich wie die tolle FW-1 engine...

Es geht mir einfach darum, incmc, so gut ich kann, zu helfen, die Lösung seiner Probleme zu finden

Gutes Schlusswort :-)
 
Original geschrieben von incmc
Mmh, wireless Lan auch hier vorhanden. Damit ich auf den Klo surfen kann, lach :-)
Aber ich würde da eher mit Dingen wie IPSec rangehen, nen Paketfilter macht die Übertagung da nicht gerade sicherer.
Oder meintest du das anders...?

Gruss, incmc

bnerft hat einen Link gepostet unter dem du, unter anderem, auch 'ne Menge pber IPsec erfahren kannst.

Hier nochmal der Link (die Homepage davon): http://www.unixscout.de

Ausserdem findest du bei http://www.openbsd.org in der OpenBSD-FAQ eine detaillierte Beschreibung, wie man IPSec unter OpenBSD fährt. Und diese kann man ja bestimmt (Änderungen aber möglich) unter FreeBSD anwenden.

Bestimmt gibt es auch da Anleitungen von dem FreeBSD-Projekt selbst. Ich kann dir aber keine direkt nennen :(

Gruß

CW
 
Original geschrieben von current
Ja klar - nur der snort meckert erst wenn es zu spät ist :-)



Die FW-1 kann bestimmt auch die Gedanken der Attacker nicht lesen ;)

*kleiner Scherz*

Aber die Analogie ist gut, ich denke snort macht es so ähnlich wie die tolle FW-1 engine...

Bis jetzt läuft alles O.K. mit meiner Snort-Installation in Verbindung mit pf :)

Gutes Schlusswort :-) [/B]

Danke :)

Gruß

CW
 
Zurück
Oben