Hallo Janto, At 30.07.2001, Janto Trappe wrote: > * Guido Hennecke <g.hennecke@t-online.de> [30-07-01 12:14]: [...] > > Ich rede nicht von einer ACEPT Policy! > "brauche ich den nicht weiter durch Filterregeln absichern" hoert > sich aber so an. Nein, mit Filterregeln meine ich Filterregeln und nicht die Policy fuer eine Standard Chain. > > 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? Wenn ich keine Dienste anbiete, lautet eine der ersten Regeln der Input Chain fuer das Interface am Fremdnetz eben: REJECTE alle TCP Pakete mit gesetztem Syn Flag. Fuer TCP hat sich damit schon fast alles erschlagen. Ich filtere zusaetzlich noch RFC 1928 raus (da ein Paket von und zu einer solchen Adresse nicht legitimerweise aus dem Internet (bei meinem Fall) kommen kann). Entweder handelt es sich bei solchen Paketen um eine Fehlkonfiguration oder einen Angriffsversuch. Ausserdem kann ich (in meinem speziellen Fall (jede Firewall ist Massarbeit)) alle TCP Pakete an Ports unterhalb von 1024 ebenfalls verbieten. Den Rest kann man eigentlich schon durchlassen. Vielleicht noch Alway defragment einschalten und Fragmentierte Pakete verbieten. Viel mehr ist bei mir nicht notwendig (TCP). Bei der TCP/IP Implementierung von Linux muss man noch beruecksichtigen, dass prinzipiell alle IP Adressen des Routers aus allen Netzen erreichbar sind und man Regeln braucht, die eben Pakete an die Adressen der Internen Netze dediziert verbietet - aber ansonsten hat man damit TCP bereits erschlagen. Unterhaelst Du dann keinen UDP Dienst, der nicht auf ein Interface zu binden ist, kannst Du UDP eigentlich offen lassen (ein offener Port ist ein Port, an dem ein Dienst angeboten wird und nicht ein Port der nicht gefilter wird). Die meisten Regeln habe ich fuer das Interne Netz auf das Apllication Level Gateway, weil es sehr viel komplzierter ist, den Verkehr auf bestimmte Dienste zu reglementieren. Fuer jede Regel sollte man sich _genau_ ueberlegen, was man damit denn nun erreichen kann und will. Und was kann man damit erreichen, ein TCP Paket ohne gesetztes Syn Flag zu verbieten? Gut, man kann seine Netzinfrastruktur etwas verbergen (nicht sehr sicher). Aber ist es nicht sinnvoller, seine Systeme so zu konfigurieren, dass die Infrastruktur offen luegen kann, weil sie sicher ist, anstatt seine Regeln aufzublasen und dann an einen Punkt zu kommen, an dem ich mich einmal wiederfand (ich hatte irgendwann Probleme, durch meine eigenen Filter durchzusteigen, weil ich wirklich _alles_ (egal warum und egal, was davon fuer eine Gefahr ausgeht) filtern zu wollen)? > > > > > > 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. Aber nicht dediziert mit eigenen Filterregeln sondern alles was durch dein Reglementarium faellt, wird (nicht geblockt!) REJECTET. Blocken, wegwerfen (also DENY) setze ich nur bei Regeln ein, bei denen ich nicht davon ausgehen kann, dass die ICMP Antwort auch den Sender erreicht. Beispielsweise bei IP Spoofing. > Oder war mit obiger Aussage das Sperren von Ports, mit extra ipchains > Regeln, bei einer DENY Policy (also doppelt) gemeint? Genau. Allerdings setze ich die Policy auf REJECT und DENYe dediziert Pakete, bei denen ein REJECT keinen Sinn macht. Siehe oben. > Dann wuerde ich > Dir recht geben, aber darum ging es ja nicht. Dann habe ich wohl was falsch verstanden? > > > > > 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. Also vergessen wir das oder gibt es sinnvolle Ansaetze? [...] > > 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. Liest Du Bugtraq? Hint Kernel 2.0.x und Kernel 2.2.x haben da jetzt auch was nettes ;-) Ich stehe auf dem Standpunkt: Entweder ich kuemmere mich um die Sicherheit an meine Paketfilter, nehme das ernst und seze das _konsequent_ durch, oder ich kann mir die Muehe gleich sparen. Ob ich eine Tuer offen lasse, oder mehrere, das spielt nicht die grosse Rolle. > > > > (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. Was fuer eine Rolle spielt das bei einem kritischen System wie dem Paketfilter? Gruss, Guido -- I like BOTH kinds of music.
Attachment:
pgpCz4FS_u3ur.pgp
Description: PGP signature