Ressourcenverwaltung mit Xen
Virtualisierung ist in aller Munde. Wie kaum ein anderes Thema, hat dieser Begriff in den letzten Jahren den Servereinsatz konsolidiert. Für Endkunden gibt es ganze vServer für ein Taschengeld und für professionellere Anwender bringen virtualisierte Server große Einsparpotentiale.
In der Art und Weise, wie Server virtualisiert werden, gibt es viele Möglichkeiten. Die populärste für Linux ist vermutlich Xen. Dieses besticht durch Performance, echten und paravirtualisierten Gastsystemen (bei Xen DomU genannt) und ausgereifte, einfache Handhabe im Hostsystem (bei Xen: Dom0). Das Hauptaugenmerk der Entwicklung liegt damit auf Geschwindigkeit, nicht auf Ressourcenlimitierung und Accounting. Erwähnte Hoster von vServern benutzen aus diesem Grund üblicherweise andere Virtualisierungstechniken wie Virtuozzo/OpenVZ. Diese erlauben eine umfassende Ressourcenverwaltung und die hermetische Abgrenzung von zugesprochenen Limits. Im Detail ist dies bei Xen nicht so tiefgründig möglich, wie bei OpenVZ zum Beispiel.
Verwaltung von Limits
Das heißt jedoch nicht, dass dies bei Xen nicht möglich ist. Zugegeben, die Granularität von OpenVZ erreicht Xen damit nicht, aber vieles ist ebenso umsetzbar. Da Xen tief in Linux verankert ist und vielenortes native Linux-Methoden verwendet, kann einiges jedoch mit Hausmitteln nachgerüstet oder umgesetzt werden.
Ich gehe nicht darauf ein, wie Xen und DomUs installiert und konfiguriert werden, sondern setze das viel mehr voraus. Im Folgenden ist also eine funktionierende DomU nötig, welches Betriebssystem im Gastsystem allerdings läuft, ist dafür unerheblich.
CPU
Xen nennt die CPUs “VCPU” und erlaubt standardmäßig jedem Gastsystem alle vorhandenen CPUs zu nutzen. Die einfachste und effizienteste Methode zur Ressourcenlimitierung sind hier schlicht die Anzahl an Kernen, die einer DomU erlaubt sind zu nutzen. Moderne Zentralprossesoren auf Servern haben viele Kerne und gelegentlich sogar mehrere Prozessoren, es ist daher sinnvoll und nötig eine DomU gelegentlich auf weniger Prozessoren zu beschränken. Man beachte jedoch, dass der Begriff “Prozessor” in diesem Fall von Linux synonym für echte CPU, Kern und “Hyperthreading” gleichermaßen verwendet wird.
ophelia:~$ xm vcpu-list smart.knallkopp.de Name ID VCPU CPU State Time(s) CPU Affinity smart.knallkopp.de 10 0 0 -b- 74277.5 any cpu smart.knallkopp.de 10 1 2 -b- 999.6 any cpu smart.knallkopp.de 10 2 3 -b- 860.4 any cpu smart.knallkopp.de 10 3 3 -b- 882.4 any cpu
Diese DomU benutzt also vier CPUs (im Sinne obiger Definition). Angenommen die CPU Leistung sollte reduziert werden, kann die Anzahl zugewiesener CPUs auch beschränkt werden:
ophelia:~$ xm vcpu-set smart.knallkopp.de 1 ophelia:~$ xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1032 4 r----- 6728.4 ... smart.knallkopp.de 10 2000 1 -b---- 77030.4
Das ganze ist übrigens hot-pluggable, das bedeutet, diese Einstellung kann jederzeit zur Laufzeit geändert werden. Unter Linux Gastsystemen wird diese sofort nach Änderung der VCPU-Einstellung aktiv:
smart:~$ dmesg ... [2834508.652433] SMP alternatives: switching to SMP code [2834508.660427] Initializing CPU#1 [2834508.661362] CPU0 attaching sched-domain:
Alternativ erlaubt Xen auch CPU-Pinning. Das weißt eine CPU fest einer Domain zu. In dem Fall wird Xen angewiesen eine DomU immer und ausschließlich auf den angegebenen CPUs auszuführen.
ophelia:~$ xm vcpu-pin smart.knallkopp.de 1 1
Mit xm vorgenommene Änderungen sind flüchtig, gelten also nur bis zum nächsten Reboot der Dom0 oder bis die zugehörige DomU beendet wird. Aus diesem Grund müssen Änderungen, die dauerhaft sind, zusätzlich auch in der DomU-Konfiguration vorgenommen werden. Die vcpu-set- und vcpu-pin-Einstellung kann zum Beispiel wie folgt in der DomU-Konfiguration übertragen werden:
vcpus = '4' cpus = '0-2,3,^1'
Ersteres entspricht der vcpu Einstellung, zweiteres dem CPU-Pinning. Die Angabe bedeutet, der Domain ist erlaubt die CPUs 0 bis 2, 3 aber nicht 1 zu benutzen.
Abgesehen von diesem manuellen Eingriff, benutzt Xen einen Scheduler, der alle Domains über alle CPUs lastmäßig gleichermaßen (aber nicht fair) verteilt. Das Verhalten kann beeinflusst werden, indem Priorisierungen gewichtet werden können. So kann einer Domain zum Beispiel doppelt soviel CPU-Zeit zugewiesen werden, wie einer anderen.
ophelia:~$ xm sched-credit Name ID Weight Cap Domain-0 0 256 0 clever.knallkopp.de 6 256 0 smart.knallkopp.de 10 256 0
“Weight” ist dabei die Gewichtung, in obigem Beispiel ist diese ungewichtet, jede Domain erhält gleich viel CPU-Zeit. Je höher der Wert ist, desto mehr CPU-Zeit erhält die betroffene Domain. Ein Wert von 512 weißt einer Domain also doppelt soviel CPU-Zeit zu, wie den anderen. Der Wert ist eine virtuelle, relative Zahl. Sie ist kein effektiver Zeitwert, der Scheduler wird, sofern zwei Domains Zugriff auf die CPU anfordern lediglich mit einer Häufigkeit von 2:1 die priorisierte Domain wählen. Absolute Limits beeinflusst der Wert “Cap”. Diest ist die obere absolute Grenze an CPU-Auslastung, welche die zugewiesene Domain nutzen darf, einschließlich Leerläufen (”idle cycles”). Der Wert ist ein Prozentwert, Standard ist “0″ - also keine obere Grenze, ein Wert von “50″ würde der Domain 50% einer CPU zusprechen, 100 entsprechend 100%. Noch größere Werte beziehen sich auf SMP-Systeme, so würde “250″ also 2 CPUs voll und eine dritte halb auslasten dürfen.
Veränderbar ist das über den selben Befehl:
ophelia:~$ xm sched-credit -d smart.knallkopp.de -w 256 -c 100 ophelia:~$ xm sched-credit Name ID Weight Cap Domain-0 0 256 0 ... smart.knallkopp.de 10 256 100
Meines Wissens nach, ist es gegenwärtig aber nicht möglich, die Scheduling Credits dauerhaft in der DomU-Konfiguration zuzweisen.
Arbeitsspeicher
Speicher ist sehr einfach partitionierbar. Es gibt in jedem System eine gewisse endliche Menge an Arbeitsspeicher. Für den Hypervisor ist es dann relativ einfach den Bereich in verschieden große Scheiben aufzuteilen und jeder Domain zuzuweisen. Zum Start des Gastsystems reserviert Xen also die veranschlagte Menge Speicher und weißt die dem System dediziert zu.
Dazu ist es ausreichend (und notwendig) in der DomU-Konfiguration eine gewisse Menge Speicher anzugeben, mit der das System gestartet wird.
memory = '2000'Leider ist es nicht so einfach möglich, den Speicherbedarf einer DomU zur Laufzeit dieser anzupassen. Es ist also beispielsweise eine komplizierte Angelegenheit, nach Start der DomU die Speichergröße zu verändern. Dies bedarf nämlich der tatkräftigen Mithilfe des virtualisierten Gastsystems. Das als Gast laufende Betriebssystem muss also “wissen”, dass es virtualisiert läuft und auf Speicheränderungen entsprechend reagieren. Für Windows DomUs funktioniert dies also zum Beispiel nicht, Linux-DomUs (mit ungepatchten Kernels ab 2.6.27) unterstützen hingegen den “Balloon Treiber”, der - wie ein Luftballon - Speicher im Gastsystem vergrößern und verkleinern kann.
Unkonfiguriert kann ein System den Speicherverbrauch aber nur reduzieren, nicht über den Startwert hinaus vergrößern. Soll beispielsweise ein System, das mit 2 GB RAM gespeichert wurde, auf 2,5 GB erweitert werden, ist dies nur mit vorhergehender Konfiguration möglich. Die DomU-Konfigurationsdatei unterstützt dazu den maxmem-Schlüssel:
memory = '2048' maxmem = '4096'
Man beachte, dass die Domain auch direkt mit diesem Parameter gestartet werden muss, standardmäßig wird sonst nämlich maxmem = memory gesetzt. Die xm-Shell unterstützt zwar ebenso die Veränderung des maximalen Speicherbedarfs, die Anpassung funktioniert aber nur beim Start der Domain. Das bedeutet, es ist jederzeit möglich, den maximalen Speicherbedarf wie folgt zu verändern:
ophelia:~$ xm mem-max smart.knallkopp.de 4096Übernommen werden diese Änderungen (für Linux) aber erst nach einem Neustart der Domain (“xm reboot smart.knallkopp.de”). Ist jedoch ein Wert für max-memory gesetzt, kann der Speicherbedarf auch über den initial gesetzten Speicherwert hinaus vergrößert werden, Xen wird die Domain aber stets mit den in “memory” gesetzten Wert starten.
Zur Laufzeit kann der Speicherverbrauch dann nach Belieben mit
ophelia:~$ xm mem-set smart.knallkopp.de 2500verändert werden, wobei der Domain hier 2500 MB Speicher zugewiesen werden. Hier kann prinzipiell jeder Wert zwischen 0 und “mem-max” beliebig vergeben werden. Die Auswirkungen auf die DomU sind jedoch unvorhersehbar. Xen unternimmt keine Anstalten tatsächlichen Speicherverbrauch zu ermitteln. Das bedeutet, wird dieser Wert zu sehr verringert, liegt es am virtualisierten Betriebssystem mit den Auswirkungen klar zu kommen - bis hin zur “Kernel Panic” wenn der Speicherbedarf über das harte Limit von Arbeitsspeicher und etwaigen vorhandenem Swap steigt.
In einer virtualisierten Umgebung ist der zuwiesene Speicher dann sofort sichtbar (die entsprechenden mem-set Kommandos in der Dom0 sind nicht angezeigt):
smart:~$ cat /proc/xen/balloon Current allocation: 2048000 kB Requested target: 2048000 kB Low-mem balloon: 4352 kB High-mem balloon: 0 kB Driver pages: 1024 kB Xen hard limit: ??? kB smart:~$ free -m total used free shared buffers cached Mem: 2000 1479 520 0 73 1051 -/+ buffers/cache: 353 1646 Swap: 2047 0 2047 smart:~$ cat /proc/xen/balloon Current allocation: 1536000 kB Requested target: 1536000 kB Low-mem balloon: 516352 kB High-mem balloon: 0 kB Driver pages: 1024 kB Xen hard limit: ??? kB smart:~$ free -m total used free shared buffers cached Mem: 1500 1483 16 0 73 1055 -/+ buffers/cache: 354 1145 Swap: 2047 0 2047
Festplatte
Größe
Der Festplattenspeicher kann sowohl in absoluter Größer, als auch in der Auslastung beschränkt werden. Für Xen ist es unerheblich, wie dies vonstatten geht. Dieses interessiert sich nämlich in keiner Weise für Quelle und Art des Containers, der dem Gastsystem als “Festplatte” übergeben wird. Es unterstützt dabei simple Dateisystemimmages, reale Festplatten und logische virtuelle Container (LVM) die wie ein physikalisches Device benutzt werden können. Sowohl aus Effizienzgründen, als auch aus Gründen der Wartbarkeit würde ich an dieser Stelle LVM-Container empfehlen. Gibt es irgendwelche Gründe, die gegen LVM sprechen, wird Xen vermutlich mit Images verwendet, zum Beispiel so:
disk = [ 'tap:aio:/domu/smart-disk.img,xvda1,w' ]
Die einzige “Partition” der DomU liegt in diesem Beispiel also als Image im Dateisystem des Hostsystems, im Beispiel an der Stelle /domu/smart-disk.img. Wichtig ist, dass die Partition tatsächlich als solche an Xen übergeben wird (xvda1), nicht als vollständige Festplatte (xvda). In letzterem Fall ist es nicht (bzw. präziser: sehr viel komplizierter) Änderungen an der Größe der Daten vorzunehmen, weil im Image selbst Partitionstabellen und eigenständige Partitionen abgelegt werden. In jedem Fall ist diese Änderung aber nur offline möglich, das heißt das Gastsystem darf dabei nicht laufen. Zwar kann man am Livesystem ganze Blockdevices hinzufügen und entfernen, in der Regel ist das aber nicht, was der Anwender möchte - schließlich soll in der Regel eine bestehende Festplatte/Partition verändert werden, nicht eine vollständig neue hinzugefügt oder eine andere vollständig entfernt werden.
Ist die Partition als solche eingebunden, kann ein Image jederzeit vergrößert und verkleinert werden. Zu beachten ist jedoch, dass diese Methode lediglich mit vollständigen Images (und LVM-Containern) funktioniert, “Sparse” Images sind komplizierter. Images als solche sind relativ einfach veränderbar, da das Dateisystem direkt in diesem Image liegt:
ophelia:~$ mount -o loop smart-disk.img /mnt/ ophelia:~$ touch /mnt/hello_world ophelia:~$ umount /mnt/ ophelia:~$ file smart-disk.img smart-disk.img: Linux rev 1.0 ext3 filesystem data, UUID=eff7680b-0f9a-4a66-acee-7c35dfe72fa5 ophelia:~$ ls -l smart-disk.img -rw-r--r-- 1 root root 10485760 24. Feb 14:27 smart-disk.img
Vorhandenes Image ist also 10 MB groß. Vergrößert wird dieses Image dann ganz einfach mit dd und herkömlichen Dateisystem-Hilfsprogrammen:
ophelia:~$ dd if=/dev/zero of=smart-disk.img bs=1M count=10 seek=10 10+0 Datensätze ein 10+0 Datensätze aus 10485760 Bytes (10 MB) kopiert, 0,0525805 s, 199 MB/s ophelia:~$ e2fsck -f smart-disk.img e2fsck 1.41.9 (22-Aug-2009) Durchgang 1: Prüfe Inodes, Blocks, und Größen Durchgang 2: Prüfe Verzeichnis Struktur Durchgang 3: Prüfe Verzeichnis Verknüpfungen Durchgang 4: Überprüfe die Referenzzähler Durchgang 5: Überprüfe Gruppe Zusammenfassung smart-disk.img: 12/2560 Dateien (0.0% nicht zusammenhängend), 1450/10240 Blöcke ophelia:~$ resize2fs smart-disk.img resize2fs 1.41.9 (22-Aug-2009) Resizing the filesystem on smart-disk.img to 20480 (1k) blocks. Das Dateisystem auf smart-disk.img ist nun 20480 Blöcke groß. ophelia:~$ file smart-disk.img smart-disk.img: Linux rev 1.0 ext3 filesystem data, UUID=eff7680b-0f9a-4a66-acee-7c35dfe72fa5 ophelia:~$ mount -o loop smart-disk.img /mnt/ ophelia:~$ ls /mnt/ hello_world lost+found ophelia:~$ df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf ... /dev/loop0 20M 1,1M 18M 6% /mnt
Wichtig und äußerste Vorsicht ist allein beim seek-Parameter nötig. Dieser muss mathematisch genau die Größe des bereits vorhandenen Dateisystems vorweisen und wird in Blöcken, nicht absolut angegbeen. Das bedeutet bei einer Blockgröße “bs=1M” von 1 MB müssen 10 Blöcke übersprungen werden um ein 10 MB Dateisystem zu vergrößern, im Beispiel um weitere 10 MB.
Vorsicht: Eine Verkleinerung ist so nicht möglich, das Dateisystem würde einfach abgeschnitten, die Daten die hinter der Grenze lägen, würden einfach abgeschnitten. Soll ein ext3-Dateisystem verkleinert werden, müssen spezialisiertere Programme eingesetzt werden, zum Beispiel parted (Befehl “resize”). Das funktioniert allerdings auch nur eingeschränkt und setzt voraus, das für ext3 zum Beispiel spezielle Eigenschaften bei Erzeugung des Dateisystems nicht gesetzt wurden.
Wird anstelle von einfachen Images hingegen LVM verwendet, ist das Vorgehen sehr ähnlich:
ophelia:~$ lvdisplay /dev/xen-domu/smart-disk-img --- Logical volume --- LV Name /dev/xen-domu/smart-disk-img VG Name xen-domu LV UUID nG3zmW-BjTO-hM6K-Pzik-Y41i-l9rz-usdWne LV Write Access read/write LV Status available # open 0 LV Size 2.00 GB Current LE 512 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:7 ophelia:~$ lvextend -L +1G /dev/xen-domu/smart-disk-img Extending logical volume smart-disk-img to 3.00 GB Logical volume smart-disk-img successfully resized ophelia:~$ e2fsck -f /dev/xen-domu/smart-disk-img e2fsck 1.41.3 (12-Oct-2008) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/xen-domu/smart-disk-img: 11/131072 files (0.0% non-contiguous), 25405/524288 blocks ophelia:~$ resize2fs /dev/xen-domu/smart-disk-img resize2fs 1.41.3 (12-Oct-2008) Resizing the filesystem on /dev/xen-domu/smart-disk-img to 786432 (4k) blocks. The filesystem on /dev/xen-domu/smart-disk-img is now 786432 blocks long. ophelia:~$ lvdisplay /dev/xen-domu/smart-disk-img --- Logical volume --- LV Name /dev/xen-domu/smart-disk-img VG Name xen-domu LV UUID nG3zmW-BjTO-hM6K-Pzik-Y41i-l9rz-usdWne LV Write Access read/write LV Status available # open 0 LV Size 3.00 GB Current LE 768 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:7
Einschränkungen zur Verkleinerung vom Dateisystem gelten analog. Komplizierter ist die Sache, wenn es nicht um absolute Größen geht, sonden um die kapzitive Auslastung der Festplatte.
Disk I/O
Egal ob Dateisystemimage oder LVM-Container: Die Festplattenauslastung des Hostsystems ist begrenzt und wird von den Gastsystemen geteilt. Xen ist dabei nicht “fair”, das heißt es kriegt nicht jedes Gastsystem fest zugeteilte Festplattenseeks. Im Extremfall bedeutet das, wenn ein Gastsystem die Festplatte durch schreiblastige Anwendung für sich beansprucht, zieht das die Performane etwaiger anderer Gastsysteme mit in den Abgrund. Solange sich Gastsysteme die selben physikalishen Ressourcen teilen, gibt es seitens Xen keine Möglichkeit, dieses Verhalten zu verändern. In Xen 4.0 ist diese Möglichkeit angekündigt, bis jetzt ist das jedoch noch nicht verfügbar.
Da Xen aber eng in Linux verankert ist, gibt es bis dahin einen Workaround, der zu ähnlichen Ergebnissen ohne Unterstützung von Xen führt. Mit ionice können Prozesse in ihrer I/O-Last limitiert werden. Dieses funktioniert im Prinzip ganz ähnlich wie nice: Der Benutzer weißt einem Prozess eine Priorität zu und abhängig davon priorisiert der Scheduler den betreffenden Prozess. Xen bildet in diesem Fall zum Glück den Festplattenzugriff auf dem Hostsystem als einfachen Prozess ab.
Voraussetzung zur Disk-I/O-Verwaltung ist CFQ-I/O-Scheduler im Dom0-System. Moderne Linux-Kernel sollten diesen automatisch bereits einsetzen, distributionsspezifisch kann es allerdings Ausnahmen geben. Überprüft werden kann dies (unter eventueller Veränderung des Festplatten-Blockdevices) mit
ophelia:~$ cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq]
Gibt dies nicht “cfq” aus, muss der Scheduler dahingehend geändert werden. Ionice funktioniert nur mit dem CFQ-Scheduler. Da es sich hierbei um eine fundamentale Kernel-Einstellung handelt, kann diese nur zum Bootzeitpunkt verändert werden. Dazu einfach elevator=cfq als Kernel-Parameter beim booten übergeben. Debian- bzw. Ubuntu-Nutzer können dazu einfach die “Start Default Options” verändern, indem sie “#kopt=[..] elevator=cfq” in der Datei /boot/grub/menu.lst setzen, anschließend “update-grub” ausführen und das System neustarten.
Bei Verwendung von LVM-Containern wird der Diskzugriff auf ein physikalisches Interface abgebildet. Xen benutzt dazu den “blkback” Treiber. Angenommen folgende Festplatte ist in der DomU konfiguriert:
ophelia:/etc/xen/auto$ grep "disk =" smart.cfg disk = [ 'phy:/dev/xen-domu/smart-disk,xvda1,w' ] ophelia:/etc/xen/auto$ xm list smart Name ID Mem VCPUs State Time(s) smart 10 2000 4 -b---- 138400.5
Dann findet sich in der Prozessliste auch der zugehörige Prozess, der diesen Festplattenzugriff der DomU bereitstellt (Die Zahl ist hierbei die Domain-ID):
ophelia:/etc/xen/auto$ ps aux | grep "blkback.10" root 7098 0.0 0.0 0 0 ? S< Jan22 1:57 [blkback.10.xvda] root 31563 0.0 0.0 5160 776 pts/4 R+ 11:45 0:00 grep blkback.10
Alles was bleibt, ist eben diesen Prozess eine Priorität zuzuweisen. Zunächst kann man die aktuelle Priorität des Prozesses mit ionice erfragen und anschließend Änderungen vornehmen. Die Prioritäten kann man in acht Klassen einteilen indem man dem Prozess einen Wert zwischen 0 und 7 zweist. Die Prioritätsklassen sind dabei absteigend. Das bedeutet, je kleiner der Wert, desto höher die Priorität. Belegt eine DomU also zuviele Ressourcen, kann man den Wert verkleinern:
ophelia:/etc/xen/auto$ ionice -p 7098 none: prio 0 ophelia:/etc/xen/auto$ ionice -p 7098 -c 2 -n 4 ophelia:/etc/xen/auto$ ionice -p 7098 best-effort: prio 4
Das Verfahren gilt analog für andere Disk-Zugriffe zum Beispiel dem TAP-AIO-Treiber der für Images verwendet wird. Zu beachten ist jedoch, dass in dem Fall ein anderer Treiber verwendet wird, der den Plattenzugriff abbildet. In dem Fall muss man in der Prozessliste nach “tapdisk” suchen. Das gibt zum Beispiel:
ophelia:/etc/xen/auto$ ps aux | grep tapdisk root 31563 0.0 0.0 5160 776 pts/4 R+ 11:45 0:00 tapdisk /dev/xen/tapctrlwrite1 /dev/xen/tapctrlread1
Aber Vorsicht: Die Nummern werden fortlaufend vergeben und stehen hier nicht für die DomU-ID. Die Nummer wird vielmehr laufend in der Startreihenfolge der Domains vergeben.
Netzwerkdurchsatz und Netzwerksicherheit
Hier sieht es gegenwärtig sehr düster aus mit Xen. Vor Xen 4.0 ist hier auch keine Neuerung zu erwarten. Dieses verspricht dafür alles nachzuholen, das hier fehlt. Dieses wird es erstmals erlauben Netzwerkdurchsatz zu überwachen, limitieren und (vollständig) zu kontrollieren.
Bis dahin gibts es lediglich einige Notbehelfe. Ich persönlich habe mich nicht damit beschäftigt, es sollte allerdings möglich sein, auf der Dom0 entsprechende Traffic Shaping Firewalls zu installieren.
IP-Adressen und Spoofschutz
Möglich und auch wirklich notwendig ist hingegen der Spoofschutz. Insbesondere dann, wenn der Administrator der DomU nicht vertrauenswürdig ist. Das ist konsequenterweise jede DomU die nicht der Besitzer der Dom0 selbst betreibt. In dem Fall gilt es Maßnahmen zu ergreifen, die verhindern, dass der DomU-Betreiber eigenmächtig IP-Adressen hochfährt, fälscht und Traffic auf seine Maschine umleitet, der nicht für ihn bestimmt ist.
Grundsätzlich sind zwei Möglichkeiten ein Netzwerk mit Xen aufzubauen verbreitet: Routing und Bridges. Ein geroutetes Netzwerk ist nicht ganz so flexibel wie ein gebridgtes, bietet aber viel mehr Sicherheit. Dieses ist auch die einzige Möglichkeit bei vielen kommerziellen Internet Service Providern einen Xen-Server zu betreiben, da dieses die Mac-Adresse maskiert. Nach außen hin sieht ein geroutetes Netzwerk so aus, als ob lediglich eine Maschine mit mehreren IP-Adressen existierte, erst auf der Dom0 selbst entscheiden statische Routingtabellen wohin ein Paket geleitet wird.
Das sieht dann so aus:
ophelia:/etc/xen/auto$ grep "vif" smart.cfg vif = [ 'ip=278.40.54.41,mac=00:16:3E:69:6D:C6' ] ophelia:/etc/xen/auto$ grep "network-script" /etc/xen/xend-config.sxp (network-script network-route) ophelia:/etc/xen/auto$ route -n | grep "278.40.54.41" 278.40.54.41 0.0.0.0 255.255.255.255 UH 0 0 0 vif9.0 ophelia:/etc/xen/auto$ iptables -n -L Chain FORWARD (policy ACCEPT) target prot opt source destination ... ACCEPT all -- 278.40.54.41 0.0.0.0/0 PHYSDEV match --physdev-in vif9.0 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vif9.0 udp spt:68 dpt:67
Oder in Worten: Nur die Pakete, die der IP entsprechen, die in der DomU-Konfiguration angegeben sind, werden an die DomU weitergeleitet. Alle anderen Pakete erreichen gar nicht erst die DomU und werden im IP-Stack des Kernels der Dom0 verworfen, weil er nichts damit anzufangen weiß. Das ist auch gleich der beste Sicherheitsvorteil, so ist es unmöglich, dass Pakete die nicht für die DomU bestimmt sind dort ankommen.
In dem flexibleren, aber ungleich unsicheren Bridge-Setup wird die virtuelle Netzwerkschnittstelle der DomU mit der physikalischen Netzwerkschnittstelle verbunden und jedes Paket ungeprüft durchgereicht. Nach außen hin schwirren sämtliche Mac-Adressen herum, die an die DomUs vergeben sind und es ermöglicht jeder DomU eigenständig die Netzwerkkonfiguration vorzunehmen. Nichts hindert dann die DomU daran weitere IP-Adressen hinzuzufügen oder die IP-Adresse des Nachbarn “zu stehlen” und damit die Pakete die für den Nachbarn bestimmt sind abzufangen. MAC-Spoofing macht das möglich.
Es gilt also auf der Dom0 Maßnahmen zu ergreifen, die eben dies verhindern. Das Bridge-Netzwerkscript hat eine gut versteckte Methode dies sogar automatisch zu verhindern, von der in jedem Fall Gebrauch gemacht werden sollte:
# Usage: # network-bridge (start|stop|status) {VAR=VAL}* # # Vars: # # bridge The bridge to use (default ${netdev}). # netdev The interface to add to the bridge (default gateway device). # antispoof Whether to use iptables to prevent spoofing (default no)
Umgesetzt wird dies, indem also einfach der Parameter “antispoof=yes” an das Bridge-Script mit übergeben wird. Dies geschieht einfach durch Anpassung in /etc/xen/xend-config.sxp:
... (network-script 'network-bridge antispoof=yes') ...
Dann werden alle Pakete gedroppt (man achte auf die iptables Policy für FORWARD), die nicht von oder an IPs gerichtet sind, die in der DomU-Konfiguration angegeben ist:
ophelia:/etc/xen/auto$ xm network-list smart Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3E:80:71:A7 0 4 22 768 /769 /local/domain/0/backend/vif/10/0 ophelia:/etc/xen/auto$ iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in peth0 ... ACCEPT all -- 278.40.54.41 0.0.0.0/0 PHYSDEV match --physdev-in vif10.0
Loading...