Re: ipchains
Hallo Janto,
At 30.07.2001, Janto Trappe wrote:
> * Guido Hennecke <g.hennecke@t-online.de> [30-07-01 12:09]:
[...]
> > Du filterst das, was vom Internet (Beispiel) kommt und geroutet werden
> > soll in die Forward Chain (nicht einzeln pro Port sondern moeglichst
> > global und filterst dann eben in der Forward Chain.
> Das hoert sich schon besser an. Das 'Du hast Regeln ueber Dinge, die
> nicht passieren duerfen' hat mich gestoert.
Ich hab das nicht sehr schoen formuliert. Aber im Prinziep ist das so.
Du filterst raus, was nicht sein darf und leutest den Rest von dem was
Du dann noch routen willst in die forward Chain. Die Policys bleuben
alles auf REJECT.
> Die Methode hat den Vorteil, dass man pro Verbindung 4 Regeln weniger
Ich filtere beispielsweise in der output Chain nur aus, was
Fehlkonfiguration sein kann. Alles Andere lasse ich raus (Kommunikation
von innen nach aussen kann man nicht zuverlaessig am Paketfilter
reglementiere).
> hat und den Nachteil, dass die Pakete 'tiefer ins System' kommen.
Teilweise ja. Aber nur Pakete, die keinen "Schaden anrichten koennen"
;-)
Alles was nicht rein soll, wird in der input Chain geregelt (IP Spoofing
und TCP Pakete mit gesetztem Syn Flag, die man nicht will - mit UDP ist
das etwas aufwendiger, aber auch uebersichtlich machbar).
> Oder gibts noch mehr Vorteile?
Hmmmm... Ich finde es schon einen grossen GEwinn, die Regeln (ohne die
Sicherheit zu mindern!) dermassen drastisch zu verringern.
Ich habe das an meinem privaten (und eigentlich ueberfluessigen)
Paketfilter bemerkt. Als ich das Konzept neu ueberdacht habe, habe ich
die Anzahl der Regeln auf weniger als ein Drittel reduziert und durch
die Verwendung von benutzerdefinierten Chains derart vorsortiert, dass
die Uebersichtlichkeit zusaetzlich verbessert wurde _und_ jedes Paket
_deutlich_ weniger Regeln passieren musste, ehe es behandelt wurde.
Ich habe so auch (siehe anderer Thread) bei T-DSL im Downstream und beim
Download grosser Dateien einen deutlichen Performancegewinn feststellen
koennen.
Beeindruckend, wie ein undurchdachter Filter auf einem aelteren System
die Performance verringern kann (besonders auffaellig bei Live
Streaming).
> > > > Ansonsten kennst auch der 2.2´er Kernel Syn Floods.
> > > Du meinst er kann sie verhindern?
> > IIRC kann er bei einem "erkannten" Syn Flood die Pakete verwerfen
> > anstatt sie an die Anwendung weiter zu leiten.
> Ja, das kann er.
Ich war mir nicht sicher, ob das wirklich so ist, Ich hatte da nur so
was im Hinterkopf. Sollte mich damit wohl mal naeher auseinander setzen.
> Ich wollte nur wissen ob Du das meinst.
Ja, das meinte ich.
Gruss, Guido
--
An dieser Stelle nochmal ein Aufruf an alle: wenn ihr nicht sicher seid,
dann POSTET HALT NICHT. Es ist niemandem damit geholfen, wenn hier
hundert Leute ihr Halbwissen posten. (FvL in doc - Message-ID:
<slrn8moth3.7al.fefe@baileys.convergence.de>)
--
-----------------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie bitte eine
E-Mail an debian-user-de-request@lehmanns.de die im Subject
"unsubscribe <deine_email_adresse>" enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@Lehmanns.de
-----------------------------------------------------------
871 eingetragene Mitglieder in dieser Liste.
Reply to: