Re: Re: Subject: [suse-isdn] bei DoD+Dyn IP te lnet möglich!?
Hallo Sven, auch erstmal DANKE! On Thu, 30 Sep 1999 14:30:15 +0200, Sven Marth wrote:
Ziel muß es also sein eine Regel aufzusetzen, welche nach dem automatischen Beenden einer Verbindung alle ausgehenden Verbindungswünsche mit der, bis dahin gültigen, jetzt aber nicht mehr gültigen Absender-IP abweist (REJECT ALL) und nach bestimmter Zeit (30 min dürften reichen) wieder gelöscht wird. Weiterführende Literatur hierzu findest Du z.B. unter http://www.little-idiot.de
das hört sich prinzipiell noch besser an...da muß ich wohl denn noch reinarbeiten, um mir solch eine Regel zusammenzubasteln um die in ip-down einzufügen. ...bin ich denn der Einzige mit solchen Problemen? Gibts die Regel(n) nicht schon fertig (auf die schnelle hab ich der "idiot"-doku nichts gefunden)? MfG Kai Gülzau
kai wrote:
Hallo Sven,
auch erstmal DANKE!
On Thu, 30 Sep 1999 14:30:15 +0200, Sven Marth wrote:
Ziel muß es also sein eine Regel aufzusetzen, welche nach dem automatischen Beenden einer Verbindung alle ausgehenden Verbindungswünsche mit der, bis dahin gültigen, jetzt aber nicht mehr gültigen Absender-IP abweist (REJECT ALL) und nach bestimmter Zeit (30 min dürften reichen) wieder gelöscht wird. Weiterführende Literatur hierzu findest Du z.B. unter http://www.little-idiot.de
das hört sich prinzipiell noch besser an...da muß ich wohl denn noch reinarbeiten, um mir solch eine Regel zusammenzubasteln um die in ip-down einzufügen.
...bin ich denn der Einzige mit solchen Problemen? Gibts die Regel(n) nicht schon fertig (auf die schnelle hab ich der "idiot"-doku nichts gefunden)?
Hmm. ich habe so etwas mal probiert. Beim Aufruf von ip-up wird als 4. parameter die IP übergeben (dto. ip-down, Verbindungsabbau) Also habe ich folgendes getan: Im ip-down Teil der case Anweisung: # mein versuch, die zuletzt benutzte IP in der firewall zu sperren ipchains -A output -s $LOCALIP -j DENY # nun fuer die Freigabe nach 30 min sorgen (im script...) /usr/local/bin/chainfree $LOCALIP & Dazu das script für die Freigabe: #!/bin/sh # # "zuletzt" genutzte IP wieder freigeben (nach einer Trauerfrist...) # die freizugebende IP wird als parameter uebergeben # FREEIP=$1 FRIST=30m sleep $FRIST ipchains -D output -s $FREEIP -j DENY Bei "vergessenen" http-Verbindungen (Netscape auf irgendeiner externen Seite und schliessen von Netscape) funzt es. Ich hatte aber erhebliche Probleme mit setiathome als beim laden des datenfiles die Verbindung entschlummert ist. Ich vermute, ich habe da noch etwas nicht gerafft, Firewall / ipchains habe ich eh nur ganz oberflächlich verstanden. Jürgen PS: gibt es die daten auf little-idiot auch zum runterladen und off-line lesen?? -- ========================================== __ _ Juergen Braukmann mail: brauki@cityweb.de| -o)/ / (_)__ __ ____ __ Tel: 0201-743648 dk4jb@db0qs.#nrw.deu.eu| /\\ /__/ / _ \/ // /\ \/ / ==========================================_\_v __/_/_//_/\_,_/ /_/\_\
On Thu, Sep 30, 1999 at 18:55 +0200, Juergen Braukmann wrote:
PS: gibt es die daten auf little-idiot auch zum runterladen und off-line lesen??
Hast Du das Inhaltsverzeichnis gelesen? Das war einer der ersten Punkte, wenn auch nicht gerade der erste. War aber recht einfach zu finden, habe ich ja auch geschafft :> Frage an SuSE: Das Subject geht schon wieder kaputt (wie frueher auch schon immer). Kann man diesen Quatsch nicht einfach mal weglassen? Dafuer sind doch andere Header-Zeilen da, so dass man kein Stueck subject dafuer opfern muss (ich habe allein in dieser Message 5 - in Worten: fuenf - Headerzeilen gesehen, die alle auf suse-isdn zeigen). Und selbst solche Programme wie Netscape kommen damit klar ("body" erschlaegt die header mit, die nicht explizit fuer Filter aufgefuehrt sind). Ich haette gerne einfach nur den Betreff im Subject gesehen. Sonst macht ein folder index keinen sonderlichen Sinn. virtually yours - Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Hallo Jürgen. ich habe gerade Dein Posting zum Thema dyn IP gelesen. Ich habe gerade selbst einen Anfrage mit meinen Sorgen gepostet. Deine Lösung bietet sicherlich schon mal einen guten Ansatz. Aber was macht man wenn man durch Zufall bei der nächsten Anwahl die gleiche IP zugewiesen bekommt? Gibt es nicht eine Möglichkeit offene IP-Verbindungen komplett aus dem IP-Stack zu entfernen? Gruß Peter
Hmm. ich habe so etwas mal probiert. Beim Aufruf von ip-up wird als 4. parameter die IP übergeben (dto. ip-down, Verbindungsabbau) Also habe ich folgendes getan:
Im ip-down Teil der case Anweisung:
# mein versuch, die zuletzt benutzte IP in der firewall zu sperren ipchains -A output -s $LOCALIP -j DENY # nun fuer die Freigabe nach 30 min sorgen (im script...) /usr/local/bin/chainfree $LOCALIP &
Dazu das script für die Freigabe:
#!/bin/sh # # "zuletzt" genutzte IP wieder freigeben (nach einer Trauerfrist...) # die freizugebende IP wird als parameter uebergeben # FREEIP=$1 FRIST=30m
sleep $FRIST ipchains -D output -s $FREEIP -j DENY
Bei "vergessenen" http-Verbindungen (Netscape auf irgendeiner externen Seite und schliessen von Netscape) funzt es. Ich hatte aber erhebliche Probleme mit setiathome als beim laden des datenfiles die Verbindung entschlummert ist. Ich vermute, ich habe da noch etwas nicht gerafft, Firewall / ipchains habe ich eh nur ganz oberflächlich verstanden.
On Thu, Oct 07, 1999 at 12:04 +0200, Peter Bossy wrote:
Deine Lösung bietet sicherlich schon mal einen guten Ansatz. Aber was macht man wenn man durch Zufall bei der nächsten Anwahl die gleiche IP zugewiesen bekommt?
Das waere ein dummer Zufall. Aber man kann ja in ip-down ALLES zur gerade verfallenen IP blockieren und im ip-up die eben erhaltene IP freischalten (egal ob vorher gehabt oder nicht).
Gibt es nicht eine Möglichkeit offene IP-Verbindungen komplett aus dem IP-Stack zu entfernen?
Du kannst Dir sicher fuser und kill ansehen, falls Du ernsthaftes Interesse hast :> "fuser -n tcp $PORT" gibt Dir eine PID, IIRC kann fuser wohl auch gleich Signale versenden.
[ ... ip-down mit "ipchains -A" und "sleep 30m; ipchains -D" ... ]
Kann man da nicht einfach at benutzen? In etwa so (ungetestet): ... ipchains -A output -s $LOCALIP -j DENY echo "ipchains -D output -s $LOCALIP -j DENY" | at now + 30 min ... Das hat den Nebeneffekt, dass die Aktion und ihre Ruecknahme unmittelbar beieinander stehen. Manche halten sowas fuer uebersichtlicher :) Vielleicht muss man noch zur Mailvermeidung die Ausgabe nach /dev/null schicken. Und wenn die ipchains-Regel von einem folgenden ip-up schon zurueckgenommen wurde, macht der at-Jobs eben effektiv nichts mehr und schadet nicht weiter. virtually yours - Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Gerhard Sittig wrote:
On Thu, Oct 07, 1999 at 12:04 +0200, Peter Bossy wrote:
Deine Lösung bietet sicherlich schon mal einen guten Ansatz. Aber was macht man wenn man durch Zufall bei der nächsten Anwahl die gleiche IP zugewiesen bekommt?
Das waere ein dummer Zufall. Aber man kann ja in ip-down ALLES zur gerade verfallenen IP blockieren und im ip-up die eben erhaltene IP freischalten (egal ob vorher gehabt oder nicht).
Stimmt. Diese Runde gehr an Gerhard. ;-)) Also die IP irgendwo sichern (vorher, ip-down)
Gibt es nicht eine Möglichkeit offene IP-Verbindungen komplett aus dem IP-Stack zu entfernen?
Du kannst Dir sicher fuser und kill ansehen, falls Du ernsthaftes Interesse hast :> "fuser -n tcp $PORT" gibt Dir eine PID, IIRC kann fuser wohl auch gleich Signale versenden.
Du meinst, wenn ein socket offen ist gibt es irgendwo noch einen prozess der nur darauf wartet mit kill -9 gemeuchelt zu werden??? Und danach ist Ruhe?? Das kann man doch im ip-down "erledigen" (doppeldeutig!)
[ ... ip-down mit "ipchains -A" und "sleep 30m; ipchains -D" ... ]
Kann man da nicht einfach at benutzen? In etwa so (ungetestet):
... ipchains -A output -s $LOCALIP -j DENY echo "ipchains -D output -s $LOCALIP -j DENY" | at now + 30 min ...
Das hat den Nebeneffekt, dass die Aktion und ihre Ruecknahme unmittelbar beieinander stehen. Manche halten sowas fuer uebersichtlicher :) Vielleicht muss man noch zur Mailvermeidung die Ausgabe nach /dev/null schicken. Und wenn die ipchains-Regel von einem folgenden ip-up schon zurueckgenommen wurde, macht der at-Jobs eben effektiv nichts mehr und schadet nicht weiter.
"hält" das ip-down script dann nicht an?? sorry klar, at. Ziehe Frage zurück. :) besser als meine variante. ;)
virtually yours - Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
-- ========================================== __ _ Juergen Braukmann mail: brauki@cityweb.de| -o)/ / (_)__ __ ____ __ Tel: 0201-743648 dk4jb@db0qs.#nrw.deu.eu| /\\ /__/ / _ \/ // /\ \/ / ==========================================_\_v __/_/_//_/\_,_/ /_/\_\
On Thu, Oct 07, 1999 at 23:17 +0200, Juergen Braukmann wrote:
Gerhard Sittig wrote:
Aber man kann ja in ip-down ALLES zur gerade verfallenen IP blockieren und im ip-up die eben erhaltene IP freischalten (egal ob vorher gehabt oder nicht).
Stimmt. Diese Runde gehr an Gerhard. ;-)) Also die IP irgendwo sichern (vorher, ip-down)
Macht das den Eindruck, dass hier Leute wetteifern oder gar boxen? Das waere traurig und ungewollt. Aber Du laechelst, also ist es gut ... Die alte IP brauche ich doch ueberhaupt nicht mehr. Ich mache einfach den Verkehr zur verfallenen IP dicht und lege schon einen Befehl auf Halde, diese Regel wieder zu entfernen, wenn die Socke sicher zu ist. Das beschraenkt dann die Anzahl derartiger Regeln, die gerade aktiv sind und verwaltet werden muessen. Im ip-up kann ich die neue IP unbesehen freischalten (die Blockade loeschen): war kein Sperrbefehl da, macht's nix; hatte ich diese IP schon und gesperrt, kann ich sie wieder benutzen. Der Vorschlag von Axel ist freilich besser: Im ip-up wird der zur gerade erhaltenen IP freigegeben und alles andere sinnvollerweise die ganze Zeit ueber blockiert. Im ip-down wird die "Erlaubnis" fuer diese IP wieder entzogen. Dann gibt es zu jeder Zeit nicht mehr als zwei Regeln: eine blockiert allen Verkehr und eine erlaubt evtl fuer die Online-Zeit den Traffic mit der aktuellen IP. Man muss nur aufpassen, dass die Erlaubnis VOR der Blockade greift.
Du kannst Dir sicher fuser und kill ansehen, falls Du ernsthaftes Interesse hast :> "fuser -n tcp $PORT" gibt Dir eine PID, IIRC kann fuser wohl auch gleich Signale versenden.
Du meinst, wenn ein socket offen ist gibt es irgendwo noch einen prozess der nur darauf wartet mit kill -9 gemeuchelt zu werden??? Und danach ist Ruhe?? Das kann man doch im ip-down "erledigen" (doppeldeutig!)
Warum denken die Leuts bei kill immer an grausames Meucheln? kill(2) ist ein Mechanismus zum Zustellen von Signalen, die in der betroffenen Applikation registriert und behandelt werden koennen. kill(1) bzw die internen Shell-Befehle sind Wrapper um den Systemruf. Das schien mir wieder mal wichtig zu erwaehnen. Also wuerde ich vor der -9 erstmal HUP oder sowas schicken. Ich bin mir aber nicht hundertprozentig sicher, dass nicht mehr existente Apps (die evtl einen Socket unsauber hinterlassen) eine Garantie fuer Ruhe sind. Man hoert da ab und an von Quengeleien auf dem http-Port, obwohl Netscape schon zu ist (und das sogar sauber). virtually yours - Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Gerhard Sittig wrote:
On Thu, Oct 07, 1999 at 23:17 +0200, Juergen Braukmann wrote:
Gerhard Sittig wrote:
Aber man kann ja in ip-down ALLES zur gerade verfallenen IP blockieren und im ip-up die eben erhaltene IP freischalten (egal ob vorher gehabt oder nicht).
Stimmt. Diese Runde gehr an Gerhard. ;-)) Also die IP irgendwo sichern (vorher, ip-down)
Macht das den Eindruck, dass hier Leute wetteifern oder gar boxen? Das waere traurig und ungewollt. Aber Du laechelst, also ist es gut ...
Es war wirklich grinsend gemeint. Füe mich sind aus dem Thread viele Informationen gekommen.
Die alte IP brauche ich doch ueberhaupt nicht mehr. Ich mache einfach den Verkehr zur verfallenen IP dicht und lege schon einen Befehl auf Halde, diese Regel wieder zu entfernen, wenn die Socke sicher zu ist. Das beschraenkt dann die Anzahl derartiger
ja. Das meinte ich. IP auf Halde legen und dann ein script draus machen. Umgekehrte Reihenfolge.
Regeln, die gerade aktiv sind und verwaltet werden muessen. Im ip-up kann ich die neue IP unbesehen freischalten (die Blockade loeschen): war kein Sperrbefehl da, macht's nix; hatte ich diese IP schon und gesperrt, kann ich sie wieder benutzen.
Der Vorschlag von Axel ist freilich besser: Im ip-up wird der zur gerade erhaltenen IP freigegeben und alles andere sinnvollerweise die ganze Zeit ueber blockiert. Im ip-down wird
Ja. das ist auf jeden Fall das Beste: Irgendetwas hat dafür gesorgt, (im zusammenhang mit dem download bei setiathome) das die Sockets trotzdem überlebt haben und nach der Freigabe ging es wieder los. Ich glaube nur, für die "dummy" ip des/der ipppX devices muss man auch eine Regel einfügen, denn wenn alles gesperrt ist darf 192.168.0.1 (oder was auch immer) ebenfalls nicht raus.
die "Erlaubnis" fuer diese IP wieder entzogen. Dann gibt es zu jeder Zeit nicht mehr als zwei Regeln: eine blockiert allen Verkehr und eine erlaubt evtl fuer die Online-Zeit den Traffic mit der aktuellen IP. Man muss nur aufpassen, dass die Erlaubnis VOR der Blockade greift.
Du kannst Dir sicher fuser und kill ansehen, falls Du ernsthaftes Interesse hast :> "fuser -n tcp $PORT" gibt Dir eine PID, IIRC kann fuser wohl auch gleich Signale versenden.
Du meinst, wenn ein socket offen ist gibt es irgendwo noch einen prozess der nur darauf wartet mit kill -9 gemeuchelt zu werden??? Und danach ist Ruhe?? Das kann man doch im ip-down "erledigen" (doppeldeutig!)
Warum denken die Leuts bei kill immer an grausames Meucheln? kill(2) ist ein Mechanismus zum Zustellen von Signalen, die in der betroffenen Applikation registriert und behandelt werden koennen. kill(1) bzw die internen Shell-Befehle sind Wrapper um den Systemruf. Das schien mir wieder mal wichtig zu erwaehnen.
;-)
Also wuerde ich vor der -9 erstmal HUP oder sowas schicken. Ich bin mir aber nicht hundertprozentig sicher, dass nicht mehr existente Apps (die evtl einen Socket unsauber hinterlassen) eine Garantie fuer Ruhe sind. Man hoert da ab und an von Quengeleien auf dem http-Port, obwohl Netscape schon zu ist (und das sogar sauber).
kann ich aus Erfahrung bestätigen. Ich hatte nur etwas Hoffnung, das es doch noch eine Möglichkeit gibt die Sockets zu schließen ... Juergen
virtually yours - Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
-- ========================================== __ _ Juergen Braukmann mail: brauki@cityweb.de| -o)/ / (_)__ __ ____ __ Tel: 0201-743648 dk4jb@db0qs.#nrw.deu.eu| /\\ /__/ / _ \/ // /\ \/ / ==========================================_\_v __/_/_//_/\_,_/ /_/\_\
participants (4)
-
Gerhard Sittig -
Juergen Braukmann -
kai -
Peter Bossy