Datenschutz-Einwilligung – Google’s wachsender Druck auf Nutzer der Suchmaschine – wie erwartet …

Hatte ich doch noch vor ein paar Tagen in diesem Blog darüber spekuliert, dass das EuGH-Urteil nicht ohne Folgen bleiben wird und es auch den deutschen Datenschutzbestimmungen ein breite Bresche schlägt. Siehe
http://linux-blog.anracom.com/2015/10/13/eugh-urteil-zu-safe-harbour-und-die-reaktion-der-vordenker-zeitschrift-die-zeit/

Und was passiert: Eine wachsende Anzahl deutsche Nutzer der Google Suchmaschine erhalten nun - mit oder ohne Google-Konto - regelmäßig und mit verschärfter Tonlage eine Einblendung, über die der Anwender dem Unternehmen Google quasi eine Zustimmung zum Datensammeln erteilen muss, wenn er die Google Dienste - in diesem Fall die Suchmaschine - weiter nutzen will. Zuletzt hat der Stern darüber berichtet; siehe
http://www.stern.de/tv/google-datenschutzeinstellung--hinweise-zum-pop-up-6512842.html#mg-1_1445528506974
Dieses in die Suchmaschinenseiten eingebettete, relativ groß dimensionierte "Pop-Up" bietet keine Möglichkeit, das Verlangen von Google abzulehnen.

Das eigentlich Erschreckende - wenn auch kaum Neue - ist, dass Einem beim genauen Lesen der weiteren Dialoge (speziell beim Durcharbeiten der "Optionen") das erklärte Ziel der Zustimmung sehr klar vor Augen geführt wird - nämlich die Erlaubnis nicht nur zur Erfassung sondern auch zur Zusammenführung letztlich personenbezogener Daten auf allen Ebenen. In diesem Zusammenhang von Daten-"Schutz" zu reden würde selbst Herrn Orwell wundern. Nun, damit ist wenigstens für Klarheit gesorgt. Verwunderlich ist das nicht - mit Persönlichkeitsprofilen und Werbung verdient Google ja schließlich sein Geld.

Google erlaubt einem dann netterweise noch einen Streifzug durch diverse browser- und dienste-bezogenen Einstellungen. Man kann zwar einige Einstellungen ändern - aber die schränken Werbung und das dafür erforderliche Datensammeln lediglich etwas ein - beendet wird das Erheben von Daten zur eigenen Person und zum Verhalten bei der Suche mit Google dadurch keinesfalls. Auch die Werbung wird nicht komplett unterbunden. Das wird fairerweise auch gesagt. Konsequenterweise bietet Google's aktuelle Popup-Meldung auf den Seiten der Suchmaschine auch keine Option zum pauschalen Ablehnen des Erfassens und Zusammenführens meiner personenbezogenen Daten an. Das ist eine klare und deutliche Botschaft: Gib mir deine Daten oder nutze meinen Dienst nicht!

Ich finde das keineswegs verwerflich. Nur außerordentlich überdenkenswert - und mit hohem Druck auf den Anwender unterlegt. Nicht verwerflich heißt für mich dabei noch lange nicht gut. Google will angesichts der rechtlich verschärften Lage vom (deutschen?) Nutzer nun offenbar eine explizite Zustimmung erzwingen und damit Rechtssicherheit für das eigene Unternehmen schaffen. Wir haben es hier mit einem, nicht mehr ganz neuen Phänomen, das ich "Erzwingungs-Popup" nennen möchte, zu tun. Einer Art Eula für die Suchmaschine ...

Noch - wohlgemerkt noch (!) - ist die Lage aber nicht ganz hoffnungslos. Wenn man als Nutzer von Google das Sammeln von Daten zum eigenen Persönlichkeits- und Verhaltensmuster auch nicht nicht mehr implizit oder pauschal ablehnen kann, so kann man es wenigstens teilweise umgehen - wenn auch vermutlich nur für einige Zeit. Auf das Wie komme ich weiter unten zurück.

Ist das Ganze eigentlich überraschend? Habe ich eigentlich etwas anderes erwartet? Nein! Schließlich stellen die zunehmend präzisierten deutsche Datenschutzanforderungen, das EuGH-Urteil und auch ein insgesamt vermehrtes Bewusstsein für Privatsphäre und informationelle Selbstbestimmung zumindest in Deutschland die aktuellen Geschäftsmodelle nicht nur von Google, sondern diverser Internet-Giganten grundlegend in Frage. Das provoziert Reaktionen und führt fast zwangsläufig zu diesen Methoden.

Das hat auch sein Gutes - denn die Interessengegensätze zwischen Geldverdienen mit Persönlichkeitsprofilen und den Anforderungen nach informationeller Selbstbestimmung in einer Demokratie treten so klarer zu Tage. Das kann der Diskussion nur dienlich sein. Zudem sollte jedem Nutzer hierzulande bewusst werden, wie abhängig wir uns von den durchaus nützlichen Diensten der US-Internet und IT-Giganten gemacht haben - ohne regelmäßig zu bedenken, dass es im Internet nichts umsonst gibt. Wir bezahlen so oder so - mit Geld oder Daten zu unserer Persönlichkeit, unseren Gewohnheiten und Interessen. Das ist eine nüchterne Feststellung - die Kritik richtet sich hier in erster Linie an die eigenen Versäumnisse und nicht dagegen, dass Google klar definierte Geschäftsinteressen verfolgt. Das ist aus meiner Sicht zumindest im Rahmen geltender Gesetze völlig legitim.

Was kann man aktuell tun?
Zähneknirschend zustimmen mag für viele eine Option sein. Bei mir ist es zunächst so, dass ich mich ungern zu solchen weitreichenden Entscheidungen über eine Meldung auf einer Webseite erpressen lasse. Freiheit der Meinungsbildung und auch der Entscheidung ist mir konservativem Menschen eben wichtig. Meinungsbildung erfordert zudem Zeit - und nicht einen spontanen Klick mit der Maus. Nun kann man durchaus etwas auf Zeit spielen - und sei es nur deswegen, um sich die Sache nochmal gründlich durch den Kopf gehen zu lassen:

  1. Im Google-Erzwingungs-Popup bzw. in der Googlemeldung zunächst und so lange es möglich ist auf "Später lesen" klicken.
  2. Google wird sich nach einiger Zeit wieder melden und dem Nutzer im Ton und Layout der Meldung keine Wahl mehr lassen, als sich mit dem Thema intensiver zu beschäftigen.
  3. Dann erst mal die "Optionen" wahrnehmen und den folgenden, durchaus interessanten Spaziergang durch die Einstellmöglichkeiten mitmachen. Dabei das Maximale im Sinne der Privatsphäre herausholen.
  4. Dann eben nicht einfach zustimmen - es sei denn man will es wirklich. Sondern die geöffnete Webseite mit der Google-Suche schlicht schließen.
  5. Alle Cookies oder speziell die Cookies von Google löschen. (Und soweit möglich, über seinen Router vom Internet-Provider mal häufiger eine neue IP anfordern.)
  6. Firefox im Bereich "Privatsphäre" so einstellen, dass er alle Cookies beim Beenden des Browsers automatisch löscht. Für andere Browser bzw. eine ältere FF-Version analoge Einstellmöglichkeiten ausfindig machen.

Das wirkt erstmal, weil der Mechanismus hinter dem Erzwingungs-Popup z.Z. offenbar noch cookie-basiert ist. Leider verfügt Google natürlich noch über andere Mittel, eine konkrete Person bei der Nutzung der Suchmaschine zu identifizieren. Das Ganze wird also nur eine vorübergehende Lösung sein. Da ich nicht wirklich damit rechne, dass Google ein Einsehen zeigen wird, bleibt danach vermutlich nur,

  • konsequent den "Tor"-Browser zu nutzen,
  • Suchen bei Google über die Seite https://search.disconnect.me/ durchzuführen (bis Google das auch nicht mehr zulässt),
  • schlicht die Suchmaschine zu wechseln (bis auch die anderen IT-Konzerne über ähnliche Erzwingungsmethoden die Zustimmung des Nutzers zum Datensammeln erzwingen). Z.Z. lohnt sich zudem ein Blick auf Meta-Suchmaschinen wie "startpage.com" oder "https://www.ixquick.com/deu/".

oder eben doch entnervt zuzustimmen. Man hat - egal wie - aber letztlich nur die Möglichkeit des Versuchs einer anonymisierten Dienste-Nutzung! Um die Dienste selbst kommt man kaum herum. Und schmerzlichst wird einem wieder bewusst: Leider haben wir Europäer bislang kein qualitativ gleichwertiges Äquivalent zu Google. Ich finde zudem: den ungehinderten Zugang zu Informationen im Internet bei Wahrung der Persönlichkeitsrechte und des Datenschutzes zu gewährleisten, ist zudem eine Hauptaufgabe eines modernen, demokratischen Staates. Ich halte es für eine Mär, dass dies mit polizeilichen Schutzaufgaben nur schwer vereinbar sei.

Liebes Unternehmen Google! Ihr habt in eurem Kerngeschäft großartige Arbeit geleistet und bietet viele nützliche und wichtige Dienste an - das steht außer Zweifel. Die Suche nach und der Zugang zu Informationen im Internet ist ein wichtiges Gut, für das ihr mit den Boden bereitet habt. Ich glaube euch sogar, dass Ihr jetzt bzgl. Datenschutz noch was lernen und vielleicht auch umsetzen wollt - solange es eure Einnahmen nicht substanziell gefährdet. Aber Datenschutz fängt mit begründetem (!) Vertrauen und nicht mit Zwangsmaßnahmen an. Das müsst ihr offenbar als Allererstes lernen .... Meines jedenfalls habt ihr heute mal wieder erschüttert. So sehr ich eure Dienste auch schätze .... Offen bleibt zudem die Frage, wie denn das Vorgehen eigentlich mit dem EuGH-Urteil in Einklang zu bringen ist. Denn es gibt ernstzunehmende Interpretationen, die genau euer Vorgehen in Frage stellen:
http://www.faz.net/aktuell/wirtschaft/maechtige-internetriesen/uld-schlewigholstein-haelt-safe-harbor-fuer-nicht-umgehbar-13858360.html

Was ist eigentlich mit der Idee, dass ihr Geld für eure Dienste verlangt und im Gegenzug zahlenden Kunden garantiert, dass das Suchverhalten nicht nachverfolgt wird, keine user-bezogenen Daten erhoben werden und dass der Suchdienst primär über europäische Server läuft? Das wäre wenigstens ein klares, offenes und ehrliches Geschäftsmodell. Wie ich euch kenne, arbeitet ihr daran bereits ... Und eine teilweise Kostenübernahme für bedürftige und finanziell Schwache wäre dann Gegenstand einer politischen Diskussion zur Verbesserung unseres Sozialsystems. Auch das kann der laufenden Auseinandersetzung um Datenschutz und informationelle Selbstbestimmung als Grundpfeiler einer modernen Demokratie nur dienen.

Links
https://www.datenschutzbeauftragter-info.de/google-verlangt-einwilligung-ich-stimme-zu/
https://www.verbraucherzentrale.de/google-datenschutz
http://www.stern.de/tv/google-datenschutzeinstellung--hinweise-zum-pop-up-6512842.html#mg-1_1445528506974
http://www.netz-trends.de/id/4353/Verstoesst-Google-mit-seinen-Datenschutz-Einblendungen-gegen-deutsches-und-EU-Recht/
http://www.googlewatchblog.de/2015/07/google-zeigt-hinweise-zum-datenschutz-bei-google/comment-page-1/#comment-141396
http://www.handelsblatt.com/my/unternehmen/it-medien/zugestaendnisse-beim-datenschutz-google-will-erwachsen-werden/12471656.html?ticket=ST-5951533-pfjOxbEXcfbs1bCsfajP-s02lcgiacc01.vhb.de
http://www.welt.de/wirtschaft/webwelt/article141754265/So-aendern-Sie-was-Google-ueber-Sie-speichern-darf.html
http://www.datenschutzbeauftragter-online.de/google-und-datenschutz/
http://www.deutschlandfunk.de/datenschutz-google-zwischen-transparenz-und-augenwischerei.735.de.html?dram:article_id=326641

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
    http://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 ...

Virtualisierte Netze mit KVM/qemu/libvirt – Hinweise und Links zur systematischen Einarbeitung

Ich befasse mich gerade mit einem Artikel zum Aufbau einer virtuellen Übungsumgebung für Penetrations-Tests unter Linux. Es geht dabei nicht um ressourcenschonendes Hosting - sondern um die Darstellung vollständiger Gastsysteme und ihrer Kommunikation in konfigurierbaren virtuellen Netzen. Die virtuellen Gastsysteme müssen zudem auf einfache Weise wieder im Originalzustand hergestellt oder eingespielt werden können. Eine Lösung mit vorgefertigten Containern (Docker, LXC) ist auf einer Workstation oder gar einem Laptop eher uninteressant; ich setze daher auf KVM/qemu für Linux-Gäste (wie Kali 2.0) und VMware WS/Player für Windows-Gäste.

Mir ist beim Schreiben erneut aufgefallen, dass interessierte Einsteiger es wahrlich schwer haben könnten, sich aus dem Sammelsurium an verstreuten Informationen im Internet einen Überblick über die Einrichtung virtueller Netzwerke unter Linux zu verschaffen. Das Niveau der zugehörigen Internet-Artikel ist uneinheitlich, die Verteilung der Information unübersichtlich. Einige Artikel sind allgmeingültig, andere stark distributionslastig. Das gilt auch für KVM/qemu und das Toolset libvirt/virt-manager.

Die oft kontextbezogene und z.T. überlappende bis synonyme Verwendung der Begriffe "Bridge", "virtueller Switch" oder "virtuelles Netz" in verschiedenen Artikeln verwirrt Einsteiger möglicherweise. Ähnliches gilt für die Abkürzung "vlan" oder "vLAN",

  • die einerseits die 802.1Q-basierte Kopplung (bonding) mehrerer NIC-Devices zur Erstellung logischer Segmente in physikalischen LANs bezeichnet (s. https://de.wikipedia.org/wiki/Virtual_Local_Area_Network),
  • die andererseits in vielen Artikeln kontextbezogen aber lediglich als Bezeichnung "virtuelles LAN" im Sinne eines virtualisierten Netzwerks auf einem Host mit Virtualisierungsumgebung (KVM/qemu, VMware, etc.) verwendet wird; oft genug ist jedoch auch das Bonding virtueller Netzwerk-Interfaces angesprochen.

Der Artikel
https://en.wikipedia.org/wiki/Virtual_network
versucht eine Abgrenzung; stellt aber richtigerweise fest, dass auch die Kombination der Konzepte - also 802.q1-basierte vNIC-Kopplung in virtualisierten Netzwerken - möglich ist. Wir betrachten in diesem Artikel "virtualisierte Netzwerke" auf Basis virtueller Bridges/Switches (vBridge/vSwitch) und virtueller Netzwerk-Interfaces (vNICs) in Virtualisierungsumgebungen unter Linux.

Zur Verwirrung mag auch beitragen, dass man bei einer Internet-Recherche zwangsläufig auch über Artikel zu relativ speziellen Netzwerk-Konfigurationsmöglichkeiten stolpert. Etwa zu eine Bridge- oder "vepa"-Konfiguration auf Basis von "macvtap/mcvlan"-Devices, bei der eine direkte Kopplung virtueller mit physikalischen Devices des Hosts unter Nutzung spezieller Eigenschaften von Ethernet-Devices ermöglicht wird. Die richtige Einordnung dieser speziellen Varianten und ihrer Konsequenzen in den Gesamt-Kanon von Möglichkeiten zur Netzwerk-Virtualisierungen dürfte am Anfang sicher nicht leicht fallen.

Ich habe in diesem Artikel deshalb ein paar Links zusammengestellt,

  • deren Lektüre meiner Meinung nach eine gestaffelte und in der Komplexität steigende Lernkurve für die Einrichtung virtueller Netze unter KVM/qemu unterstützen kann;
  • die ich selbst in der Vergangenheit verschiedentlich zu Rate gezogen habe.

Leider habe ich nicht die Zeit, eine eigene Einführung in die Thematik virtualisierter Netze zu schreiben. Aber ich möchte die angegebenen Links doch mit ein paar Anmerkungen flankieren, die Schlüsselpunkte für das grundlegende Verständnis zusammenfassen.

Vorbemerkungen zur Virtualisierung von Netzwerken unter Linux

Folgende Punkte scheinen mir zum Verständnis virtualisierter Netzwerke und ihrer Interaktion mit physikalischen Netzwerken essentiell zu sein:

Bridges
Linux und/oder unter Linux laufende Virtualisierungsumgebungen erlauben die Definition und Erstellung virtueller (Multiport)-Bridges. Solche Bridges können auf einem Linux-Host auch außerhalb und unabhängig vom libvirt- oder KVM/qemu-System kreiert werden. Eine virtuelle Multiport-Bridge unter Linux entspricht dabei in der üblichen Standardkonfiguration recht gut einem virtuellen Switch (vSwitch). Moderne Virtualisierungsumgebungen wie KVM/qemu erzeugen optimierte vBridges/vSwitches, die eng mit dem Kernel verzahnt sind

Virtuelle Netze
Ein virtueller Switch (z.B. ein "virbr0" unter KVM/qemu) realisiert in Kombination mit einem lokalen DHCP-Dienst die Grundlage für ein entsprechendes "virtuelles Netzwerk" ("vLAN"; hier nicht im Sinne von 802.Q1 verwendet). Ein solches virtuelles Netzwerk

  • kann auf dem Linux-Host ganz unabhängig vom physikalischen Netz existieren,
  • kann einen eigenen, für die angeschlossenen (virtuellen) Systeme gültigen IP-Adressbereich abdecken,
  • kann für den Host selbst über eine (ggf. spezielle) virtuelle Netzwerk-Schnittstelle zugänglich gemacht werden,
  • kann über verschiedene Methoden mit den physikalischen Netzen der Host-Umgebung verbunden oder von ihnen isoliert werden.

Es gibt somit unterschiedliche Varianten der Anbindung an oder der Isolierung virtueller Switches und ihrer zugehörigen virtuellen LANs vom Gastsystem und physikalischen Netzen.

Virtuelle Netzwerkdevices (vNICs)
Man kann einer (virtuellen) Linux-Bridge (bzw. einem virtuellen Switch)

  • rein virtuelle Netzwerk-Devices (vNics) von vitualisierten Gastsystemen,
  • ein virtuelles Netzwerk-Interface des Hosts selbst ("tap"-Device)
  • oder in speziellen Konfigurationen auch ein physikalisches Netzwerk-Interface (pNICs)

zuordnen. Virtuelle NICs für Gastsysteme und für den Virtualisierungs-Host werden über die jeweilige Virtualisierungsumgebung (z.B. KVM/qemu in optimierter Form) oder aber aber auch durch elementare Systemkommandos (wie etwa "tunctl") bereitgestellt.

Die Bereitstellung virtualisierter vNICs ("tap"-devices) für den Host selbst dient dazu, die Kommunikation des Hosts mit virtuellen Switches und den daran angeschlossenen virtualisierten Systemen zu ermöglichen. So können z.B. Gastsysteme, die hinter einer KVM/qemu-Bridge "virbr0" liegen, vom Host aus über ein artifizielles Device "virbr0-nic", das an einen Port der Bridge angeschlossen ist, angesprochen werden. Die Erstellung eines solchen vNICs für den Host muss aber (je nach Virtualisierungsumgebung) über spezielle Kommandos herbeigeführt werden.

Unterschiedliche Isolierungsgrade und virtuelle Netzwerk-Modelle
Virtuelle Netze und angeschlossene Gäste können je nach Zuordnung von vNICs und pNICS einen unterschiedlichen Grad der Isolierung gegenüber anderen virtuellen Netzen auf demselben Host, gegenüber dem Host selbst und seinen physikalischen Devices bzw. physikalischen Netzen einnehmen. Je nach Auslegung des virtuellen Netzes spricht man auch von unterschiedlichen vLAN-Modellen oder vLAN-Varianten.

Anbindung virtueller Netze an physikalische Netze
Methoden zur Anbindung virtueller Netze eines Hosts an physikalische Netze sind u.a.:

  • das Routing zwischen virtuellen und physikalischen NICs auf dem Host,
  • das sog. "direkte Bridging" virtueller Devices von virtualisierten Gastsystemen zu und mit physikalischen Devices des Hosts,
  • die Bereitstellung besonderer virtueller Devices wie "macvtap" (zum direkten Teilen der Ressourcen eines physikalischen Netzwerk-Devices).

Virtuelle Devices von Virtualisierungsgästen werden im Falle der letzten beiden Verfahren direkt im physikalischen Netzsegment adressier- und ansprechbar und teilen sich Ressourcen mit einem vorhandenen physikalischen Interface (wie etwa eth0 oder enp8s0 unter Opensuse).

Im Falle des erstgenannten Verfahrens leitet der Host dagegen Netzwerkpakete, die von virtuellen Systemen und einem vSwitch-Port einer vBridge kommen, über sein eigenes virtuelles vNIC als Router/Gateway zu physikalischen pNICs und physikalischen Netzwerken weiter.

Hinzu kommen weitere Spezialverfahren, die z.T. die Definition besonderer virtueller Netzwerk-Devices erfordern.

Routing
Natürlich kann der Host Netzwerkpakete eines Virtualisierungsgastes vG1, der etwa in einem vLAN hinter einer vBridge "virbr0" lokalisiert sein mag, prinzipiell auch zu einem Gast vGx in einem anderen vLAN hinter einer vBridge "virbrx" weiterleiten, wenn er denn (virtuelle) Interfaces zu beiden vBridges besitzt. Natürlich müssen aber entsprechende Routing-Regeln definiert sein und durch paktefilter/Firewalls auch zugelassen werden.

Virtuelle Devices des Hosts (sog. "tap"-Devices), die in virtuelle Switches integriert werden, können einem Routing des Hosts unterworfen werden, müssen es aber nicht. Beispielsweise kann man Routing zwischen virtuellen LANs erlauben, Routing über physikalische Devices nach außen aber unterbinden. Entsprechende Route-Definitionen sind einerseits in die Routing-Tabellen des Hosts aufzunehmen und durch Skripts permanent zu machen, andererseits aber auch in den Paketfilter/Firewall-Einstellungen zu berücksichtigen. Paketfilter-Einstellungen (z.B. über netfilter-iptables/ebtables) können allgemeinere Routing-Regeln des Hosts dabei feingranularer eingrenzen oder bei Bedarf gänzlich aufheben.

"Direktes Bridging" zu einem physikalischen Device des Hosts
Eine besondere Variante des Bridgings ist das weiter oben bereits erwähnte "direkte Bridgen" virtueller Devices von virtualisierten Gastsystemen zu und mit einem physikalischen Device des Hosts. Die virtuellen Devices teilen sich dann das physikalische Device mit dem Host und erscheinen bei entsprechender IP-Adress-Zuordnung direkt im physikalischen Netz.
In manchen Artikeln wird eine entsprechende Bridge auch als eine "Public Bridge" bezeichnet. Leider sprechen einige Internet-Artikel salopp von "Bridging", wenn sie eigentlich diese spezielle Variante des Aufbaues einer virtuellen Bridge meinen; andere Artikel beziehen "Bridging" dagegegen auf das generelle Verfahren der Erstellung einer virtuellen Bridge als Basis eines virtuellen Netzwerkes. Der Leser muss sich die richtige Interpretation manchmal etwas mühsam aus dem Kontext des Artikels herleiten.

Virtualisierungs-Toolsets
Virtualisierungstools wie "libvirt/virt-manager" unterstützen nicht nur die Erstellung von Gastsystemen unter verschiedenen Virtualisierungsumgebungen (genauer Hypervisoren wie etwa "KVM/qemu"), sondern auch die Erstellung von (optimierten) virtuellen Bridges, von zugehörigen (optimierten) virtuellen Gast- und Host-Netzwerk-Devices (vNICs), DHCP-Diensten und damit insgesamt von virtuellen Netzen.

Paketfilterung und Firewalling ist auf verschiedenen Ebenen erforderlich
Virtuelle Devices des Host wie auch der virtualisierten Gastsysteme (!) können/müssen ebenso in iptables/ebtables-Regeln einer "netfilter"-basierten Firewall ebenso eingebunden werden wie die vorhandenen physikalischen Devices des Hosts auch. Es kommen u.U. aber spezielle Definitionen und Regeln zum Einsatz. Der Netfilter/iptables-Interpreter des Kernels "versteht" dabei u.a. auch spezielle Anweisungen zur Steuerung (direkt) gebridgter virtueller Devices hinter einem virtuellen Switch, die Signale über das virtuelle Host-Device in die Host-Umgebung senden oder aus dieser empfangen. Ein Präzisierung der iptables/ebtables-Regeln bzgl. der Weiterleitung der Signale von und zu direkt gebridgten Gast-Devices über die jeweilige virtuelle Bridge des Hostes Bridge ist in vielen Fällen dennoch unumgänglich (s. auch den folgenden Punkt). Besonders zu beachten ist, dass KVM/qemu - je nach Konfiguration - initial eigene Default-iptables/ebtables-Regeln etabliert. Diese werden bei Aktivierung eigener Firewall-Systeme durch andere Tools aber u.U. überschrieben. Eine Untersuchung und ein manueller Ausgleich sind oft erforderlich.

Sicherheitsrisiken bei (mehreren) direkten Bridges zu physikalischen Devices
Die "iptables"-Komponente von "netfilter" kümmert sich lediglich um den Pakettransport auf den Ebenen 3/4 des TCP-IP-Protokolls. "iptables" beachtet jedoch nicht den Level 2 (Ethernet, MAC-Adressen) des OSI- oder TCP/IP-Schichtenmodells. Virtuelle Switches können aber durch dieselben Angriffsmuster manipuliert werden, wie reale Switches. ARP Spoofing und ARP-Flooding sind hier zwei Stichworte. Angreifer können mit diesen Methoden die eindeutige Zuordnung von IP-Adressen zu MAC-Adressen bzw. von MAC-Adressen zu Switch-Ports aushebeln. Dadurch ist die Isolierung von Gastsystemen gegeneinander u.U. gefährdet und kann durchbrochen werden.

Sichere Konfigurationen erfordern deshalb neben dem Einsatz von iptables-Regeln auch noch zwingend den Einsatz von ebtables-Regelsätzen. Dies gilt im Besonderen auf Hosts mit direktem Bridging und ggf. mehreren "direkten Bridges" sowie aktiviertem "conntrack" in den iptables-Regeln. Eine saubere Trennung der ankommenden Pakete nach dem Ursprung, der die Verbindung initiierenden Adresse ist u.U. nicht mehr möglich, wenn Angreifer im gleichen LAN-Segment legale und illegale Pakete an dasselbe Target senden.
U.u. können selbst mehrere "direkte Bridges" auf ein und demselben Virtualisierungshost ohne ebtables-Regeln nicht zuverlässig gegeneinander abgeschottet werden. Bestimmte Angriffsverfahren, die virtuelle Bridges/Switches in einen "HUB Modus" zwingen, führen zur Möglichkeit des Mitlesens von Traffic durch einen Gast auf einer anderen Bridge als der, der der Gast zugeordnet ist. "Direkte virtuelle Bridges" sind auf produktiven Hosting-Systemen daher durchaus als potentiell problematisch einzustufen.

Ich hoffe, dem Leser mit diesen Statements ein paar Leitplanken zum besseren Einstieg in die Artikel hinter den nachfolgenden Links gegeben zu haben. Während die grundlegende Einrichtung geeigneter virtueller Bridges/Switches mit dem Gespann "libvirt/virt-manager" sehr schnell und sehr bequem gelingt, erfordern die zuletzt angesprochenen iptables/ebtables-Themen doch eine intensive Beschäftigung mit grundlegenden Netzwerk-Techniken und -Protokollen, netfilter-Regeln und dem ARP-Protokoll. Gerade dieses Feld ist aber ein Eldorado für Pen-Test-Übungen.

Ein paar grundlegende Definitionen zu (virtuellen) Bridges

Es schadet nicht, zu Beginn einer Einarbeitung in virtuelle Netze ein paar grundlegende Dinge zu Bridges/Switches und deren "Abgrenzung" zu rekapitulieren:

 
Wichtig ist zu verstehen, dass ein Switch im Kern einer Multiport-Bridge entspricht.
Es sollte nach der Lektüre der obigen Artikel klar sein, dass auch die Definition virtueller Netzwerke, die im Endeffekt über (virtuelle) Switches gesteuert werden, die Darstellung von virtuellen Multiport-Bridges und zugehöriger Regeln über den Kernel bzw. über vermittelnde und optimierende Virtualisierungs-SW erfordern wird.

Aufsetzen von Bridges unter Linux

An dieser Stelle ist es dann sinnvoll nachzulesen, wie man unter Linux (und spezifischen Linux-Distributionen) ganz allgemein virtuelle Bridges einrichten kann:

 
Ich empfehle hier dringend, sich mit dem Schlüsselkommando "brctl" und seinen Subkommandos auseinanderzusetzen (s. http://linux.die.net/man/8/brctl). Um eine Übersicht über angelegte Bridges/Switches und zugeordnete Interface auf einem Host zu erhalten, nutzt man "brctl show". Dieses Kommando zeigt auch vBridges, zugehörige aktive Host- und Gastinterfaces an, die z.B. direkt mit Hilfe von KVM/qemu oder VMware und nicht manuell mit "brctl" erzeugt wurden.

Erwähnt sei an dieser Stelle auch, dass man ein HUB-ähnliches Verhalten der Bridge erzwingen kann:
http://www.linuxquestions.org/questions/linux-networking-3/can-a-bridge-be-configured-to-act-as-hub-not-a-switch-817170/
http://adamdoupe.com/blog/2010/10/22/configuring-linux-bridge-to-act-as-a-hub/
Dies its für Experimente nützlich zu wissen; ein solches HUB-Verhalten ist aber auf Virtualisierungshosts, auf denen Gäste und ihr Netzwerkverkehr gegeneinander abgeschirmt werden sollen, natürlich zu vermeiden.

libvirt/virt-manager als Interfaces und Tools für die Verwaltung virtueller Netzwerke (verschiedener Hypervisoren)

Der nächste Schritt besteht darin, sich darüber zu informieren, wie man unter Linux die Einrichtung ganzer virtueller Netzwerke auf (relativ) bequeme Weise steuern kann. Man wird zu recht vermuten, dass die Definition virtueller Bridges durch die Bereitstellung von Netzwerk-Schnittstellen für virtuelle Gastsysteme des eingesetzten Hypervisors und auch für den Host ergänzt werden muss. Hinzu kommen Basisdienste wie DHCP für das virtuelle Netzwerk. Das Gespann "libvirt/virt-manager" sind für diese Aufgaben unter Linux die erste Adresse. Das libvirt-Toolset unterstützt mehrere Hypervisoren. Eine "KVM/qemu"-basierte Virtualisierungsumgebung wird dabei zuverlässig unterstützt.

virt-manager liefert ein grafisches Interface zu libvirt, mit dem sich Gastsysteme und Netzwerke (relativ) bequem einrichten lassen. Die Gäste können zudem auf einer elementaren Ebene überwacht, an/ab-geschaltet oder "suspended" werden.

Einführung in libvirt:
https://de.wikipedia.org/wiki/Libvirt
http://libvirt.org/
Eine Übersicht über die Hypervisoren, die libvirt unterstützt, ist hier zu finden:
https://libvirt.org/drivers.html

Das erfolgreiche Nutzen von libvirt erfordert das Starten eines Daemons - libvirtd. Ein entsprechender "libvirtd.service" ist auf aktuellen Distributionen in die Target/Unit-Startreihenfolge von "systemd" zu integrieren. Zumindest bei Opensuse 13.2 geschieht dies mit der Installation der Virtualisierungsumgebung unter
"YaST2 >> Virtualisierung >> Install Hypervisor and Tools"
automatisch.

Graphischer Aufsatz "virt-manager" für KVM/qemu, Xen und LXC:

 

"virt-manager" unterstützt neben der Einrichtung von Gästen vor allem auch die Möglichkeit, komplette virtuelle Netze zu konfigurieren. Hierzu befasse man sich in einem gestarteten "virt-manager"-Fenster mit den Optionen, die man unter dem Menüpunkt
Edit >> Connection Details >> "Virtual Networks"
findet.

Ein weiterer wichtiger Punkt ist, dass "virt-manager" Konfigurationsdateien im XML-Format anlegt. Dies wiederum nutzen weitere libvirt-Programme zur Umsetzung der Virtualisierungsvorgaben über elementare Kommandostrukturen, die an den jeweiligen Hypervisor und seine Kernelintegration angepasst sind. Die XML-Konfigurationsdateien für Gastsysteme bzw. virtuelle Netze sind für KVM/qemu-Umgebungen (meist) in den Verzeichnissen
"/etc/libvirt", "/etc/libvirt/qemu/" bzw. "/etc/libvirt/qemu/networks"
zu finden.

Neben "virt-manager" gibt es auch CLI-Interface zu libvirt namens "virsh". Wir kommen weiter unten darauf zurück. Zunächst will ich aber ein paar Links zu einem Hauptthema für die Einarbeitung - nämlich unterschiedlichen virtuellen Netzwerk-Varianten - angeben.

Grundlegende Varianten virtueller Switches und deren Anbindung an physikalische Netze unter libvirt - Schlüsselartikel zur Übersicht

Bei der Auseinandersetzung mit Tools und ihren Möglichkeiten gerät man in Gefahr, vor lauter Bäumen den Wald nicht mehr zu sehen. Bei der Planung virtueller Netze ist es aber vor allem wichtig, sich mit den verfügbaren Varianten für die eigenen Einsatzzwecke auseinanderzusetzen. Dies gilt im besonderen für den Aufbau von Pen-Test-Umgebungen.

Der folgende Schlüssel-Artikel aus dem "libvirt WIKI" fokussiert auf verschiedene grundlegende virtuelle Netzwerkkonfigurationen und die Anbindung zugehörige virtuelle Switches an die physikalische Hostumgebung und physikalische Netze:

http://wiki.libvirt.org/page/VirtualNetworking

Weitere Strukturdiagramme zur Positionierung der virtuellen LANs findet man hier
http://www.libvirt.org/archnetwork.html

Zu unterscheiden ist zwischen Konfigurationen, bei denen die Gastsysteme offiziell registrierte IP-Adressen erhalten und solchen, bei denen private Adressen verwendet werden.

In gerouteten Varianten über ein oder mehrere physikalische Interfaces des Hostes nach außen wird oft ein virtuelles (!) Device des Hosts, das wiederum mit einem virtuellen Switch verbunden ist, in geeignete Routing-Definitionen des Hostes eingebunden - mit und ohne NAT. Das ermöglicht Konfigurationen, bei denen die virtuellen Gäste hinter dem virtuellen Switch Zugriff auf das Internet oder aber andere virtuelle Netzwerke des Hostes erlangen können. Durch NAT-Einsatz kann dabei der direkte Zugriff von außen auf einen spezifischen Gast unterbunden werden. Es ist zu beachten, dass NAT auf IP-Ebene iptables-Regeln erfordert. Will man NAT auf MAC-Ebene realisieren, so ist der Einsatz von ebtables notwendig.

Für den Spezialfall einer direkten Bridge zu einem physikalischen Device findet man eine anschauliche Erläuterung grundlegender Prinzipien in folgenden zusammenhängenden Artikeln :
http://www.innervoice.in/blogs/2013/12/02/linux-bridge-virtual-networking/
http://www.innervoice.in/blogs/2013/12/08/tap-interfaces-linux-bridge/
Man beachte, dass der Autor nur den genannten Spezialfall genauer beschreibt. Einige der Aussagen gelten jedoch generell, und ich finde die Skizze im zweiten Artikel sehr instruktiv.

XML-Konfigurationsdateien für virtuelle Netzwerke unter libvirt/virt-manager

Die Konfiguration von virtuellen Netzwerken in Form von XML-Dateien, die für KVM/qemu dann unter "/etc/libvirt/qemu/networks" abgelegt werden, ist unter folgendem Link genauer behandelt:
https://libvirt.org/formatnetwork.html
libvirt nutzt diese Dateien zur Umsetzung der Netzwerk-Konfiguration; virt-manager bietet, wie gesagt, nur ein grafisches Interface zur Erzeugung dieser Dateien.

Es lohnt sich, den genannten Artikel in Gänze durchzulesen:
Durch die beschriebenen Konfigurationsoptionen werden nämlich die unterschiedlichen virtuellen Netzwerk-Varianten noch einmal verdeutlicht (siehe speziell die Optionen zum Konfigurationsparameter "forward"). Der Leser wird feststellen, dass es neben dem direkten Bridging noch weitere Möglichkeiten gibt, eine Kopplung von virtuellen Netzen an physikalische Host-Devices vorzunehmen - z.B. über mcvtap-Devices. Solche Netze erfordern jedoch Zusatzmaßnahmen, um den Host direkt mit Gästen hinter der Bridge kommunizieren zu lassen. Als Einsteiger würde ich mich deshalb zunächst mit normalem direkten Bridging vertraut machen, bevor man mit mcvtap-Konfigurationen experimentiert. Links zu diesem Spezialthema folgen weiter unten. Der Einsatz von mcvtaps kann aber aus Performance-Gründen interessant sein.

"virsh"-Komponente von libvirt für die Kommandozeile

libvirt kann statt über "virt-manager" auch über die Kommandozeile instruiert werden. Dabei kommt der CLI-Kommandointerpreter "virsh" zum Einsatz. Zur Konfiguration von virtuellen Netzwerken über den "virsh"-CLI-Interpreter siehe:

 

Zwischenstand und Wiederholung

Es sollte nach der bisherigen Lektüre klargeworden sein, dass den virtuellen Netzwerken Multiport-Bridge-Definitionen für den jeweiligen Hypervisor zugrunde liegen. (Die Bridge-Definitionen erfolgen dabei entweder über Linux "brctl"-Kommandos (s.u.) oder "ip"-Kommandos (iproute2) bzw. direkte Kommandos der Virtualisierungsumgebung für optimierte "vbridges" an den Kernel). Einer (Multiport-) "Bridge" können dann virtuelle und ggf. auch physikalische Devices zugeordnet werden. Die Konfiguration von kernel-optimierten "vBridges" und "vNICs" unter KVM/qemu ist am einfachsten mit "virt-manager" möglich.

Auf einer anschaulichen Ebene kann man sich vorstellen, dass virtuelle Netze über einen virtuellen Switch realisiert werden, der die Kommunikation zwischen mehreren Ports steuert.

Die Repräsentanz des virtuellen Netzes im Host kann über ein spezielles sog. "tap0"-Device gewährleistet werden, das eine virtuelle NIC im Host erzeugt, die wie physikalische NICs auch in iptables/ebtables-Regeln eingebunden werden kann. Diese Device "hängt" dann auch am virtuellen Switch und ermöglicht die Kommunikation des Hosts mit dem virtuellen Gästen hinter dem virtuellen Switch. Zur Einführung in Tap-Devices siehe
https://de.wikipedia.org/wiki/TUN/TAP
http://backreference.org/2010/03/26/tuntap-interface-tutorial/

Es wurde durch die Lektüre zudem deutlich, dass zwischen "direkten Bridges" zu physikalischen NIC-Devices und rein virtuellen Bridges zu unterscheiden ist. Die Repräsentanz einer rein virtuellen Brigde (bzw. Switches) im Host kann - wie gesagt - über ein spezielles tap-Device erfolgen, das zusätzlich zu erstellen ist. Unter dem aktuellen "libvirt/virt-manager"-Gespann ist dies meist eine zu wählende Option beim Einrichten der virtuellen Netze.

Beachte: Bei direktem Bridging erhält die Bridge selbst die IP-Adresse und nicht das physikalische Device (s.u.).

Also: Einer aufgesetzten Bridge (werden dann je nach Isolierungsgrad

  • situationsgerechte virtuelle Devices der Gäste der jeweiligen Virtualisierungsumgebung zugeordnet,
  • spezielle virtuelle Devices, die das virtuelle Netz für den Host zugänglich machen (mit oder ohne Routing auf dem Host) zugeordnet
  • oder aber in bestimmten Fällen des direkten Bridgings zur physikalischen Netzwerkumgebung eben auch physikalische Devices zugeordnet (wobei das physikalische Device dann keine IP erhält, sondern die Bridge (z.B. br0)). Die virtuellen NIC-Devices erscheinen dabei direkt im physikalischen Netzbereich des Hosts.

Virtuelle Netzwerkinterfaces (verschiedener Hypervisoren wie von Spezialfällen) für die Gäste und den Host, die an verschiedene Bridge/Switch-Typen angebunden werden können, werden hier behandelt:
http://qemu-buch.de/de/index.php?title=QEMU-KVM-Buch/_Netzwerkoptionen/_Virtuelle_Netzwerke_konfigurierenhttp://libvirt.org/formatdomain.html#elementsNICS

Performance-Optimierung
Nutzt man "virt-manager" werden einem je nach gewähltem Netzwerk-Typ unterschiedliche Modelle für virtuelle NICs beim Einrichten der Gäste bzw. auch beim Einrichten des Host-Tap-Interfaces angeboten. Man sollte durchaus mit verschiedenen Modellen experimentieren und die Performance testen. Unter Opensuse 13.1/13.2 habe ich durchweg gute Erfahrungen mit "virtio"-Treibern gemacht.

Hochfahren des Netzes und der virtuellen Gastdevices

Das Hochfahren von Netzwerk-Bridges und das Anlegen zugehöriger virtueller Host-Devices (z.B. virbr0) erfolgt unter aktuellen Distributionen meist über den "Autostart"-Mechanismus von "libvirt". Man werfe bzgl. der automatisch zu startenden virtuellen Netzwerke einen Blick in das Verzeichnis
"/etc/libvirt/qemu/networks/autostart".

So zeigt in einem Beispiel ein Opensuse-Host, für den mittels "virt-manager"
eine Bridge "br0" unter Einbindung des physikalische Devices
und eine rein virtuelle Bridge mit angeschlossenem Host-Device
definiert wurden, etwa folgendes nach dem Systemstart (inkl. libvirtd.service):

mytux:~ # brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.aabbccddee11       no              enp8s0
virbr0          8000.ccddee112233       yes             virbr0-nic
mytux:~ # ifconfig
br0       Link encap:Ethernet  HWaddr AA:BB:CC:DD:EE:11  
          inet addr:192.168.12.1  Bcast:192.168.12.255  Mask:255.255.255.0
	  ...
enp8s0    Link encap:Ethernet  HWaddr BB:CC:DD:EE:11:AA  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
	  ....	
virbr0    Link encap:Ethernet  HWaddr CC:DD:EE:11:22:33  
          inet addr:192.168.200.1  Bcast:192.168.200.255  Mask:255.255.255.0
	  ....

 
Welche Gastsysteme übrigens beim Systemstart des Hosts automatisch hochgefahren werden sollen, kann man ebenfalls über "virt-manager" festlegen. Das Ganze ist offenbar in den Start des "libvirtd.service" integriert. Siehe unter:
"/etc/libvirt/qemu/autostart".

Unter "libvirt" und "KVM/qemu" gilt: Die vNICs von virtuellen Gastsystemen werden erst beim Starten und Einrichten dieser Gastsysteme erzeugt und an die Bridge angebunden. Die virtuellen vNIC-Devices der Gastsysteme sind vorher nicht existent, werden danach aber unter ifconfig und "brctl show" sichtbar!

mytux:~ # brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.aabbccddee11       no              enp8s0
                                                        vnet0
virbr0          8000.ccddee112233       yes             virbr0-nic
                                                        vnet1

 
Die erstellten virtuellen Ethernet-Devices werden unter KVM/qemu mit einem Treibermodell (z.B. virtio) unterlegt und in die startende virtuelle Maschine integriert. Gesteuert wird der gesamte Prozess über entsprechende Start-Kommandos für die virtuellen Maschinen. libvirt/virt-manager überdecken diesen Aufwand netterweise. KVM arbeitet dabei eng mit dem Kernel zusammen.

Manuell könnte man auf Betriebssystem-Ebene einen ähnlichen Vorgang etwa dadurch vollziehen, indem man durch Anwendung des "tunctl"-Befehles (erfordert unter Opensuse die Installation des entsprechenden Paketes!) virtuelle tap-Devices erzeugt, diese einem anschließenden "brctl addif" an die Bridge anbindet und dann dieses Device in einem qemu-Start-Befehl für einen virtuellen Gast benutzt. Das funktioniert auch - nur hat man hierbei keinerlei Optimierungsmöglichkeiten.

Es ist aus meiner Sicht grundsätzlich besser, sich auf die für den Kernel optimierten Devices zu verlassen, die man über die Virtualisierungsumgebung (KVM/qemu) und "virt-manager" als Frontend erzeugt.

Einschub: Pfad der Konfigurationsdateien unter Opensuse

Unter Opensuse findet man die Vorgaben und Startup-Skripts für Bridges (wie br0 etc.) zu physikalischen NIC-Devices unter

/etc/sysconfig/network.

Eine br0-Bridge wird von Opensuse 13.1/13.2 beim Einrichten des Systems als Virtualisierungshost über YaST meist bereits automatisch eingerichtet. Auf diese per "brctl" generierte Bridge kann dann unter "virt-manger" Bezug genommen werden. Dies ist sinnvoll etwa beim Einrichten von Gastsystemen mit einem direkt zum physikalischen Device gebridtem vNIC.

Libvirt bezogene Bridge- und Netzwerk-Definitionen - also solche, bei denen die vBridge direkt über die Virtualisierungsumgebung erzeugt wird - sind unter

/etc/libvirt/

bzw. unter

/etc/libvirt/qemu/networks

zu finden.

Umsetzung virtueller Netze unter "KVM/qemu"

In den Links zu libvirt/virt-manager wurde noch nicht gezeigt, auf was sich "libvirt/virt-manager" bei der Generierung von Netzwerken und zugeordneten virtuellen NICs letztlich stützen. Zudem sollte man sich darüber im klaren sein, dass man über ein wenig Skripting einen "KVM/qemu"-Hypervisor auch direkt ansteuern kann.

KVM ist ein Hypervisor zur Vollvirtualisierung, der als Linux Kernelmodul operiert. Er ist eng mit qemu verzahnt - und stellt eine optimierte Integration der Virtualisierungsumgebung in den Kernel dar. Zu qemu und KVM wird eine erste Einführung hier gegeben:
http://serverfault.com/questions/208693/difference-between-kvm-and-qemu
http://www.innervoice.in/blogs/2014/03/10/kvm-and-qemu/
http://www.linux-kvm.org/page/Main_Page

Umfangreicher Artikel zur elementaren Konfiguration von qemu-Systemen:
http://qemu-buch.de/de/index.php?title=QEMU-KVM-Buch/_Netzwerkoptionen/_Virtuelle_Netzwerke_konfigurieren

Networking unter KVM/qemu:
http://www.linux-kvm.org/page/Networking
http://wiki.qemu.org/Documentation/Networking
https://en.wikibooks.org/wiki/QEMU/Networking
http://wiki.qemu.org/Documentation/Networking
https://people.gnome.org/~markmc/qemu-networking.html

Interessant und anregend ist auch ein Studium der praktischen Beispiele, die etwa das Unternehmen Hetzner für seine gehosteten Server-Plattformen diskutiert:
http://wiki.hetzner.de/index.php/Kategorie:KVM

Zur Klärung, wie ein qemu-vLan begrifflich zu verstehen ist, siehe:
http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatbptap.htm

SLES- und Opensuse-spezifische Informationen zu KVM/qemu gibt es hier:
https://www.suse.com/documentation/sles-12/singlehtml/book_virt/book_virt.html
https://www.suse.com/documentation/sles-12/singlehtml/book_virt/book_virt.html#cha.qemu.running.networking
https://www.suse.com/documentation/sles11/book_kvm/data/book_kvm.html
https://www.suse.com/documentation/sles11/book_kvm/data/cha_qemu_running_networking.html
https://activedoc.opensuse.org/book/opensuse-virtualization-with-kvm/chapter-12-running-virtual-machines-with-qemu-kvm
https://activedoc.opensuse.org/book/opensuse-virtualization-with-kvm
https://www.howtoforge.com/virtualization-with-kvm-on-an-opensuse-12.1-server
http://www.vorkon.de/SU1210.001/drittanbieter/Dokumentation/openSUSE_11.4/manual/book.kvm.html

Für Debian-spezifische Informationen s. hier:

 
Ubuntu-spezifische Informationen finden sich hier:
https://help.ubuntu.com/community/KVMFeisty

NAT-Variante der Anbindung eines virtuellen Netzes an die physikalische Umgebung

Die NAT-Anbindung virtueller Netze an physikalische Netze wird hier diskutiert:
http://wiki.qemu.org/Documentation/Networking/NAT

Verschiedene virtuelle Netzwerk-Varianten für Debian-basierte Host-Systeme über die dortige iface-Konfiguration

Debian sammelt die Konfigurationsvorgaben zu Netzwerken und Netzwerk-Devices in einer "iface"-Datei. Siehe zu diesem Thema:

Beispiele für direktes Bridging mit physikalischem Host-Device

http://blog.elastocloud.org/2015/07/qemukvm-bridged-network-with-tap.html
http://www.oneunified.net/blog/Virtualization/BridgeTap.article
http://www.dedoimedo.com/computers/kvm-bridged.html
http://hzqtc.github.io/2012/02/kvm-network-bridging.html

Windows-Gastsystem mit direktem Bridging
Artikel für praktische Beispiele mit einem Windows Guest für ein Bridging mit dem physikalischen Host-Device unter Debian-nahen Systemen sind folgende:
http://resources.infosecinstitute.com/qemu-windows-guest-bridged-networking/
http://resources.infosecinstitute.com/qemu-windows-guest-networking/

Alternative zum Direct Bridging: Netzwerk mit mcvtap/vepa devices

Leute, die Alternativen zum direkten Bridging suchen, weil sie evtl. Probleme mit der Performance bekommen, werden etvl. mit macvtyp-Devices glücklicher. Hier ein paar Artikel-Links dazu:
http://virt.kernelnewbies.org/MacVTap
https://libvirt.org/formatnetwork.html#elementsConnect
https://libvirt.org/formatnetwork.html#examplesDirect
https://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
https://wiki.math.cmu.edu/iki/wiki/tips/20140303-kvm-macvtap.html

Netfilter, Firewalling und libvirt

Ich setze hier voraus, dass der Anwender von virtuellen Netzen bereit ist, sich in "netfilter" und seine iptables/ebtables-Komponenten selbst einzuarbeiten. Ich gebe hierzu nur wenige Literaturhinweise an:
https://people.redhat.com/fcaviggi/Firewalls.pdf
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html
https://wiki.archlinux.org/index.php/Iptables
https://wiki.archlinux.org/index.php/Simple_stateful_firewall

http://ebtables.netfilter.org/examples/basic.html
https://laddumishra.wordpress.com/2012/01/19/mac-filtering-and-bridging-firewalls-in-linuxubuntu/

Grundsätzlich möchte ich Paket-Filterung über eigene iptables/ebtables-Regeln und zugehörige Skripte abgrenzen von den elementaren Möglichkeiten, die "libvirt" bietet. Mein persönlicher Rat ist, sich mit den Möglichkeiten von libvirt zwar auseinanderzusetzen, um Kenntnisse über bestimmte, dort realisierte Standardfilter als Lehrbeispiele zu erlangen. Sobald man die aber nachvollzogen hat, empfiehlt es sich aus meiner Sicht, diese Regeln in eigene Skripte überzuführen. Gerade beim Aufsetzen von Pen-Testing-Übungsumgebungen hat man dadurch eine wesentlich bessere Kontrolle über das System-Setup. Und was da gilt, kann für Hosting-Umgebungen nicht so falsch sein ...

Libvirt bringt bereits eigene elementarste Regeln mit, die je nach Konfiguration der virtuellen Netze bei deren Erstellung mit erzeugt werden. Man überprüfe das mit "iptables -L".

Wichtig ist zu verstehen, dass diese elementaren Definitionen durch andere Firewall-Tools auf dem eigenen Host abgeschaltet, gelöscht oder überschrieben werden können - auch versehentlich. Auf aktuellen Distributionen ist daher unbedingt die Startreihenfolge von iptables-Tools und die resultierenden Auswirkungen auf physikalische wie virtuelle Netze zu beachten! Für Opensuse-Freunde sind etwa folgende Hinweise angebracht:

Hinweise zur Susefirewall2:
So löscht etwa ein Starten der Susefirewall2 unter Opensuse 13.2/13.1 alle der bei einem vorhergehenden Start des "libvirtd.service" angelegten Regeln. Man beachte auch, dass die Susefirewall2 beim Abschalten Routing auf dem Host automatisch deaktiviert! (Auf diese von Opensuse zur Sicherheit implementiertes Vorgehen, bin ich beim schnellen Aufsetzen von Pentest-Umgebungen schon mehrfach hereingefallen.)

Fakt ist auch, dass die wenigen elementaren Default-Regeln von livirtd das Host-System mit seinen virtualisierten Netzen gegenüber bestimmten Angriffen relativ offen lassen.

Eine erste detailliertere Diskussion von iptables-Regeln für einfache virtuelle Netzwerkkonfigurationen erfolgt hier:
https://libvirt.org/firewall.html

Dieser Artikel zeigt in seiner Mitte auch, dass es einen ganzen Satz komplexerer, vordefinierter Firewall-Regelsätze gibt, die man einerseits in Netzwerk-Definitionen unter libvirt, ggf. aber auch in eigene iptables/ebtables-Scripts einbeziehen kann. Für letzteres ist ein kleiner Umweg nötig:

Bitte beachtet, dass der Zugriff auf die vordefinierten Regeln unter Opensuse die Installation diverser zusätzlicher (!) Pakete in Ergänzung der Pakete libvirt-daemon, libvirt-client, virt-manager, virt-manager-common erfordert. Am einfachsten ist es jedoch, das Paket "libvirt" zu installieren. Danach "systemctl restart libvirtd.service" und schon funktioniert

mytux:~ # virsh
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # nwfilter-list
 UUID                                  Name                 
------------------------------------------------------------------
 01c82440-808d-4def-a22f-21848d896cbd  allow-arp           
 154492fb-3198-4de3-8e0c-b0ccbb8f9abc  allow-dhcp          
 60c01c9a-4039-49d9-8ed8-ca55090a6e1a  allow-dhcp-server   
 919ec06f-76bc-4c14-b0dd-5f7cc914edae  allow-incoming-ipv4 
 b3408089-22cf-4b5d-82fa-82769f43a2ed  allow-ipv4          
 c85622ce-1acb-4627-ba5d-cc93476dd5d7  clean-traffic       
 c7865ee0-8dd3-4d2c-98a1-1b3a811322df  no-arp-ip-spoofing  
 81f384b6-5576-4762-a708-33b218868ac6  no-arp-mac-spoofing 
 11fe3e29-2947-45a4-863e-b1e52b923ab2  no-arp-spoofing     
 07123a0e-6b8b-4883-9ef3-49ab88f6cfe2  no-ip-multicast     
 66c36165-89b6-461a-9427-1451b61f697f  no-ip-spoofing      
 ee3e292b-c795-4602-9cd4-3117bbdf36e1  no-mac-broadcast    
 144dd5af-449e-46dd-b9e8-f009d692ce35  no-mac-spoofing     
 ad6e6769-1c8e-40aa-9109-722144841c72  no-other-l2-traffic 
 cfde67c1-aafa-4a0f-8099-34ceb9469197  no-other-rarp-traffic
 18ada8c3-a132-4f89-9999-476f0fa2309e  qemu-announce-self  
 b45e1a74-e5b4-4af1-bd91-1d14bb65f9d8  qemu-announce-self-rarp

virsh # 

 
Die zugehörigen XML-Dateien findet man unter "etc/libvirt/nwfilter".

Um die Sache je nach Blickwinkel noch komplizierter zu machen, erlaubt libvirt das Einbinden dieser Filter und eigener Regel-Sätze in XML-Form in die XML-Konfigurationsdateien zu Netzen/Gästen. Das wird im Detail hier behandelt:
https://libvirt.org/formatnwfilter.html

Um Zugriff auf die iptables/ebtables-Regeln zu bekommen, kann man kann die Filter dann einfach mal testweise über die Einbindung in libvirt-XML-Dateien zur Anwendung bringen, sich die zugehörigen generierten iptables- und ebtables-Regeln über "iptables -L" und "ebtables -L" anzeigen lassen und später in modifizierter Form in eigene iptables-Scripts integrieren.

Folgender wichtiger Artikel zeigt, wie etwa der wichtige "clean-traffic"-Filter mit Hilfe von ebtables konkret von libvirt implementiert wird (besser im Jahr 2010 wurde):
https://www.redhat.com/archives/libvir-list/2010-June/msg00762.html

Security-Themen im Zusammenhang mit virtuellen Netzen

Auch virtuelle Switches können durch dieselben Angriffsmuster manipuliert werden, wie reale Switches. ARP Spoofing und Flooding sind hier die Stichworte. Etliche Probleme der Berücksichtigung von gebridgten Devices bestehen deshalb darin, dass der Layer 2 des OSI-Schichtenmodells von iptables-Regeln ignoriert wird.
http://serverfault.com/questions/457262/configure-iptables-on-kvm-host-to-block-guest-bridge-traffic

Das führt z.B. bei der Benutzung von conntrack-Regeln unter iptables potentiell zu Schwierigkeiten. Gastsysteme können - z.B. über Ausnutzung des conntrack-Verhaltens und Erzwingen eines HUB- statt Switch-Verhaltens auf der Bridge den eigenen Datenfluss mit dem anderer Gäste mischen. ARP-Spoofing kann sogar zu Problemen bei 2 getrennten Bridges führen. Siehe hierzu folgende Diskussionen:
http://patchwork.ozlabs.org/patch/29319/
https://bugzilla.redhat.com/show_bug.cgi?id=512206
http://serverbugs.com/Question.aspx?q=-conntrack-tracking-private-TCP-sessions-between-VMs&i=593650
und entsprechende Teile von
http://blog.klauskiwi.com/wp-content/uploads/2010/08/KVM-Security_en.pdf

Will man iptables auf direkten Bridges zu physikalischen Devices nutzen, so sind "physdev"-Definitionen erforderlich:
Siehe
http://people.netfilter.org/kadlec/ipset/iptables.man.html
und dort den Abschnitt zu "physdev".

Siehe auch:

und dort S.504 bis S.517.

Es wurde jedoch aus Sicherheitsgründen vielfach empfohlen, iptables auf direkt gebridten Hosts abzuschalten. Siehe hierzu neben den obigen Artikeln auch die Seiten 3 und 4 des folgenden Artikels:
https://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatsecurity_pdf.pdf
und
https://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatkvmsecnetfilter.htm
https://wiki.archlinux.org/index.php/QEMU#Bridged_networking_using_qemu-bridge-helper
http://wiki.libvirt.org/page/Networking - s. dort den Bereich über (direct) "bridged networking"
http://www.cyberciti.biz/faq/debian-ubuntu-linux-kvm-guest-shared-physical-network/
https://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Network_Configuration-Bridged_networking_with_libvirt.html

Siehe jedoch als Gegenmeinung :
http://netfilter.vger.kernel.narkive.com/M0WsSp2h/security-validity-of-iptables-in-multi-bridge-environment

Was immer ihr davon haltet, ich meine, dass Abhilfe generell durch die zusätzliche Etablierung von restriktiven ebtables-Regeln möglich ist. Die schaden zumindest nicht und helfen auch bzgl. ARP-Spoofing.

Zum Thema des ARP-Spoofings siehe u.a.
https://www.berrange.com/posts/2011/10/03/guest-mac-spoofing-denial-of-service-and-preventing-it-with-libvirt-and-kvm/
http://www.admin-magazine.com/Articles/Arp-Cache-Poisoning-and-Packet-Sniffing
sowie
http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatkvmsecmac.htm
http://www.linux-magazin.de/Ausgaben/2004/12/Zugbruecke
http://www.linux-magazin.de/Ausgaben/2004/12/Zugbruecke/%28offset%29/6

Etwas Off-Topic: ARP-Spoofing und Flooding wird übrigens auch als Problem für Docker-Implementierungen diskutiert:
https://nyantec.com/en/2015/03/20/docker-networking-considered-harmful/
http://arxiv.org/pdf/1501.02967.pdf
Die Argumente in der letzten Untersuchung gelten meiner Meinung nach für KVM-Systeme analog und belegen, dass es wichtig ist, ebtables-Regeln zu etablieren!

Bridging und ebtables-Regeln sind in genereller Form hier diskutiert:
http://ebtables.netfilter.org/misc/brnf-faq.html
http://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html
http://ebtables.netfilter.org/documentation/bridge-nf.html
http://ebtables.netfilter.org/misc/brnf-faq.html

Ein kleines Fallbeispiel, dass erneut die Bedeutung von ebtables aufzeigt, ist hier besprochen:
http://serverfault.com/questions/607224/iptables-matching-packets-for-bridged-interface

Ich hoffe, ich habe mit diesen Lektüre-Hinweisen dem einen oder anderen einen kleinen Fahrplan für das Erforschen der Tiefen und Untiefen virtueller Netze und Linux und speziell mit KVM/qemu an die Hand gegeben.