- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,300
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Ich hoffe mal, das ist jetzt nicht OT, aber hier ist meine Chance auf eine Antwort sicherlich am größten.
Ich hätte mal eine Frage bzgl. des ctlmgr, der ja für vieles - meines Wissens auch für das Durchsetzen von Zugriffsbeschränkungen auf den Webserver - zuständig ist.
Der ctlmgr ist im Normalfall an den Port 80 auf allen Interfaces gebunden.
Wenn jetzt auf einem nicht-lokalen Interface eine private "Class A"-IP aus 10.0.0.0/8 verwendet wird, ordnet der ctlmgr diesen Zugriff dann als lokal oder als "internet" ein ?
Vielleicht hat ja jemand privat einen ausrangierten DSLAM und das schon einmal mit einer DSL-Box im Gartenhaus über eine Zweidrahtleitung
getestet.
Einen Test mit einer meiner 7390 im IP-Client-Mode - meine einzige Idee und Möglichkeit - halte ich nicht für aussagekräftig, da der ctlmgr dann ja auch weiß, daß die Box in diesem Modus läuft und ggf. die Zuordnung dann doch wieder genauer prüft.
Auslöser meiner Frage ist unter anderem der folgende Abschnitt in der Konfiguration meiner FB6360:
Ich habe einen solchen Abschnitt bisher in keinem anderen mir zugänglichen Modell (7050, 7170, 7270v1, 7390) gefunden, auch nicht bei einer Internet-Recherche. Oder ich habe doch falsch gesucht oder nicht weit genug geblättert, "ar7.cfg" bringt halt sehr viele Treffer und auch "subfolder" ist eben nicht sehr spezifisch.
Wenn man jetzt einmal die Namen der Einstellungen wörtlich nimmt, ist dieser Ordner (subfolder) nur aus dem lokalen Netz (allow_from_internet = no) ohne Authentifizierung (lan_authentication = no) zugänglich. Ich mutmaße einmal, daß auch ein leeres Kennwort in "passwd =" zu einem schönen langen Eintrag führt und somit dieser Eintrag irreführend sein kann.
Ein Aufruf von "fritz.box/info" führt jedenfalls (ob mit oder ohne gültige sid) bei mir immer auf die "url not found"-Seite, was bei einem "subfolder" ja auch zu erwarten ist. Eine FB7390 (05.52) lehnt "subfolder" ab, wenn ich mich beim Editieren der ar7.cfg nicht vertan habe; andererseits enthält auch der ctlmgr einer 7390 das Symbol "AR7CFG_subfolder_alloc" und es sollte eigentlich funktionieren.
Jetzt muß man noch wissen, daß meine FB6360 seitens des Providers auf der wan0-Schnittstelle (DOCSIS-Interface) mit einer Adresse aus 10.46.128.0/20 zusätzlich zur über DHCP bezogenen öffentlichen IP (eigentlich sogar 2, VoIP geht extra) konfiguriert wird und das ist offensichtlich auch nicht nur ein Transitnetz.
Da stellt sich mir angesichts der Möglichkeit, daß unter "info" ja auch so ziemlich jede Seite aus dem "normalen" UI (notfalls mit Generierung einer gültigen sid auf einer zusätzlichen Einstiegsseite, falls eine der anderen Lua-Seiten die sid prüfen will) verlinkt sein könnte, schon die Frage, wie weit die Zugriffsmöglichkeiten über das "DOCSIS management"-Interface wirklich gehen.
Dafür wäre es entscheidend, die o.a. Frage zu klären, da natürlich ansonsten in der Konfiguration auch die üblichen Forward-Rules
vorhanden sind, die eigentlich eine Beschränkung der offenen Ports auf "dsliface:name=internet" auf ftp und https (unter konfigurierbarem Port) annehmen lassen.
Wenn ich mir dann aber wieder die Routing-Tabelle der Box (in den DOCSIS-Diagnosedaten)
und die Anzeige der Interfaces (ifconfig -a)
ansehe, komme ich für mich zu der Einschätzung, daß es sich um 2 unterschiedliche Interfaces handelt (auch wenn das "logische" dsl wohl auf das "physische" wan0 bridged => wan_bridge_with_dhcpc = yes) und daß da die Forward-Rules aus der ar7.cfg für wan0 wohl nicht per se gelten.
Dafür spräche auch die Ausgabe von zusätzlichen Zeilen wie diesen
im Rahmen der Diagnose-Informationen des DOCSIS-Interfaces.
Und ja, ich sehe auch, daß da erst einmal offensichtlich keine HTTP(S)-Regel zu erkennen ist ... ich habe aber überhaupt keine gesicherte Erkenntnis, wie diese Daten für das DOCSIS-Interface gesetzt werden und ob nicht doch eine dynamische Änderung möglich ist. Genauer: Die o.a. Angaben könnten sowohl eine statisch konfigurierte Startkonfiguration als auch die Anzeige zur Laufzeit sein, das geht auch aus dem Kontext für mich nicht hervor.
Die konkrete 10.x-Adresse meiner Box und ihrer Vorgängerin (die hatte auch wirklich eine andere Adresse) hat sich - jedenfalls seitdem ich sie immer wieder mal abfrage - nicht geändert. Aber das wäre auch bei einer DHCP-Lease auf wan0 wohl nicht anders, solange die Box nicht über ein mehrfaches der (unbekannten) Lease-Time offline ist.
Bei UM-Boxen scheinen diese Zugriffsregeln auch nicht zu existieren, daher würde ich ein festes Verdrahten in den DOCSIS-Komponenten eher ausschließen, vorausgesetzt der DOCSIS-Teil (Hard- und Software) ist für alle OEMs gleich.
Spaßigerweise findet sich in der netstat-Ausgabe kein Prozess, der an den UDP-Ports (Proto 17) mit den Nummern 2427 oder 2428 lauscht, dafür ist ein Prozess mit dem Namen "snmp_agent_cm" dann auch gleich noch an den SNMP-Trap-Port (162) auf wan0 gebunden, für den wiederum keine der o.a. Regeln zuträfe. Irgendwie ist das alles schon echt verwunderlich ...
So, noch einmal kürzer zusammengefaßt:
Wenn der ctlmgr Zugriffe über wan0 von einer 10.x-Adresse als "lokal" ansieht, kann meines Erachtens der Provider auf einer FB6360 so ziemlich alles tun, was er möchte. Und zwar (das ist nur eine Vermutung, da ctlmgr meines Wissen "closed source" ist) ohne irgendeine Rücksichtnahme auf die Zugriffsbeschränkungen durch den Kunden. Daher meine eingangs gestellte Frage ...
Sorry für die Überlänge des Postings und danke an alle, die bis hier gelesen haben.
Ich hätte mal eine Frage bzgl. des ctlmgr, der ja für vieles - meines Wissens auch für das Durchsetzen von Zugriffsbeschränkungen auf den Webserver - zuständig ist.
Der ctlmgr ist im Normalfall an den Port 80 auf allen Interfaces gebunden.
Wenn jetzt auf einem nicht-lokalen Interface eine private "Class A"-IP aus 10.0.0.0/8 verwendet wird, ordnet der ctlmgr diesen Zugriff dann als lokal oder als "internet" ein ?
Vielleicht hat ja jemand privat einen ausrangierten DSLAM und das schon einmal mit einer DSL-Box im Gartenhaus über eine Zweidrahtleitung
getestet. Einen Test mit einer meiner 7390 im IP-Client-Mode - meine einzige Idee und Möglichkeit - halte ich nicht für aussagekräftig, da der ctlmgr dann ja auch weiß, daß die Box in diesem Modus läuft und ggf. die Zuordnung dann doch wieder genauer prüft.
Auslöser meiner Frage ist unter anderem der folgende Abschnitt in der Konfiguration meiner FB6360:
Code:
websrv {
port = "80";
https_port = "XXX";
read_timeout = 15m;
request_timeout = 30s;
keepalive_timeout = 5m;
nokeepalive = "*";
errordir = "/usr/www/html/errors";
webdir = "/usr/www";
cgidir = "cgi-bin";
indexfn = "index.var", "index.htm", "index.html";
users_only_for_https = yes;
cors_allow_origins = "*.avm.de";
cors_allow_headers = "SOAPACTION", "Content-Type", "Origin";
cors_allow_methods = "GET", "POST", "OPTIONS";
cors_max_age = 1d;
[B] subfolder {
name = "info";
passwd = "$$$$ZVS1QPHIBDTEJQXUZGCJLKF2F6QOW2K1GAKC6TLK1VOVNSY2CFPKZGORBWYAO5YEMTWARE22N5135MZS"; (absichtlich nicht maskiert !)
allow_from_internet = no;
lan_authentication = no;
}
[/B]}Wenn man jetzt einmal die Namen der Einstellungen wörtlich nimmt, ist dieser Ordner (subfolder) nur aus dem lokalen Netz (allow_from_internet = no) ohne Authentifizierung (lan_authentication = no) zugänglich. Ich mutmaße einmal, daß auch ein leeres Kennwort in "passwd =" zu einem schönen langen Eintrag führt und somit dieser Eintrag irreführend sein kann.
Ein Aufruf von "fritz.box/info" führt jedenfalls (ob mit oder ohne gültige sid) bei mir immer auf die "url not found"-Seite, was bei einem "subfolder" ja auch zu erwarten ist. Eine FB7390 (05.52) lehnt "subfolder" ab, wenn ich mich beim Editieren der ar7.cfg nicht vertan habe; andererseits enthält auch der ctlmgr einer 7390 das Symbol "AR7CFG_subfolder_alloc" und es sollte eigentlich funktionieren.
Jetzt muß man noch wissen, daß meine FB6360 seitens des Providers auf der wan0-Schnittstelle (DOCSIS-Interface) mit einer Adresse aus 10.46.128.0/20 zusätzlich zur über DHCP bezogenen öffentlichen IP (eigentlich sogar 2, VoIP geht extra) konfiguriert wird und das ist offensichtlich auch nicht nur ein Transitnetz.
Da stellt sich mir angesichts der Möglichkeit, daß unter "info" ja auch so ziemlich jede Seite aus dem "normalen" UI (notfalls mit Generierung einer gültigen sid auf einer zusätzlichen Einstiegsseite, falls eine der anderen Lua-Seiten die sid prüfen will) verlinkt sein könnte, schon die Frage, wie weit die Zugriffsmöglichkeiten über das "DOCSIS management"-Interface wirklich gehen.
Dafür wäre es entscheidend, die o.a. Frage zu klären, da natürlich ansonsten in der Konfiguration auch die üblichen Forward-Rules
Code:
forwardrules = "tcp 0.0.0.0:21 0.0.0.0:21 0",
"tcp 0.0.0.0:4xx 0.0.0.0:4xx 0";Wenn ich mir dann aber wieder die Routing-Tabelle der Box (in den DOCSIS-Diagnosedaten)
Code:
IPv4 Default routing table
--------------
169.254.180.1 dev dsl metric 2
169.254.180.2 dev dsl metric 2
85.214.xxx.xxx/30 via 192.168.xxx.2 dev lan
192.168.xxx.0/28 dev lan src 192.168.xxx.1
172.31.179.0/24 dev guest src 172.31.179.1
91.65.72.0/23 dev dsl metric 2
91.65.112.0/21 dev dsl metric 3
169.254.0.0/16 dev lan src 169.254.1.1
192.168.0.0/16 via 192.168.xxx.2 dev lan
default dev dsl metric 2
IPv4 Docsis routing table
--------------
10.46.128.0/20 dev wan0 src 10.46.1xx.xxx
default via 10.46.1xx.xxx dev wan0
Code:
dsl Link encap:Point-to-Point Protocol
inet addr:192.168.XXX.1 P-t-P:192.168.XXX.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:27345 errors:0 dropped:0 overruns:0 frame:0
TX packets:1119 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:2157460 (2.0 MiB) TX bytes:205111 (200.3 KiB)
[...]
wan0 Link encap:Ethernet HWaddr 9C:C7:A6:XX:XX:XX
inet addr:10.46.1XX.XXX Bcast:10.46.1XX.255 Mask:255.255.240.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:47678 errors:0 dropped:155 overruns:0 frame:0
TX packets:196 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3371331 (3.2 MiB) TX bytes:42526 (41.5 KiB)Dafür spräche auch die Ausgabe von zusätzlichen Zeilen wie diesen
Code:
Classifiers:
-----------------------
Clfy 0: EtherType MAC ==> SF 11e6b
Clfy 1: IPv4 SRC 10.0.0.0/255.0.0.0 Proto 17 Ports 2427-2428:0 ==> SF 11e6b
Clfy 2: IPv4 SRC 10.0.0.0/255.0.0.0 Proto 17 Ports 0:53 ==> SF 11e6b
Clfy 3: IPv4 SRC 10.0.0.0/255.0.0.0 Proto 17 Ports 161:0 ==> SF 11e6b
Clfy 4: IPv4 DST 83.169.182.0/255.255.255.128 Proto 17 Ports 5060:5060 ==> SF 11e6b
Clfy 5: IPv4 SRC 10.0.0.0/255.0.0.0 DST 10.0.0.0/255.0.0.0 Proto 17 TosLow 0x50 TosHigh 0x50 Mask 0xff ==> SF 11e6b
Clfy 6: EtherType MAC ==> SF 11e6b
Clfy 7: IPv4 DST 10.0.0.0/255.0.0.0 Proto 17 Ports 0:2427-2428 ==> SF 11e6c
Clfy 8: IPv4 DST 10.0.0.0/255.0.0.0 Proto 17 Ports 53:0 ==> SF 11e6c
Clfy 9: IPv4 DST 10.0.0.0/255.0.0.0 Proto 17 Ports 0:161 ==> SF 11e6c
Clfy 10: IPv4 SRC 83.169.182.0/255.255.255.128 Proto 17 Ports 5060:5060 ==> SF 11e6cUnd ja, ich sehe auch, daß da erst einmal offensichtlich keine HTTP(S)-Regel zu erkennen ist ... ich habe aber überhaupt keine gesicherte Erkenntnis, wie diese Daten für das DOCSIS-Interface gesetzt werden und ob nicht doch eine dynamische Änderung möglich ist. Genauer: Die o.a. Angaben könnten sowohl eine statisch konfigurierte Startkonfiguration als auch die Anzeige zur Laufzeit sein, das geht auch aus dem Kontext für mich nicht hervor.
Die konkrete 10.x-Adresse meiner Box und ihrer Vorgängerin (die hatte auch wirklich eine andere Adresse) hat sich - jedenfalls seitdem ich sie immer wieder mal abfrage - nicht geändert. Aber das wäre auch bei einer DHCP-Lease auf wan0 wohl nicht anders, solange die Box nicht über ein mehrfaches der (unbekannten) Lease-Time offline ist.
Bei UM-Boxen scheinen diese Zugriffsregeln auch nicht zu existieren, daher würde ich ein festes Verdrahten in den DOCSIS-Komponenten eher ausschließen, vorausgesetzt der DOCSIS-Teil (Hard- und Software) ist für alle OEMs gleich.
Spaßigerweise findet sich in der netstat-Ausgabe kein Prozess, der an den UDP-Ports (Proto 17) mit den Nummern 2427 oder 2428 lauscht, dafür ist ein Prozess mit dem Namen "snmp_agent_cm" dann auch gleich noch an den SNMP-Trap-Port (162) auf wan0 gebunden, für den wiederum keine der o.a. Regeln zuträfe. Irgendwie ist das alles schon echt verwunderlich ...
So, noch einmal kürzer zusammengefaßt:
Wenn der ctlmgr Zugriffe über wan0 von einer 10.x-Adresse als "lokal" ansieht, kann meines Erachtens der Provider auf einer FB6360 so ziemlich alles tun, was er möchte. Und zwar (das ist nur eine Vermutung, da ctlmgr meines Wissen "closed source" ist) ohne irgendeine Rücksichtnahme auf die Zugriffsbeschränkungen durch den Kunden. Daher meine eingangs gestellte Frage ...
Sorry für die Überlänge des Postings und danke an alle, die bis hier gelesen haben.
Zuletzt bearbeitet:
