Cpmaccfg funktioniert nicht wie in der Wiki beschrieben

[derheimi]

Bei diesem Regeln werden ja keine Zustandinformationen über die aktiven Verbindungen benötigt, da alle Informationen über die Filterung in den IP-Paketen vorliegt (hier konkret jeweils nur die Zielports bzw. ob TCP/UDP). Ich würde daher behaupten, dass ip_conntrack nicht verwendet wird, ein wirklich knapper Test auf meiner Debian-Box sagt mir, dass nur iptable_filter.ko und ip_tables.ko als Kernel-Module benötigt werden und auch nur geladen sein sollten. An Userspace-Module brauchst Du vermutlich: libipt_tcp.so, libipt_udp.so (wobei ich die gerade nicht im dsmod-menuconfig finde?!?). Was man jetzt konkret für --dport braucht, ist mir intuitiv gerade noch nicht klar...

 

[sweetie-pie]

7170: Netze trennen mit cpmacfg und absichern mit iptables

Danke, sieht ganz gut aus. Was ich bisher getan habe:

Die von derheimi genannten Dateien aus dem ds26-15.2 nach /var/media/ftp/uStor01/iptables kopiert.

Pfad zu den libs gesetzt:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/var/media/ftp/uStor01/iptables

Module geladen:

 $ insmod ./iptable_filter.ko
 $ insmod ./ip_tables.ko

Rules aus dem vorherigen Post eingetragen plus der Regel für den DHCP-Server:

./iptables -I INPUT -i eth1 -p udp --dport 67 -j ACCEPT

Die Regeln mit ./iptables -L -v geprüft:

Chain INPUT (policy ACCEPT 16991 packets, 1893K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  eth1   any     anywhere             anywhere            udp dpt:67
    0     0 ACCEPT     udp  --  eth1   any     anywhere             anywhere            udp dpt:1194
   50  6100 ACCEPT     tcp  --  eth1   any     anywhere             anywhere            tcp dpt:22
  656 44278 ACCEPT     udp  --  eth1   any     anywhere             anywhere            udp dpt:53
    0     0 ACCEPT     tcp  --  eth1   any     anywhere             anywhere            tcp dpt:53
   46  2640 DROP       tcp  --  eth1   any     anywhere             anywhere
  256 59209 DROP       udp  --  eth1   any     anywhere             anywhere

Chain FORWARD (policy ACCEPT 12015 packets, 3288K bytes)
 pkts bytes target     prot opt in     out     source               destination
 6562  798K ACCEPT     0    --  eth1   dsl     anywhere             anywhere
   71  4578 DROP       0    --  eth1   any     anywhere             anywhere

Das Ergebnis ist so wie ich es erwartet habe:

                WAN
                 |
        +-----------------+
        | Fritz!Box       |
        | openVPN         |
        | LAN A     LAN B |
        | eth0      eth1  |
        +-----------------+
         |               | 
192.168.2.*              192.168.0.*
 +--------+            +-------------+
 | switch |            | WLAN (WAP54)|
 +--------+            +-------------+
lokales Netz

Regeln:
192.168.2.*:
Darf ins WAN
192.168.1.*:
Darf ins WAN
Darf nicht direkt ins lokale Netz (192.168.2.*)
Darf über openVPN ins lokale Netz (192.168.2.*)


Dafür erstmal vielen Dank ans Forum...

Jetzt habe ich noch ein kleines Problem:
Im WLAN gibts eine Webcam und zwangsläufig den Access-Point. Beide haben eine Weboberfläche und sollten weiterhin über Ihre private Adresse auch aus LAN A erreichbar sein, bzw. die Antwort der Geräte sollte ins LAN A gelangen dürfen.
Ich habe schon verschiedenes ausprobiert, ist mir aber bisher nicht gelungen. Die Geräte haben eine Feste IP im LAN B die zur Identifikation genutzt werden könnte.
Wie muss die Regel dann lauten?

 

[derheimi]

Kannst ja bei Gelegenheit mal schreiben, ob die Geschichte bei Dir stabil läuft!

Die Regel müsste IMHO lauten:

iptables -I FORWARD -i eth1 -p tcp -s FESTEIPDESGERAETES/32 --sport 80 -j ACCEPT

 

[sweetie-pie]

Kannst ja bei Gelegenheit mal schreiben, ob die Geschichte bei Dir stabil läuft!

Momentan habe ich das Problem, dass die Änderung der Umgebungsvariable LD_LIBRARY_PATH gem. diesem Post verloren geht. Ich kann Momentan noch nicht nachvollziehen, wann das passiert... aber das dürfte kein Problem von iptables sein....

Edit: Ich habe jetzt diesen Vorschlag von knox mal verworfen, weil die Umgebungsvariable immer zurück gesetzt wird.
Statt dessen habe ich jetzt den Ansatz von HanSolo im Test... iptabels scheint in der minimal Konfig aber zu laufen....

Edit 14.01.2008:
Läuft stabil, habe es heute in mein Image eingebaut... allerdings war mir nicht klar welche Userspace-Module ich brauchte, deshalb habe ich mal alle eingebaut, habe ja 8MB Flash... ;-)

 

[kriegaex]

Unix-Grundlagen, vereinfacht dargestellt:

Ein häufiges Mißverständnis bei Umgebungsvariablen ist, daß man sie einmal setzen und exportieren könne in irgendeiner Shell-Sitzung und sie sich dann auf andere Prozesse auswirkten, die in einer anderen Shell-Sitzung oder durch einen Automatismus gestartet würden. Dem ist nicht so, übrigens auch nicht unter Windows. Möchte man also, daß eine Umgebungsvariable beim Aufruf eines bestimmten Programms einen bestimmten Wert innehat, sollte man sie im globalen (/etc/profile) oder benutzerbezogenen (~/.profile) Shell-Profil setzen oder aber explizit in einem Startskript, welches das gewünschte Programm initialisiert.

Möglichkeit 1 ist ohne weiteres (z.B. Paket mini_fo, welches das gesamte Dateisystem virtuell beschreibbar macht) auf der Fritz!Box nicht möglich, weil /etc/profile im read-only gemounteten Flash-Speicher liegt. Man müßte gewünschte Änderungen also vor dem Zusammenbauen der Firmware auf dem Build-System eintragen.

Möglichkeit 2 geht, indem man in debug.cfg die Datei ~/.profile (beim Benutzer root wäre das im DS-Mod das Verzeichnis /mod/root/.profile) erzeugt und mit entsprechenden Inhalten versieht. Das passiert dann nach jedem Neustart. Allerdings wirkt sich so ein Shell-Profil nur in interaktiven Benutzersitzungen aus, nicht unbedingt in Hintergrundprozessen, bei denen vorher kein Shell-Profil automatisch ausgeführt wird.

Daher ist die einzige wirklich sichere Möglichkeit in unserem Kontext Nr. 3, d.h. exportiere einfach die gewünschte Variable im Startskript Deines Programms. Knox' Vorschlag ist also in Ordnung, Du mußt ihn nur richtig anwenden.

P.S.: Wieso gilt der unter Windows gesetzte Pfad für alle nach dem Setzen gestarteten Anwendungen? Weil er ins globale oder benutzerspezifische Profil geschrieben wird. Windows sorgt dann dafür, daß dieses Profil auch jedem gestarteten Prozeß übergeben wird. Ihr seht, das Prinzip ist das Gleiche.

 

[sweetie-pie]

Unix-Grundlagen, vereinfacht dargestellt

:groesste: Tausend Dank, wieder was gelernt... find ich wirklich Klasse wie manche Leute sich hier reinhängen....