Bridge oder Router?

B

balu

Well-Known Member
Ok, folgende Situation:

LAN - Host 1 - DSL Router

Der DSL Router ist nen WLAN Router und die Verbindung zu Host 1 ist halt WLAN.
Host 1 ist wie das LAN an einem Switch.

Generell soll Host 1 als Packetfilter fungieren, setzt man den besser als Router der zwischen WLAN (wo ansich nur der DLS Router drinhängt, selten auch nen Laptop der vom LAN aus auch erreichbar sein muss) und LAN routet, oder als transparente Bidge auf?

Die einfachere Lösung / die sympathischere oder gibts Gründe warum eins dafür prädistiniert ist? Rein theoretisch müsste ja beides funktionieren?

Rein intuitiv würde ich sagen eine bridge bietet weniger Angriffsfläche oder?
 
Zuletzt bearbeitet:
Die Bridge brauchst du hier nicht unbedingt. Das gute, alte PacketForwarding reicht alle Male ... egal ob wlan oder nicht.

Und eine bridge hat nix mit irgendeiner "Angriffsfläche" zu tun, denn es wird nicht die Hardware angegriffen (auch nicht eine "logische" wie es die bridge ist), sondern die Software (also daemons etc.).
 
Zuletzt bearbeitet:
Naja, nur dann hat der PF ja ne IP, kann quasi direkt angesprochen werden, also hat ein potentieller Angreifer ja einen Ansatzpunkt.

Ne Bridge ist doch transparent oder nicht? kann also nicht direkt angesprochen werden.
 
balu schrieb:
Naja, nur dann hat der PF ja ne IP, kann quasi direkt angesprochen werden, also hat ein potentieller Angreifer ja einen Ansatzpunkt.

Ne Bridge ist doch transparent oder nicht? kann also nicht direkt angesprochen werden.
Zum Vergrößern anklicken....

Und wie wäre es mit blockieren von Außenanfragen auf die Firewall-IP?
 
Die blockiert man aber doch über den PF selber.

Ist nun aber nen rudimentärer Fehler in der PF Software selbst, oder im TCP/IP Stack und man hat die IP, so kann man ihn doch direkt angreifen oder nicht?

Hat ein Angreifer Zugriff zu dem PF der gleichzeitig auch noch Router in das Netz dahinter ist, hat er Zugriff auf das gesamte Netz.

Wäre der PF transparent und es währe nen Fehler in der PF Implementierung, würde es nen Atter ja ansich nichts nutzen da er den PF nicht direkt ansprechen kann, oder verrenn ich mich hier? :D
 
balu schrieb:
Die blockiert man aber doch über den PF selber.

Ist nun aber nen rudimentärer Fehler in der PF Software selbst, oder im TCP/IP Stack und man hat die IP, so kann man ihn doch direkt angreifen oder nicht?

Hat ein Angreifer Zugriff zu dem PF der gleichzeitig auch noch Router in das Netz dahinter ist, hat er Zugriff auf das gesamte Netz.

Wäre der PF transparent und es währe nen Fehler in der PF Implementierung, würde es nen Atter ja ansich nichts nutzen da er den PF nicht direkt ansprechen kann, oder verrenn ich mich hier? :D
Zum Vergrößern anklicken....

Wie wäre es mit "weniger komplex denken ist mehr vernünftig handeln"?

Außerdem kann ein Angreifer keinen "Zugriff zum PF" haben, da PF IM KERNEL SITZT!

Lese dir bitte die FAQ/Manpages durch. Die sind voll von Beispielen.

Außerdem gibt es das wirklich gute Buch von Jacek Artymiak zum PF selbst.

Und auch eine "unsichtbare" Firewall schützt nicht vor miserabel konfigurierter/programmierter Software (daemons etc.) im Hintergrund (sprich: auf den Rechnern in deinem LAN).

Und beim nächsten Mal benutze die OpenBSD-Sparte für deine Netzwerkfragen, wenn es schon ums Netzwerken mit OpenBSD geht, O.K.?
 
Zuletzt bearbeitet:
CW schrieb:
Wie wäre es mit "weniger komplex denken ist mehr vernünftig handeln"?

Außerdem kann ein Angreifer keinen "Zugriff zum PF" haben, da PF IM KERNEL SITZT!

Lese dir bitte die FAQ/Manpages durch. Die sind voll von Beispielen.

Außerdem gibt es das wirklich gute Buch von Jacek Artymiak zum PF selbst.

Und auch eine "unsichtbare" Firewall schützt nicht vor miserabel konfigurierter/programmierter Software (daemons etc.) im Hintergrund (sprich: auf den Rechnern in deinem LAN).

Und beim nächsten Mal benutze die OpenBSD-Sparte für deine Netzwerkfragen, wenn es schon ums Netzwerken mit OpenBSD geht, O.K.?
Zum Vergrößern anklicken....

So, immer mal halblang.

PF kann man durchaus auch als Pseudonym für einen PACKETFILTER nehmen. Ich muss _nicht_ zwingend den OpenBSD Packetfilter nehmen.

Nutze ich PF als Begriff für einen Rechner der Packets filtert kann ein Angreifer sehr wohl Zugriff bekommen, meiner Meinung nach bei einem transparenten PF ne Ecke schwieriger, da er ihn ja nicht direkt adressieren kann.

Sicher schützt eine unsichtbare Firewall nicht vor miserable konfigurierter Software dahinter, aber um die Software geht es hier im Thread gar nicht, sondern rein um den PF Rechner.

Nochmal es geht hier _nicht_ um OpenBSD, sogar wenn ich mit PF genau den pf meine den du meinst so kann ich ihn auch mit NetBSD oder FreeBSD nutzen.
 
balu schrieb:
So, immer mal halblang.

PF kann man durchaus auch als Pseudonym für einen PACKETFILTER nehmen. Ich muss _nicht_ zwingend den OpenBSD Packetfilter nehmen.

Nutze ich PF als Begriff für einen Rechner der Packets filtert kann ein Angreifer sehr wohl Zugriff bekommen, meiner Meinung nach bei einem transparenten PF ne Ecke schwieriger, da er ihn ja nicht direkt adressieren kann.

Sicher schützt eine unsichtbare Firewall nicht vor miserable konfigurierter Software dahinter, aber um die Software geht es hier im Thread gar nicht, sondern rein um den PF Rechner.

Nochmal es geht hier _nicht_ um OpenBSD, sogar wenn ich mit PF genau den pf meine den du meinst so kann ich ihn auch mit NetBSD oder FreeBSD nutzen.
Zum Vergrößern anklicken....

Denkst du etwa, dass Leute hier wissen, was du meinst, wenn du einen Begriff einfach so in den Mund nimmst?

Hier ist der Akronym PF immer mit OpenBSD's Paketfilter verbunden und wenn du etwas anderes meinst, dann bitte ERKLÄRE dies auch.

Ansonsten, versuche mich nicht zu belehren, wenn du Hilfe brauchst.

Dies gilt auch für andere User, die dir helfen würden.

Und wenn du schon was anderes als STANDARD meinst (das mit PF), dann sage dies zuvor, damit wir es wissen und nicht umsonst schreiben!

Und was OpenBSD PF angeht, so kannst du diesen zwar unter FBSD voll nutzen, aber nicht unter NetBSD.

Informiere dich gründlicher.

Vor allem was die Grundlagen anbetrifft.

Und wenn ich noch deine Erklärung sehe, dass es nicht um Software, sondern um der PF-Rechner geht, kann ich nur mit meinen Augen jonglieren!

Was ist denn ein laufender Rechner???

SOFTWARE die auf HARDWARE läuft!

Und ein PF-Rechner ist ein Rechner auf welchem PF läuft!
 
Zuletzt bearbeitet:
Hallo balu,

wie hast Du es denn nun gelöst? Ich habe die gleiche Konfiguration vor mir.

Grüße
Christian
 
Hallo,

ich komme einfach nicht weiter. Mein Ziel wäre bei folgendem Netz erreicht:

--DSL WLAN AP (192.168.2.1)----< WLAN Strecke >---<(192.168.2.5) Freebsd Bridge (192.168.2.6)>------<8 fach Switch>-----<Windowsclient 192.168.2.3>

Ich habe zunächst die Tipps von CW bzgl. PacketForwarding verfolgt, aber nichts passenden für mich gefunden.
Daher hab ich das Handbuch (http://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/network-bridging.html) gelesen und so verfolgt. Mind. ein Device soll keine IP zugewiesen bekommen.
Beide Devices sind "up".

Nun ergibt sich folgendes Problem:
1. Wenn wi0 keine IP bekommt, gibt es keinen Empfang mit dem WLAN AP, also kein Internet.
2. Wenn rl0 keine IP hat, dann erreiche ich mit dem Windowsclient die FreeBSD-Bridge nicht.

Was mache ich falsch, bzw habt ihr eine Idee zur Lösung?

Grüße
Christian - der seit 3 Tagen FreeBSD nutzt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben