Hallo Jens, At 25.07.2001, Jens Benecke wrote: > On Wed, Jul 25, 2001 at 02:13:48PM +0200, Guido Hennecke wrote: > > Wenn Du keine Dienste anbieten willst und keine TCP Syn Pakete von aussen > > rein laesst, brauchst Du dich fuer TCP Dienste nicht weiter darum > > kuemmern. Das schreib ich auch. Nur sollte eben die erste Massnahme sein, > > Dienste, die man nicht anbieten will, erst garnicht anzubieten. > ACK. Weitere Sicherheismassnahmen werden dadurch allerdings nicht > überflüssig. 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. Der Feind der Sicherheit ist unnoetige Komplexitaet. KISS! > > Dann noch dediziert irgendwelche Ports zu "sperren" ist Unsinn. > Eben nicht. Eben doch! Lies mal in de.comp.security.firewall mit oder such dir die passenden Threads aus http://groups.google.com/ raus. > Du läßt ja auch deinen Safe nicht offen stehen, weil sowieso keiner deinen > Haustürschlüssel hat. Falscher Vergleich. Du musst den Safe nicht mit tausenden von Schloessern versehen, wenn nichts drin ist (kein Port von einem Dienst gebunden ist). [...] > > > Er hat deutlich mehr Features und deutlich weniger bekannte Probleme. > > Was bringen dir die neuen Features von iptables > Rate-limits. Beispielsweise fuer ICMP kann das der 2.2´er Kernel auch ohne den Filter. Fuer andere Protokolle ist der Nutzen mehr als Fragwuerdig. Siehe weiter unten: > Zustandsbehaftete Filterregeln. Bringen welchen Vorteil? > Richtiges NAT (nicht nur IP > Masq). Nur in bestimmten Spezialfaellen wichtig (ich schreib ja auch nicht, iptables sei schlecht). Normalerweise will man aber kein NAT und auch kein Masquerading (was ja nur eine Untergruppe von NAT darstellt). > Port-Forwarding an andere Rechner/IPs. Mit ipchains alleine so nicht moeglich. Allerdings gibt es dafuer bewaehrte und sichere Loesungen und die schon lange. > Flexibleres Modulsystem > (ipchains ist weiterhin komplett vorhanden, und zwar als sub-Modul von > ipfilter!). Wenn ich mir beispielsweise nur die aktuellsten Probleme damit ansehe, will ich das nicht auf Systemen, die der Sicherheit dienen. Und nochmal: KISS: (http://cert.uni-stuttgart.de/archive/bugtraq/2001/07/msg00257.html) > Das fällt mir so spontan ein. Das kann in vielen Situationen sehr, sehr > nützlich sein. Ich denke, die Features, die iptables mitbringt und ipchains nicht, sind nur in wenigen Spezialfaellen wirklich wichtig und auch da faellt mir einfach kein Fall ein, in dem man das nicht auch mit ipchains und zusaetzlich kleinen Helferlein genau so gut loesen koennte. > Wie verhinderst du z.B. einen DoS? Das kommt auf den DoS an. Viele kann man nicht auf einem Paketfilter verhindern. > Ich würde z.B. ab einem > bestimmten Limit von einer böse ausschauenden IP einfach für die nächsten > YY min nur noch XX kb/sec oder ZZ Pakete/sec akzeptieren. Und schon hast Du ggf. einen Webserver von saemtlichen T-Online Kunden abgeschnitten, die ueber einen Proxy kommen. Auch ein DoS Angriff. Ich fahre ihn eben ueber diesen Proxy und kann so millionen von Kunden aussperren. Ganz gefaehrlich diese ueberlegung. Damit hatten wir auch viel zu tun. > Mit ipchains ist das m.W. nicht so ohne weiteres (i.e. wrapper-skripte, > externe programme) möglich. Siehe oben. Einen DoS oder gar dDoS Angriff abzuwehren, ist moeglich, aber in den seltensten Faellen am Paketfilter. Da muss man viel frueher ansetzen. > Ach ja: ipfilter wird aktiv entwickelt. ipchains wird nur noch gepflegt. Wenn die Features von ipchains ausreichend sind und die Pflege nur der Verbesserung der Implemetation diehnt, ist das doch voellig ok. Wozu ein neues Feature, welches fuer die Sicherheit meiner Systeme nicht unabdingbar ist? Die Codemenge wird erhoeht und damit die potentielle Gefahr von Fehlern. KISS! > > und wirkt sich ein mehr an Code wirklich positiv auf die Sicherheit aus? > > Nein! > Du pauschalisierst. Darf ich dich zitieren: > --------------------------------------------------------------------------- > > Ausserdem ist so eine Pauschale Aussage einfach falsch. > --------------------------------------------------------------------------- Du darfst zitieren, aber nicht aus dem Zusammenhang reissen: Es ist pauschal, aber es ist nicht falsch davon ausugehen, dass ein Mehr an Code die potentielle FGefahr von Fehlern erhoeht. Wenn das Mehr an Code die Sicherheit (durch die mitgebrachten Features) nicht deutlich erhoeht und zwar _sehr_ deutlich, ist es potentiell eine Gefahr und damit abzulehnen. > > > mich ist das ebenfalls eine Verbesserung. > > In wie fern? > Siehe oben. Ich sehe keinen Zusammenhang. Bitte erleutere das. Oben stehen Features, aber nicht der definitive Gewinn an Sicherheit, der damit einher gehen soll. > > > > Ich fuer meinen Teil werden keinen 2.4´er Kernel fuer Paketfilter > > > > einsetzen. > > > Das ist deine Sache. > > Das steht auch so da. > Dann ist ja gut. Hoer mal, es macht doch keinen Sinn, bei einer Diskussion, bei der es um die Sicherheit von Systemen geht, den Anderen durch solche DInger versuchen anzugreifen. Ich habe von Anfang an deutlich gemacht, dass _ich_ Kernel 2.4.x nicht einsetze und erst Recht nicht auf Systemen, die der Sicherheit dienen sollen. Ich habe deutlich gemacht, warum ich das nicht tue und ich habe erst Recht _von Anfang an_ klar und deutlich gemacht, dass es sich um _meine Meinung_ handelt und _ich das so mache_ und mehr war da nicht. Was sollen deine plumpen Versuche also? > > > > Ausserdem ist so eine Pauschale Aussage einfach falsch. > > > Du kannst natürlich auch sagen, er wurde komplett ersetzt, anstatt > > > verbessert. Von mir aus. > > Ich finde eine pauschale Aussage, iptables sei besser als ipchains falsch > > bis gefaehrlich. > Sie ist halt nich zu 100% richtig, sondern vielleicht nur zu 98%. Nein, so pauschal ist sie zu 100% falsch. Differenziert erleutert kann sie fuer bestimmte Szenarien richtig sein. Aber pauschal und undiffernziert ist sie falsch. > Mir fällt > zwar keiner ein, aber es gibt sicher noch Gründe, ipfilter nicht zu > benutzen. Vielleicht nennst du mal ein paar konkrete. Es ist neuer, es ist groesser und es bietet _mir_ (und bei Szenarien, die mir in den Sinn kommen) keinen Gewinn an Sicherheit. Warum sollte ich es also einsetzen? Was bringen mir stelful paketfilter? Wo ist der Gewinn an Sicherheit? Wo ist der Mehrwert? Gruss, Guido -- Irgendjemand von SuSE schrieb: "We will not offer a fully installable evaluation version of SuSE Linux, as too many people damaged their MS-windows partition with it." Quelle: http://www.linuxiso.org/news.html
Attachment:
pgprYRLaQ4MKc.pgp
Description: PGP signature