Proxmox VE 3.2 Beta-Version – Was gibts neues?

Wie im Forum angekündigt, ist Proxmox VE 3.2 als Beta-Version verfügbar. Was gibt es neues?

logo_prox

Neuer Kernel

Die größte Änderung besteht im Angebot des RHEL7 basierenden Kernels in Version 3.10, allerdings bisher nur mit Unterstützung von KVM-Virtualisierung und ohne OpenVZ. OpenVZ ist die in Proxmox eingesetzte Paravirtualisierungslösung. Ein Parallels-Entwickler (der Hersteller von OpenVZ) kündigt in seinem Blog die Portierung von OpenVZ für den RHEL7-Kernel an. Der neue Kernel wird darüber hinaus langfristig unterstützt werden. Zuständig für die Unterstützung ist die LTSI, oder kurz Greg Kroah-Hartman.

Die Proxmox-Entwickler haben dem Kernel für die Beta-Version einige Treiber für RAID- und Netzwerkkarten hinzugefügt.

Und natürlich enthält der neue Kernel auch deutliche Verbesserungen der Verschlüsselungs-Infrastruktur; falls der eigene Proxmox-Server verschlüsselt ist.

Neues Dateisystem

Eine weitere interessante Entwicklung ist die Einbindung von Ceph, einem verteilten Dateisystem. Die Vorteile für den Einsatz mit Proxmox finden sich hier.

Weiteres

featured-image

(Quelle: openvswitch.org)

Darüber hinaus bringt die Beta-Version von Proxmox VE 3.2 einen Ersatz für die auf Java basierende Web-Konsole: Spiceterm. Spiceterm wird seit August 2013 von Dietmar Maurer entwickelt. Die README-Datei des Entwicklungs-Repositories enthält weitere Informationen.

Auch Open vSwitch ist in der Beta enthalten, soweit ersichtlich ohne Änderungen gegenüber der Version in Debian wheezy. vSwitch könnte in Zukunft aufgrund des Funktionsumfangs und dem scheinbar besseren Maximaldurchsatz gegenüber den Linux bridge-utils interessant werden.

Danke an Tim R. für den Hinweis zur neuen Beta.

blog_homelab

Metasploitable 2 Kennwörter brechen

Im gestrigen Artikel wurde beschrieben, wie durch eine Hintertür in vsftpd 2.3.4, Rootrechte auf der virtuellen Maschine Metasploitable 2 erlangt werden können. Diese Rootrechte sollen verwendet werden, um die Kennwörter der virtuellen Maschine zu entnehmen und folgend zu brechen.

Mit den Befehlen cat /etc/passwd und cat /etc/shadow werden die Inhalte der entsprechenden Dateien ausgegeben. Warum gerade diese? Sie enthalten die Benutzerdaten der lokalen Systembenutzer; zumindest solange keine esoterischen Verfahren wie OpenLDAP zur Authentifikation eingesetzt werden. Der Hash des Kennworts und die Benutzerdaten werden seit Ende der 1980er Jahre in getrennten Dateien gesichert, damit normale Benutzer die Benutzerdaten lesen dürfen, nicht aber damit auch die Hashes der Kennwörter zu Gesicht bekommen.

Die aus der virtuellen Maschine entnommenen Dateien als passwd und shadow speichern. Dann werden sie mittels unshadow wie folgt zusammenfügen.

root@kalilinux:~/10.13.37.24# unshadow 
Usage: unshadow PASSWORD-FILE SHADOW-FILE
root@kalilinux:~/10.13.37.24# unshadow passwd shadow > metasploitable2_credentials.txt 

Das Ergebnis des Programms unshadow kann mit John the Ripper bearbeitet werden. Für Metasploitable sind weder Wörterbücher noch Parallelisierung notwendig, darum kann die von Kali Linux mitgelieferte Version verwendet werden. Die ersten sieben von acht Kennwörtern werden innerhalb von Sekunden gebrochen.

john metasploitable2_credentials.txt
Loaded 7 password hashes with 7 different salts (FreeBSD MD5 [128/128 SSE2 intrinsics 12x])
user             (user)
postgres         (postgres)
msfadmin         (msfadmin)
service          (service)
batman           (sys)
123456789        (klog)

Der Wert in Klammern entspricht dem Benutzernamen, der vorgestellte Wert dem Kennwort.

Benutzername Kennwort
user user
postgres postgres
msfadmin msfadmin
service service
sys batman
klog 123456789

Da john ohne Wörterbuch einen Bruteforce-Angriff gegen die Hashes durchführt (sogenannter Incremental Mode), kann es überraschen, dass bereits ein neunstelliges Kennwort gebrochen wurde.

Aufgrund der Reife der Software, arbeitet john die möglichen Kennwörter in sinnvollen Phasen ab. Begonnen wird mit dem Single Mode, dem der Benutzername und Informationen aus den weiteren Feldern der passwd zugrunde liegt. Dadurch werden bereits vier der Kennwörter gebrochen. Die weiteren beiden Kennwörter der Benutzer sys und klog werden mit Hilfe des mitgelieferten Wörterbuchs password.lst gefunden. Erst nach diesen beiden Phasen wird zu einem Bruteforce-Angriff übergegangen.

blog_homelab

Metasploitable 2 mittels vsftpd 2.3.4 Exploit angreifen

Wie in einigen vorherigen Artikeln beschrieben, ist mein Heimlabor für Penetrationstests in Form eines Virtualisierungsservers endlich fertig. Trotz Klausurstress lasse ich es mir nicht nehmen, abends zur Entspannung virtuelle Maschinen anzugreifen. Den Anfang macht Metasploitable 2, von dem ich bereits viel gelesen habe, es aber noch nie selbst angefasst habe.

Wie der Name bereits andeutet, soll zum Testen Metasploit zum Einsatz kommen. Nach Installation und Einrichtung (unter Kali Linux nicht notwendig), wird Metasploit durch Eingabe des Befehls msfconsole gestartet. Metasploit erlaubt das Verwalten verschiedener Ziele in sogenannten Workspaces. Workspaces erleichtern es, den Überblick zu behalten. Darum wird einer verwendet.

Bildschirmfoto - 30.01.2014 - 22:11:25

Um einen ersten Überblick über die von Metasploitable angebotenen Dienste zu bekommen, wird der Portscanner nmap eingesetzt. Da nur ein einzelner Host zu prüfen ist und die Erkennung des Scans keine Rolle spielt, kann ein kompletter Portscan mit Test aller 65.535 Ports und Versionserkennung gestartet werden. Der Scan wird mit dem Befehl db_nmap -A -p1-65535 metasploitable-ip-adresse gestartet und dauert circa 5 Minuten. Das Ergebnis sieht wie folgt aus und wird automatisch in der an Metasploit angeschlossenen Datenbank gespeichert.

Bildschirmfoto - 30.01.2014 - 22:19:25

Eine kurze Recherche ergibt, dass auf dem Server Ubuntu 8.04 LTS läuft. Da auf vielen Servern der SSH-Port offen ist, lässt sich aus der meist angepassten SSH-Version (hier OpenSSH 4.7p1 Debian 8ubuntu1) schnell ein Ausgangspunkt für die Schwachstellen-Recherche finden.

Die Version 2.3.4 des FTP-Servers vsftpd sticht sofort ins Auge. In 2011 wurden die Projektserver des vsftpd Projekts kompromittiert und eine angepasste Version dort bereitgestellt. Bei Anhängen eines einfachen Smilies wie :) an den Benutzernamen öffnet die kompromittierte vsftpd Version eine Bind-Shell auf Port 6200 mit Rootrechten. Eine angemessene:) Schwachstelle:) um:) das:) Heimlabor:) einzuweihen.

Praktischerweise liefert Metasploit ein Modul für genau diese Schwachstelle mit. Durch Eingabe des Befehls search vsftpd wird Metasploit angewiesen, nach Modulen zu suchen, deren Beschreibung vsftpd enthält.

Bildschirmfoto - 30.01.2014 - 22:40:19

Das Modul wird mit dem Befehl use exploit/unix/ftp/vsftpd_234_backdoor aktiviert. Mit dem Befehl set ohne Argumente werden die möglichen Parameter des Moduls angezeigt. Um das Exploit auszuführen genügt es, die Zieladresse durch Eingabe des Befehls set RHOST ip.des.ziel.hosts zu setzen.

Bildschirmfoto - 31.01.2014 - 10:22:24

Folgend kann das Exploit mit dem Befehl run ausgeführt werden und liefert eine einfache nicht-interaktive Shell auf dem Zielsystem, die wie folgt aussieht.

Bildschirmfoto - 31.01.2014 - 10:21:59

Im folgenden Artikel wird beschrieben, wie durch den temporären Zugang eine permanente Hintertür installiert oder die Kennwörter gebrochen werden können.

OpenVPN mit TUN/TAP in OpenVZ Instanz

Um in einer OpenVZ Instanz das TUN/TAP Gerät /dev/net/tun verwenden zu können sind einige kurze Schritte notwendig. Da die Hersteller-Dokumentation leider nicht fehlerfrei zum gewünschten Ergebnis führt, hier die Zusammenfassung.

Zuerst wird die eindeutige Identifikatiosnummer der OpenVZ Instanz bestimmt. Dann kann wie folgt auf dem Host fortgefahren werden. Um die Befehle erfolgreich absetzen zu können, muss die VM teilweise gestartet und teilweise gestoppt werden.

# Identifikationsnummer, zum Beispiel 106
VZID=106
vzctl stop $VZID
vzctl set $VZID --devnodes net/tun:rw --save
vzctl set $VZID --devices c:10:200:rw --save
vzctl set $VZID --capability net_admin:on --save
vzctl start $VZID
vzctl exec $VZID mkdir -p /dev/net
vzctl exec $VZID mknod /dev/net/tun c 10 200
vzctl exec $VZID chmod 600 /dev/net/tun

Die Fähigkeit net_admin kann zu einer reduzierten Abschottung zwischen Host und Gast führen. Eine Schwachstelle gab es bereits (2).

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.