Zeitgesteuerte ipfw Regeln, wie ?
- Ersteller moxxito
- Erstellt am
ReinerWein
Evil Doer
moxxito,
ich kenne mich mit ipfw nicht aus und weiß daher nicht, ob man Regeln während der Lauft laden- und entladen kann. Wenn das aber möglich ist, könnte man dein Problem evtl. mit cronjob-gesteuerten Skripten lösen.
Nur so ne fixe Idee...
ich kenne mich mit ipfw nicht aus und weiß daher nicht, ob man Regeln während der Lauft laden- und entladen kann. Wenn das aber möglich ist, könnte man dein Problem evtl. mit cronjob-gesteuerten Skripten lösen.
Nur so ne fixe Idee...
Danke @Alle für die Tipps,
aber leider ist nicht das was ich suche. Die Idee mit den cron jobs hatte ich auch, aber die ist zu umständlich und bei vielen Regeln nicht mehr transparent im Enterprise Level. Ich betreue hier unser Firmen Firewall und und DMZ Systeme noch unter Linux. Allerdings plane ich den Umstieg auf FreeBSD für die Firewalls und DMZ Applikationsserver. Um da die Anzahl der custom-Regeln im Auge zu behalten, sollten diese automatische verfallen (z.B. User braucht bestimmten Zugriff zum Kunden bis xy, danach Sense). Damit das Ganze auch "verteilt" Administrierbar wird wollre ich fwbuider einsetzen und bin dort über das "Verfallsdatum" bei iptables gestolpert. So ein Feature würde mir die Arbeit (und die der Kollegen, die cron für Kekse halten) sehr erleichtern.
mmmhhh vielleicht sollte ich mal die ipfw Developer anhauen, ob die nicht Lust haben....
@current: Statefull inspection ist hier nicht gemeint, sondern ein echtes Verfallsdatum nach der sich die Regel selbst zerstört.
@ReinerWein: ipfw kann ausch zur Laufzeit eingestellt werden. Gibt es etwa fw's mit statischen Regelsatz ?
Danke und Gruß
mox
aber leider ist nicht das was ich suche. Die Idee mit den cron jobs hatte ich auch, aber die ist zu umständlich und bei vielen Regeln nicht mehr transparent im Enterprise Level. Ich betreue hier unser Firmen Firewall und und DMZ Systeme noch unter Linux. Allerdings plane ich den Umstieg auf FreeBSD für die Firewalls und DMZ Applikationsserver. Um da die Anzahl der custom-Regeln im Auge zu behalten, sollten diese automatische verfallen (z.B. User braucht bestimmten Zugriff zum Kunden bis xy, danach Sense). Damit das Ganze auch "verteilt" Administrierbar wird wollre ich fwbuider einsetzen und bin dort über das "Verfallsdatum" bei iptables gestolpert. So ein Feature würde mir die Arbeit (und die der Kollegen, die cron für Kekse halten) sehr erleichtern.
mmmhhh vielleicht sollte ich mal die ipfw Developer anhauen, ob die nicht Lust haben....
@current: Statefull inspection ist hier nicht gemeint, sondern ein echtes Verfallsdatum nach der sich die Regel selbst zerstört.
@ReinerWein: ipfw kann ausch zur Laufzeit eingestellt werden. Gibt es etwa fw's mit statischen Regelsatz ?
Danke und Gruß
mox
Wie/Woraus sollen die Regeln erzeugt werden? Damit das einigermassen Sinn macht muss man ja erstmal wissen wo genau man die Regel einfuegt, und dann kann man die auch zeitgesteuert wieder entfernen lassen.
Btw, ich bin da gerade an etwas aehnlichem dran. Ist nur leider (zum Glueck??) noch nicht bei der Implementierung und das ganze ist eher akademisch ausgelegt
Btw, ich bin da gerade an etwas aehnlichem dran. Ist nur leider (zum Glueck??) noch nicht bei der Implementierung und das ganze ist eher akademisch ausgelegt
moin zusammen,
zuindest scheine ich ja ein interessantes Thema gefunden zu haben
@ICE: Ich habe mir gerade mal die man 4/5 ipf angesehen und keine Option in der Richtung entdecken können. Vermutlich trügt der Schein, aber ipf sieht mir nicht so komfortabel aus oder meinst Du eine ganz andere Implementierung ?
@MrFixIt: Also wo die Regel liegt ist erstmal egal solange die Regel sich aus sich selbst heraus zerstören kann. cron Gebilde usw. kommen in meinem Fall nicht in Frage, da ich dann an min. 2 Stellen Administrieren muss um eine Regel zu löschen
@current: Ich denke da irrst Du
man ipfw:
If the ruleset includes one or more rules with the keep-state or limit option, then ipfw assumes a stateful behaviour, i.e. upon a match it will create dynamic rules matching the exact parameters (addresses and ports) of the matching packet. Allerdings kan man prächtig darüber streiten wann eine fw statefull ist und wann nicht oder sich nur so verhält.
Gruß
mox
zuindest scheine ich ja ein interessantes Thema gefunden zu haben
@ICE: Ich habe mir gerade mal die man 4/5 ipf angesehen und keine Option in der Richtung entdecken können. Vermutlich trügt der Schein, aber ipf sieht mir nicht so komfortabel aus oder meinst Du eine ganz andere Implementierung ?
@MrFixIt: Also wo die Regel liegt ist erstmal egal solange die Regel sich aus sich selbst heraus zerstören kann. cron Gebilde usw. kommen in meinem Fall nicht in Frage, da ich dann an min. 2 Stellen Administrieren muss um eine Regel zu löschen
@current: Ich denke da irrst Du
man ipfw:
If the ruleset includes one or more rules with the keep-state or limit option, then ipfw assumes a stateful behaviour, i.e. upon a match it will create dynamic rules matching the exact parameters (addresses and ports) of the matching packet. Allerdings kan man prächtig darüber streiten wann eine fw statefull ist und wann nicht oder sich nur so verhält.
Gruß
mox
current
BSD Fan
Stateful ist das schon, aber nicht 'stateful inspection'. Letzteres steht für eine Analyse des Inhalts der IP-Pakete durch die Firewall, um Protokolle semantisch zu analysieren. Ein Beispiel dafür ist die Analyse des ftp-Protokolls auf dem Kontrollkanal, um die über das 'PORT' Kommando ermittelten Ports dynamisch zu öffnen.
Hallo current,
ich denke statefull = dynamic = statefull inspection = dynamic packet filtering ist per Definiton (http://www.webopedia.com/TERM/S/stateful_inspection.html) als gleich zu betrachten. Dein eben beschriebenes Verhalten von ftp Verbindungen beschreibt, dass dynamisch zur Laufzeit die Firewall geöffnet wird und solange offen bleibt bis kein entsprechendes Packet die Regel mehr aufrecht erhält. Die Unterschiede sind eher in der Implmentierung zu finden in wie weit dieses Verhalten auskodiert wurde.
So unterscheidet Checkpoint z.B. sehr genau zwischen Inspection und Application level intelligence, bei der der genaue Paketinhalt überprüft wird.
Da wäre es interessant ob die FBSD'ler auch an einer Analyse von high level Protokollen arbeiten.
Gruß
mox
ich denke statefull = dynamic = statefull inspection = dynamic packet filtering ist per Definiton (http://www.webopedia.com/TERM/S/stateful_inspection.html) als gleich zu betrachten. Dein eben beschriebenes Verhalten von ftp Verbindungen beschreibt, dass dynamisch zur Laufzeit die Firewall geöffnet wird und solange offen bleibt bis kein entsprechendes Packet die Regel mehr aufrecht erhält. Die Unterschiede sind eher in der Implmentierung zu finden in wie weit dieses Verhalten auskodiert wurde.
So unterscheidet Checkpoint z.B. sehr genau zwischen Inspection und Application level intelligence, bei der der genaue Paketinhalt überprüft wird.
Da wäre es interessant ob die FBSD'ler auch an einer Analyse von high level Protokollen arbeiten.
Gruß
mox
Irgendetwas/Irgendjemand erzeugt die Regel (oder fallen die bei Dir vom Himmel?), und derjenige soll sich dann gefaelligst auch um die Loeschung der Regel kuemmern. Kein Grund da an zwei Stellen taetig zu werden.Original geschrieben von moxxito
Also wo die Regel liegt ist erstmal egal solange die Regel sich aus sich selbst heraus zerstören kann. cron Gebilde usw. kommen in meinem Fall nicht in Frage, da ich dann an min. 2 Stellen Administrieren muss um eine Regel zu löschen
Wodurch werden denn die Regeln eingegeben?
zu den "High Level Protocols": man libalias(3)
Wenn man dem Thread folgt sehe ich zunächst nur eine Methode zum automatsiche mittels eines cron-jobs, der bestimmte zeilen/nummer löscht. Die ist allerdings "maximal hässlich". Der löschende cron-job muss ja irgendwoher wissen welche Regeln er löschen soll. Folglich muss ich eine Liste führen, welche die Zeilenummern und/oder Regelnummern führt. Entweder schreibe ich jetzt ein Erstellungstool, dass gleichzeitig diese Liste führt oder ich muss sie eben an zweiter Stelle pflegen. Meine Frage zielt aber eindeutig auf ein fertiges Feature und nicht auf ein selbstgebautes Konstrukt.
fwbuilder
Den Zusammenhang verstehe ich jetzt nicht. Nimmst Du da Bezug auf das statefull inspection Thema ?
Zuletzt bearbeitet:
ich weiss nicht genau wofuer du das brauchst, aber ich wuerde den cron-job eher dazu bringen in regelmaessigen intervallen die filter-regeln aus der default datei zu lesen, und die temporaeren regeln manuell auf dem CLI eingeben (falls das machbar ist). ab einer gewissen groesse des netzwerkes ist das natuerlich nicht mehr praktikabel.
alternativ hilft dir evt. PF und authpf?
http://www.openbsd.org/faq/pf/authpf.html
ps. PF gibts ja mittlerweile auch fuer freebsd
alternativ hilft dir evt. PF und authpf?
http://www.openbsd.org/faq/pf/authpf.html
ps. PF gibts ja mittlerweile auch fuer freebsd
Ein fertiges Feature gibt es da m.W.n. nicht. Ist auch nicht noetig, da derjenige, der die Regel erstellt auch fuer die Loeschung veranwortlich sein sollte. Es gibt keinen Grund da etwas an zwei Stellen abzulegen.
Da kannst natuerlich auch die Kommentare von IPFW2 dafuer missbrauchen (erst ab 5.2)
Code:
% sudo ipfw show
00100 824 137064 allow ip from any to any
65535 2918 642417 deny ip from any to any
% sudo ipfw add deny all from 10.0.0.0/8 to me // delete at $(($(date +%s) + 86400))
00200 deny ip from 10.0.0.0/8 to me // delete at 1069767540
% sudo ipfw show
00100 9326 1927481 allow ip from any to any
00200 0 0 deny ip from 10.0.0.0/8 to me // delete at 1069767540
65535 2918 642417 deny ip from any to anyUnd wer steuert fwbuilder? Erzeugt er die Regeln periodisch aus einer Textdatei? Wird er von Benutzern ueber ein Webfrontend angesprochen? Wer legt fest, wie lange eine Regel existieren soll?
Du wolltest wissen, ob die Inspektion von "High Level' Protokollen unterstuetzt werden. Das werden sie durch libalias.