AVM Firewall, ipv6 & AR7.cfg Interna

[cando]

Hallo,

kennt sich hier jemand etwas genauer mit dem dsld und den darin enthaltenen Firewalls aus?

Mir ist aufgefallen, daß es in der ar7.cfg an 3 verschiedenen Stellen der dsld als firewall konfiguriert werden kann, wovon 2 per default komplett auf Durchgang geschaltet sind:

pppoefw

      pppoefw {
                interfaces = "lan", "usbrndis", "eth0", "wlan";
[B]                nofirewall = yes;[/B]
                ipnetbiosfilter = yes;
                dnsfilter_for_active_directory = yes;
                hostuniq_filter = "";
                dpconfig {
                        security = dpsec_host;
                        lowinput {
                                policy = "reject";
                                accesslist = 
                                             "permit ip any any connection outgoing-related", 
                                             "permit ip any any connection incoming-related", 
                                             "permit icmp any any";
                        }
                        lowoutput {
                                policy = "permit";
                        }
                        highinput {
                                policy = "permit";
                        }
                        highoutput {
                                policy = "permit";
                                accesslist = 
                                             "reject ip any 242.0.0.0 255.0.0.0", 
                                             "deny ip any host 255.255.255.255", 
                                             "reject ip any 169.254.0.0 255.255.0.0", 
                                             "reject udp any any range 161 162", 
                                             "reject udp any any eq 111";
                        }
                }
        }

dsl-internet Interface (das ist wohl die AVM-Firewall aus freetz)

                dsldpconfig {
                        security = dpsec_firewall;
                        lowinput {
                                policy = "deny";
                                accesslist = 
                                             "deny ip any 242.0.0.0 255.0.0.0", /*AVM*/ 
                                             "deny ip any host 255.255.255.255", /*AVM*/ 
                                             "deny udp any any eq 135", /*AVM*/ 
                                             "deny tcp any any eq 135", /*AVM*/ 
                                             "deny udp any any range 137 139", /*AVM*/ 
                                             "deny tcp any any range 137 139", /*AVM*/ 
                                             "deny udp any any range 161 162", /*AVM*/ 
                                             "deny udp any any eq 520", /*AVM*/ 
                                             "deny udp any any eq 111", /*AVM*/ 
                                             "deny udp any any eq 22289", /*AVM*/ 
                                             "deny udp any any eq 1710", /*AVM*/ 
                                             "deny udp any any eq 1048", /*AVM*/ 
                                             "deny udp any any eq 158", /*AVM*/ 
                                             "deny udp any any eq 515", /*AVM*/ 
                                             "permit ip any any connection outgoing-related";
                        }
                        lowoutput {
                                policy = "deny";
                        }
                        highinput {
                                policy = "deny";
                        }
                        highoutput {
                                policy = "deny";
                                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*/ 
                                             "reject udp any any range 161 162", /*AVM*/ 
...
                                             "reject udp any any eq 111", /*AVM*/ 
                                             "permit tcp any any eq 80", 
                                             "permit udp any any eq 80", 
                                             "permit ip any any connection outgoing-related";
                        }

VoIP Internet Interface: (die ist offen, wie ein Scheunentor für alle udp Dienste)

                dsldpconfig {
                        security = dpsec_firewall;
                        lowinput {
                                policy = "permit";
                                accesslist = "permit udp any any", 
                                             "permit icmp any any", 
                                             "deny ip any host 255.255.255.255", 
                                             "reject ip any any";
                        }
                        lowoutput {
                                policy = "permit";
                        }
                        highinput {
                                policy = "permit";
                        }
                        highoutput {
                                policy = "permit";
                                accesslist = "permit udp any any", 
                                             "reject ip any any";
                        }
                }

Was hat es denn mit lowinput, lowoutput, highinput, highoutput genau auf sich (ich vermute, das sind dsl kanäle)?

lowoutput und highinput sind immer offen, konfiguriert werden nur lowinput und highoutput. Kann man die lowoutput und highinput überall gefahrlos auf deny setzen, sind die eine potentielle Hintertür für Provider / Hersteller?

Wenn man kein VoIP hat, sollte man dann nicht sinnvoller Weise die VoiP Firewall generell sperren brw die Rechte für den udp Verkehr entziehen?

Die ppoefw ist komplett abgeschaltet. Greift die nur in der Betriebsart "Modem" oder auch in der Betriebsart "Router"?

Ich wollte einfach nur mögliche Sicherheits-Lücken aufdecken / schliessen.

Ipv6 wird in der Box getunnelt (ipv6mode = ipv6_tunnel;), die Firewall ist eine reine ipv4 Firewall. Wenn man also mit ipv6 clients im Lan zu ipv6 Servern im Internet kommuniziert ist man ungeschützt, da das Protokoll getunnelt wird.

Eine Möglichkeit ist, bei allen Clients ipv6 und teredo zu deaktivieren, besser wäre es insgesamt ipv6 auf der Box zu sperren, solange dafür keine vernünftige Firewall da ist - das nat greift bei ipv6 nicht, es wurde ja erfunden, um nat überflüssig zu machen / zu überwinden.

Wie kann man ipv6 und ipv6 Tunnel auf der Box komplett deaktivieren?

ipv6 {
        ulamode = ulamode_dynamic;
        use_default_ula = yes;
        ula = fd00::;
        use_fixed_mtu = no;
        fixed_mtu = 1280;
        radv {
                MinRtrAdvInterval = 450;
                MaxRtrAdvInterval = 600;
                AdvDefaultLifetime = 1800;
                PreferedLifeTime = 3600;
                ValidLifeTime = 7200;
        }
        sixxs {
                ticserver = "tic.sixxs.net";
        }
        labconfig {
                enable = no;
                radv_GUA_disable = no;
                radv_overwrite_liftimes = no;
                radv_overwrite_prefered_lifetime = 1800;
                radv_overwrite_valid_lifetime = 3600;
                radv_overwrite_flags = no;
                radv_set_mflag = no;
                radv_set_oflag = yes;
                dhcpv6wanmode = dhcpv6wanmode_statefull;
        }
}

Ich weiss, das sind sehr viele Fragen auf einmal.

Aber wenn man eine sichere Box will, muss man Entlang der gesamten Kette die Schwachstellen suchen und beseitigen.

 

[Silent-Tears]

Auch wenns interessant ist, meinst du nicht, du übertreibst damit? Ich zumindest habe mein gesamtes Netz im Griff hier, und vor allem keine fehlerhaften Windows-Clients, da die wenn überhaupt nur per NAT durch die lokalen Firewalls ins Netz dürfen. Von daher mache ich mir so ungefähr 0 Gedanken darüber.
Vor allem aber: Wer setzt denn aktuell schon ipv6 ein? Selbst in der originalen Firewall ist das nur als kaum gepflegte Beta vorhanden.

 

[cando]

Lustig, dass Du es erwähnst.

Seit XP SP2 gibt es Teredo (UDP Port 3544), dass durch jede NAT Firewall marschiert (UDP ist ja wegen VoIP default offen) und so IPv6 Verbindungen in beiden Richtungen erlaubt.

In Vista und Windows7 sind IPv6 per default an, Windows7 hat gleich 3! IPv6 Tunnelprotokolle standardmäßig an:

ISATAP
TEREDO
6to4

Microsoft begründet das mit ihren neuen Messaging Diensten (LifeMessanger), die nur noch über ipv6 funktionieren und deshalb halt die Umgehung der NAT-Firewalls nötig machen.

Die FritzBox fügt noch SIXXS mit TIC /AICCU hinzu (UDP 3740, TCP 3874,...)

Linux ist auch nicht besser, es hat auch ipv6 Tunnel und native ipv6 Unterstützung default angeschaltet.

Ein Schweizer Käse könnte nicht löchriger sein, zumal die ganzen Tunnelaktivitäten vom Lan aus beim Booten der PC initiiert werden und die stateful einstellungen der Firewall für den Rückverkehr diese Tunnel alles öffenen.

Da kann man seinen PC Direkt ins Internet ohne Firewall hängen.

http://www.cert.org/blogs/vuls/2009/08/managing_ipv6_part_i.html

Hier eine Anleitung zum Schutz vom CERT, da sind die sixxs leider noch nicht berücksichtigt. Das Problem ist, dass wenn man ein Loch stopft, die Hersteller neue aufmachen.

Hier die Hilfe für geplagte Firewall - Admins, die sixxs blocken wollen:

http://www.sixxs.net/faq/connectivity/?faq=firewalled

Es ist ein großes Problem, und das schlimme ist die Unwissenheit der User. Diese Hintertüren, die vom PC aus durch die Firewalls geöffnet werden bieten Angriffspunkte für Trojaner, Viren, Rootkits, Onlinedurchsuchungen etc.

Da jedes Gerät eine eindeutige ipv6 Adresse zugeordnet bekommt, ist es potentiell über diese weltweit erreichbar, sobald es sich am Netzwerk anmeldet.

 

[Silent-Tears]

Läuft hier alles nicht. Von daher....

Dennoch ist da ein Stück weit Panikmache dabei und ich würde das nicht zu weit hoch stilisieren.
Nicht falsch verstehen, ich finds klasse, dass sich da jemand drum kümmert, aber ich denke, mein ipv4only-Netz mit Natting der Windows-Systeme (und deren physikalische Abschaffung), lokalen Firewalls und iptables reicht lange Meter aus. Zumindest für mich

Ergo langt es doch aber aus, alöles auf "deny" zu stellen in der Firewallconfig von AVM und nur noch durchzulassen, was man wirklich will.

 

[cando]

So schütze ich mich ja bislang auch, indem ich auf jedem Rechner im Netz die ipv6 deinstalliere / sperre.

Trotzdem darf eine Firewall nicht für udp einen Persilschein ausstellen (wie die Fritzbox im voip Bereich der AVM Firewall). Ich würde gern wissen, ob dieses voip interface Verkehr in die LAN Segmente zulässt oder "nur" die Fritzbox kompromittiert. Und selbst wenn nur die Box betroffen wäre, sollte man geeignete Massnahmen ergreifen, um ein Hacken des Routers von Aussen zu verhindern.

Das AVM-Firewall GUI kümmert sich leider nur um Regeln für 2 von 12 möglichen Interfaces.

iptables sperrt schon eine Menge mehr, wenn auch noch ip6tables auf die Box kämen und default DROP hätten, wäre es fast perfekt.

 

[MaxMuster]

Trotzdem darf eine Firewall nicht für udp einen Persilschein ausstellen (wie die Fritzbox im voip Bereich der AVM Firewall).

Das würde ich etwas dedizierter sehen.
Grund eins ist, dass es eine teilweise reine (zugegeben: naheliegende ;-)) Vermutung ist, was du da aus den Einträgen in der ar7.cfg herausliest. Was aber keiner (außer AVM) weiß ist, worauf sich diese Einträge beziehen. Wenn die z.B. bedeuten, dass der voipd eine "eigene FW" hat und der für alle UDP Ports "offen ist", wie und was willst du dran ändern, da ja auch der voipd selbst eine AVM Eigenkreation ist? Ein "generelles" statefull UDP-Handling ist für ein "verbindungsloses" Protokoll erstmal unmöglich, auf einzelnen Dienste bezogen zwar theoretisch denkbar, aber in der Praxis doch fast unmöglich.
Zudem finde auch ich die Begriffe wie "Scheunentor" usw. etwas zu arg, denn es hängt nun einmal im dsld hinter "dieser" Firewall noch der NAT-"Firewall-Part". Und wie gut oder schlecht der ist kann niemand wirklich sagen. Und wenn tatsächlich alle Pakete ohne NAT-Eintrag verworfen werden, ist das aus meiner Sicht durchaus genauso gut, als wenn sie vorher verworfen werden (wie gesagt, es sind beides ausschließlich dsld-Interna).

Das soll deine "iptables Verdienste" überhaupt nicht schmälern, aber ich würde momentan in der Tat nicht so weit gehen zu behaupten, eine Fritzbox in ihrer "Grundeinstellung" ist übermäßig stark gefährdet.

Jörg

 

[cando]

Hallo MaxMuster,

Ich würde Jein sagen.

Zunächst mal weitere Ergebnisse meiner Forschungen. Ich habe in allen permit Zweigen der ar7.cfg Reject eingetragen (natürlich vorher mein Admin Segment zur Firewall jeweils erlaubt).

Siehe da, Internet geht nicht mehr (AVM-Firewall per GUI natürlich richtig konfiguriert, sie hat schon immer default deny bei mir). Also die Regeln in den anderen Bereichen scheinen Wechselwirkungen auf einander und auf die AVM Firewall - Sektion zu haben.

Nun zum udp. Mit conntrack und seinen Zusatzmodulen wird ja eben "Statefull" udp als verbindungsloses Protokoll für die verschiedenen Anwendungen gefiltert.

Teredo & Co wurden von den Herstellern dafür entwickelt, ipv6 auszurollen und NAT Firewalls für ipv6 Applikationen zu überwinden, Wenn man Fritz-Boxen und andere SoHo Büchsen nicht konfiguriert, werden ipv6 Tunnel von den Clients ins Internet z.B. zu sixxs oder teredo oder Microsoft aufgebaut und von den dortigen ipv6 dhcp Servern eindeutige ipv6 Adressen
zugewiesen. Der client baut die Verbindung auf beim Booten, so dass die Nat-Büchsen es als "freundlichen" ausgehenden Verkehr interpretieren und den Tunnelaufbau zulassen.

Über diese Tunnel sind danach die Rechner mit ihrer ipv6 Adresse aus dem Internet erreichbar für ipv6 Applikationen.

Für Firmen, die das natürlicherweise nicht wollen, dass alle ihre privaten Netze und Arbeitsplatzrechner im Internet angreifbar werden, gibt es detaillierte Anleitungen für die Firewall Admins wie das zu verhindern ist.

Nun mal meine Frage. Wieso sollen Rechner von Privatpersonen nicht so schutzbedurftig sein, wie Firmen PC's?

IMHO ist das TÜV-Siegel für die Sicherheit der Fritz!Box nicht gerechtfertigt, solange die Boxen die ipv6 Tunnelung explizit zulassen, ohne eine Möglichkeit zu bieten, dies abzuschalten. Die Berufung auf "nat" ist sicher zieht bei ipv6 Tunnelung nicht.

im übrigen der Eintrag in der ar7.cfg:

ipv6mode = ipv6_tunnel;

spricht ja wohl Bände, ipv6 Verkehr wird explizit von der Fritzbox selbst getunnelt, und zwar mit Hilfe von sixxs TIC /AICCU Diensten.
Hinzu kommt, dass udp default permit für abgehenden und kommenden Verkehr hat, was teredo, ISATAP, 6to4, AYIYA etc. ermöglicht.

 

[MaxMuster]

Hi cando,

ich gehe ja vollkommen mit dir konform, dass eine sauber eingerichtete FW sicher "besser" sein wird, als der Standard von AVM.
Nur ist dabei zu bedenken, welchen Aufwand eine "sauber Einrichtung" bedarf. Und da ist nunmal meine These, dass oft die Bequemlichkeit siegt was im Fazit bedeutet: In einem Großteil der Fälle wird, wenn es "halbwegs funktioniert", der Standard beibehalten.

Und bislang bleibe ich bei meiner Einschätzung, dass die Grundfunktion "Firewall" der Fritzboxen durchaus "ganz brauchbar" ist und meine Befürchtung eher in die Richtung geht, dass Begriffe wie "offene Scheunentore" bei einigen Usern vielleicht eher zu hektischen Aktivitäten führen, die nicht immer das gewünschte Ergebnis haben...

Letztlich plädiere ich für einen "gemäßigteren" Umgang mit dem Thema: Wenn sich "Experten" unterhalten, sollen sie gerne über Gefahren und mögliche Abhilfen austauschen.

Den Eindruck, dass allein in der Tatsache, dass dsld einige Dinge in seiner "Firewallfunktionalität" zulässt eine "Gefahr" besteht würde ich zumindest solange bezweifeln, bis es jemand geschafft hat, einen Dienst auf der Box zu erreichen, ohne ein Portforwarding dafür eingerichtet zu haben (ausgenommen die, für die AVM das schon selbst so vorgesehen hat).

Wenn ich "Schuldige" oder "Gefahren" im V6 Umfeld suche, würde ich noch am ehesten in deine Richtung tendieren. Aber auch da habe ich "aber"s ;-)
Machen tatsächlich alle Boxen IP-V6? Ein vorhandener ar7.cfg-Eintrag allein stellt ja keine Funktionalität her (sonst könnte z.B. meine Eumex auch WLAN ;-)).
Und man könnte sich auch auf den Standpunkt stellen, dass derjenige, der IP-V6 installiert, wissen sollte, was er tut. Und wenn die Standardmäßige Installation in einem "weit verbreiteten Betriebssystem"
ohne eine solche Nachfrage oder Wissen des Benutzers erfolgt, könnte man auch von dem Hersteller erwarten, den PC entsprechend zu schützen ;-)

Generell könnte man ja durchaus an AVM die Anfrage stellen, sich an den "Symantec-Rat" laut Wikipedia zu halten: "Dem sicherheitsorientierten Administrator wird daher empfohlen, bis zur Verfügbarkeit entsprechender Firewalls den durch Teredo benutzten UDP-Port 3544 komplett zu sperren."

Jörg

 

[cando]

Wahrscheinlich hast Du Recht.

Ich befürchte ja nicht mal so sehr, dass die Box gehackt wird, sondern daß die Geräte im LAN hinter der Box angegriffen werden können auf Grund der Tunnel, die sie Zugegebenermassen selber aufmachen.

Nur, einfach Windows (oder Linux) zu installieren und dann zu glauben, ich habe eine Fritzbox, die schützt mich schon, weil sie eine eingebaute Internet nat Firewall hat (was auch immer das sein soll) ist nicht der Bringer.

Mag sein, dass ipv6 noch sehr neu ist und es kaum jemand wirklich bewusst nutzt oder versteht und auch überhaupt braucht. Das ist vorläufig schon ein gewisser Schutz vor den bösen Buben.

Nur v6 wird mit Macht in den Markt gedrückt und die OS Hersteller integrieren sowohl das native v6 als auch alle möglichen Tunnelchen - mit kommerziellen Interessen nach iptv, voip, messenger diensten etc., die bislang an firewalls scheiterten. Zum Teil werden diese ja nicht mal von installierten IDS Systemen vernünftig gescannt und aufgespürt.

Früher war es noch einfach: Firmenpolycy: Internet nur über Proxy, FTP verboten, udp gesperrt. Für eine Handvoll User gab es SOCKS, für Sonderfälle in der Entwicklung - DMZ Netze. Wer mit Tunneln erwischt wurde, wurde abgemahnt, Messenger waren verboten und telefoniert wurde mit dem Telefon.

Heute kann jeder alles über jedes Protokol tunneln, Proxys bieten keinen Schutz mehr - ssl Tunnel marschieren da überall durch, selbst icmp wird zum Tunneln verwendet. Und die Hersteller bauen gleich ins OS aktivierte Tunnel ein.

Die iptabels firewall ist schon ein Schritt in die richtige Richtung, aber nur die halbe Miete. ip6tables muss auch noch drauf und mindestens alles sperren, was nicht gebraucht wird. Zusätzlich sollte man auch noch die üblichen Verdächtigen (teredo & co) mit entsprechenden Policies einfangen.

Da bleiben noch genug andere Risiken für die Virenjäger.

 

[olistudent]

Könnte es sich bei dem VOIP Interface nicht um den bei manchen Provider aufgebauten 2. VCC handeln? Da ich sowas noch nicht gesehen habe weiß ich nicht wie das realisiert ist.

MfG Oliver

 

[RAMler]

Entschuldigt das ich das hier wieder ausgrabe, aber weiß nun jemand wie ich IPv6 in der Box deaktivieren kann?

PS:
Wenn ich mit AVM Firewall GUI ne Whitelist einrichte, ist dann auch VoIP davon betroffen und die UDP "any" Freigabe quasi dicht? Wäre wünschenswert, da VoIP nicht genutzt wird.

 

[cando]

Mit freetz kannst Du die ipv6 Unterstützung im Kernel deaktivieren (replaced kernel - make kernel-menuconfig -> networking -> networking options -> The ipv6 protocol)

Außerdem kannst du mit iptables die gängigen ipv6 tunnelprotokolle und ports per regel sperren (sixxs, teredo, 6to4 etc.), damit die clients nicht über ipv4 den ipv6 traffic heimlich trotzdem tunneln.

Mit iptables kannst Du auch auch sehr fein abgestimmt den udp traffic mit dynamischen ports (z.B. ftp, voip irc etc.) steuern (conntrack module).

Die AVM Firewall ist dafür eher unbrauchbar / zu grob.

Die Fritz Box - VoIP Lösung hat übrigens einen eigenen Bereich in der ar7.cfg für die VoIP Firewall Freigaben und läßt sich über das Web-GUI von Freetz nicht manipulieren. Allerdings scheinen die Einstellungen in den einzelnen Sektionen sich wechselseitig zu beeinflussen, so dass die schärferen Regeln im Netz Bereich auch das Voip sperren können. Wie die Firewall mit den verschiedenen Einstellungen in der ar7.cfg aber genau funktioniert (Prioritäten, Reihenfolge etc.) weiss nur AVM.

hier die Regeln für iptables zum sperren von ipv6:

iptables -A FORWARD -p udp -m multiport --dports 3544,3545,3740,5072 -j REJECT --reject-with icmp-net-prohibited 
iptables -A FORWARD -p tcp -m tcp --dport 3874 -j REJECT --reject-with icmp-net-prohibited 
iptables -A FORWARD -p udp -m multiport --sports 3544,3545,3740,5072 -j REJECT --reject-with icmp-net-prohibited 
iptables -A FORWARD -p tcp -m tcp --sport 3874 -j REJECT --reject-with icmp-net-prohibited 
iptables -A FORWARD -p ipv6 -j REJECT --reject-with icmp-net-prohibited 
iptables -A FORWARD -p ipv6-route -j REJECT --reject-with icmp-net-prohibited 
iptables -A FORWARD -p ipv6-frag -j REJECT --reject-with icmp-net-prohibited 
iptables -A FORWARD -p ipv6-icmp -j REJECT --reject-with icmp-net-prohibited 
iptables -A FORWARD -p ipv6-nonxt -j REJECT --reject-with icmp-net-prohibited 
iptables -A FORWARD -p ipv6-opts -j REJECT --reject-with icmp-net-prohibited 

iptables -A OUTPUT -p udp -m multiport --dports 3544,3545,3740,5072 -j REJECT --reject-with icmp-net-prohibited 
iptables -A OUTPUT -p tcp -m tcp --dport 3874 -j REJECT --reject-with icmp-net-prohibited 
iptables -A OUTPUT -p ipv6 -j REJECT --reject-with icmp-net-prohibited 
iptables -A OUTPUT -p ipv6-route -j REJECT --reject-with icmp-net-prohibited 
iptables -A OUTPUT -p ipv6-frag -j REJECT --reject-with icmp-net-prohibited 
iptables -A OUTPUT -p ipv6-icmp -j REJECT --reject-with icmp-net-prohibited 
iptables -A OUTPUT -p ipv6-nonxt -j REJECT --reject-with icmp-net-prohibited 
iptables -A OUTPUT -p ipv6-opts -j REJECT --reject-with icmp-net-prohibited 

iptables -A INPUT -p udp -m multiport --sports 3544,3545,3740,5072 -j REJECT --reject-with icmp-net-prohibited 
iptables -A INPUT -p tcp -m tcp --sport 3874 -j REJECT --reject-with icmp-net-prohibited 
iptables -A INPUT -p ipv6 -j REJECT --reject-with icmp-net-prohibited 
iptables -A INPUT -p ipv6-route -j REJECT --reject-with icmp-net-prohibited 
iptables -A INPUT -p ipv6-frag -j REJECT --reject-with icmp-net-prohibited 
iptables -A INPUT -p ipv6-icmp -j REJECT --reject-with icmp-net-prohibited 
iptables -A INPUT -p ipv6-nonxt -j REJECT --reject-with icmp-net-prohibited 
iptables -A INPUT -p ipv6-opts -j REJECT --reject-with icmp-net-prohibited

Artikel zu IPv6 Bedrohungen

 

[RAMler]

Vielen Dank, nur soll Iptables mit den conntrack Modulen und meiner "7170" (W701V) ja nicht stabil laufen.

Oder ist da Problem nicht mehr existent?

 

[Silent-Tears]

Oder ist da Problem nicht mehr existent?

Hast du entsprechendes gelesen? Wenn ja, werden sich sicher einige freuen.

 

[quantive]

Und wieder holt einer dieses Thema herauf.

Ich kann momentan meine FB 7270 nur über öffentlichen 6to4 Tunnel mit dem
Globalen IPv6-Präfix "2002:2f15:cde5::/56" ans IPv6-Internet bringen.

1. Bei mir steht z.B. in der Fritz!Box unter IPV6
"An FRITZ!Box angeschlossene Computer sind sicher vor unerwünschten Zugriffen aus dem Internet. Für einige Anwendungen wie z.B. Online-Spiele oder das Filesharing-Programm eMule muss Ihr Computer jedoch für andere Teilnehmer des Internets erreichbar sein. Durch Portfreigaben erlauben Sie solche Verbindungen. ",
obwohl IPv6 Unterstützung aktiviert ist. Das heißt Holzhammermethode. Von Außen kommt nichts ins Heimnetzwerk, nur über Freigaben. Widerspricht zwar dem End-zu-End Gedanken von IPV6, aber was interessiert mich der Gedanke. Die Entwickler interessieren sich auch nicht für meine Sicherheit.

2. Und dass diverse Ports für VOIP weiter geleitet sind, ist auch klar.

Ich verstehe die Diskussion bezüglich Firewall-Regeln nicht ganz, denn die FB regelt das doch intern.
Anders wäre es, wenn ich einen Tunnel per Software, z.B. vom Tunnelbroker SIXXS, aufbauen würde oder wenn ich eine VOIP Software installiert hätte. Dann wäre meine Firewall/NAT-Router je nach meinen Einstellungen durchlöchert.

Übrigens, wenn kein Dienst/Programm Pakete erwartet, dann können in der Firewall ALLE Pakete ins Heimnetz weiter geleitet werden. Es kommt auf die korrekte Konfiguration des Clients an.

 

[cando]

Ja, das alte Thema Sicherheit...

Also zunächst, alles was kommunizieren kann, ist per se unsicher.
Jeder, der Werbesprüche vertraut ist selbst Schuld.

Grundsätzlich gilt, die Fritzbox schütz nicht von Haus aus gegen die Gefahren aus dem Internet, weder in ipv4 noch im ipv6 Umfeld. Und ja, ich kann einen PC mit entsprechenden Mitteln / Konfiguration auch ohne Fritz Box relativ sicher direkt ans Internet stecken, er wäre nicht mehr oder weniger gefährdet als mit einer vorgeschalteten Fritz Box und es steht mir frei diese Mittel auch in einem vermeintlich sicheren LAN zu verwenden.

Die Hürde bei IPv4 in der FritzBox ist das NAT in Verbindung mit einem entsprechend notwendigen connection tracking, damit eine Verbindung von einer privaten IP Adresse
in das Internet aufgebaut werden kann und das Antwortpaket auch sein Ziel findet. Das beinhaltet eine aktive Sitzungsüberwachung - wie in einer richtigen Firewall.

Bei IPv6 ist das nicht mehr nötig, da keine Adressübersetzung mehr stattfindet und damit einer direkten bidirektionalen Kommunikation nichts mehr im Wege steht. Hier ist der einzige Schutz die PC Firewall, die Fritzbox ist dann nur noch ein einfacher Router.

Nun kommen wir zu den schier unendlichen Tunnelprotokollen. Hier ist der Tunnelbauer und die Art des Tunnels das Problem. Macht der PC selbst den Tunnel auf, läuft er zusätzlich mit seinem im IPv4 eingepackten IPv6 Payload über das NAT der Fritte - mit den oben beschriebenen Einschränkungen, was Angreiver aus der Welt von IPv4 angeht, anders aber bei Angriffen über IPv6. Die werden ganz normal durch den Tunnel geroutet.

Sichere Systeme sind nur welche, die man versteht und ordentlich überwacht. In beiden Punkten ist die AVM Firmware, samt Werbeaussagen ein schwarzes Loch und deshalb unsicher. Es wird gezielt auf Verharmlosung und einem Sorglos-Paket als Verkaufsargument gesetzt. Bei genauer Betrachtung der Entwicklung der Internetkriminalität mit Keylogger, Viren und Trojaner zeigen deutlich, dass auch AVM mit einem sehr hohen Marktanteil bei den Routern nichts wirlich Gutes dagegen zu setzen hat.

Wenn die Fritzbox so gut wäre, wieso kaufen wohl Firmen dann dedizierte Firewalls, Proxyserver, IDS Systeme etc, statt jeder Abteilung eine billige Fritzbox zu spendieren?

Die Frage ist doch, wie gut will man sich schützen. Man benutzt ja auch Kondome, und wenn nicht, dann riskiert man eben die Folgen.

 

[SaschaBr]

... Bei genauer Betrachtung der Entwicklung der Internetkriminalität mit Keylogger, Viren und Trojaner zeigen deutlich, dass auch AVM mit einem sehr hohen Marktanteil bei den Routern nichts wirlich Gutes dagegen zu setzen hat. ...

Genau deswegen hatte ich mich auch mal mit iptables auf meiner 7270v2 versucht. Diese Firewall bietet bei richtiger Konfiguration ja deutlich mehr Schutz. Leider hat mich das WebIF mit der Vielzahl der einstellbaren Parameter und Konfigurationszeilen überfordert. Auch hatte ich (vermutlich durch Fehlbedienung) mehrfach spotane Neustarts der Box, weswegen ich schlussendlich ersteinmal aufgegeben habe.

Was ich aber eigentlich sagen wollte:
Die Box ist und bleibt eben ein Heim-Router, der auch durch unbedachte User konfiguriert werden können muss. Und aus diesem Grunde glaube ich, dass AVM das bewusst einfach gehalten hat. Wie das dann alles mit IPv6 aussieht, damit habe ich mich allerdings nur insoweit beschäftigt, als das ich es deaktiviert habe.

 

[RalfFriedl]

Bei genauer Betrachtung der Entwicklung der Internetkriminalität mit Keylogger, Viren und Trojaner zeigen deutlich, dass auch AVM mit einem sehr hohen Marktanteil bei den Routern nichts wirlich Gutes dagegen zu setzen hat.

Bei genauer Betrachtung der Funktionsweise eines Routers zeigt sich deutlich, dass ein Router nichts gegen Keylogger, Viren und Trojaner tun kann. Oder soll jetzt ein ausgewachsener Virenscanner auf der Box laufen? Damit wäre die Box sicher endgültig überfordert.

 

[quantive]

Das ist richtig, dass eine SPI Firewall schon lange nicht mehr reicht und für ein Profieinsatz nicht geeignet ist.
Das mit der Malware ist eine Sache, die andere ist, dass ich in meinem LAN arbeiten möchte und nicht weltweit. Die chance meine IPv6 zu ermitteln ist bei der Anzahl der Hosts im Subnetzt zwar gering, aber doch möglich, also muss eine Firewall her.
Dann kommt noch der Preis hinzu. 180¤ für eine FB geht gerade noch, eine UTM-Appliance kostet 1000¤ und viel mehr.
SaschaBr hat es schon gesagt, konfigurieren muss man die Sache auch noch und verwalten und bewerten.

Wenn ich Malware abhalten möchte und 1000¤ habe, dann nehme ich z.B. eine UTM-Firewall wie in der SonicWall TZ 210 mit ipv6 Unterstürzung.

Ich greife wahrscheinlich vieles von oben auf, aber jetzt aber zu ar7.cfg:

Ich denke lowinput, lowoutput, highinput und highoutput sind Stufen der Firewall und dazwischen, metaphorisch natürlich, werden die Tunnel aufgebaut, denke ich. Zum Beispiel,
um IPv6-Pakete über IPv4 zu transportieren. Also
Internet -> lowinput | lowoutput <- Zwischestufe -> highinput | highoutput <- LAN (-> und <- Richtung der Pakete).

Wo sind aber die Regeln für natives IPv6?

Accessliste aus dslifaces "internet"-Teil:

                        dsldpconfig {
                        security = dpsec_firewall;
                        filter_teredo = yes;
                        filter_netbios = yes;
[B][COLOR="red"]Aus Internet[/COLOR][/B]            lowinput {
                                policy = "permit";
                                accesslist = 
                                             "deny ip any 242.0.0.0 255.0.0.0", 
                                             "deny ip any host 255.255.255.255";
                        }
                        lowoutput {
                                policy = "permit";
                        }
                        highinput {
                                policy = "permit";
                        }
[B][COLOR="red"]Richtung Internet[/COLOR][/B]       highoutput {
                                policy = "permit";
                                accesslist = 
                                             "reject ip any 242.0.0.0 255.0.0.0", 
                                             "deny ip any host 255.255.255.255", 
                                             "reject ip any 169.254.0.0 255.255.0.0";
                        }
                }

Sieht aber übersichtlich aus, die Accessliste.

Nachtrag, keine Änderung:
"...Bei IPv6 ist das nicht mehr nötig, da keine Adressübersetzung mehr stattfindet und damit einer direkten bidirektionalen Kommunikation nichts mehr im Wege steht. Hier ist der einzige Schutz die PC Firewall, die Fritzbox ist dann nur noch ein einfacher Router..."

Die policy oben besagt, immer alles durchlassen, wenn keine Regel greift. Wie ist das zu vereinbaren mit http://www.avm.de/de/Service/FAQs/FAQ_Sammlung/15670.php3. Das steht auch im Frontend der FB unter "Freigaben" -> "IPv6"? Ist der Teil hard-coded?
Das "Jeder, der Werbesprüche vertraut ist selbst Schuld." reicht mir nicht.
Ich spreche hier vom von der FB getunnelten IPv6 Datenverkehr und vom nativen IPv6 Datenverkehr.

 

[quantive]

Also ich würde gerne für mich abschließen (bis auf eine Sache, UDP).
Alle IPv6 TCP Ports, die ich getestet habe, werden tatsächlich geblockt aber auch durch IPv6 Freigaben einfach zum gewünschten PC (Interface Identifier) weiter geleitet, entweder zur globalen oder zur temporären ID. Also mir reicht das und ich kann die paar Regeln, die ich vielleicht benötige auch von Hand nachtragen. Es fehlt aber wirklich eine anständige Oberfläche und eine Protokolldatei. Wäre ein sinnvoller Vorschlag an AVM.

Um die Ports zu testen muss man aber noch die Windows-Firewall deaktivieren oder über die erweiterten Einstellungen gehen, wahrscheinlich über die Edgeausnahme.
Getestet habe ich es am Port 135, 445, 49270 über die Seite http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-port-scanner.php
Dort kann man die Host-IPv6 eingeben.