Tag Archives: Debian 8

Remote Desktop für Debian 8 mit X2Go auf Strato-V-Servern

Posted on by

In unserer Firma fallen z.Z. mehrere technische Schritte an, die wir parallel abwickeln müssen:

So stellen wir einerseits zwei Opensuse-Leap-Server für einen Kunden auf Debian-8-basierte vServer beim Hoster Strato um. Zeitgleich ersetzen wir das von uns unter Eclipse genutzte Versionsverwaltungssystem SVN durch Git und binden u.a. auch dabei einen der gehosteten vServer ein.

Damit wir und unser Kunde auf dem vServer

  • das dortige Git-Server-Repository besser kontrollieren und verfolgen können,
  • gelegentlich Branches anlegen und Merge-Aktionen durchführen können,

sollen auf dem vServer auch graphische GIT-Frontends zum Einsatz kommen. Z.B. “cola-git”, “qgit”, “giggle”. Ziel ist u.a. die Ansicht solcher Graphen wie in der nachfolgenden Abbildung:

Obwohl die Anwendung am Server läuft, wollen wir den Output natürlich auf dem Desktop unserer Arbeitsplatz-PCs oder denen des Kunden ansehen können.

So stellte sich uns also die Frage, wie man am schnellsten zu einem performanten graphischen Remote-Desktop für ein gehostetes “headless” System, also für ein System ohne echte eigene Grafik-Ressourcen, kommt. In unserem Fall zeigte sich, dass X2GO die richtige Wahl war und ist.

Nomenklatur – Remote Hosts, X-Server, X-Clients

Wir verwenden im weiteren Text die nachfolgende Nomenklatur, um Missverständnisse zu vermeiden. Bekanntermaßen ist ja beim X11-Protokoll die laufende Grafik-Anwendung ein “X-Client”. Das Umsetzungsprogramm, das aus den Grafik-Befehlen des Clients schließlich Fenster und grafische Inhalte auf den Bildschirm eines Linux-Desktops oder oder die Grafikstation eines Thin Client zaubert, ist hingegen der “X-Server”.

Die zuständigen Protokolle für den Datenaustausch zwischen X-Client und X-Server funktionieren auch über Netzwerke hinweg:

  • Als “Remote-Host” bezeichne ich den vServer bei Strato. Dort laufen dann Linux-Anwendungen, die grafischen Output im Rahmen ihres Benutzerinterfaces anbieten (in unserem Beispiel GIT-Anwendungen mit GUI).
  • Das Linux-System, von dem aus wir auf den vServer zugreifen, nenne ich “Arbeitsplatz-PC” oder kurz “PC”. Auf ihm läuft unter Linux selbstverständlich auch ein lokaler X-Server. Dieser dient wiederum einem Linux-Desktop – in meinem Fall KDE 5 – als technische Basis für die Integration grafischer Benutzerschnittstellen zu lokalen und entfernten Anwendungen.
  • Die graphischen Programme wie “qgit”, die auf dem vServer (=Remote-Host) laufen und ihren Output wie grafische Anweisungen einem lokalen oder über das Internet auch einem entfernten X-Server zuweisen, nennen wir “Remote X-Clients”.

Bzgl. möglicher Lösungen für Remote-Desktop-Darstellungen auf einem Arbeitsplatz-PC ist es nicht von vornherein klar, wo und in welcher Form ein X-Server zum Einsatz kommt. Natürlich läuft auf einem normalen Linux-PC ein X-Server für eine grafische Oberfläche; das schließt aber nicht aus, dass auch auf dem Remote-System ein X-Server aktiv ist.

Ein Remote-X-Client-Programm könnte also einerseits mit einem (headless) X-Server auf dem Remote-Host zusammenarbeiten. Er könnte andererseits aber auch direkt mit dem X-Server am Arbeitsplatz-PC über das Internet interagieren (z.B. über ssh -X oder die explizite Vorgabe eines entfernten X-Servers samt Screen über die Umgebungsvariable “DISPLAY”).

Funktionsweise von VNC vs. X2Go

Der Vollständigkeit halber werfen wir deshalb auch einen kurzen Blick auf Unterschiede in der typischen Funktionsweise von VNC und X2Go. Man beachte, dass in beiden Fällen “Server”-Komponenten auf dem Remote-Host und “Client”-Komponenten auf dem Arbeitsplatz-PC zum Einsatz kommen; das ist gerade umgekehrt wie bei den X11-Komponenten:

  • VNC: Auf dem Remote-Host kann theoretisch ein headless X-Server laufen, für dessen Implementierung ggf. die zu installierende Remote-Desktop-Umgebung (wie etwa ein VNC-Server-Modul) sorgen muss. Dessen Bilddaten-Output könnten dann über ein VNC-Programm abgegriffen und über das Internet an einen Arbeitsplatz-PC bei uns übertragen werden. Dort greift dann ein VNC-Client-Programm die Daten auf und blendet sie als lokaler X-Client über ein passendes Fenster in den grafischen Linux-Desktops des PCs ein.
  • X2Go: Unter X2Go läuft auf dem Remote-Host der sog. “X2Go-Server”. Der nutzt essentielle Teile des X11-Protokolls um Daten und Grafikanweisungen an den X-Server eines Arbeitsplatz-PCs zu übertragen. Dort koppelt allerdings ein zwischengeschalteter “X2Go-Client” an den X11-Server des Arbeitsplatz-PCs an. (Unter Windows Clients ist ein geeigneter X11-Server bereitzustellen!). Im Unterschied zu ” ssh -X” oder einem direkten Remote Zugriff auf einen X11-Server werden von den zwischengeschalteten X2Go-Komponenten zusätzlich Kompressionsalgorithmen und Caches exzessiv genutzt und der Statusabgleich zwischen X11-Server und X11-Client auf das notwendige Minimum reduziert.

In beiden Fällen müssen die VNC- oder X2Go-Client-Komponenten natürlich die Keyboard- und Mausinteraktionen mit den relevanten Fenstern am Arbeitsplatz-PC abfangen und an die X-Clients auf dem Remote-Host übertragen.

Ich gehe nachfolgend von klassischen X-Servern (und nicht Wayland) aus. Wayland ist meines Wissens nicht mit X2Go kompatibel.

SSH -X als Alternative ?

Natürlich habe ich auf unserem Strato-vServer erstmal eine direkte grafische Datenübertragung zwischen den X-Clients der vServer und meinem Arbeitsplatz-PC mittels “ssh -X” ausprobiert. Dabei wird der Grafik-Output der X-Remote-Clients (über das zwischengeschaltete Internet) direkt vom X-Server am Arbeitsplatz-PC behandelt. Aber Qgit, Giggle und Co. sind doch schon recht komplexe Anwendungen, die mit einem X-Server relativ häufig relativ viele Informationen austauschen müssen.

Ich war mit der Performance überhaupt nicht zufrieden. Das Arbeiten an sich erwies sich zwar nicht als unmöglich; aber bei verschiedenen Schritten treten doch spürbare Wartezeiten auf – u.a. beim Aufbau von Verzeichnis- und Strukturbäumen. Die Durchführung von Änderungen war dann nicht wirklich bequem, sprich nicht flüssig möglich. Mein Eindruck war: Es wird eine deutlich bessere Kompression und Pufferung der Daten benötigt.

Probleme mit VNC – und Einschränkungen bzgl. der Desktop-Umgebung

Ich dachte als Nächstes natürlich an klassische VNC-Anwendungen (https://de.wikipedia.org/ wiki/ Virtual_Network_Computing), mit deren Hilfe man einen echten Remote-Desktop realisiert.

In LANs hatte ich früher schon mal TurboVNC eingesetzt. Ich hatte das damals als recht performant empfunden. Sogar der Einsatz von VirtualGL für Remote-Hosts, die mit einer 3D-Grafik-Karte ausgestattet waren, war möglich. Nun braucht man für einen Strato vServer und GIT-Frontends natürlich kein VirtualGL. Aber TurboVNC war ja auch sonst ganz OK – zumindest unter älteren Opensuse-Systemen.

Dennoch habe ich den Einsatz von TurboVNC auf einem Strato-vServer mit Debian nach ein paar Experimenten abgebrochen. Unter Debian 8 gab es (fast erwartungsgemäß) Probleme mit Gnome 3 (trotz vorhandener Mesa-Bibliotheken). Gnome 3 ist (wie KDE 5 auch) von Haus aus für VNC problematisch, da 3D-Fähigkeiten der Umgebung vorausgesetzt werden. Bei mir klappte der Start des Desktops trotz vorhandener Mesa-Bibliotheken und des lokalen VMware-Grafiktreibers des Virtuozzo-Containers für den Strato-vServer nicht.

Auch eine kurze Recherche im Internet zeigte: Der Einsatz von Gnome erfordert unter klassischen VNC-Servern (und auch unter TurboVNC) einfach viel zu viele Klimmzüge. Wie funktionabel und performant dagegen der in Gnome integrierte VNC-Server “vino” ist, habe ich in meinem Frust dann nicht mehr ausprobiert.

KDE 4 unter Debian 8 ging zwar unter TurboVNC; ich bekam aber keine Veränderung der Auflösung jenseits 1024x768px am TurboVNC-Client auf dem Arbeitsplatz-System hin. Der Zeitaufwand für das Rumprobieren wurde mir dann irgendwann zu groß. Das hatte zwei Konsequenzen:

  • Als erstes reduzierte ich meine Anforderungen an eine Desktop-Umgebung kurzentschlossen auf LXDE und KDE4. Mit letzterem kennt sich auch unser Kunde in hinreichendem Maße aus.
  • Als zweites konzentrierte ich mich auf die von Debian im Standardumfang mitgelieferten VNC-Pakete: “tightvnc” und “vnc4server”.

Ein Kurztest der beiden VNC-Varianten überzeugte mich aber hinsichtlich der Performance mit KDE 4 nicht; besonders nicht der vnc4server. Mit LXDE konnte ich dagegen ganz gut arbeiten.

KDE 4 ist halt ein Desktop-Schwergewicht, das den X11-Server je nach Desktop-Gestaltung laufend belastet. Dabei ist zu bedenken, dass die meisten VNC-Systeme auf dem Remote-Linux-System einen laufenden (headless) X11-Server brauchen, dessen Bilddaten dann abgegriffen und an einen VNC-Client auf einem lokalen PC übertragen werden. Das ist vom logischen Prozess-Ablauf her gesehen ein Umweg, weil neben dem X11-Server noch eine Zwischenschicht auf dem Remote-System ausgeführt werden muss. Die Bilddaten auf dem lokalen PC müssen zudem wieder in einem Fenster auf dem lokalen X11-Server dargestellt werden.

X2Go als Alternative ?

Wenn es denn hinreichend schnell funktionieren würde, würde man deshalb als Linuxer eigentlich immer gerne direkt Remote-X11 über SSH einsetzen. Auf dem Remote-System – hier also dem vServer – liefen dann Anwendungen, die als X-Window-Client-Programme ihre Daten und graphischen Steuerbefehle (über einen SSH-Tunnel) direkt an den aktuell laufenden X11-Server auf meinem Arbeitsplatz-PC übertragen. In unserem LAN klappt das auch wunderbar – sogar mit der Übertragung von 3D-Grafik-Daten. Da reicht die Bandbreite schon in einem Gigabit-Netz zur schnellen Datenübertragung völlig aus. Das gilt aber leider nicht unbedingt für Remote-Systeme im Internet zu denen die Bandbreite in beide Richtungen begrenzt ist. (Zumindest bei mir).

Dann fiel mir ein: Eine hinsichtlich Kompression, Caching und X11-Server/Client-Abgleich optimierte Variante des X11-Protokolls über ein Netzwerkverbindungen lieferte doch das NX3-Nomachine-Protokoll; es bildet die Grundlage des Opensource Forks X2Go (siehe hierzu die Links weiter unten).

Ergebnis eines kurzen X2Go-Tests

Am Ostersamstag habe ich mir dann nach ein wenig Internet-Recherche (und zum Leidwesen meiner Frau) auch den X2Go-Server und X2Go-Client angesehen. Ergebnis: Ich bin nach wie vor begeistert! Stichpunkte sind:

  • Denkbar einfache Installation und Konfiguration. Einfache Integration von SSH-Schlüsseln. Einfache Einstellung unterschiedlicher Auflösungen.
  • Sehr gute, wirklich überzeugende Performanz!
  • Der Datenaustausch zwischen Remote-System und dem Arbeitsplatz-PC erfolgt von vornherein auf SSH-Basis.

Weitere erwähnenswerte Features, die die praktische Nutzung erleichtern, sind:

  • Copy/Paste zwischen nativen lokalen Fenstern des Arbeitsplatz-PCs und Fenstern des Remote-Desktops ist nahtlos möglich.
  • Freigabe lokaler Verzeichnisse: X2Go erlaubt vom Remote-Desktop aus auch einen Zugriff auf (dafür freigegebene) lokale Verzeichnispfade des Arbeitsplatz-PCs. Damit können Files auf dem Remote-Host z.B. in einem graphischen File-Manager zwischen den dortigen Verzeichnissen (des Hosts) und dem lokalen Verzeichnis des Arbeitsplatz-PCs verschoben/kopiert werden. Zur Wahrung der Sicherheit bei solchen Transaktionen gibt es die Option, den Datenaustausch über SSH getunnelt durchzuführen.
  • Mehrere Sitzungen gleichzeitig: Will man mehrere Sitzungen zu verschiedenen Servern gleichzeitig öffnen, so startet man auf dem lokalen PC mit “x2goclient &” einfach einen neuen Client. Auch zwei Sitzungen unter unterschiedlichen Benutzernamen zum gleichen Server sind möglich. Ebenso zwei Sitzungen mit derselben Remote-UID für verschiedene Desktops/Window-Manager – z.B. eine Sitzung mit LXDE und eine mit KDE für ein und denselben User auf demselben Remote-Host. X2Go-Client zeigt einem eine Liste laufender Sitzungen und fragt, was mit den laufenden Sitzungen passieren soll. Die lässt man weiterlaufen und wählt für die neue Sitzung die Option “Neu”. Die verschiedenen Remote-Sitzungen zum gleichen Remote-Host teilen sich dann aber natürlich dessen Netzwerk-Ressourcen. Die sind bei Stratos vServern durchaus begrenzt.
  • Seamless Mode: X2Go erlaubt anstelle der Anzeige eines kompletten Remote-Desktops theoretisch auch das Remote-Starten einer einzelnen Anwendung und deren Anzeige auf dem lokalen Desktop des Arbeitsplatz-PCs. (Seamless Mode; das Ganze entspricht dann in der klassischen SSH-Welt in etwa dem vorkonfigurierten Aufruf einer grafischen Remote-Applikation nach einem ssh -X.). Leider klappt das aber auf einem KDE5-Plasma-Desktop (s.u.) nicht wie erwartet.
  • Desktop-Sharing: X2Go bietet auch die Möglichkeit des Desktop-Sharings zwischen verschiedenen Nutzern an – das habe ich aber unter den Bedingungen eines vServers aber noch nicht ausprobiert. Ich gehe darauf in diesem Artikel auch nicht weiter ein.

Mit jedem dieser Punkte kann ja jeder mal selber herumexperimentieren. Siehe zur Thematik paralleler Sitzungen auch
https://gist.github.com/ ledeuns/ f0612fb43b967c129c88)

Bzgl. des Desktop-Sharings:
http://wiki.x2go.org/ doku.php/ doc:usage:desktop-sharing

Arbeitet man gleichzeitig unter derselben UID mit 2 getrennten Sessions – z.B. einer LXDE- und einer KDE-Sitzung – auf demselben Arbeitsplatz-PC, so können dabei interessante Effekte z.B. unter Libreoffice auftreten: Ist Libreoffice bereits auf einem der (Remote-)Desktops (z.B. dem KDE-Desktop) geöffnet, so wird ein nachfolgendes Libreoffice-Programm, das in einer parallel laufenden LXDE-Sitzung gestartet wird, trotzdem im KDE-Desktop angezeigt. Ansonsten läuft das Meiste aber normal und erwartungsgemäß.

Für mich war wirklich überraschend, dass neben meinen Git-GUIs auch stark grafiklastige Anwendungen wie Libre-Office Draw, Impress, Inkscape etc. gleichzeitig und sehr, sehr flüssig nutzbar waren. Aus meiner Sicht ist hier die Performance eines Terminal-Servers gegeben, die im wesentlichen nur durch die Netzanbindung des vServers ans Internet limitiert wird und im getesteten Umfang (4 parallele 1920×1200 Sitzungen) überhaupt nicht durch CPU/RAM des Virtuozzo Containers für unseren vServer [V30 bzw. V40, HP3PAR] begrenzt wurde.

Weil es so schön ist, nun eine Zusammenstellung der wichtigsten Hinweise zur Installation und Inbetriebnahme von X2Go, die ich bei dieser Gelegenheit im Internet aufgesammelt habe.

X2Go-Installation: Passende Repositories ziehen

Unter folgendem Link ist beschrieben, wo man die aktuellen Repositories mit X2Go-Komponenten für Debian 8 (64Bit) findet: http://wiki.x2go.org/ doku.php/ wiki:repositories:debian.

Man trägt dann die Repositories über folgende Zusatzzeilen in die Datei “/etc/apt/sources.list” ein: 

root@myremotedebian:~# cat /etc/apt/sources.list
# See sources.list(5) for more information, especialy
# Remember that you can only use http, ftp or file URIs
# CDROMs are managed through the apt-cdrom tool.
deb ftp://ftp.stratoserver.net/pub/linux/debian/ jessie main contrib non-free
deb ftp://ftp.stratoserver.net/pub/linux/debian-security/ jessie/updates main contrib non-free

#ICH - 15.04.2017 - Repos for X2Go:
# -----------------------------------
#X2Go Repo
deb http://packages.x2go.org/debian jessie main
# X2Go Repository (sources of release builds)
deb-src http://packages.x2go.org/debian jessie main

Zur Sicherheit machen wir den zugehörigen Key verfügbar; als root: 

root@myremotedebian:~ # apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E

Dann Update der Paket-Datenbank durchführen: 

root@myremotedebian:~ # apt-get update

Nun – als Test – Installieren des Schlüssels über ein Paket aus dem X2Go-Repository: 

root@myremotedebian:~ #  apt-get install x2go-keyring && apt-get update

Dann die Pakete x2goserver und x2goserver-xsession installieren: 

root@myremotedebian:~ #  apt-get install x2goserver

Bei mir wurde x2goserver-xsession automatisch mit installiert. Falls das nicht der Fall sein sollte: 

root@myremotedebian:~ #  apt-get install x2goserver-xsession

Man glaubt es vielleicht nicht – aber das war es im Prinzip serverseitig schon. Zumindest was X2Go anbelangt. Der Grund hierfür ist, dass der X2GO-Client (s.u.) eine SSH-Sitzung nutzt und im Zuge des SSH-Logins die nötigen Umgebungsvariablen setzt und erforderliche Programme auf dem Server für eine Remote-X-Sitzung startet.

LXDE und KDE 4 installieren

Sollte man LXDE oder KDE 4 unter Debian 8 noch nicht installiert haben, so ist dies über 

root@myremotedebian:~ #  apt-get install lxde

bzw.

root@myremotedebian:~ #  apt-get install kde-standard

möglich.

Will man Remote-Audio nutzen, sollte man ggf. auf dem Remote-Host und auch auf dem Arbeitsplatz-PC Pulseaudio installieren. Für mich ist Sound irrelevant – und Pulseaudio kommt bei mir aus Prinzip nicht auf einen PC-Desktop. Aber das mag ja bei anderen anders sein … 🙂

Natürlich muss auf beiden Systemen SSH bereitstehen ..

Auf dem Debian 8 Remote-Host muss zwingend das Paket “openssh-server” installiert sein. Zudem sollte der Server aus Sicherheitsgründen so konfiguriert sein, dass der SSH-Port verlagert ist, sichere Kex-Algorithmen genutzt und eine Authentifizierung über asymmetrische Keys (hinreichender Länge) durchgeführt wird. Der Zugang sollte ferner durch eine Firewall und weitere Maßnahmen auf bestimmte Clients beschränkt werden. Ich gehe auf die SSH-Server-Konfiguration hier nicht weiter ein. Da wir es hier mit gehosteten Remote-Systemen zu tun haben, gehe ich davon aus, dass der zuständige Admin dieses Metier beherrscht.

Jedenfalls muss auf dem Server ein SSHD-Dämon laufen und bereit sein, Logins über einen in der Firewall für bestimmte Clients geöffneten Port entgegen zu nehmen. X2Go tunnelt später die gesamte Kommunikation zwischen Client und Server durch die SSH-Verbindung. Darum muss man sich nicht mehr selber kümmern; s.u.. Es ist übrigens nicht notwendig, für verschiedene Sitzungen auf ein und demselben Remote-Host mehrere unterschiedliche SSH-Ports zu öffnen.

Installation und Nutzung auf dem Arbeitsplatz-PC (X2Go-Client)

Bzgl. der Client-Installation gilt: Es sind passende Pakete für die Distribution zu finden, die man auf seinem Arbeitsplatz-PC einsetzt. Siehe für Hinweise
http://wiki.x2go.org/ doku.php/ doc:installation: x2goclient.

Ich beschreibe die Clientseite hier nur für einen Opensuse Leap 42.2 Client. Für Opensuse liegen die erforderlichen RPMs unter folgendem Repository:
repositories/X11:/RemoteDesktop:/ x2go/openSUSE_Leap_42.2/
Von dort installiert man mittels YaST etwa “x2goclient”, “pyhoca-gui”. Der Rest der benötigten Pakete wird dann über Abhängigkeiten nachgezogen:

Nun öffnet man auf seinem Client-PC den Client am Terminal etwa über: 

ich@mytux:~> x2goclient &

Es öffnet sich initial eine Oberfläche, die die Anlage von sog. “Sitzungen” zu Remote-Hosts erlaubt; diese “Sitzungsvarianten” werden später im X2Go-Client-Fenster zur Auswahl angeboten.

Ich zeige nachfolgende die verschiedenen Konfigurationsdialoge für eine Sitzung (die ich “Dummy” genannt habe). Natürlich muss man die Eingabefelder mit den für seine eigene Situation passenden Daten ausfüllen.
Siehe für eine ausführliche Beschreibung des X2Go-Client-Setups zudem:
http://wiki.x2go.org/ doku.php/ doc:usage:x2goclient

Zunächst – und das ist das Wichtigste – müssen wir die Serververbindung einstellen:

Dann steht eine Konfiguration der Bandbreite der Verbindung an:

Wir wenden uns anschließend einer Konfiguration der Auflösung der Desktop-Darstellung zu:

Für erste Tests deaktivieren mal die Sound-Unterstützung:

Als letztes kann man konfigurieren, ob man bestimmte Verzeichnisse auf dem Arbeitsplatz-PCs für einen direkten Zugriff durch Remote_X-Client-Programme freigeben will. Tut man das, so sollte man in jedem Fall die zugehörige Option zur SSH-Port-Weiterleitung aktivieren.

Man kann all diese Konfigurationseinstellungen später über den Menüpunkt “Sitzung => Sitzungsverwaltung” nachbessern.

Resultate

Hat man seine “Sitzung” konfiguriert, so steht diese im rechten Bereich des X2Go-Client-Fensters zur Aktivierung bereit.

Nach einem Doppelklick rückt die aktivierte Verbindung ins Zentrum der Anzeige; in unserem Fall öfnnet sich zudem ein kleines Dialogfenster, in dem wir die Passphrase für unseren SSH-Key eingeben müssen. Und nach wenigen Augenblicken/Sekunden öffnet sich schließlich das Fenster für unseren Remote-Desktop – hier mit LXDE :

Der aufmerksame Betrachter wird Qgit im linken Bildbereich entdeckt haben – hier für ein noch sehr langweiliges Test-Repository. Ich habe fast alle mir unter Linux bekannten Git-Clients ausprobiert – jeder läuft flüssig; fast wie lokal.

Das Ganze nun auch nochmal für einen Remote-KDE-Desktop:

Für 2 parallele Sitzungen zum gleichen Server muss man einfach zwei x2go-Clients öffnen und in einer zwischenzeitlichen Anzeige bereits geöffneter Sessions die Optionen so wählen, dass die bereits geöffnete Sitzung nicht unterbrochen werden soll, sondern dass eine neue Sitzung geöffnet werden soll.

Die nachfolgende Abbildung zeigt zwei parallel zu einem vServer unter Debian 8 geöffnete Sitzungen – eine unter LXDE, die andere unter KDE4:

Getestet habe ich das Ganze mit einer vDSL-Leitung, aber auch einer ADSL-16MBit-Leitung – auch bei letzterer sind mehrere gleichzeitige Sitzungen kein Problem !

Wo so viel Licht ist, gibt es aber auch Schatten. Daher sei abschließend noch auf 2 Punkte hingewiesen, die in der Praxis relevant werden können.

Problematischer Punkt bzgl. der Soundunterstützung und Firefox unter X2Go

Im Prinzip kann X2Go (angeblich) Audio-Daten übertragen. Allerdings über einen Pulseaudio-Server. Den habe ich bei mir allerdings wegen vieler Probleme mit einer Xonar D2X und einer X-Fi nicht am Laufen. Ich benutze ausschließlich plain Alsa – das funktioniert zuverlässig und erlaubt das Umschiffen vieler Pulseaudio-Probleme. Fakt ist jedenfalls, dass es mit einer aktivierten Sound-Unterstützung für Pulseaudio unter X2Go und einem remote gestarteten Firefox ESR erhebliche Probleme gibt:

Alle Menüpunkte der Firefox-Oberfläche reagieren nicht mehr bzw. mit erheblicher (!) Zeitverzögerung auf Maus-Klicks im X2GO-Client. Firefox wirkt wie eingefroren; das stimmt aber nicht – die Reaktion kommt nur mit Minuten Verzögerung. Das ist u.a. hier beschrieben:
http://thescriptingadmin.blogspot.de/ 2015/09/ firefox-freezing-on-linux-x2go.html
https://debianforum.de/ forum/ viewtopic.php?t=164257

Wer immer daran Schuld hat. Da das mit anderen GTK-Anwendungen als FF nicht passiert, tippe ich darauf, dass FF bei installiertem PA auch erwartet, dass PA reagiert. Was remote evtl. ein Problem darstellt, wenn dort PA ggf. gar nicht installiert ist.

Ich habe mangels Interesse nicht getestet, ob dieser Fehler u.U. daran liegt, dass auf meinem Arbeitsplatz PA nicht aktiv ist. Lasst mir gerne eine Email zukommen, wenn ihr dazu was wisst. Ich persönlich verzichte aber lieber auf Sound von einer Remote-X2Go-Quelle, als mich mit PA herumzuschlagen. Vielleicht probiere ich das später mal auf einem Laptop. Falls ihr auch auf dieses Problem mit FF stoßen solltet und bereit seid, auf Sound vom X2go-Server zu verzichten, gilt Folgendes:

Wichtiger Hinweis zu einem Problem mit Firefox und dem X2Go-Client unter Linux:

Soundunterstützung im X2Go-Client abschalten (Reiter “Medien” unter den Einstellungen) oder aber auf einen anderen Soundserver umschalten. Bei mir funktionierte ein Remote-Firefox FF im X2Go-Desktop-Fenster nach einer Abschaltung der Soundunterstützung durch Pulseaudio problemfrei.

X2Go Seamless Mode funktioniert nicht unter KDE5

X2Go bietet zwar im Prinzip die Möglichkeit an, Remote X-Anwendungen auch als singuläre Applikationen zu starten, die direkt als Fenster (also ohne umgebenden Remote-Desktop) in den Desktop des Arbeitsplatz-PCs eingeblendet werden.

Hierzu konfiguriert man eine entsprechende Sitzung, z.B. nur für “qgit”, wie folgt:

Danach startet die angegebene Applikation im seamless Fenstermode. Das klappt auch mit einem Terminal wie etwa “lxterminal” (“/usr/bin/lxterminal”). Von der Kommandozeile aus, kann man dann weitere Anwendungen wie “qgit” starten, die dann wiederum als Einzelapplikation auf dem lokalen Desktop angezeigt werden.

Leider täuscht aber der erste positive Eindruck; unter KDE5 sind die zugehörigen Fenster für komplexere Anwendungen als ein Terminal in ihrer Größe leider nicht veränderbar. Das macht den Einsatz des “Seamless Mode” für KDE5 am Arbeitsplatz-PC in der Praxis unbrauchbar. Der seamless Mode funktioniert aber sehr wohl unter einem LXDE-Desktop am Arbeitsplatz-PC.

Fazit

X2Go bietet eine einfache zu handhabende Möglichkeit, performant von einem Linux-Arbeitsplatz-PC auf grafische Anwendungen eines Remote-Strato-vServers zuzugreifen. Die Linux-Installation des vServers muss lediglich einen LXDE- oder KDE4-Desktop unterstützen. (Desktops unter XFCE, Mate, LXQT habe ich nicht getestet; das sollte aber auch alles funktionieren).

Als einzige Wermutstropfen bleiben, dass der Seamless Mode auf einem KDE5-Target-Desktop des Arbeitsplatz-PCs nicht richtig funktioniert und dass im Moment weder native KDE5- noch Gnome3-Desktops des vServers unterstützt werden. Angeblich wird daran aber bereits von den X2Go-Entwicklern gearbeitet; wir freuen uns auf entsprechende neue X2Go-Versionen.

Links

Was ist X2GO?
http://www.mn.uio.no/geo/ english/services/it/help/ using-linux/x2go.html
https://de.wikipedia.org/ wiki/ NX_NoMachine
http://xmodulo.com/x2go-remote-desktop-linux.html
https://serverfault.com/ questions/227542/ what-alternatives-to-vnc-are-there-for-linux

Details zum Server
http://wiki.x2go.org/doku.php/wiki: advanced: x2goserver-in-detail

Installation von X2Go
http://wiki.x2go.org/doku.php/ wiki:repositories:debian
https://www.sugar-camp.com/x2go-vorstellung-und-installationsanleitung/
http://wiki.x2go.org/ doku.php/ doc:installation:x2goserver
http://www.linux-community.de/Internal/Artikel/ Print-Artikel/LinuxUser/2011/07/X2go-Terminalserver-auch-fuer-den-Hausgebrauch
http://xmodulo.com/x2go-remote-desktop-linux.html
https://mun-steiner.de/ wordpress/ index.php/ linux/ x2go-mit-ssh/
https://wiki.archlinux.de/title/X2go

Installation und Übersicht über ein paar Bugs
http://www.mn.uio.no/geo/english/ services/it/help/ using-linux/x2go.html

VNC : Benötigt VNC einen X-Server?
https://unix.stackexchange.com/ questions/ 129432/vnc-server-without-x-window-system

KVM, video QXL und video virtio Treiber – Video-Auflösung des Gnome-Desktops eines Debian 8-Gastystems einstellen

Posted on by

Das Gespann KVM/Qemu ist großartig und aus meinem Linux-Leben nicht mehr wegzudenken. Vorgestern habe ich ein “Debian 8”-Gast-System für Testzwecke auf einem KVM-Host aufgesetzt, der unter “Opensuse Leap 42.2” betrieben wird. Dabei fiel mir auf, dass bzgl. des Punktes “Video” (-System) während der Konfiguration der virtuellen Maschine mittels “virt-manager” nun neben dem guten und vertrauten qxl auch eine “virtio”-Komponente zur Auswahl bereitsteht. Beide Varianten verkörpern unterschiedliche “Treiber” mit denen das Gastsystem eine virtuelle Grafikkarte ansprechen kann. Als Kommunikationsprotokoll für den Transport der Grafikinformation zum Host setze ich typischerweise Spice ein.

Mir stellte sich dann die Frage, wie man eigentlich als User die Auflösung bestimmen kann, mit der das Spice-Fenster für den Gast-Desktop (hier: Gnome 3) unter dem X-Window-System des Hosts (hier: unter KDE-Plasma5) dargestellt wird. Das ist vor allem für den Fall des “virtio”-Treiber interessant. Da der Hypervisor hier wohl direkt über die Hostsystem-Treiber auf die Grafikkarte des Hostes (bzw. Speicheradressen der Graka) zugreift, war es für mich unklar, was ich an Einstellmöglichkeiten erwarten darf. Die Maximalauflösung des Hauptschirms am Host? Eine Liste von verschiedenen Auflösungen unterhalb einer Maximalauflösung?

Voraussetzung

Auf meinem Test-Host betreibe ich 3 Schirme im “xinerama”-Verbund an einer Nvidia-Grafikkarte (GTX 960; proprietärer Treiber der Version 375). Ich möchte natürlich das KVM-Fenster (genauer das Spice-Fenster) für den Gast nicht mit der Maximalauflösung des xinerama-Verbunds (7040×1440 Pixel) betreiben. Umso wichtiger ist für den User also eine angemessene, einfache Einstellmöglichkeiten im Gast-System selbst, die sich dann auf die Darstellung des Gast-Fensters auf dem Host niederschlagen soll.

Unterschiede in den Einstellmöglichkeiten beim Einsatz von QXL und virtio

Installiert man einen KVM-Gast unter “virt-manager” und kümmert sich nicht weiter um die Konsolen-Auflösung, so richtet geht libvirt von einer Standardauflösung von 800x600x16 für die Darstellung der GUI des Gast-Systems unter dem Spice-Protokoll aus. Diese Auflösung schlägt dann typischerweise auch auf einen Gnome- oder KDE-Desktop des Gastes durch. Entsprechend klein ist dann anfänglich auch das Spice-Display-Fenster auf dem Host.

Nun wird man als Standarduser versuchen, diese Auflösung im Gastsystem über die Einstellmöglichkeiten des jeweiligen Gast-Desktop-Systems (Gnome’s “gnome-control-center” bzw. KDE’s “systemsettings5”) zu verändern.

Hat man man als Video-Einheit, also die virtuelle Graka, des Gastsystems qxl gewählt, so kann man unter der Gnome- oder KDE-GUI des Gastes die Auflösung des Desktops tatsächlich dynamisch – d.h. im laufenden Betrieb – abändern.

Entscheidet man sich bei der Konfiguration des Gastes allerdings für “virtio” als Video-System, so erleidet man unter Debian 8 Schiffbruch: Die Einstellmöglichkeit beschränkt sich dann genau auf die bereits vorgegebene Größe von 800×600.

Ich bespreche die Standard-Einstellmöglichkeiten nachfolgend zunächst für QXL, den Gnome-Desktop und auch für TTYs; anschließend gehe ich auch kurz auf eine Einstellmöglichkeit für “virtio” ein. Weitergehende Einstellmöglichkeiten – wie etwa über “xrandr” werde ich auf Wunsch eines Lesers in einem späteren Artikel aufgreifen.

Gnome-Desktop-Auflösung des Gastes unter qxl setzen

Das nachfolgende Bild zeigt den Gnome 3 Desktop eines Debian-8-Gastes mit “qxl” in einer Auflösung von 1920x1080x32 auf einem KDE-Schirm des SuSE-KVM-Hostes mit einer 2560x1440x32-Auflösung.

Die Auflösung des Gnome-Desktops eines KVM-Gastsystems kann man (zumindest im Falle von QXL) sehr einfach über die “Gnome-Einstellungen=>Monitore” festlegen.

Das mögliche Auflösungsspektrum wird dabei offenbar nur durch die Auflösung der aktuellen Host-Schirme begrenzt. De facto bietet mir das System in meinem Fall Auflösungen bis zu 4K an. Diese Einstellungen beziehen sich aber nur auf den Desktop des Gastes – nicht jedoch dessen Konsolen-TTYs !

Hinweis: Hat man einen KVM-Gast mit KDE-Plasma5 so verwendet man “systemsettings5 &” und dort den Punkt “Anzeige und Monitor”, um die KDE-Auflösung festzulegen.

Das Tolle ist: Man kann unter QXL/Spice auch bei den gezeigten hohen Auflösungen wirklich flüssig arbeiten! Auch mit transparenten Fenstern! Da ist in den letzten Jahren ganze Arbeit geleistet worden. Vielen Dank an die Entwickler! (Vor allem wohl bei Red Hat.)

Auflösung der Debian8-Gast-TTYs setzen

Das “virt-manager”-Unterfenster zur Anzeige eines Gastes über Spice bietet einem dankenswerterweise einen Menüpunkt “Send Key” an, mit dessen Hilfe man Steuersequenzen wie Ctrl-Alt-F1 auch an den KVM-Gast schicken kann. So gelangt man dann u.a zu den Gast-Konsolen-TTYs “tty1” bis tty6. Um deren Auflösung von 800×600 auf vernünftige Werte abzuändern, muss der Framebuffer-Support des Hypervisors beeinflusst werden. Dies ist unter Debian 8 über Grub-Einstellungen möglich.

Hierzu editiert man mit Root-Rechten die Datei “/etc/default/grub” bzgl. zweier Zeilen (eine davon ist auszukommentieren):

GRUB_GFXMODE=1920x1080x32
GRUB_GFXPAYLOAD_LINUX=keep

Natürlich kann man auch eine andere definierte Standard-Auflösung als die für meinen Fall angegebene wählen.

Danach ist nach einem unten angegebenen Link nur noch das Absetzen eines “update-grub” (erfordert Root-Rechte) nötig. Und tatsächlich: Nach einem Reboot wiesen meine TTYs die gewünschte Konsolenauflösung auf.

Was kann man bei einem Wechsel von QXL zu “virtio” tun?

Wie gesagt, bietet die unter Opensuse Leap 42.2 verfügbare KVM-Implementierung die Möglichkeit an, für das Video-Device eines KVM-Gastes “virtio” statt QXL (oder weit weniger leistungsfähigen Treibern) zu wählen.

Welche Folgen hat ein Wechsel zu dieser Darstellungsart, bei der direkt auf die Host-HW zugegriffen wird?
Auf meinem System bislang keinerlei offenkundig negativen. Das Zeichnen der einzelnen Gnome-Fenster auf dem Gastdesktop geht bei sehr schnellen Bewegungen dieser Fenster über die Fläche des Gastdesktops gefühlt noch etwas flüssiger
als beim Einsatz von QXL. Das ganze grafische Verhalten des Gastes im “virt-manager”-Fenster ist danach so gut, dass man auch bei höchster Auflösung von der 2D-Grafik her praktisch keinen Unterschied zur Arbeit auf einem nativen System mehr merkt. Das ist wirklich beeindruckend gut!

Einen Wehrmutstropfen muss man als Standard-User unter Debian 8 (mit Kernel 3.16) aber dennoch hinnehmen:

Unter den “Gnome-Einstellungen=>Monitore” lässt sich die Auflösung nicht mehr dynamisch wie im Fall von QXL ändern. Für das Einblenden des grafischen Gast-Outputs in den Speicherbereich der realen Graka zählt unter Debian 8 offenbar allein die Auflösung, die man wie oben beschrieben für die Unterstützung des virtuellen Gast-Framebuffers durch den Hypervisor eingestellt hat.

Immerhin steht einem dadurch aber eine Einstellmöglichkeit zur Verfügung – wenn auch keine dynamische! Damit kann ich aber gut leben; wenn ich jemals eine dynamische Änderung des Gnome-Desktops eines KVM-Gastes brauchen sollte, verwende ich halt “qxl”.

Nachtrag, 29.06.2017:
Faktisch gilt die obige festgestellte Einschränkung für Debian 8 nur für Kernel 3.X. Mindestens ab Kernel 4.9 bietet der virtio-Treiber eine ganze Liste an Auflösungen an, aus denen man wählen kann. Siehe hierzu den Artikel

KVM, video virtio, Debian 8 guest, host with Intel HD 4000 – install a 4.9 kernel on the guest for optimal 2D graphics performance!

Nachtrag, 03.07.2017:
Ein User hat mich angeschrieben und zu Recht angemerkt, dass die im Gastsystem angebotenen Auflösungen unter “qxl” nicht immer an die Maximal-Auflösung der Schirme des Hosts heranreichen. Auf die Frage, was man dann tun kann, gehe ich gerne in einem weiteren Artikel ein. Sobald ich Zeit finde, den zu schreiben … Den entsprechenden Link werde ich dann hier nachtragen. Der Schlüssel liegt dabei vor allem in der Nutzung von “xrandr”. Bei der Gelegenheit gehe ich dann auch kurz auf das Thema von mehreren “virtuellen” Monitoren unter qxl ein.

Skalierung des Fensterinhaltes

Hingewiesen sei auch darauf, dass sich die Darstellung das gesamte Fenster zur Darstellung des KVM/Qemu-Gastes, das man vom virt-manager aus geöffnet hat, bei entsprechender Einstellung unter dem Menüpunkt “View” dynamisch skalieren lässt.

Auch das geht sehr flüssig und verzögerungsfrei!

Viel Freude weiterhin mit Linux und KVM/Qemu!

Links

https://superuser.com/questions/598374/how-to-change-the-resolution-of-the-bash-for-a-debian-vm

ufw auf Strato-vServern mit Debian 8 – fehlende iptables Log-Meldungen im systemd-Journal – rsyslogd

Posted on by

Gestern hatte ich das Vergnügen, ein Debian-Server-System auf einer aktuellen vServer-Plattform bei Strato einzurichten. Ich bereite entsprechende Arbeiten in der Regel vor, indem ich elementare Konfigurationsschritte – im Besonderen solche, die sicherheitsrelevant sind – vorab auf einem ähnlichen KVM-Gast-System in unserem Hausnetz simuliere und teste.

Diese Art von vorbereitenden Tests hat jedoch ihre Grenzen; nicht alles ist vergleichbar. Gestern bin ich mal wieder auf einen Unterschied im Zusammenhang mit iptables, ufw und den zugehörigen LOG-Meldungen unter systemd gestoßen. Letztere fehlten nämlich im systemd-Journal des Strato-vServers völlig.

Da fragt man sich schon, wie man denn unter solchen Voraussetzungen das gehostete System bzgl. von Angriffsmustern monitoren soll. Ich finde, diese Frage ist so relevant, dass sie sich auch andere Strato-Kunden besser vor dem Mieten eines vServers beantworten sollten. Deshalb dieser Post. Die gute Nachricht ist: Es gibt unabhängig von den Ursachen für das Fehlen der LOG-Meldungen einen Workaround.

Die schlechte Nachricht ist: Die Ursache der fehlenden Kernel-Meldungen im systemd-Journal ist unklar; zumindest mir. Auf einem KVM-Host funktioniert alles wie erwartet. Unterschiede zu gehosteten Servern sind meist auf einen anderen Ansatz in der Virtualisierung zurückzuführen (Stichwort: Container-Technologie vs. Hypervisor für Full/Para-Virtualisierung).

In diesem Falle erscheint mir das aber als Erklärungsansatz nicht plausibel und hinreichend. Ich gehe nachfolgend auf die Gründe etwas genauer ein. Zudem ist bei Debian 8 (leider) eben auch systemd in den Logging-Prozess involviert. Defizite von “systemd” in der Interaktion mit bestimmten Virtualisierungsumgebungen halte ich für durchaus möglich. Der Irrwitz, dass ein Programm beim Systemstart die Umgebung analysieren und für jeden Fall die richtige Antwort ziehen muss, hat halt seinen Preis …

ufw, netfilter/iptables und das Logging-Problem

Ich bin eigentlich ein Freund von Firewall-Builder (FWB). Für Debian-Systeme verwende ich aber auch “ufw“, um initial die wichtigsten Paketfilter-Regeln, also iptables-Anweisungen, bequem und zeitsparend aufzusetzen. Die drehen sich zunächst um den SSH-Zugang von außen und die Erlaubnis, dass der gehostete Server DNS-Server, NTP-Server und bestimmte Update-Server kontaktieren darf. Auch “pings” und “traceroute” vom Server nach außen erlaube ich. Alles andere wird von mir anfänglich rigoros geblockt. Später wird dann für die angestrebten Services des Servers gezielt nachgearbeitet. (Off topic: Viele Dienste, die mein Kunde benötigt, tunnele ich auf dem Server über eine SSH-Verbindung; ein direkter SSH-Zugang des Users root wird sowieso unterbunden und der SSH-Port verschoben.)

Anfänglich ist hinsichtlich eines minimalen Regelsatzes gar nicht viel zu tun. Im Anschluss an das Etablieren der ersten Paketfilter-Regeln möchte ich gerne die Arbeit von “netfilter” testen und das zugehörige Logging mitverfolgen. Typischerweise lasse ich dann “nmap” von außen auf das gehostete System los. Für einen Test des Serverzugriffs auf externe DNS-Dienste und Zugriffe auf Update-Server tut es dagegen “apt-get”. In beiden Fällen verfolge ich per SSH auf einem (Remote-) Terminal den Strom der Meldungen der (ufw-)”Firewall”.

Das erhoffte Verfolgen der iptables-Log-Meldungen schlug auf dem Strato-vServer mit installiertem Debian 8 aber fehl.

Debian 8.x nutzt wie gesagt systemd. Ufw schreibt die iptables-Log-Daten mit eigenen Zusätzen in das Log-System des Servers – bei einem systemd-basierten Systemen also in das dortige binäre Journal. Das systemd-Journal fängt im Normalfall neben System-Meldungen und Meldungen aus dem Userspace auch Kernel-Messages auf. Da systemd den gesamten Mix aus Messages in ein
binäres Datenformat in einer Datei überführt, muss man das Kommando “journalctl” mit geeigneten Filtern bzw. der Option “-f -nxxx” benutzen, um Log-Einträge auswerten bzw. direkt am Schirm mitverfolgen zu können.

Gesagt, getan. Leider tauchen auf einem Strato-vServer im Journal von “systemd” generell nur sehr wenig Informationen auf; hinsichtlich der Paketfilter-LOG-Meldungen findet man dort jedoch leider gar nichts.

Das iptables-Target “LOG” mündet auf einem mit “rsyslogd” ausgestatteten Log- und Warnsystem dagegen in Meldungen in der Datei “/var/log/kern.log” – schließlich handelt es sich ja um Kernel-Meldungen.

Die aus meiner Sicht schon immer kritikwürdige Idee, alle systemrelevanten Meldungen an einer Stelle in einem Binärformat zu sammeln, wird uns auf einem Strato vServer nun offenbar zum Verhängnis: Nur mit systemd können wir kleine und große externe Zugriffsversuche auf einen vServer offenbar nicht überwachen!

Ich bin übrigens nicht der Einzige, der dieses Problem hatte; siehe:
http://linux.debian.user.german.narkive.com/8AbyxJTP/keine-eintrage-von-dmesg-im-journal-systemd
Erstaunlich ist dennoch, dass man ansonsten im Internet fast nichts zu dieser Thematik findet.

Ob das Problem nun etwas mit systemd-Defiziten oder einer speziellen Konfiguration der systemd-Interaktion mit der Virtualisierungsumgebung bei Strato zu tun hat, muss man natürlich ein wenig austesten.

Firewall-Logging, Virtualisierung und Container

Tatsächlich erweist sich das Verhalten von Debian 8 mit “ufw” auf einem KVM-Gastsystem als gänzlich anders. Hier ein Auszug der ufw-Meldungen von einem KVM-Gast mit Debian 8, die mittels des Befehls

“journalctl -f -n20”

zur Anzeige gebracht wurden: 

Apr 05 16:05:52 deb11 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=52:54:00:d5:4a:9b:52:54:00:fc:27:c5:08:00 SRC=192.168.10.1 DST=192.168.10.11 LEN=44 TOS=0x00 PREC=0x00 TTL=54 ID=25556 PROTO=TCP SPT=64358 DPT=110 WINDOW=1024 RES=0x00 SYN URGP=0 
Apr 05 16:05:52 deb11 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=52:54:00:d5:4a:9b:52:54:00:fc:27:c5:08:00 SRC=192.168.10.1 DST=192.168.10.11 LEN=44 TOS=0x00 PREC=0x00 TTL=59 ID=47868 PROTO=TCP SPT=64358 DPT=135 WINDOW=1024 RES=0x00 SYN URGP=0 
Apr 05 16:05:52 deb11 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=52:54:00:d5:4a:9b:52:54:00:fc:27:c5:08:00 SRC=192.168.10.1 DST=192.168.10.11 LEN=44 TOS=0x00 PREC=0x00 TTL=45 ID=41401 PROTO=TCP SPT=64358 DPT=53 WINDOW=1024 RES=0x00 SYN URGP=0 
Apr 05 16:05:52 deb11 kernel: [UFW ALLOW] IN=eth0 OUT= MAC=52:54:00:d5:4a:9b:52:54:00:fc:27:c5:08:00 SRC=192.168.10.1 DST=192.168.10.11 LEN=44 TOS=0x00 PREC=0x00 TTL=42 ID=10106 PROTO=TCP SPT=64358 DPT=22 WINDOW=1024 RES=0x00 SYN URGP=0 
Apr 05 16:05:52 deb11 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=52:54:00:d5:4a:9b:52:54:00:fc:27:c5:08:00 SRC=192.168.10.1 DST=192.168.10.11 LEN=44 TOS=0x00 PREC=0x00 TTL=54 ID=65381 PROTO=TCP SPT=64358 DPT=113 WINDOW=1024 RES=0x00 SYN URGP=0 
Apr 05 16:05:52 deb11 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=52:54:00:d5:4a:9b:52:54:00:fc:27:c5:08:00 SRC=192.168.10.1 DST=192.168.10.11 LEN=44 TOS=0x00 PREC=0x00 TTL=47 ID=1758 PROTO=TCP SPT=64358 DPT=587 WINDOW=1024 RES=0x00 SYN URGP=0 
Apr 05 16:05:52 deb11 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=52:54:00:d5:4a:9b:52:54:00:fc:27:c5:08:00 SRC=192.168.10.1 DST=192.168.10.11 LEN=44 TOS=0x00 PREC=0x00 TTL=47 ID=22236 PROTO=TCP SPT=64358 DPT=443 WINDOW=1024 RES=0x00 SYN URGP=0 
Apr 05 16:05:52 deb11 kernel: [UFW BLOCK] IN=eth0 OUT= MAC=52:54:00:d5:4a:9b:52:54:00:fc:27:c5:08:00 SRC=192.168.10.1 DST=192.168.10.11 LEN=44 TOS=0x00 PREC=0x00 TTL=55 ID=60478 PROTO=TCP SPT=64358 DPT=23 WINDOW=1024 RES=0x00 SYN URGP=0 
Apr 
05 16:05:52 deb11 kernel: [UFW BLOCK] IN=eth0 OUT=

 
Offensichtlich führt im obigen Fall das System 192.168.10.1 einen Portscan auf dem betroffenen KVM-Host mit der IP 192.168.10.11 durch.

Ähnliche Meldungen erhält man bei einem Portscan auf einem vServer aber – wie gesagt – nicht.

Wie könnte man das erklären?
Ein naheliegender Erklärungsansatz wäre etwa folgender:
Das Logging von Kernel-Messages klappt auf einem KVM-Gast, also unter dem QEMU-Hypervisor (sog. Typ 2 Hypervisor), der über “virtio” auf dem Host nur partiell Paravirtualisierung und keine Container-Technologie einsetzt, natürlich problemfrei. Das Betriebssystem des KVM-Gastes und dessen Kernel arbeiten ja weitgehend autonom und greifen nur über Vermittlungsschichten auf den Kernel des Hosts und dessen HW-Unterstützung zu. Es besteht von Haus aus kein Problem bzgl. des Loggings von Kernel-Meldungen – sie beziehen sich immer auf den Kernel des Gastsystems.

Dagegen setzt Strato Container-Technologie ein – genauer VZ-Container unter Virtuozzo; selbiges basiert auf OpenVZ. Zu Grundeigenschaften siehe :
https://openvz.org/Main_Page und https://openvz.org/Features

Es handelt sich bei Strato wohl um Version 4.7 oder eine frühe 6er Version von “Virtuozzo Containers”. Dafür gibt es Indizien (u.a, dass sich Docker nicht installieren lässt); um einen genauen Nachweis habe ich mich aber (noch) nicht gekümmert. Ist auch egal.

In einer Container-Lösung wird jedenfalls die Kapazität und Funktionalität des Host-Kernels zwischen den Containern, die keinen eigenen Kernel besitzen, geteilt (schlanker “Single-Kernel-Approach”). Der Zugriff auf Netze erfolgt über eine entsprechende Netzwerk- und Schnittstellen-Virtualisierung. Typischerweise werden virtuelle venet- oder veth-NICs eingesetzt; je nachdem, auf welcher Ebene OSI-Stacks man arbeiten will. (veth-NICs setze ich selbst vielfach auch in komplexeren KVM/Qemu-Umgebungen bei der Netzwerkvirtualisierung ein.)

Die notwendige Separation der Container und ihrer Netzwerk-Kommunikation gegeneinander und gegenüber dem Host muss vom Host-Kernel bzw. dessen Modulen auf der Basis von Konfigurationsvorgaben für unpriviligierte Container (in ihren separaten Namespaces und bei modernen Ansätzen ggf. in cGroups) gewährleistet werden. Man wird den Container-Systemen jedenfalls nicht erlauben, alles einzusehen, was auf dem für alle zuständigen Host-Kernel abläuft. Dies bedeutet u.a., dass Containersysteme nicht beliebige Kernel-Module (z.B. für Packettracking unter Wireshark) laden dürfen.

Wer “iptables” im Zusammenhang mit Virtualisierungshosts aber ein wenig genauer kennt, kann sich vorstellen, dass man eine Host-Firewall natürlich immer so konfigurieren kann, dass die einzelnen virtuellen Netzwerkschnittstellen der (Container-) Gäste gegeneinander geblockt werden, aber dass generelle Forward-Regeln für physikalische Interfaces des Hosts nicht in Konflikt mit speziellen Filter-Regeln für ein spezifisches (virtuelles) Gast-Interface geraten müssen.

OpenVZ kann man deshalb sehr wohl so einrichten, dass der Admin eines Container-Systems seine eigenen iptables-Regeln für seine gastspezifischen NICs definieren kann. Siehe hierzu z.B.:
https://openvz.org/Setting_up_an_iptables_firewall.

Wesentliche Teile der verschiedenen netfilter-Module – im Besonderen für die Schicht 3 – stehen also auch Gästen zur Verfügung. Voraussetzung ist in einer Container-Architektur natürlich, dass grundlegende “netfilter”-Module auf dem OpenVZ-Host selbst geladen wurden.

Aber: Es wäre fahrlässig, wenn ein Container-Host alle netzwerkspezifischen Kernel-Meldungen (darunter iptables-Meldungen) auch für die Einsichtnahme durch die root-User der Container preisgeben würde. Das würde u.a ein
Ausspionieren der virtuellen Netzwerkumgebung und darauf aufbauend bestimmte Angriffsszenarien ermöglichen. Wenn wir überhaupt etwas im Container sehen, dann höchstens Meldungen zu selbst gesetzten Paketfilterregeln für die Container-spezifische NIC.

Zwischenfazit:

  • Wir dürfen uns in einer Container-Umgebung u.a. nicht darüber wundern, dass man bestimmte Kernel-Module vom Container aus erst gar nicht laden darf und z.B. lsmod eine vernünftige Antwort schuldig bleibt.
  • Wir dürfen uns nicht wundern, dass bestimmte sysctl-Befehle, die im Container abgesetzt werden, ggf. ignoriert werden.
  • Wir dürfen uns in einer Container-Umgebung nicht wundern, wenn man bestimmte Teile des systemd-Logs auf einem Container – und damit auf einem Strato-V-Server – nicht ggf. zu Gesicht bekommt. (Im Gegensatz zu einem KVM-Gast).

Der erste Punkt ist u.a. für den Betrieb der ufw relevant; s.u..

Bzgl. des zweiten Punktes ist zu beachten, dass OpenVZ, genauer der OpenVZ-Kernel, (network-) “Namespaces” nutzt. (“Namespaces” werden natürlich aber auch von aktuellen Linux-Kerneln unterstützt. Zu “Namespaces” siehe etwa
https://jvns.ca/blog/2016/10/10/what-even-is-a-container/
https://de.slideshare.net/jpetazzo/anatomy-of-a-container-namespaces-cgroups-some-filesystem-magic-linuxcon
https://openvz.org/WP/What_are_containers.

Deshalb lassen sich bestimmte Einstellung unterhalb von “/proc/sys” durchaus auch vom Container aus anpassen. Was in der jeweiligen OpenVZ-Umgebung erlaubt ist und was nicht, muss man ggf. durch Probieren herausfinden.

Den dritten Punkt werden wir in den nächsten Abschnitten für vServer kritisch hinterfragen.

Erste Konsequenzen für den Einsatz von “ufw”

Auch durch Probieren wird man herausfinden, dass “ufw” auch auf einem mit Debian 8 betriebenen vServer von Strato läuft – und man eigene iptables-Regeln problemfrei an den OpenVZ-Kernel weiterreichen kann.

Achtung:

Nach der Installation von ufw auf dem vServer NICHT unmittelbar “ufw enable” absetzen!! Zuerst den Port, auf dem man SSH betreibt, freischalten. Also etwa durch “ufw allow 22”, wenn man den SSH-Standardport benutzt. Ihr wollt euch ja nicht durch Anschalten der Firewall selbst aussperren!

Wie man schnell (hier durch einen Blick in das systemd-Journal feststellt), ist der Start von ufw auf einem vServer – auch im Rahmen eines Systemstarts – mit ein paar Fehlermeldungen verbunden. 

Apr 05 14:21:03 xxx.stratoserver.net ufw[147]: Starting firewall: ufw...modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not ope
Apr 05 14:21:03 xxx.stratoserver.net ufw[147]: modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modul
Apr 05 14:21:03 xxx.stratoserver.net ufw[147]: modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modul
Apr 05 14:21:03 xxx.stratoserver.net systemd-journal[114]: Permanent journal is using 24.0M (max allowed 4.0G, trying to leave 4.0G free of 499.5G a
Apr 05 14:21:03 xxx.stratoserver.net systemd-journal[114]: Time spent on flushing to /var is 1.770ms for 8 entries.
Apr 05 14:21:03 xxx.stratoserver.net ufw[147]: sysctl: permission denied on key 'net.ipv4.tcp_sack'
Apr 05 14:21:03 xxx.stratoserver.net ufw[147]: Setting kernel variables (/etc/ufw/sysctl.conf)...done.

r
 
Diese Meldungen rühren u.a. daher, dass ufw mit Hilfe von modprobe versucht, bestimmte “conntrack”-Sub-Module zu laden. Zudem versucht ufw per sysctl Kernel-Parameter abzuändern. Vorgegeben sind diese Schritte in den Dateien “/etc/default/ufw” und “/etc/ufw/sysctl.conf“.

Die genannten Fehler blockieren den Start aktueller ufw-Versionen aber nicht; wer sich dennoch an den Meldungen stört, kann die über Modifikationen der genannten Dateien, nämlich durch Auskommentieren der fehlerträchtigen Statements, verhindern. Siehe auch
https://www.hosteurope.de/faq/server/virtual-server/besonderheiten-firewall-virtual-server/; im Unterschied zu den dortigen Tipps aber beachten, dass auf dem vServer nur einer der sysctl-Befehle problematisch ist.)

Übrigens: Über das Starten von ufw bei einem Reboot des vServers muss man sich nach einem Absetzen von

systemctl enable ufw

keine Gedanken mehr machen. Debian 8 beinhaltet für ufw einen passenden LSB-Service, der beim Hochfahren ausgeführt wird.

Monitoring von ufw-iptables-Meldungen auf dem vServer mit Hilfe von dmesg

Nachdem man in systemd-Journal nichts findet: Gibt es andere Möglichkeiten, die LOG-Messages von ufw-/iptables zu verfolgen?

Da es sich um Kernel-Messages handelt, liegt ein versuchsweiser Blick auf den “dmesg”-Output nahe. Und tatsächlich – auf meinem vServer: 

    
root@xxx:~ # dmesg
[1240949.664984] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=45.55.2.201 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=40788 DPT=3306 WINDOW=65535 RES=0x00 SYN URGP=0 
[1240954.051018] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=93.174.93.136 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=250 ID=4710 PROTO=TCP SPT=43745 DPT=3128 WINDOW=1024 RES=0x00 SYN URGP=0 
[1240986.448807] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=45.55.1.72 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=46822 DPT=1900 WINDOW=65535 RES=0x00 SYN URGP=0 
[1241002.495868] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=88.100.184.82 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=13380 PROTO=TCP SPT=35180 DPT=23 WINDOW=44554 RES=0x00 SYN URGP=0 
[1241015.141452] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.163.144.224 DST=xxx LEN=445 TOS=0x00 PREC=0x00 TTL=57 ID=32820 DF PROTO=UDP SPT=5180 DPT=5046 LEN=425 
[1241132.233004] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=197.44.69.222 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=239 ID=44476 PROTO=TCP SPT=53226 DPT=1433 WINDOW=1024 RES=0x00 SYN URGP=0 
[1241145.520318] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=208.100.26.228 DST=xxx LEN=40 TOS=0x08 PREC=0x00 TTL=242 ID=51210 PROTO=TCP SPT=47975 DPT=15672 WINDOW=1024 RES=0x00 SYN URGP=0 
[1241185.158299] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.163.144.224 DST=xxx LEN=443 TOS=0x00 PREC=0x00 TTL=57 ID=56812 DF PROTO=UDP SPT=5400 DPT=4000 LEN=423 
[1241297.661764] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=186.45.130.20 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=241 ID=12134 PROTO=TCP SPT=63715 DPT=23 WINDOW=14600 RES=0x00 SYN URGP=0 
[1241350.742715] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.163.144.224 DST=xxx LEN=446 TOS=0x00 PREC=0x00 TTL=57 ID=14769 DF PROTO=UDP SPT=5320 DPT=5172 LEN=426 
[1241353.098569] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=5.53.113.195 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=48667 PROTO=TCP SPT=46919 DPT=23 WINDOW=39535 RES=0x00 SYN URGP=0 
[1241377.620483] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=46.152.41.83 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=40038 PROTO=TCP SPT=12600 DPT=23 WINDOW=14600 RES=0x00 SYN URGP=0 
[1241386.187457] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=122.114.187.140 DST=xxx LEN=40 TOS=0x00 
PREC=0x00 TTL=238 ID=8477 PROTO=TCP SPT=46170 DPT=23 WINDOW=1024 RES=0x00 SYN URGP=0 
[1241437.193431] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=218.91.210.142 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=4557 PROTO=TCP SPT=45821 DPT=23 WINDOW=27541 RES=0x00 SYN URGP=0 
[1241512.054090] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.163.144.224 DST=xxx LEN=443 TOS=0x00 PREC=0x00 TTL=57 ID=37720 DF PROTO=UDP SPT=5179 DPT=1028 LEN=423 
[1241553.246515] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=49.4.143.59 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=104 ID=256 PROTO=TCP SPT=6000 DPT=135 WINDOW=16384 RES=0x00 SYN URGP=0 
[1241632.706391] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=39.71.216.3 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=4841 PROTO=TCP SPT=57398 DPT=22 WINDOW=55725 RES=0x00 SYN URGP=0 
[1241643.559480] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=196.202.5.43 DST=xxx LEN=44 TOS=0x00 PREC=0x00 TTL=48 ID=53691 PROTO=TCP SPT=34866 DPT=23 WINDOW=33710 RES=0x00 SYN URGP=0 
[1241674.241572] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.163.144.224 DST=xxx LEN=446 TOS=0x00 PREC=0x00 TTL=57 ID=60393 DF PROTO=UDP SPT=5288 DPT=1029 LEN=426 
[1241683.411659] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=124.167.232.138 DST=xxx LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=40536 DF PROTO=TCP SPT=57844 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 
[1241686.407572] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=124.167.232.138 DST=xxx LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=40537 DF PROTO=TCP SPT=57844 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0

 
Ja, die Welt ist schlecht – und wir tun offenbar gut daran, den Zugang zum Server zu blocken bzw. die Logs auch mal auszuwerten und später Blacklists einzusetzen. “fail2ban” zu konfigurieren schadet nebenbei auch nichts.

Wer periodische Updates des Outputs von dmesg ähnlich zu “tail -f” verfolgen will, probiere mal das Kommando

watch -n 0,2 “dmesg | tail -n $((LINES-6))”

in einem Terminal aus. (Ggf. das Terminalfenster etwas vergößern. Auf englischsprachigen Systemen “0.2” statt wie hier “0,2” ! Auf neueren Kerneln als dem der aktuellen vServer gibt es übrigens auch die dmesg-Option “-w”).

Aber das eigentlich Feststellenswerte ist ja, dass wir überhaupt was sehen!

Natürlich ist das, was man unter OpenVZ unter dmesg zu Gesicht bekommt, eingeschränkt (s. etwa https://bugs.openvz.org/browse/OVZ-5328).
Aber:
Der OpenVZ-Kernel liefert dem Container zulässige, relevante Informationen in den lokalen Message-Ringpuffer, die dort von root eingesehen werden können. Darunter auch die ersehnten iptables-Meldungen!

Nun stellt sich die große Frage, wie systemd mit diesen Kernelmeldungen interagiert und warum das, was unter dmesg erschient, nicht ins Journal der OpenVZ-Container-Umgebung eingestellt wird.

Das Problematische an systemd ist, wie immer, dass man das ohne seitenweises Lesen in systemd Blogs etc. und/oder gar Codestudium vermutlich nicht beantworten kann. Logisch erscheint mir das Ganze jedenfalls nicht. OpenVZ sorgt offenbar für eine Reduktion der Kernelinformationen auf das, was root im Container sehen sollte. iptables-Meldungen zur lokalen NIC des Containers werden dabei nicht ausgespart. Sie sollten daher eigentlich auch im systemd-Journal erscheinen!

Monitoring mittels rsyslogd ? !

Durch den dmesg-Test ermutigt, fragte ich mich, was wohl passieren würde, wenn rsyslog auf dem vServer-Debian-System installiert und aktiviert wäre. Das ist insofern interessant, als systemd ja externe Linux System-Logging-Services über Schnittstellen bedient und trotzdem sein eigenes Journal weiter versorgt. Man loggt dann im Normalfall sozusagen zweimal …

Eigentlich würde man nun erwarten, dass die Meldungen von dmesg auch in den verschiedenen Dateien, die der rsyslog-Dämon bedient, nicht auftauchen sollten. Weil systemd ja schon den
Transfer in die eigene Binärdatei verweigert. Also machen wir mal die Probe:

root@xxx:~# apt-get rsyslog
root@xxx:~# systemctl start rsyslog
root@xxx:~# systemctl enable rsyslog

Wenn nun doch etwas passieren sollte, so müssten iptables-Meldungen als Einträge unter “/var/log/kern.log” und/oder in der von ufw vorgesehenen Datei “/var/log/ufw.log” auftauchen.

Und tatsächlich finden wir (wider Erwarten) nach einer Weile in “kern.log” iptables-LOG-Meldungen: 

  
Apr  6 13:19:57 xxx kernel: [1245761.082097] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=118.163.90.134 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=14764 PROTO=TCP SPT=33202 DPT=23 WINDOW=44186 RES=0x00 SYN URGP=0 
Apr  6 13:21:03 xxx kernel: [1245827.018789] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=85.90.163.248 DST=xxx LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=358 PROTO=TCP SPT=21965 DPT=23 WINDOW=12453 RES=0x00 SYN URGP=0 
Apr  6 13:21:16 xxx kernel: [1245840.027789] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.163.144.224 DST=xxx LEN=445 TOS=0x00 PREC=0x00 TTL=57 ID=61654 DF PROTO=UDP SPT=5201 DPT=4011 LEN=425 
Apr  6 13:22:26 xxx kernel: [1245910.326051] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=91.98.36.115 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=3739 PROTO=TCP SPT=31242 DPT=23 WINDOW=22306 RES=0x00 SYN URGP=0 
Apr  6 13:23:13 xxx kernel: [1245957.077099] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=117.193.182.117 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=29137 PROTO=TCP SPT=12209 DPT=22 WINDOW=52845 RES=0x00 SYN URGP=0 
Apr  6 13:23:54 xxx kernel: [1245997.536218] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=45.55.1.114 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=43185 DPT=8123 WINDOW=65535 RES=0x00 SYN URGP=0 
Apr  6 13:23:56 xxx kernel: [1246000.108495] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=192.151.169.29 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=46742 PROTO=TCP SPT=54014 DPT=23 WINDOW=49390 RES=0x00 SYN URGP=0 
Apr  6 13:24:05 xxx kernel: [1246008.982092] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.163.144.224 DST=xxx LEN=445 TOS=0x00 PREC=0x00 TTL=57 ID=19866 DF PROTO=UDP SPT=5391 DPT=4012 LEN=425 
Apr  6 13:24:08 xxx kernel: [1246011.450635] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=163.172.204.214 DST=xxx LEN=447 TOS=0x00 PREC=0x00 TTL=58 ID=25411 DF PROTO=UDP SPT=5440 DPT=5060 LEN=427 
Apr  6 13:24:18 xxx kernel: [1246022.133966] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=181.193.99.26 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=47683 PROTO=TCP SPT=36520 DPT=23 WINDOW=41856 RES=0x00 SYN URGP=0 
Apr  6 13:24:29 xxx kernel: [1246032.599018] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.248.166.146 DST=xxx LEN=48 TOS=0x00 PREC=0x00 TTL=123 ID=26103 PROTO=TCP SPT=11206 DPT=2083 WINDOW=65535 RES=0x00 SYN URGP=0 
Apr  6 13:24:50 xxx kernel: [1246053.507827] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=71.165.26.106 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=381 PROTO=TCP SPT=29725 DPT=23 WINDOW=3178 RES=0x00 SYN URGP=0 
Apr  6 13:25:44 xxx kernel: [1246108.065452] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=139.162.118.251 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=246 ID=54321 PROTO=TCP SPT=56219 DPT=6379 WINDOW=65535 RES=0x00 SYN URGP=0 
Apr  6 13:26:16 xxx kernel: [1246139.839711] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=174.16.249.159 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=54734 PROTO=TCP SPT=43074 DPT=23 WINDOW=14600 RES=0x00 SYN URGP=0 
Apr  6 13:26:28 xxx kernel: [1246151.805797] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=117.1.220.212 DST=xxx LEN=44 TOS=0x00 PREC=0x00 TTL=242 ID=2085 PROTO=TCP SPT=14216 DPT=5358 WINDOW=14600 RES=0x00 SYN URGP=0 
Apr  6 13:26:50 xxx kernel: [1246174.013725] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=123.151.42.61 DST=xxx LEN=135 TOS=0x00 PREC=0x00 TTL=47 ID=32696 PROTO=UDP SPT=9019 DPT=1701 LEN=115 
Apr  6 13:27:01 xxx kernel: [1246184.993843] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.163.144.224 DST=xxx LEN=445 TOS=0x00 
PREC=0x00 TTL=57 ID=44551 DF PROTO=UDP SPT=5365 DPT=4013 LEN=425 
Apr  6 13:27:27 xxx kernel: [1246211.300971] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=89.120.177.89 DST=xxx LEN=44 TOS=0x00 PREC=0x00 TTL=55 ID=64605 PROTO=TCP SPT=59589 DPT=23 WINDOW=64213 RES=0x00 SYN URGP=0

 
Die Welt ist inzwischen nicht besser geworden, aber nun können wir das Schlechte wenigstens mal verfolgen. (Dieselben Einträge erscheinen übrigens auch in ufw.log).

Tja, nicht alles im Leben mit systemd ist offenbar nachvollziehbar ….

Fazit

Das erwartete native Zusammenspiel zwischen einem Strato OpenVZ vServer und systemd unter Debian 8 funktioniert bzgl. der Protokollierung der LOG-Target-Meldungen von iptables nicht. Kernel-Meldungen zu iptables-Rules für die Container-NIC erschienen nicht im Journal von systemd.

Workarounds bestehen darin

  • den Output von dmesg kontinuierlich per Skript abzufragen und in eine Datei umzulenken.
  • rsyslog zu installieren und die Arbeit dem Zusammenspiel von systemd mit dem rsyslog-Dämon zu überlassen. Man protokolliert dann doppelt, aber man erhält wenigstens dauerhafte Log-Protokolle, die jeder sicherheitsbewußte Admin zur vorsorglichen Gefahrenabwehr benötigt.

Da die gewünschten Kernel-Meldungen bei gleicher Debian- und Systemd-Version in einem KVM-Gast erscheinen, ist das Problem mit dem systemd-Journal entweder

  • auf einen Fehler oder ein Sicherheitsfeature der OpenVZ-Umgebung,
  • oder auf ein seltsames (gewolltes oder fehlerhaftes) Zusammenspiel des OpenVZ-Kernels mit systemd in den Container-Umgebungen,
  • oder schlicht auf ein fehlerhaftes, bislang nicht erkanntes/bedachtes Verhalten von systemd in einem OpenVZ-Container

zurückzuführen.

Für letzteres spricht die Tatsache, dass der OpenVZ-Kernel iptables-Meldungen zur Container-NIC unter dmesg offenbart und dass systemd die Meldungen, die unter dmesg auftauchen wohl korrekt an weitere System-Logging-Services wie rsyslog weiterleitet.

Eine entsprechende Anfrage bei Strato, die hoffentlich Virtuozzo einschalten, läuft.

Das Fehlen von iptables-Log-Protokolle ist im Sinne der ISO 27000 (Strato hat da ein Zertifikat!) zudem als Sicherheitsproblem einzustufen, das Kunden kommentarlos zugemutet wird und von diesen Kunden selbst gelöst werden muss.

Weiterführende Links

Fehlende Einträge im systemd-Journal
http://linux.debian.user.german.narkive.com/8AbyxJTP/keine-eintrage-von-dmesg-im-journal-systemd

Container, Virtuozzo, OpenVZ und iptables, ufw
http://forum.openvirtuozzo.org/index.php?t=msg&goto=37264&&srch=container
https://openvz.org/Setting_up_an_iptables_firewall
http://askubuntu.com/questions/399624/ubuntu-server-12-04-and-ufw-failure-on-startup-and-several-module-not-found-err
https://www.hosteurope.de/faq/server/virtual-server/besonderheiten-firewall-virtual-server/
https://superuser.com/questions/659236/permission-denied-when-setting-values-in-sysctl-on-ubuntu-12-04
https://help.
ubuntu.com/community/UFW
https://help.virtuozzo.com/customer/en/portal/articles/2509437?_ga=1.206607316.635252319.1491384754
ab S. 317 in folgender Referenz
http://www.odin.com/fileadmin/parallels/documents/hosting-cloud-enablement/pvc/Production_Documents/VzLinuxUG_03132013.pdf
https://bugs.openvz.org/browse/OVZ-5328

Namespaces
http://www.netdevconf.org/1.1/proceedings/slides/rosen-namespaces-cgroups-lxc.pdf

LXC vs. OpenVZ
https://www.janoszen.com/2013/01/22/lxc-vs-openvz/
https://en.wikipedia.org/wiki/LXC
https://openvz.org/Comparison

OpenVZ integrates KVM/Qemu
http://openvz.livejournal.com/tag/criu
https://www.heise.de/ix/meldung/Virtualisierungsplattform-OpenVZ-wird-eigenstaendige-Distribution-3278115.html
https://openvz.org/Virtuozzo
https://openvz.org/QEMU
https://www.heise.de/ix/meldung/Virtualisierungsplattform-OpenVZ-wird-eigenstaendige-Distribution-3278115.html
https://openvz.org/FAQ
https://virtuozzo.com/virtual-machines-in-virtuozzo-7/
https://openvz.org/WP/What_are_containers#Networking

Virtualisierungsangebote in D – Vergleich
https://timreeves.de/trip-content/uploads/dokumente/Internet-Mietserver-Typen_im-Vergleich.pdf

Watch dmesg Output
http://unix.stackexchange.com/questions/95842/how-can-i-see-dmesg-output-as-it-changes