Ich mach Pause von Kodi

Zitat von easy4me

Dafür habt ihr nur sechs Seiten gebraucht...

Lies sie. In den vergangenen 6 Seiten geht es vielmehr um Aufklärung, Sensibilisierung und (leider zu wenig auch von mir) um Ursachenforschung.

Eine Lösung hatten wir schon auf der ersten Seite. Was und warum der eigentliche Anwendungsfall war und warum bisher kein VPN gewählt wurde, erst auf dieser hier (Wohnmobil mit iPhone als Hotspot). Da ändern sich halt manche Gegebenheiten.

@Ponyriemen, wenn es dir primär ums Fernsehen im Wohnmobil geht, ist möglicherweise ein IPTV-Anbieter wie Magenta TV eine Option für dich. Gibt es auch monatlich kündbar (z.B. nur für die Ferienmonate) zu Kosten, die unter den Stromkosten von manchem Server liegen. Leider darf die Telekom ihr Smart On nicht mehr anbieten, wo man das sogar bekam, ohne dass es in Europa Einfluss aufs Mobil-Daten-Budget hatte.

Das "Leider" sehe ich eher als "zum Glück" an... Während man in anderen Ländern längst bezahlbare Flatrates bekommt, wird man hier weiterhin für dumm verkauft. 100€/4 Wochen für Unlimited 5G im D1-Mobilfunk sind ein schlechter Witz. Welche Dienste man unbegrenzt nutzen möchte, hat den Anbietern nicht zu interessieren, das entscheidet immer noch der User.

Magenta TV kann man auch in Kodi nutzen, sowohl für Live TV via IPTV Simple als auch mit der Megathek im Video-Addon.

Zattoo könnte man auch in tvHeadend einbinden. Die Streams lassen sich ja auch priorisieren, damit man eine entsprechende Ausfallsicherheit hat.

Zitat von Ponyriemen

Habe über Google eine Anleitung gefunden, wie man unter CE auch Wireguard nutzen kann, aber da blicke ich nicht wirklich durch.

CoreELEC SSH Zugriff - Anleitung hier
WireGuard auf CoreELEC installieren - Anleitung hier

Fritzbox - WireGuard Einstellungen anzeigen - Schlüssel im CoreELEC-Client eintragen, fertig

Man kriegt das auch ohne VPN sicher ans laufen, aber ein VPN ist auch nicht schwerer aufzusetzen..
Problem ist halt das CE und LE den TVH Service mit der Option -C starten. Dabei wird eine User ohne Passwort mit allen rechten angelegt der von überall erreichbar ist.
Das ist nach den TVH Machern keine best practice.

Da mich eine Antwort im CE Forum aber ein bisschen geärgert hat schaue ich am WE mal ob man das install Script von TVH so umschreiben kann das man am Ende kein offenes Scheunentor hat.

@darkside40 Mit install script hat das nichts zu tun. Die Addons werden mehr oder weniger nur in einen Ordner entpackt und beim Booten gestartet.

https://github.com/LibreELEC/Libr…headend43.start

Weiß aber nicht, was du da genau umschreiben willst bzw. was das anderen bringen soll?

Zitat von jkdask

Weiß aber nicht, was du da genau umschreiben willst bzw. was das anderen bringen soll?

Bei der Ersteinrichtung wird man durch den Einrichtungsassistenten geführt. Den kann man abbrechen (noch vor der Vergabe eines Passworts für root) - mit dem Ergebnis, dass man sich als root ohne Authentifizierung anmelden kann. Bumm, drin.

Letztendlich sollte wenigstens ein Passwort für die Einrichtung/root erzwungen werden.

Zitat von PvD

Bei der Ersteinrichtung wird man durch den Einrichtungsassistenten geführt. Den kann man abbrechen (noch vor der Vergabe eines Passworts für root) - mit dem Ergebnis, dass man sich als root ohne Authentifizierung anmelden kann. Bumm, drin.

Nutze TVH nicht aber das habe ich dem Thema schon entnehmen können. Es hilft aber nur was, da was umzuschreiben, wenn das dann auch im Repo von LE/CE landet. Ansonsten ist damit ja niemandem geholfen.

Doch es gibt ne Lösung, statt den TVH total unsicher zu starten und es dann dem User zu überlassen das abzudichten gibt es die Möglichkeit eine superuser datei mit anmeldedaten anzulegen und dann den TVH zu starten.
Man muss im Startscript also nur diese Datei anlegen und schon ist das Webif dicht.
Die Kür ist dann natürlich die dynamisch generierten Anmeldedaten in den Settings des Addons anzuzeigen.

Unter Debian geschieht das automatisch so wenn man TVH aus dem Deb Paket installiert.

Das bezweifel ich nicht aber wie sollen andere davon profitieren? Willst du versuchen, deine Änderungen in die Repos von LE und CE aufgenommen zu bekommen oder was ist der Plan?

Zitat von Ponyriemen

wie muss ich die "wg0.conf" editieren? Das kappier ich gerade noch nicht.Die Fritte ist auf Wireguard eingestellt, config liegt vor.

Du trägst unter Adress die FB-IP ein, den PrivateKey, den ListenPort, den PublicKey, EndPoint xxxxxxxxxxxxx.myfritz.net:portnummer jeweils aus der Fitzbox/WireGuard-Info ein.

[Interface]
Address = 10.10.10.5 # local-ip-of-wg-interface
PrivateKey = ... # private-key
ListenPort = 51820 # wg-port

[Peer]
PublicKey = ... # public-key
Endpoint = <dynamic-dns-of-server>:51820
AllowedIPs = 0.0.0.0/1,128.0.0.0/1 # instead of 0.0.0.0/0

Zum üben und testen, kannst Du WireGuard einfach mal auf dem Smartphone, Tablet oder Windows installieren, also überall dort wo über WLan unterwegs bist, wegen der Sicherheit und so....

Ist halt immer eine Frage wer/wo fuer Sicherheit zustaendig ist.

Die heutigen Extreme im consumerbereich sind ja:

1. Alle Software is Moppelkotze, ich kloppe ein VPN davor
2. Alle Software ist gut abgedichtet, mit TLS (e.g.: HTTPs) und zertifikat

2. gibts halt wenig. Und ist im Prinzip halt auch Vergeudete Arbeit, wenn jede Anwendung wieder denselben Sicherheitscode implementieren sollte und mann das alles separat verifizieren muss.

Deswegen war ja meine Empfehlung in discussion mit @buers oben, sich den Mittelweg 1.5 anzuschauen, der ja auch so in professionellen Umgebungen verwendet wird:

1.5 HTTPs/HTTP proxy, einmal aufgesetzt mit Zertifikat, einfach fuer jeden HTTP Anwendungsport konfigurierbar.

Wie gesagt, caddy scheint mir da ein guter Einstiegspunkt zu sein, aber fuer mich noch eher Idee, muss ich noch durchprobieen - habs schon als HTTPs server selbst am laufen, aber noch nicht das Proxy plugin. Aber das automatishe anfordern des Zertifikates ist schon klasse.

Natuerlich geht das nicht fuer serverports, die nicht http machen. Da braeuchte man immer noch VPN. Und dann eben auch VPN client ueberall. Waehrend man bei HTTPs halt diese Arbeit auf der Client-Seite nicht hat.

@te36 und inwiefern hätte SSL/TLS auf Seiten des Servers im hier vorliegenden Fall geholfen?

Zitat von jkdask

@te36 und inwiefern hätte SSL/TLS auf Seiten des Servers im hier vorliegenden Fall geholfen?

Erstmal natuerlich ausreichend gutes Passwort vorausgesetzt:

Wenn Du dich "bloss" mit gutem Passwort ueber e.g.: HTTP auf den Server einloggst, dann kann jeder der irgendwo zwischen Deinem Client und Deinem Server zugriff auf Pakete hat, dein Passwort mitloggen und spaeter verwenden.

Die "kurze" Liste:

Z.b.: Wenn Du ueber WiFi zugreifst und da kein WiFi Passwort ist kann jeder Dein Passwort fuer den Server mitlesen.

Wenn da ein WPA-PSK Passwort drauf ist, was oeffentlich ist, also das was heute mit etwas Glueck irgendwo in Hotels oder so hast, dann kann auch jeder mitlesen. Einziger Unterschied zu kein-wifi-passwort ist das der Mitleser schon mitlesen muss, wenn Du dich da ins WiFi einloggst, reicht also nicht das nach ner Stunde zu machen wenn Du schon eingeloggt bist.
(fuer das Problem wird gerade eine Loesung gebaut).

Wenn das WPA-PSK Passwort nicht oeffentlich ist, koennen einfache WPA-PSK Passwoerter von Angreifern wohl auch relativ leicht geraten werden.

Wenn Der Betreiber des Access Points nicht vertrauenswuerdig ist kann er natuerlich abhoeren. Wenn irgendein Service Provider auf dem Netzpfad neugierig ist kann er das auch.

[ Letzteres war der originale Grund, warum Firmen wie Google ueberhaupt TLS gebaut haben: Die haben uebers Internet via HTTP video gestreamed, und Service Provider durch die die Pakete laufen haben sich in die Videoverbindung eingeklinkt und Werbung reingespielt an der sie (aber nicht Google) verdient haben. Oder halt einfach auch nur mitgelauscht haben, was Du anschaust und dann Kundendaten und diese Information an Werbetreibende verkauft. Mit TLS kann das natuerlich nur noch der eigentliche Contentanbieter selbst machen (also Google/Youtube, etc. pp.). Inzwischen natuerlich via GDPR besser dokumentiert in Europa.]

Die NSA hat eigentlich bei jedem groesseren Internetvermittlungspunkt - Frankfurt ist da gut bekannt - direkt nebenan Bueros, von denen sie die Kabel anzapfen koennen und dann auch Passworter usw. mitlesen koennen.

Die Ermittlungsbehoerden vieler Laender duerfen auch legal viele Internetkabel abhoeren, direkt. Ohne buddeln. Deutschland ist da ja besser: Die outsourcen sowas an die NSA damit sie sich die Haende nicht dreckig machen muessen
Ist wahrscheinlich auch billiger fuer die deutschen Steuerzahler (nicht fuer die amerikanischen ;-).

Das geht halt alles mit TLS weg. Da bleiben dann nur all die Angriffe, die sich direkt bei Dir auf dem Client oder Server einnisten. Viren usw. Aber mit Viren kenne ich mich nicht gut aus *hatschi*

Die Vorteile gelten natuerlich genauso fuer VPN.

Bloss das das halt nicht in die Anwendungen integriert ist, wie TLS und das vor allem auf der Client-Seite deswegen mehr Arbeit macht. Z.b. wenn man ein paar Freunde hat und jeder da seine Mediensammlung uebers Internet mountbar macht (read-only). Und jeder Kumpel einen anderen username/passwort kriegt (so das man das problemlos managen kann). Sowas geht im Prinzip mit Kodi und https file shares mit username/passwort. Probier das mal mit VPN (theoretisch ja, ab...).

War frueher nicht so sinnvoll wenn man nur DSL upstream Geschwindigkeit hatte. Aber heute mit FTTH geht sowas genial.

@te36 Okay also zusammengefasst hätte es im vorliegenden Fall wenig bis gar nichts gebracht, da es sich augenscheinlich nicht um eine MITM-Attacke handelte. Nichtsdestotrotz macht es natürlich Sinn, über das Internet erreichbare Dienste mit einer Transportverschlüsselung zu versehen.

Zitat von jkdask

@te36 Okay also zusammengefasst hätte es im vorliegenden Fall wenig bis gar nichts gebracht, da es sich augenscheinlich nicht um eine MITM-Attacke handelte. Nichtsdestotrotz macht es natürlich Sinn, über das Internet erreichbare Dienste mit einer Transportverschlüsselung zu versehen.

Die Loesung HTTPs mit Proxy ist quasi eine Alternative zu VPN. Ohne gutes Kochrezept wohl schwieriger aufzusetzen, aber am Ende hoffentlich ohne client nutzbar. In beiden Faellen, VPN oder HTTPs/proxy brauchst Du dich dann nicht mehr nur auf Passwort im Server verlassen sondern vor allem auf das passwort vom VPN oder HTTPsproxy (oder zertifikate, was noch besser sein koennte, aber meist mehr arbeit macht).

Und wie erklaert, einfach nur Passwort in der Serverapp TVH zu setzen ohne so eine gesicherte Verbindung uebers Internet (VPN oder HTTPs) hilft nix wenn Du da haeufiger an richtig unsicheren WiFi accesses bist. Die anderen Beispiele NSA oder so waren eher als Refernz, aber Hotel, Geschaefte, irgendwelche oeffentlichen WiFi mit bekannten passwoertern (oder ohne wifi passwort) sind halt voll das Einfalltor.

Natuerlich sind ungesicherte Internetverbindungen immer noch weniger wahrscheinlich angegriffen zu werden, als der Angriff um den es hier ging: ein Scanner der freie Ports ausprobiert hat. So ein Scanner kann von ueberall kommen. Jemand der eine ungesicherte Verbindung angreift muss schon irgendwo sitzen wo er das kann. Also ist auch das Server passwort ohne VPN/HTTPsproxy schon mal eine Stufe rduktion in Risiko. Aber halt allgemein als nicht ausreichend angesehen.