s.u. Gruss Axel

-----Ursprüngliche Nachricht----- Von: Juergen Braukmann [mailto:juergen.braukmann@ruhr-west.de] Gesendet am: Donnerstag, 7. Oktober 1999 23:17 An: SuSE ISDN-Liste Betreff: Re: [suse-isdn] bei DoD+Dyn IP te lnet möglich!?

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.

Wie wäre es denn, anstelle derartiger "wüster" Konstrukte ;-) die einschränkende Grundhaltung zu implementieren? Es werden nur die Verbindungen nach draussen mit Quell-IP $LOCALIP erlaubt. Alles andere (von innen nach aussen über ippp0) wird nicht mit DENY abgewürgt, sondern via REJECT zurückgewiesen. Alles Illegale von aussen nach innen wird jedoch mit DENY geblockt. Was auf jeden Fall verhindert werden sollte ist, dass die Regelbasis bei häufigem Verbindungsauf-/abbau (z.B. beim Surfen mit kurzem Timeout von 30 Sekunden) anwächst, wenn für jede $LOCALIP eine neue DENY- Regel in ppp-down aufgesetzt wird. Das wird im obigen Vorschlag durch die Zeitsteuerung zwar eingeschränkt, lässt sich dennoch nicht ganz verhindern und ermöglicht bei einem angenommenen Timeout von 30 Sekunden theoretisch bis zu 60 DENY-Regeln, die alle ein wenig in der Luft hängen, weil sie in keinem Skript stehen. Dies halte ich persönlich für unschön. Ist aber eher Geschmackssache. Das ganze erinnert mich übrigens an das Problem mit den Verbindungen im Zustand FIN_WAIT1, die bei mir für viele unerwünschte Verbindungs- aufbauten beim Surfen gesorgt haben. Ich habe das über die RECJECTs gelöst. Nach ca. 15 Minuten verschwinden die nicht mehr existenten Verbindungen mit nicht mehr vorhanderner Quell-IP dann endlich. Laut SuSE Support ist das übrigens ein Fehler im Kernel, der wohl auch in 2.2.12 noch nicht behoben ist.

...

"hält" das ip-down script dann nicht an?? sorry klar, at. Ziehe Frage zurück. :) besser als meine variante. ;)

...

virtually yours - Gerhard Sittig