Zu dumm für ipfilter

Konfuzius

human being
Moin,

ich habe gerade das Gefühl an ipfilter verzweifeln zu müssen.
Firewalltechnisch hänge ich irgendwie noch immer bei Linux und
iptables..

Folgende Konfiguration:
Firewall ipfilter
Kernel Options (4.9)

# Firewall Support
options IPFILTER
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK

internes Netz -> xl0 -> vr0 -> Router

In einem Moment von Unwissen und Umnachtung habe ich auf der Kiste
aber auch den natd aktiviert der auf der vr0 rum mapped:
map vr0 192.168.1.0/24 -> 0.0.0.0/32

Durch das default_block muss/will ich nun jeden Port definieren, um die
einzelnen Services frei zu schalten.

Demnach, so meine Annahme, müsste ein:
pass in quick on xl0 proto tcp from 192.168.1.0/24 to any port = 80 keep state

doch folglich meinen Usern das Surfen erlauben, oder sehe ich das falsch?

Weiter habe ich irgendwo gelesen, dass das Paket auf dem Weg von
Innen nach Aussen per folgendem Schema wandert:

pass in xl0 -> pass out vr0

Müsste ich also noch eine entsprechende Gegenregel auf vr0 definieren a la:
pass out quick on vr0 proto tcp from 192.168.1.0/24 to any port = 80 keep state


HILFEEEEE :)

Konfuzius
 
Hmmm,

pass in quick rl0
pass out quick rl0

pass in quick lo0
pass out quick lo0

pass out quick tun0


Passiert das Paket also auf dem Wege von rl0 nach tun0 auch lo0?

Und warum überall ein pass in -> pass out, aber bei tun0 nicht?

Ich werde deinen Regelsatz gleich mal einspielen und testen, aber ich
würde nicht so gerne alle Kommunikation von innen nach aussen zulassen.
Mir wäre es lieber nur http und https zu genehmigen. Daher auch die
Frage mit dem in und out, denn der Traffic geht ja auf dem Weg über
zwei Interfaces (rl0 und tun0 bei dir, xl0 und vr0 bei mir)..

Ich habe auch noch im ipfilter-howto von obfuscation.org gelesen und
war über die Einstellungen für einen transparenten squid gestolpert,
trage ich das rdr in der ipnat.conf ein oder auch in der ipf.filter ?


Konfuzius
 
@Maledictus
Ich dachte es geht um IPFilter..? ;)

@Konfuzius
Beim tun0 gibt es kein "pass in" weil es nicht erlaubt sein soll eine Verbindung nach innen aufzubauen, bei zustande gekommener Verbindung dürfen die Daten in beide Richtungen laufen, wegen dem "keep state".

Nur weil lo0 in den Regeln steht, heisst das nicht das da auch Pakete hingeschickt werden. Die Regeln definieren keinen Weg (keine Reihenfolge die JEDES Paket durchläuft) den das Datenpaket nimmt. Sondern sie enthalten die Information ob ein Paket (am Ende des egelsatzes) durch gelassen wird (oder nicht).


Hier ist noch ein ganz nettes howto zum Thema:
http://www.onlamp.com/pub/a/bsd/2002/02/28/openbsd.html?page=1
Es ist zwar für OpenBSD, kann aber vom Regelsatz hier 1:1 auf FreeBSD angewandt werden.
 
Konfuzius schrieb:
Moin,

ich habe gerade das Gefühl an ipfilter verzweifeln zu müssen.
Firewalltechnisch hänge ich irgendwie noch immer bei Linux und
iptables..


Ähem, ist zwar komplett off-topic aber auf längere Sicht wirst du mir bestimmt dankbar sein, wenn ich dir statt ipf den viel besseren pf vorschlage.

pf ist von OpenBSD auf FreeBSD/NetBSD portiert worden und läuft prima auf diesen beiden.

Mehr Infos findest du hier und hier und schnapp dir auch die offizielle pf-FAQ (pdf).

Wenn du magst, kann du dir auch meine pf-FAQ (pdf) schnappen. Ich werde bald eine Neuauflage erstellen :)

Alles, was ipf kann, kann pf viel besser und noch eine sangenhafte Menge mehr als dieser.

Lese dir die Sachen durch und vergleiche. :)

Grüße und viel Erfolg!
 
Zuletzt bearbeitet:
Moin,

Alles, was ipf kann, kann pf viel besser und noch eine sangenhafte Menge mehr als dieser.

Lese dir die Sachen durch und vergleiche. :)

Grüße und viel Erfolg!

Ok, werde ich mir heute abend mal anschauen, einzig, pf gibt es derzeitig ja nur
in der 5.2er Reihe. Da bootet aber der Datenträger aus irgendwelchen Gründen
nicht auf der Büchse (ist nen alter HP Server) und für einen Umstieg von 4.9 auf
5.2.1, also das kompilieren des halben Systems fühle ich mich derzeitig nicht
fit genug in der Materie.

Sprich, der Aufwand wäre noch höher.. Allerdings habe ich den Rat schon
einmal gehört, es könnte also was dran sein. Ich werde es beobachten..

Konf
 
Zurück
Oben