.titleBar { margin-bottom: 5px!important; }

[Problem] instabile AVM-Firewall auf 7270

Dieses Thema im Forum "Freetz" wurde erstellt von Christoph_F, 31 Aug. 2011.

  1. Christoph_F

    Christoph_F Neuer User

    Registriert seit:
    5 Dez. 2006
    Beiträge:
    68
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Hallo,

    zur Zeit benutze ich auf einer 7270 Freetz 1.2 (7500) mit der AVM-Version 74.04.88.

    Bei der Konfiguration der AVM-Firewall mit dem entsprechenden Paket bin ich in eine Reboot-Schleife geraten und mußte sie daraufhin wieder abspecken.

    Jetzt frage ich mich, ob ein Update auf die "internationale" 74.04.90 diesbezüglich etwas bringen könnte (und wenn ja, wie das geht, ich habe hier irgendwelche Bemerkungen bezüglich "Branding" gelesen, aus denen ich nicht schlau werde und daß die Einstellungen verlorengehen und weiß auch trotz eifrigen Lesens immer noch nicht, was diese internationale von der deutschen Version eigentlich sonst noch unterscheidet). Die 74.05.05 geht ja, wenn ich das richtig verstanden habe, selbst mit dem Trunk nicht?
     
  2. Silent-Tears

    Silent-Tears IPPF-Promi

    Registriert seit:
    3 Aug. 2007
    Beiträge:
    7,456
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    BI
    Hast du mal im Wiki geschaut, was ein Branding ist? (Man kann es auch "Kundenspzezifische Anpassungen' nennen, die vor allem das Webinterface betreffen). Dazu: Das AVM-Firewallpaket ist nur eine zusätzliche Konfigurationsmöglichkeit für die eingebaute, immer von aVM mitgelieferte Firewall, von daher schliesse ich mal nen Fehler bei der Firewall selber aus.
    Und da auch das Webinterface dafür funktioniert, denke ich mal, dass dort eventuell ein Benutzerfehler vorliegen könnte?
     
  3. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    2
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    Was genau hast du denn eingetragen, dass es zu dem Fehler kam?

    Gruß
    Oliver
     
  4. fant

    fant Mitglied

    Registriert seit:
    6 Mai 2005
    Beiträge:
    622
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Hallo Ihr alle,

    ich hatte mit einer 7390 und einem Trunk-Build ein ähnliches Problem. Meine Box läuft auf 192.168.2.1 und ich wollte allen Rechner außer einem im LAN Zugang zum Internet geben. Dazu habe ich allen Verkehr (IP, from 192.168.2.1, allow) ausgehend von der Box zugelassen, dazu dem einen Rechner Zugriff überall hin (IP, from 192.168.2.X, to any, allow), Zugriff von LAN auf FritzBox (IP, to 192.168.2.1, from 192.168.2.0/255.255.255.0, allow), Zugriff vom LAN auf den einen Rechner (ist mein Server) (IP, to 192.168.2.X, from 192.168.2.1/255.255.255.0, allow) und danach dem LAN den Zugriff genommen (IP, to any, from 192.168.2.0/255.255.255.0, reject). Auf meiner alten 7170 hat das wunderbar so geklappt, auf der 7390 habe es eine Endlos-Reboot-Schleife.

    Hoffe, daß das irgendwie hilfreich ist.

    Hawedieehre.
    Fant
     
  5. MaxMuster

    MaxMuster IPPF-Promi

    Registriert seit:
    1 Feb. 2005
    Beiträge:
    6,919
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Es gab bei der 04.80-er FW das Problem, dass der dsld nur eine begrenzte Anzahl Firewall-Regeln verkraftet (siehe hier und hier). Das sollte aber bei der 04.88 nicht mehr auftreten, soweit ich weiß ?!?


    Jörg
     
  6. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    2
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    @fant
    Da bräuchten wir schon den geänderten Abschnitt aus deiner ar7.cfg oder zumindest ein Screenshot davon...

    Gruß
    Oliver
     
  7. Christoph_F

    Christoph_F Neuer User

    Registriert seit:
    5 Dez. 2006
    Beiträge:
    68
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Oh, da hat sich aber viel getan in dem Thema, ich werde mal ohne jetzt speziell meine ganzen Vorredner zu zitieren auf das eine oder andere eingehen.

    Also ich bin sicher, daß es nicht an den Regeln oder Freetz liegt, sondern an AVM, das Problem ist bekannt und hier irgendwo schon beschrieben worden, jemand hatte es AVM gemeldet und die wollten danach schauen. Ob sie tatsächlich am DSLD was geändert haben, weiß ich nicht. Es tritt anscheinend auf, wenn man zu viele Regeln macht.

    Was ein Branding ist, weiß ich schon, wollte nur genaueres über DIESES wissen, also Unterschied zwischen "avm" und "avme"-Firmware und ob es auch Methoden zum Wechsel gibt, ohne Mtd3/mtd4 zu löschen und damit die Einstellungen und Daten weitgehend zu verlieren und natürlich, ob sich das für mein Problem überhaupt lohnt, die 90 statt der 88 zu testen. Kann ja sein, daß es immer noch derselbe Firewall-Code ist.

    Ich müßte selber nochmal gründlich suchen, wo ich da was genau gelesen habe, aber letztendlich ging es mir nur darum, mehr über die Unterschiede der "deutschen" und "internationalen" Firmware zu erfahren, bevor ich damit herumexperimentiere. Die Relasenotes sind da leider ziemlich unergiebig.

    Die Vorgaben von AVM sind leider nicht so sinnvoll. Mal ein Beispiel: die sperren den Multicast-Bereich 224.0.0.0/8 (außen DENY, innen REJECT), der gesamte Bereich ist aber laut RFC um Größenordnungen größer, nämlich 224.0.0.0/4. Zudem sollte man hier ausnahmsweise DENY nehmen, wovon ich normalerweise nichts halte, aber dann auch innen, nicht nur internetseitig. Grund: Multicast-Pakete sollten von Geräten/Programmen, die sich nicht angesprochen fühlen, ignoriert, nicht mit sinnlosen Meldungen quittiert werden, daß zum Beispiel der Router sie nicht weiterzuleiten gedenkt, für Broadcast gilt das auch. Wenn man es richtig machen will, wird es komplizierter. Der "private" Multicast-Bereich ist in diesem großen /4 "zersplittert" in 242.0.0.0/24, 239.255.0.0/16, 239.192.0.0/15. Diese drei Abschnitte haben wirklich nichts im Internet verloren, die sollten wir also nicht rauslassen und wenn draußen solche Pakete rumschwirren, sind das Irrläufer und nichts für uns. Reserviert sind noch ein paar mehr Adreßbereiche, wenn diese jedoch mal offiziell werden, dann sicher nicht für den Intranet-Privatbereich.

    Wenn man schon so anfängt, sollte man aber auch konsequent sein und die RFC-1918 und Zeroconf-Bereiche berücksichtigen und sich nicht nur nach außen abschotten, sondern auch dafür sorgen, daß solches Zeug nicht aus dem eigenen Netz hinausdiffundiert.

    Die Ports die AVM sperrt, sind auch nicht meine bevorzugte Auswahl (wie kommen die da drauf?) und bei SMB/CIFS sind sie auch schon wieder ungenau; statt 137-139/TCP und 137-138/UDP müßten die beiden Regeln lauten: 137-138/UDP und 139/TCP, sowie zusätzlich 445/TCP. An Stelle der diversen seltsamen Nummern würde ich eher noch LPD, CUPS und 9100/TCP nehmen, damit mir nicht doch mal irgendwer das Papierfach leerdruckt.

    Hm, ich schweife ab, aber jetzt kennt Ihr wenigstens meine Beweggründe, da überhaupt dran rumzufummeln.

    Vielleicht finde ich ja die entsprechenden Threads noch…
     
  8. Christoph_F

    Christoph_F Neuer User

    Registriert seit:
    5 Dez. 2006
    Beiträge:
    68
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    So, gefunden:

    Das beim Freetz-Paket „iptables“ ausgeführte fand ich ganz einleuchtend und habe mich deswegen mit der Freetz-Konfigurationsoberfläche zunächst mal an die AVM-Firewall gewagt.

    Nachdem ich die Dauerreboots behoben hatte (Backup von "mtd5" wohlweislich zuvor mit "dd" gezogen und dann zurückgespielt, offenbar hatte es auch einen Fehler in der Partitionstabelle gegeben, keine Ahnung, woher der kam, jedenfalls wollte "rootfs" nur noch "ro"…), habe ich das hier gefunden:

    Änderung der Firewall-Regeln mit der freetz-GUI bringt Reboot-Schleife.

    Diese Anmerkung am Ende, daß AVM das womöglich in der nächsten Version behebt, ließ mich an die nach der 74.04.88 herausgekommenen 74.04.90 und 74.05.05 denken, letztere geht anscheinend mit Freetz noch überhaupt nicht wegen einer neueren Kernelversion, bei der anderen ist eben das "Branding" das "falsche".

    Diese AT-/CH-Version ist zwar neuer, aber ich habe verschiedentlich Hinweise gesehen, daß ein Zurücksetzen auf Werkseinstellungen nötig sei, wenn man auf diese von der "deutschen" wechselt, keine Ahnung, ob das wirklich exakt so stimmt. Im übrigen geht aus nichts, was ich gefunden habe hervor, ob AVM an dem Firewall-Problem wirklich was gemacht hat. Deren Enthusiasmus schätze ich eher gering ein, weil normale Nutzer da eh nicht drankommen. Daher wollte ich mich zunächst genauer erkundigen, bevor ich herumexperimentiere.
     
  9. MaxMuster

    MaxMuster IPPF-Promi

    Registriert seit:
    1 Feb. 2005
    Beiträge:
    6,919
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    #9 MaxMuster, 1 Sep. 2011
    Zuletzt bearbeitet: 1 Sep. 2011
    Um dir das Suchen zu erleichtern oder abzunehmen hatte ich genau darauf in Beitrag #5 verwiesen ;-)

    Leider enden die Threads ohne eine echte Erfolgs- oder Misserfolgsmeldung für neuere Kernel. Hast du eine serielle Konsole?
    Dann könntest du das selbst mal prüfen, ob die gleiche Fehlermeldung noch kommt. Zur Not könnte ich mir das übers WE nochmal ansehen...

    EDIT Das mit den "vielen Regeln" kann es eigentlich nicht mehr sein.
    Ich habe mal auf einer 7270 V2 (54.04.88freetz-1.2-stable Rev 7565; "last changed 7225") in der Firewall 20 In und 33 Out Regeln eingetragen. Kein Reboot...

    Code:
    
    Connected to 192.168.178.1.
    Escape character is '^]'.
    
    fritz.fonwlan.box login: root
    Password: 
       __  _   __  __ ___ __
      |__ |_) |__ |__  |   /
      |   |\  |__ |__  |  /_
    
       The fun has just begun ...
    
    
    BusyBox v1.18.5 (2011-09-01 19:01:40 CEST) built-in shell (ash)
    Enter 'help' for a list of built-in commands.
    
    root@fritz:/var/mod/root# uptime 
     01:01:13 up 1 min, load average: 2.10, 0.62, 0.21
    root@fritz:/var/mod/root# 
    root@fritz:/var/mod/root# 
    root@fritz:/var/mod/root# sed -n '/forwardrules/,/} {/ p' /var/flash/ar7.cfg | sed -n '/dsldpconfig/,$ p'
                    dsldpconfig {
                            security = dpsec_firewall;
                            filter_teredo = yes;
                            filter_netbios = yes;
                            lowinput {
                                    policy = "permit";
                                    accesslist = 
                                                 "permit tcp any host 192.168.178.1 eq 120", 
                                                 "permit tcp any host 192.168.178.1 eq 119", 
                                                 "permit tcp any host 192.168.178.1 eq 118", 
                                                 "permit tcp any host 192.168.178.1 eq 117", 
                                                 "permit tcp any host 192.168.178.1 eq 116", 
                                                 "permit tcp any host 192.168.178.1 eq 115", 
                                                 "permit tcp any host 192.168.178.1 eq 114", 
                                                 "permit tcp any host 192.168.178.1 eq 113", 
                                                 "permit tcp any host 192.168.178.1 eq 112", 
                                                 "permit tcp any host 192.168.178.1 eq 111", 
                                                 "permit tcp any host 192.168.178.1 eq 110", 
                                                 "permit tcp any host 192.168.178.1 eq 109", 
                                                 "permit tcp any host 192.168.178.1 eq 108", 
                                                 "permit tcp any host 192.168.178.1 eq 107", 
                                                 "permit tcp any host 192.168.178.1 eq 106", 
                                                 "permit tcp any host 192.168.178.1 eq 105", 
                                                 "permit tcp any host 192.168.178.1 eq 104", 
                                                 "permit tcp any host 192.168.178.1 eq 103", 
                                                 "permit tcp any host 192.168.178.1 eq 102", 
                                                 "permit tcp any host 192.168.178.1 eq 101", 
                                                 "permit tcp any host 192.168.178.1 eq 100", 
                                                 "permit tcp any host 192.168.178.1 eq 99", 
                                                 "deny ip any 242.0.0.0 255.0.0.0", /*AVM*/ 
                                                 "deny ip any host 255.255.255.255";/*AVM*/ 
                            }
                            lowoutput {
                                    policy = "permit";
                            }
                            highinput {
                                    policy = "permit";
                            }
                            highoutput {
                                    policy = "permit";
                                    accesslist = 
                                                 "reject ip any 242.0.0.0 255.0.0.0", /*AVM*/ 
                                                 "deny ip any host 255.255.255.255", /*AVM*/ 
                                                 "reject ip any 169.254.0.0 255.255.0.0", /*AVM*/ 
                                                 "permit tcp host 192.168.178.100 any eq 80", 
                                                 "permit tcp host 192.168.178.101 any eq 80", 
                                                 "permit tcp host 192.168.178.102 any eq 80", 
                                                 "permit tcp host 192.168.178.103 any eq 80", 
                                                 "permit tcp host 192.168.178.104 any eq 80", 
                                                 "permit tcp host 192.168.178.105 any eq 80", 
                                                 "permit tcp host 192.168.178.106 any eq 80", 
                                                 "permit tcp host 192.168.178.107 any eq 80", 
                                                 "permit tcp host 192.168.178.108 any eq 80", 
                                                 "permit tcp host 192.168.178.109 any eq 80", 
                                                 "permit tcp host 192.168.178.110 any eq 80", 
                                                 "permit tcp host 192.168.178.111 any eq 80", 
                                                 "permit tcp host 192.168.178.112 any eq 80", 
                                                 "permit tcp host 192.168.178.113 any eq 80", 
                                                 "permit tcp host 192.168.178.114 any eq 80", 
                                                 "permit tcp host 192.168.178.115 any eq 80", 
                                                 "permit tcp host 192.168.178.116 any eq 80", 
                                                 "permit tcp host 192.168.178.117 any eq 80", 
                                                 "permit tcp host 192.168.178.118 any eq 80", 
                                                 "permit tcp host 192.168.178.119 any eq 80", 
                                                 "permit tcp host 192.168.178.120 any eq 80", 
                                                 "permit tcp host 192.168.178.121 any eq 80", 
                                                 "permit tcp host 192.168.178.122 any eq 80", 
                                                 "permit tcp host 192.168.178.123 any eq 80", 
                                                 "permit tcp host 192.168.178.124 any eq 80", 
                                                 "permit tcp host 192.168.178.125 any eq 80", 
                                                 "permit tcp host 192.168.178.126 any eq 80", 
                                                 "permit tcp host 192.168.178.127 any eq 80", 
                                                 "permit tcp host 192.168.178.128 any eq 80", 
                                                 "permit tcp host 192.168.178.129 any eq 80";
                            }
                    }
            } {
    root@fritz:/var/mod/root# 
    
    
    
     
  10. MaxMuster

    MaxMuster IPPF-Promi

    Registriert seit:
    1 Feb. 2005
    Beiträge:
    6,919
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    #10 MaxMuster, 1 Sep. 2011
    Zuletzt bearbeitet: 1 Sep. 2011
    So, hier mal ein paar Anmerkungen zu deinem "Regelwerk":

    Das bedeutet vermutlich bei "Ausgehende Regeln (highoutput)" sowas (mit X = 123):
    Code:
    permit ip host 192.168.2.123 any
    permit ip host 192.168.2.1 any
    Soweit, so gut. Jetzt aber:
    Die Firewall wirkt nur und ausschließlich bei Paketen, die "durch" den dsld laufen, also die Box durch das DSL-Interface "verlassen" oder "betreten" wollen. Das dürfte also "sinnlos" sein.
    Und: 192.168.2.1/255.255.255.0 war doch hoffentlich 192.168.2.0/255.255.255.0...
    So?
    Code:
    reject ip 192.168.2.0 255.255.255.0 any
    O.k., unabhängig von der "Sinnfrage" habe ich das auf 192.168.178.0/24 übertragen mal eingestellt und...
    Code:
    root@fritz:/var/mod/root# sed -n '/forwardrules/,/} {/ p' /var/flash/ar7.cfg | sed -n '/dsldpconfig/,$ p'
                    dsldpconfig {
                            security = dpsec_firewall;
                            filter_teredo = yes;
                            filter_netbios = yes;
                            lowinput {
                                    policy = "permit";
                                    accesslist = 
                                                 "deny ip any 242.0.0.0 255.0.0.0", /*AVM*/ 
                                                 "deny ip any host 255.255.255.255";/*AVM*/ 
                            }
                            lowoutput {
                                    policy = "permit";
                            }
                            highinput {
                                    policy = "permit";
                            }
                            highoutput {
                                    policy = "permit";
                                    accesslist = 
                                                 "permit ip 192.168.178.0 255.255.255.0 host 192.168.178.123",  
                                                 "permit ip 192.168.178.0 255.255.255.0 host 192.168.178.1",  
                                                 "permit ip host 192.168.178.123 any",  
                                                 "permit ip host 192.168.178.1 any",  
                                                 "reject ip 192.168.178.0 255.255.255.0 any",  
                                                 "reject ip any 242.0.0.0 255.0.0.0", /*AVM*/ 
                                                 "deny ip any host 255.255.255.255", /*AVM*/ 
                                                 "reject ip any 169.254.0.0 255.255.0.0";/*AVM*/ 
                            }
                    }
            } {
    root@fritz:/var/mod/root# 
    

    ...bekomme ebenfalls einen Reboot:
    Code:
    avm_net_trace: New net trace device 'WDS (2.4 GHz, wdsdw1)' registered with minor 132.
    avm_net_trace: New net trace device 'WDS (2.4 GHz, wdsdw1)' registered with minor 133.
    userman: init ok
    device wdsdw1 entered promiscuous mode
    lan: port 3(wdsdw1) entering learning state
    lan: topology change detected, propagating
    lan: port 3(wdsdw1) entering forwarding state
    ADDRCONF(NETDEV_UP): wan: link is not ready
    device wan entered promiscuous mode
    ---- eof avmdebug ----
    
    ---- start avmdebug(suppress 0 bytes) ----
    
    [4294942708][pcmlink]error: trigger to late 1123888 usec (51D47A02 5DE35454 5DE3B4FC)
    [4294942708]avm_DebugSignal: 0 kernel info: 0
    ---- eof avmdebug ----
    CPU 0 Unable to handle kernel paging request at virtual address 6d6f644c, epc == c051b9a0, ra == c051b9dc
    Oops[#1]:
    Cpu 0
    $ 0   : 00000000 1000ce01 6d6f643c 9519b2ac
    $ 4   : 00000003 00000003 00000007 957e9a9c
    $ 8   : 00000001 00000000 00000dd8 942927a0
    $12   : c024014c 94290000 00200200 00100100
    $16   : 957e9aac 0000001c 957e9a80 0000000a
    $20   : c0520000 c0520000 95a2b480 9519c360
    $24   : 00000000 c051b400                  
    $28   : 96bac000 96bad410 96bad5ac c051b9dc
    Hi    : 00000000
    Lo    : aaaaaaab
    epc   : c051b9a0 sort_rules+0x48/0xffd236a8 [kdsldmod]     Tainted: P     
    ra    : c051b9dc sort_rules+0x84/0xffd236a8 [kdsldmod]
    Status: 1000ce03    KERNEL EXL IE 
    Cause : 30800008
    BadVA : 6d6f644c
    PrId  : 00019068
    Modules linked in: userman_mod(P) wlan_scan_ap wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_xauth ath_pci ath_spectral(P) ath_rate_atheros(P) wlan ath_dfs(P) ath_hal(P) avm_ath_)
    Process dsld (pid: 1546, threadinfo=96bac000, task=97e16d18)
    Stack : 957e9a80 c051b900 9519b2ac 951a0c00 c058249c 9519c360 957e9a80 0000001c
            c051bb80 95a2b4b4 9519b214 c05a1d94 9519c360 95a8e280 9519b214 c05a1d94
            c058249c 9519c360 951b0020 95a8e280 00000001 95a2b4b4 95a2b480 00000000
            96bad5ac c0582888 c051229c 00000004 c0513354 c0513290 00000000 00000001
            c0514c44 c0514ce4 c023f8ac 951b0020 95783809 96b31e80 951b0020 951b0020
            ...
    Call Trace:
    [<c051b9a0>] sort_rules+0x48/0xffd236a8 [kdsldmod]
    [<c051bb80>] ipaccess_optim_set+0x5c/0xffd234dc [kdsldmod]
    [<c0582888>] set_dp_parameters+0x2dc/0xffcbca54 [kdsldmod]
    [<c0581420>] dslinterface_create+0xe7c/0xffcbea5c [kdsldmod]
    [<c05011cc>] kdsld_ioctl+0x1724/0xffd3f558 [kdsldmod]
    [<94079024>] do_ioctl+0x64/0x78
    [<94079348>] vfs_ioctl+0x310/0x338
    [<940793c0>] sys_ioctl+0x50/0x90
    [<94010400>] stack_done+0x20/0x3c
    
    
    Code: 8e020000  02662023  26100004 <8c450010> 8c620010  2483ffff  10a2000c  28680002  00e02021 
    Call Trace:
    [<9400d914>] dump_stack+0x8/0x34
    [<9402854c>] panic+0x34/0x1f0
    [<9400e0c8>] die+0xc8/0xd0
    [<94011cac>] do_page_fault+0x24c/0x3c0
    [<94007168>] ret_from_exception+0x0/0x14
    [<c051b9a0>] sort_rules+0x48/0xffd236a8 [kdsldmod]
    [<c051bb80>] ipaccess_optim_set+0x5c/0xffd234dc [kdsldmod]
    [<c0582888>] set_dp_parameters+0x2dc/0xffcbca54 [kdsldmod]
    [<c0581420>] dslinterface_create+0xe7c/0xffcbea5c [kdsldmod]
    [<c05011cc>] kdsld_ioctl+0x1724/0xffd3f558 [kdsldmod]
    [<94079024>] do_ioctl+0x64/0x78
    [<94079348>] vfs_ioctl+0x310/0x338
    [<940793c0>] sys_ioctl+0x50/0x90
    [<94010400>] stack_done+0x20/0x3c
    
    Kernel panic - not syncing: Fatal exception in interrupt
     WARING: use tffs in panic mode (minor 96)
    Rebooting in 5 seconds..
    (AVM) EVA Revision: 1.544 Version: 1544
    (C) Copyright 2005 AVM Date: Oct 24 2008 Time: 11:07:57 (3) 2 0x0-0x41D
    
    [FLASH:] SPANSION Uniform-MirrorBit-Flash 16MB 64 Bytes WriteBuffer
    [FLASH:](Eraseregion [0] 128 sectors a 128kB) 
    [SYSTEM:] UR8 on 360MHz/120MHz syncron
    
    Eva_AVM >
    
    Jetzt muss man nur noch die "genaue" Ursache finden, ich werde es erstmal mit den "überflüssigen" Einträgen versuchen...


    EDIT: Meine Nase war scheinbar ganz gut, die beiden LAN-internen Regeln scheinen das ausgelöst zu haben ;-). So geht es:

    Code:
    root@fritz:/var/mod/root# uptime
     01:02:18 up 2 min, load average: 0.77, 0.54, 0.21
    root@fritz:/var/mod/root# Jan  1 01:02:34 chronyd[2123]: Invalid host/IP address at line 3
    sed -n '/forwardrules/,/} {/ p' /var/flash/ar7.cfg | sed -n '/dsldpconfig/,$ p'
                    dsldpconfig {
                            security = dpsec_firewall;
                            filter_teredo = yes;
                            filter_netbios = yes;
                            lowinput {
                                    policy = "permit";
                                    accesslist = 
                                                 "deny ip any 242.0.0.0 255.0.0.0", /*AVM*/ 
                                                 "deny ip any host 255.255.255.255";/*AVM*/ 
                            }
                            lowoutput {
                                    policy = "permit";
                            }
                            highinput {
                                    policy = "permit";
                            }
                            highoutput {
                                    policy = "permit";
                                    accesslist = 
                                                 "permit ip host 192.168.178.123 any",  
                                                 "permit ip host 192.168.178.1 any",  
                                                 "reject ip 192.168.178.0 255.255.255.0 any",  
                                                 "reject ip any 242.0.0.0 255.0.0.0", /*AVM*/ 
                                                 "deny ip any host 255.255.255.255", /*AVM*/ 
                                                 "reject ip any 169.254.0.0 255.255.0.0";/*AVM*/ 
                            }
                    }
            } {
    root@fritz:/var/mod/root# 
    
    Damit kann man zunächst mal AVM eigentlich keinen richtigen Vorwurf machen.
    Schließlich ist es nicht vorgesehen, dass jemand "von Hand" da Regeln einträgt, mit der die Box nicht klar kommt ;-). Und die "richtigen" Regeln funktionieren ja scheinbar wie gewünscht (zumindest stürzt die Box nicht ab).

    Aber eben nur "zunächst mal":
    Leider kommt es aber auch nach einer Änderung der entfernten Regeln auf "sinnvolle" Werte ( bei den ersten beiden als Ziel IPs "im Internet") zum gleichen Reboot, und daran erkenne ich nun nichts "illegitimes"

    Code:
    permit ip 192.168.178.0 255.255.255.0 host 192.178.178.123
    permit ip 192.168.178.0 255.255.255.0 host 192.178.178.1
    permit ip host 192.168.178.123 any
    permit ip host 192.168.178.1 any
    reject ip 192.168.178.0 255.255.255.0 any
    reject ip any 242.0.0.0 255.0.0.0 /*AVM*/
    deny ip any host 255.255.255.255 /*AVM*/
    reject ip any 169.254.0.0 255.255.0.0/*AVM*/
    

    EDIT2: Gleicher Fehler auch mit aktuellem Trunk und Version 54.05.05.
     
  11. Christoph_F

    Christoph_F Neuer User

    Registriert seit:
    5 Dez. 2006
    Beiträge:
    68
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Das hatte ich in der Nacht übersehen und erst heute gemerkt…

    Nein, nicht an der Fritzbox. Ist das einfach zu bewerkstelligen an einer 7270, die an der Wand hängt oder wird das dann so ein "fliegender Aufbau"?

    Ich hatte mich schon gewundert, wie Du an die schönen Kernel-Ausgaben kommst. Per Telnet/SSH wäre ein wenig schwierig, vor dem Absemmeln dazwischenzukommen.

    Schon mal vielen Dank, unabhängig davon, ob Du das jetzt schaffst oder nicht.

    Mein Verdacht geht in die Richtung, daß der die Grätsche macht, wenn die IP von "seinem" Interface oder welche in dessen Netz, also die aktuelle interne, in dem gesperrten Bereich liegen, das ist aber nur wild geraten.

    Ich hatte unter anderem versucht, mal eine "allgemeingültig" brauchbare Konfiguration auf die Beine zu stellen, die auch häufige Konfigurationsfehler im internen Netz nicht nach außen dringen läßt, beziehungsweise sowas auch nicht von draußen nach drinnen; beispielsweise sollte man durchaus an der Grenze zu fremden Netzen die Privatbereiche sperren, etwa "192.168.0.0/16". Das eigene Netz läßt der Router ja schon von selber drinnen, aber Zeug das falsche IPs aus den Bereichen, jedoch außerhalb des eigenen /24 konfiguriert hat, würde fröhlich nach draußen geleitet. Mit "Reject" vom eigenen Router merkt man bei der Fehlersuche dann auch schneller, wo das Problem liegt.

    Das Freetz-CGI dafür verstehe ich auch noch nicht ganz, manchmal sind meine Änderungen nach einem Reboot wieder weg, kann was mit Wechsel zwischen ein- und ausgehenden und Weiterleitungsregeln, sowie abwechselnden Änderungen im Text-Debug-Fenster zu tun haben. Ich kopiere und modifiziere ja lieber Textzeilen, als immer wieder ähnliche Zahlen in Kästchen einzutragen und auf "Hinzufügen" zu klicken.

    Ich werde demnächst mal systematisch vorgehen und ein paar Änderungen machen, zwischen jeder neu starten und schauen, was geschieht.
     
  12. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    2
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
  13. MaxMuster

    MaxMuster IPPF-Promi

    Registriert seit:
    1 Feb. 2005
    Beiträge:
    6,919
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Die Tests mit der Konsole hab ich schon gemacht, siehe den Beitrag von gestern Abend...
    Ich vermute daher: Es liegt an den "Netzen" als Source zusammen mit "Host" als Ziel (das ist der Unterschied zu den funktionierenden Regeln, denn beides "einzeln" kommt dort vor, allerdings auch nicht mit mit "permit").
    Die Änderungen beim "Übernehmen" landen in der ar7.cfg. Solange kein Neustart von dsld/ctlmgr passiert, können diese beiden AVM-Dienste "nach belieben" Änderungen an der Datei vornehmen. Da die aber irgendwie interne Caches (oder sowas in der Art) davon benutzen, verändern sie die ar7.cfg in der Art "die sie kennen" (ohne die von Freetz gemachten Änderungen) und überschreiben die eventuell wieder.

    Du kannst übrigens den ganzen "GUI-Klick-Kram" auch beiseite lassen, wenn du nur in den "Debug-Anzeigen" arbeitest: Genau das, was da steht, wird in die ar7.cfg eingebaut (mit Einrückungen, Anführungszeichen sowie Komma/Semikolon drum herum). Das Risiko für "Fehler" ist also deutlich größer, der "Copy&Paste"-Vorteil aber auch ;-)
     
  14. Christoph_F

    Christoph_F Neuer User

    Registriert seit:
    5 Dez. 2006
    Beiträge:
    68
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Hallo allerseits, was das Wiki betrifft, schlage ich vor, das in Angriff zu nehmen, wenn wir der Rätsellösung genügend nahe gekommen sind, im Moment sehe ich mehr Fragen als Antworten, ich schaue aber gleich mal nach, ob man nicht eine aktualisierte Warnung einbauen sollte/müßte, damit weniger Leute an Reboot-Schleifen verzweifeln, wegen DIESES Problems braucht man dann nämlich nicht neu zu flashen, sondern nur den ADSL-Stecker zu ziehen, was den Verbindungsaufbau verhindert und den Router übers LAN wieder ganz bequem zugänglich macht.

    Meine Testergebnisse von gestern Nacht:

    1) Portsperren scheinen unkritisch zu sein, sicher bin ich mir aber nicht, ob die nicht auch zum Problem beitragen.
    2) Es *hat* irgendwas mit der "Menge" zu tun, vielleicht nicht dorekt mit der Anzahl, sondern dem Speicherverbrauch der Regeln oder sonstwas in der Art.

    Herumprobiert habe ich mit Regeln für die Multicast-Bereiche:

    Code:
    deny ip any 242.0.0.0 255.255.255.0
    deny ip 242.0.0.0 255.255.255.0 any
    deny ip any 239.255.0.0 255.255.0.0
    deny ip 239.255.0.0 255.255.0.0 any
    deny ip any 239.192.0.0 255.252.0.0
    deny ip 239.192.0.0 255.252.0.0 any
    Diese habe ich zwischen der Broadcast-Sperre und meinen Port-Sperren sowohl in "lowinput", als auch in "highoutput" eingefügt.

    Wie befürchtet gab es eine Rebootschleife. Nach und nach habe ich nun Zeilen gelöscht und abgewartet, ob die Schachtel mehrmals startet. Aufgehört hat das Problem, als ich nur noch eine einzige von den Zeilen ("highoutput") übrig hatte, insgesamt sind nun folgende Anzahlen an Regeln definiert:

    "lowinput": 15
    "highoutput": 16 (die gleichen plus "deny ip any 242.0.0.0 255.255.255.0")
    "forwardrules": 10

    Insgesamt sind das also 41 Stück.

    Randbemerkung: jemand scheint die Regeln übrigens nachträglich zu befummeln: wenn man eine Regel macht, die exakt einer von AVM entspricht, aber den Kommentar dahinter wegläßt, hat sie nach dem Neustart zumindst im Freetz-CGI "/*AVM*/" dahinter; in der "/var/flash/ar7.cfg" finde ich das nicht wieder.

    Interessant finde ich in dem Zusammenhang auch die Funktionsweise des AVM-DNS. Die verwenden doch tatsächlich "Privatadressen", nämlich "192.168.180.1" und "192.168.180.2", die von meinem Internetprovider tauchen nirgends auf. Wie zum Geier geht das, wohin wird das geroutet? Ich hatte schonmal gedacht, es könnte deswegen zicken, wenn man zum Beispiel "192.168.0.0/16" nach draußen sperrt, aber das erklärt nicht das gleiche Verhalten bei den von mir getesteten Multicast-Bereichen.

    Noch ein Exkurs am Ende: ich hatte irgendwo eine Bemerkung über vielleicht durch diese Neustarts verursachte kaputte Partitionierung gemacht, ich bekomme das hier ohne offensichtliche Folgen:

    Code:
    Jan  1 01:01:10 fritz user.warn kernel: mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only
    […]
    Jan  1 01:01:10 fritz user.warn kernel: mtd: partition "kernel" doesn't end on an erase block -- force read-only
    Das dürfte aber anders entstehen, es scheint nämlich immer zu passieren, bei 34 geloggten Neustarts ("syslogd started") habe ich 67 Vorkommen von "erase block" gefunden, betroffen sind wie oben ja zwei Partitionen, also wären 68 normal. Fragt mich jetzt nicht nach der Lücke in den Logs.
     
  15. Christoph_F

    Christoph_F Neuer User

    Registriert seit:
    5 Dez. 2006
    Beiträge:
    68
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ich habe das schon mal dahingehend ergänzt, daß auf die Gefahr von immerwährenden Neustarts hingewiesen und die Lösung durch Abziehen des ADSL-Kabels erklärt und neben den anderen auch auf diese Diskussion verwiesen wird.

    Richtige neue Erkenntnisse gibt es ja leider keine.
     
  16. Christoph_F

    Christoph_F Neuer User

    Registriert seit:
    5 Dez. 2006
    Beiträge:
    68
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    #16 Christoph_F, 4 Sep. 2011
    Zuletzt bearbeitet: 4 Sep. 2011
    Hat sich erledigt…

    Hm, ungefähr seit meiner Testreihe stellt sich mein USB-Speicher dauernd auf "read only", ich sehe nichts in den Logs (Syslog, "dmesg"). Kennt das Phänomen jemand? Es half nicht ein neues Freetz zu installieren (wollte ich sowieso machen, um eine Fehlerbehebung zu testen).

    [LÖSUNG] Hat sich erledigt, einer der Abstürze hat das Dateisystem in Mitleidenschaft gezogen. Warum muß ich dafür die "Push-Service"-Mails von AVM bemühen und kann das nicht im Syslog sehen?
     
  17. MaxMuster

    MaxMuster IPPF-Promi

    Registriert seit:
    1 Feb. 2005
    Beiträge:
    6,919
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Moin,

    die /*AVM*/ Kommentare baut die Firewall-GUI ein, um die "nicht-AVM" Regeln besser zu erkennen (es gab die Idee, alle Nicht-Standard Regeln löschen zu können, ist aber nicht realisiert in der GUI)

    Wie schon oben geschrieben glaube ich aber nicht, dass es grundsätzlich was mit einer "absoluten Maximalzahl" von Regeln zu tun hat:
    Kein Reboot bei 53 Regeln (siehe #9)
    Reboot bei 10 Regeln (siehe #10).

    Kein Reboot:
    Code:
    #Input:
    deny ip any 242.0.0.0 255.0.0.0 /*AVM*/
    deny ip any host 255.255.255.255/*AVM*/
    
    #Output:
    permit ip host 192.168.178.123 any
    permit ip host 192.168.178.122 any
    permit ip host 192.168.178.1 any
    reject ip 192.168.178.0 255.255.255.0 any
    reject ip any 242.0.0.0 255.0.0.0 /*AVM*/
    deny ip any host 255.255.255.255 /*AVM*/
    reject ip any 169.254.0.0 255.255.0.0/*AVM*/
    
    Reboot (eine weitere Zeile):
    Code:
    #Input:
    deny ip any 242.0.0.0 255.0.0.0 /*AVM*/
    deny ip any host 255.255.255.255/*AVM*/
    
    #Output:
    permit ip host 192.168.178.123 any
    permit ip host 192.168.178.122 any
    [B]permit ip host 192.168.178.121 any[/B]
    permit ip host 192.168.178.1 any
    reject ip 192.168.178.0 255.255.255.0 any
    reject ip any 242.0.0.0 255.0.0.0 /*AVM*/
    deny ip any host 255.255.255.255 /*AVM*/
    reject ip any 169.254.0.0 255.255.0.0/*AVM*/
    
    Momentan geht meine Vermutung deshalb in die Richtung, dass der Fehler "nur" von der Menge der Regeln mit Protokoll "ip" abhängt ("viele" Regeln hatte ich sonst nur mit "Protokollbeschränkung" versucht):

    Entweder in und out zusammen: 9 Regeln funktionieren noch, ab 10 nicht mehr oder
    Nur für einen (bei mir "out"): 7 Regeln funktionieren noch, ab 8 geht es nicht mehr


    Da ich kein ADSL an der Box habe, sondern das mit "Internet über LAN1" mache, hilft das Entfernen vom Kabel nicht (reboot auch, wenn LAN1 leer ist); ich nutze deshalb eine angepasste rc.S, die die Regeln "geradezieht" ;-)


    Sobald ich das verifiziert habe, trage ich es nach..
     
  18. MaxMuster

    MaxMuster IPPF-Promi

    Registriert seit:
    1 Feb. 2005
    Beiträge:
    6,919
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Ich glaube, ich hab's :D:D:D:
    Es dürfen von allen Regeln mit dem "Protokoll" ip nur 3 von "einer Art" hintereinander stehen. Sind es mehr als drei, kommt es zum Reboot (gilt für "permit ip", "reject ip" und "deny ip").

    Mit einer "Dummy"-Regel nach jeweils drei Regeln kann ich "sehr lange" Regelwerke bauen, so wie dieses bei "Output" mit 50 "permit ip"-Regeln:
    Code:
    permit ip host 192.168.178.1 any
    permit ip host 192.168.178.2 any
    permit ip host 192.168.178.3 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.4 any
    permit ip host 192.168.178.5 any
    permit ip host 192.168.178.6 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.7 any
    permit ip host 192.168.178.8 any
    permit ip host 192.168.178.9 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.10 any
    permit ip host 192.168.178.11 any
    permit ip host 192.168.178.12 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.13 any
    permit ip host 192.168.178.14 any
    permit ip host 192.168.178.15 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.16 any
    permit ip host 192.168.178.17 any
    permit ip host 192.168.178.18 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.19 any
    permit ip host 192.168.178.20 any
    permit ip host 192.168.178.21 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.22 any
    permit ip host 192.168.178.23 any
    permit ip host 192.168.178.24 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.25 any
    permit ip host 192.168.178.26 any
    permit ip host 192.168.178.27 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.28 any
    permit ip host 192.168.178.29 any
    permit ip host 192.168.178.30 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.31 any
    permit ip host 192.168.178.32 any
    permit ip host 192.168.178.33 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.34 any
    permit ip host 192.168.178.35 any
    permit ip host 192.168.178.36 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.37 any
    permit ip host 192.168.178.38 any
    permit ip host 192.168.178.39 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.40 any
    permit ip host 192.168.178.41 any
    permit ip host 192.168.178.42 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.43 any
    permit ip host 192.168.178.44 any
    permit ip host 192.168.178.45 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.46 any
    permit ip host 192.168.178.47 any
    permit ip host 192.168.178.48 any
    reject ip host 1.2.3.4 any
    permit ip host 192.168.178.49 any
    permit ip host 192.168.178.50 any
    reject ip any 242.0.0.0 255.0.0.0 /*AVM*/
    deny ip any host 255.255.255.255 /*AVM*/
    reject ip any 169.254.0.0 255.255.0.0/*AVM*/
    
    
     
  19. Christoph_F

    Christoph_F Neuer User

    Registriert seit:
    5 Dez. 2006
    Beiträge:
    68
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Hallo,

    das ist ja unglaublich! Wie bist Du darauf gekommen und vor allem: wie schafft man es, so einen seltsamen Programmfehler zu erzeugen? Interessant wäre jetzt noch, was alles als "Unterbrechung" zählt, heute Abend oder so mal ausprobieren, ob man nicht einfach eine Portsperre nach jeweils drei Reject-Regeln einstreuen kann. Da gibt es ja genug, was man sinnvollerweise nach draußen hin unterbinden kann.
     
  20. MaxMuster

    MaxMuster IPPF-Promi

    Registriert seit:
    1 Feb. 2005
    Beiträge:
    6,919
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Drauf gekommen bin ich, weil das mit dem reinen "Zählen" der Regeln nicht wirklich klappen wollte.
    Ich war bei der These: drei von "einer Klasse" geht, aber vier nicht mehr, bis ich merkte, dass beim funktionierenden(!) Test mit drei mal "reject ip" noch "weiter unten" eine weitere (original-Regel) der gleichen Klasse war, so dass es eigentlich vier waren. Dann kam die Vermutung auf, dass die "Unterbrechung" durch die "deny" Regel das funktionieren ließe...
    Und so scheint es bei mir zumindest gewesen zu sein.
    Bin gespannt, ob du das nachvollziehen kannst.