Teamviewer 13 funtzt unter Wayland nicht sauber

Wie wir in empirischen Tests gerade nachweisen konnten, funktioniert Teamviewer 13 nicht mehr mit Wayland. Man kann zwar noch von Linux aus auf Windows zugreifen, aber auf ein Linux mit Wayland ist nicht mehr möglich. Man bekommt in dem Fall nur ein schwarzes Bild.

„Nutzen Sie X.ORG“

Teamviewer empfiehlt daher in einer langen Verkettung von Erklärungen, daß man doch die Desktopsession auf X.org umstellen sollte, also den alten X-Server. Klappt leider auch nicht 🙁 Genauso ein schwarzes Bild, wie unter Wayland.

Dabei beweist z.B. der SimpleScreenRecorder, daß es möglich ist, auch unter Wayland alles zu capturen, was man sich so vorstellen kann.Warum der Teamviewer das nicht kann, können wir hier leider nicht herausfinden.

Bleibt nur zu hoffen, daß es entweder eine bessere Lösung gibt, zumal das ja sowieso bedenklich ist, eine Session mit Audio/Video/Tastatur über die Teamviewerserver zu schicken, oder das Problem bald gelöst wird.

Workaround

Die praktische Antwort auf das Problem lautet dann natürlich auf VNC zurück zu fallen. Dafür muß im Router z.B. der Fritz!box ein Portforwarding eingerichtet werden. Im Screenshot ist ein Beispiel für GlusterFS und SSH abgebildet:

Symbolbeispiel für Portfreigaben auf der Fritzbox

Symbolbeispiel für Portfreigaben auf der Fritzbox

Für VNC muß man i.d.R. Port 5800-5910 freigeben und zum heimischen PC umleiten. Vorteil dabei ist, daß man jeden Port auf einen anderen Rechner leiten kann, so daß der Admin aus der Ferne festlegen kann zu welchen Desktoprechner er will.

VNC != VNC

VNC kann aber auch ein Problem in sich sein. So lange nur ein Adminuser auf den PC soll, ist das kein Problem, weil VNC heute meist so eingestellt ist, daß es eine eigene Desktopsession aufmacht. Wenn man sich dort einloggt, kann es vorkommen, daß z.B. Pulseaudio einen Abgang macht, weil es irrtümlich doppelt gestartet wird.

Was man also im VNC braucht, ist eine Shared Session, so daß man sieht, was auf dem physischen Bildschirm zu lesen ist:

x0vncserver -display :1 -SecurityTypes=none

aber der Befehl erlaubt jedem sofort ohne Passwort auf den Schirm zu connecten, was man natürlich NICHT will.

mit „vncpasswd“ kann man ein Zugangspasswort vergeben und dem Server so starten:

x0vncserver -display :1 -SecurityTypes=TLSVnc,VncAuth,TLSPlain -PasswordFile=.vnc/passwd

Und nicht vergessen, VNC braucht zum Desktop Sharing X.ORG 😉 Das will unter Wayland vermutlich aus dem gleichen Grund nicht, wie Teamviewer auch nicht wollte.

 

Signieren von npm Paketen

Zur Einleitung eine kleine Geschichte zu einem Projekt, daß ich mit einem unserer Kunden umgesetzt habe. Da das Projekt mangels Benutzer jüngst eingestellt wurde, ist wohl die Floskel „Es war einmal…“ angebracht 🙂

Die Geschichte von Lord Uglify

Also.. Es war einmal .. ein tolles webbasiertes Firmenspiel für das jede Menge Javascriptcode erzeugt wurde, weil es ja im Browser zu spielen war. Nun sollte das ellenlange Javascript eingedampft werden mit „Uglify“ einem node.js Tool zum Schrumpfen und Verschleiern von Javascriptcode.

Nun sollte jemand Uglify irgendwo installieren und es dafür benutzen. Das war der erste Fehler. Nachdem Node.Js aus dem Repository installiert wurde, tat es natürlich nichts sinnvolles, denn Uglify hat wie so viele andere Node.js Programme, einen Abhängkeitsbaum, der milde betrachtet, bis zum Mond reicht. Mit NPM, dem Node.Js Paketmanager, kann man die Abhängkeiten befriedigen, glaubten wir zumindest. Das war Fehler Nummer 2. Denn die Abhängigkeiten von den Abhängigkeiten der Abhängigkeiten von den Abhängigkeiten der Abhängigkeiten von den Abhängigkeiten die keine Ende nehmen wollten, brauchten geschlagene 30 Minuten sich zu installieren. Na gut, jetzt wird es ja wohl endlich starten. Das war der dritte Fehler.. allerdings dann auch der letzte, weil ich keinen Bock mehr hatte mich von so einem Witzprogramm verarschen zu lassen.

Ich habe dann einfach „jsmin“ genommen: klein,schnell,effektiv,läuft überall, keine Abhängigkeiten und einfachst zu bedienen. Kurzum, ein Programm wies sein sollte.

Was hat das jetzt mit dem Signieren von Paketen zu tun ?

Tja, wie man oben lesen kann, sind Node.js Programm extrem modularisiert, sprich, mal eben selbst was schreiben ist praktisch nicht, weil man erst mal jede Menge an Paketen installieren muß. Im Gegensatz zu Java, wo eine Fülle von Klassen mitgeliefert werden, kommen die Pakete per NPM ins Projekt rein.

Diese Pakete sind nicht signiert, die von Java zwar auch nicht, aber die kommen ja auch aus einer definierten Quelle gleich mit. Signieren ist im NPM auch nicht vorgesehen. Daher hat jemand in Australien ( Details bei Heise ) gemeint, er müßte das ändern und hat ein Signaturtool für Node.js Pakete gebaut.

Die Begründung war, das neulich diverse Pakete aus dem NPM Repo auf merkwürdige Art verschwunden sind, zwischenzeitlich durch gleichnamige Pakete ersetzt wurden, um dann funktional mit den früheren Paket  zu kollidieren, sprich, was anderes zu machen, als das Original.

Da jeder Pakete in das NPM Repo laden kann, würde das Signieren also den Prozess mit den Paket-Abhängigkeiten sicherer machen, weil wenn sich so ein Vorgang wie eben beschrieben passiert, würde ja die Signatur nicht mehr passen und dem Entwickler würde dann auffallen, daß da gerade was schief läuft. Nun, das mag sein.

Das eigentliche Problem

Das eigentliche Problem löst das natürlich nicht: 100 Abhängigkeiten im Projekt, und den von den Entwicklern hat noch nie einer gehört. Ob die da Schadcode einbauen oder nicht, kann man nicht an der Tatsache einer gültigen Signatur erkennen.
Alles was dieses Signaturen bieten, ist ein Verwechslungsschutz, das aber auch nur, wenn der lange verschollene Author doch nochmal gefunden wird 🙂

Ich halte das für nichts, was man an die große Glocke hängen sollte, denn das hier kann man damit nicht vermeiden:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

Es lohnt sich bis zum Ende zu lesen, weil Ihr sonst einen falschen Eindruck von der Sache bekommt. Wenn Ihr damit fertig sein, hier ein Zitat von „blog.fefe.org“ unser aller Weltverschwörungsguru 😉 passend zum Thema :

[l] Ein Einsender kommentiert die Webfrontend-Warnung:

  • lass‘ uns als kleine Veranschaulichung, wie breit und tief die Güllegrube npm sein kann, eine Webanwendung anfangen. Natürlich mit Angular und dem aktuellen Standard-Build-System @angular/cli:

    $ npm i @angular/cli
    $ node_modules/.bin/ng new webkid --directory=.

    Das Ergebnis ist ein Skeleton mit einer Hello-World-Seite und:
    31 direkten Abhängigkeiten
    974 Abhängigkeiten insgesamt
    305 MB in node_modules

    Davon sind 158 Pakete Duplikate von bereits installierten Paketen mit einer anderen Versionsnummer. Bei so vielen Abhängigkeiten ändern sich die Zahlen natürlich schnell, also am besten sofort anfangen mit dem Audit!“

    “ [Ende des Zitats]  Aufgrund der Struktur von Fefes Webseite, müßt Ihr selbst den „Wed Jan 10 2018“ suchen 😉

 

Dem Kommentar kann man sich nur anschließen. Keine Signatur der Welt macht das irgendwie sicherer!

Davon ab, keine Ahnung wie jemand auf die Idee kommt, dafür zu Entwickeln. Da braucht man ja Stunden um anzufangen. Leute nehmt was vernünftiges, nehmt Java. Eclipse auf. Neues Javaprojekt aufmachen und einfach losschreiben 😉

Java kommt übrigens leer mit knapp 105 MBye aus 😉 und das wäre dann auch für alle Projekte und nicht PRO Projekt 😀

Quelle: heise.de – Open Source Tool zum Signieren von npm Paketen veroeffentlicht

Linux – Jitsi Probleme mit Sipgate beheben

Seit SIPGate vor einigen Monaten an Ihrer Infrastruktur unangekündigt Veränderungen vorgenommen hat, verliert die Linuxversion von Jitsi im UDP Modus häufig die Verbindung zum Server. Dabei ist es egal, welche Version und welches Java man verwendet.

Die Abhilfe ist aber sehr leicht zu schaffen, man schaltet das automatische Proxy ab und ersetzt es mit :

Proxy:  tcpproxy.sipgate.de
Port: 5060
Bevorzugter Transport: TCP <-! Wichtig

Seit der Anpassung, funktioniert Jitsi wieder stabil mit SIPGATE.

Autofahrer verstehen Schilder nicht

Es ist unglaublich wie viele Wagenlenker keine Schilder lesen können:

Die Baustelle ist jetzt seit über zwei  Wochen da und trotzdem fahren laufend Leute drauf zu und durch

Auch wenn es komisch klingt, aber die meisten Autofahrer können die Schilder nicht lesen, und die sind gut zu erkennen!

Das Bild oben haben wir an dieser Baustelle mehrmals täglich, weil Leute wie in Trance Autofahren und erst direkt vor der Baustelle glauben, daß es wirklich nicht weiter geht. Einige ignorieren die „Durchfahrt verboten“ Schilder auch und fahren einfach weiter. Ich warte nur darauf, daß da mal eine Polizeistreife steht und die Durchfahrer abkassiert.

Etwas Kontext: Die Baustelle ist jetzt seit über zwei  Wochen da.

 

Sparkassen-Shop mit Tracking und unsicheren Webseiten

Da wollte man so harmlos mal die Webseiten der Braunschweigischen Landessparkasse aka. Norddeutsche Landesbank oder kurz NORD/LB, benutzen, da zieht ein merkwürdiger Werbelink meine Aufmerksamkeit auf sich : http://www.sparkassen-shop.de

Hätte ich mal nicht hingeschaut :

SSL-Report des Sparkassen-shops mit Fehlermeldungen. Die Webseite ist als unsicher markiert und der Schlüssel entspricht nciht mehr so ganz den Ansprüchen an einen sicheren SSL Key

SSL-Report des Sparkassen-shops

Wie man schön sehen kann, stimmt was mit der HTTPS Seite nicht, weil der Browser schon von sich aus warnt, daß unsichere Links enthalten sind. Da sowas mein Job ist, kurz mal FireBug aktiviert und nachgesehen. Das hätte ich mal besser nicht machen sollen 😀

oh wie peinlich :  ERWISCHT beim Tracken

Da fand sich dann folgender Trackinglink der hauseigenen PIWIK Installation:

<img src=“http://piwik.sparkassenverlag.de/piwik/piwik.php?idsite=18″ style=“border:0;“ alt=““ />

sowas gehört auf einer HTTPS Seite natürlich auch mit HTTPS:// eingebunden !
Lustigerweise macht der Code-Schnippsel von PIWIK selbst, das richtig 🙂

Damit haben wir die Quelle der Browsermeldung, aber wenn wir schon dabei sind,  was zum Geier soll das sein ?!?

<a href=“http://www.blsk.de“ target=“_blank“>

Seit wann braucht man hardgecodete HTML Entitätsersatzanweisungen aus dem UTF-8 Zeichensatz für ein simples „://“ ?!?

Da kann man nur mit dem Kopfschütteln 🙂

Schlüssellängen

Aber warum habe ich jetzt eigentlich in dem SSL-Report die Schlüssellänge und den HASH-Algo markiert ?

Für die meisten (Männer) gilt die Formel :  Länge * Angelerfahrung => Menge(Selbstbewußtsein), lustigerweise gilt das auch für Webseitenverschlüsselungen. 2048bit Schlüssellänge waren vor Jahren mal empfohlen als ausreichend, ein paar konservative Fachmenschen würden das heute noch empfehlen, aber für eine Bank, da kann man nur zu einer vernünftigen Schlüssellänge von 4096+ Bits raten. Denn das sollte ja wohl sicher sein, oder war Fort Knox mit Wattebällchen abgesichert ?

Fazit

Diese Webseite gehört zu Kategorie: „Hätten Sie mal jemanden ohne Zertifikat gefragt“. Aber nicht alles ist schlecht, denn insgeheim hatte ich mit Google Analytics gerechnet zum Tracken der Benutzer und da ist mir PIWIK auf den eigenen Servern des Webseitenbetreibers natürlich lieber.

Da diese Grafik (oben) aber geladen wird, noch bevor man die Chance hatte, die Datenschutzerklärung zu lesen und die Seite ohne Tracking wieder zu verlassen, ist es wohl nur eine Frage der Zeit, bis der Datenschutz die Seite dicht macht. Wir sind ja hier in der EU, die auch eine Einwilligung zum Tracking per Einsatz von Cookies vorraussetzt.

Nur so ein Denkanstoß an die Verantwortlichen: Auf der Startseite brauch man noch kein Tracking, wie oft die aufgerufen wurde, sagt einem auch ohne weiteres das Apache Domlog.

Weiter als die Startseite durchzusehen, habe ich mich dann nicht getraut, ich hatte Angst, daß ich heute Nacht noch an dem Artikel sitzen würde 😉