Kernel Configuration

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Kernel Configuration

Beitrag von pelleschi » 12.03.2008 21:16:08

[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? :roll:

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?

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Re: Kernel Configuration

Beitrag von gms » 12.03.2008 21:53:23

pelleschi hat geschrieben: Könne ihr mir sagen, was das set "networking-> ... " bedeutet und wie ich das mache? :roll:
pelleschi hat geschrieben: Muss ich für den gebrauch von Iptables etwas spezielles am Kernel aktivieren?
wenn du einen Kernel aus dem Debian-Repository verwendest nicht

ob dein Kernel mit Bridging konfiguriert wurde, kannst du mit diesem Kommando feststellen:

Code: Alles auswählen

grep CONFIG_BRIDGE /boot/config-$(uname -r) 
das sollte dir dann zumindest eine Zeile mit zurückliefern:

Code: Alles auswählen

CONFIG_BRIDGE=m
wenn so etwas ausgegeben wird, dann wäre das schlecht:

Code: Alles auswählen

# CONFIG_BRIDGE is not set
Gruß
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 :lol:

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 12.03.2008 22:38:21

Ja :lol: ...
Brauche diese Bridge für eine Arbeit in der Schule.. und sie will und will nicht. Werde morgen sofort den Kernel checken.

Vielen Dank für die Antwort.

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 13.03.2008 09:15:45

So habe es angeschaut... es liefert mir tatsächlich eine =m züruck.
Nun meine Frage. Kann es sein, dass sich irgendeine lokale FW noch einmischt?

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 13.03.2008 10:23:54

Habe etz gesehen dass eigentlich ein Y drin stehen mösste wie mache ich das nun?

Spasswolf
Beiträge: 3472
Registriert: 30.11.2005 10:32:22
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Wald

Beitrag von Spasswolf » 13.03.2008 10:41:41

Eigentlich sollte es doch reichen das bridge Modul zu laden:

Code: Alles auswählen

modprobe bridge
Ä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?

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 13.03.2008 11:04:54

Doch schon...

War nur ein wenig genervt... sry

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Beitrag von DynaBlaster » 13.03.2008 11:37:42

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
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.

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
Die Clients im Netz 192.168.0.0/24 bekommen als Standard-GW die eth0-IP des ETCH-Rechners zugewiesen. Die Clients im Netz 192.168.1.0/24 nutzen entweder die eth1-IP des ETCH-Rechners oder du musst auf dem Router eine statische Route ins Netz 192.168.0.0/24 über die eth1-IP des ETCH-Rechners eintragen.

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 13.03.2008 15:17:18

Ich möchte später das Snort im Inlinemodus auf dem ETCH installieren.
Brauche nun etwas das ich wie gesagt Inline schalten kann.

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Beitrag von DynaBlaster » 13.03.2008 16:01:37

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?

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 13.03.2008 18:01:29

Bin nun daran den Kernel neu zu kompilieren. Die Option "802.1d Bridging" habe ich jetzt enabled.
Ist das Standart, dass diese Einstellung nicht mitinstalliert ist? Oder habe ich einen Fehler gemacht?

Werde mich morgen nach dem Test der Bridge nochmal melden.

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 13.03.2008 18:01:29

Bin nun daran den Kernel neu zu kompilieren. Die Option "802.1d Bridging" habe ich jetzt enabled.
Ist das Standart, dass diese Einstellung nicht mitinstalliert ist? Oder habe ich einen Fehler gemacht?

Werde mich morgen nach dem Test der Bridge nochmal melden.

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Beitrag von DynaBlaster » 13.03.2008 18:24:00

Naja, laut
grep CONFIG_BRIDGE /boot/config-$(uname -r)
CONFIG_BRIDGE=m
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.

CONFIG_BRIDGE=m - entspricht als Modul eingebaut
CONFIG_BRIDGE=* - fest im Kernel eingebaut
# CONFIG_BRIDGE is not set - deaktiviert

Viel Erfolg jedenfalls ....

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 14.03.2008 15:47:56

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:

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
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

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Beitrag von DynaBlaster » 14.03.2008 16:06:02

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.

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 14.03.2008 16:56:11

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
Habe von dieser Seite her die Idee mit dem Bridging:
http://www.openmaniak.com/inline_bridge.php

EDIT KBDCALS: Codetags eingefügt

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Beitrag von DynaBlaster » 14.03.2008 17:43:04

So langsam verstehe ich, was du machen willst.
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
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.

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.

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 14.03.2008 18:11:42

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.

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Beitrag von DynaBlaster » 14.03.2008 18:24:51

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 ...

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 14.03.2008 18:28:28

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.

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Beitrag von DynaBlaster » 15.03.2008 01:38:42

Reicht es aus wenn ich einfach echo 1 > /proc/sys/net/ipv4/ip_forward eingebe, um das Routing zu aktivieren?
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.

Code: Alles auswählen

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -j QUEUE
Die Frage, die ich mir stelle, ist halt, wie der ESX-Server intern routet - sprich welchen Traffic sendet der ESX-Server an seine virtuellen Maschinen - aber wie gesagt, ich kenne mich in dieser Richtung nicht wirklich aus ....

pelleschi
Beiträge: 19
Registriert: 12.03.2008 16:44:01

Beitrag von pelleschi » 18.03.2008 22:23:23

Also meinst du mit diesen beiden Zeilen muss ich gar kein Bridging mehr vornhemen?

Kann es sein, dass ich das IPTABLES noch anpassen muss?

iptables -I FORWARD -o br0 -j ACCEPT


Dachte zwar das IPTABLES als default alles auf ACCEPT gesetzt hat...

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Beitrag von DynaBlaster » 19.03.2008 15:03:22

Dachte zwar das IPTABLES als default alles auf ACCEPT gesetzt hat...
Das ist auch so, aber ip_forward ist meines Wissens nach bei Debian standardmaessig deaktiviert.

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.

Antworten