Wie verhinderst Du so etwas unter IPv4? Wenn jemand root-Zugriff auf seine Maschine hat, dann musst Du sowieso (ob v4 oder v6) am Port, wo der Rechner h�ngt, verhindern, dass so etwas m�glich ist. Deswegen sehe ich dort auch nicht, warum das problematisch ist. Ich w�rde einfach Dein IPv4-Sicherheitsmodell (soweit dies f�r Deine Szenarios existiert) auf IPv6 �bertragen, denn dort verhindert Ihr solchen Missbrauch doch sicher auch.Wenn Du in einem Hosting-Umfeld Servern IPs gibt, moechtest Du verhindern, dass der Kunde, weil er root auf seiner Maschine hat, sich mal die IP des Nachbarn als Alias greift.
Naja, wie Du nun die Rechner aus der gleichen Broadcast-Domain heraus nimmst oder wie Du genau filterst, ist Jacke wie Hose. Wenn die nicht mehr in derselben BD sind oder wenn gefiltert wird, kann ein Rechner so viel RAs br�llen, wie er will. Es h�rt ihn halt keiner mehr. Aber wie gesagt, ich sehe hier keinen Unterschied dazu, wie die Situation unter v4 ist.Dazu kannst Du auf Switch-Ebene mit VLANs usw arbeiten, aber das reicht nicht (so meine theoretische Denke, an der Praxis fehlt's noch).
Warum die /128? Welchen Sinn macht die?Switch, festgebrannte ether/Port-Maps. Dann: Zwei Server, jeder mit /128 fuer sich selbst und /64 fuer virtuelle Server auf der Maschine.
Ergebnis: Wenn nicht statisch geroutet, koennte ein RechnerDas kann er doch auch, wenn Du statisch routest. Wenn auch nur einer der Nachbarn auf RAs lauscht, bist Du sowieso im Ges��. Du kommst so oder so nicht ums Filtern bzw. Trennen der Broadcast-Domains herum. Und dann ist es immer noch so, dass Du das Problem analog mit IPv4 auch hast, wenn ein Kunde seinem Server beliebige IPs vergeben kann.
jetzt per RA sagen: Das /64 oder eine more-significant-route des Nachbarn,
das schickt Ihr zu mir.
Ich halte dynamische Adressen fuer Boese(tm) 8-)Oft geh�rt, genau so oft dr�ber geg�hnt. ;-P
Entfaellt wg. unsicher. Kunden-Geraete sind untrusted devices.Ja, aber die sollen ja auch keine RAs machen. Das sollen *Deine* Router machen. :-) Und RAs der Kunden kannst Du doch filtern (IPv6-ICMP Typ 134). Ich sehe einfach das Problem nicht.
Was hindert ihn daran, das auch unter IPv4 zu tun? Das ist vielleicht ein Grund, warum man Kunden keine Zugriffe auf Interfaces erlauben sollte, aber kein Grund, warum RAs oder DHCP zur Adressvergabe an die Server nicht taugt. Erlaube doch einfach auf den Ports, an denen ein Server h�ngt, ausschlie�lich Verkehr mit den per DHCPv6 vergebenen Adressen. Dann kann der Kunde sich so viele andere IPv6-Adressen geben, wie er lustig ist.Was hilft DHCP, wenn der User sich seine Interface-Alias usw einfach selbst schnitzt ? D.h.: Entfaellt wg. unsicher.
Naja, aber der Einwahlkunde bekommt einen /48er-Pr�fix -- wie vergibt er denn dann ergonomisch die Adressen in seinem Firmennetz? Es ist doch nicht kundenfreundlich, wenn er die alle per Hand konfigurieren muss. Wenn er's leicht haben soll, macht er RAs, und dann ist Prefix-Delegation per DHCPv6 einfach bezaubernd (und bei Cisco-Hardware AFAIK schon implementiert).Bei Dialup bekommen die eh per radius ihre IPs. Die werden den Usern dann auch noch per DHCP usw mitgeteilt, aber das ist eher "Durchreiche".
Ich kann wieder nur sagen: passiert nicht bei RAs und passiert auch nicht mit Privacy Adressen. Es kann niemand bei simplen per RA ermittelten Adressen der Hosts raten, welche Host-IDs in einem Netz wirklich vergeben sind. Damit muss er das /64 mindestens scannen. Und dazu: siehe n�chsten Abschnitt.Siehst Du, da habe ich meine Zweifel. Wenn die ganze (ISP-)Welt ihre IPs nach simplen Strickmustern vergibt, kannst Du so weiterscannen wie bisher: Einfach die ersten paar tausend Adressen beginnend bei SubTLA (/32) Grenzen.
Da gibt's nichts mehr unrentabel zu machen. Wenn Du ein /64er von au�en scannen willst, brauchst Du eine Anzahl von Jahren im Milliarden-Bereich bei einem Ping im Millisekunden-Bereich. ;-)Und weil ich *das* unrentabel machen moechte, deswegen will ich die Rechner im /32 schoen verteilen.
Es lohnt sich auch ohne die Ma�nahmen nicht. Wenn Du alle paar Jahre in einem Pr�fix einen Rechner findest, wenn Du das Netz stumpf abscannst, dann kann man das nicht als effizient bezeichnen. Aber die Diskussion �ber den Sinn oder Unsinn von Scans in IPv6-Netzen ist m��ig, denn wenn ein Rechner nach au�en hin konsequent gesch�tzt wirst, dann ist es schlicht egal, ob er bei einem Scan gefunden wird.Das machen wir sowieso, es geht aber darum, die Erfolgsquote von Scans fuer den Scanner niedriger zu machen, so dass es sich fuer ihn einfach nicht lohnt.
Ja, Du hast Recht, ich habe da etwas durcheinander geworfen.Nein. Ein /48 bekommt jede Kundensite -- so war v6 eigentlich gedacht, so mein Eindruck.
Eine Leitung kann ein dialup sein, oder auch eine 2Mbit Strecke.S.o., /48 ist da richtig. Auch vor diesem Hintergrund nat�rlich.
Warum soll der Kunde renumbern, wenn er das Uebertragungsmedium wechselt ?
Und? Ich kann einfach die Gefahr nicht sehen. Wenn das Netz, wie Du ja selber sagst, vern�nftig gesch�tzt ist (Firewall, sinnvolle Filterregeln), dann gibt es kein Problem.Na, wenn ich und Kunden in ihrem Ethernet immer dieselbe relative IP als GW verwenden (z.B. immer die erste oder immer die letzte im Subnetz), dann ist ein Scannen nach genutzten Netzen deutlich einfacher (ein /16 Scan findet in einem /32 SubTLA alle aktiven Ethernetze).
Wenn es nicht trivial ist, die gateway-IPs zu finden, muss der AngreiferIch sehe den Grund f�r diese Art der Vergabe von IPs nicht, aber das ist Geschmacksache. Wobei ich bleibe, ist: das ist "Security through obscurity". Ein Netz muss auch dann einem Angriff Stand halten, wenn man die Obscurity au�en vor l�sst. Und wenn das gegeben ist, macht Obscurity keinen Sinn und f�gt auch keine Sicherheit hinzu, und dabei bleibe ich.
das gesamte /32 scannen, das wird ihm nicht so einfach gelingen.
Gru�, 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
