[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ipchains



Hallo Guido,

* Guido Hennecke <g.hennecke@t-online.de> [30-07-01 12:14]:

> > > Aber weitere Filterregeln werden ueberfluessig. Kann ein Dienst nicht
> > > initalisiert werden, brauche ich den nicht weiter durch Filterregeln
> > > absichern. Du erhoest sonst nur die Komplexitaet und damit auch die
> > > Gefahr, Fehler einzuschleppen.
> > Bei einer ACCEPT Policy (ansonsten werden auch unbenutzte Ports immer
> > geblockt) ist die Gefahr Fehler einzuschleppen sowieso sehr hoch.
> 
> Ich rede nicht von einer ACEPT Policy!

"brauche ich den nicht weiter durch Filterregeln absichern" hoert
sich aber so an.

> Wenn Du deine TCP Dienste nicht erreichbar machen willst, reicht es
> voellig aus, TCP Syn Pakete zu rejecten, die rein kommen. Fertig. Alles
> Andere erhoeht nur die Komplexitaet und damit die Moeglichkeit fuer
> Fehler.

Du redest wieder vom gezielten blocken von Syn Paketen. Warum und
wo sollte man das machen, ausser bei einer ACCEPT Policy?

> > > > > Dann noch dediziert irgendwelche Ports zu "sperren" ist Unsinn.
> > > > Eben nicht.
> > > Eben doch!
> > Nein. ;)
> 
> Dann erklaer mal bitte den Sinn.

Bei einer Policy, bei der Du alles blockst was nicht erlaubt ist,
werden logischerweise auch Ports geblockt auf denen kein Dienst laeuft.

Oder war mit obiger Aussage das Sperren von Ports, mit extra ipchains
Regeln, bei einer DENY Policy  (also doppelt) gemeint? Dann wuerde ich
Dir recht geben, aber darum ging es ja nicht.

> > > > Zustandsbehaftete Filterregeln.
> > > Bringen welchen Vorteil?
> > 80 und 119 und nur in der Mittagspause. ;)
> -v

$USER soll in der Mittagspause nicht surfen und keine News lesen.
War ein bloedes Beispiel und nicht ernst gemeint.

> > > Normalerweise will man aber kein NAT und auch kein Masquerading (was ja
> > > nur eine Untergruppe von NAT darstellt).
> > Warum wollte man kein Masquerading wollen?
> 
> Weil man damit eine der grundlegenden Funktionen von IP Netzen
> sabotiert. Die Transparenz von Client zu Server und umgekehrt, weil es
> in den meisten Fallen voellig unnuetz anstatt von Application Level
> Gateways einsetzt etc.

Es ist aber schoen bequem, darum will man es IMO doch.

> > > (http://cert.uni-stuttgart.de/archive/bugtraq/2001/07/msg00257.html)
> > Das hat aber nichts mit iptables zu tun.
> 
> Sicher hat es da. Allerdings nur indirekt oder welchen Kernel setzt Du

Genau, nur indirekt.

Gruss
Janto

-- 
Janto Trappe    Germany     /* rapelcgrq znvy cersreerq! */
GnuPG-Key:      http://www.sylence.de/gpgkey.asc
Key ID:         0x8C53625F
Fingerprint:    35D7 8CC0 3DAC 90CD B26F B628 C3AC 1AC5 8C53 625F

Attachment: pgp3z2FLL_9Ya.pgp
Description: PGP signature


Reply to: