Motive für eine intensivere Beschäftigung mit KVM-Hosts und Security

Ein Angestellter eines Kunde, bei dem ich mehr in der Rolle des Prozessberaters arbeite, fragte mich vor kurzem, warum ich in letzter Zeit so viel Zeit in das Sicherheitsmanagement von Servern stecke.

Es stimmt: Ich beschäftige mich – im eigenen Netz, aber auch im Auftrag von Kunden – immer wieder mit KVM Hosts und Web- / Datenbank-/ Mail-Servern bzw. MS Windows-Clients in Gastinstanzen. Ein Thema, das mich seit längerem – vielleicht zu Unrecht – beunruhigt, ist die Abschottung von Gastsystemen und virtuellen Netzwerkbereichen hinter (virtuellen Bridges/Switches) gegeneinander.

Mehrere Punkte und Fragen sorgen hier bei mir immer wieder für besagte Unruhe:

  • Sind iptables-Regeln für Paketfilter auf dem Host hinreichend? Sind nicht auch zusätzliche ebtables-Regeln erforderlich?
  • Ist eine Paketfilter auf dem Host und damit für die virtuellen Bridges überhaupt sinnvoll? Oder sollte jeder Netzwerkbereich seine eigene virtuelle Perimeter-Firewall bekommen? Oder beides?
  • Wie können virtuelle Bridges/Switches angegriffen werden? Was ist z.B. mit ARP-Sppofing/-Flooding?
  • Wenn Firewall-Regeln auf dem Host und übergreifend für virtuelle Bridges/Switches: Sind Regeln zu etablierten Verbindungen der Form
    • $IPTABLES -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
    • $IPTABLES -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
    • $IPTABLES -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

    ein potentielles Sicherheitsrisiko, da damit ein Bridge-übergreifender Kontext auf dem Host geschaffen wird?

  • Welche Möglichkeiten hat eine Angreifer bei aktiviertem Routing über den Host zwischen 2 virtuellen Netzwerksegmenten?

Zu all diesen Punkten gibt es in diversen einschlägigen Foren Diskussionspunkte. Ich finde, das Spektrum der Fragen ist ein genaueres, eigenes Studium von virtuellen Bridges auf Linux-Hosts wert. Ich werden in kommenden Artikeln immer mal wieder auf diese Fragestellungen und zugehörige Scan- und ggf. Penetrations-Tests und notwendige Verteidigungsmaßnahmen zurückkommen.

Wine/Crossover Office – Positionierung und Größenänderung von KDE-Fenstern für MS Office 2007/2010

Im Rahmen von Beratungsaufträgen für Kunden bin ich immer mal wieder gezwungen, auf Windows Office-Anwendungen zurückzugreifen. Denn leider funktioniert in etlichen Fällen mit komplexeren Dokumenten oder Präsentationen der Weg

LibreOffice => Zip-File/Mail => MS Office => Zip-File/Mail => LibreOffice => Zip-File/Mail => MS Office

nicht völlig verwerfungsfrei.

Um Kundenbeschwerden aus dem Weg zu gehen, nutze ich deshalb – wenn erforderlich – MS Office 2010 Applikationen unmittelbar über Wine (in Form von Crossover Office) auf meinem Linux/KDE-Desktop. Nun habe ich mir kürzlich einen neuen Laptop zugelegt; zwangsläufig musste ich meine komplette SW-Umgebung vom Altsystem um- und nachziehen. Dabei stößt man dann im Zuge der Wine-, der Crossover Office- und der nachfolgenden MS Office-Installation unter einer passenden “Wine-Bottle” als MS-Laufzeit-Umgebung (oder nach einem Bottle-Ex/Import) zwangsläufig auf folgendes Thema:

Die KDE-Fenster für die Wine basierten MS Office-Applikationen lassen sich nach einer einmal durchgeführten Full-Screen-Maximierung nicht mehr wie andere Standardfenster mit der Maus über einen Drag-Vorgang mit der Maus auf der Menüleiste bewegen. Ferner funktionieren danach freie Größenänderungen des Fensters mit der Maus nicht mehr. Man kann nur zwischen maximaler Größe und einem vordefinierten Größen-Format hin und her schalten.

Das ganze Problem hatte ich früher schon mal durchlitten – und schließlich über KDE-Einstellungen gelöst – nur leider vergessen wie. Ärgerlich! Die Zeit zum Rumprobieren kann man sich beim nächsten Mal wirklich sparen. Deshalb hier eine Zusammenstellung der erforderlichen Schritte.

Einstellungen für die betroffene Wine/Crossover Bottle (“Flasche”) der Windows-Applikation

Hierzu das zentrale “CrossOver” Verwaltungsapplikation öffnen (im Terminal nach einer Standardinstallation z.B. über den Aufruf von “/opt/cxoffice/bin/crossover”).

Dort den Menüpunkt “Werkzeuge >> Flaschen verwalten” wählen. Die jeweilige “Flasche” für die Windows-Office-Installation im linken Seitenbereich auswählen, rechts den Tab “Systemsteuerung” wählen und darunter den Punkt “Wine Konfiguration” anklicken.

Im sich öffnenden Konfigurationsfenster den Reiter “Grafik” anklicken. Dort folgende Optionen auswählen:

  • Erlaube dem Fenstermanager die Fenster zu dekorieren
  • Erlaube dem Fenstermanager die Fenster zu kontrollieren

bottle1

Diese Einstellungen dienen dazu, dass der Window-Manager (ob unter Windows oder nicht) – zumindest grundsätzlich – die Kontrolle über die Applikationsfenster zu bekommt.

Wenn man bei einem Umzug auf ein anderes System die Export/Import-Funktionalität für Wine-Bottles nutzt, sollten diese Einstellungen auf dem neuen System bereits gegeben sein – soweit man sie auf dem Altsystem schon vorgenommen hatte.

Sonderregeln für KDE-Fenster-Einstellungen

Nun müssen wir noch die andere Seite – nämlich die des Window-Managers unter KDE betrachten. Hierzu die KDE Systemeinstellungen öffnen (im Terminal über das Kommando: systemsettings &).

Dort unter der Rubrik “Erscheinungsbild und Verhalten der Arbeitsfläche”
den Punkt “Fensterverhalten” anklicken. Im sich öffnenden Fenster “Fensterregeln” wählen. Dann den Button “Neu” klicken.

Wir landen im Reiter “Fensterübereinstimmung” eines sich neu öffnenden Dialogfensters.
Das Feld “Beschreibung” füllen wir mit Stichwörtern unserer Wahl (“MS Office 10 Regeln”). Nun ein Klick auf Button “Fenstereigenschaften ermitteln”. Dies hilft uns, Informationen dazu zu erhalten, unter welcher sog. Fensterklasse KDE die wine-basierten MS Office-Applikationen eigentlich führt. Klickt man mit dem angebotenen Kreuz-Cursor nun auf ein geöffnetes Crossover Fenster für Winword, so öffnet sich ein Fensterchen, in dem man bzgl. der sog. “Klasse” den Ausdruck “Wine (WINWORD.EXE Wine)” vorfindet.

Nach dieser Information klicken wir im Informationsfensterchen auf “Abbrechen” und landen wieder im Dialog zur “Fensterübereinstimmmung”.

bottle2

Bei der Combobox zum Punkt “Fensterklasse” nun den Punkt “Regulärer Ausdruck” wählen. Wir müssen einen Regex-Ausdruck festlegen, der die Fensterklassen, die KDE (bzw. X-Windows) den betroffenen Crossover-Fenstern zuordnet, am besten erfasst. In Anlehnung an die oben bereits ermittelte Information, die wir auf Excel und Powerpoint erweitern wollen, nehme ich

.*\b(winword.exe|excel.exe|powerpnt.exe)\b.*

Bzgl. evtl. Sorgen bzgl. einer Groß-/Kleinschreibungs-Thematik siehe den letzten Kommentar unter https://bugs.kde.org/show_bug.cgi?id=173544. Wer dem Regex wegen der Großschreibung z.B. der MS Office 2010-EXE-Dateien dennoch nicht traut, kann ja versuchsweise “i”-Modifikatoren einsetzen, wird aber feststellen, dass das i.d.R. Fehler nach sich zieht. Zusätzlich ist ein Haken beim Feld “Übereinstimmung mit gesamter Fensterklasse” erforderlich.

Wichtige Ergänzung 20.11.2015:

Speziell im Falle von Powerpoint gibt es mit den bisherigen und den nachfolgenden Einstellungen Probleme, da auch kleine Grafiken bei Verschiebungen und Größenänderungen zur Erzeugung kleiner Fenster führen, die z.B. die Verschiebung während der Mausaktion anzeigen. Man muss daher die Anwendung der nachfolgenden Regeln von vornherein weiter auf die Hauptfenster einschränken. Ein wenig Experimentieren führte mich dann zu folgender Lösung: Für das Feld “Fenstertitel” wählt man erneut “regulärer Ausdruck” und

.*\b(.*)\b.*

crossover_5_800

Nicht besonders elegant- aber wirksam. (Sicher gibt es bessere Lösungen, aber ich komme grad nicht drauf.)

Nun weiter zum Reiter “Größe und Position”. Wir wollen verhindern, dass der Fenstertyp sich beim erneuten Öffnen an eine evtl. vorgenommene Maximierung erinnert und dass wir auf eine bestimmte Geometrie festgelegt werden. Deshalb sind folgende Einstellungen erforderlich:

  • Vollbild => Erzwingen => Nein
  • Angeforderte Geometrie ignorieren => Erzwingen => Ja

bottle3

Wir bestätigen diese Einstellungen durch OK. Nach dem Schließen der Dialogfenster zu den konkreten Einstellungen aktivieren wir die geänderten Einstellungen noch über den Button “Anwenden”.

Danach verhalten sich die Crossover Fenster für MS Office Applikationen unter KDE
wie normale Fenster nativer Linux-Applikationen. Falls nicht: Einmal abmelden und dann wieder in den KDE-Desktop einloggen.

beispiel1_red

Alternative Fensterhandhabung

Ein “Alt-Klick” auf ein Fenster ermöglicht grundsätzlich dessen Verschiebung auf dem Desktop. Das gilt auch für Crossover-Fenster. Das Gleiche erreicht man über einen Klick mit der rechten Maustaste auf das Fenstersymbol zu unserem Crossover-MS-Office-Fenster in der KDE Fensterleiste und eine nachfolgende Wahl des Punktes “Weitere Aktionen” im sich öffnenden Menü. Dies führt uns zu einer Auswahl von Fensteroperationen, die sich auf diesem Wege auch für Crossover Fenster ausführen lassen. Eine dieser Fensteroperationen ist auch die Größenänderung.

Links

https://www.codeweavers.com/compatibility/crossover/forum/microsoft-office-2010?msg=157908
https://bugs.kde.org/show_bug.cgi?id=329227
http://www.linuxforen.de/forums/showthread.php?230623-Wine-Fenster-l%E4sst-sich-nicht-verschieben-und-ist-immer-im-Vordergrund
https://forum.winehq.org/viewtopic.php?f=8&t=20006

Viel Spaß dann noch mit Wine und Crossover Office! Dass man mit MS Office Spaß haben wird, ist bei den Lesern eines Linux-Blogs kaum zu erwarten. Seit MS Office 2007 frage ich mich persönlich immer wieder, welcher Wahnsinnige sich wohl die aus meiner Sicht chaotische und den Arbeitsfluss nicht fördernde, sondern eher behindernde Benutzerführung ausgedacht hat … Na ja, eingefleischte MS Fans können das sicher erklären. Ich bin jedenfalls froh, dass es ein inzwischen relativ ausgereiftes LibreOffice gibt und mir das Leben leichter macht.