Moin Gert und Liste,
Gert Doering <g...@space.net> writes:
> Gegen das Argument der fehlerhaften Implementierung hilft nur "das
> Device vom Internet trennen, abschalten, und zu Staub zermahlen" - denn
> das ist kein Problem von *ICMP*.
das ist zu einfach. Warum setzen wir Firewalls und ähnliche Sachen
überhaupt ein? Um bei fehlerhaften oder schlampigen Implementierungen
und Konfigurationen nicht gleich mit komplett runtergelassener Hose
dazustehen.
Wenn man Deine Argumentation bis in die Absurdität weitertreibt,
bleiben nur die zwei Möglichkeiten "Abklemmen" und "ohne
vorgeschaltete Schutzmaßnahmen ins Netz". Im Provider-Umfeld ist in
weiten Bereichen die zweite Variante typisch und unvermeidbar -- aber
in dieser Hinsicht ist das ISP-Geschäft ziemlich extrem. Im
militärischen Kontext ist als anderes Extrem das Abklemmen vom
Internet durchaus gelegentlich sinnvoll und notwendig.
Der Bereich dazwischen ist der, wo Multi Level Security im allgemeinen
und Firewalls und ähnliches im besonderen eine Rolle spielen -- und
für viele von uns ist auch genau das unser Arbeitsumfeld. Abklemmen
ist da keine Option, deshalb muss man sich etwas detaillierter
überlegen, was man tut. Und der Grundsatz "nichts erlauben, was nicht
gebraucht wird" ist ein einfacher aber enorm hilfreicher Spezialfall
der allgemeineren Abwägung von Nutzen und Risiko.
Damit kann man sehr wohl fehlerhafte Implementierungen, kaputte
Betriebssysteme, inhärent unsichere Protokolle und bis zu einem
gewissen Grad auch plan- und verantwortungslose User sinnvoll schützen
-- nicht unbedingt im ISP-Umfeld, aber anderswo schon.
> Mir ist bisher übrigens auch aus dem IPv4-Umfeld kein Fall bekannt, wo
> mit off-link ICMP redirects o.ä. erfolgreich Schaden angerichtet wurde
Wenn jetzt (hoffentlich) rein hypothetisch Windows 7 ausreichend
kaputt implementiert wäre und Redirects für Angriffe großflächig
ausgenutzt würden, dann fändest Du Dich in ungefähr so einer Situation
wieder:
Manager: Ohgottohgottohgott, wie konnte das passieren?
Techniker: Ich habe Ihnen schon vor Jahren gesagt, dass das auf Dauer
nicht gutgehen kann.
Manager: Aber bisher ist nie was passiert!
Techniker: Irgendwann ist immer ein erstes Mal.
Manager: Jetzt sei endlich mal konstruktiv und mach was.
Bin ich der einzige, der solche Szenen bisher erlebt hat?
Die Argumentation "es ist bisher noch nie was passiert" ist immer
gefährlich kurzsichtig, egal ob es um das Online-Banking mit
ungeschützten Windows-2000-Rechnern, Wahlcomputer oder die tägliche
Raserei mancher Berufspendler auf dem Weg zur Arbeit geht.
Außerdem gibt es einen fundamentalen Unterschied zwischen IPv4 und
IPv6 bei den Redirects:
Bei IPv4 darf ein Host passiv im dynamischen Routing mithören und
seine Routing-Tabelle entsprechend pflegen, solange er nicht selbst
irgendwelche Mond-Routen verkündet. Bei IPv6 ist das nicht vorgesehen
und wird auch von keinem Routing-Daemon, den ich mir näher angesehen
habe, in irgend einer Weise unterstützt -- die beenden sich alle
RFC-konform gleich wieder, wenn das Forwarding ausgeschaltet ist.
Die Routing-Tabellen auf Hosts in Verbindung mit Autoconfiguration
bestehen aus einer Liste von Default Routes und temporären Host
Routes, die durch Redirects gepflegt werden. Deshalb kann man aber
(abhängig von der Netztopologie) auf Host-Seite so einfach Redirects
nicht mehr ignorieren.
Damit liegt im Zweifelsfall die Aufgabe bei vorgelagerten
Paketfiltern, diese Art von Zauber zu verhindern, wenn die
Implementierung dahinter nicht sauber ist.
Zugegeben, es gibt genug andere und größere Baustellen, wenn's um
Internet-Unsicherheit geht, aber wenn wir das Thema jemals in den
Griff bekommen wollen, müssen wir allmählich mal anfangen, Sachen so
systematisch zu erledigen, dass sie anschließend auch vom Tisch sind,
statt immer nur Hotfixes einzuspielen. Wenn ich in einem
vorgeschalteten Paketfilter Redirects von außen zumache, muss ich mich
da nie mehr drum kümmern; die einzigen Nachteile sind die etwas
aufwendigere und marginal weniger effiziente PF-Konfiguration.
> - aber es wird unglaublich Panik geschoben, und mit "Oh Gott, ICMP ist
> so böse!" ein immenser Schaden angerichtet.
Womit wir wieder bei der Aufgabe wären, Leute aufklären zu müssen.
In den Workshops bei mir kommt immer wieder auch das Thema Paketfilter
auf. Wenn's um ICMP6 geht, ist das die Gelegenheit, um in zehn bis
fünfzehn Minuten die Liste der relevanten ca. 15 ICMP Types
durchzugehen und zu besprechen, was man unter welchen Bedingungen
durchlassen muss (damit alles funktioniert) oder will (um sich das
Leben zu erleichtern). Danach ist das Thema im wesentlichen durch.
Das Schöne an IPv6 ist, dass mit komplett geblocktem ICMP6 eben gar
nichts mehr funktioniert, also Leute gezwungen sind, sich ansatzweise
Gedanken zu machen. Und zugegeben, alleine durch die Scopes wird
schon viel Ärger verhindert, solange sich die Implementierungen an die
Regeln halten.
Das einzige "Restproblem" das bleibt, sind Leute, die ICMP nur von
Link-Local-Adressen zulassen (und damit den Ärger mit der Path MTU
Discovery verursachen) und diejenigen Hersteller von User Grade
Equipment, die sich bei den Voreinstellungen und beim User Interface
zu wenig Gedanken machen. Wobei die Thematik rund um die Path MTU
Discovery wirklich unschön ist, weil Ursache und Folgen zu weit
voneinander getrennt sind.
Viele Grüße, und ein schönes Wochenende,
Benedikt
--
Business Grade IPv6
Consulting, Training, Projects
Benedikt Stockebrand, Dipl.-Inform. http://www.benedikt-stockebrand.de/
--
ipv6 mailing list
ipv6@listserv.uni-muenster.de
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
