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

[Silent-Tears]

Ich finde ja, das ist echt trunkwert insgesamt. Dann sieht man auch, wie die breiten massen dadrauf reagieren, und ob sich wer tatsächlich aussperrt.

Oder spricht noch was dagegen (ich hab alleridngs nicht die komplette Entwicklung verfolgt und kenne die aktuellen Sourcen nicht).

 

[cando]

Hallo SilentTiers,

Ich bin noch nicht ganz fertig mit dem Testen und Fixen.

Ich habe das Interface täglich im Einsatz, aber so die eine oder andere Feinheit und Optimierung kommt ständig dazu, auch Dank des Feedbacks aus dem Forum.

Irgendwann wird man vom Testen und Patchen blind, da hilft es, wenn mal einer von außen mit drauf schaut.

Einige Lösungen, die ich am Anfang noch drin hatte sind während der Weiterentwicklung obsolet geworden oder wurden dann doch anders realisiert - das Projekt wächst an den Herausforderungen.

Ich würde so noch 1-2 Wochen warten, bis alles so richtig rund ist und Altlasten / Debug-Code komplett entfernt sind. Dann spricht aus meiner Sicht nichts gegen eine Integration in den Trunk.

Ich würde dafür die freetz version abrüsten, was die Config angeht und der Erzeugung des Log-Deamons (die Dateien kann ich ja statisch ins Paket packen)

Bis dahin habe ich auch die Freetz Maske für die Config soweit fertig:

• Web-Interface zusammen mit freetz auf port 81 (intern)
• oder eigener httpd (port einstellen; autostart/manuell, nur LAN IP für httpd an/aus)
• Logdienst: syslogd oder eigener deamon (autostart / manuell), Log-Verzeichnis
• Back-Up Verzeichnis für alte Configs
• Admin-IP
• Boot-Delay (aus, 30s, 1min, 3min, 5min)
• dsld ausschalten während bootdelay (ja/nein)
• FW Regeln booten vom flash oder vom stick (Stick-Verzeichnis)

Zusätzlich könnte man noch die aktuelle Version komplett als "Externes" Paket belassen, falls jemand Speichermangel auf der Box hat und das Interface ausschliesslich vom Stick nutzen möchte.

Ich könnte noch ein kleines Script spendieren, damit die Links und die Maske im freetz bei diesem externen Paket dynamisch bei jedem Boot hinzugefügt werden, so dass man das nicht mal flashen muss, um es (zusätzlich) über freetz konfigurieren zu können.

Da habe ich noch ein paar Ideen, ist aber noch nicht ganz ausgereift.

Wie gesagt, so 2 Wochen wird's wohl noch dauern, bis ich zufrieden bin.

 

[alpha1974]

@cando,
ein weiteres Feature-Request

Zur besseren Übersichtlichkeit wäre es hilfreich, die Rules mit Kommentaren versehen zu können. Dafür gibt es bereits ein entsprechendes iptables-Modul (ipt_comment), das über einen Patch (Ticket #589) auch unter Freetz ins Image eingebaut werden kann. Die Funktionsweise ist ziemlich simpel:

/ # modprobe ipt_comment
/ # iptables -A FORWARD -s 192.168.178.20 -j ACCEPT -m comment --comment "Test-Kommentar!"
/ # iptables -L FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
TRANS      all  --  anywhere             anywhere            
ACCEPT     all  --  192.168.178.20       anywhere            /* Test-Kommentar! */ 
/ #

Gruß
alpha

 

[cando]

Hallo Freunde der Nacht!

Ich habe mich mal hingesetzt und das GUI dynamisch ins Freetz "eingebastelt". (zum Download ipt.tar.gz auf der Startseite dieses threads)

Bitte nicht gleich schimpfen. Es ist z.Zeit nur ein Freetz-.Wrapper um das eigenständige IP-Tables GUI.

Es funktioniert aber schon in weiten Teilen:

Man kann damit die Dienste Konfigurieren, den inetd starten und stoppen, den Log deamon stoppen (ich bekomme den nicht in den Hintergrund beim Starten, hat jemand einen Tipp?) und die Boot Konfiguration anpassen.

Das Persistieren in den Flash habe ich aus freetz noch nicht realisiert, die werte werden aber in der RAM - Disk an das GUI übergeben. Ein Knopfdruck dort und die Bootrecords werden erzeugt.

Ist der httpd gestartet, kann man sich auf Knopfdruck aus freetz in das IP-Tables GUI beamen.

Installation:

- das Archiv auf der root von uStor01 auspacken
- register.sh ausführbar machen (chmod +x register.sh)
- die register.sh in der shell ausführen (./register.sh)

danach sollte im freetz interface ein neues Paket NHIpt erscheinen.

Über Feedback von den freetz Experten würde ich mich freuen.

Viele Grüße

cando

 

[cando]

freetz UI - Frage

Hallo freetz-Profis,

Ich habe mal das freetz-Paket von dem ip-Tables GUI fertig gemacht.

Ich habe da mal eine Frage. Ich möchte, dass mein Paket dynamisch im freetz nach dem Reboot wieder eingelesen wird.

Ich habe ein script (/var/media/ftp/uStor01/ipt/register.sh), dass aufgerufen werden soll, sobald freetz aufnahmefähig ist.

Wie ist denn die richtige Vorgehensweise? In der debug.cfg ist es vermutlich noch viel zu früh, das Script zu starten.

Das Paket ist vorne zum Begutachten. Ich freue mich auf Eure Tipps.


@alpha1974

Danke für Dein Feature Request.

Ich würde es Einbauen, nur solange das Modul nicht direkt auswählbar ist, wird es viele Fragen geben. Außerdem verkompliziert sich das Parsen der Regeln wegen den neuen Kommentar-Begrenzern und das Feld "Extra", das jetzt schon von verschiedenen Zielen genutzt und automatisch umbelegt wird, wird bei komplexeren Regeln noch schlechter zu handeln.

Ich sehe da im Moment eher mehr Nachteile, als Vorteile. Über die "Experten" Eingabe kann man diese Kommentar-Regeln ja immer eingeben. Für Otto-Normal würde ich es lieber lassen.

 

[alpha1974]

Zu ipt_comments: Ich habe die Hoffnung, dass der ipt_comments-Patch seinen Weg in den Trunk findet ;-)

Nach etwas anderes: Der Boot-Delay (sleep in debug.cfg) erfolgt zu einem Zeitpunkt, an dem die Freetz-Dienste noch nicht gestartet sind. Deshalb läuft während des boot-delays auch openssh als Freetz-Dienst noch nicht (rc.mod und rc.openssh werden erst nach dem debug.cfg-Durchlauf aufgerufen). Während des Boot-Delays kommt man daher derzeit nicht per ssh auf die Box. Vielleicht könnte man das ganze als Hintergrund-Prozess laufen lassen, damit die Freetz-Dienste während des Boot-Delays (der dann nur noch ein iptable-Delay wäre) gestartet werden?

 

[Silent-Tears]

AOus Sicherheitsgründen dann wohl nur rc.openssh und rc.webcfg und nicht alles, oder?

 

[cando]

Kann sich mal jemand das neue freetz UI ansehen / ausprobieren?

Ich würde gerne wissen, wo ich die register.sh Routine reinhängen kann, damit das freetz UI beim Reboot automatisch wieder registriert wird.

Ist hierfür die rc.custom der richtige Platz?

Die Integration ist nun in beiden Richtungen erfolgt (beide UI greifen auf die selben Datenbasis zu, Änderungen werden in beiden Richtungen sichtbar)

Der Zustand des Paketes nun ist Beta.

D.h., die Funktionen sind jetzt alle soweit drin, dass man es als "Paket" ansehen könnte.


@Alpha

Wie sollte denn Deiner Meinung nach die Debug.cfg aussehen? Kannst Du mal bitte die modifizierten Zeilen posten?

Ach ja, poste bitte mal eine Ausgabe von iptables Regeln mit comment Kommentar mit folgendem Kommando:

iptables [-t tabelle] -S

-t tabelle, natürlich nur wenn sie nicht in der Standard - Tabelle filter sind

Mich interessieren die Delimiter der Ausgabe. Sind es /* */ oder ""

 

[alpha1974]

Wie sollte denn Deiner Meinung nach die Debug.cfg aussehen?

Hmmm... gute Frage. Mir persönlich wäre es am liebsten, wenn überhaupt nichts über debug.cfg geht, sondern alles über freetz. Denn dann könnte man die Reihenfolge, in der rc.mod die Dienste startet, definieren (in der Reihenfolge aus /etc/static.pkg, wobei die dortige Reihenfolge durch die $(PKG)_STARTLEVEL in den *.mk-Files bestimmt wird). Dass iptables eigentlich gar kein Dienst (im Sinne eines Dämons) ist, macht wohl nichts. /etc/init.d/rc.php startet ja auch keinen Dämon, sondern führt beim Start nur eine einmalige Aktion aus.

Ach ja, poste bitte mal eine Ausgabe von iptables Regeln mit comment

-A FORWARD -s 192.182.200.20/32 -m comment --comment "Lap1" -j ACCEPT 
-A FORWARD -s 192.182.200.30/32 -m comment --comment "Lap2" -j ACCEPT

 

[cando]

Hmmm..

Ich fände es besser, wenn iptables so früh wie möglich alles dicht macht. Bei den freetz sachen bin ich mir nicht sicher, ob da nicht Änderungen an der Config iptables rauskicken können.

Die debug.cfg ist halt etwas, was nicht über die freetz UI verändert wird und somit für den 0815-Klicki-Bunti-User keine Angriffsmöglichkeit bietet.

Damit ist das System halbwegs gekapselt. Ich muss aber zugeben, dass ich die Mimik der Diensteverwaltung von freetz und die Möglichkeiten der Einflussnahme nach dem Flashen der Firmware zu wenig kenne.

Eine Beschreibung des Bootvorganges + freetz und die Eingriffsmöglichkeiten (beschreibbare config Dateien, beschreibbare Ablage für die Skripte zur Runtime) würde mir weiterhelfen.

Ach ja, das mit dem comment ist doch nicht so schlimm, wie ich erst dachte, da die delimiter wie beim --log-prefix funktionieren. Kann ich mal einbauen, nur leider noch nicht testen, da ich den Patch dafür noch nicht in meiner Firmware drin habe.

 

[alpha1974]

Eine Beschreibung des Bootvorganges + freetz und die Eingriffsmöglichkeiten (beschreibbare config Dateien, beschreibbare Ablage für die Skripte zur Runtime) würde mir weiterhelfen.

Ich kann leider nur mit ein paar Bookmarks weiterhelfen, deren Aktualität mir aber auch nicht so ganz klar ist:
- Bootreihenfolge
- Reihenfolge der Dienste
- Persistent Settings

 

[cando]

Würde Dir denn soetwas in der debug.cfg helfen?

debug.cfg:

#/bin/sh


###NHIPT-START###


cat /tmp/flash/nhipt.cfg > /var/tmp/nhipt.cfg
cat /tmp/flash/nhipt.par > /var/tmp/nhipt.par
chmod +x /var/tmp/nhipt.cfg
[B]/bin/sh /var/tmp/nhipt.cfg &[/B]

###NHIPT-END###

Ich habe mal die Registrierung des Freetz Interfaces angepasst, damit sie bei Bedarf die rc.custom für den Bootvorgang erweitert.

register.sh:

#!/bin/sh

mkdir /mod/etc/default.nhipt
cp /var/media/ftp/uStor01/ipt/freetz/nhipt.cfg /mod/etc/default.nhipt
modconf load nhipt
cd /mod/usr/lib/cgi-bin
ln -s /var/media/ftp/uStor01/ipt/freetz/nhipt.cgi nhipt.cgi
cd /mod/etc/init.d
ln -s /var/media/ftp/uStor01/ipt/freetz/rc.nhipt rc.nhipt
modreg cgi nhipt NHIpt
cp /var/media/ftp/uStor01/ipt/cgi-bin/nhipt.par /var/tmp/nhipt.par
chmod +x /var/media/ftp/uStor01/ipt/cgi-bin/nhipt.cgi
chmod +x /var/media/ftp/uStor01/ipt/freetz/nhipt.cgi
if [ -z "$(grep 'register.sh' /tmp/flash/mod/rc.custom)" ]; then echo '. /var/media/ftp/uStor01/ipt/register.sh' >> /tmp/flash/mod/rc.custom; 
modsave flash; fi

Ich habe es mal so in die aktuelle Version eingebaut (v.0.8.2a)

 

[cando]

NEU - Unterstützung für ipt_comment

Hallo Alpha1974,

Comment wird nun auch unterstützt. Bitte mal testen.

 

[alpha1974]

Bei Rules mit comments wird unter "Module" zutreffend "comment" angezeigt, allerdings steht in der Spalte "Param": --comment "Kommentartext"
Sollte da nicht nur "Kommentartext" stehen (analog zum state-Modul)?

 

[cando]

Die Ausgabe hab ich mir noch nicht angesehen, die Eingabe funktioniert aber direkt (ohne --comment eingeben zu müssen).

Es kann ja sein, dass mehrere Module Sonderparameter haben (Experteneingabe), dann weiss man nicht, wo die hingehören. Deshalb gebe ich das meiste, was nicht in die Felder passt samt Vorspann aus.

Ich schaue aber noch mal drüber, ob ich es sinnvoll abfangen kann.

Viele Grüße

cando

EDIT: Ich habe die Ausgabe angepasst und neu hochgeladen (0.8.2d). Leider kann ich es selbst noch nicht testen.

 

[alpha1974]

In der aktuellen Version wird unter Param Folgendes ausgegeben:

"Kommentartext" -j ACCEPT

Allerdings funktioniert es, wenn man in der entsprechenden myArray["Comment"]-Zeile den Code ein wenig modifziert, indem man ein Leerzeichen einfügt:

... if (index($j, "[B] \[/B]"") ... > 0

EDIT: Ob Leerzeichen oder sonstiges Zeichen in der IF-Abfrage ist schnuppe, habe aber leider keine Zeit für näheres Debugging.
EDIT2: Dein Code funktioniert, wenn der Comment mit einem Leerzeichen vor dem abschließenden Anführungsstrichen endet (--comment "Kommentartext "). Dann werden die zweiten Anführungszeichen als Break-Bedingung erkannt. Der Unterschied zum Parsing des Log-Parameters liegt wohl darin, dass nach dem Log-Parameter keine weiteren Argumente mehr kommen, und das Parsing deshalb am Zeilenende abbricht.

Alles natürlich reine Kosmetik (ebenso wie der Umstand, dass bei der Ausgabe von Rules mit mehreren Modulen die Reihenfolge der Module und die Reihenfolge der dazugehörigen Parameter nicht immer übereinstimmt).

 

[cando]

--- fixed ---

Hallo Alpha, des String Parser geht jetzt, wie er soll. Problem war, dass im String mindestens ein Leerzeichen erwartet wurde, ansonsten ohne "".
Offenbar gibt aber iptables für diese Parameter grundsätzlich "" aus.

Ist nun abgefangen und das Update oben zum Download.

 

[cando]

Integration in trunk?

Hallo Leute,

Ich habe mein Paket soweit als externes Feature fertig, die "known" Bugs scheinen soweit alle beseitigt zu sein und die angefragten Features sind implementiert.

Mein Paket hat bislang 2 Modes:

• Reines CGI vom USB Device
• Dynamische Integration (reset-fest) in Freetz vom USB Device

Ich würde vielleicht einen (ab/umgerüsteten?) 3. Modus anregen als Paket im Trunk (mit make menuconfig etc.)

Ich dachte mir, das statische Paket so anzupassen:

• booten der Regeln nur noch von der Box (oder sollte man die Auslagerung auf Stick weiter zulassen?)
• keine Konfiguration des Root Verzeichnisses für UI (immer im EEPROM)
• feste Dateien für den Log-Deamon, nur für DECT Boxen selektierbar
• Dienste werden von Freetz verwaltet:

• FW abschaltbar in Freetz Prozesskette eingebunden (wie?)
• Log-deamon als freetz Dienst steuerbar (wie?)
• FW-UI (httpd) start/stop/port einstellen

• Keine Nutzung mehr von debug.cfg und rc.custom für start (wo sonst?)

Ich wollte das mal mit Euch diskutieren, ob das aus Eurer Sicht überhaupt Sinn macht, oder ob wir das "dynamische" Paket so in den Trunk packen sollen, wie es ist (die freetz Variante, mit angepasstem register.sh das z.Zt. aus der rc.custom aufgerufen wird für den modconf / modreg zur UI Einbindung in freetz).

Ich habe bisher noch kein Paket gebaut und bräuchte ein paar Tipps, wie ich es am geschicktesten angehen kann.

Alle 3 Varianten haben ihren Reiz:

• Variante 1: Nur UI auf Stick / Regeln im Flash. Man kann den "Admin-Stick" nach getaner Konfiguration einfach abziehen und die Box ist sicher.
• Variante 2: Über freetz konfigurierbar, Regeln entweder im Flash oder auf Stick ("Zündschlüssel für Firewall" gegen Aussperren), minimaler Speicherverbrauch auf der Box
• Variante 3: Sicheres Interface, immer verfügbar, fest installiert, in Freetz integriert, braucht keinen externen Speicher.

Habt Ihr Ideen / Vorschläge wie man die am besten publizieren / integrieren kann?

 

[olistudent]

Ich wäre dafür, dass wir das Paket vollständig integrieren. Als Beispiel können wir wol-cgi nehmen. Keine debug.cfg und keine rc.custom.

Was meinst du mit Log-Daemon? Wir haben ja ein syslog-cgi.

Mit dem Aussperren bin ich mir noch nicht ganz sicher wie wir das machen sollten. Es gibt einen Schalter, dass die Dienste nicht gestartet werden. Aber der muss über den ADAM2 gesetzt werden, wenn die Box anders nicht mehr erreichbar ist.

MfG Oliver

 

[Silent-Tears]

Der log-daemon hat einen echten Vorteil, dass trotz aktiviertem AVM_PRINTK die kmesg auftauchen, wenn ich das richtig verstanden hab, und das ausserhalb vom syslogd