Hardware für Proxmox VE Virtualisierungsserver

Ein Server für mein privates Pentest-Labor zur Virtualisierung der Opfersysteme musste her. Auf Bitte eines Lesers folgt eine kurze Dokumentation der getroffenen Hardware- und Software-Entscheidungen.
fantec_front

Kurz vorweg:
Es ist erstaunlich, wie viel Rechenleistung für moderaten Geldeinsatz kaufbar ist.

Mit einer geschickten Kombination aus Desktop- und Server-Hardware ist es möglich, einen nicht für den produktiven sondern für den experimentellen Betrieb geeigneten Virtualisierungsserver zusammenzustellen, der sich nicht verstecken muss.

Da der Server in einem bewohnten Bereich betrieben wird, musste das Gehäuse mit Schalldämmung versehen werden. Schalldämmung ist bei Server-Gehäusen noch weniger üblich, als im Desktop-Bereich und erschwert die Hardwareauswahl.

Hardware

IMG_20140102_145901

  • Intel Xeon E3-1245 v3, 4x 3.40GHz, Sockel-1150, boxed (BX80646E31245V3)

Statt dem i7-4770, zum Zeitpunkt des Kaufs signifikanter Kostenvorteil. Verlust von 100Mhz Turbo. Vergleich beider CPUs hier.

Bietet Intel I217-LM Gigabit-LAN, vPro (statt IPMI bei einem Server-Mainboard) und kostet unter 100 Euro.

Passform sehr gut für 4HE Server-Gehäuse mit Schalldämmung und Montage mit Backplate (im Preissegment um 20 Euro nicht selbstverständlich).

  • Fantec NNC-4550X, 4HE (1489)

Sehr günstiges und stabiles 4HE Server-Gehäuse. Lässt sich Zwecks Schalldämmung komplett demontieren. Nachteil: Keine Rackschienen vom Hersteller.

Erfahrungsgemäß gut verarbeitbare Schalldämmmatten. Leider werden zwei Pakete benötigt.

Die Liste mit Tagespreisen ist hier abrufbar.

Zusammenbau

Der Zusammenbau gestaltet sich sehr einfach. Die Montageanleitung des CPU-Kühlers ist umfangreich.

Problematisch war die Anbringung der Schalldämmmatten. Das Fantec-Gehäuse erlaubt im Gegensatz zu einigen anderen günstigen Server-Gehäusen die Demontage des Mainboard-Trays, sodass auch unter dem Mainboard Bitumenpappe angebracht werden kann. Der Schnitt der Cooltek-Dämmmatten ermöglicht die Anbringung am kompletten Gehäusedeckel, den Seiten des Gehäuses und der Front ohne Zuschnitt.

IMG_20131230_185240

IMG_20131230_185311

IMG_20131230_190156

IMG_20131231_212829

IMG_20140101_210409

Wer viele kleine Schrauben nicht scheut, kann mit zwei Sätzen Cooltek Dämmmatten und dem Fantec NNC-4550X Gehäuse einen schallgedämmten Server bauen. Einziger Wermutstropfen des Gehäuses ist das sehr günstig gewählte Schloss, dass weder dem Einbruchsschutz dient, noch die Frontplatte bei regelmäßiger Benutzung besonders gut hält.

Software

Wenn Virtualisierungslösungen in Unternehmen eingesetzt werden sollen, wird oft VMWare ESXi eingesetzt. Leider wird entweder ein NAS oder SAN benötigt, oder ein Hardware-RAID Controller. Beides kam für mich nicht in Frage. Ein eigenes SAN/NAS ist für unwichtige Entwicklungssysteme im privaten Bereich überdimensioniert und Hardware-RAID meiner Ansicht nach nicht ökonomisch sinnvoll, wie ich vor drei Jahren erklärt habe.

Um die Zeit zu verringern, die für Einrichtung und Verwaltung nötig wird, habe ich mich für Proxmox VE entschieden. Proxmox VE basiert auf Debian und kann verschlüsselt und mit Software-RAID installiert werden. Die Installation des Servers ist in folgenden Artikeln dokumentiert.

Die anfänglichen Bedenken, dass eine so weit entfernt von den Projektvorgaben installierte Virtualisierungslösung nicht zuverlässig funktionieren kann, haben sich nicht bestätigt. Der Virtualisierungsserver läuft seit Inbetriebnahme so zuverlässig, wie man es von einem Debian erwarten darf. Ergänzend besteht die Möglichkeit bekannte Verwaltungswerkzeuge und Helferlein wie apticron einzusetzen.

Ausnahmen für OpenVPN Verbindung mit iptables, ipset und Policy-based Routing

Wer auf eine permanent bestehende VPN-Verbindung angewiesen ist, oder einfach etwas paranoid, möchte einige Ziel-IPs oder Hostnamen im Internet trotzdem gern direkt ansprechen. Dazu zählt zum Beispiel der Speedtest des eigenen Internetanbieters oder Distributions-Spiegelserver. Ohne den Umweg über die VPN-Verbindung wird der Maximaldurchsatz der eigenen Internetanbindung erreicht, was bei vielen Diensten von Vorteil ist. Darüber hinaus lässt sich so zum Beispiel eine Trennung zwischen anonymisiert besuchten Webseiten und nicht anonymisiert besuchten Webseiten herstellen. Wie das geht? Mit iproute2, ipset und einer iptables-Regel.

Zwei Routing-Wege zu unterschiedlichen Zielen

Zwei Routing-Wege zu unterschiedlichen Zielen

Um das Ziel zu erreichen, wird eine zweite Routing-Tabelle angelegt, die den zur Vorgabe (default route) unterschiedlichen Router enthält. Basierend auf der Ziel-IP oder dem Ziel-Hostnamen der Ausnahme-Ziele wird der Kernel die Routing-Entscheidung abweichend treffen. Dafür wird jedes Paket zu oder von den Ausnahme-Zielen mit einer Markierung versehen.

1. Neue Routing-Tabelle in /etc/iproute2/rt_tables

Zuerst wird durch folgenden Eintrag die neue Routing-Tabelle definiert.

1       novpn

2. Regeln zu /etc/network/interfaces hinzufügen

Folgend werden zwei Regeln für die neue Routing-Tabelle novpn angelegt. Dies muss nicht in der Datei interfaces geschehen, sondern könnte auch auf die Datei /etc/rc.local angewendet werden. Die interfaces Datei bietet sich aber aufgrund des Sachzusammenhangs an. Die beiden Regeln lauten wie folgt.

ip rule add fwmark 1 table novpn
ip route add default via 192.168.178.1 dev eth0 table novpn

Die erste Regel führt dazu, dass die Routing-Entscheidung für durch die Firewall mit dem Marker 1 markierte Pakete von der Vorgabe abweicht. Es wird statt der voreingestellten Routing-Tabelle die Tabelle novpn für die Routing-Entscheidung herangezogen. Die zweite Regel fügt der Tabelle novpn ein default gateway hinzu, dass von der Vorgabe abweicht.

Werden die Regeln in der Datei interfaces ergänzt (für das externe Interface der Firewall), könnte das Ergebnis wie folgt aussehen.

# The external (DMZ) network interface
allow-hotplug eth0
iface eth0 inet static
        address 192.168.178.254
        netmask 255.255.255.0
        network 192.168.178.0
        gateway 192.168.178.1
        dns-nameservers 192.168.178.1
        # check with ip route show table novpn && ip rule
        post-up ip rule add fwmark 1 table novpn
        post-up ip route add default via 192.168.178.1 dev eth0 table novpn

iptables und ipset

Es bleibt die Erstellung einer adequaten iptables Regel. Diese lautet wie folgt.

# Setup ipset
if [ -x /etc/rc.firewall.ipset ]; then
       /etc/rc.firewall.ipset || echo "problem loading ipsets"
fi
iptables -A PREROUTING -i $LAN -t mangle -m set --match-set Direct_Hosts dst  -j MARK --set-mark 1

Die Regel muss an den PREROUTING-Chain angehängt werden, um die Routing-Entscheidung beeinflussen zu können (siehe hier). Umgangssprachlich ausgedrückt wird der Marker jedes Pakets, dessen Ziel in der Tabelle Direct_Hosts vorkommt, auf 1 gesetzt. Dieser Marker führt dazu, dass die so gekennzeichneten Pakete die alternative Routing-Tabelle verwenden.

Bleibt die Einrichtung des ipsets Direct_Hosts. Fehlt das Programm ipset, kann es mit dem Befehl apt-get install ipset installiert werden. Um einzelne Ziele in einem ipset zu verwalten, bietet sich die Datenstruktur hash:ip an, die das geforderte leistet. Abkürzend folgt das fertige Beispiel.

#!/bin/bash
#
# Direct_Hosts - Hosts to connect directly to (no VPN)
#
ipset destroy Direct_Hosts
ipset create Direct_Hosts hash:ip hashsize 4096
# Hosts 
ipset add Direct_Hosts -! '[speedtest-1.unitymedia.de]'
ipset add Direct_Hosts -! '[speedtest-2.unitymedia.de]'
ipset add Direct_Hosts -! web.de
ipset add Direct_Hosts -! 8.8.8.8

Zu beachten ist bei ipset-Einträge, dass Hostnamen bei der Erstellung des Sets aufgelöst werden und nur die IP-Adresse gespeichert werden. Hostnamen, die Bindestriche enthalten, müssen in eckige Klammern gesetzt werden. Um die Auswertung der eckigen Klammern in der Laufzeitumgebung (bash) zu verhindern, werden einfache Anführungszeichen verwendet.

Fehler in Paketnamen bei Debian in /var/lib/dpkg/available

Wer selbst Pakete kompiliert und das bereits vor Erscheinen von Debian wheezy getan hat, zum Beispiel mittels checkinstall, kann Fehler in Paketnamen mit der neuen dpkg Version erhalten. Folgend einige Beispiele.

dpkg: Warnung: Parsen der Datei »/var/lib/dpkg/available«, nahe Zeile 16240 Paket »libevent-2.0.14«:
 Fehler in Versionszeichenkette »stable-1«: Versionsnummer beginnt nicht mit einer Ziffer
dpkg: Warnung: Parsen der Datei »/var/lib/dpkg/available«, nahe Zeile 27980 Paket »linux-image-3.4.18sintel64.1«:
 Fehler in Versionszeichenkette »sintel64.1«: Versionsnummer beginnt nicht mit einer Ziffer

Durch Deinstallation der benannten Pakete lässt sich das Problem nicht aus der Welt schaffen. Die Fehlermeldung bleibt, bis die available Datenbank mit folgendem Befehl gelöscht wird.

dpkg --clear-avail

Um die Datenbank neu anzulegen und zu befüllen existieren zwei Möglichkeiten.

# Neuere Debian- & Ubuntu-Versionen
sync-available
# Alternative
apt-get install dselect
dselect update

Selbstzerstörung für cryptsetup

641px-Mad_scientist_transparent_background.svg
Die Verrückten Wissenschaftler von Offensive-Security haben es getan. Ab sofort kann mit einem kleinen Patch für cryptsetup eine neue Funktion hinzugefügt werden: luksAddNuke.

Mit dieser Funktion kann ein KeySlot in LUKS mit einem speziellen Schlüssel belegt werden. Wird dieser Nuke-Schlüssel eingegeben, werden alle Schlüssel in den LUKS KeySlots gelöscht. Das führt dazu, dass das dm-crypt Volume nicht mehr geöffnet werden kann.

Der Patch basiert auf einem fünf Jahre alten Beitrag von Jürgen Pabel. Wer Spaß daran hat, findet alles weitere auf der Kali Linux Webseite für den Patch.

Aber

Der Patch erzielt zwar, dass das dm-crypt Volume nicht mehr geöffnet werden kann. Abstreitbar ist dessen Existenz dadurch nicht, denn der LUKS-Header bleibt intakt.

Archiv und Kali Mirror

Große Dateien und virtuelle Maschinen befinden sich ab sofort auf einem eigenen Server. Dazu ebenso die Videos vom BDay 2013.

archiv.paketsequenz.de

Und um der Gemeinschaft rund um Penetrationstests etwas zurück zu geben, betreibe ich (scheinbar als erste Privatperson) einen Kali Linux Mirror.

kalimirror

Privater Kali Linux Mirror – Danke Offensive Security!

Bei einem Server von OVH zum Spottpreis von 3,99 Euro (echt wahr) kann niemand wiederstehen. Jetzt bekommt der Server endlich etwas zutun. Der dauerhafte Link befindet sich in der Top-Navigation.

Wer liest meinen Blog?

Manchmal möchte man als Blogger erfahren, welche Art von Leser man anzieht und ob die Ausrichtung des Blogs stimmt. Selbstzweifel nagen am Autor, der die meiste Zeit allein mit dem Texteditor und dem Blog verbringt. Wie gut, dass es Statistik-Plugins wie StatComm gibt. Dieses Plugin verrät für diesen Blog, welches Betriebssystem und Browser besonders beliebt ist.

Bildschirmfoto - 06.01.2014 - 11:19:19

Beliebtester Browser: Unbekannt.

Für diesen Blog verwenden 33% der Besucher einen unbekannten Browser auf einem unbekannten Betriebssystem. Auch IP-Adressen aus Deutschland sind weit abgeschlagen hinter der Schweiz und den Niederlanden. Besonders beliebt sind Computer in Rechenzentren mit Windows und Firefox oder Windows und unbekannten Browsern. Dabei handelt es sich höchstwahrscheinlich um Proxys.

Für mich steht damit fest, dass ich die Zielgruppe erreiche.

Und natürlich Dankeschön, dass Ihr meinen Blog lest und Anonymisierung einsetzt.

Über Fragen, Kommentare oder Themenwünsche würde ich mich trotz eurer Anonymität um so mehr freuen. Hinterlasst doch einen Kommentar!

Proxmox internes Host-only Netzwerk

Um komplexe Netzwerkstrukturen mit einem Proxmox VE Virtualisierungsserver abzubilden, sind interne Netzwerke Host-only notwendig. Das Vorgehen ist einfach.

Im Reiter Netzwerk wird der Menüpunkt Erstellen gewählt.

Bildschirmfoto - 05.01.2014 - 19:02:36

Beispiel Host-only Netzwerkinterface vmbr1

Es muss keine IP-Adresse für die neue Netzwerkschnittstelle gewählt werden. Nach der Einrichtung muss ein Neustart des Virtualisierungsservers durchgeführt werden. Danach kann die neue Schnittstelle zu virtuellen Maschinen hinzugefügt werden und erscheint wie folgt.

Bildschirmfoto - 05.01.2014 - 19:45:06

Erscheinungsbild vmbr1 auf Host

Proxmox VE mit Software-RAID und Full-Disk-Encryption

Wie bereits im Artikel zur voll-verschlüsselten Installation von Kali beschrieben, kann nach der Tauchfahrt-Anleitung jedes Debian basierende System voll-verschlüsselt installiert werden. Der Bare-metal Hypervisor Proxmox VE basiert auf Debian. Was liegt näher, als Virtualisierungsserver zu verschlüsseln?

proxmox_fde_swraid

Folgend wird am Beispiel eines Servers mit vier 2TB Festplatten gezeigt, wie die Partitionierung und Installation im Unterschied zur Anleitung
Debian Colocation/Leased Server Full-Disk-Encryption durchgeführt werden kann.

Es sind die Schritte 3, 5.2 und 6 wie folgt durchzuführen. Die Installation von Proxmox geschieht in Schritt 11.

3. Festplatte partitionieren

Für Proxmox VE wird empfohlen, LVM einzusetzen und in einer Volume-Group pve die zwei logischen Volumes root und data anzulegen. Daraus ergibt sich für die vier 2TB Festplatten (sda,sdb,sdc,sdd) folgendes Endschema.

  • 2x 8GB RAID1 für /boot
  • 2x 8GB RAID1 für swap
  • 4x 1992GB RAID10 für LVM

Um dieses Schema zu erreichen, müssen die Partitionsschemen der einzelnen Festplatten wie folgt hergestellt werden. Der Partitionsmanager muss für jede Festplatte einmal aufgerufen werden.

cfdisk -z /dev/sdX

Gelöscht wird automatisch das komplette Partitionsschema der vorherigen Installation.

Angelegt werden zwei Partitionen. Für die ersten beiden Festplatten muss das Bootflag gesetzt werden. Für die restlichen beiden nicht.

sdX1

  • Größe 8GB
  • Typ FD (Wird unverschlüsseltes /boot- oder swap-RAID1)
  • Bootfähig für 1. und 2. Festplatte

sdX2

  • Größe Rest (1992GB)
  • Typ 8E (wird Teil des LVM)

Folgend werden die beiden RAID1-Verbünde für die /boot Partition und die Auslagerungspartition erstellt. Das alte mdadm Metadaten-Format kommt zum Einsatz, damit der betagte Kernel von Proxmox die RAID-Verbünde beim Systemstart automatisch erkennt.

mdadm --create -e 0.9 --level=1 -n 2 /dev/md0 /dev/sda1 /dev/sdb1
mdadm --create -e 0.9 --level=1 -n 2 /dev/md1 /dev/sdc1 /dev/sdd1

Es folgt das RAID10,f2 für das verschlüsselte LVM-Volume.

mdadm --create --level=10 -p f2 -n 4 /dev/md2 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2

Dann wird das RAID10 für das LVM-Volume verschlüsselt und formatiert. Hier ist es besonders wichtig, ein Passwort auszuwählen, dass länger als 20 Zeichen ist. Je länger und zufäliger das Passwort, desto länger dauert das Brechen. Dieses Passwort ist gemeinsam mit einem folgend erstellten SSh-Schlüssel die Achillesferse des Prinzips und muss geheimgehalten werden. Es ist sehr empfehlenswert, eine Software wie PWGen zu verwenden, um ein sehr langes Passwort (zum Beispiel 200 Zeichen) zu erzeugen.

Wenn das Passwort erzeugt ist, kann wie folgt fortgefahren werden. Bei der Verschlüsselung der Partition muss zuerst die Verschlüsselung mit Eingabe von YES bestätigt werden und dann der Schlüssel zweimal eingegeben werden.

cryptsetup luksFormat /dev/md2
cryptsetup luksOpen /dev/md2 md2_crypt

Jetzt kann das LVM initialisiert und die nötigen logischen Volumes nach Proxmox-Vorgabe erstellt werden. Die Größe des logischen Volumes data ist absichtlich klein gewählt, sodass weitere logische Volumes für Backups erstellt werden können.

pvcreate /dev/mapper/md2_crypt
vgcreate pve /dev/mapper/md2_crypt
lvcreate --name root --size 60G pve
lvcreate --name data --size 500G pve

Folgend werden die Partitionen formatiert. Dabei soll nach Proxmox-Vorgabe das Dateisystem ext3 eingesetzt werden.

mkfs.ext3 /dev/mapper/pve-data
mkfs.ext3 /dev/mapper/pve-root
mkfs.ext3 /dev/md0

Jetzt werden die Partitionen eingebunden, damit im nächsten Schritt das Basis-System installiert werden kann.

mount /dev/mapper/pve-root /mnt
mkdir -p /mnt/boot /mnt/var/lib/vz
mount /dev/mapper/pve-data /mnt/var/lib/vz
mount /dev/md0 /mnt/boot

5.2 Einrichtung der /etc/crypttab,/etc/fstab, Paketquellen und lokale Einstellungen

Zuerst wird die Dateisystem-Tabelle für verschlüsselte Partitionen angelegt.

md1_crypt /dev/md1	/dev/urandom cipher=aes-cbc-essiv:sha256,size=256,swap
md2_crypt /dev/md2	none	luks

Dann die entsprechende Dateisystem-Tabelle für unverschlüsselte und aktive verschlüsselte Partitionen.

/dev/md0		/boot		ext3	relatime		0 2
/dev/mapper/md1_crypt	none		swap	sw			0 0
/dev/mapper/pve-root	/		ext3	relatime,data=ordered 	0 1
/dev/mapper/pve-data	/var/lib/vz	ext3	relatime,data=ordered	0 3
proc			/proc		prox	defaults

Jetzt werden die Paketquellen in der Datei /etc/apt/sources.list wie folgt eingetragen.

# Debian wheezy
deb http://ftp.de.debian.org/debian/ wheezy main non-free contrib
deb-src http://ftp.de.debian.org/debian/ wheezy main non-free contrib
deb http://security.debian.org/ wheezy/updates main non-free contrib
deb-src http://security.debian.org/ wheezy/updates main non-free contrib
deb http://ftp.de.debian.org/debian/ wheezy-updates main non-free contrib
deb-src http://ftp.de.debian.org/debian/ wheezy-updates main non-free contrib

Nach Aktualisierung der lokalen Caches für Pakete kann fortgefahren werden.

aptitude update && aptitude -y upgrade

Jetzt erfolgt die Konfiguration der Sprache des Systems.

aptitude -y install locales && dpkg-reconfigure locales

Hier wird de_DE.UTF-8 gewählt. Die Zeitzone muss auch gesetzt werden, in der Regel auf Europa/Berlin.

dpkg-reconfigure tzdata

6.1 Grundlegende Software installieren

aptitude install -y ssh grub-pc pciutils psmisc cryptsetup dropbear busybox mdadm lvm2

Während der Installation erscheint eine Nachfrage von grub-pc. Es wird nach dem Ort, an dem GRUB installiert werden soll gefragt. Es sind /dev/sda und /dev/sdb anzugeben. Weicht die Festplattenbenennung ab, ist es wichtig zu wissen, dass GRUB nicht in einer Partition (wie /dev/sda1) oder einem Software-RAID-Verbund, sondern auf Festplatten (wie /dev/sda) installiert werden sollte.

11. Debian in Proxmox VE umwandeln

Nach der erfolgreichen Installation von Debian nach den Proxmox-Vorgaben, kann die Installation nach der Anleitung im Proxmox VE Wiki umgewandelt werden. Es sind die Schritte ab Install Proxmox VE durchzuführen.