On Monday 11 May 2009, Grimnin Fridyson wrote:
Das ACCEPT fuer TCP ist noetig, sonst funktionieren von innen etablierte Verbindungen nicht. Das finale DROP am Ende meiner Chains ist reine Paranoia - Absicherung gegen Konfigurationsfehler.
hast du jetzt die ironietags vergessen
Nein.
weil wenn eine Regel mir erlaubt reinzugehen auch wenn sie "falsch" ist macht ein drop es nicht wieder gut
weil wie entscheidet ein "-A ineth -j DROP" über Konfigurationsfehler?
Es ist die Art der Konfigurationsfehler gemeint, bei der eine Regel *hinter* der Chain Blödsinn macht. Kleines Beispiel mit korrigierter Reihenfolge:
:INPUT DROP :ineth - :ineth2 -
-A INPUT -i eth0 -j ineth -A ineth -p icmp -j ACCEPT -A ineth -p udp -m udp --dport 123 -j ACCEPT -A INPUT -i eth1 -j ineth2 -A INPUT -i eth2 -j ineth2 -A ineth2 -j ACCEPT
Nehmen wir mal an eth0 ist aussen, eth1 und eth2 sind intern.
Sollte ich jetzt aus irgendeiner Dussligkeit heraus -i eth1 und -i eth2 als -i eth+ zusammenfassen dann habe ich den Salat, weil alles akzeptiert wird statt wie erwartet auf eth0 nur ICMP und NTP zu erlauben.
Daher ein Paranoia-DROP am Ende jeder Device-Chain. Hat auch den netten Nebeneffekt dass es Protokolle abfängt von denen ich noch nix weiß (GRE, IP-in-IP, IP/Sec, SCTP, etc.pp.).
habe nur mal kurz gelesen was mich persönlich etwas stört ist das man auf den Gedanken kommt UDP --> TCP setzen 'nur' auf IP auf
Ich hatte keine Lust alle Einzelheiten von TCP/IP zu erklären. Daher auch die Links auf Wikipedia.
Ja, TCP und UDP können auch auf IPv6 laufen und sie benutzen das Schwesterprotokoll ICMP für bestimmte Fehler und IPv4 benutzt auch noch ARP auf Link-Ebene (IPv6 benutzt da bestimmte neue ICMP-Messages).
Es ist nicht sonderlich sinnvoll ICMP oder ARP in einer Firewall zu behandeln (die Mode ICMP-Ping zu filtern ist vorbei).
Wo genau liegt Dein Problem? Was genau kann ich noch klarer schreiben? Muss ich wirklich TCP/IP Grundlagen komplett erklären?
Konrad