Beurteilung meines Sicherheitskonzeptes | Raspberry Server

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 :)

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.

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.

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.

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.

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.

Da die Datei noch signiert wird nö.

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. 
:)

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.

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.

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".

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.

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.

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.

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.