[NEU] schnelles iptables / ip6tables interface für die 7270 (v.0.8.3a) + 7390 etc...

Oh Mann! Wenn man nicht alles selber macht.

Ich habe mir das UI heute zufällig mal im Internet Explorer angesehen, das geht ja gar nicht mit den Radio Buttons und den Checkboxen. Da sagt aber auch keiner einen Mux von den ganzen Testern. Habt Ihr alle nur Linux (ist ja nichts wofür man sich schämen müsste ;) )?

Anbei ein modifizierter Patch mit Stylesheets, die IE & Firefox gleichermaßen verstehen... (es wurde nur die nhipt.cgi im Verzeichnis /usr/ipt/cgi-bin verändert). Ich habe mal alle Versionen auf der 1. Seite aktualisiert.


:-Ö
 

Anhänge

  • nhipt.patch.tar.gz
    27.5 KB · Aufrufe: 1
Außerdem wollte cando doch ein Interface "für Männer" machen und kein Spielzeug. Dann darf er sich nicht wundern, wenn das auch nur mit richtigem Werkzeug getestet wird (oder um es mit Metabo zu sagen: work. don´t play) ;-)
 
Des passt scho...

Ist schon recht.

Also wenn Ihr Zeit und Bock habt, dann könnt Ihr meinetwegen das GUI in den Trunk einchecken. Ich glaube nicht, dass sich daran noch was wesentliches ändert.

Vielen Dank für die Tipps und das Testen!

cando.

(yes we can!)

PS. Ich hab schon mal das WiKi in deutsch angelegt, wer mag kann es sich mal ansehen und in Englisch übersetzen...
http://trac.freetz.org/wiki/packages/nhipt
 
Zuletzt bearbeitet:
funktioniert nun auch mit trunk, Danke

Cool.

Ich werde es morgen gleich ausprobieren...


:rock:

UPDATE:

Habe es aus dem Trunk ausgcheckt und damit meine FW neu gebaut. Hat soweit funktioniert. Danke!
 
Zuletzt bearbeitet:
Hallo!

Ich habe das Paket über freetz installiert.
Nur, auf dem Port 83 läuft nichts bzw. meldet sich nichts.

Muss in die debug.cfg noch etwas eingetragen werden?
Muss was auf den USB-Stick noch, wenn es über Freetz läuft?

In freetz sind Moduleinträge doppelt vorhanden. Zum einen in Großschreibweise und einmal klein geschrieben.
Könnte sich das mal jemand anschauen?

Gruß
 
Nun, du weisst schon, dass du die Sachen auch noch anstellen musst? Von allein passiert da erstmal nichts ;)

@cando: KAnnst du deine Box mal recovern und das neu einspielen um den Fall darzustellen, wie es jemandem geht, der das neu installiert?
 
Kleine Einführung

Hallo JensEgon,

das hat alles seine Richtigkeit.

Nach der Installation solltest Du ins Freetz UI unter Pakete das Paket NHIPT finden.

Klick da mal drauf.

Dann stellst Du alles für das UI ein:
(Meins sieht so aus - siehe Anlage)


Wenn die Verzeichnisse stimmen und Du mit den Einstellungen zufrieden bist, dann speicherst Du das mit übernehmen.

Tipp:
Die Dienste für UI und evtl. für das Logging solltest Du auf running setzen, damit sie auch wirklich rennen.

Man muss die Einstellungen immer erst übernehmen, damt sie Wirksam werden.

Wenn die Dienste Laufen, sind die Eingabemasken für die Verzeichnise ServerIP, Port ausgegraut. auch das ist Absicht.

Der Button EDIT FIREWALL RULES bringt Dich zum Interface, wenn die Dienste laufen.

Zu den Namenskonventionen der Module. Das Kannst Du gerne bei netfilter.org / iptables nachlesen.

Manche Module sind dem Namen nach mehrfach vorhanden. Es gibt sie nämlich als Aktion und als Filter.

nehmen wir mal als Beispiel mark

xt_mark
xt_MARK
libxt_mark
libxt_MARK


xt_MARK ist das Modul, dass als Ziel (Großbuchstaben) in einer Regel verwendet werden kann (prerouting), um ein bestimmtes Paket zu markieren.

xt_mark ist das Gegenstück dazu, dass die markierten Pakete für ipv4/ipv6 anschlieend verarbeitet / filtert

libxt_mark und libxt_MARK sind die zugehörigen dynamischen Bibliotheken

Allgemein gilt: GROSSBUCHSTABEN sind ZIELE, kleinbuchstaben sind filter.

Was den USB Stick angeht, es geht auch ganz ohne, es ist alles auf der Box. Den Stick kann man für das Firewall Log und das BackUp der Regeln nutzen, wenn man will. Man kann aber auch die Konfiguration so einstellen, dass die Regeln vom Stick beim Booten geladen werden (um z.B. im Notfall den Stick abzuziehen und die Box ohne iptables zu booten).

Also kurze Antwort: nein, man braucht ihn nicht, er kann aber sehr nützlich sein.

Ach ja, siehe 1. Beitrag und Beschreibung:

VORAUSSETZUNGEN:

- iptables müssen vorhanden sein und laufen.

Das bedeutet, du musst beim aller ersten mal unter Umständen dafür sorgen, dass iptables funktionieren und geladen sind:
Wenn Du den replaces kernel mit autoload modules gewählt hast reicht:

Code:
iptables -S

in der shell. Andernfalls musst Du sie in der shell manell laden:

Code:
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_tables
modprobe ipt_LOG
modprobe ipt_REJECT
modprobe iptable_filter
modprobe x_tables
modprobe xt_multiport
modprobe xt_state
modprobe xt_tcpudp

Wenn Du deine Einstellungen einmal gespeichert hast, werden die Module beim Boot automatisch wieder geladen.
 

Anhänge

  • UI.jpg
    UI.jpg
    85.4 KB · Aufrufe: 20
Zuletzt bearbeitet:
Was ich noch gut fände (aber nicht weiss, wie man das realisieren sollte) wäre ein "Standardsatz" Regeln, die man als völliger Newbie anhaken kann im Menuconfig und somit Defaults unterbringt, die ein wenig Sicherheit bringen, aber nicht Fort Knox generieren.
Auch zu "Resetten" der Rules wäre das vllt. eine Option, wenn man sich doch mal ausgesperrt hat :D
 
Ist schwer zu definieren. Reset ist ja für Filter im script schon drin, obwohl nicht benötigt (sinnvoll nur bei wiederholtem Aufruf des scripts nach Reboot, damit die Regeln nicht mehrfach erstellt werden) :

iptables -P INPUT ACCEPT # Policy box eingehend
iptables -P OUTPUT ACCEPT # Policy box ausgehend
iptables -P FORWARD ACCEPT # Policy Durchgangsverkehr
iptables -F # Alle Regeln Löschen
iptables -X # Alle eigenen Ketten Löschen

für NAT, MANGLE und RAW habe ich nichts eingebaut - die sind eh nur was für weit Fortgeschrittene mit sehr speziellen Wünschen...

Defaul Regeln für Basis - Sicherheit lassen sich schwer definieren - siehe AVM Firewall (die sorgt ja eigentlich schon dafür, mann kann sie auch nicht weglassen, ohne den dsld mutwillig zu killen - dann weiss man aber auch was man tut...)

Bei AVM ist die Regel: Incomming Permit, Outgoing Permit, einzige Hürde ist der conntrack von nat. Ausgehend ist glaube ich Broadcast und NBT noch separat geblockt, nicht aber für ipv6 Tunnel über ipv4 - insofern bei neueren Windows Versionen eher wirkungslos.

Im Prinzip kann man ja schon eine Bootconfig mitgeben - wenn jemand aber seine Netze / Interfaces umbenennt (DMZ etc) ist diese bestenfalls wirkungslos, schlimmstenfalls schädlich.

iptables / netfilter ist ja auch Profiwerkzeug und kein Heimwerkertool.

Für den Amateur gibt's den Spaten (AVM Firewall) und für den Profi den Bagger (iptables) ;)
 
Zuletzt bearbeitet:
Kommt darauf an. Braucht man überhaupt Regeln? :wiejetzt:
 
Ja, und dennoch sind ein paar Defaults vielleicht keine schlechte idee. Gibt sicherlich genug, die einfach mal rumexperimentieren...

Idee dabei ist schlicht ein REgelsatz, der - wenn er existiert - sowas wie "alles ovn innen erlaubt" und "alles von aussen verboten, was nicht von innen animiert ist". Wenn man das ins image packt ,werden die eingetragenen rules überschrieben, wenn dieoption nicht drinnen ist, dann eben die eigenen.
Macht dann in 98% aller fälle einen satz, der ein wenig schützt, und in den 2%, die du dann genannt hast, weiss dieser Jemand ja auch, was er getan hat...

@Ralf: Nein, denn der Standarduser ,der keinein Plan hat, sollte die Finger davon lassen. Nur: Tut das jemand? Die meisten, die sich hier tummeln sind ausreichend experimentierfreudig, um sich daran zu wagen und tragen sonst etwas ein dort ohne plan.
 
Man könnte beim Flashen den Bootloader und die debug.cfg in der Box löschen (leere Datei) und damit iptables am Auto-Start nach dem Flashvorgang hindern. Mehr würde ich nicht tun.

So ein Regelwerk saugt man sich nicht eben mal aus den Fingern, das wächst über eine gewisse Zeit an. Wenn man das unachtam plattmacht, fängt der ganze Aufwand von vorne wieder an. Ich habe in meiner Firewall mittlerweile über 100 Regeln (DMZ-Regelwerk, Blocker für geschwätzige Software von PC's, Tunnel-Blocker für diverse ipv6,...).

Basis - Sicherheit, wie vorgeschlagen, hat man mit der AVM Firewall schon, es macht keinen Sinn das noch mal einzutragen. (es wäre ja auch keine Regel dafür nötig - iptables ist beim start default ACCEPT auf allen Pfaden und naten braucht sie nicht). Man weiss ja auch nicht, welche ip Adressen jemand verwendet - man kann ja auch andere nehmen, als die vorgeschlagenen - auch kann man seine Interfaces umbenennen. Auf was sollen sich die Regeln stützen?

Im WiKi ist doch ein recht brauchbares Regelwerk für eine Basis-Sicherheit mit ein paar Schmankerln als Beispiel veröffentlicht.
 
Zuletzt bearbeitet:
Die meisten ... tragen sonst etwas ein dort ohne plan.

Das läßt sich sowieso nicht verhindern.
"alles ovn innen erlaubt" und "alles von aussen verboten, was nicht von innen animiert ist".
Aber die iptables Regeln gelten zusätzlich zu den AVM-Regeln. Dieses Verhalten hat man also schon, wenn man die iptables Regeln leer läßt und nur die AVM Regeln hat.
 
@RalfFriedl:

Zu Deiner Frage, ob man zusätzlich zur AVM Firewall noch weitere Regeln braucht.

Die AVM Firewall ist ein sehr einfaches Gebilde, dass nicht granular genug den Verkehr steuern kann. Ausserdem ist sie buggy. (Manche Regeln für einzelne Ports werden einfach ignoriert). Sie hat mehrere Sektionen in der ar7.cfg, in denen Regeln hinterlegt werden könnten, die aber nicht mit Regeln versehen sind (offen:pERMIT) und sie sitzt sozusagen im proprietären Teil der Box (dsld), die Funktionsweise ist unklar und sie ist (über AVM Interface) nicht einstellbar.

Das Freetz AVM-Firewall Interface widmet sich einem kleinen Bruch-Teil des möglichen Regelwerks in einer einzigen Sektion der config.

Das TÜV-geprüfte Teil ist von Haus aus nicht sonderlich geschützt. Der einzige Schutz kommt von der NAT Funktion. Wenn in der NAT Tabelle keine interne Adresse für ein Antwortpaket (ausgehendes Port) über conntrack vorhanden ist, landet das Paket im Nirvana.

Wenn man die Verbindung von innen initiiert hat - kann vom Zielrechner alles mögliche zurückkommen und unter Umständen über den "Tunnel" auch neue Verbindungen von außen initiert werden (Siehe komplexe Protokolle wie ftp Protokoll, SIP, VoIP, irc etc.).

Das Gleiche um Längen gefährlicher ist der ipv6 Tunnle - Kram von teredo & co. Was hier passiert ist eine unkontrollierte abgehende Verbindung vom PC im Lan ins Internet zum ipv6 provider, der eine externe und routbare Adresse dem Rechner zuweist (DHCPv6) und ab da als externes Internet Gateway dient. Das heisst im Klartext, zusätzlich zum Internet Übergang an der Fritzbox gibt es eine weitere virtuelle völlig unkontrollierte Internetverbindung, die in beiden Richtungen uneingeschränkt genutzt werden kann (Tunnel zwischen IPv6 Provider und PC, Interface terminiert auf dem PC!!!) Hier versagt die Fritzbox komplett in Bezug auf Sicherheit.

Die IPv6 Protokolle und IPv6 Tunnelprotokolle sind per default in allen neuen OS freigeschaltet und bereits bei der Installation aktiviert (VISTA, WIN7, UBUNTU...)

Deshalb ja, man braucht unbedingt eine Firewall und zusätzliche Regeln.
 
Nun, war eine Idee, dasd noch ein wenig abzusichern, damit irgendein "Depp" einen Anfang hat, und nicht jeglichen Scheiss reinschreibt.
Somit würd ich vorschlagen ,das Ganze unter "Testing" und weiterhin "Show advanced options" zu schieben, damit ebne nicht jeder direkt daran geht.
 
Also ich bin da Leidenschaftslos, ob und wie es eingehängt wird. Ich meine, es ist ein sehr gutes, sehr gut funktionierendes Werkzeug.

Rein Logisch hängt es als Web-Interface an der richtigen Stelle, vom Status her ist es sicher lange nicht mehr testing oder unstable, iptables gibts hier ja schon ewig.

Inwieweit man den Nutzer vor sich selbst schützen muss - weiss ich nicht, das ist auch nicht meine Mission. Ich bin ja kein Babysitter oder Polizist. Allein schon durch die willentliche Veränderung der Firmware ist der User als mündig anzusehen - er hat ja bereits bewusst eine Entscheidung getroffen, auf Gewährleistung / Garantie zu verzichten und seine Hardware selbst zum Leben zu erwecken.

Ich sehe es auch nicht als verantwortungslos, dem Benutzer ein scharfes Schwert in die Hand zu geben, denn er bekommt ja auch eine Aufklärung über Risiken und Nebenwirkungen, sowie ausreichend Informationen zur sachgemäßen Anwendung (Iptables Handbuch, WiKi, Beispiele der Konfig, Literaturhinweise)

Ich denke, mehr kann und sollte man nicht tun.

Anbei noch etwas interessante Grusel-Lektüre... ;)
 

Anhänge

  • doc.pdf
    20.6 KB · Aufrufe: 13
Zu Deiner Frage, ob man zusätzlich zur AVM Firewall noch weitere Regeln braucht.

Es ging mir nicht darum, ob es eine Anwendung für iptables gibt, sondern darum, ob man irgendwelche Standard-Regeln laden soll, wenn jemand das Paket lädt, aber keine Ahnung davon hat. Und da das Paket optional ist und jemand, der es mit ins Image nimmt aber nicht konfiguriert, auch nicht mehr gefährdet ist als jemand, der das Paket gar nicht ausgewählt hat, sehe ich keine Grund, gleich irgendwelche reglen zu laden, die der Benutzer nicht ausgewählt hat.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.