Opensuse – manuelles Anlegen von Bridge to LAN Devices (br0, br1, …) für KVM Hosts

Wenn man sich mit KVM beschäftigt, taucht u.U. das Thema auf, dass dem einen oder anderen KVM-Gastsystem ggf. ein virtuelles Netzwerk-Device im “bridged mode” zugeordnet werden soll. Dabei wird ein physikalisches Netzwerkdevice (NIC) des KVM-Hostes vom Gastsystem als Ressource für Verbindungen in die Netzwerkumgebung des Hosts genutzt. Das Gastsystem erhält eine IP-Adresse im physikalischen LAN des Hosts. Ich hatte ein solches Vorgehen in einem früheren Artikel als “direktes Bridging zum LAN” bezeichnet, um es von anderen Formen des Einsatzes virtueller Brigdes abzugrenzen. Wir beschreiben in diesem Artikel Elemente einer solchen Bridge-Konfiguration und gehen dann der Frage nach, wie man die Bridge mittels Linux-Kommandos manuell anlegt.

YaST legt virtuelle direkte LAN-Bridges im Rahmen einer Hypervisor-Installation automatisch an

Unter Opensuse unterstützt einen YaST nicht nur bei der Einrichtung von Netzwerk-Devices sondern auch beim grundlegenden Setup eines KVM- oder XEN-Hostes. Im Zuge eines solchen Setups (YaST2 >> “Install Hypervisor and Tools”) legt YaST automatisch für jedes vorhandene und konfigurierte physikalische Device des Hostes – z.B. enp8s0 – eine durch Gäste “direkt” nutzbare Bridge – z.B. br0 – an. Damit auch der Host über die Bridge kommunizieren kann, wird der physikalischen Schnittstelle (hier enp8s0) die IP-Adresse entzogen und dem erzeugten Bridge-Device (z.B. br0) zugeordnet. Siehe hierzu etwa:
http://libvirt.org/ formatdomain.html# elementsNICS
bzw.
http://libvirt.org/ formatdomain.html# elementsNICSBridge

Wozu ist eine direkte LAN-Bridge eines KVM-Hosts eigentlich gut?

Es gibt verschiedene Möglichkeiten KVM- (oder auch XEN-) Gastsysteme mit einer physikalischen LAN-Umgebung des Hosts zu verbinden. Eine “Direct Bridge To Lan” bietet einen bequemen, wenn auch nicht den sichersten Weg, einzelne Gäste in das LAN zu integrieren. Dabei teilen ggf. mehrere KVM Gastsysteme und der Host ein physikalisches Netzwerk-Device zur direkten Paketübermittlung in das physikalische LAN – und darüber wiederum ggf. ins Internet. Derartige direkte Bridges werden typischerweise mit einer Bezeichnung der Form “brN” (N steht für eine Nummer) versehen.

Wir leisten uns zum besseren Verständnis einen kurzen Exkurs: Die nachfolgende Skizze zeigt schematisch zwei unterschiedliche Arten der Anbindung von KVM-Gästen an physikalische Netze.

kvm_br0_2

Das Bild dient nur einer grundsätzlichen Veranschaulichung und ist nicht in jedem Detail ernstzunehmen. Wie der Ethernet-Protokollstapel für verschiedene virtuelle Devices intern tatsächlich verarbeitet wird, sei mal dahingestellt.

Direct Bridge to LAN:
Im unteren Bereich erkennt man den Einsatz eines physikalischen Ethernet-Devices “enp8s0” im Rahmen einer “Direct Bridge to LAN”.

Die Bridge ist zwar ein virtuelles Konstrukt (mit Kernel-Unterstützung); im Sinne der Zeichnung kann man sich aber vorstellen, dass sie wie ein realer Hub/Switch mit diversen Ports versehen ist, an die wiederum physikalische und virtuelle Netzwerkdevices angebunden werden. Ich habe die Ports mit den entsprechenden Bezeichnungen der angebundenen Devices versehen.

Die Bridge übernimmt dabei eine Doppel-Rolle – einerseits entspricht sie einem host-bezogenen Ethernet-Netzwerk-Device mit einer IP-Adresse und garantiert eine entsprechende Paketverarbeitung im Kernel; andererseits subsummiert sie die gesamte Logik zur Ethernet-Paketelimination bzw. -Paket-Verteilung zwischen den virtuellen Ports. Die Bridge behandelt Pakete
normalerweise und im Gegensatz zur physikalischen NIC dabei nicht im “promiscuous mode”, sondern verwirft Pakete, die angeschlossenen Devices nicht zugeordnet werden können. (Für bestimmte Zwecke kann man eine Linux-Bridge aber auch in einen “promiscuous mode” versetzen.)

Die Bridge ist bei bestimmten Einstellungen (sog. ageing-Parameter; s. die “man”-Seiten für das Kommando “brctl”) ferner in der Lage, wie ein Switch zu fungieren und Pakete gezielt und ausschließlich zu den richtigen Target-Ports weiterzuleiten. Das ist der Standard; die Bridge kann aber auch in einen HUB-Modus versetzt werden. Wegen einer weitgehenden Gästeisolation ist das aber selten wirklich wünschenswert.

Das physikalische Interface (enp8s0) wird gezielt mit der Bridge assoziiert (s.u.) und übernimmt in etwa die Funktionen eines physikalischen Uplinks. Die physikalische NIC wird bei der Bridgezuordnung automatisch in den sog. “promiscuous mode” geschaltet, da sie ja Pakete für verschiedene IP- bzw. MAC-Adressen in Empfang nehmen muss.

Die beiden dargestellten KVM-Gastsysteme nutzen die Kapazitäten der physikalischen NIC über die Bridge. Hierzu werden weitere virtuelle Netzwerk-Interfaces (tun/tap-Devices) “vnet0” und “vnet2” verwendet, die in die Konfiguration des Gastsystems aufgenommen und natürlich auch der Bridge zugeordnet werden.

Der Host selbst erhält im Beispiel über die Adresse 192.168.2.1, die br0 zugeordnet wurde, Kontakt zum umliegenden physikalischen LAN. Die Gastsysteme teilen sich die physikalischen Ressource über die Adressen 192.168.2.5 bzw. 192.168.2.6. Sie erscheinen mit diesen Adressen direkt im (physikalischen) LAN und sind (je nach Firewall-Einstellungen) von dort aus auch ansprechbar. Dem physikalischen Interface (enp8s0) selbst wird in dieser Konfiguration keine IP zugeordnet.

Alternative – Host-Only-Bridge und Routing:
Im oberen Bereich der Abbildung ist dagegen eine weitere virtuelle Bridge “virbr0” dargestellt ist, die ein reines “Host-Only Netzwerk” realisiert. Die beiden Gäste wie der Host können über (virtuelle) NICs auch mit einer solchen rein virtuellen Bridge “virbr0” verbunden werden. Das der Bridge ggf. zugeordnete virtuelle Host-Device taucht bei einer Standardvorgehensweise mit KVM oder libvirt-Tools (virt-manager !) normalerweise unter der Bezeichnung “virbr0-nic” auf. Diese Bridge-Variante, die im Grunde wie ein virtueller Switch funktioniert, wird jedoch nicht direkt mit einem physikalischen Device verbunden. Sind die Gastsysteme nur an eine solche “virbr0” angebunden, so erfordert eine Verbindung zur Außenwelt ein (ggf. NAT-) Routing auf dem Host zwischen dem virtuellen Interface “virbr0-nic” des Hostes und einer seiner physikalischen NICs. Eine solche – relativ kontrolliert und gut absicherbare – Situation trifft man häufig auf produktiven KVM-Hosts an.

Hinweis: Die Skizze dient nur der Illustration unterschiedlicher Typen virtueller Bridges – und stellt kein praktisch sinnvolles Szenario dar. Würde man die dargestellte – wenig ressourcenschonende – Situation tatsächlich realisieren, müsste man natürlich aufpassen, keine Netzwerk-Loops durch problematisches Routing zu generieren. Auch die Namensgebung pro Host und Netzwerk sowie die DHCP-Dienste für die beiden Netze müssten strikt getrennt werden. Ein Default Gateway sollte dann nur für eine Netzwerkverbindung definiert sein, hier für das physikalische LAN.

Ich mache ausdrücklich darauf aufmerksam, dass ein direktes Bridging zwar eine einfache Möglichkeit darstellt, Gastsysteme an die physikalische Umwelt anzubinden. Das Ganze ist aus Sicherheitsgründen aber durchaus problematisch – zu denken ist vor allem an ARP- und auch IP-Spoofing durch die Gastsystemnutzer. Der Host muss deshalb mit einer Kombination von iptables- und ebtables-Regeln ausgestattet werden, um die direkte Bridge abzusichern. Auch und
gerade, wenn der Host noch Routing-Aufgaben übernimmt. In produktiven Umgebungen ist eher auf Host-Only Konfigurationen mit/ohne NAT zu setzen.

Auf Test- und Übungssystemen – insbesondere lokalen Pentest-Umgebungen, bei denen Zielsysteme für Übungen im gleichen oder unterschiedlichen virtuellen Segmenten untergebracht werden – vereinfacht eine temporäre Nutzung von gebridgten Host-Devices aber durchaus die regelmäßig erforderliche Aktualisierung von bestimmten Gastsystemen – man sollte nur nicht vergessen, diese Devices unter internen Penetrationstests in seinen virtuellen Netzen abzuklemmen. Für interne Pentest-Übungen zwischen Gästen eines Virtualisierungshosts wird man dagegen Host-Only Bridges – ohne (!) aktiviertes Routing auf dem Host – nutzen, die gegenüber der Umwelt isoliert sind. Aber auch wenn Penetrationstests nach außen gerichtet werden, kann die Nutzung virtuelle Maschinen hinter einer gebridgten NIC sinnvoll sein.

Manuelles Anlegen einer direkten br0-Bridge zu einem physikalischen Device

Eine durchaus interessante Frage ist, ob und wie man unter Opensuse/SLES eine solche Bridge auch manuell anlegen kann – z.B. wenn man sich (möglicherweise über YaST) die Bridge-Konfiguration zerschossen hat. (Z.B. dadurch, dass man in einem Anflug von Unkonzentriertheit der Ethernet-Schnittstelle über YaST irgendwann wieder direkt eine IP-Adresse zugeordnet hat).

Voraussetzung – ein aktivierbares Netzwerk-Interface

Ich möchte in diesem Artikel nicht auf die manuelle Anlage eines physikalischen Ethernet-Netzwerk-Devices selbst eingehen. Hierzu müsste man für moderne Linux-Systeme den aktuellen “udev”- und “systemd”-Mechanismus, das automatische Erkennen und Identifizieren von Devices gem. entspr. Datenbanken, die Bereitstellung von Gerätedateien unter “/dev”, das (automatische) Laden zugehöriger Treiber und auch die Vergabe von “predictable” Device-Namen besprechen (und verstehen). Hier zieht man sich besser auf YaST oder die suse-spezifischen Konfigurationsdateien unter “/etc/sysconfig/network” zurück, in denen bestimmte Parameter wie die IP-Adresse für ein Device permanent hinterlegt werden.

SuSE-spezifische Informationen zur Konfiguration findet man hier:
https://www.suse.com/ de-de/ documentation/ sled11/ book_sle_admin/ data/sec_basicnet_ manconf.html
und hier
https://www.suse.com/ documentation/ sles-12 /book_sle_admin/ data/ sec_basicnet_ manconf.html
Die letzte Doku passt auch gut zu Opensuse 13.2.

Übrigens: Wer verstehen will, wie udev/systemd zu den “predictable names” für Devices gelangen, der lese folgenden Artikel
https://major.io/ 2015/08/21/ understanding-systemds-predictable-network-device-names/

und meine Zusammenfassung unter
Linux-Namensgebung für physikalische Netzwerk-Devices

Ich gehe davon aus, dass es auf unserem KVM-Host z.B. bereits ein aktiviertes Ethernet-Device – in unserem Beispiel “enp8s0” – gibt. Soll es von KVM-Gästen über eine direkte virtuelle Bridge zum LAN genutzt werden, darf ihm beim Systemstart keine IP-Adresse zugeordnet werden. Dies kann man einerseits über “YaST2 >> Netzwerkeinstellungen” für diese NIC einstellen. Alternativ kann man manuell das opensuse-spezifische File “/etc/sysconfig/network/ifcfg-enp8s0” anlegen und mit leeren Konfigurationsanweisungen editieren:

mytux:/etc/sysconfig/network # cat ifcfg-enp8s0 
BOOTPROTO='none'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU=''
NAME=''
NETMASK=''
nNETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
DHCLIENT_SET_DEFAULT_ROUTE='yes'
PREFIXLEN=''
mytux:/etc/sysconfig/network # 

Einrichtung einer Bridge mittels des Kommandos brctl

Opensuse 13.2 nutzt im Gegensatz zu früheren Opensuse-Versionen “wicked” zum Starten von NICs etc.. Durch den “compat”-Modus von “wicked” werden aber immer noch die klassischen “ifcfg-…”-Dateien, die unter “/etc/sysconfig/network” definiert sind, unterstützt und ausgelesen.

Leider ist die zugehörige Factory-Doku von SuSE zu diesem Themenkomplex noch nicht ausgereift. Es lohnt sich daher, zunächst ein Blick in die SLES12-Doku zu werfen. Siehe hierzu:
https://activedoc.opensuse.org/ book/ opensuse-reference/ chapter-13-basic-networking
https://www.suse.com/ de-de/ documentation/ sles-12/book_sle_admin/data/sec_basicnet_ manconf.html
Siehe ergänzend zu den bereits erwähnten Quellen auch :
https://activedoc.opensuse.org/ book/ opensuse-virtualization-with-kvm/ chapter-12-running-virtual-machines-with-qemu-kvm

Man kann eine Standard-Bridge “br0” unter Opensuse natürlich mit Hilfe von YaST2 einrichten.
Es lohnt sich aber, das mal manuell zu machen, um entsprechende Befehle und suse-spezifische Konfigurationsdateien kennenzulernen. Der entscheidende Befehl hierzu ist “brctl”, zu dem man sich unbedingt mal die man-pages durchlesen sollte.

Man beachte auch: Das Tool “Network-Manager” unterstützt bislang meines Wissens keine Bridge-Strukturen – im besonderen nicht “direkte” Linux-Bridges zu physikalischen NIC_Devices.

Das nachfolgende Beispiel zeigt die Anlage einer “direkten” Host-Bridge über “brctl addbr” und die Zuordnung zu einem physikalischen Ethernet Device (für direktes Bridging) mittels “brctl addif”. [Hierbei wurde vorausgesetzt, dass dem physikalischen Device bislang keine IP-Adresse zugeordnet wurde.] Die Aktivierung des erzeugten Bridge-Devices erfolgt ganz konventionell über “ifconfig br0 up”.

Der Bridge selbst wird dann mittels “ifconfig” sehr eine IP-Adresse zugeordnet. Dies ist dann die Adresse unter der der (KVM-) Linux-Host selbst nach außen kommunizieren kann. Natürlich hätte man das alles statt mit “ifconfig” auch mit dem Kommando “ip” und seinen Optionen erledigen können. Ich überlasse diese Übung dem Leser.

mytux:~ # ifconfig enp8s0 down 
mytux:~ # ifconfig enp8s0 up 
mytux:~ # brctl addbr br0
mytux:~ # ifconfig br0 up 
mytux:~ # brctl addif br0 enp8s0
mytux:~ # brctl show
mytux:~ # ifconfig br0 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255
mytux:~ # ifconfig br0 

Um diese erreichte Konfiguration permanent machen, muss man noch ein entsprechendes ifcfg-File unter “/etc/sysconfig/network” mit folgendem beispielhaften Inhalt anlegen:

mytux:/etc/sysconfig/network # cat ifcfg-br0
BOOTPROTO='static'
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='enp8s0'
BRIDGE_STP='off'
BROADCAST=''
DHCLIENT_SET_DEFAULT_ROUTE='yes'
ETHTOOL_OPTIONS=''
IPADDR='192.168.2.1/24'
MTU=''
NETWORK=''
PREFIXLEN='24'
REMOTE_IPADDR=''
STARTMODE='auto'
NAME=''
mytux:/etc/sysconfig/network #

 
Nicht vergessen sollte man die Definition
eines Default-Gateways für Routing nach außen – im Beispiel etwa über einen Host “192.168.2.10”. Das erfordert eine weitere Textdatei namens “ifroute-br0” unter “/etc/sysconfig/network”. Der Inhalt besteht nur aus einer Zeile “default 192.168.2.10 – br0”:

mytux:/etc/sysconfig/network # cat ifroute-br0 
default 192.168.2.10 - br0 
mytux:/etc/sysconfig/network # 

 
Das ganze Vorgehen lässt sich natürlich für die Anlage weiterer direkter Bridge-Devices zu anderen noch vorhandenen physikalischen Erhernet-Devices wiederholen.

Über Tools zur Einrichtung von KVM-Gastsystemen (wie virt-manager) kann man nun virtuelle NICs der Gastsysteme anlegen und der erzeugten Bridge zuordnen. Ich gehe darauf in einem weiteren kommenden Artikel ein.

Steht die Bridge erst einmal, so kann man ihren Status und aktive, zugeordnete Devices über das Kommando “brctl show br0” ansehen:

mytux # brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.1c6f653dfd1e       no              enp8s0
                                                        vnet0
                                                        vnet2

 
Der Befehl “wicked show all” zeigt übrigens auch die NIC-Zuordnung zu Bridges und zudem die IP-Adressen an:

mytux: # wicked show all           
lo              up
      link:     #1, state up
      type:     loopback
      config:   compat:/etc/sysconfig/network/ifcfg-lo
      leases:   ipv4 static granted
      leases:   ipv6 static granted
      addr:     ipv4 127.0.0.1/8 [static]
      addr:     ipv6 ::1/128 [static]

enp8s0          enslaved
      link:     #2, state up, mtu 1500, master br0
      type:     ethernet, hwaddr 1d:ff:76:5c:cd:4e
      config:   compat:/etc/sysconfig/network/ifcfg-enp8s0

br0             up
      link:     #4, state up, mtu 1500 
      type:     bridge               
      config:   compat:/etc/sysconfig/network/ifcfg-br0
      leases:   ipv4 static granted    
      addr:     ipv4 192.168.2.1/24 [static]
      route:    ipv4 default via 192.168.2.10

vnet0           device-unconfigured
      link:     #12, state up, mtu 1500, master br0
      type:     tap, hwaddr fe:54:00:cc:dd:ee

vnet1           device-unconfigured
      link:     #13, state up, mtu 1500, master br0
      type:     tap, hwaddr dd:54:00:dd:ee:ff

vnet2           device-unconfigured
      link:     #14, state up, mtu 1500, master br0
      type:     tap, hwaddr fe:54:00:22:33:44

Viel Spaß beim Experimentieren mit virtuellen Bridges!

 

Erste Erfahrungen mit Kali Linux 2.0 unter KVM/qemu auf einem Opensuse 13.2 Host

Ich muss mich in näherer Zukunft aus beruflichen Gründen stärker mit Penetration-Testing und IT-Forensic beschäftigen. Um bestimmte Szenarien nachzustellen, bedarf es einer virtuellen Übungsumgebung. Dabei liegt es u.a. nahe, Kali 2.0 auf einem virtualisierten Gastsystems zu nutzen.

Die von mir inzwischen bevorzugte Virtualisierungsumgebung für Linux-Gastsysteme auf einem Virtualisierungshost ist KVM/qemu mit virt-manager/libvirt als Frontend-Gespann. Da ich vorab von etlichen Problemen zu zu Kali 1.0, aber auch Kali 2.0 in normalen und virtuellen Umgebungen gelesen hatte, war ich etwas gespannt, was auf einem Opensuse-13.2-Host im Zuge einer KVM-Installation von Kali 2.0 alles an Ungemach auf mich zukommen würde.

Ich kann nach nunmehr ein paar Wochen Benutzung zusammenfassend nur sagen: Es gibt praktisch keine ernsthaften Probleme.

Die Installation über ein ISO-Image läuft auf Opensuse 13.2-Plattformen mit i7-Prozessor, SSD, Nvidia-Graka (mit propr. Treiber) bzw. Laptop mit Optimus-Grafik problemfrei. Ich habe inzwischen mehrere Installationen auf verschiedenen Systemen (PC, Laptops mit Optimus) mit Hilfe von “virt-manager” durchgeführt, ohne mich mit etwas Gravierendem auseinandersetzen zu müssen. (Virtualisierungsprofis werden natürlich eher auf XML-Konfigurationsdateien oder explizite Kommandos/Scripts zurückgreifen. Das ist aber sekundär.) Wichtig ist, dass der Host aktualisiert ist und die KVM-Virtualisierungsumgebung vorab auf Funktionstüchtigkeit getestet wurde.

kali_install_800

Ich erlaube mir, im Vorgriff auf weitere Artikel an dieser Stelle ein paar hoffentlich hilfreiche Hinweise zu geben:

  • RPM-Pakete zu KVM, libvirt/virt-manager:
    Ich habe die KVM/qemu/libvirt-Pakete der Opensuse 13.2-Standard-Repositories und nicht die brandaktuellen Pakete des Opensuse-libvirt-Repositories verwendet.
  • Video-Konfiguration des Gastsystems:
    Man wähle bei der Konfiguration des Gastes in jedem Fall ein Spice-Display mit einem virtuellem Video-Interface “Video QXL”. Für virtuelle Platten nehme man “debianwheezy.qcow2”-Devices mit virtio-Treiber. Auch die virtuellen NICs sollten mit virtio-Treibern unterfüttert werden.
  • Änderung virtuelle Bildschirmgröße:
    Änderungen der virtuellen Bildschirmgröße für das Gnome-X-Display kann man über den Punkt “Anwendungen” in der linken Gnome-Leiste, die Anwendung “Einstellungen” >> Monitore” sehr bequem vornehmen. Die grafische Interaktion über Spice läuft auf meinem System sehr flüssig. Da haben die Entwickler hinter Spice in den letzten 2 Jahren wirklich großartige Arbeit geleistet.
  • SSH-Zugang vom Host:
    Ist einem Spice (entgegen meiner eigenen Erfahrung) zu träge, so kann man natürlich auch über “ssh -X” auf der virtuellen Maschine arbeiten. Wenn man das tut, sollte man sich vorab ernsthaft Gedanken über die Isolierung des KVM-Gastes während Penetration-Experimenten in seinen virtuellen Netzen machen. Ich nutze für den Zugang zum Kali-Gast meist ein von anderen virtuellen Bridges separates Host-Only-Netzwerk, dessen HOST-Interface von evtl. Routing auf dem Host per Paketfilter (netfilter mit iptables/ebtables) explizit ausgeschlossen ist. Stattet man das Kali-Gastsystem mit mehreren virtuellen NICs aus, sollte dort aus Sicherheitsgründen während Penetrationstest-Übungen in virtuellen Netzen kein
    Routing aktiviert sein.
  • “Gnome Control Center”-Zugang?

    Für Gnome-Ungewohnte: Viele System- und Desktop-Einstellungen erreicht man über das sog. “Gnome Control Center”, was man von der Kommandozeile eines Terminals mittels

    mykali~: # gnome-control-center &

    starten kann.
    Der Aufruf funktioniert allerdings nur lokal innerhalb des Spice-Displays. Er funktioniert nicht über eine SSH-Shell vom Host aus. Es wird ein X-Window-Fehler angezeigt – und zwar erstaunlicherweise aus dem glx-Bereich – offenbar wird am Display ein glx-fähiger Renderer erkannt. Ähnliche Fehler gab es übrigens unter Debian und Ubuntu schon früher bei VNC- und X2go-Verbindungen. Man musste damals GL-X und OpenGL-Fähigkeiten des Remote Displays explizit abschalten. Offenbar liegt nun ein ähnliches Problem vor.
    Es funktioniert leider auch nicht nach einem

    export LIBGL_ALWAYS_INDIRECT=y

    auf dem Kali Gast.
    Keine Ahnung. Schlichter Anwendungs-Bug? Irgendwelche Inkompatibilitäten zwischen dem MESA/libGL-Bibliotheken unter Debian und dem 3D-Nvidia-Treiber Setup auf dem Opensuse-Host? [glxheads läuft – und nach einer Installation von VirtualGL auch glxspheres; glxinfo zeigt vernünftige Meldungen. Warum das “gnome-control-center” überhaupt libGL-Ahängigkeiten auflösen muss, entzieht sich meinem Verständnis. Genauer: Warum machen die Gnome-Entwickler ein so zentrales Ding vom Erkennen eines glx-fähigen Displays und spezifischen Reaktionen darauf abhängig?] Das Thema ist mir im Moment zu aufwändig und auch zu kniffelig; das Problem schränkt aber die eigentliche Arbeit mit Kali in der virtuellen Umgebung nicht wirklich ein.

    Übrigens: Für Änderungen der Netzwerk-Einstellungen – was ggf. häufiger benötigt wird – steht auf einer SSH-Konsole auch der Befehl

    nm-connection-editor

    zur Verfügung, der ein geeignetes grafisches Interface für “NetworkManager” öffnet.

  • apt-get-Konfiguration
    Lediglich die “apt-get”-Konfiguration ist nach der Installation evtl. anzupassen, je nachdem welche Optionen man bzgl. des Update-Verhaltens während der Installation gewählt hat oder wählen konnte. Letztlich sollte die Datei “/etc/apt/sources.list” folgende Einträge enthalten:

    mykali2:~# cat /etc/apt/sources.list
    deb http://http.kali.org/kali/ sana main contrib non-free
    deb-src http://http.kali.org/kali/ sana main contrib non-free
     
    deb http://security.kali.org/kali-security/ sana/updates main contrib non-free
    deb-src http://security.kali.org/kali-security/ sana/updates main contrib non-free

    Auf dieser Grundlage sollte man nach der Installation unbedingt die Sequenz

    mykali:~# apt-get clean
    mykali:~# apt-get update
    mykali:~# apt-get upgrade

    ausführen lassen. Wichtig für eine einwandfreies Starten von “armitage” als Metasploit-Frontend und auch für einen funktionierenden JtR.

  • Bei evtl. Problemen mit einem Armitage-Start:
    Armitage ist ein wichtiges teilgrafisches Frontend für eine Reihe von Tools, u.a. Metasploit. Es sollte neben der “msf-console” lauffähig sein. Dazu sind ein paar Voraussetzungen erforderlich. Wie im letzten Punkt beschrieben, sind zunächst Updates und Upgrades mittels apt-get durchzuführen. Vor dem “armitage”-Start muss zudem die Postgre-Datenbank laufen. Dazu:

    mykali:~# /etc/init.d/postgresql start
    [ ok ] Starting postgresql (via systemctl): postgresql.service.

    Achtung: Der
    Verbindungsaufbau zum XML-RPC-Dämon verzögert sich ggf. etwas, wenn “msfrpcd” und sein Connection Client im Zuge des armitage-Starts erst nachgeladen und selbst gestartet werden. Einer unmittelbaren Meldung über einen abgelehnten Verbindungsaufbau sollte man daher mit etwas Geduld begegnen. Armitage läuft bei mir auch über eine SSH-Shell auf dem Virtualisierungshost.

  • Virtuelle Netze:
    Eine Pen-Test-Übungsumgebung setzt auf dem Host virtuelle Netzwerke mit weiteren virtualisierten Target-Systemen voraus. “virt-manager” unterstützt einem beim Einrichten von virtuellen Netzwerken und deren Bridge-Konfigurationen auf dem Host sehr gut, so dass es hier kaum zu Problemen kommen sollte.
    Der Kali-Gast unter KVM ist danach mit mehreren Interfaces zu unterschiedlichen virtuellen Netzen – und/oder zum (ggf. spezifisch routenden) Host – auszustatten. Ggf. sind sogar virtualisierte Bridges/Switches auf dem Host und deren Verhalten bei Angriffen von einem virtualisierten Gast aus Hauptgegenstand der Untersuchung. In jedem Fall sollte man sich sehr genau überlegen, mit welchen virtualisierten Netzen man den Host ausstattet und wie der Kali-Gast mit diesen Netzen in Kontakt tritt. Für eine Einarbeitung in virtuelle Netze kann man etwa den Literatur-Hinweisen unter
    https://linux-blog.anracom.com/2015/10/19/virtualisierte-netze-mit-kvmqemulibvirt-hinweise-und-links-zur-systematischen-einarbeitung-2/
    folgen.
    Auf dem Kali-Gastsystem selbst bietet das Netzwerk-Symbol rechts auf der obigen Bedienleiste des Gnome-Desktops schnellen Zugang zu Netzwerk-Einstellungen. Alternativ über das “Gnome Control Center”: Unter “Anwendungen” suche man “Einstellungen >> Netzwerk”. Die Möglichkeit, “Profile” für das jeweilige NIC einzurichten, ist absolut nützlich – vor allem wegen des Anlegens von evtl erforderlichen Routen auf dem Gastsystem. Dass auch bei kleineren Änderungen möglicherweise gleich ein komplettes neues Profil angelegt wird, ist etwa gewöhnungsbedürftig. Zudem klappt das Umschalten zwischen validen Profilen in der virtualisierten Umgebung nicht immer ganz problemfrei. Zur Not muss man die Netzwerkverbindung über die angebotenen Schalter stoppen und neu starten. Überflüssige Profile sollte man tunlichst löschen. Einmal laufende Verbindungen für die verschiedenen NICS zu unterschiedlichen virtuellen Netzen und ihren Bridges werden zuverlässig reproduziert.
  • Internet-Zugang:

    Natürlich benötigt das virtuelle Gastsystem für Paketinstallationen Internet-Zugang. Auch hier stellt sich wieder die Frage der Isolation des Systems. Man hat hier mehrere Möglichkeiten in ansteigender Reihenfolge der Isolation:

    direktes Bridging einer virtuellen Gast-Nic auf eine physikalisches Device des Hosts, virtuelle Bridge mit virtuellem Host-Interface und Routing am Host, virtuelle Bridge mit virtuellem Host-Interface und NAT-Konfiguration am Host.

    Die letzte, ggf. aber auch die vorletzte Variante erfordern entsprechende Netfilter-ebtables/iptables-Regeln am Host zur besseren Kontrolle. Was immer man wählt:

    Die entscheidende Punkt ist, ob und dass man das System während Penetrationstests in seiner virtuellen Umgebung vom Kontakt mit der Umwelt abklemmt und dafür die entsprechenden virtuellen Interfaces des Hosts abschaltet – oder ob man bei bestimmten Tests parallel auf das Internet zugreifen muss/will. Letzteres sehe ich für Übungsszenarien im virtuellen Labor eher als Problem. Ich erledige Internet-Recherchen etc. im Zweifel eher über den Host selbst.

Fazit:
Insgesamt bin ich mit dem Einsatz von Kali unter KVM auf einem Opensuse-13.2-Host sehr zufrieden. Die KVM-Umgebung
bietet hinreichend Flexibilität, um jede Art von virtuellem Netz aufzusetzen und bei Bedarf auch ad hoc und zügig zu ändern. Das ist für ein Penetration-Test-Labor optimal. Das Kali 2.0-System ist gut aufgeräumt und bekanntermaßen mit vielen nützlichen Tools ausgestattet, die für die verschiedenen Phasen und Aufgabenbereiche von Pen-Tests vorsortiert sind. Der Debian-Unterbau von Kali 2.0 läuft unter KVM mit Spice und virtio-Treibern wirklich flüssig. Es macht richtig Spaß!

Interessanterweise muss ich als alter KDE-Nutzer sogar zugeben, dass ich dem schnörkelfreien Gnome-Desktop von Kali durchaus etwas abgewinnen kann. Man arbeitet ja meist eh’ auf der Kommando-Zeile …