Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Promiscuous mode - dispatch packets to ip stack

1 view
Skip to first unread message

Andreas Born

unread,
Dec 26, 2009, 11:46:49 AM12/26/09
to
Hallo,

ich wei� leider nicht, wo ich sonst nachfragen sollte; hoffe, da� hier
jemand ist der sich mit der Problematik auskennt. Falls OT, dann bitte
XPost und F'up zur passenderen Gruppe.

Es geht darum, da� ich pakete, die an meiner Netzwerkkarte mit einer
falschen MAC (!) eintreffen, gerne mittels iptables filtern oder darauf
reagieren m�chte.

Grunds�tzlich scheinen iptables und ebtables nur pakete zu "sehen", die
mit der korrekten MAC eintreffen, unabh�ngig davon, ob die Netzwerkkarte
in den promiscuous mode geschaltet ist oder nicht.

Erste Frage: gitb es ein tool, das Pakete mit nicht "passender" MAC in
den Netzwerkstack einspeist, damit diese wie Pakete mit "passender" MAC
behandelt und geroutet werden k�nnen?


Eine andere Idee war, eine Bridge zu erstellen, um mit ebtables das
Verhalten steuern zu k�nnen. Ich habe nun:
$ brctl addbr br0
$ ifconfig br0 0.0.0.0
$ brctl addif br0 eth0
gemacht, allerdings wird eth0 dann irgendwann ge-disabled. Bevor eth0
deaktiviert wird sind dann tats�chlich auch alle Pakete unabh�ngig der
destination-MAC sichtbar. Warum aber wird eth0 deaktiviert, und l��t
sich das irgendwie verhindern?

Ich suche nur eine vor�bergehende, keine Dauerl�sung. Hintergrund ist
der, da� ich auf Pakete mit einer speziellen Destination-MAC ein
icmp-host-unreachable resp. tcp-rst senden m�chte. Gibt es vielleicht
eine alternative zu iptables? Mittels tcpkill k�nnte ich die tcp-rst's
senden, aber leider keine ICMP-Antworten auf UDP-Pakete.


Viele Gr��e,
Andreas

Volker Birk

unread,
Dec 27, 2009, 8:33:01 AM12/27/09
to
Andreas Born <Andrea...@gmx.de> wrote:
> Grundsätzlich scheinen iptables und ebtables nur pakete zu "sehen", die
> mit der korrekten MAC eintreffen, unabhängig davon, ob die Netzwerkkarte

> in den promiscuous mode geschaltet ist oder nicht.

Das sollte so nicht sein, denn das ist ja der Zweck des promiscous mode.

Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!

Andreas Born

unread,
Dec 27, 2009, 10:17:59 AM12/27/09
to
Volker Birk wrote:
> Andreas Born <Andrea...@gmx.de> wrote:
>> Grundsätzlich scheinen iptables und ebtables nur pakete zu "sehen",
>> die
>> mit der korrekten MAC eintreffen, unabhängig davon, ob die
>> Netzwerkkarte
>> in den promiscuous mode geschaltet ist oder nicht.
>
> Das sollte so nicht sein, denn das ist ja der Zweck des promiscous
> mode.

Dachte ich eigentlich auch.
tcpdump und ethereal können diese Paket auch sehen, d.h. daß der promisc
mode durchaus funktioniert.

Aber lt. google-suche bestätigt sich das beobachtete verhalten, iptables
und ebtables bekommen diese pakete nicht zu Gesicht. Ich vermute, daß
der promisc mode zwar das Abgreifen dieser Pakete mittels raw sockets
ermöglicht, aber der Netzwerkstack diese Pakete trotzdem nicht bekommt,
und damit auch ebtables und iptables nicht. (Bei iptables ist mir das
relativ klar, da es auf Schicht 3 arbeitet, aber ebtables arbeitet auf
Schicht 2 und sieht die Pakete dennoch nicht).

Ich will nicht ausschließen, daß der Fehler bei mir liegt. Wenn nicht,
dann stellt dies aber m.E. auch ein Sicherheitsproblem dar, denn es wäre
nicht möglich, unerwünschten Traffic mit den genannten Tools zu filtern;
eingeschleuster Schadcode könnte an der Firewall vorbei Daten von außen
über den promisc mode und raw sockets empfangen.


Viele Grüße,
Andreas

Volker Birk

unread,
Dec 27, 2009, 10:43:54 AM12/27/09
to
Andreas Born <Andrea...@gmx.de> wrote:
> Aber lt. google-suche bestätigt sich das beobachtete verhalten, iptables
> und ebtables bekommen diese pakete nicht zu Gesicht.

Dann bridge doch und filtere darauf mit ebtables. Dann kriegst Du alles.

Andreas Born

unread,
Dec 27, 2009, 11:27:49 AM12/27/09
to
Volker Birk wrote:
> Andreas Born <Andrea...@gmx.de> wrote:
>> Aber lt. google-suche bestätigt sich das beobachtete verhalten,
>> iptables
>> und ebtables bekommen diese pakete nicht zu Gesicht.
>
> Dann bridge doch und filtere darauf mit ebtables. Dann kriegst Du
> alles.

Genau das hatte ich ebenfalls versucht, aber irgendwas scheine ich dabei
falsch gemacht oder übersehen zu haben.

mache ich das:

# brctl addbr br0
# ifconfig br0 0.0.0.0
# brctl addif br0 eth0

klappt das für kurze zeit (1 bis 2 minuten), und auch die Pakete sind zu
sehen.
Dann allerdings wird eth0 laut log gedisabled und das netzwerk ist down.

log:
kernel: br0: topology change detected, propagating
kernel: br0: port 1(eth0) entering forwarding state
*kernel: br0: port 1(eth0) entering disabled state

Unter debian klappt das, unter dem betr. suse leider nicht. Kann das
daran liegen, daß nur eine Schnittstelle der Bridge zugeordnet wurde?
Hab ich etwas anderes vergessen?


Viele Grüße,
Andreas

Sven Hartge

unread,
Dec 27, 2009, 5:24:27 PM12/27/09
to
Andreas Born <Andrea...@gmx.de> wrote:

> log:
> kernel: br0: topology change detected, propagating
> kernel: br0: port 1(eth0) entering forwarding state
> *kernel: br0: port 1(eth0) entering disabled state

> Unter debian klappt das, unter dem betr. suse leider nicht. Kann das

> daran liegen, daᅵ nur eine Schnittstelle der Bridge zugeordnet wurde?

> Hab ich etwas anderes vergessen?

Du solltest mal STP in der Bridge abschalten. Das stᅵrt hier wohl den
von dir vorgesehenen Betrieb.

S!

--
Sig lost. Core dumped.

Andreas Born

unread,
Dec 28, 2009, 2:05:44 AM12/28/09
to

Danke, das war die Lᅵsung; jetzt funktionierts!


Viele Grᅵᅵe,
Andreas

Sven Hartge

unread,
Dec 29, 2009, 12:15:03 AM12/29/09
to

Eigentlich sollte der Code den einzigen Port der Bridge nicht einfach
deaktivieren, denn dieser stellt ja den einzigen Pfad zur Root-Bridge
dar.

Warum er hier dennoch aktiv wurde, kᅵnnte interessant zu ergrᅵnden sein.

Sᅵ

0 new messages