Kernel Configuration
Kernel Configuration
[edit] Kernel Configuration
You need to enable bridging in the kernel. Set "networking -> 802.1d Ethernet Bridging" to either yes or module
Komme leider mit meinem Bridging immer noch nicht weiter.
Habe nun auf folgender Seite http://www.linux-foundation.org/en/Net: ... figuration
nochmals eine Anleitung gefunden. Könne ihr mir sagen, was das set "networking-> ... " bedeutet und wie ich das mache?
Grundsätzlich sieht es so aus.
2 NICs für das Bridge System: eth0 und eth1
NET 192.168.0.0/24 ----eth0<----ETCH (mit Snort-inline)---->eth1-----192.168.1.0/24-----eth2<---Router--->WAN
Nun möchte ich diese Bridge einrichten, damit ich den ganzen Verkehr mittels iptables an Snort senden kann.
Muss ich für den gebrauch von Iptables etwas spezielles am Kernel aktivieren?
You need to enable bridging in the kernel. Set "networking -> 802.1d Ethernet Bridging" to either yes or module
Komme leider mit meinem Bridging immer noch nicht weiter.
Habe nun auf folgender Seite http://www.linux-foundation.org/en/Net: ... figuration
nochmals eine Anleitung gefunden. Könne ihr mir sagen, was das set "networking-> ... " bedeutet und wie ich das mache?
Grundsätzlich sieht es so aus.
2 NICs für das Bridge System: eth0 und eth1
NET 192.168.0.0/24 ----eth0<----ETCH (mit Snort-inline)---->eth1-----192.168.1.0/24-----eth2<---Router--->WAN
Nun möchte ich diese Bridge einrichten, damit ich den ganzen Verkehr mittels iptables an Snort senden kann.
Muss ich für den gebrauch von Iptables etwas spezielles am Kernel aktivieren?
Re: Kernel Configuration
pelleschi hat geschrieben: Könne ihr mir sagen, was das set "networking-> ... " bedeutet und wie ich das mache?
wenn du einen Kernel aus dem Debian-Repository verwendest nichtpelleschi hat geschrieben: Muss ich für den gebrauch von Iptables etwas spezielles am Kernel aktivieren?
ob dein Kernel mit Bridging konfiguriert wurde, kannst du mit diesem Kommando feststellen:
Code: Alles auswählen
grep CONFIG_BRIDGE /boot/config-$(uname -r)
Code: Alles auswählen
CONFIG_BRIDGE=m
Code: Alles auswählen
# CONFIG_BRIDGE is not set
gms
edit: Ich habe gerade deinen anderen Thread gefunden:
http://www.debianforum.de/forum/viewtop ... highlight=
Irgendwie kommt es mir so vor, als wäre dein Wunsch nach einer Bridge doch nicht so ausgeprägt
-
- Beiträge: 3472
- Registriert: 30.11.2005 10:32:22
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Wald
Eigentlich sollte es doch reichen das bridge Modul zu laden:
Änderungen an der Kernelkonfiguration können un den vollständigen Quellen mit "make menuconfig" vorgenommen werden. Allerdings muss danach der Kernel nochmal kompiliert werden.
Meinst du nicht das ein Thread reicht?
Code: Alles auswählen
modprobe bridge
Meinst du nicht das ein Thread reicht?
- DynaBlaster
- Beiträge: 958
- Registriert: 25.03.2004 18:18:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DF0://dynablaster.adf
Wieso brauchst du überhaupt eine Bridge? Eine Bridge hat für gewöhnlich nur eine (!!!) IP-Adresse und dient zum Zusammenfassen getrennter physikalischer Netze in ein Subnetz - Normale WLAN-Router machen das z.B. mit ihrer WLAN-Schnittstelle und ihrer Ethernet-Schnittstelle.Grundsätzlich sieht es so aus.
2 NICs für das Bridge System: eth0 und eth1
NET 192.168.0.0/24 ----eth0<----ETCH (mit Snort-inline)---->eth1-----192.168.1.0/24-----eth2<---Router--->WAN
Was genau willst du denn erreichen? Die beiden Netze kannst du doch über normales Routing miteinander verbinden; grundsätzlich sollte das hier reichen, wenn eine iptables-Script auf dem ETCH-PC läuft, muss das entsprechend angepasst werden.
Code: Alles auswählen
echo "1" > /proc/sys/net/ipv4/ip_forward
- DynaBlaster
- Beiträge: 958
- Registriert: 25.03.2004 18:18:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DF0://dynablaster.adf
Ok, ich wusste zugegebenermassen nicht, was snort-inline ist und wofür es gut ist. Nach ein bisschen Recherche bin ich nun schlauer - man will ja nicht dumm sterbern
So wie ich das sehe, sollte der Standard-Debian-Kernel aus ETCH ausreichen, um snort-inline benutzen zu können, jedenfalls was die Bridging-Fahigkeit angeht. Wie Spasswolf schon anmerkte, "modbrobe bridge" läd das entsprwchende Modul und im Anschluß müsste snort-inline das auch benutzen können.
Ich habe das hier gefunden (leider von Anfang 2006) und es scheint einige Fallstricke bezüglich snort-inle zu geben bzw. gegeben zu haben. https://wwwbs.informatik.htw-dresden.de ... rt_inline/
Wie gesagt, ich kenne snort-inline nicht, aber wie es aussieht, greift snort-inline irgendwie auf die Bridging-Fähigkeiten des Kernels zurück, um die IP-Pakete, die mittels iptables in die Queue-Kette sortiert werden müssen, überhaupt weiterverarbeiten zu können.
Gibt es denn Fehlermeldungen von snort-inline?
So wie ich das sehe, sollte der Standard-Debian-Kernel aus ETCH ausreichen, um snort-inline benutzen zu können, jedenfalls was die Bridging-Fahigkeit angeht. Wie Spasswolf schon anmerkte, "modbrobe bridge" läd das entsprwchende Modul und im Anschluß müsste snort-inline das auch benutzen können.
Ich habe das hier gefunden (leider von Anfang 2006) und es scheint einige Fallstricke bezüglich snort-inle zu geben bzw. gegeben zu haben. https://wwwbs.informatik.htw-dresden.de ... rt_inline/
Wie gesagt, ich kenne snort-inline nicht, aber wie es aussieht, greift snort-inline irgendwie auf die Bridging-Fähigkeiten des Kernels zurück, um die IP-Pakete, die mittels iptables in die Queue-Kette sortiert werden müssen, überhaupt weiterverarbeiten zu können.
Gibt es denn Fehlermeldungen von snort-inline?
- DynaBlaster
- Beiträge: 958
- Registriert: 25.03.2004 18:18:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DF0://dynablaster.adf
Naja, laut
CONFIG_BRIDGE=m - entspricht als Modul eingebaut
CONFIG_BRIDGE=* - fest im Kernel eingebaut
# CONFIG_BRIDGE is not set - deaktiviert
Viel Erfolg jedenfalls ....
war "802.1d Bridging" auch schon vorher enabled - nur halt als Modul und nicht fest im Kernel einkompiliert. Beim festen Einbau des Moduls fällt halt das Laden des Moduls mittels modprobe/insmod weg, ansonsten ist der Funktionsumfang der selbe, egal ob Modul oder fest eingebaut.grep CONFIG_BRIDGE /boot/config-$(uname -r)
CONFIG_BRIDGE=m
CONFIG_BRIDGE=m - entspricht als Modul eingebaut
CONFIG_BRIDGE=* - fest im Kernel eingebaut
# CONFIG_BRIDGE is not set - deaktiviert
Viel Erfolg jedenfalls ....
Hallo Zusammen.
Das mit dem Kernel hat prima geklappt. Habe auch bemerkt, dass es gar nicht nötig gewesen wäre aber ja.
Nun habe ich folgende Schritte gemacht.
1. die Bridge-Utils installiert.
2. mit diesem Skript die Bridge erstellt:
Ein Ping funktioniert aber immernoch nicht.
Wenn ich aber mit
watch ifconfig br0
den Verkehr betrachte, habe ich sowohl RX, wie auch TX Packete.
EDIT KBDCALLS: Codetags eingefügt
Das mit dem Kernel hat prima geklappt. Habe auch bemerkt, dass es gar nicht nötig gewesen wäre aber ja.
Nun habe ich folgende Schritte gemacht.
1. die Bridge-Utils installiert.
2. mit diesem Skript die Bridge erstellt:
Code: Alles auswählen
#!bin/sh
ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 up
brctl br0 show
echo -e
Wenn ich aber mit
watch ifconfig br0
den Verkehr betrachte, habe ich sowohl RX, wie auch TX Packete.
EDIT KBDCALLS: Codetags eingefügt
- DynaBlaster
- Beiträge: 958
- Registriert: 25.03.2004 18:18:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DF0://dynablaster.adf
Welche IP hat denn die br0 ? Poste mal bitte "ifconfig -a" und "route -n".
Läuft auf dem Rechner schon ein iptables-Script, das evtl. für die Bridge angepasst werden muss ?
Und noch einmal. Bist du sicher, dass du eth0 und eth1 wirklich zu br0 zusammenfassen musst, um snort-inline benutzen zu können? Beim Überfliegen der meines Erachtens nach ziemlich dürftigen Doku auf der Projekt-HP habe ich nämlich nichts vom Erstellen einer Bridge gelesen, lediglich der Kernel muss die Fähigkeiten zum "Bridgen" haben - jedenfalls habe ich das so verstanden. Wahrscheinlich "bridged" snort-inline alle Pakete, die mittels iptables in die Queue-Chain sortiert werden, vom physischen Netzwerk-Device (also eth0, eth1, usw.) an ein snort-inline-eigenes Device (stelle mir das gerade wie eine Art virtuelles Device vor), wendet daraufhin die snort-inline-spezifischen Regeln an, und "bridged" dann alles zurück an iptables, das anschließend weitermacht.
Läuft auf dem Rechner schon ein iptables-Script, das evtl. für die Bridge angepasst werden muss ?
Und noch einmal. Bist du sicher, dass du eth0 und eth1 wirklich zu br0 zusammenfassen musst, um snort-inline benutzen zu können? Beim Überfliegen der meines Erachtens nach ziemlich dürftigen Doku auf der Projekt-HP habe ich nämlich nichts vom Erstellen einer Bridge gelesen, lediglich der Kernel muss die Fähigkeiten zum "Bridgen" haben - jedenfalls habe ich das so verstanden. Wahrscheinlich "bridged" snort-inline alle Pakete, die mittels iptables in die Queue-Chain sortiert werden, vom physischen Netzwerk-Device (also eth0, eth1, usw.) an ein snort-inline-eigenes Device (stelle mir das gerade wie eine Art virtuelles Device vor), wendet daraufhin die snort-inline-spezifischen Regeln an, und "bridged" dann alles zurück an iptables, das anschließend weitermacht.
Code: Alles auswählen
Snort-Inline-1:/home/user1# . /usr/src/testbridge.sh
bridge name bridge id STP enabled interfaces
br0 8000.000c297d51b6 no eth0
eth1
Code: Alles auswählen
Snort-Inline-1:/home/user1# ifconfig -a
br0 Protokoll:Ethernet Hardware Adresse 00:0C:29:7D:51:B6
inet6 Adresse: fe80::20c:29ff:fe7d:51b6/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING NOARP PROMISC MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:138 (138.0 b) TX bytes:210 (210.0 b)
eth0 Protokoll:Ethernet Hardware Adresse 00:0C:29:7D:51:B6
inet6 Adresse: fe80::20c:29ff:fe7d:51b6/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING NOARP PROMISC MULTICAST MTU:1500 Metric:1
RX packets:835 errors:0 dropped:0 overruns:0 frame:0
TX packets:963 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:602994 (588.8 KiB) TX bytes:162298 (158.4 KiB)
Interrupt:17 Basisadresse:0x1400
eth1 Protokoll:Ethernet Hardware Adresse 00:0C:29:7D:51:C0
inet6 Adresse: fe80::20c:29ff:fe7d:51c0/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING NOARP PROMISC MULTICAST MTU:1500 Metric:1
RX packets:159 errors:0 dropped:0 overruns:0 frame:0
TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:9913 (9.6 KiB) TX bytes:5165 (5.0 KiB)
Interrupt:18 Basisadresse:0x1480
eth2 Protokoll:Ethernet Hardware Adresse 00:0C:29:7D:51:CA
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:0 (0.0 b) TX bytes:510 (510.0 b)
Interrupt:19 Basisadresse:0x1800
lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1416 errors:0 dropped:0 overruns:0 frame:0
TX packets:1416 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:109232 (106.6 KiB) TX bytes:109232 (106.6 KiB)
Snort-Inline-1:/home/user1# route -n
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
http://www.openmaniak.com/inline_bridge.php
EDIT KBDCALS: Codetags eingefügt
- DynaBlaster
- Beiträge: 958
- Registriert: 25.03.2004 18:18:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DF0://dynablaster.adf
So langsam verstehe ich, was du machen willst.
Wenn du beide Netze brauchst (also 192.168.0.0/24 und 192.168.1.0/24), dann musst du auf dem ETCH-Rechner auch 2 IP's haben, jeweils eine im entsprechenden Netz - sonst wird da nix geroutet, snort-inline hin oder her.
Grundsätzlich muss ip_forward aktiv sein und die FORWARD-CHAIN sollte vorerst nichts filtern.
Nach dem Bildchen (Case1) des Links dürfen eth0 und eth1 (also die Bridge) nicht in unterschiedlichen Netzen sein. Besser ausgedrückt: die Client-PC's müssen im selben Netz sein. Für die Bridge ist das ja egal - die hat ja keine eigene IP. Die br0 aus eth0 und eth1 ist quasi transparent, um den kompletten Traffic zwischen den physikalischen Netzen für die snort-Analyse abgreifen zu können - so ähnlich als wenn man alles über einen Mirror-Port am Switch für den SNORT-Rechner duplizieren würde - natürlich mit dem Vorteil, dass man den Traffic nicht nur analysieren kann, sondern Traffic wirklich filtern kann.2 NICs für das Bridge System: eth0 und eth1
NET 192.168.0.0/24 ----eth0<----ETCH (mit Snort-inline)---->eth1-----192.168.1.0/24-----eth2<---Router--->WAN
Wenn du beide Netze brauchst (also 192.168.0.0/24 und 192.168.1.0/24), dann musst du auf dem ETCH-Rechner auch 2 IP's haben, jeweils eine im entsprechenden Netz - sonst wird da nix geroutet, snort-inline hin oder her.
Grundsätzlich muss ip_forward aktiv sein und die FORWARD-CHAIN sollte vorerst nichts filtern.
Ja genau. Es soll lediglich den Verkehr Sniffen und so geschaltet sein, dass es gerade Ports schliessen kann.
Ich habe aber nur 1 Netz. Grob erklärt:
WAN---->(PPPOE Router und FW mit IP 192.168.1.254/24)-----(ETH0:SNORT:ETH1)-----(verschiedene Clients im Lan 192.168.1.0/24)
Und weil das Ganze auf einem VmWare ESX Server läuft, musste ich einfach zwei virtual Switches erstellen. In jedem von diesem virtual Switch hat nun SNORT eine NIC drin.
Ich habe aber nur 1 Netz. Grob erklärt:
WAN---->(PPPOE Router und FW mit IP 192.168.1.254/24)-----(ETH0:SNORT:ETH1)-----(verschiedene Clients im Lan 192.168.1.0/24)
Und weil das Ganze auf einem VmWare ESX Server läuft, musste ich einfach zwei virtual Switches erstellen. In jedem von diesem virtual Switch hat nun SNORT eine NIC drin.
- DynaBlaster
- Beiträge: 958
- Registriert: 25.03.2004 18:18:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DF0://dynablaster.adf
Puh, die Frage ist also eher, wie VMWare bzw. die virtuellen Switches konfiguriert werden müssen, damit der gesamte Traffic auch da ankommt, wo er hin soll. Mit VMWare kenne ich mich nicht genügend aus, sorry. Hilfreich wäre allerdings, wenn man wüsste ob snort-inline auf dem ESX-Server selbst läuft oder auf einem Gastsystem ...
Wie meinst du das jetzt genau. Das Snort ist einfach ne virtuelle Maschine auf dem ESX Server.
Andere Frage:
Reicht es aus wenn ich einfach echo 1 > /proc/sys/net/ipv4/ip_forward eingebe, um das Routing zu aktivieren?
Und installiert Debian irgendeine FW mit, die da auch noch ins Spiel kommen könnte?Wie schön erwähnt watch ifconfig br0 liefert mir RX sowohl auch TX Pakete.
Andere Frage:
Reicht es aus wenn ich einfach echo 1 > /proc/sys/net/ipv4/ip_forward eingebe, um das Routing zu aktivieren?
Und installiert Debian irgendeine FW mit, die da auch noch ins Spiel kommen könnte?Wie schön erwähnt watch ifconfig br0 liefert mir RX sowohl auch TX Pakete.
- DynaBlaster
- Beiträge: 958
- Registriert: 25.03.2004 18:18:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DF0://dynablaster.adf
Ja, damit leitet der Kernel grundsätzlich alles weiter + Debian hat standardmässig keine Firewall installiert. Demnach sollte snort-inline mit diesen beiden Zeilen den gerouteten Traffic analysieren können.Reicht es aus wenn ich einfach echo 1 > /proc/sys/net/ipv4/ip_forward eingebe, um das Routing zu aktivieren?
Code: Alles auswählen
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -j QUEUE
- DynaBlaster
- Beiträge: 958
- Registriert: 25.03.2004 18:18:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: DF0://dynablaster.adf
Das ist auch so, aber ip_forward ist meines Wissens nach bei Debian standardmaessig deaktiviert.Dachte zwar das IPTABLES als default alles auf ACCEPT gesetzt hat...
Was den Nutzen des Bridging angeht:
So wie ich snort-inline verstanden habe, braucht man zwar die Bridging-Funktionalität des Linux-Kernels, aber nicht unbedingt eine wirkliche Bridge, um snort-inline zu nutzen. Der Sinn deiner Konfiguration eines snort-inline auf einer virtuellen Maschine ist meines Erachtens nach fragwürdig, denn der Traffic, der zu dieser VM gelangt, wird ja schon vorher irgendwo geroutet.
Das Szeanrio mit der Bridge von eth0 und eth1 aus dem geposteten Howto macht imho nur Sinn, wenn ein "richtiger" Rechner zwischen Router (eth0) und LAN (eth1) sitzt, um daraufhin den gesamten Traffic, der seine gebridgten Netzwerkkarten passiert, mittels snort-inline zu untersuchen. Die Bridge zwischen eth0 und eth1 wird in diesem Szenario ja nur genutzt, um den snort-inline-Rechner quasi "unsichtbar" (bzw. transparent - wie auch immer da der richtige Ausdruck für ist) zwischen Router und LAN zu platzieren.