> > Ein L3-Interface pro Kunde. Alles andere ist beliebig exploitbar. > Bitte deutlicher erklaeren, was Du damit meinst (L3 pro Kunde) ? > - Ich habe einen Router, der z.B. ins webether zeigt. > - Angeschlossen an einem Switch, jeder Kundenrechner bekommt > ein VLAN, alle VLANs zeigen auf den Router-Port. > Meinst Du jetzt: Jeder Kunde bekommt einen eigenen Router-Port ? Es ist eigentlich v�llig egal, wie Du es machst, aber Du musst die Ports auf L3-Ebene irgendwie trennen. Du kriegst die Gefahr nicht beseitigt, solange die Ports alle in derselben Broadcast-Domain liegen.
> Wenn Du beides versteckst, ist das genau dann schluessig, wenn > die Zahl der Scans zurueckgeht. Aber wir versuchen Dir doch zu erkl�ren, dass die Scans eh nix bringen und dass das absolut keinen Unterschied macht, ob Du was versteckst, oder nicht. Aber wenn Du die Arbeit unbedingt investieren willst, dann mach es. ;-) > Allerdings ist das kaum messbar, denn: ein ISP mit linearer Adressvergabe, > einer mit zufaellig, da gibt's so viel, das dazu reinspielt, > dass kaum belastbare Kennzahlen rauskommen werden. Den Satz verstehe ich nicht. Das �ndert nichts an der Tatsache, wie ineffizient stumpfe Scans sind. Und das scannende Script-Kiddie wei� doch a priori gar nicht, wie die Adressen in dem Subnetz vergeben sind, das es scant. > Wenn ein Kunde im LAN ::1 usw vergibt, kann ich ihn nicht hindern, > empfehlen wuerde ich's trotzdem nicht. Wenn die entsprechenden Server aber vern�nftig gesichert sind, dann spricht absolut nichts gegen die Vergabe. Abgesehen davon: wenn die Dinger im DNS stehen, verstehe ich Deine Argumentation sowieso nicht. Dann kannst Du doch anstellen, was Du m�chtest, dann braucht doch niemand zu scannen, um den Server zu finden. Dann hast Du eh keine andere Wahl, als den Server zu sch�tzen. > Haengt an der Kundenstruktur, aber ich kann einer Kleinfirma nicht > erklaeren, dass sie einen DHCPv6 Server braucht, der irgendwohin > mitlogged, damit sie wissen, wer's war, wenn was Boeses(tm) passiert. Wo haben Gert oder ich geschrieben, dass der Kunde einen DHCPv6-Server braucht? Und wie soll das m�glich sein, dass er "mitloggt", ob Missbrauch geschieht? Der DHCPv6-Server wei� doch nur �ber Leases Bescheid. Du fragtest nach Adress-Vergabe. Die kannst Du als ISP bis dahin machen, wo der Kunden-Router anf�ngt. Als Option steht Dir daf�r bis zum Kunden-Router z.B. DHCPv6 zur Verf�gung (ggf. sogar bis ins Kunden-Netz, wenn Du Relay-Agents einsetzt -- das k�nnte man sich sogar als Dienst vorstellen, der verkauft werden kann, vorausgesetzt, die entsprechenden Ger�te tauchen bald auf). Aber niemand hat gesagt, dass beim Kunden ein DHCPv6-Server aufgesetzt werden muss. > Die haben schon Probleme mit Steckdosen, arg viel komplizierter > darf's nicht werden. Da bieten sich doch RAs wunderbar an. Die von Dir vorgeschlagene statische Vergabe ist doch dagegen f�r einen solchen Kunden ein kaum zumutbarer Aufwand. > Deine These: Scans wird es sowieso nicht geben, weil es sich nicht lohnt. Das hat Gert so nicht gesagt. Geben wird's die m�glicherweise, aber viel rumkommen wird dabei nichts. Ob es sie nicht geben wird, da kann man sowieso nur dr�ber spekulieren. Rechnen musst Du aber so oder so damit. > Meine These: Scans wird es weiterhin geben, weil die Kunden mit ::1 usw > anfangen. Dann bringt's auch nichts, Adressen zu verschleiern, oder? Das wird niemanden daran hindern, trotzdem bei Dir zu scannen. > Ein Beweis wird schwierig, ist also ein Streit um Kaiser's Bart. Da gibt's nichts zu beweisen. Du verfolgst nur eine Philosophie, die wir offensichtlich nicht nachvollziehen k�nnen. Wir sehen nur, dass Du Dir einen Kopf um Dinge machst, die Du mit Deiner Adressierungsstrategie so oder so nicht beeinflussen k�nnen wirst. Aber des Menschen Willen ist sein Himmelreich. Wenn Du ein besseres Gef�hl hast, IPs zu verschleiern und das praktikabel f�r die Kunden hin bekommst, dann mach es. Aber ich sehe nicht, dass da die Kosten-Nutzen-Rechnung auf geht. Verhindern oder verringern wirst Du Scans damit nicht (und das sagst Du ja auch selber mit Deiner These), Im Prinzip wollen wir Dir nur die Arbeit ersparen. :-) 'nuff said. Christian -- JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf�lische Wilhelms-Universit�t M�nster http://www.join.uni-muenster.de Zentrum f�r Informationsverarbeitung Team: [EMAIL PROTECTED] R�ntgenstrasse 9-13 Priv: [EMAIL PROTECTED] D-48149 M�nster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31653 _______________________________________________ ipv6 mailing list [EMAIL PROTECTED] http://listserv.uni-muenster.de/mailman/listinfo/ipv6
