iptables icm. brctl

[JackBol]

Ik ben bezig met een beetje dirty-network gestuntel en ik kom er niet helemaal uit.

Ik wil het volgende:

Een machine met 2 ethernet poorten, acterend als een bridge (niet zo moeilijk)

code:

# ifconfig eth0 up promisc
# ifconfig eth1 up promisc
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# ifconfig br0 up

Klaar. Werkt.

Nu wil ik het volgende. Van alle UDP pakketten die over de bridge heen komen, wil ik de TTL zetten op 30. Ook niet zo moeilijk.

code:

# iptables -t mangle -A OUTPUT -j TTL --ttl-set 30
# iptables -t mangle --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
TTL        all  --  anywhere             anywhere            TTL set to 30

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
#

Het enige probleem dat ik heb, is dat het niet werkt. De bridged pakketten gaan niet door de iptables heen.

Ik heb gekeken of net.bridge.bridge-nf-call-iptables op "1" staat en IP forwarding staat ook aan.
Verkeer gaat gewoon over de bridge heen, maar de TTL word niet geset.

Hoe kan ik deze pakketten door de iptables heen forceren zonder dat ik hoeft te routen?

[0xDEADBEEF]

ebtables (: ?

Getting a bridging firewall on a 2.4.x kernel consists of patching the kernel source code. The 2.6 kernel contains the ebtables and br-nf code, so it doesn't have to be patched.

Handig, met examples.

[benoni]

Ik heb 't nog niet zo geprobeerd hoor, maar je kunt de TTL van de bridge zelf ook opgeven:

code:

brctl setmaxage <bridgename> <time>

Ik vraag me af of dit de TTL inderdaad aan elk doorgestuurd pakketje meegeeft...

[JackBol]

benoni schreef op donderdag 22 maart 2007 @ 16:22:
Ik heb 't nog niet zo geprobeerd hoor, maar je kunt de TTL van de bridge zelf ook opgeven:

code:

brctl setmaxage <bridgename> <time>

Ik vraag me af of dit de TTL inderdaad aan elk doorgestuurd pakketje meegeeft...

Helaas is dat niet de TTL van passerende pakketten, maar zet je daarmee de aging-timer van BPDU's.

[Confusion]

_DH schreef op donderdag 22 maart 2007 @ 15:53:
Het enige probleem dat ik heb, is dat het niet werkt. De bridged pakketten gaan niet door de iptables heen.

Dat betwijfel ik; je moet moeite doen om packets niet 'door iptables' te laten gaan. Ik denk eerder dat je regels niet kloppen of je de noodzakelijke componenten mist. Is je kernel wel geconfigureerd met de noodzakelijk modules om bijvoorbeeld TTL te kunnen manglen?

[ Voor 8% gewijzigd door Confusion op 22-03-2007 17:48 ]

[JackBol]

Confusion schreef op donderdag 22 maart 2007 @ 17:47:
[...]

Dat betwijfel ik; je moet moeite doen om packets niet 'door iptables' te laten gaan. Ik denk eerder dat je regels niet kloppen of je de noodzakelijke componenten mist. Is je kernel wel geconfigureerd met de noodzakelijk modules om bijvoorbeeld TTL te kunnen manglen?

Als ik route, werkt het zondermeer. Als ik bridge, raken de frames de ip laag niet, en gaat ze dus ook niet door iptables.

[Confusion]

_DH schreef op donderdag 22 maart 2007 @ 18:02:
Als ik route, werkt het zondermeer. Als ik bridge, raken de frames de ip laag niet, en gaat ze dus ook niet door iptables.

Dan geef je toch zelf het antwoord al? Als je de packets zover krijgt om door iptables rules beinvloed te worden, dan ben je aan het routen. Wil je dat persé vermijden?

[JackBol]

Confusion schreef op donderdag 22 maart 2007 @ 18:07:
[...]

Dan geef je toch zelf het antwoord al? Als je de packets zover krijgt om door iptables rules beinvloed te worden, dan ben je aan het routen. Wil je dat persé vermijden?

Ja en nee. Ik wil de TTL value aanpassen maar zonder te hoeven routen. Routing is per definitie geen optie.

Als je een andere manier kan bedenken om de TTL aan te passen zonder iptables sta ik er ook voor open.

[ Voor 20% gewijzigd door JackBol op 22-03-2007 23:15 ]

[Parasietje]

IIRC heb je onder linux twee manieren om te bridgen. Je kan een pure bridge maken, maar je kan ook een bepaalde truc met iptables gebruiken. Die techniek noemt "transparent bridge". Ie: de router is niet zichtbaar, maar toch wordt bepaalde traffic in de bridge geblokkeerd.

Je hebt dus meteen je google-zoekterm. Ik zou eerst proberen om bepaalde pakketten te blokkeren, en daarna pas met ingewikkelder dingen als TTL te spelen.

[Confusion]

_DH schreef op donderdag 22 maart 2007 @ 23:14:
Ja en nee. Ik wil de TTL value aanpassen maar zonder te hoeven routen. Routing is per definitie geen optie.

TTL is een eigenschap van IP paketten, dus zal je per definitie de IP laag moeten raken. Als je daar toch zit, dan kan je toch net zo goed routen?

[JackBol]

Confusion schreef op vrijdag 23 maart 2007 @ 10:01:
[...]

TTL is een eigenschap van IP paketten, dus zal je per definitie de IP laag moeten raken. Als je daar toch zit, dan kan je toch net zo goed routen?

Daarom gaf ik ook aan dat het dirty is. Ik disregard het OSI-model compleet, maar dat is nu niet van belang.

Het is een hack voor in een testomgeving. Als routing een optie was, had ik dat al lang gedaan. (Hell, als het makkelijk was, hoefde ik het hier niet eens te vragen )

[benoni]

_DH schreef op vrijdag 23 maart 2007 @ 12:13:
Als routing een optie was, had ik dat al lang gedaan.

Maar met een transparante bridge is de 'hop' die de pakketen maken toch niet zichtbaar? Kunnen we aannemen dat dat is wat je wilt, de TTL kunnen aanpassen zonder de topologie van het netwerk verder te beïnvloeden?

[JackBol]

benoni schreef op vrijdag 23 maart 2007 @ 12:24:
[...]


Maar met een transparante bridge is de 'hop' die de pakketen maken toch niet zichtbaar? Kunnen we aannemen dat dat is wat je wilt, de TTL kunnen aanpassen zonder de topologie van het netwerk verder te beïnvloeden?

Ik ga die transparante bridge ook nog even proberen, inderdaad. Maar ik heb niet de tijd om 24/7 aan deze tests te werken...

[CyBeR]

Zet die rules eens op je FORWARD chain. OUTPUT geldt alleen voor verkeer gegenereerd door je host zelf.