15 replies to this topic

[ExeCRabLE]

Hallo zusammen !

Mich würde einmal interessieren, ob das Projekt im Bereich Sicherheit einmal nach legen möchte. Momentan ist die Box IMHO eine Zeitbombe und dürfte sicherlich bei dem einen oder anderen Besuch erhalten haben - wohl ungemerkt.

Momentan macht mich das Wissen um den Zustand des Betriebssystems doch sehr nachdenklich und irgendwie etwas wütend. Gibt es da inzwischen ernsthafte Bemühungen da nach zulegen ?

Gruß
Exe

[Frenske]

Willkommen aud dem OpenPLi Forum.
Was soll man jetzt darauf antworten? Es gibt, seit der Introduktion von PLi mehrere Zehntausende von Benutzer die normalerweise zufrieden bis sehr zufrieden sind mit PLi.
Da aber das Image noch immer in Entwicklung ist kann es passieren das der Box ab und zu mal nicht funktioniert. Normalerweise werden die Sachen innerhalb von ein par Stunden oder ein Tag wieder gelöst.. Dies ist vor zu beugen wenn man nicht täglich einen Update macht. Also wenn du einen 100% funktionierende Empfänger haben willst von dem du dicht nicht braucht zu fragen ob da jemand tagsüber oder nachts eindringen wird, dann kaufe dir einen nicht Linux Receiver.

Oder habe ich deine Frage falsch verstanden.

[koivo]

Ich möchte anmerken das es sich immer noch um einen Receiver handelt. Zum Surfen sollte man etwas anderes benutzen.
Viele wollen aber scheinbar ihren PC durch so eine Box ersetzen.
Auf so einer Box muss kein VPN, Usenet, Emule und was nicht sonst noch für Krempel laufen.

Ich möchte mal einen vergleichbaren Receiver mit Windows sehen (Virenchecker auf einer STB). Da hätte ich wirklich Angst vor. Aber so.
Man sollte mal die Kirche im Dorf lassen.

[rtzhjgg0]

Ich bevorzuge"NIGHTLY" software weil dort eben täglich alles gefixt/verbesert wird. Daswegen verwende seit langem für den täglichen gebrauch zb. den browswer Firefox-Nightly und PLi auf Dreambox

[ExeCRabLE]

Ich denke das Security nichts mit "Browsen" und "Emule" zu tun hat. IMHO geht es mir darum, dass die Box nun mal Dienste anbietet und diese nicht gesichert sind. Das absolut offensichtlichste ist, das alle Dienste im Root-Kontext laufen und die Dienste mit Versionsnummer Public sind, aber IMHO fehlt das Autoupdate, damit diese auch automatisiert eingespielt werden. Die Plugins werden nicht kontrolliert und können sich frei im System bewegen. Das Linuxsystem hält sich nicht an die Standardvorgaben, wie ein Filestruktur aufgebaut werden soll, das Logging ist IMHO nicht transparent usw.

Es ist ja alles da, nur nutzt man es nicht. Die Box ist bei fast allen Usern mit Netz versorgt, daher wäre "Sicherheit" ein Thema, der sich das Projekt schon etwas widmen könnte.

[hypnotoad]

Auf Sicherheit ist kein OS getrimmt auf dem e2 läuft.
Das war vermutlich auch einfach nicht Ziel von DMM, um nicht zu sagen denen war das sch...egal.
Man kann jetzt viel darüber philosophieren wie man das System sicherer machen könnte, fakt ist aber auch das es "keinen" interessiert und man sich sicherlich viele neue Probleme einhandeln würde. Also für was den Aufwand.
Von daher kann ich die dev´s schon verstehen.
Am besten man hängt die Box hinter nen router und lässt keine ports auf die Box weiterleiten.
Das Thema Sicherheit hat schlicht keine Relevanz, das muss man ganz klar sagen.
Gruß von einem langjährigen Debian User

[BuGless]

Auf Sicherheit ist kein OS getrimmt auf dem e2 läuft.

Am besten man hängt die Box hinter nen router und lässt keine ports auf die Box weiterleiten.

Es ist nicht kompliziert um die Box so zu trimmen das nur noch folgende ports offen sind:

UDP: 123 (NTP)
TCP: 21 (FTP)
22 (SSH)
23 (TELNET)
80 (OpenWebIF)
8001 (Mediastream)

Wobei ich persoenlich ports 21 und 23 nie verwende; koennte mich aber vorstellen dass andere die manchmal brauchen.

Ich habe zwei Boxen, beide getrimmt wie oben (eine mit OpenPLi 3.0, die andere mit OpenPLi 2.1), beide ins *offene* Internet (nicht hinter einem Router, also ohne NAT). Der einzige Port den ich abschirmen muss ist port 8001; der ist leider von Enigma2 aus ungeschuetzt. Fuer den Rest sind die Boxen sicher (vom Netz aus gesehen; solange man keine "falschen" plugins installiert).

[MiLo]

Ich habe zwei Boxen, beide getrimmt wie oben (eine mit OpenPLi 3.0, die andere mit OpenPLi 2.1), beide ins *offene* Internet (nicht hinter einem Router, also ohne NAT).

Hast du bisher gluck gehabt. Dass werd sich vielleicht andern, da Sie es jetzt die Welt erzahlt habt...

[BuGless]

Ich habe zwei Boxen, beide getrimmt wie oben (eine mit OpenPLi 3.0, die andere mit OpenPLi 2.1), beide ins *offene* Internet (nicht hinter einem Router, also ohne NAT).

Hast du bisher gluck gehabt. Dass werd sich vielleicht andern, da Sie es jetzt die Welt erzahlt habt...

Wieso wuerde das einen Unterschied machen?
Port 123 akzeptiert keine Anfragen (so konfiguriert).
Port 21, 22, 23 und 80 sind Passwort geschuetzt (mit einem nicht-trivialen Passwort).
Port 8001 wird blokkiert per iptables (leider notwendig wegen fehlendem Passwortschutz).

Habe ich noch etwas uebersehen?

Edited by BuGless, 30 October 2012 - 12:13.

[ExeCRabLE]

Es nützt nichts, wenn man Dienste blockt (Dann funktionieren sie meistens nicht ) oder wenn man Dienste in Netz hängt, die zum völligen Überfluss noch die ganze Versionierung angeben. Der Sprung zu den gängigen Exploit-DBs ist schnell gemacht und Passwörter helfen nur, wenn der Dienst keinen Fehler hat - haben Sie in der Regel aber nicht.

IMHO bleibt das Hauptproblem, das die Software im Root-Kontext läuft, inkl. der Plugins und das ist doch das das eigentliche Feature schlecht hin aber auch das absolut Tödlichste. Die Argumentation, dass es sich doch nur um eine STB handelt wäre die gleiche, wenn Google von Android behauptet, dass es sich bei einem Smartphone doch nur um ein Telefon handelt und wenn man die Apps installiert man schlicht selbst schuld ist. Ich denke das man die Argumentation definitiv nicht fahren sollte...

Wenn ich eine art "Blackbox" in meinem Netz stehen habe, die über eine andere Kiste oder sonst wie gehackt wurde und sich bei mir einnistet, habe ich doch im Moment keine Chance das zu erkennen, außer ich fahre regelmäßig ein TCPDump oder installiere mir ein IDS. Das schießt IMHO aber über das Ziel hinaus - auch wenn ich es allen grundsätzlich sehr Empfehlen würde.

Wenn OpenPLI die normalen Standards im Bereich Security und Layout umsetzen würde, hätte man kaum Probleme das System zu überwachen oder evtl. sogar eine Plugin zu schreiben, die die Box überwacht. Dazu müsste das Projekt aber das Image inkl. dem e2 straff ziehen, Dev-Richtlinien entwickeln und den Root-Kontext verlassen.

PS: Nur damit solch eine Diskussion nicht Port abhängig gefahren wird: Ein Port kann mehrere Dienste und damit auch alles erdenkliche Transportieren - die Nummerierung eines Ports sagt nichts aus und eine Firewallregel ala DROP mit IPTables hat keinerlei Sicherheitsfunktion.

Edited by ExeCRabLE, 30 October 2012 - 12:31.

[ExeCRabLE]

Ich möchte mit dem Thread _keinem_ ans Bein pinkeln Ich möchte eher erreichen, dass ein Gedankenprozess entsteht und man langsam aber sicher ein Umfeld schafft, das deutlich sicherer ist. Sobald sich herum gesprochen hat, dass das Image ein Sicherheitsproblem hat, wird das Projekt Probleme bekommen - damit ist wirklich keinem geholfen.

Ich arbeite als Sec-Admin in einer Firma, die ein weltweites Netzwerk hat und eine zentrale Funktion bietet und selbst da muss ich heute immer noch für jede Sicherheitsfunktion kämpfen. Wir segeln selbst in "unruhigen" Gewässern, was die Sicherheit angeht, aber wir kommen langsam voran und ich würde behaupten das wir die berühmte "Kuh vom Eis" haben. Ich erzähle das, weil ich hoffe das man versteht, das ich keine Erwartung haben ala "Nächstes Release muss aber sicher sein", sondern es mir sehr wohl bewusst ist, was es bedeutet etwas bestehendes in ein Sicherheit-Korsett zu drücken.

[BuGless]

Es nützt nichts, wenn man Dienste blockt (Dann funktionieren sie meistens nicht )

Die Dienste (port 8001 in diesem Fall) werden geblockt fuer jeden ausserhalb eines gewissen Netzbereiches.

oder wenn man Dienste in Netz hängt, die zum völligen Überfluss noch die ganze Versionierung angeben. Der Sprung zu den gängigen Exploit-DBs ist schnell gemacht

Stimmt. OTOH, beschleunigt dass das finden und eliminieren von allen Fehlern.

und Passwörter helfen nur, wenn der Dienst keinen Fehler hat - haben Sie in der Regel aber nicht.

Der Dienst braucht nur Fehlerfrei zu sein bis zum Punkt wo das Passwort kontrolliert wird; dass ist in der Regel machbar. Ich gebe zu dass es fuer ntp, ftp, telnet und ssh viele male wahrscheinlicher ist dass es zu dem Punkt schon Fehlerfrei ist, als bei OpenWebIf von enigma2.

IMHO bleibt das Hauptproblem, das die Software im Root-Kontext läuft, inkl. der Plugins und das ist doch das das eigentliche Feature schlecht hin aber auch das absolut Tödlichste.

Wenn OpenPLI die normalen Standards im Bereich Security und Layout umsetzen würde, hätte man kaum Probleme das System zu überwachen oder evtl. sogar eine Plugin zu schreiben, die die Box überwacht. Dazu müsste das Projekt aber das Image inkl. dem e2 straff ziehen, Dev-Richtlinien entwickeln und den Root-Kontext verlassen.

Solche Massnahmen sind immer gut, und sorgen prinzipiel fuer ein robusteres System. Ich moechte nur betonen dass auch ohne diese Massnahmen, ein relativ sicheres System jetzt schon moeglich ist wenn man nur die Anzahl von laufenden Diensten auf der Box entsprechend einschraenkt.

[Lutz]

Vielleicht sehe ich alles zu einfach: meine et9x00 ist für mich in erster Linie eine Settop Box, und kein Computer. Sie hängt hinter einem DSL Modem/Router, und kann ins Internet.
Das nutze ich nur zum Updaten oder für die Wettervorhersage. Des weiteren kann meine Box in mein Heimnetz, um meine CD Karte mit dem Zweitempfänger zu teilen.

Wenn ein Hacker kommt, kann er vermutlich nicht über WAN in mein Modem kommen, da ich Fernwartung ausgeschaltet habe. Ein Hacker kann allein über mein Heimnetz zum Modem vordringen, aber dann müsste er mein Passwort kennen. Auch wäre ein Kabelanschluss hilfreich, da WLAN ausgeschaltet ist. Auf der BOX selber gibt es nicht viel zu entdecken. In der Hauptsache das Filmarchiv, seit ich die Box habe, ungefähr 800GB. Alles ganz legal über die Schüssel empfangen.

Mit einer realistischen Einschätzung der Risiken kommt man auch sehr weit...

[ExeCRabLE]

Es fällt mir wirklich schwer die Antworten zu lesen und dabei noch Objektiv zu antworten.

Beim hacken wird in der Regel nie ein Passwort geknackt, da es viel zu lange dauert (Wer macht so etwas noch ?). Wenn ich weis das sich hinter ein IP ein mir bekannter Dienst läuft, egal ob Updates oder FTP oder Wetterdaten oder EPG-Daten usw... dann kann ich die Dienste und Anfragen manipulieren und damit das Systemen kompromittieren, vor allem, wenn er die Daten wie bei dem OpenPli ungefilter nutzt und den Exploit dann sogar direkt als root ausführt. Ob man selbst die STB als Computer sieht oder nicht spielt doch für den Angreifer keine Rolle, für ihn ist das immer ein Computer auch wenn der Computer fürs Kaffekochen zu ständig ist.

Um das nochmals verständlich zu machen, wenn ein Hacker die STB unter Kontrolle hat - das wird keiner von euch merken - kann er alle eure Dienste inkl. euren Onlienbanking usw. ohne einen Aufwand mitschneiden und manipulieren, da er sich bei euch im Netz befindet. Das nennt man im übrigen "Men in the middle", da hilft kein Virenscanner und kein Sicherhesbetriebssystem mehr, damit ist alles im Netzwerk gefallen.

[Roodkapke]

Ein bisschen zu paranoid meiner Meinung.
Da kann Mann wenn Mann das glaubt besser nichts am inet verbinden.
Phishing usw. kommt täglich vorbei wenn Mann übers inet geht.

[BuGless]

Wenn ich weis das sich hinter ein IP ein mir bekannter Dienst läuft, egal ob Updates oder FTP oder Wetterdaten oder EPG-Daten usw... dann kann ich die Dienste und Anfragen manipulieren und damit das Systemen kompromittieren, vor allem, wenn er die Daten wie bei dem OpenPli ungefilter nutzt und den Exploit dann sogar direkt als root ausführt.

Stimmt. Um dieses Problem ein zu kreisen muss man jetzt Entwicklerstunden einsetzen, und die kann man einsetzen in Sachen Kompartimentalisierung oder in Sachen Korrektur der Parsingroutinen dieser Daten so dass sie Bufferoverflow-frei sind und Fremddaten entsprechend als grundsaetzlich-unzuverlaessig betrachten. In Anbetracht dieses und die eher begrenzte Anzahl von verfuegbaren Entwicklerstunden kann man vermutlich die Zeit zuerst mal besser investieren in gezielte partielle Rewrites dieser Parsingroutinen. Damit wird es direkt korrekter, sicherer und effizienter.

Wenn man danach noch Zeit uebrich hat, ist Kompartimentalisierung der naechste Schritt.

Edited by BuGless, 18 November 2012 - 12:35.