[Frage] AVM-Firewall im aktuellen Trunk

Versuche es mal mit der 127.0.0.1 (0.0.0.0 ist so recht keine gültige IP-Adresse).

G., -#####o:
 
Was genau soll da nicht gehen? Hinzufügen des Eintrags oder die Funktionalität? Bei mir geht beides ohne Probleme.
 
Ist es bekannt das man im aktuellen Trunk kein Portforwarding auf die eigene Box mehr machen kann ?
Jein. Es ist für dein Beispiel bekannt (also Port 21). Dafür hat AVM jetzt eine eigene GUI-Einstellung (Internet → Freigaben → FRITZBox-Dienste → "Internetzugriff auf Ihre Speichermedien über FTP/FTPS aktiviert").
Und ich bin mir nicht sicher, ob es den Aufwand einer "Sonderbehandlung" wert ist. Vielleicht mit einem Hinweis in der Seite.

@scolopender: 0.0.0.0 als "Ziel-IP" nutzt AVM in ihrer internen Firewall als "die Box selbst".
 
Danke Euch !

Werde die Tips mal an meinen Kumpel zum testen geben.
 
@scolopender: AVM-Firewall ist nichts "übliches". 127.0.0.1 funktioniert bei AVM nachweislich genau so wenig, wie 192.168.178.1 oder ähnliches.
@MaxMuster: Das solche Kleinigkeit in so einem Mega-Ticket runter geht, ist nichts besonderes. Ich habe schon deine Meinung dazu verstanden, dass du nicht mit dem Vorschlag von cuma aus dem Ticket "mitgehst". Dann sollte man sich eine Alternative überlegen und lieber die Stelle patchen, wo AVM dies zurücksetzt. Oder noch besser, einen "Synchronisator" zwischen der Firewall und dieser dubiösen Extra-Einstellung von AVM einbauen. Dass die Einstellung auch gesetzt wird, sobald man die Firewall-Regel ändert.

MfG
 
Das Problem ist, dass die "AVM-Firewall" eigentlich nichts weiter ist, als ein Filtern und Ändern der Einträge in der ar7.cfg.

Zum einen müsste man einen "sicheren" Mechanismus haben, die "betroffenen" Versionen zu finden, und dann dafür eine "komplette Sonderbehandlung" schreiben.
Aber ich schaue es mir nochmal an, das "Eintragen" selbst ist hierfür nämlich gegenüber des "Rumfuddelns mit der ar7.cfg" trivial (und genau auf die Art, wie ich die AVM-Firewall gerne hätte):

Einschalten der Port 21 Freigabe mittels:
Code:
ctlmgr_ctl w ctlusb settings/storage-ftp-internet 1
(ist ja wohl eindeutig zum Beeinflussen des Wertes "ftp_internet_enabled = yes" ;-) )
 
Wenn wir schon beim Thema sind... Gibt es die Möglichkeit, die Firewallregeln über ctlmgr_ctl zu verändern? Es wäre viel eleganter, als an der ar7.cfg direkt zu "operieren". Vermutlich hätte man komplett auch auf Reboots und sonstige Nebeneffekte verzichten können. Hast du da schon irgendwas rausfinden können?
Dadurch, dass AVM jetzt viel LUA einsetzt und allgemein diese ctlmgr-Schnittstelle nutzt, kann man da viel leichter und viel mehr in deren geschlossene Küche "reinschauen". Zu einem verrät "Quelltext anzeigen" von manchen AVM-Webseiten mit passenden Masken sehr viel. Dann auch noch begleitend in die LUA-Dateien reinschauen. Zum anderen kann man mit strace auch Einiges ermitteln. Zum dritten hilft das "durchforsten" von ctlmgr und Co. nach Zeichenketten. Da kann man nämlich die eine oder die andere fehlene Commando-Bezeichnung herausfinden. Wie z.B. deine "storage-ftp-internet". Das schöne daran, dass sie meistens nebeneinander stehen. Wenn du 2-3 Commandos kennst, dann findest du leichter dir fehlende Bezeichnungen.

MfG
 
Wirklich viel bin ich da nicht weitergekommen. Auf einer 7170 (Speedport w701) geht z.B. noch
Code:
root@Speedport:/var/mod/root# for x in activated description protocol port \
> fwip fwport endport; do ctlmgr_ctl r forwardrules settings/rule0/$x; done
1
HTTP-Server
UDP
80
192.168.178.43
80
80
root@Speedport:/var/mod/root# 
root@Speedport:/var/mod/root# ctlmgr_ctl w forwardrules settings/rule0/fwip 192.168.178.111
root@Speedport:/var/mod/root# for x in activated description protocol port \
> fwip fwport endport; do ctlmgr_ctl r forwardrules settings/rule0/$x; done
1
HTTP-Server
UDP
80
192.168.178.111
80
80
root@Speedport:/var/mod/root#
Auf einer 7390 kommt da "nix". Habe es auch nicht geschafft, Regeln anzulegen...
 
ctlmgr_ctl ist eine Krücke. Da hatte ich auch viele Probleme mit. Daher hatte ich oben LUA und Co. angesprochen. Manche Sachen kannst du nur dann erfolgreich bearbeiten, wenn du eine komplette Sektion über ctlmgr anlegst/veränderst. Dies kann ctlmgr_ctl nicht, weil er immer nur einen Wert verändern kann, keine Sektionen. Über LUA und direkt über ctlmgr gibt es eine andere Möglichkeit, die AVM auch intern nutzt.
Ferner hatte ich öfters beobachtet, dass es darauf kommt, in welcher Reihenfolge man welche Werte verändert. Was sich noch von 7170 Richtung 7390 geändert haben könnte, ist die "Autorisierung". Denn theoretisch können die AVM im ctlmgr sehen, von "wem" die Anfrage nach Veränderung kommt. ctlmgr_ctl sendet da seinen Namen (geschieht per Socket und Dateinamen). Man kann zumindest theoretisch dem ctlmgr_ctl diese Veränderung ja auch verweigern, was AVM womöglich tut.
Viel schwieriger ist es einen komplett neuen Wert anzulegen. Sprich z.B. rule1 neu eröffnen und nicht nur IP in dem rule0 ändern. Dafür gibt es seitens AVM oft entweder einen Extra-Befehl, den zu erraten gilt, oder eben diese sehr komplizierte und von AVM eindeutig definierte Reihenfolge. Z.B. in diesem Beispiel würde man zuerst die IP für rule1 anlegen müssen, damit die rule1 überhaupt als solche angelegt wird. Startest du dagegen rule1 mit dem Namen, so wird nichts angelegt (bitte meine Behauptung nur als Beispiel deuten!). Ich hatte solche Effekte beim Anlegen weiterer Accounts (z.B. für die 2.PVC) unter dyndns-Konfiguration. Dazu gab es hier schon Diskussionen...
Also, ideal wäre, wenn wir uns ein Werkzeug verschaffen würden, mit dem ctlmgr auf der Augenhöhe zu reden und nicht über diese stumme Krücke ctlmgr_ctl. Ich hatte dazu hier schon mal ein Thema eröffnet. Leider waren wir an der Stelle nicht besonders weit gekommen. Der Einsatz war, den LUA-Interpreter von AVM für unsere Zwecke zu ertüchtigen. Gescheitert sind unsere Versuche an der Anbindung von passenden Libs (closed source, natürlich), in denen das Interface zu ctlmgr versteckt ist.

MfG
 
Das mit der Reihenfolge war der entscheidende Hinweis, ich konnte so auf allen Boxen im Kurztest eine Regel anlegen:

Code:
NEWRULE=$(ctlmgr_ctl r forwardrules settings/rule/count)
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/fwip 10.10.10.$(( 10 + ${NEWRULE} ))
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/description testeintrag_${NEWRULE}
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/fwport $(( 100 + ${NEWRULE} ))
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/endport $(( 100 + ${NEWRULE} ))
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/port $(( 100 + ${NEWRULE} ))
ctlmgr_ctl w forwardrules settings/rule${NEWRULE}/protocol TCP
Mit (de-)aktivieren kann man die Dinger auch "anpassen".
Nur, ob man auch eine Regel wohl auch Löschen kann ?!? Ja!!
Code:
ctlmgr_ctl w forwardrules settings/rule2/fwip 0
Also ein Super-Hinweis/Ansatz.
Da schau ich mal nach, das umzusetzten, kann dauern bis ich dazu komme, aber der Ansatz ist da!
 
Gut, dass wir darüber gesprochen haben...
Kannst du damit auch 0.0.0.0 bedienen? Werden die Regel dann auch [irgendwann] in ar7.cfg abgespeichert? Beobachte dies alles bitte im Dauertest, bevor du hier die Erfolgsmeldungen verbreitest. Leider kann man diesem ctlmgr_ctl nie trauen. Obwohl, wenn schon eine Regel drin ist, dann überlebt sie vieles. Bei mir laufen mindestens 2-3 Boxen mit so gesetzten 2.PVC für dyndns. Und schon seit mehreren Monaten und einigen Firmware-Updates. Also, selbst wenn "undokumentiert" und irgendwie quer reingeschossen scheint es manchmal doch zu gehen. Im Unterschied zu anderen Dingen wie /etc/passwd und Co. scheint AVM mit ihren eigenen Configs deutlich vorsichtiger umzugehen. Es wird nichts "überschrieben", wenn es schon mal drin ist. Auch nicht selbst angelegte Daten werden in diesem Fall von AVM respektvoll behandelt.

MfG
 
Wie geschrieben, war das nur ein "Kurztest", und dabei lauten die Antworten auf deine Fragen: Jein ;-)
- Die Einträge landen in der ar7.cfg (allerdings landen auch "Zwischenschritte" drin)
- Für Einträge auf 0.0.0.0 gilt ähnliches wie für die GUI: Anlegen geht und sie bleiben erstmal als "ruleX" sicht- und zugreifbar, sie verschwinden aber beim Reboot aus den "rules"...

Es gab also wohl doch einen Grund, warum ich das damals so gemacht hatte...
 
Aber in ar7.cfg bleiben die 0.0.0.0-Regeln doch trotzdem bestehen, selbst wenn man sie mit ctlmgr_ctl zuvor angelegt hat? Sprich, es bleibt lediglich die Stelle zu finden, wo AVM beim Hochfahren entscheidet, wie man die Datenbank anhand der ar7.cfg befüllt. Vielleich gelingt es uns, diese Stelle zu finden und herauszupatchen? Bestimmt checken sie gegen 0.0.0.0 und lässen dies nicht zu. Wenn man die Vergleichsbedingung z.B. gegen 0.0.0.1 ersetzt, schlägt der Vergleich fehl und 0.0.0.0 wird zugelassen. Es reicht bestimmt nur an einer Stelle im ctlmgr ein Byte zu patchen. Es wird allerdings nicht einfach sein, strace beim Hochlauf laufen zu lassen...

MfG
 
Hallo ihr guten...

Möchte da mal einhaken...
Ich zum beispiel habe in meiner ar7.cfg GARKEINE meiner Freigaben mehr stehen, die aber im AVM Webinterface unter Freigaben angezeigt werden.
Daher zeigt mir das Freetz avm-firwall paket auch nüscht an.
Und ich kann nix anlegen...
Gibt es da schon überlegungen...bzw. wo liegen die denn jetzt überhaupt?
Grüße!!

Ach und das mit dem kurztest über das ctl dingens klingt aber klasse...
Werd mal auch bei mir nen bissel testen...das wäre ja super wenn die box nicht immer abschmieren müsste für nen neue Portfreigabe!!
 
Also bei einer 7270 mit 05.50 sind (bis auf die FTP-Geschichte) die Einträge noch vorhanden.
 
Hmm...bei mir lassen sich nicht mal einfachste Freigaben auf 0.0.0.0 setzen...
Und die Debug ausgabe iss immer leer...
Idee?
 
Keine der Freigaben der AVM-GUI taucht auf?
Machst du bitte mal ein
Code:
 sed -n '/dslifaces/,/} {/p' /var/flash/ar7.cfg
 
Zuletzt bearbeitet:
Servus Max!

Also wenn ich eine freigabe mache und dann mit haken unten bestätige, taucht sie nicht auf und in der ar7.cfg iss sie auch nicht drin.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,159
Beiträge
2,247,074
Mitglieder
373,678
Neuestes Mitglied
brainkennedy
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.