Hi,

On Tue, Jan 13, 2004 at 02:15:58PM +0100, Kurt Jaeger wrote:
> > Aus Deinen Schilderungen kann ich im Moment nicht ganz ersehen, was das 
> > exakte Problem ist, das Du umschiffen willst.
> 
> 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.
> 
> Dazu kannst Du auf Switch-Ebene mit VLANs usw arbeiten, aber das
> reicht nicht (so meine theoretische Denke, an der Praxis fehlt's noch).

Das reicht wunderbar.  

Jeder Kunde ein eigenes VLAN, darauf ein /64, Thema durch.

(Natuerlich setzt das Switches voraus, die die VLAN-Trennung auch strikt
einhalten - wenn ein Switch das nicht tut, ist er falsch konfiguriert
oder buggy)

> Beispiel:
> 
> 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 Rechner
> jetzt per RA sagen: Das /64 oder eine more-significant-route des Nachbarn,
> das schickt Ihr zu mir.

RAs informieren angeschlossene *Clients*, welche Prefixe und Router
es in einem LAN gibt.  Wenn ein Rechner RAs rausschickt, verwirrt er
damit andere Rechner im selben LAN (die aber nach o.G. Modell demselben
Kunden gehoeren, er kann sich also genau selbst ins Knie schiessen).

Router ignorieren RAs.

(Ausnahme: Client-seitige Router, die als "dynamische Adressierung
zum ISP hin" konfiguriert sind, das ist aber hier nicht der Fall).

> > Wenn Du nicht moechtest, 
> > dass der EUI-64-Teil die konvertierte MAC enthaelt, musst Du halt die 
> > Privacy-Extension verwenden (etwas unguenstig fuer Reverse DNS) oder 
> > direkt DHCPv6.
> Ich halte dynamische Adressen fuer Boese(tm) 8-)

Ich auch, aber fuer die Adressierung der Server primaer deshalb, weil
sie *unpraktisch* sind.

Fuer die Clients sind sie, in Verbindung mit einem brauchbaren 
Mechanismus fuer DNS-Updates (und der Sicherheit, dass kein Rechner 
im Netz "rogue" RAs verschickt - hier ist noch ein Problem), ausnehmend 
praktisch.

[..]
> > (1) RA <- ist sicher a priori die einfachste Moeglichkeit, weil sie ein 
> > Minimum an Konfigurationsarbeiten erfordert. Dann ist allerdings zu 
> > bedenken, dass die RAs vom Router des Kunden gemacht werden. In wieweit 
> > Ihr da Einfluss drauf habt, weiss ich nicht, aber das sollte man auf 
> > jeden Fall bedenken. Hier hast Du auch nur mit der Privacy Extension 
> > die Moeglichkeit, die EUI-64-Adresse aus der IP zu nehmen. Ueber den 
> > Sinn, das zu tun, kann man sich streiten.
> 
> Entfaellt wg. unsicher. Kunden-Geraete sind untrusted devices.

Fehler im Denkmodell.  Das RA schickt der ISP-Router.  Der Kunde kann den RAs
zuhoeren oder es lassen.  Der ISP-Router ignoriert RAs - das beeintraechtigt
die dynamische Adressierung der Hosts nicht (sondern ist eh' der Normalfall).

[..]
> Was hilft DHCP, wenn der User sich seine Interface-Alias usw
> einfach selbst schnitzt ? D.h.: Entfaellt wg. unsicher.

Du musst die Trust-Boundary einfach anders ziehen:

 - Kunden-Interface (dediziertes Layer3-Interface pro Kunde, keine(!!)
   "shared hosting"-Segmente)
 - Prefix (/48 oder /64)
 - reverse path filtering

 - was der Kunde da drin macht, ob er DHCPv6 macht, RAs akzeptiert, 
   seine Sachen statisch konfiguriert, usw., ist dem ISP *egal*.  

   Es gibt keinen Angriffspunkt auf die ISP-Infrastruktur, und wenn der
   Kunde sich die falschen Adressen gibt (spoofing), funktioniert es
   einfach nicht.

> > (3) Stateless DHCPv6 mit Praefix-Delegierung <- Ein nette Moeglichkeit 
> > besonders fuer Einwahlkunden: der Einwahlrouter ist DHCPv6-Client und 
> > fragt den ISP-DHCPv6-Server nach einem Praefix, den er im Kundennetz per 
> > RA announcen soll.
> 
> 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".
> 
> Btw: kennt jemand bezahlbare ISDN/Modem Dialup-Router, die schon
> IPv6 koennen ?

Cisco oder Linux/*BSD-Buechsen... sonst kann es gar keiner, ob bezahlbar
oder nicht.

[..]
> > Ich glaube, dass Angreifer in 
> > der IPv6-Welt sich sehr bald schon vom simplen Scannen von Subnetzen 
> > verabschieden werden.
> 
> 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.

Du machst Dir irgendwie keine Vorstellung davon, *wie* gross ein /64 
ist, oder?

Selbst wenn der Angreiffer weiss, dass alle meine Kunden-Netze in meinem
/32 "linear von vorne startend" vergeben sind, muss er dann trotzdem pro
Kunde die einzelnen Hosts in seinem /48 finden - und selbst wenn er weiss,
dass die *dort* im :x:0::/64 zu finden sind, gibt es da noch (knapp) 2^64 
verschiedene Moeglichkeiten.

> Und weil ich *das* unrentabel machen moechte, deswegen will ich
> die Rechner im /32 schoen verteilen.

Du musst Deine Assignments ohnehin dokumentieren.  Damit weiss der
Angreifer, in welchen /48s was zu finden ist.

> > Es wird sicher bald andere Tricks geben, und dann 
> > wird es voellig egal sein, wie die IPs vergeben sind. Entweder, man 
> > schuetzt die Rechner aktiv, oder man laesst es.
> 
> 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.

Ein Scan auf ein /64 lohnt sich nicht - ein Treffer ist da so wahrscheinlich
wie ein 6er im Lotto...

> > >- Vorschlag zur Adressverteilung:
> > >  o Ethernetze bekommen zufaellig ausgewaehlte /48 aus dem /32-Fenster
> > Das ist dann fuer groessere Kunden, die quasi eigene Sites haben, richtig? 
> 
> Nein. Ein /48 bekommt jede Kundensite -- so war v6 eigentlich gedacht,
> so mein Eindruck.

Ja, so ist das.

> > >  o Kunden hinter Leitungen/Dialups bekommen ein zufaellig
> > >    ausgewaehltes /48
> > Hui! Das ist aber grosszuegig. Was spricht gegen einen laengeren Praefix 
> > wie /64?
> 
> Eine Leitung kann ein dialup sein, oder auch eine 2Mbit Strecke.
> Warum soll der Kunde renumbern, wenn er das Uebertragungsmedium wechselt ?
> 
> Das handhaben wir derzeit im v4 auch so.

Auch Dialup oder DSL-Kunden duerfen (sollen!) ein /48 bekommen, wenn
die geringste Chance besteht, dass sie jemals ein 2. Netzsegment brauchen.

[..]
> > traceroute kannst Du doch auch ueber IPv4 
> > machen. Wenn Du den Gateway schuetzen/verstecken willst, musst Du halt 
> > eine Firewall verwenden (anders geht das unter IPv4 auch nicht). Oder 
> > habe ich diesen Absatz missverstanden?
> 
> Wenn es nicht trivial ist, die gateway-IPs zu finden, muss der Angreifer
> das gesamte /32 scannen, das wird ihm nicht so einfach gelingen.

"traceroute6 -l complx.lf.net", schon habe ich ein paar Gateway-IPs.  

War jetzt nicht so schwierig, oder?

"Security by Obscurity" funktioniert nicht, ohne dabei wesentliche
Fundamente zu zerstoeren (traceroute-Funktionalitaet, reverse DNS, 
RIPE-Datenbank-Eintraege).

(Ich muss leider weg, deshalb ist obiges vielleicht etwas knapp - spaeter
mehr)

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  57882  (57753)

SpaceNet AG                 Mail: [EMAIL PROTECTED]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

_______________________________________________
ipv6 mailing list
[EMAIL PROTECTED]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6

Antwort per Email an