Hallo Zusammen, ich würde gerne zuhause einen Raspberry Server laufen lassen. Diesen würde ich auch gerne über eine Remote-Verbindung mittels SSH übers Internet konfigurieren und erweitern können. Da dies einige Sicherheitsrisiken birgt, habe ich mir ein kleines Sicherheitskonzept überlegt und würde gerne eure Meinung zu diesem Konzept erfahren, da ich nicht ausreichend informiert bin, was für Möglichkeiten Hacker besitzen, um in mein System zu gelangen. Ich bin mehr in der Hardwareprogrammierung aktiv, deswegen habt bitte nachsehen mit mir :) Zu dem Server: Der Server soll ein einfacher TCP/IP-Server sein, der es mir ermgöglicht, auf Sensoren und Aktuatoren in meiner Wohnung zuzugreifen. Dieser Dienst soll 24/7 erreichbar sein. Kommuniziert wird dabei mit meinem Handy als Client und dem Raspberry-Server Das Sicherheitskonzept soll in erster Linie Hobby-Hacker davor abhalten, in mein System zu gelangen und mir als Übung bezüglich Systemsicherheit dienen, auch wenn das Konzept in mancher Hinsicht unter Umständen, als zu übertrieben und aufwendig dargestellt ist. Zu dem Konzept: Da eine SSH-Schnittstelle ein "Offenes Tor" in das System darstellt, will ich den Zugriff möglichst sicher gestalten. Deshalb soll die SSH-Schnittstelle mittels TCP/IP-Commands an- bzw. abgeschaltet werden können. Somit kann ich entscheiden, wann überhaupt eine SSH-Verbindung möglich ist. Weiterhin soll das System ermitteln, ob ein Benutzer zwei mal im System angemeldet ist oder ob gerade ein zweiter Loginversuch gestartet wird, was zum direkten Abschalten des SSH-Dienstes führen soll. Da der TCP/IP-Server 24/7 erreichbar sein soll, ist es nun möglich für einen Angreifer sich als Client anzumelden und die SSH-Verbindung selbst zu aktivieren, vorausgesetzt er kennt die entsprechenden Commands. Aus diesem Grund wird ein Login-System eingefügt, mit dem ich mir zuerst die Rechte abholen muss, um Commands an den Server schicken zu können. Weiterhin wird jede Kommunikations mittels AES-Encryption verschlüsselt. Somit dürfte ich von Angriffen von einem "Man In The Middle" weitestgehen geschützt sein. Nun besteht noch Gefahr von Angreifern, die sich z.B. bereits im System meines Handys befinden könnten. Diese können meine Anwendung Decompilieren und den Verschlüselungs-Key nachvollziehen, die Kommunikation entschlüsseln, die Kommands zur SSH-Verbindung schnüffeln und die SSH-LoginDaten Bruteforcen. Aus diesem Grund kann sich der Schlüssel auf externer Hardware befinden, z.B. einem kleinen µC. Diesem schicke ich die Nachricht als Klartext per USB, der verschlüsselt meine Nachricht und gibt diese verschlüsselte Nachricht an mein Handy zurück. Somit ist der Schlüssel schon mal sicher auf einer externen Hardware verwahrt. Wobei dies wahrscheinlich nur Pseudo-Sicherheit bietet, da der Angreifer sieht, welche Nachricht ich an den µC schicke und welche Antwort ich daraufhin zurück bekomme. Somit kann er sich einen Zusammenhang zw. verschlüsselte und unverschlüsselte Nachricht zusammenreimen und die verschlüsselten Nachrichten als Klartext an den Server schicken. Dies sollte es erstmal zu meinem Konzept gewesen sein. Manche Schritte dürfte wahrscheinlich zu übertrieben sein, um einen "Hobby-Hacker" vom System fern zu halten, aber ich sehe dieses Projekt wie bereits erwähnt, als eine kleine Übung. Mich würde nun eure Meinung zum Konzept interessieren und ich würde mich über Feedback und konstruktive Kritik freuen.
:
Verschoben durch User
Forum Projekte: Hier könnt ihr eure Projekte, Schaltungen oder Codeschnipsel vorstellen und diskutieren. *Bitte hier keine Fragen posten!*
900ss D. schrieb: > Hier könnt ihr eure Projekte, Schaltungen oder Codeschnipsel vorstellen > und diskutieren. > *Bitte hier keine Fragen posten!* Das ist mein Projekt, über das ich gerne Diskutieren würde. Was ist also falsch daran? Soll ich jetzt 10 Wörter in meinem Text ändern, damit es hier rein passt?
Das sieht schon ganz gut aus, ich würde jedenfalls dran verzweifeln :)
Zum Login / SSH-Bruteforce kannst du auch Fail2Ban einsetzen. So wird die IP-Adresse des Angreifers per iptables für einen gewissen Zeitraum gesperrt, wenn korrekt eingestellt. Tutorials sind dazu auch im Netz haufenweise zu finden, außerdem kann nicht nur SSH damit vor Bruteforce besser geschützt werden als ohne dieses Stück Software. Dazu kann auch ein alternativer SSH-Port schon vor einem Großteil von Zugriffsversuchen schützen.
Man sollte jedenfalls die Kontrolle über seine Sachen behalten. Dazu wäre z.B. eine Antwort: "Letztes Login Nr.4713 am 24.12.2019 17:43" schon ein schöner Hinweis. Wenn dann zu viele Logins waren, kannst Du ja die Schnittstelle abklemmen.
RogerGER schrieb: > Da eine SSH-Schnittstelle ein "Offenes Tor" in das System darstellt, > will ich den Zugriff möglichst sicher gestalten. > Deshalb soll die SSH-Schnittstelle mittels TCP/IP-Commands an- bzw. > abgeschaltet werden können. Schau mal nach dem Stichwort "Port Knocking", das hat sich bewährt, gibt es fertige Toolkits für. > Weiterhin soll das System ermitteln, ob ein Benutzer zwei mal im System > angemeldet ist oder ob gerade ein zweiter Loginversuch gestartet wird, > was zum direkten Abschalten des SSH-Dienstes führen soll. Keine gute Idee: Sagen wir Du kommst mit Deinem Handy in ein Funkloch, dabei wird Deine bestehende SSH-Session unterbrochen und nicht sauber beendet. Durch die TCP-Timeouts bleibt die aber noch ne ganze Weile auf dem Server aktiv. Du bist aus dem Funkloch raus, Dein Handy meldet sich wieder am LTE etc. an, bekommt ne neue IP und mit der baust Du jetzt eine neue SSH-Verbindung auf -> Bumm, ausgesperrt. Das Port-Knocking (siehe oben) macht das SSH nur für eine IP auf, nicht für alle. Kaum ein Angreifer wird warten bis Du Dich einloggst, auch das Mobilfunknetz gehackt haben damit er die selbe IP wie Dein Handy bekommt um dann die SSH-Verbindung zu versuchen. > Da der TCP/IP-Server 24/7 erreichbar sein soll, ist es nun möglich für > einen Angreifer sich als Client anzumelden und die SSH-Verbindung selbst > zu aktivieren, vorausgesetzt er kennt die entsprechenden Commands. > Aus diesem Grund wird ein Login-System eingefügt, mit dem ich mir zuerst > die Rechte abholen muss, um Commands an den Server schicken zu können. > Weiterhin wird jede Kommunikations mittels AES-Encryption verschlüsselt. Mach es nicht zu kompliziert. Desto mehr selbstentwickelte, komplexe Software, desto größer die Chance für Fehler im Konzept und Programm. > Nun besteht noch Gefahr von Angreifern, die sich z.B. bereits im System > meines Handys befinden könnten. Ja, das ist viel realistischer als die anderen Varianten. > Aus diesem Grund kann sich der Schlüssel auf externer Hardware befinden, gute Idee. > z.B. einem kleinen µC. Setz lieber auf bekannt gute Lösungen. Entweder Smartcards wie die GnuPG-Card oder Lösungen wie Yubikey oder Gnuk. Kein Bluetooth oder NFC zwischen Handy und Token/Karte. Denn da gibt es noch keine Standards die diese Verbindung verschlüsseln. Daher das Token/Reader immer per USB ans Handy anschließen. Ein Token verwenden, bei dem Du eine Pin eingeben musst oder zumindest eine Taste am Token selber drücken um die Auth freizugeben. Das setzt ein Handy voraus, bei dem Du genug Möglichkeiten zum einbinden passender Treiber etc. hast, iOS kannst Du also vergessen, eher Lineage.
:
Bearbeitet durch User
Wenn man am Ball bleibt und für Updates sorgt, ist schon reines SSH serverseitig eine ziemlich sichere Angelegenheit. Zertifikate oder gute Passwörter vorausgesetzt. Zusätzliche serverseitige Verfahren zur Absicherung sind gut, aber nicht absolut zwingend. RogerGER sieht ein Problem berechtigterweise auch auf der Seite des Clients. Im Abschnüffeln der Zugangsinformation.
:
Bearbeitet durch User
Fail2Ban + sshd reicht eigentlich. Selbstgebastelte Lösungen, die dir den sshd Dienst erst starten, könnten selbst eine Sicherheitslücke darstellen, deswegen würde ich das lassen. Zusätzlich würde ich noch den IP Adressraum einschränken. Du wirst dich bspw. wohl kaum mit deinem Handy mit einer chinesischen IP Adresse in deinen Server einloggen. Also kannst du ganze IP Räume per Firewall blocken. Es gibt im Internet dafür IP Adressraumlisten, die den jeweiligen Ländern zugewiesen sind. Wenn du steuern willst, ob dein sshd Server laufen soll oder nicht, dann würde ich das ganz anders lösen. Gib deinem Server Zugriff auf einen kostenlosen Clouddienst. Dort soll er regelmäßig nach einer Datei suchen. Ist diese Datei vorhanden, dann soll er den sshd Server starten, ist sie nicht vorhanden, dann soll der Server nicht gestartet werden bzw. falls er schon gestartet ist, beendet werden. Du selbst müsstest dich also von deinem Handy zuerst in deiner Cloud einloggen, die Datei uploaden, etwas warten bis dein Server das bemerkt und den sshd Dienst hochfährt und dann könntest du dich per sshd einloggen. Diese Datei kannst du auch öffentlich verfügbar machen, dann braucht dein sshd Server kein PW für den Zugriff zur Cloud. Vorraussetzung dafür wäre allerdings, dass er die Datei immer unter der gleichen URL finden kann. Wenn du noch etwas Sicherheit oben drauf setzten willst, dann könntest du die Datei per OpenPGP Verfahren verschlüsseln und der Server kann sie dann auswerten, in dem er sie mit seinem private Key entschlüsselt. Und je nach dem was da drin steht, kann der Server dann verschiedene Dinge tun. Wie bspw. sshd Server starten, beenden oder irgendwas anderes. Der Vorteil dieser Lösung ist, dass die Clouds in der Regel besser geschützt sind und du so trotzdem deinen sshd Server nur auf Anfrage bei Bedarf einschalten kannst. Sieh auch noch zu, dass dein Raspi Zuhause möglichst in einer DMZ läuft und das private LAN vor diesem sicher ist. Außerdem muss man beim Raspi selbst noch ein paar Änderungen vornehmen, wie bspw. dem root account ein PW vergeben usw.. Alternativ dazu könntest du dem Raspi auch ein GSM Modul geben und dessen SSH Dienst per SMS einschalten. Das wäre ein alternativer Weg zum Internet. Ansonsten würde ich auf dem Raspi noch alles per FW blocken, außer dem Port für den ssh Dienst und was du sonst noch brauchst. Die Anzahl der Dienste, die per UDP oder TCP erreichbar sind, solltest du auf das nötigste einschränken. Für den Fall das dein Raspi trotzdem kompromitiert ist, solltest du zusehen, dass dein Router vor ihm geschützt ist. Den Router also nur zum weiterleiten nutzen und direkte Anfragen vom Raspi an ihn blocken. Das größte Problem dürften hier die Router selbst sein, denn viele Homerouter lassen sich leider nicht so flexibel konfigurieren. Aber wenn du die Möglichkeit dazu haben solltest, dann kannst du damit auch noch die Sicherheit erhöhen. Die Verwendung einer IDS und IPS wäre auch noch eine optionale Möglichkeit. Und immer darauf achten, dass der Raspi regelmäßig seine Updates bekommt. Also mindestens einmal täglich.
Nano schrieb: > Und immer darauf achten, dass der Raspi regelmäßig seine Updates > bekommt. Also mindestens einmal täglich. Nicht jedes Update muß glücklich machen? Es gab auch Fehlschläge.
oszi40 schrieb: > Nano schrieb: >> Und immer darauf achten, dass der Raspi regelmäßig seine Updates >> bekommt. Also mindestens einmal täglich. > > Nicht jedes Update muß glücklich machen? Es gab auch Fehlschläge. Das ist leider richtig. In dem Fall sollte man eine Distribution wählen, in der das Qualitätsmanagement passt. Da der Raspi ohnehin ein Debian stable anbietet, sehe ich da jetzt allerdings nicht so ein großes Problem.
oszi40 schrieb: > Nicht jedes Update muß glücklich machen? Es gab auch Fehlschläge. Automatische Updates sind Fluch und Segen zugleich. Man kann sie über den gleichen Weg auch manuell machen. Ist dann ist mehr routinemässige Arbeit: Man muss dicht am Ball bleiben und mehr oder weniger täglich sichten, welche Probleme grad anstehen, ob man reagieren muss.
Meiner Meinung nach ist das leider ziemlicher Unsinn :/ RogerGER schrieb: > Da eine SSH-Schnittstelle ein "Offenes Tor" in das System darstellt, > will ich den Zugriff möglichst sicher gestalten. Wie kommst du auf diese Idee? Ein OpenSSH-Daemon ist vermutlich so mit die sicherste Remote-Schnittstelle, die du dir ausdenken kannst, wenn du Passwort-Authentifizierung ausschaltest. Auf jeden Fall ist ssh tausendmal sicherer als alles, was du dir selber basteln kannst. > Deshalb soll die SSH-Schnittstelle mittels TCP/IP-Commands an- bzw. > abgeschaltet werden können. Sprich, du vertraust hier deinem eingenen Service mehr als OpenSSH? Das ist nicht sinnvoll. > Aus diesem Grund wird ein Login-System eingefügt, mit dem ich mir zuerst > die Rechte abholen muss, um Commands an den Server schicken zu können. Aka, du hast das ssh-Loginsystem, was seit 30 Jahren von den fähigsten Leuten der Welt auf sicher gebaut wird, durch dein eigenes ersetzt und denkst jetzt das ist sicherer? > Weiterhin wird jede Kommunikations mittels AES-Encryption verschlüsselt. > Somit dürfte ich von Angriffen von einem "Man In The Middle" > weitestgehen geschützt sein. AES authentifiziert das Gegenüber nicht. Gegen MITM-Angriffe hilft das also eher nicht, bzw. man muss sich genau überlegen gegen was es hilft. Wenn solltest du TLS verwenden. > Aus diesem Grund kann sich der Schlüssel auf externer Hardware befinden, > z.B. einem kleinen µC. Diesem schicke ich die Nachricht als Klartext per > USB, der verschlüsselt meine Nachricht und gibt diese verschlüsselte > Nachricht an mein Handy zurück. Somit ist der Schlüssel schon mal sicher > auf einer externen Hardware verwahrt. Das ist ein Hardware-Kryptomodul, das kann schon sinnvoll sein. Gibts aber zu kaufen, z.B. in Form des Yubikey. > Mich würde nun eure Meinung zum Konzept interessieren und ich würde mich > über Feedback und konstruktive Kritik freuen. Ist nicht böse gemeint, aber: vergiss das alles. Installier' einfach OpenSSH und konfiguriere es ordentlich (Passwort-Authentifizierung ausschalten, ECC/RSA-Key mit Passphrase verwenden). Wenn du paranoid bist, ist der nächste Schritt, deinen ssh-Key auf einem Hardware-Kryptomodul abzulegen (was du aber ebenfalls auf keinen Fall selber entwickeln willst). Ein anderer sinnvoller Paranoia-Schritt ist noch, Handy und Server in ein VPN zu tun. Alles andere was du tust macht das System garantiert unsicherer. Kryptographie macht man nie, nie selber, wenn man es irgendwie vermeiden kann. Man macht es immer falsch.
:
Bearbeitet durch User
Ich nutze SSH inzwischen nicht mehr direkt, sondern über (Open-)VPN. Das VPN dient auch dazu, dass man mit diversen Firewalls keine Probleme hat, indem man einen Port nutzt, der meist offen ist (z.B. HTTPS, PO3S oder IMAPS). Von dort aus kann man sich via SSH als ein Nutzer einloggen, der praktisch keine Rechte hat. Und von da aus via su zum eigentlichen Account. Ich halte das für relativ sicher und auch die SSH-Logs sind überschaubar. Wenn allerdings der Client kompromittiert ist, hilft das alles nicht mehr. Jörg
Sven B. schrieb: > Ist nicht böse gemeint, aber: vergiss das alles. Installier' einfach > OpenSSH und konfiguriere es ordentlich (Passwort-Authentifizierung > ausschalten, ECC/RSA-Key mit Passphrase verwenden). Genau das, OpenSSH noch regelmäßig updaten, dann ist gut. Deine Schnittstelle per ssh port forwarding lokal auf deinen rechner tunneln, und dann hast du authentication und authorization ebenfalls gelöst. Dazu fail2ban und glücklich sein. Funktioniert hier seit mehreren Jahren auf vielen Rechnern.
Die Ein und -Ausschaltoption über die Config eines Links auf einer Cloud oder einem HTTP Server hätte zumindest den Vorteil, dass man in Notfällen den ssh Server durch einen 2. Weg ausschalten kann, wenn man keine Updates einspielen kann oder dieses fehlt schlägt oder es noch keine Updates gibt oder der ssh Server mit der eigenen IP nicht erreichbar ist. Als Config Datei wäre bspw. eine XML, JSON oder INI ähnliche Datei mit einfachem Schlüssel Wertepaar sinnvoll. Bsp: sshd=on until="22:00 23.11.2019" Diese Datei könnte man dann unter einem festen Namen dann mit dem Public Key des Servers verschlüsseln und öffentlich auf der Cloud plazieren. Der Server schaut dann per polling regelmäßig nach und lädt sie runter, wenn er sie gefunden hat. Dann entschlüsselt er sie und ein Skript wertet sie aus. Je nach dem welcher Wert ein Key z.b. der sshd Server hat, wird er dann ein oder ausgeschaltet. Mit der Zeitfunktion kann man ihm dann auch sagen, wann er den Dienst wieder ausschalten soll. Natürlich wäre so auch das ein oder ausschalten weiterer Dienste, bspw. vpn usw. möglich. Um die Cloud muss man sich in der Regel nicht selbst kümmern, sollte sie aber kompromittiert werden, dann kann der Angreifer mit der Datei nichts anfangen, da er sie nicht enschlüsseln kann. Sollte der public Key geklaut werden, dann könnte er zwar eine neue uploaden, vorausgesetzt, er weiß, was für Key Werte Paare er da reinschreiben muss, aber dagegen gibt es auch ein Heilmittel. Man könnte die Datei noch mit dem eigenen privaten Key signieren. In dem Fall muss der Server zwei Dateien downloaden, die Datei und die Signatur. Die Datei kann er dann durch die Signatur prüfen. Auf dem Server muss man dazu vorher lediglich noch den public key des Clients deponieren. Prinzipiell kann man so ein Verfahren auch nutzen, wenn man den SSH Dienst nur benötigt um einfache Aufgaben durchzuführen, die sich auch mit einem Key Werte Paar abbilden und vorher testen ließen. Die Sicherheit wäre damit auch höher, weil man nicht gleich eine Shell zur Verfügung stellen muss.
Nano schrieb: > Die Ein und -Ausschaltoption über die Config eines Links auf einer Cloud > oder einem HTTP Server hätte zumindest den Vorteil, dass man in > Notfällen den ssh Server durch einen 2. Weg ausschalten kann, wenn man > keine Updates einspielen kann oder dieses fehlt schlägt oder es noch > keine Updates gibt oder der ssh Server mit der eigenen IP nicht > erreichbar ist. Dafür gibt es die Adminkonsole des Hosters bzw. dessen Telefonhotline.
Sven B. schrieb: > Nano schrieb: >> Die Ein und -Ausschaltoption über die Config eines Links auf einer Cloud >> oder einem HTTP Server hätte zumindest den Vorteil, dass man in >> Notfällen den ssh Server durch einen 2. Weg ausschalten kann, wenn man >> keine Updates einspielen kann oder dieses fehlt schlägt oder es noch >> keine Updates gibt oder der ssh Server mit der eigenen IP nicht >> erreichbar ist. > > Dafür gibt es die Adminkonsole des Hosters bzw. dessen Telefonhotline. In seinem Fall ist es ein Raspberry Pi Zuhause. Da wird kein Hoster und kein Admin verfügbar sein, wenn er eine Weltreise oder ein vorübergehenden Wechsel in die Zweitwohnung aus beruflichen Gründen oder vergleichbares durchführen möchte bzw. muss.
Nano schrieb: > Sven B. schrieb: >> Dafür gibt es die Adminkonsole des Hosters bzw. dessen Telefonhotline. > > In seinem Fall ist es ein Raspberry Pi Zuhause. Naja, ok, stimmt, hatte ich schon wieder vergessen. Trotzdem weiß ich nicht, was das ganze Ein- und Ausgeschalte von ssh soll. Was verspricht man sich davon? Die zusätzliche Komplexität vergrößert nur die Angriffsfläche.
Das kommt darauf an was er vor hat. Bei einer Atlantiküberquerung in der Segelyacht könnte das Satellitentelefon ausfallen. Zur gleichen Zeit könnte eine Sicherheitslücke in sshd bekannt werden. Wie macht er jetzt das update? In dem Fall geht es nicht. Hat er aber sshd vor der Abreise auf den Kanaren abgeschaltet, dann kann er diesen Dienst mit der Methode in Antigua wieder einschalten und updaten, wenn er da ankommt. Die Sicherheit leidet durch so eine Methode in keinster Weise, sie wird sogar erhöht und sshd lässt sich ohnehin per systemd start oder stop Befehl ein und ausschalten. Soviel Komplexität kommt da im Skript, das die config auswertet, nicht hinzu.
Nano schrieb: > Diese Datei könnte man dann unter einem festen Namen dann mit dem Public > Key des Servers verschlüsseln und öffentlich auf der Cloud plazieren. Nur bohrt man genau so schon selbst ein Loch. Indem sich der Server sein potentielles Problem freiwillig reinzieht. Zumindest vom Begriff her ist in deiner Beschreibung beides öffentlich, Schlüssel wie Cloud, kann also jeder machen.
:
Bearbeitet durch User
Jo, aber das hattest du als optional beschrieben. ;-) Das ist ja das Fiese an solchen Szenarien. Jedes Fitzelchen, das man sich zusätzlich zum 08/15-Schema ausdenkt, wird zum potentiellen Risiko.
:
Bearbeitet durch User
Ach noch etwas, niemand zwingt dich einen public key öffentlich zu machen, es genügt in diesem Fall wenn ihn der Client hat und so war das auch beschrieben. Ein public heißt nur so, weil er der Teil des Schlüsselpaares ist, der weitergegeben werden kann, anders als der private key.
A. K. schrieb: > Jo, aber das hattest du als optional beschrieben. ;-) Er wurde aber auch nicht veröffentlicht, da ihn nur der Client hat. Im Prinzip ist es also ausreichend. Wenn es dem Angreifer gelingt, den public key des servers vom client zu stehlen, dann gelingt ihm das auch mit dem private key des clients der zum signieren benutzt wird.
A. K. schrieb: > Das ist ja das Fiese an solchen Szenarien. Jedes Fitzelchen, das man > sich zusätzlich zum 08/15-Schema ausdenkt, wird zum potentiellen Risiko. Da ist kein Risiko.
Nano schrieb: > A. K. schrieb: > Jo, aber das hattest du als optional beschrieben. ;-) > > Er wurde aber auch nicht veröffentlicht, da ihn nur der Client hat. Im > Prinzip ist es also ausreichend. > Wenn es dem Angreifer gelingt, den public key des servers vom client zu > stehlen, dann gelingt ihm das auch mit dem private key des clients der > zum signieren benutzt wird. Ach noch vergessen: Und wenn er im Client drin ist, dann bietet ssh auch keinen Schutz mehr. :)
Nano schrieb: > Da ist kein Risiko. Oh doch: Wie holst Du die Datei von dem fremden Server? Per HTTP oder HTTPS, z.B. mit curl oder wget? Dann kann im curl selbst oder einer davon verwendeten Lib eine Lücke sein, die es einem kompromittiertem Server erlaubt, auch den Client zu übernehmen. Oder wenn Du die Datei einmal hast, wie interpretierst Du sie? Wenn es eine JSON ist z.B. mit jq. Dann kann da auch eine Lücke drin sein, die, wenn sie mit den richtig präparierten Daten in Kontakt kommt, auch wieder erlaubt Code auszuführen. Du verschiebst so nur das Problem von der einen Stelle an eine andere und gewinnst nix dabei, machst dafür aber die normale Administration wesentlich schwieriger.
:
Bearbeitet durch User
Gerd E. schrieb: > Nano schrieb: > Da ist kein Risiko. > > Oh doch: > > Wie holst Du die Datei von dem fremden Server? Per HTTP oder HTTPS, z.B. > mit curl oder wget? Dann kann im curl selbst oder einer davon > verwendeten Lib eine Lücke sein, die es einem kompromittiertem Server > erlaubt, auch den Client zu übernehmen. Der Client uploadet die Datei auf die Cloud, die meinst du wohl mit "fremder Server" Wenn die Cloud durch Downloads mit Downloadclients diese gefährden soll, dann ist da nicht der Clientrechner betroffen. Und wenn du dir um Downloadclients sorgen machst, dann solltest du dir auch über sshd Sorgen machen. > > Oder wenn Du die Datei einmal hast, wie interpretierst Du sie? Wenn es > eine JSON ist z.B. mit jq. Dann kann da auch eine Lücke drin sein, die, > wenn sie mit den richtig präparierten Daten in Kontakt kommt, auch > wieder erlaubt Code auszuführen. Die Datei ist verschlüsselt. Kompromittiere erst einmal die Verschlüsselung, ehe du über präparierte key value Paare nachdenkst. Zumal so eine Auswertung ordentlich programmieren kann. > > Du verschiebst so nur das Problem von der einen Stelle an eine andere Nein ich erweitere die Funktionalität und erhöhe due Sicherheit. Siehe das Beispiel mit der Atlantiküberquerung, ein Fall wo die Funktionalität von ssh nicht genügt. > und gewinnst nix dabei, Stimmt nicht.Ein Beispiel habe ja genannt. >machst dafür aber die normale Administration > wesentlich schwieriger. Ich finde das jetzt nicht schwierig. Analogie: Eine Fräse funktioniert auch ohne not-aus Schalter, aber mit ist sicherer.
Nano schrieb: > Das kommt darauf an was er vor hat. Bei einer Atlantiküberquerung in der > Segelyacht könnte das Satellitentelefon ausfallen. Zur gleichen Zeit > könnte eine Sicherheitslücke in sshd bekannt werden. Wie macht er jetzt > das update? > In dem Fall geht es nicht. Wer solche Sicherheitsansprüche hat darf eben seinen Server nicht 3 Wochen unbeaufsichtigt im Internet hängen lassen. Die Lücke könnte auch im TCP Connection Handling vom Linux-Kernel sein, dann bringt dir dein Skript nichts. Wahrscheinlich ist das Angrifssszenario für den Raspberry Pi-Server ohnehin eher nicht. > Die Sicherheit leidet durch so eine Methode in keinster Weise, sie wird > sogar erhöht und sshd lässt sich ohnehin per systemd start oder stop > Befehl ein und ausschalten. > Soviel Komplexität kommt da im Skript, das die config auswertet, nicht > hinzu. Das ist ein Trugschluss. Alleine wenn das Skript irgendwie ein wget auf eine https-URL macht, ist die nach außen sichtbare (und damit angreifbare) Komplexität vermutlich schon höher als die des kompletten sshd. Vergleiche dazu z.B. mal die CVE-Listen von sshd und wget. > Die Datei ist verschlüsselt. Kompromittiere erst einmal die > Verschlüsselung, ehe du über präparierte key value Paare nachdenkst. Genau, aber von dir verschlüsselt, und es ist eine plausible Annahme dass du dabei eher was falsch gemacht hast als sshd. Ich verstehe die Intention, irgendwie 2 Layer von Zugriffskontrolle zu haben, aber ich denke es gibt genau eine (gängig genutzte und einfache) Möglichkeit für das zweite Layer: ein VPN, in dem sich Server und Computer für den Zugriff befinden. Es ist z.B. instruktiv, sich ein paar Vorträge über Krypto-Zeug vom CCC anzuschauen. Da gibt es wirklich gut gemeinte und scheinbar auch gut gemachte kryptographische Modelle für Zugriffskontrolle oder was auch immer, und die Leute finden irgendein winziges Detail, was vergessen oder übersehen wurde und zack, ist das ganze System kaputt. Anders als bei den allermeisten Dingen auf der Welt genügt "joa, ist im Wesentlichen ganz clever" eben nicht. Deshalb: nicht selber machen.
:
Bearbeitet durch User
Nano schrieb: > Die Datei ist verschlüsselt. Dann verwendest Du entweder irgendeine Crypto-Lib oder -Programm oder hast die gesamte Crypto komplett selbst geschrieben. Sagen wir mal Du nimmst GnuPG zum verschlüsseln. Was ist, wenn jetzt in GnuPG ein Bug ist, der dafür sorgt, daß Du mit passend präparierten Daten Code ausführen kannst? Dann hast Du mit Deinem Konzept mehr Löcher gerissen als gestopft. Leider ist Sicherheit nicht ganz so einfach zu bekommen. Sven B. schrieb: > Deshalb: nicht selber machen. ganz richtig.
Sven B. schrieb: > Das ist ein Trugschluss. Alleine wenn das Skript irgendwie ein wget auf > eine https-URL macht, ist die nach außen sichtbare (und damit > angreifbare) Komplexität vermutlich schon höher als die des kompletten > sshd. Vergleiche dazu z.B. mal die CVE-Listen von sshd und wget. CVE Listen sagen nur aus, dass man sich um gefundene Sicherheitslücken kümmert und diese offiziell nummeriert, was gut ist. Sie sagen nichts darüber aus, ob der Code gut oder schlecht ist. > Da gibt es wirklich gut gemeinte und scheinbar auch gut > gemachte kryptographische Modelle für Zugriffskontrolle oder was auch > immer, und die Leute finden irgendein winziges Detail, was vergessen > oder übersehen wurde und zack, ist das ganze System kaputt. Anders als > bei den allermeisten Dingen auf der Welt genügt "joa, ist im > Wesentlichen ganz clever" eben nicht. Deshalb: nicht selber machen. Der Vergleich hinkt, weil ich gar kein neues Kryptoverfahren einführe, sondern ein bestehendes und allgemein bewährtes verwende. OpenPGP und eine Implementierung in Form von bspw. gnupg gibt es schon seit vielen Jahren und die Kryptoverfahren die es verwendet, sind standardisiert und schon von zig Kryptoexperten untersucht worden. Mit deinem VPN machst du nur einen weiteren Dienst dauerhaft auf, der von außen angegriffen werden kann. Das ist ein deutlich schlechteres Sicherheitskonzept, als für die Antlantiküberquerung einfach sshd zu beenden oder per Firewall den Port zu schließen. Und wenn der Bug tatsächlich im TCP Protokoll liegen sollte, dann hilft dir VPN da auch nicht.
Gerd E. schrieb: > Nano schrieb: >> Die Datei ist verschlüsselt. > > Dann verwendest Du entweder irgendeine Crypto-Lib oder -Programm oder > hast die gesamte Crypto komplett selbst geschrieben. Ich sprach von OpenPGP. Also was bewährtest, 1000 fach geprüft, hundertfach Code Audited usw.. > Sagen wir mal Du nimmst GnuPG zum verschlüsseln. Was ist, wenn jetzt in > GnuPG ein Bug ist, der dafür sorgt, daß Du mit passend präparierten > Daten Code ausführen kannst? Dann kann ich auch sagen, dass sshd einen Bug haben kann. Die beiden Programme sind von ihrer Verbreitung und Verwendung, Code Audits, Checks durch Kryptoexperten usw. gleichwertig anzusehen. Wenn also gnupg einen Bug hat, dann müsste ich auch bei sshd von einem Bug ausgehen, beides ist gleich Wahrscheinlich. > Dann hast Du mit Deinem Konzept mehr Löcher gerissen als gestopft. Überlege noch einmal, hier ein Vergleich: Hürden die ein Angreifer überwinden muss: 1. In die Cloud einbrechen um eine verschlüsselte Datei platzieren zu können. 2. den Bug von gnupg ausnutzen und dabei meinen Schlüssel und den public Key des Servers kennen um eine platzierte Config verschlüsseln und signieren zu können. 3. die Config kennen, wissen welche Werte sie haben darf und dann noch wissen, was man für einen präparieren Bytecode einbauen muss, damit das Script abstürzt und Code eingeschleust werden kann. Was übrigens schon ziemlich unrealistisch ist, wenn die Eingaben gut geprüft und die Möglichkeiten stark begrenzt sind. 4. Das Script zum Abstürzen bringen, wenn das bspw. Python ist, muss noch ein Bug im Python Interpreter dazugehören. 5. Code einschleusen und dabei die Sichereitsvorkehrungen des Kernels umgehen und root Rechte erlangen um Schaden zu verursachen. Bei einem kaputten sshd oder vpn sieht es dagegen so aus: 1. Die Lücke nutzen und eindringen, fertig. Im ersten Fall muss der Angreifer mindestens 5 Stufen überwinden, damit er Schaden verursachen kann. > Sven B. schrieb: >> Deshalb: nicht selber machen. > > ganz richtig. Was hier kein selber machen ist, da gnuPG und ein schlanker Downloadclient beide bewährt sind. Man muss hier auch nicht zwangsläufig kein komplexes Programm wie wget verwenden, das neben dem simplen Downloaden noch dutzend andere Features unterstützt, man kann hier auch was einfaches nehmen. Es ist sogar gut möglich, dass es sogar für Python stark verbreitete Libs oder Erweiterungen gibt, die eine simple Datei downloaden können, also schon alles fix und feritg mitliefern, dann benötigt man nichtmal ein externes Programm. Insofern, Leute, es geht nur um das Downloaden einer Config, deren Entschlüsselung und Signaturtest und ein auswerten dieser. Das ist keine große neue Sache und definitiv kein neues Kryptoverfahren. Würde ich nen eigenen Dienst programmieren würde, der dann auf Eingaben wartet, ja, dann würde das mit dem "nicht selber machen" greifen, aber in dem Fall trifft das überhaupt nicht zu.
Nano schrieb: > Sven B. schrieb: >> Das ist ein Trugschluss. Alleine wenn das Skript irgendwie ein wget auf >> eine https-URL macht, ist die nach außen sichtbare (und damit >> angreifbare) Komplexität vermutlich schon höher als die des kompletten >> sshd. Vergleiche dazu z.B. mal die CVE-Listen von sshd und wget. > > CVE Listen sagen nur aus, dass man sich um gefundene Sicherheitslücken > kümmert und diese offiziell nummeriert, was gut ist. > Sie sagen nichts darüber aus, ob der Code gut oder schlecht ist. Es geht auch nicht drum zu beurteilen ob der Code gut oder schlecht ist, sondern darum dass es auch in scheinbar trivialen Komponenten Fehler gibt. > Der Vergleich hinkt, weil ich gar kein neues Kryptoverfahren einführe, > sondern ein bestehendes und allgemein bewährtes verwende. Das tut keiner der anderen Leute, wenn du deine eigenen Kryptoverfahren erfindest, bist du eh komplett verloren. Die benutzen auch immer nur irgendwas bewährtes wie RSA, AES, etc. Aber auch beim zusammenstecken dieser Verfahren zu irgendeiner Logik, die irgendwas tut, kann man subtile Fehler machen. > Mit deinem VPN machst du nur einen weiteren Dienst dauerhaft auf, der > von außen angegriffen werden kann. Das ist ein deutlich schlechteres > Sicherheitskonzept, als für die Antlantiküberquerung einfach sshd zu > beenden oder per Firewall den Port zu schließen. Jetzt verwendest du dasselbe Argument, was du vorher selbst übergangen hast, falsch gegen mich. Ich erinnere dich an das, was du zu deinem eigenen Extra-Service gesagt hast: > Nein ich erweitere die Funktionalität und erhöhe due Sicherheit. Dazu ist das Argument bei dem VPN gar nicht richtig, weil du ja dann nicht zwei Services mit offenen Ports "VPN" und "sshd" auf deinem Pi laufen hast, sondern das VPN den Port für den sshd kapselt. Im schlimmsten Fall ist das VPN nutzlos, weil der Angreifer leicht reinkommt, dann ist er in derselben Lage wie ganz ohne das VPN.
:
Bearbeitet durch User
Sven B. schrieb: > Dazu ist das Argument bei dem VPN gar nicht richtig, weil du ja dann > nicht zwei Services mit offenen Ports "VPN" und "sshd" auf deinem Pi > laufen hast, sondern das VPN den Port für den sshd kapselt. Im > schlimmsten Fall ist das VPN nutzlos, weil der Angreifer leicht > reinkommt, dann ist er in derselben Lage wie ganz ohne das VPN. Nein, nicht unbedingt. Es kann auch eine Lücke im VPN-Dienst selber sein, mit der man z.B. direkt Code ausführen kann. Dann ist der Angreifer direkt drin und kann das ssh komplett umgehen. Was man aber natürlich machen könnte, wäre den VPN-Dienst und das SSH auf verschiedenen Rechnern laufen lässt. Der eine Rechner macht das VPN, der andere das SSH. Beide sind über ein nicht von außen erreichbares DMZ-Netz miteinander verbunden. Können natürlich auch verschiedene RasPis sein, dann braucht man aber USB-Ethernet-Adapter für die DMZ. Wenn jetzt eine Lücke im VPN-Dienst ist, kann der Angreifer zwar den ersten Rechner übernehmen und kann jetzt in der DMZ frei kommunizieren. Aber um den anderen Rechner zu übernehmen, muss er noch das ssh knacken. Dann habe ich die Sicherheit wirklich erhöht.
Sven B. schrieb: > Das tut keiner der anderen Leute, wenn du deine eigenen Kryptoverfahren > erfindest, bist du eh komplett verloren. Die benutzen auch immer nur > irgendwas bewährtes wie RSA, AES, etc. Aber auch beim zusammenstecken > dieser Verfahren zu irgendeiner Logik, die irgendwas tut, kann man > subtile Fehler machen. Es gibt einen großen Unterschied zwischen dem Selbstimplementieren von einem Verschlüsselungsverfahren wie bpsw. AES und dem verwenden eines bewährten Programms wie gnupg oder dessen Libs das sich für die Verschlüsselung und Entschlüsselung bewährt hat. Du fütterst gnupg mit einer Datei und raus kommt das entschlüsselte Ergebnis, wenn der Schlüssel passt. Das beim Füttern was schief geht ist realistisch betrachtet so gut wie unwahrscheinlich. Ist die Eingabe kaputt, dann schlägt die Entschlüsselung fehl. >> Mit deinem VPN machst du nur einen weiteren Dienst dauerhaft auf, der >> von außen angegriffen werden kann. Das ist ein deutlich schlechteres >> Sicherheitskonzept, als für die Antlantiküberquerung einfach sshd zu >> beenden oder per Firewall den Port zu schließen. > > Jetzt verwendest du dasselbe Argument, was du vorher selbst übergangen > hast, falsch gegen mich. Ich erinnere dich an das, was du zu deinem > eigenen Extra-Service gesagt hast: Bei mir läuft kein weiterer Dienst auf dem Server der an einem offenen Port lauscht. Bei dir steht: Port TCP 22 open Port UDP 1194 open Und zwei Dienste laufen dahiner, einmal sshd und einmal vpn. (EDIT: Okay, weiter unten gehe ich auf deinen Punkt mit nur einem Port ein) Bei mir steht: Port Range 0 - 65536 closed oder unknown Nach außen läuft kein Dienst. Ab und zu macht der Downloadclient einen Port zu einer ganz bestimmten Domain, nämlich dem Clouddienst für einen kurzen Moment auf. Die Firewall macht eine related Beziehung daraus. D.h. ein Angriff auf diesen Port könnte nur von diesem Clouddienst kommen, alle anderen Anfragen von anderen IP Adressen werden abgewiesen als wäre der Port closed. Man sieht also, eine Angriffsfläche ist von Außen praktisch nicht vorhanden. Während bei dir jeder Bot angreifen kann. >> Nein ich erweitere die Funktionalität und erhöhe due Sicherheit. > > Dazu ist das Argument bei dem VPN gar nicht richtig, weil du ja dann > nicht zwei Services mit offenen Ports "VPN" und "sshd" auf deinem Pi > laufen hast, sondern das VPN den Port für den sshd kapselt. Okay, dann ist eben nur der VPN Port offen. Das nützt dir aber nichts, wenn der VPN Dienst eine Sicherheitslücke hat und du durch diese beliebigen Code ausführen kannst. Das Problem ist dein Dienst läuft und ist von außen erreichbar und in den 3 Wochen auf dem Boot hast du keine Möglichkeit die Sicherheitslücke zu stopfen.
Gerd E. schrieb: > Was man aber natürlich machen könnte, wäre den VPN-Dienst und das SSH > auf verschiedenen Rechnern laufen lässt. Der eine Rechner macht das VPN, > der andere das SSH. Beide sind über ein nicht von außen erreichbares > DMZ-Netz miteinander verbunden. Können natürlich auch verschiedene > RasPis sein, dann braucht man aber USB-Ethernet-Adapter für die DMZ. > > Wenn jetzt eine Lücke im VPN-Dienst ist, kann der Angreifer zwar den > ersten Rechner übernehmen und kann jetzt in der DMZ frei kommunizieren. > Aber um den anderen Rechner zu übernehmen, muss er noch das ssh knacken. > > Dann habe ich die Sicherheit wirklich erhöht. Worin unterscheidet sich diese Bastellösung von meiner Lösung? Antwort: Es kann mindestens ein Rechner kompromittiert werden, wenn nur sshd oder vpn verwundbar ist. Bei mir sind es immer noch 6 Stufen die man überwinden muss. Wahrscheinlich scheitert der Angreifer schon beim ersten, nämlich beim Eindringen bei der Cloud. Spätestens bei der verschlüsselten oder signierten Datei gibt er auf.
Nano schrieb: > Spätestens bei der verschlüsselten oder signierten Datei gibt er auf. Korrektur, ich meine natürlich "und".
Nano schrieb: > Worin unterscheidet sich diese Bastellösung von meiner Lösung? "Bastellösung"? Das Aufteilen von Funktionen auf verschiedene Rechner und das Unterteilen von Netzen in kleinere DMZ-Segmente ist Stand der Technik. Sicherheitsrelevante Konfigurationsdateien von irgendwelchen Cloudservern herunterzuladen dagegen eher nicht. > Es kann mindestens ein Rechner kompromittiert werden, wenn nur sshd oder > vpn verwundbar ist. Und wenn bei Dir der eine Steuerdienst z.B. durch bestimmte Protokollfehler angreifbar ist, ist gleich der gesamte Rechner mit all seinen zu schützenden Daten offen. Wenn Du die Dienste auf verschiedene Rechner aufteilst, wird im Zweifelsfall nur die erste Stufe geknackt, dort sind aber keine so wichtigen Daten drauf. > Bei mir sind es immer noch 6 Stufen die man überwinden muss. Du lässt Dich von der hohen Zahl "6 Stufen" blenden. Schon an Deiner 2. Stufe reicht ein Fehler im HTTP-Handling etc. und es ist aus.
:
Bearbeitet durch User
Gerd E. schrieb: > Sven B. schrieb: >> Dazu ist das Argument bei dem VPN gar nicht richtig, weil du ja dann >> nicht zwei Services mit offenen Ports "VPN" und "sshd" auf deinem Pi >> laufen hast, sondern das VPN den Port für den sshd kapselt. Im >> schlimmsten Fall ist das VPN nutzlos, weil der Angreifer leicht >> reinkommt, dann ist er in derselben Lage wie ganz ohne das VPN. > > Nein, nicht unbedingt. Es kann auch eine Lücke im VPN-Dienst selber > sein, mit der man z.B. direkt Code ausführen kann. Dann ist der > Angreifer direkt drin und kann das ssh komplett umgehen. Ja, du hast Recht, es ist ein bisschen so-so. Je nach Fehler. Schon richtig dass das Argument nur in Gänze gilt wenn du das VPN auf eine andere Maschine tust.
Nano schrieb: > Du fütterst gnupg mit einer Datei und raus kommt das entschlüsselte > Ergebnis, wenn der Schlüssel passt. > Das beim Füttern was schief geht ist realistisch betrachtet so gut wie > unwahrscheinlich. > Ist die Eingabe kaputt, dann schlägt die Entschlüsselung fehl. Man bewundere dazu einfach die in den letzten 2 Jahren angefallenen kritischen Fehler in E-Mail-Programmen, die PGP verwenden: Microsoft hat direkt bei allen Nicht-HTML-Mails den unverschlüsselten Klartext mitgeschickt, wohl weil der Entwickler das Wort "Plaintext" missverstanden hat; und Thunderbird & Co konnte man dazu bringen, den Klartext nach dem Entschlüsseln in's Internet zu schicken indem man in einer Multipart-Komponente ein HTML-Tag nicht zugemacht hat. Beides hat mit der Kryptographie überhaupt nichts zu tun! In beiden Fällen war das Krypto richtig und es wird nur ein fertiges, fehlerfreies Tool aufgerufen. Im Gegenteil: Fehler im eigentlichen Kryptocode sind vergleichsweise selten. Die Fehler sind meist "dumm" und in irgendwas "einfachem". Aber klar, "das waren alles Noobs, uns würde sowas nie passieren!" ;) Denkt man sich. Stimmt aber nicht. > Bei mir läuft kein weiterer Dienst auf dem Server der an einem offenen > Port lauscht. Aber einer der Dateien aus dem Internet herunterlädt. Was entweder TLS verwendet oder gegen MITM-Angriffe verwundbar ist. > Okay, dann ist eben nur der VPN Port offen. > Das nützt dir aber nichts, wenn der VPN Dienst eine Sicherheitslücke hat > und du durch diese beliebigen Code ausführen kannst. > Das Problem ist dein Dienst läuft und ist von außen erreichbar und in > den 3 Wochen auf dem Boot hast du keine Möglichkeit die Sicherheitslücke > zu stopfen. Das ist richtig, wie gesagt wäre es sinnvoller den VPN-Client auf einen anderen Rechner zu tun.
:
Bearbeitet durch User
Gerd E. schrieb: > "Bastellösung"? > > Das Aufteilen von Funktionen auf verschiedene Rechner und das > Unterteilen von Netzen in kleinere DMZ-Segmente ist Stand der Technik. Dann hast du so eben auch meine Lösung damit als Nicht Bastellösung akzeptiert. Gerd E. schrieb: > Und wenn bei Dir der eine Steuerdienst z.B. durch bestimmte > Protokollfehler angreifbar ist, ist gleich der gesamte Rechner mit all > seinen zu schützenden Daten offen. Wie kommst du darauf? Entweder das Skript kann einen Dienst wie sshd einschalten oder nicht. Du schreibst in die Config ja nicht rein: zu_startender_dienst=sshd und übernimmst dann die Eingabe ungefragt mit einem start sshd sondern du prüfst ob sshd ein erlaubter Eintrag ist und startest dann bei true das, was fest als Startbefehl im Code steht. Also bspw. so (Pseudocode) switch(dienst) dienst == "sshd" dann "start sshd"; break; dienst == "vpn" dann "start vpn"; break; /* Man könnte auch blablub als Kennzeichnung schreiben, wenn auf blablub sshd gestartet werden soll * / dienst = "blablub" dann "start sshd"; break ... default mach nix. Gibt es also keinen Eintrag für dienstxy, dann kann dienstxy auch niemals gestartet werden. Es werden auch nicht irgendwelche beliebigen Scripte ausgeführt, weil das Script aus der Config keine Scripte übernimmt und ausführt. Den Aufwand mit Key Werte Paare und Abfrage ist ja schließlich nicht umsonst da. Es geht also nur das was erlaubt ist. Baust du in deine Switchanweisung deines Skripts folgendes ein: dienst == "unsichererDienst" dann "start meinselbstprogrammierterdienst" dann bist du selbst schuld. Wie etwas gestartet wird, das ist auf den diversen Distributionen in der Regel standardisiert. Im Prinzip ist so gut wie alles, was das Skript machen muss standardisiert. Würden wir zum Downloaden der Datei bspw. wget benutzen, dann würde ein Timer im Script laufen und dann einen Download triggern. Der Befehl der dann ausgeführt würde, wäre dann so etwas wie bspw. wget $url und wget $url2 wobei $url dann eine feste Adresse ist auf der man die Datei mit Namen bspw. config.ini.gpg und für $url2 config.ini.sig erwartet. Anschließend kommt die Signaturprüfung mit gnugpg zustande. Habe momentan gnupg nicht im Kopf, aber so etwas in der Art: gpg --verify config.ini.sig dürfte das sein. Liefert das Ding true zurück, dann wird entschlüsselt: gpg -d config.ini.gpg Jetzt muss das Script nur die Config Laden auswerten und nach obiger Switchanweisung die jeweiligen Dienste starten. Anschließend geht es zurück in die Timerloop. Sollte noch dabei stehen, das irgend ein Dienst zur Zeit x wieder beendet wird, dann wird das in der Timerloop erledigt. So in etwa. Das Script ist trivial, die Angriffsfläche praktisch nicht vorhanden. Steht in der config irgendwas wie: dienst=fab012149s....02431; Dann wird der Vergleich eher fehl schlagen, als dieser String dazu führen wird, dass die Bedingte Abfrage von bspw. Python kompromitiert wird und beliebiger Code ausgeführt werden kann. Man beachte hierbei auch, auch der Python Interpreter ist ein vielfach genutztes Stück Software. > Wenn Du die Dienste auf verschiedene Rechner aufteilst, wird im > Zweifelsfall nur die erste Stufe geknackt, dort sind aber keine so > wichtigen Daten drauf. Dann nutzt er deinen übernommenen Rechner eben für > 3 Wochen als Bot oder Bitcoinminer und du zahlst die Stromrechnung oder für den Schaden der daraus noch entstehen könnte. >> Bei mir sind es immer noch 6 Stufen die man überwinden muss. > > Du lässt Dich von der hohen Zahl "6 Stufen" blenden. Schon an Deiner 2. > Stufe reicht ein Fehler im HTTP-Handling etc. und es ist aus. Du übersiehst hier, so ein Angriff müsste in dem Fall von der Cloud erfolgen, denn die Verbindung ist per FW related. Andere IPs können nix machen. Der müsste also nicht bloß in deinen Account auf der Cloud eindringen, sondern die Cloud übernehmen, damit er dort Code ausführen kann um ein HTTP-Handling mit dem Downloadclient des Raspi zu stören. Wie wahrscheinlich ist das, das jemand root Zugang zur Google oder Microsoft Cloud erlangt und dann diesen dazu nutzt, den Raspi anzugreifen? Botnetze die erreichbare Dienste angreifen und bekannte oder gar unbekannte Sicherheitslücken ausnutzen sind dagegen ganz normal.
Nano schrieb: > Der Befehl der dann ausgeführt würde, wäre dann so etwas wie bspw. > wget $url > und > wget $url2 > > wobei $url dann eine feste Adresse ist auf der man die Datei mit Namen > bspw. config.ini.gpg und für $url2 config.ini.sig erwartet. Ich weise hier nochmal auf die deutlich krassere CVE-Liste für wget hin als für sshd. Ich denke, allein dieses wget hat schon ein größeres Potential angegriffen zu werden als ein richtig konfigurierter sshd. Als welcher Benutzer läuft das wget? Root? Hast du daran gedacht, dass ein Angreifer dir eine 500 GB große Datei in deine URL legen könnte? Das ist ein super DoS-Angriff, weil dein Skript, was deinen sshd startet, dann hängt. > Anschließend kommt die Signaturprüfung mit gnugpg zustande. > Habe momentan gnupg nicht im Kopf, aber so etwas in der Art: > gpg --verify config.ini.sig > dürfte das sein. Wobei man direkt mal die manpage zitieren kann: " Note: If the option --batch is not used, gpg may assume that a single argument is a file with a detached signature, and it will try to find a matching data file by stripping certain suffixes. Using this historical feature to verify a detached signature is strongly discouraged; you should always specify the data file explicitly." Hast du daran gedacht, dass gpg jetzt hier jeden Key akzeptiert, der irgendwann mal importiert wurde, also z.B. dass jeder deiner E-Mail-Kontakte auch so eine Signatur erzeugen kann? Ehrlich dran gedacht, ja? Du hattest im Kopf "jetzt muss ich hier noch meine Key-ID angeben, sonst verifiziert es zwar die Signatur aber nicht wer es eigentlich signiert hat", hast es aber aus Gründen der Einfachheit nicht hingeschrieben? Hast du daran gedacht, dass GPG zum Überprüfen einer großen Signatur (auch wenn sie falsch ist) unendlich lange rechnen könnte? Auch das ist ein super DoS-Angriff, der dich selbst aussperrt. > Das Script ist trivial, die Angriffsfläche praktisch nicht vorhanden. Klar. Trivial.
Sven B. schrieb: > Man bewundere dazu einfach die in den letzten 2 Jahren angefallenen > kritischen Fehler in E-Mail-Programmen, die PGP verwenden: Microsoft hat > direkt bei allen Nicht-HTML-Mails den unverschlüsselten Klartext > mitgeschickt, wohl weil der Entwickler das Wort "Plaintext" > missverstanden hat; und Thunderbird & Co konnte man dazu bringen, den > Klartext nach dem Entschlüsseln in's Internet zu schicken indem man in > einer Multipart-Komponente ein HTML-Tag nicht zugemacht hat. Der upload der verschlüsselten Datei auf die Cloud ist man selbst. Sollte man eine unverschlüsselte Datei auf die Cloud laden, dann hat man zwar den Aufbau der Config verraten, aber das bringt dem Angreifer nichts, da das Script von einer signierten und verschlüsselten Datei ausgeht und auch nur nach dieser sucht und diese dann entsprechend darauf testet. Thunderbird hat eine eigene HTML Engine bzw. die des Firefox. Das ist ein sehr komplexes Stück Software und nicht mit einem trivialen Skript vergleichbar. >> Bei mir läuft kein weiterer Dienst auf dem Server der an einem offenen >> Port lauscht. > > Aber einer der Dateien aus dem Internet herunterlädt. Was entweder TLS > verwendet oder gegen MITM-Angriffe verwundbar ist. Ja, die TLS Verbindung, aber die Verbindung ist durch die FW related und, das habe ich vergessen established iptables FW Regel nur von der Verbindung mit dem Clouddienst möglich. Oder kurz und einfach, die Firewall ist so eingestellt, das neue Verbindungen von außen gar nicht zugelassen werden.
Nano schrieb: > Oder kurz und einfach, die Firewall ist so eingestellt, das neue > Verbindungen von außen gar nicht zugelassen werden. Ja aber wie gesagt, du machst halt (als root, vermutlich!) TLS mit irgendeinem random Host. Das ist schon ok (außer der root-Teil), ich sage nur, die Angriffsfläche davon ist bereits vergleichbar mit der von ssh. Zu der Komplexität siehe meine Funde in deinem Trivialskript ...
:
Bearbeitet durch User
Nano schrieb: > Im Prinzip ist so gut wie alles, was das Skript machen muss standardisiert. Im Prinzip ist dein pc jetzt sicher. Und MITM solltest du bei FE related nochmal überdenken...
Schreib doch einfach mal so ein Skript, dann schauen wir uns das mal an und überlegen mal, was man damit alles anstellen kann.
Sven B. schrieb: > Ich weise hier nochmal auf die deutlich krassere CVE-Liste für wget hin > als für sshd. Ich denke, allein dieses wget hat schon ein größeres > Potential angegriffen zu werden als ein richtig konfigurierter sshd. Wie schon gesagt, das war nur ein Beispiel um zu zeigen, wie so ein Script aussehen kann. Du kannst auch einen anderen Client nehmen. > Als welcher Benutzer läuft das wget? Root? Nein, als extra User ohne besondere Rechte. Man muss natürlich dafür sorgen können, dass der zu startende Serverdienst mit seinen dafür vorgesehenen gestartet werden kann. Das Script ist auch nicht voll ausgewickelt, sondern erstmal nur grob veranschaulicht. So etwas, mit welchen Rechten was wie ausgeführt wird, muss natürlich entsprechend beachtet und auf das nötigste eingeschränkt werden. > Hast du daran gedacht, dass ein Angreifer dir eine 500 GB große Datei in > deine URL legen könnte? Das ist ein super DoS-Angriff, weil dein Skript, > was deinen sshd startet, dann hängt. Warum sollte das Script hängen? Gedacht habe ich zwar nicht daran, weil wie schon gesagt, das obige ist nur ein grober Entwurf wie das ungefähr aussehen könnte, und keine konkrete Umsetzung. Ich werde die auch nicht benötigen, sondern der TS. Im trivialsten Fall wird das Script die Datei wohl downloaden bis der Download fertig ist. Dass der sshd sofort verfügbar sein soll, davon bin ich sowieso nicht ausgegangen, weil ja die Config auf der Cloud plaziert wird und der Server sich das irgendwann in den nächsten 24 h runterladen wird. An eine konkrete Zeitplanung wie, um UTF 15:03 guckt der Server nach, dann wird um ca. UTF 15:04 der ssh Server erreichbar sein, also lad ich die Config erst um UTF 15:01 hoch, war nicht vorgesehen. Sondern eher, ich lade die Config hoch (es könnte bspw. UTF 1:00 sein). In der config habe ich eingestellt, dass der sshd Server um UTF 16:00 Uhr gestartet werden soll. Also guck ich um UTF 15:59 nochmal nach. Im übrigen ist das auch nicht relevant, denn wenn ich die Config uploaden muss, dann werde ich ja merken, dass jemand in die Cloud eingedrungen ist. Mit einer 2 Faktor Authentifizierung hol ich mir den Account zurück und ändere das Passwort, danach ist wieder gut. Und in der Zeit, in dem der Angreifer meinen Server mit einer platzierten Datei beschäftigt, wird das mich nicht betreffen. Im schlimmsten Fall führt der Server den Download bis zur Vollendung aus, prüft die Sig und schmeißt die Datei weg. Das skript würde dadurch nicht abstürzen und am nächsten Tag den Download wohl von neuem beginnen bis, ich das eben merke. Schlimmstenfalls wird vielleicht die Partition vollgeschrieben, falls keine Quote eingerichtet ist, spätestens dann wird das Skript nen Fehler merken dass die Platte voll ist, die Prüfung der Sig wird fehl schlagen, ansonsten passiert nicht viel. Aber ehrlich gesagt ist der Platz auf der Cloud begrenzt, insofern wird nicht einmal das passieren. Da du mich aber darauf hingewiesen hast, würde ich jetzt die Größe beim Download überprüfen lassen und eventuell noch ne Quota einrichten. Das ist jetzt also kein störendes Problem das den Server und das Skript irgendwie durcheinander bringen könnte. Allerschimmsten dringt er in die Cloud ein, nach dem ich meine Config upgeloaden habe und überschreibt sie mit seiner 500 GB Datei ehe der Server meine Config downgeladen hat. Am nächsten Tag werde ich das dann merken und korrigieren. >> Anschließend kommt die Signaturprüfung mit gnugpg zustande. >> Habe momentan gnupg nicht im Kopf, aber so etwas in der Art: >> gpg --verify config.ini.sig >> dürfte das sein. > > ... > Hast du daran gedacht, dass gpg jetzt hier jeden Key akzeptiert, der > irgendwann mal importiert wurde, also z.B. dass jeder deiner > E-Mail-Kontakte auch so eine Signatur erzeugen kann? Wie schon gesagt, ich müsste mir die gpg man Page genauer durchlesen, dann würde ich das auch beachten. Das man bei gpg nen Keyring hat ist mir durchaus klar. > Hast du daran gedacht, dass GPG zum Überprüfen einer großen Signatur > (auch wenn sie falsch ist) unendlich lange rechnen könnte? Auch das ist > ein super DoS-Angriff, der dich selbst aussperrt. Ich habe mal ne 600 MB ISO auf nem 1 GHz Athlon verschlüsselt, das hielt sich von der Dauer in Grenzen. Auf die Cloud passen bei der MS Cloud nur 5 GB, mehr kann er nicht platzieren. Und wie ich oben schon geschrieben habe, gehe ich nicht von einer sofortigen Verfügbarkeit des sshd servers aus. Aber ich gebe zu, es macht Sinn eine Abbruchbedingung schon beim Download einzubauen um die Größe auf das, was für eine Configdatei plausibel ist zu begrenzen. >> Das Script ist trivial, die Angriffsfläche praktisch nicht vorhanden. > > Klar. Trivial. Du hast mir noch keinen Angriff genannt der meinen Server kompromittiert. Und der DOS ist kaum relevant.
Sven B. schrieb: > Nano schrieb: >> Oder kurz und einfach, die Firewall ist so eingestellt, das neue >> Verbindungen von außen gar nicht zugelassen werden. > > Ja aber wie gesagt, du machst halt (als root, vermutlich!) TLS mit > irgendeinem random Host. Das ist schon ok (außer der root-Teil), Nein, wie schon gesagt kein root. Daran habe ich schon gedacht. > > Zu der Komplexität siehe meine Funde in deinem Trivialskript ... Viel gefunden hast du leider nicht, außer dem DOS, der in dem Fall kaum eine Rolle spielt und durch den Platz auf der Cloud begrenzt ist.
J. S. schrieb: > Nano schrieb: >> Im Prinzip ist so gut wie alles, was das Skript machen muss standardisiert. > > Im Prinzip ist dein pc jetzt sicher. > Und MITM solltest du bei FE related nochmal überdenken... Ja, established kommt eventuell noch dazu, eventuell auch new, es ist schon länger her, dass ich mir eine iptables FW eingerichtet habe. Fest steht aber, dass ich genau gesagt, was ich bezüglich der FW meine. Nämlich nur die Cloud, durch die von meinem Server geöffnete Verbindung und sonst nix. Die Details der iptables FW Regel kann man sich dann genauer ansehen, wenn es um eine konkrete Umsetzung geht.
Sven B. schrieb: > Schreib doch einfach mal so ein Skript, dann schauen wir uns das mal an > und überlegen mal, was man damit alles anstellen kann. Der obige grobe "Ungefähr So"-Entwurf muss reichen, für ein konkretes Skript fehlt mir die Zeit. Ich muss noch ein paar andere Sachen machen. Z.B. wartet ne Bugmeldung für ne Distri, die ich unbedingt schreiben wollte, schon seit 6 Wochen und ich bin zu der auch noch nicht gekommen. Dazu noch eine Reihe weiterer Projekte in meiner Freizeit. Zumal ich ein konkretes Skript jetzt auch nicht brauche. Aber der TS könnte eines schreiben, dann helfe ich gerne mit das bei Bedarf auszubessern. :) Der grobe Entwurf ist ja schon mal ein Anfang wo man ansetzen könnte.
Noch eine kleine Erängzung zum Skript. Bezüglich dem Zeitpunkt wann ein Dienst gestartet und wieder beendet werden soll, legt man mit dem Skript am besten einfach einen Cron Job an.
Noch eine Ergänzung; Genaugenommen könnte man auch das Skript per cron Job starten und notfalls zuwangsbeenden, wenn es zu lange dauert.
Nano schrieb: > Noch eine Ergänzung; > Genaugenommen könnte man auch das Skript per cron Job starten und > notfalls zuwangsbeenden, wenn es zu lange dauert. Und natürlich beim nächsten Start oder beim zwnagsbeenden sicherstellen, dass auch eine unfertige 500 GB config Datei wieder gelöscht wird.
Ja aber kuck mal, jetzt hast du schon 3 Seiten Kram geschrieben was du alles machen musst damit X nicht passiert und woran man denken muss. Ich sage ja nicht, dass es nicht geht, die Aufgabe ist nicht wahnsinnig komplex. Ich sage aber, schreib es mal praktisch auf; es wird durchaus ein bisschen komplizierter als du so denkst, und der erste Versuch wird vermutlich nicht so sein, dass man nicht mit 15 Minuten Suchen irgendwas findet, was sich unter irgendeinem Umstand komisch verhält. Diese Eigenschaft hat der sshd nicht: und deshalb ist es besser, das komische Skript einfach wegzulassen und nur den sshd laufen zu haben.
Das mit dem wackligen Stecker kann man ein wenig umgehen. Es gibt einige Shops (rate mal welcher auch dabei ist ;-) ),welche USB Kabel mit SCHALTER anbieten. Dadurch muss der USB Stecker nciht gefühlte 100 mal an- und abgeseckt werden.
Mein Pi ist auch per ssh von "überall" aus erreichbar. Folgende Maßnahmen sollten reichen: 1) login per username/passwort sperren und nur Key authentication erlauben 2) fail2ban 3) evtl. noch bestimmte Regionen black- oder whitelisten 4) Updates installieren Wichtig ist: Keine selbstgestrickten Lösungen wie ein TCP/IP-basiertes Kommandointerface. Jede zusätzliche Schnittstelle ist ein offenes Scheunentor, vor allem wenn es sich um eine eigene Bastellösung handelt. Kein Security by Obscurity (z.B. ssh-Port ändern). Das gibt keine zusätzliche Sicherheit, gaukelt aber falsche Sicherheit vor. Edit: sehe grad in meinen Notizen: Raspbian hat kein root-Passwort. Zumindest war das 2015 so. Also, gib dem root noch ein Passwort, falls noch nicht geschehen.
:
Bearbeitet durch User
Alles ein Wenig auf der aufwendigen Seite. Ne extra App zusammenkloppen, anstelle ueber einen Webserver zu gehen. Webserver mit SSL sind auch schon lange Standard. Dann muss ich mich nur darum kuemmern einen aktuellen Browser zu haben. Ich kann mich drauf verlassen, dass das Protokoll auch geroutet wird, was mit irgendwelchen Ports nicht der Fall sein muss.
Le X. schrieb: > Kein Security by Obscurity (z.B. ssh-Port ändern). > Das gibt keine zusätzliche Sicherheit, gaukelt aber falsche Sicherheit > vor. Einen Vorteil hat dan Ändern: Es fallen 99,9 % der Meldungen über Verbindungsversuche von Bots im Log weg.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.