[Problem] instabile AVM-Firewall auf 7270

[Christoph_F]

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?

 

[Silent-Tears]

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?

 

[olistudent]

Was genau hast du denn eingetragen, dass es zu dem Fehler kam?

Gruß
Oliver

 

[fant]

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

 

[MaxMuster]

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

 

[olistudent]

@fant
Da bräuchten wir schon den geänderten Abschnitt aus deiner ar7.cfg oder zumindest ein Screenshot davon...

Gruß
Oliver

 

[Christoph_F]

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…

 

[Christoph_F]

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.

 

[MaxMuster]

Nachdem ich die Dauerreboots behoben hatte [...] habe ich das hier gefunden[...]

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...

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#

 

[MaxMuster]

So, hier mal ein paar Anmerkungen zu deinem "Regelwerk":

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),

Das bedeutet vermutlich bei "Ausgehende Regeln (highoutput)" sowas (mit X = 123):

permit ip host 192.168.2.123 any
permit ip host 192.168.2.1 any

Soweit, so gut. Jetzt aber:

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)

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...

danach dem LAN den Zugriff genommen (IP, to any, from 192.168.2.0/255.255.255.0, reject).

So?

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...

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:

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:

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"

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.

 

[Christoph_F]

Um dir das Suchen zu erleichtern oder abzunehmen hatte ich genau darauf in Beitrag #5 verwiesen ;-)

Das hatte ich in der Nacht übersehen und erst heute gemerkt…

Leider enden die Threads ohne eine echte Erfolgs- oder Misserfolgsmeldung für neuere Kernel. Hast du eine serielle Konsole?

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.

Zur Not könnte ich mir das übers WE nochmal ansehen...

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

EDIT Das mit den "vielen Regeln" kann es eigentlich nicht mehr sein.

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.

 

[olistudent]

Es wäre schön, wenn die Erkenntnisse von hier auf der Wiki-Seite landen würden.
http://freetz.org/wiki/packages/avm-firewall

Danke
Oliver

 

[MaxMuster]

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").

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.

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 ;-)

 

[Christoph_F]

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:

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:

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.

 

[Christoph_F]

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.

 

[Christoph_F]

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?

 

[MaxMuster]

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:

#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):

#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..

 

[MaxMuster]

Ich glaube, ich hab's :
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:

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*/

 

[Christoph_F]

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.

 

[MaxMuster]

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.