Hallo Guido, * Guido Hennecke <g.hennecke@t-online.de> [25-07-01 23:35]: > 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. > Der Feind der Sicherheit ist unnoetige Komplexitaet. KISS! ACK. > > > Dann noch dediziert irgendwelche Ports zu "sperren" ist Unsinn. > > Eben nicht. > Eben doch! Nein. ;) > > Zustandsbehaftete Filterregeln. > > Bringen welchen Vorteil? 80 und 119 und nur in der Mittagspause. ;) > Normalerweise will man aber kein NAT und auch kein Masquerading (was ja > nur eine Untergruppe von NAT darstellt). Warum wollte man kein Masquerading wollen? [ipchains modul fuer iptables] > Wenn ich mir beispielsweise nur die aktuellsten Probleme damit ansehe, > will ich das nicht auf Systemen, die der Sicherheit dienen. Und nochmal: ACK. > (http://cert.uni-stuttgart.de/archive/bugtraq/2001/07/msg00257.html) Das hat aber nichts mit iptables zu tun. 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:
pgpedJhBYqFJb.pgp
Description: PGP signature