packetfilter Verständnissfrage

Manga

Well-Known Member
Hallo,

kann mir jemand mal kurz die pros und contras nennen,
für Packetfilter, die jedes Interface betrachten (wie zb. pf)
und solche die die Firewall als ganzes sehen (wie zb. netfilter).

Welchen Vorteil habe ich dadurch, das ich der Firewall erst sage, der Verkehr darf
in dieses Interface rein, und aus jenem wieder raus, anstatt gleich zu sagen
der Verkehr darf von diesem in jenes Netz?

ich hoffe es is halbwegs verständlich was ich meine.


MfG
 
Auch wenn das jetzt vlt. nicht dem Typus Antwort entspricht den du dir erhofft hast...

Besorg dir von irgendwoher das Buch "Firewalls und Sicherheit im Internet" von William Cheswick, Steven Bellovin und Aviel Rubins. Die erklaeren die Thematik ausfuehrlich und leicht verstaendlich. :) Nebenbei lernt man noch so einige andere interessante Sachen zu dem Thema an sich...
Die ISBN: 3-8273-2117-4

Gruss,
Philipp
 
-Daemon- schrieb:
Ich hab mir den Link jetzt nicht angeschaut, aber wenn du das so siehst, ist die Buecher-Sektion im Wiki auch Werbung. ;)

Anstatt die 30 Sekunden für deine Antwort zu verschwenden, hättest du dir lieber die 10 Sekunden Zeit für den Link nehmen sollen.

Zu deinem Einwand: Die Büchersektion im Wiki allgemein gehalten; du wirst wohl kaum eine Seite im Wiki zu einem bestimmten Problem finden, auf der nichts steht außer: "Kauf dir dieses Buch".

Zur ursprünglichen Frage: Jedes Interface einzeln zu betrachten erfordert zwar geringfügig mehr Konfigurationsaufwand, ermöglicht dafür Konfigurationen, die mit der reinen Netzwerk-Betrachtung nicht möglich sind, z.B. reverse path filtering oder unterschiedliche Filterregeln bei redundanter Netzwerkanbindung an zwei unterschiedlichen Interfaces.

Die Vor- und Nachteile von netfilter/iptables im Vergleich zu pf sind nochmal ein ganz anderes Thema...
 
@ -Daemon-

Auch wenn das jetzt vlt. nicht dem Typus Antwort entspricht den du dir erhofft hast...

Ja, tatsächlich :) ,
Das Buch sieht schon ziemlich interresant aus, aber ich bezweifle irgendwie,
das es mir bei dieser speziellen Frage helfen kann.

@Azazyel

hast Du vielleicht irgendwo ein- zwei konkrete Beispiele?


Und wo wir gerade dabei sind:

Was ist der unterschied zwischen "urpf-failed" und "antispoof" ?

macht das nicht im Prinzip das selbe?


MfG
 
Manga schrieb:
hast Du vielleicht irgendwo ein- zwei konkrete Beispiele?

Mit einem Beispiel aus der Praxis kann ich dienen.

Es ging um den zentralen Standort eines Unternehmens, der über diverse Standleitungen mit anderen Standorten verbunden war. Über diese Leitungen durfte jegliche Art Daten gehen. Zusätzlich hatte jeder Standort eine Internetanbindung.

Im Falle eines Verbindungsausfalls der Standleitung zwischen zwei Standorten wurde der Traffic einfach vorübergehend über das Internet geroutet, es gab aber "unternehmenskritische" Daten einiger Legacy-Anwendungen, die unter gar keinen Umständen über öffentliche Netze gehen durften (auch nicht per VPN, die Entscheider wollten das so).

Das Problem konnte man also einfach lösen, in dem man trotz identischen Quell- und Zielnetzes an einem Interface die entsprechenden Ports freischaltete, am anderen Interface aber sperrte. Dann ging zwar die Kommunikation besagter Legacy-Anwendungen vorübergehend nicht mehr, aber das war verschmerzbar.

Was ist der unterschied zwischen "urpf-failed" und "antispoof" ?

macht das nicht im Prinzip das selbe?

Der Unterschied liegt im Detail. Nehmen wir zum Beispiel an, das Netz 192.168.1.0/24 liegt am Interface xl0.

"antispoof" verhindert, dass jemand über ein anderes Interface, z.B. xl1, ein Paket mit einer Absenderadresse in 192.168.1.0/24 verschicken kann.

"urpf-failed" verhindert, dass jemand an xl0 eine andere Absenderadresse als 192.168.1.0/24 benutzen kann.

In diesem Falle würde "antispoof" nicht verhindern, dass jemand an xl0 eine eine Absenderadresse aus dem Netz 172.16.0.0/16 verwenden würde, "urpf-failed" schon.
 
Hallo,
danke für die Info.

Eine Frage noch zu urpf:

antispoof kann man ja zu

block in on ! fxp0 inet from 10.0.0.0/24 to any
block in inet from 10.0.0.1 to any expandieren.

wie sieht das bei urpf aus?
Es müsste ja wenn ich das richtig verstanden habe ungefähr so aussehen:

block in quick on int_if inet from ! int_net to any

nur das int_net eigentlich besser int_route _table wäre, sonst funktionierts ja nur
wenn an dem Interface tatsächlich nur ein Netz hängt, wenn durch den
Router noch andere Netze durchgeroutet werden, würden die ja auch geblockt.

Gibts da eine Möglichkeit?
 
Manga schrieb:
wie sieht das bei urpf aus?
Es müsste ja wenn ich das richtig verstanden habe ungefähr so aussehen:

block in quick on int_if inet from ! int_net to any

nur das int_net eigentlich besser int_route _table wäre, sonst funktionierts ja nur
wenn an dem Interface tatsächlich nur ein Netz hängt, wenn durch den
Router noch andere Netze durchgeroutet werden, würden die ja auch geblockt.

Gibts da eine Möglichkeit?

Deine Regel mit int_net war schon richtig, urpf ist nur für Router an Endpunkten (die also den gesamten Adressbereich an einem Interface kennen) gedacht (vor allem für ISPs, die eigene Adressbereiche für dynamische IPs haben).
 
Ok,
nachdem ich die betreffenden RCF´s gefunden hab (2267 bzw 2827 - was hat sich bei denen eigentlich geändert?),
hab ich sie mir mal zu Gemüte geführt.
ich glaub so langsam hab ich´s, danke für die Tips
Auf routern auf höherer Ebene wäre das wohl Rechenleistungstechnisch eh zu aufwändig.
 
Zurück
Oben