mikrocontroller.net

Forum: PC Hard- und Software Beurteilung meines Sicherheitskonzeptes | Raspberry Server


Autor: RogerGER (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 Moderator
Autor: 900ss D. (900ss)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Forum Projekte:
Hier könnt ihr eure Projekte, Schaltungen oder Codeschnipsel vorstellen 
und diskutieren.
*Bitte hier keine Fragen posten!*

Autor: RogerGER (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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?

Autor: gunnar (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Das sieht schon ganz gut aus, ich würde jedenfalls dran verzweifeln :)

Autor: Marcel P. (phpmysqlfreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: oszi40 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: oszi40 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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
Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da die Datei noch signiert wird nö.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. 
:)

Autor: Gerd E. (robberknight)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Spätestens bei der verschlüsselten oder signierten Datei gibt er auf.

Korrektur, ich meine natürlich "und".

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: J. S. (bb84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schreib doch einfach mal so ein Skript, dann schauen wir uns das mal an 
und überlegen mal, was man damit alles anstellen kann.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Ergänzung;
Genaugenommen könnte man auch das Skript per cron Job starten und 
notfalls zuwangsbeenden, wenn es zu lange dauert.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fred R. (Firma: www.ramser-elektro.at/shop) (fred_ram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Le X. (lex_91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Name H. (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.