Serverloft: Netzsicherheit

[Whistler]

Solche "Lösungen", die manuelle Intervention erfordern, sind immer schlecht. Was ist nachts, was ist Weihnachten, was ist während der Schulferien?

Ich persönlich bevorzuge es, derartige Schwachstellen "by design" auszuschließen statt dann dem Verursacher hinterherzurennen.

Von daher würde ich jeden Hosting-Anbieter, der nicht 255.255.255.255 als Netzmaske angibt, erstmal mit Vorsicht beäugen.

So kompliziert ist der "Ein VLAN per Kunde"-Ansatz nicht, es gibt Switche für wenige hundert Euro (z.B. HP Procurve), die das können.

 

[kju]

Solche "Lösungen", die manuelle Intervention erfordern, sind immer schlecht.

Ich stimme zu. Wenn es denn stimmt, daß man solche Vorfälle automatisch feststellt, dann kann man ja auch den fraglichen Switchport per Management-Interface dichtmachen (außer man hat Billig-Switche wie so mancher Anbieter).

Von daher würde ich jeden Hosting-Anbieter, der nicht 255.255.255.255 als Netzmaske angibt, erstmal mit Vorsicht beäugen.

Eine /32-Netzmaske sagt überhaupt nichts aus. Ein sauberes und sicheres Setup ist mit und ohne möglich, ein unsicheres genauso. Eine /32-Maske hat aber den schönen Vorteil, daß man den Broadcast-Verkehr zwischen den Ports unterbinden kann, da die einzige ARP-Anfrage vom Client nach dem Gateway kommt und nicht auch nach anderen IPs (Servern) in seinem Subnetz.

So kompliziert ist der "Ein VLAN per Kunde"-Ansatz nicht, es gibt Switche für wenige hundert Euro (z.B. HP Procurve), die das können.

Das ist eine andere Option. Eine statische ARP-Tabelle am Gateway, idealer- aber nicht notwendigerweise in Kombination mit /32-Masken tuts aber auch und sollte mit jedem besseren Router machbar sein.

 

[Whistler]

Eine /32-Netzmaske sagt überhaupt nichts aus.

Sie ist nur ein Indiz. Jedenfalls legt sie eher die Vermutung nahe, daß sich der Anbieter über Netzwerksicherheit Gedanken gemacht hat, als eine /24.

Eine statische ARP-Tabelle am Gateway braucht man sowieso (es sei denn, man ist sehr blauäugig), im Idealfall wird jeweils genau eine IP (+ ggf Zusatz-IPs) in ein VLAN auf den Aggregation Switch geroutet.

So hat man gleich auch allen Nicht-IP-Traffic (es ist lustig, beim Sniffen z.B. STP oder VRRP-Pakete zu sehen) und die Broadcast-Thematik erschlagen.

Und falsche Pakete "gegen die Wand" rennen zu lassen, statt jedesmal einen Supportcase zu erzeugen, spart durchaus auch Arbeit (sowas kann beim Herumspielen mit virtuellen Maschinen schnell auch mal versehentlich entstehen).

 

[charon]

Wer es testen will kann, ja mal proxyarp auf dem eth0 interface aktivieren. Aber bitte die Konsequenzen einplanen....

Das ganze Subnetting und die Macfilterung sind einfach nur nervig wenn man virtualisieren will.

Ich konnte das so lösen, indem ich einfach selbst intern alles route und dann auf eth0 auf alle mir zugehörigen Mac Adressen bei arp - requests antworte.
Ich setze also alle arp Einträge mit einem Script selbst.

Eigentlich zuviel bastelei, aber ich wollte sehen, ob es überhaupt geht.

 

[kju]

Das ganze Subnetting und die Macfilterung sind einfach nur nervig wenn man virtualisieren will.

Es geht in diesem Thema darum, mehr Sicherheit zu erreichen und nicht weniger. Wenn die Switch-Ports jede MAC-Adresse zulassen würden, würde Mißbrauch fremder IPs noch einfacher und schwerer nachvollziehbar. Außer man baut das Netzkonzept um.

(Preiswerte) Mietserver sind für Virtualisierung einfach nicht der geeignete Ort, da muß man halt woanders hingehen. Ich habe zwei Server in einer Co-Lo in Düsseldorf, dort habe ich mein eigenes VLAN (für beide zusammen) in welchem (nur und nur dort) meine IPs landen (gerade eben weils ein Subnetz ist) und meine MAC-Adressen niemand interessieren. Das kostet dann aber auch mehr.

Man begibt sich bei den Virtualisierungslösungen aber auch durchaus auf dünnes Eis wenn man bridged, denn die MAC-Adressen der virtuellen Maschinen werden generiert und dabei sind Kollisionen nicht ausgeschlossen.

Ich konnte das so lösen, indem ich einfach selbst intern alles route und dann auf eth0 auf alle mir zugehörigen Mac Adressen bei arp - requests antworte. Ich setze also alle arp Einträge mit einem Script selbst.

Das ist nicht nötig. Es genügt Proxy-ARP zu aktivieren und jeweils Host-Routen für die weiteren IPs zu haben. Der Kernel antwortet dann schon von alleine. Das geht z.B. bei XEN mit dem vif-route und network-route Skripten.

Hab ich auch so bei Serverloft am Laufen, keine Probleme. Hat übrigens den Vorteil, daß keiner der eigenen vServer eine andere IP übernehmen kann, weil er die Pakete nicht geroutet bekäme. Das kann man bei Bridging auch hinbekommen z.B. mit ebtables, macht aber kaum jemand (hab da mal eigene Skripte für Xen für geschrieben).

 

[wstuermer]

Hallo kju,

sicherlich magst du recht haben, dass es einfacher ist, ProxyARP zu aktivieren anstatt jede IP separat zu routen. Ich persönlich würde aber auf direktes Routing bzw. neighborhood-solicitation setzen.

Solange du alleine die VEs managed geht ProxyARP ok ... aber wenn dein Kunde innerhalb der VE eine IP hochfährt wird diese dann ebenfalls geproxied und wenn die /24 ist, proxied er u.U. tatsächlich /24 komplett.

Das passiert halt nicht, wenn du das mit neighborhood-solicitation machst.


-W