AVM-Firewall package für Freetz
- Ersteller han-solo
- Erstellt am
hermann72pb
IPPF-Promi
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
@dj1985: Ich würde sehr stark tippen, dass "eq" für "equivalent" steht und "gleich" heißt. Wird wahrscheinlich benutzt, wenn man nur einen Port definiert. "range" bedeutet wiederum in diesem Fall "Portbereich" und definiert vermutlich mehrere nacheinander folgende Ports.
Zum Rest kann ich dir leider wenig sagen, warte bis einer der Entwickler sich meldet.
MfG
Zum Rest kann ich dir leider wenig sagen, warte bis einer der Entwickler sich meldet.
MfG
Das sollte nicht sein, irgendwie scheind das zugehörige Skript zur FW da einmal mit falschem Parameter aufgerufen zu werden.
Ich sehe mir das mal an, ebenso wie die "abweichenden" Defaultwerte. Geht aber im Moment nicht, weil ich momentan unterwegs bin.
Wenn du vorher definitiv nur die ersten Regeln drin hattest, könntest du die anderen natürlich löschen. Aber in der Regel sollte die Box auch so ohne Probleme laufen...
Jörg
Naja bis jetzt habe ich die neuen werte noch nicht übernommen, somit sind sie nach nen neustart wieder weg...
Wollte nur mal wissen ob es ratsam ist diese Regel richtig zu aktivieren (aus Sicherheitsgründen) oder ob ich mich da irgendwo aussperre, wenn ich die Aktiviere.
Wollte nur mal wissen ob es ratsam ist diese Regel richtig zu aktivieren (aus Sicherheitsgründen) oder ob ich mich da irgendwo aussperre, wenn ich die Aktiviere.
Das gleiche "Problem" war bei mir auch, inklusive der Fehlermeldung. Probleme habe ich bisher keine. Er lädt doch trotz allem nur die Standardeinträge, die in der FW stehen in die GUI.
Zumindest sind das die Einträge, die sich auch von Anfang an in der ar7 finden, daher habe ich ich mir da nicht sonderlich viele Gedanken drum gemacht um ehrlich zu sein. :-/
Sagt mal, weiß hier einer wie ich die Firewall für passiv FTP konfigurieren muss? Ausgehend alle Ports von 1024-65535 öffnen läuft zwar, ist aber irgendwie keine Lösung. PFsense bietet dazu z.B. einen FTP Helper, der das ermöglicht. IPtables kann es über conntrack_ftp.
Kann man der AVM Firewall auch irgendwie beibringen passiv FTP zu erlauben ohne alle Portbereiche dafür auf zu reißen? Also eben der Firewall zu sagen, dass sie die Pakete der vorherigen FTP Verbindung über Port 21 zuordnen soll und es daher "erlaubt" ist. Oder ist die Firewall dazu "zu blöd"?
Zumindest sind das die Einträge, die sich auch von Anfang an in der ar7 finden, daher habe ich ich mir da nicht sonderlich viele Gedanken drum gemacht um ehrlich zu sein. :-/
Sagt mal, weiß hier einer wie ich die Firewall für passiv FTP konfigurieren muss? Ausgehend alle Ports von 1024-65535 öffnen läuft zwar, ist aber irgendwie keine Lösung. PFsense bietet dazu z.B. einen FTP Helper, der das ermöglicht. IPtables kann es über conntrack_ftp.
Kann man der AVM Firewall auch irgendwie beibringen passiv FTP zu erlauben ohne alle Portbereiche dafür auf zu reißen? Also eben der Firewall zu sagen, dass sie die Pakete der vorherigen FTP Verbindung über Port 21 zuordnen soll und es daher "erlaubt" ist. Oder ist die Firewall dazu "zu blöd"?
Die AVM-Firewall ist aus meiner Sicht für "komplexe Regeln" nicht wirklich geeignet. Wie "statefull" die ist und in wiefern komplexere Protokolle darin abgebildet sind, weiß vermutlich nur AVM...
Jörg
Jörg
Ach Schei....benkleister! 
Trotz allem Danke für deine Rückmeldung.
Iptables mit conntrack kann ich auf einem W701V@7170 ja vergessen, laut den Infos, die man sich per google so zusammen suchen kann. Oder läuft das mit Tricks irgendwie stabil?
Eigentlich reicht die AVM Firewall für mein Anliegen aus. Mein einziges Problem sind aktuell eben ausgehende FTP Verbindungen. Hast du vielleicht ne Idee was ich da noch versuchen könnte?
Btw, 2 kleinere Fragen am Rande. Das sind keine wirklichen Probleme, aber es zu lösen wäre trotzdem schön. Die Fritzbox selbst frägt ja über UDP 123 (NTP) die Zeit ab. Wie kann ich UDP/123 ausgehend nur für die Fritzbox erlauben? Aktuell habe ich eben any/any, da ich nicht weiß welcher "host" ich für die Box selbst angeben muss. 0.0.0.0 / Fritzbox LAN IP usw. funktioniert nicht.
Eingehend das gleiche Spiel. Aktuell any/any für 2 offene Ports. Mich würde interessieren was ich eintragen muss damit diese "nur" (machen sie im Endeffekt auch so, aber ...) zum NAT gehen.
Trotz allem Danke für deine Rückmeldung.Iptables mit conntrack kann ich auf einem W701V@7170 ja vergessen, laut den Infos, die man sich per google so zusammen suchen kann. Oder läuft das mit Tricks irgendwie stabil?
Eigentlich reicht die AVM Firewall für mein Anliegen aus. Mein einziges Problem sind aktuell eben ausgehende FTP Verbindungen. Hast du vielleicht ne Idee was ich da noch versuchen könnte?
Btw, 2 kleinere Fragen am Rande. Das sind keine wirklichen Probleme, aber es zu lösen wäre trotzdem schön.
Die Fritzbox selbst frägt ja über UDP 123 (NTP) die Zeit ab. Wie kann ich UDP/123 ausgehend nur für die Fritzbox erlauben? Aktuell habe ich eben any/any, da ich nicht weiß welcher "host" ich für die Box selbst angeben muss. 0.0.0.0 / Fritzbox LAN IP usw. funktioniert nicht.Eingehend das gleiche Spiel. Aktuell any/any für 2 offene Ports. Mich würde interessieren was ich eintragen muss damit diese "nur" (machen sie im Endeffekt auch so, aber ...) zum NAT gehen.
cando
Aktives Mitglied
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Hallo RAMler,
vielen ank auch für die PN Anfrage. Ich versuche es mal hier im Forum zu beantworten, da es wahrscheinlich auch andere interessiert.
Die connection incomming-related und outgoing-related Regeln haben nichts mit NAT zu tun sondern mit einer Mimik, die "CONNTRACK" entspricht. es ist richtig, dass AVM da keine Einschränkungen auf Adressen, Protokolle und Ports zuläßt. Der Grund dafür sind die komplexeren Protokolle, die z.B. über tcp eine Verbindung aufbauen und dann über udp Datenpakete die Daten austauschen, dynamische Portbereiche verwenden etc. Die Box "erkennt" das Protokoll und öffnet bei Bedarf die Ports. Diese Regeln betreffen immer den Rückkanal einer Verbindung. Um die Verbindung zu steuern genügt es, den Hin-Kanal zu erlauben oder zu verbieten. Damit kannst Du z.B. gezielt ausgehende Verbindungen zu bestimmten Adressen blocken, auch wenn der Rückkanal dafür scheinbar offen ist - es werden keine Daten von diesen Adressen akzeptiert, da es ja keine passende ausgehende Verbindung gibt.
Die Firewall Regeln werden der Reihe nach abgearbeitet, bei einem Treffer werden nachfolgende Regeln ignoriert. Damit kann man z.B. mit einer Deny Regel ein Adressbereich z.B. für tcp sperren und in einer Folge Regel tcp für any erlauben mit der Wirkung, dass der tcp Verkehr zu allen Hosts, ausser den oben gesperrten - funktioniert.
Damit lassen sich auch dedizierte Regeln für den Rückkanal definieren, wenn sie vor den Conntrack Regeln stehen.
Das NAT ist eine ganz andere Geschichte. Wenn die Fritzbox im NAT Modus läuft, verhält sie sich wie ein transparenter Proxy für alle abgehender Protokolle. Sie baut die Verbindung zum Zielrechner im Internet mit ihrer externen IP-Adresse auf und schreibt in einer internen Tabelle von welcher Aderesse / Port / Protokoll im LAN die Anfrage zu dieser Verbindung kam. Wenn die Antwort an der Box ankommt, wird sie dann an den Rechner im LAN weitergeleitet.
Ausgehend:
LAN -> FritzLAN -> highoutput - NAT -> FritzWAN -> Internet
Rückweg:
Internet -> FritzWAN -> NAT -> lowinput -> FritzLAN -> LAN
Wie Du siehst, wird der jeweilige Zweig der Firewall immer durchlaufen, so dass man den Verkehr in beiden Richtungen kontrollieren kann.
Bei Portfreigaben werden statische Einträge in die oben genannte NAT Tabelle angelegt, die dafür sorgen, dass von Außen ankommende Pakete zum Verbindungsaufbau auf bestimmten Ports an der Fritzbox immer zu einer festen ip-Adresse im LAN weitergeleitet werden. Der Rückkanal kann dann z.B. mit einer conntrack Regel (connection incomming-related) im highuotput Zweig erlaubt werden. Beim AVM Standartregelsatz ist das nicht nötig, da outgoing alles erlaubt wird (bis auf NetBIOS).
Man kann die Rückkanäle auch mit normalen Regeln öffnen, conntrack ist aber eleganter, da nur dann eine Rück-Verbindung zugelassen wird, wenn zuvor eine Anfrage in die Gegenrichtung erfolgreich stattfand. Die Firewall ist sonst für alle anderen Anfragen auf dem selben Protokoll / Port gesperrt (wenn man sie so einstellt z.B. durch eine nachfolgende Deny-Regel oder einer default policy: Deny für den Zweig).
Das Hauptproblem bei der AVM Firewall ist, dass man kein Log bekommt, was an Paketen verworfen oder durchgelassen wird, so dass sich sowohl das Testen der Regeln als auch die Überwachung des Verkehrs schwieriger gestaltet. Man sieht ja nicht, was da alles an Verbindungen im Hintergrund aufgebaut werden und wozu sie dienen.
iptables funktioniert übrigens auch auf der 7170, nur die conntrack Regeln sind mit Vorsicht zu geniessen. Man kann aber mit Hilfe von iptables recht gut als Ergänzung zur AVM Firewall abgehende Verbindungen überwachen und protokollieren - auch ohne conntrack (z.B. durch Rückregel per default alles erlauben - AVM Firewall Conntrack kümmert sich ja um das Filtern). Außerdem unterscheidet iptables zwischen Verkehr von/zur Box (INPUT / OUTPUT chain) und Durchgangsverkehr zum LAN (FORWARD chain), so dass man hier sehr genau steuern kann was die Box darf und was nur für das LAN bestimmt ist.
Du wärst überrascht, wie viele Verbindungen Deine Geräte unaufgefordert ins Internet aufbauen...
IPv4 lässt sich mit der AVM Firewall einigermassen gut steuern, viel schwieriger wird es mit IPv6 und den vielen IPv6 Tunnel Protokollen. Die Verbindungs- Protokoll- und Nutzdaten werden da in "normale" tcp oder udp Pakete versteckt, um die Firewalls mehr oder weniger erfolgreich auszutricksen. Es gibt Protokolle, die verwenden z.B. tcp Port 80 (das normale WWW Protokoll) um IPv6 Verkehr zu tunneln, was sogar durch Proxies hindurch funktioniert, es gibt ISATAP, TEREDO, 6to4, 6in4, SixxS etc. die allesamt dafür gebaut wurden, um sich der Kontrolle durch sorglose / ahnungslose Admins zu entziehen und IPv6 zum Durchbruch zu verhelfen. Die OS Hersteller sitzen mit im Boot (Linux genauso wie Microsoft), sie installieren und schalten standardmäßig IPv6 frei, wenn kein IPv6 Router vorhanden ist, werden automatisch die Tunnelprotokolle aktiviert. MS geht sogar noch weiter und erlaubt es Applikationen trotz existierender ipv6 Verbindung dediziert TEREDO, 6to4 oder ISATAP Tunnel aufzubauen (mal im Internet danach googeln) was den Firewall Admins so alles graue Haare beschert.
vielen ank auch für die PN Anfrage. Ich versuche es mal hier im Forum zu beantworten, da es wahrscheinlich auch andere interessiert.
Die connection incomming-related und outgoing-related Regeln haben nichts mit NAT zu tun sondern mit einer Mimik, die "CONNTRACK" entspricht. es ist richtig, dass AVM da keine Einschränkungen auf Adressen, Protokolle und Ports zuläßt. Der Grund dafür sind die komplexeren Protokolle, die z.B. über tcp eine Verbindung aufbauen und dann über udp Datenpakete die Daten austauschen, dynamische Portbereiche verwenden etc. Die Box "erkennt" das Protokoll und öffnet bei Bedarf die Ports. Diese Regeln betreffen immer den Rückkanal einer Verbindung. Um die Verbindung zu steuern genügt es, den Hin-Kanal zu erlauben oder zu verbieten. Damit kannst Du z.B. gezielt ausgehende Verbindungen zu bestimmten Adressen blocken, auch wenn der Rückkanal dafür scheinbar offen ist - es werden keine Daten von diesen Adressen akzeptiert, da es ja keine passende ausgehende Verbindung gibt.
Die Firewall Regeln werden der Reihe nach abgearbeitet, bei einem Treffer werden nachfolgende Regeln ignoriert. Damit kann man z.B. mit einer Deny Regel ein Adressbereich z.B. für tcp sperren und in einer Folge Regel tcp für any erlauben mit der Wirkung, dass der tcp Verkehr zu allen Hosts, ausser den oben gesperrten - funktioniert.
Damit lassen sich auch dedizierte Regeln für den Rückkanal definieren, wenn sie vor den Conntrack Regeln stehen.
Das NAT ist eine ganz andere Geschichte. Wenn die Fritzbox im NAT Modus läuft, verhält sie sich wie ein transparenter Proxy für alle abgehender Protokolle. Sie baut die Verbindung zum Zielrechner im Internet mit ihrer externen IP-Adresse auf und schreibt in einer internen Tabelle von welcher Aderesse / Port / Protokoll im LAN die Anfrage zu dieser Verbindung kam. Wenn die Antwort an der Box ankommt, wird sie dann an den Rechner im LAN weitergeleitet.
Ausgehend:
LAN -> FritzLAN -> highoutput - NAT -> FritzWAN -> Internet
Rückweg:
Internet -> FritzWAN -> NAT -> lowinput -> FritzLAN -> LAN
Wie Du siehst, wird der jeweilige Zweig der Firewall immer durchlaufen, so dass man den Verkehr in beiden Richtungen kontrollieren kann.
Bei Portfreigaben werden statische Einträge in die oben genannte NAT Tabelle angelegt, die dafür sorgen, dass von Außen ankommende Pakete zum Verbindungsaufbau auf bestimmten Ports an der Fritzbox immer zu einer festen ip-Adresse im LAN weitergeleitet werden. Der Rückkanal kann dann z.B. mit einer conntrack Regel (connection incomming-related) im highuotput Zweig erlaubt werden. Beim AVM Standartregelsatz ist das nicht nötig, da outgoing alles erlaubt wird (bis auf NetBIOS).
Man kann die Rückkanäle auch mit normalen Regeln öffnen, conntrack ist aber eleganter, da nur dann eine Rück-Verbindung zugelassen wird, wenn zuvor eine Anfrage in die Gegenrichtung erfolgreich stattfand. Die Firewall ist sonst für alle anderen Anfragen auf dem selben Protokoll / Port gesperrt (wenn man sie so einstellt z.B. durch eine nachfolgende Deny-Regel oder einer default policy: Deny für den Zweig).
Das Hauptproblem bei der AVM Firewall ist, dass man kein Log bekommt, was an Paketen verworfen oder durchgelassen wird, so dass sich sowohl das Testen der Regeln als auch die Überwachung des Verkehrs schwieriger gestaltet. Man sieht ja nicht, was da alles an Verbindungen im Hintergrund aufgebaut werden und wozu sie dienen.
iptables funktioniert übrigens auch auf der 7170, nur die conntrack Regeln sind mit Vorsicht zu geniessen. Man kann aber mit Hilfe von iptables recht gut als Ergänzung zur AVM Firewall abgehende Verbindungen überwachen und protokollieren - auch ohne conntrack (z.B. durch Rückregel per default alles erlauben - AVM Firewall Conntrack kümmert sich ja um das Filtern). Außerdem unterscheidet iptables zwischen Verkehr von/zur Box (INPUT / OUTPUT chain) und Durchgangsverkehr zum LAN (FORWARD chain), so dass man hier sehr genau steuern kann was die Box darf und was nur für das LAN bestimmt ist.
Du wärst überrascht, wie viele Verbindungen Deine Geräte unaufgefordert ins Internet aufbauen...
IPv4 lässt sich mit der AVM Firewall einigermassen gut steuern, viel schwieriger wird es mit IPv6 und den vielen IPv6 Tunnel Protokollen. Die Verbindungs- Protokoll- und Nutzdaten werden da in "normale" tcp oder udp Pakete versteckt, um die Firewalls mehr oder weniger erfolgreich auszutricksen. Es gibt Protokolle, die verwenden z.B. tcp Port 80 (das normale WWW Protokoll) um IPv6 Verkehr zu tunneln, was sogar durch Proxies hindurch funktioniert, es gibt ISATAP, TEREDO, 6to4, 6in4, SixxS etc. die allesamt dafür gebaut wurden, um sich der Kontrolle durch sorglose / ahnungslose Admins zu entziehen und IPv6 zum Durchbruch zu verhelfen. Die OS Hersteller sitzen mit im Boot (Linux genauso wie Microsoft), sie installieren und schalten standardmäßig IPv6 frei, wenn kein IPv6 Router vorhanden ist, werden automatisch die Tunnelprotokolle aktiviert. MS geht sogar noch weiter und erlaubt es Applikationen trotz existierender ipv6 Verbindung dediziert TEREDO, 6to4 oder ISATAP Tunnel aufzubauen (mal im Internet danach googeln) was den Firewall Admins so alles graue Haare beschert.
Zuletzt bearbeitet:
Erst einmal Danke für die sehr ausführliche Antwort.
Ich glaube du hattest mich etwas missverstanden. Das die related Regeln nichts mit dem NAT zu tun haben, ist mir natürlich bewusst.
Es ging um folgendes:
- Whitelist Betrieb "outgoing-related" bei lowinput und "incoming-related" bei highoutgoing um den "stateful" Betrieb zu ermöglichen
Wenn ich jetzt z.B. 2 Portweiterleitungen im NAT setze (es laufen eben 2 Dienste auf Rechner X, die man von außen erreichen sollte), muss ich diese 2 Ports natürlich auch unter "lowinput" öffnen. Dort _muss_ ich den Port aber für "Ziel any" öffnen, sonst funktioniert das ganze nicht. Gebe ich als Ziel direkt den gewünschten Rechner an, so kommt dort schlicht weg nichts an und bei nem Portscan wird der Port als "gefiltert" gemeldet.
Daher war auch meine Vermutung:
Eingehend:
Internet -> FritzWAN -> lowinput -> NAT -> FritzLAN -> LAN
So das die Firewall durch das Ziel "any" das Paket (auch) an den NAT weiterreicht. Kann natürlich totaler Quark sein, aber anders kann ich mir das Verhalten nicht erklären. Vielleicht hast du ja ne Idee und/oder könntest das mal bei die gegentesten (sofern Lust da ist).
Zwecks iptables:
Da liegt ja mein Problem. Das Conntrack FTP Modul, das mir passiv FTP ermöglich würde ohne den ganzen high-port Bereich ausgehend aufzureisen, dürfte wohl auf meiner 7170 nicht vernünftig laufen.
Aktuell tut es ja nicht einmal die freetz FW mit AVM FW GUI. Die Box startet einfach ab und zu neu, daher erstelle ich gerade ein Alien Image mit dem letzten freetz trunk.
Zwecks IPv6 -> Kann hier kein einziger Client - bis jetzt. Die Fritzbox bietet doch eigentlich gar keine IPv6 Unterstützung oder? (Davon gehe ich aus, da man diese per Freetz nachrüsten kann.)
Ich glaube du hattest mich etwas missverstanden. Das die related Regeln nichts mit dem NAT zu tun haben, ist mir natürlich bewusst.
Es ging um folgendes:
- Whitelist Betrieb "outgoing-related" bei lowinput und "incoming-related" bei highoutgoing um den "stateful" Betrieb zu ermöglichen
Wenn ich jetzt z.B. 2 Portweiterleitungen im NAT setze (es laufen eben 2 Dienste auf Rechner X, die man von außen erreichen sollte), muss ich diese 2 Ports natürlich auch unter "lowinput" öffnen. Dort _muss_ ich den Port aber für "Ziel any" öffnen, sonst funktioniert das ganze nicht. Gebe ich als Ziel direkt den gewünschten Rechner an, so kommt dort schlicht weg nichts an und bei nem Portscan wird der Port als "gefiltert" gemeldet.
Daher war auch meine Vermutung:
Eingehend:
Internet -> FritzWAN -> lowinput -> NAT -> FritzLAN -> LAN
So das die Firewall durch das Ziel "any" das Paket (auch) an den NAT weiterreicht. Kann natürlich totaler Quark sein, aber anders kann ich mir das Verhalten nicht erklären. Vielleicht hast du ja ne Idee und/oder könntest das mal bei die gegentesten (sofern Lust da ist).
Schön wärs - für passiv FTP (ausgehend) ist die Firewall ja leider zu blöd. *g* Das erkennt sie nicht und sperrt den benötigten high port (Port P, den der Server nach PASV Befehl an den Client liefert und auf den der Client dann connecten möchte). Dafür such ich immer noch ne Lösung. Vielleicht kann sie es ja doch, irgendwie. :-/
Zwecks iptables:
Da liegt ja mein Problem. Das Conntrack FTP Modul, das mir passiv FTP ermöglich würde ohne den ganzen high-port Bereich ausgehend aufzureisen, dürfte wohl auf meiner 7170 nicht vernünftig laufen.
Aktuell tut es ja nicht einmal die freetz FW mit AVM FW GUI. Die Box startet einfach ab und zu neu, daher erstelle ich gerade ein Alien Image mit dem letzten freetz trunk.
Zwecks IPv6 -> Kann hier kein einziger Client - bis jetzt. Die Fritzbox bietet doch eigentlich gar keine IPv6 Unterstützung oder? (Davon gehe ich aus, da man diese per Freetz nachrüsten kann.)
Zuletzt bearbeitet:
Mal eine Frage zwischendurch...
Warum muss eigentlich die Internetverbindung getrennt werden bzw die Anlage neugestartet werden um die Forwardings und so zu aktivieren?
AVM schafft das ja auch irgendwie Forwardings zu aktivieren ohne die Verbindung neu aufzubauen...
Warum muss eigentlich die Internetverbindung getrennt werden bzw die Anlage neugestartet werden um die Forwardings und so zu aktivieren?
AVM schafft das ja auch irgendwie Forwardings zu aktivieren ohne die Verbindung neu aufzubauen...
olistudent
IPPF-Urgestein
- Mitglied seit
- 19 Okt 2004
- Beiträge
- 14,787
- Punkte für Reaktionen
- 13
- Punkte
- 38
Wir hatten es eingebaut und ich hab es wieder entfernt. Da gibts ein Ticket zu und Patches von MaxMuster.
MfG Oliver
MfG Oliver
Das ist letztlich ein "Kompromiss" ;-)
Wenn nur die Forwardings geändert wurden, müsste zum übernehmen nur der dsld per Signal "HUP" darüber informiert werden, dann würden die neuen Regeln greifen. Zusätzlich muss noch der ctlmgr neu gestartet werden, damit auch der über die neuen Regeln weiß, sonst wird eine Änderung im AVM Webfrontend die hier gemachten Änderungen wieder verwerfen und überschreiben.
Werden die Firewall-Regeln verändert, was AVM selbst nicht vorsieht (im Gegensatz zu den änderbaren Forwardings), muss der dsld neu komplett gestartet werden.
Vielleicht gibt es tatsächlich Mechanismen, wie man das gleiche auch anders erreichen kann, aber solange wir die nicht kennen, sehe ich keine Alternative.
Du kannst aber auch gern die Version aus dem Trunk vor Revision 4544 auschecken, dort kannst du alle diese Optionen einzeln wählen, und z.B. Forwardings ohne Neustart des dsld anwenden (ob der dsld bei einem "HUP" z.B. eine neue IP zieht, weiß ich nicht).
Jörg
cando
Aktives Mitglied
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Hallo RAMler,
für Inbound Traffic ist das richtig. Du musst ja den Verkehr von außen auf die Box selbst für die freigegebenen Ports zulassen, die dann in das LAN weitergeleitet werden. Da Deine Box eine dynamische IP Adresse aus dem Internet vom Provider bekommt, kannst Du keine feste eintragen insofern sind 2 Regeln hilfreich:
lowinput:
permit (tcp | udp | ip) any any eq (port) /* erlaubt Eingangsverkehr aus Internet
highoutput
permit (tcp | udp | ip) any (zielrechner) eq (port) /* erlaubt verkehr Firewall zum LAN-Rechner
block (tcp | udp | ip) any (LAN-Segment/24) eq (port) /* sperrt port für alle anderen Rechner im LAN
Im übrigen ist das nicht wirklich nötig, da durch die NAT Regel (Portweiterleitung) der Verkehr immer zu der angegebenen Adresse geleitet wird und die anderen Rechner nicht addressiert werden. Aber so könnte man es machen.
AVM hat das zu sehr vereinfacht, so dass man das Regelwerk und seine Wirkungsweise nicht wirklich durchsteigt.
Ich vermute mal, dass die AVM Firewall etwas an iptables angelehnt ist und die Regeln in alle passenden Filter eingetragen werden.
deswegen lässt sie ja auch Quelle und Ziel sowohl in lowinput als auch in highoutput zu.
Normalerweise ist eine logische Filteranordnung mit NAT / Routing so : (Siehe Anlage)
Ein INPUT Filter hat keine sinnvolle Zieladresse, ein OUTPUT Filter keine sinnvolle Quelle, für FORWARD ist Quelle und Ziel nützlich etc.
Ich vermute, AVM interpretiert die Regelliste und setzt intern die nötigen Filter und Routing Informationen an der richtigen Stelle.
lowinput und highoutput ist nicht identisch / vergleichbar mit INPUT und OUTPUT bei iptables (Sie enthalten auch den FORWARD Traffic) und ist auch nicht gleichzusetzen mit den WAN bzw. LAN Interfaces...
für Inbound Traffic ist das richtig. Du musst ja den Verkehr von außen auf die Box selbst für die freigegebenen Ports zulassen, die dann in das LAN weitergeleitet werden. Da Deine Box eine dynamische IP Adresse aus dem Internet vom Provider bekommt, kannst Du keine feste eintragen insofern sind 2 Regeln hilfreich:
lowinput:
permit (tcp | udp | ip) any any eq (port) /* erlaubt Eingangsverkehr aus Internet
highoutput
permit (tcp | udp | ip) any (zielrechner) eq (port) /* erlaubt verkehr Firewall zum LAN-Rechner
block (tcp | udp | ip) any (LAN-Segment/24) eq (port) /* sperrt port für alle anderen Rechner im LAN
Im übrigen ist das nicht wirklich nötig, da durch die NAT Regel (Portweiterleitung) der Verkehr immer zu der angegebenen Adresse geleitet wird und die anderen Rechner nicht addressiert werden. Aber so könnte man es machen.
AVM hat das zu sehr vereinfacht, so dass man das Regelwerk und seine Wirkungsweise nicht wirklich durchsteigt.
Ich vermute mal, dass die AVM Firewall etwas an iptables angelehnt ist und die Regeln in alle passenden Filter eingetragen werden.
deswegen lässt sie ja auch Quelle und Ziel sowohl in lowinput als auch in highoutput zu.
Normalerweise ist eine logische Filteranordnung mit NAT / Routing so : (Siehe Anlage)
Ein INPUT Filter hat keine sinnvolle Zieladresse, ein OUTPUT Filter keine sinnvolle Quelle, für FORWARD ist Quelle und Ziel nützlich etc.
Ich vermute, AVM interpretiert die Regelliste und setzt intern die nötigen Filter und Routing Informationen an der richtigen Stelle.
lowinput und highoutput ist nicht identisch / vergleichbar mit INPUT und OUTPUT bei iptables (Sie enthalten auch den FORWARD Traffic) und ist auch nicht gleichzusetzen mit den WAN bzw. LAN Interfaces...
Anhänge
Zuletzt bearbeitet:
Guten Morgen cando,
irgendwie reden wir etwas aneinander vorbei. :-D
Die Standardregeln sitzen bei mir auf "deny", also muss ich bei "lowinput" die besagten 2 Ports von Hand any/any freigeben, sonst kommt da (trotz Portweiterleitung beim NAT) nichts rein/an. So weit so klar.
Du hast geschrieben:
Eingehend:
Internet -> FritzWAN -> NAT -> lowinput -> FritzLAN -> LAN
Wäre dem so, müsste ich ja eigentlich unter "lowinput" auch "permit (tcp/udp) any (zielrechner) eq (port)" eintragen können. Tut man das aber, kommt nichts an.
Ich denke daher das ganze läuft wie folgt:
Internet -> FritzWAN -> lowinput -> NAT -> FritzLAN -> LAN
War mehr Theorie, als Praxis. Rein um die Funktionen besser zu verstehen.
PS
Die Box frägt ja über UDP 123 die Zeit ab. Nun muss ich ausgehend aber "permit udp any any eq 123" freigeben, damit die Box dies auch nutzen kann. Weist du was ich dort eintragen müsste, damit nur die box den NTP Port nutzen kann?
Ich dachte es würde an der dynamischen IP Adresse liegen, aber mit einem 87.0.0.0 255.0.0.0 wurde das auch nichts. (Im 87. Bereich wird mir ne IP zugewiesen.) Mit 0.0.0.0 ebenfalls ein Schlag ins Wasser. :-/
irgendwie reden wir etwas aneinander vorbei. :-D
Die Standardregeln sitzen bei mir auf "deny", also muss ich bei "lowinput" die besagten 2 Ports von Hand any/any freigeben, sonst kommt da (trotz Portweiterleitung beim NAT) nichts rein/an. So weit so klar.
Du hast geschrieben:
Eingehend:
Internet -> FritzWAN -> NAT -> lowinput -> FritzLAN -> LAN
Wäre dem so, müsste ich ja eigentlich unter "lowinput" auch "permit (tcp/udp) any (zielrechner) eq (port)" eintragen können. Tut man das aber, kommt nichts an.
Ich denke daher das ganze läuft wie folgt:
Internet -> FritzWAN -> lowinput -> NAT -> FritzLAN -> LAN
War mehr Theorie, als Praxis. Rein um die Funktionen besser zu verstehen.
PS
Die Box frägt ja über UDP 123 die Zeit ab. Nun muss ich ausgehend aber "permit udp any any eq 123" freigeben, damit die Box dies auch nutzen kann. Weist du was ich dort eintragen müsste, damit nur die box den NTP Port nutzen kann?
Ich dachte es würde an der dynamischen IP Adresse liegen, aber mit einem 87.0.0.0 255.0.0.0 wurde das auch nichts. (Im 87. Bereich wird mir ne IP zugewiesen.) Mit 0.0.0.0 ebenfalls ein Schlag ins Wasser. :-/
cando
Aktives Mitglied
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Die Box verwendet für eigenen ausgehenden Verkehr ins Internet eine Adresse aus dem internen Segment 169.254.0.0/16 (169.254.2.1 oder 169.254.2.2 = DSL Interface) für dns und ntp Anfragen (ermittelt mit Hilfe von iptables log), die dann ge-NAT-tet werden.
Übrigens, die AVM Firewall hat noch 2 weitere Filter: lowoutput und highinput, die über das UI nicht zugänglich sind und immer auf PERMIT stehen. Wenn man das Filterwerk von AVM komplett verstehen will, müsste man die zwei Filter mit betrachten. Für normale Anwender genügen aber die lowinput und highoutput Filter - eigentlich sind da schon die meisten damit überfordert. AVM benutzt die Firewall ja auch nur sehr rudimentär um NBT und Broadcast Verkehr ins Internet zu sperren, sonst tut sie ja in der AVM Einstellung nichts sinnvolles (Alle Zweige stehen auf PERMIT).
----------
Ich habe meinen Beitrag etwas ergänzt.
Ich glaube es ist eher so:
Quelle -> lowinput -> NAT / ROUTING -> highoutput -> Ziel
wobei Quelle und Ziel jedes Interface sein kann (WAN -> BOX, WAN -> LAN, LAN -> WAN, WAN -> DMZ, ...).
Man kann mit lowinput und highoutput auch DMZ Regeln von LAN zu LAN erstellen. Man kann auch nur mit highoutput in allen Richtungen filtern, wenn man Quelle und Ziel angibt, ich vermute bei lowinput ist es ähnlich.
Übrigens, die AVM Firewall hat noch 2 weitere Filter: lowoutput und highinput, die über das UI nicht zugänglich sind und immer auf PERMIT stehen. Wenn man das Filterwerk von AVM komplett verstehen will, müsste man die zwei Filter mit betrachten. Für normale Anwender genügen aber die lowinput und highoutput Filter - eigentlich sind da schon die meisten damit überfordert. AVM benutzt die Firewall ja auch nur sehr rudimentär um NBT und Broadcast Verkehr ins Internet zu sperren, sonst tut sie ja in der AVM Einstellung nichts sinnvolles (Alle Zweige stehen auf PERMIT).
----------
Ich habe meinen Beitrag etwas ergänzt.
Ich glaube es ist eher so:
Quelle -> lowinput -> NAT / ROUTING -> highoutput -> Ziel
wobei Quelle und Ziel jedes Interface sein kann (WAN -> BOX, WAN -> LAN, LAN -> WAN, WAN -> DMZ, ...).
Man kann mit lowinput und highoutput auch DMZ Regeln von LAN zu LAN erstellen. Man kann auch nur mit highoutput in allen Richtungen filtern, wenn man Quelle und Ziel angibt, ich vermute bei lowinput ist es ähnlich.
Zuletzt bearbeitet:
Wäre es für die Forwardings nicht eigentlich gleich das Einfachste wenn man das etwas patcht?
so das auch sachen auf 0.0.0.0 eingetragen werden können (über das AVM WebIF), da verhindert ja immerhin das JS und/oder CGI ein Forwarding an 0.0.0.0
So könnte man erstmal einfach Forwardings einrichten zum Apache/Lighttpd/vsftpd usw, da AVM eigene Software die Arbeit verrichten muß und diese keinen Neustart braucht zum übernehmen der Regeln.
Das wäre zumindest für die Forwardings die Beste Lösung --> ein Patch.
Meine Gedanke ist ja, das wir hier über den Falschen Weg ran gehen, in dem wir das Rad ein zweites mal erfinden und zwar nur um auf den Internen FTP Server zu kommen (als Beispiel)
AVM kann das ja auch, ok die FTP Freigabe für den Speicher wird nie bei den AVM Freigaben im AVM WebIF angezeigt
dennoch ist sie im Firewall Pack ersichtlich. also hängt da schon mal was zusammen.
Sprich der Spaß der solche Funktionen im AVM Webif nicht anzeigt muss rausgepatcht werden.
Durch einen weiteren Patch dürfen Zugänge zu 0.0.0.0 und so im AVM Freigaben Menü erstellt werden.
Wenn man das beides zusammen legt zu einen Patch brauchen wir das Rad kein 2. mal zu konstruieren.
so das auch sachen auf 0.0.0.0 eingetragen werden können (über das AVM WebIF), da verhindert ja immerhin das JS und/oder CGI ein Forwarding an 0.0.0.0
So könnte man erstmal einfach Forwardings einrichten zum Apache/Lighttpd/vsftpd usw, da AVM eigene Software die Arbeit verrichten muß und diese keinen Neustart braucht zum übernehmen der Regeln.
Das wäre zumindest für die Forwardings die Beste Lösung --> ein Patch.
Meine Gedanke ist ja, das wir hier über den Falschen Weg ran gehen, in dem wir das Rad ein zweites mal erfinden und zwar nur um auf den Internen FTP Server zu kommen (als Beispiel)
AVM kann das ja auch, ok die FTP Freigabe für den Speicher wird nie bei den AVM Freigaben im AVM WebIF angezeigt
dennoch ist sie im Firewall Pack ersichtlich. also hängt da schon mal was zusammen.
Sprich der Spaß der solche Funktionen im AVM Webif nicht anzeigt muss rausgepatcht werden.
Durch einen weiteren Patch dürfen Zugänge zu 0.0.0.0 und so im AVM Freigaben Menü erstellt werden.
Wenn man das beides zusammen legt zu einen Patch brauchen wir das Rad kein 2. mal zu konstruieren.
Zuletzt bearbeitet:
olistudent
IPPF-Urgestein
- Mitglied seit
- 19 Okt 2004
- Beiträge
- 14,787
- Punkte für Reaktionen
- 13
- Punkte
- 38
Ich meine mich zu erinnern, dass es nicht so einfach möglich ist die 0.0.0.0 Forwardings anzeigen zu lassen. Aber einen Patch würden wir natürlich gerne nehmen...
MfG Oliver
MfG Oliver
Achso na dann, leider habe ich nicht die passenden Prorammierkenntnisse dafür,das war eigentlich eher so als kleine Anregung gedacht für Personen die diese Kenntnisse haben
Der PAtch, um die Sachen einzutragen, war recht einfach imho, nur das Anzeigen war irgendwie etwas schwieriger, und wahrscheinlich sogar im closed-source-Bereich.
Neueste Beiträge
-
[Frage] Smarthome im Mesh > 100 Geräte
- Letzte: Netzonline
-
[Problem] F!B 6591 Bootloop
- Letzte: porcupine
-
Installation Freetz / Freetz-NG
- Letzte: blackstar
-
Empfehlung Switch für Entertain TV & Sonos
- Letzte: BeeHaa
-
FRITZ!Box 7590 AX / FRITZ!OS 7.80 vom 30.01.2024- Letzte: Exodus88
-
Telekom FTTH-"Ausbau" bei bestehender FTTH-Anbindung
- Letzte: Lurtz
-
Wlan Mesh Problem- Letzte: frank_m24
