[Python] Login-Daten innerhalb eines Scriptes schützen

[RubberDog]

Moin,

für $Gerät haben wir ein Script gebaut dass die Daten, welche $Gerät misst, direkt in eine SQL-Datenbank synchronisieren soll.

$Gerät besteht aber unter anderem aus einem Raspberry Pi. Es besteht also die möglichkeit, dass irgendwer das Ding einfach auseinanderbaut, die Login-Daten aus dem Script nimmt und Dinge tut, die wir nicht so toll finden.

Gibt es eine möglichkeit, diese Login-Daten irgendwie zu schützen?

Bearbeitet 28. Juni 2018 von RubberDog

[Enno]

Dann mach mehrere Dinge:

1.) auf die SD Karte kommt ein verschlüsseltes Binary

2.) zum Authentifizieren liest das Binary die HardwareID aus. -> Karte kann nicht in anderen Pis verwendet werden = andere HardwareID

3.) feste IP Adresse vergeben und einschränken das sich bestimmte Benutzer nur von bestimmten Ip Adressen anmelden können

4.) auf dem Switch Mac-Adresse filterung = man kann mit dem PI auch nicht innerhalb des Netzes umziehen

 

[Han_Trio]

Ich sehe eigentlich nur zwei Möglichkeiten:

1) (Voll)Verschlüsselung
In diesem Fall müsste man gleich die ganze SD card verschlüsseln, und die ENTschlüsselung muss extern, also unabhängig vom Pi, passieren. Entsprechend müsste bei jedem (!) booten entweder ein weiteres key device vorhanden sein, oder jemand gibt ein entspr. Passwort ein. Was beides in eurer Hand liegen müsste.
Was auch zu beachten wäre: Bei vollverschlüsselter SD card wird der RasPi gut zu tun haben, sprich Leistungsverlust wäre unumgänglich.

2) Die SD card mit Heißkleber / Epoxid-Harz unzugänglich machen.
Kein 100%iger Schutz, aber zumindest erschwert es das Ganze erheblich.

[Enno]

dann stell das login so um, das der Raspi sich mit einer lokalen HardwareID anmeldet.

Also in der Art das du immer die Hardware brauchst um dich anmelden zu können.

[lessbess]

Nein, du kannst den Zugriff erschweren (Verschlüsselung, das Gerät physisch sichern o.ä.), aber verhindern kannst du es nicht.

Daher ist die beste Möglichkeit deine Anwendung umzubauen, statt Datenbankzugangsdaten (am besten noch mit Vollzugriff und diesselben Zugangsdaten für alle Geräte) auf den Geräten zu speichern, sollten die Geräte mit einem Service / API kommunizieren über das zunächst individuelle Zugangsdaten für jedes Gerät generiert werden und welches nur die wirklich notwendigen Aktionen zulässt (Daten hochladen, Daten abrufen usw.). Der Service kümmert sich dann um die Ablage in der Datenbank.

[arlegermi]

Naja, allererster Ansatz wäre doch erstmal, den SQL-Benutzer rechtemäßig so weit einzuschränken, dass er keinen / kaum Schaden verursachen kann. Wenn er direkt in eine Tabelle der Datenbank schreibt, also nur ein GRANT auf die eine Tabelle.

Wenn ihr durch 'ne (Web-)Schnittstelle geht, dann kann man da Filter implementieren. Sobald Hardware in der Hand "des Feindes" ist, ist alles, was darauf ist, grundsätzlich als kompromittiert zu betrachten.

vor einer Stunde schrieb RubberDog:

Aktueller Plan ist wohl, ne binary aus dem Script zu machen..

Nur durch das Kompilieren eine Python-Skripts in eine Binärdatei wirst du die Zugangsdaten aber auch nicht los. Was ist denn eigentlich das Szenario hier? Geht's um kritische Daten, die aktiv angegriffen werden oder möchtest du nur das Gelegenheits-Script-Kiddie abwehren?

Bearbeitet 29. Juni 2018 von arlegermi

[arlegermi]

vor 3 Stunden schrieb RubberDog:

An was für Filter denkst du dabei genau?

Naja, zum einen ein Inhalts-Filter (à la "die Operation darfst du von dem Gerät aus gar nicht durchführen"), zum anderen ist es auch denkbar, IP- oder MAC-Adressen zu filtern (ja, lässt sich auch spoofen, aber besser als nix).

[Enno]

P.S.

alegermis Filter kannst du auch durch eine Temp Tabelle und einen View in der DB darstellen.

Schreiben darf der PI nur in eine Temp Tabelle. Nen SQL Job holt die daten dort alle x Zeiteinheiten ab und prüft diese auf Plausibilität.

z.b. Pi schreibt viel zu oft Daten.

Pi schreibt komische Daten (bsp.: Temperatur viel zu Hoch oder zu niedrig)

 

a) könnt ihr damit die Daten die in der DaBa landen vorfilter und Angriffe unterbidnen

b) könnt Ihr euch Mails schicken lassen wenn solche Daten ankommen das dort was unplausibel ist.

Ihr bekommt also zeitnah mit wenn nen PI Mist baut.

[RubberDog]

vor 4 Minuten schrieb Han_Trio:

1) (Voll)Verschlüsselung
 

2) Die SD card mit Heißkleber / Epoxid-Harz unzugänglich machen.

Zu 1) Jede Person die den Login klauen könnte hat - und braucht - Zugriff auf das Gerät. 
Wir wollen nicht immer mitlaufen müssen, um ein Passwort einzugeben - und wenn jemand ein Keydevice bekommt, können wir es auch gleich lassen. Macht ja keinen Unterschied ob plain, oder encrypted aber mit dem Key dabei.

Zu 2) Macht aber auch Wartungen schwierig, wenn ein Hardwaredefekt vorliegt.

 

Alternativ fanden wir noch ein paar crypto-libs, man könnte das eigentliche Passwort in ne binary packen, und die vom Script mit nem Key wieder zurückrechnen - ist dann aber das gleiche wie 1), ob plain oder mit Key.. 

[RubberDog]

vor 17 Minuten schrieb Enno:

dann stell das login so um, das der Raspi sich mit einer lokalen HardwareID anmeldet.

Also in der Art das du immer die Hardware brauchst um dich anmelden zu können.

Sehr schöne Idee, gefällt mir.
Allerdings kann man auch die spoofen, wenn man sie mal kennt.

 

Aktueller Plan ist wohl, ne binary aus dem Script zu machen..

[RubberDog]

vor 2 Minuten schrieb arlegermi:

Naja, allererster Ansatz wäre doch erstmal, den SQL-Benutzer rechtemäßig so weit einzuschränken, dass er keinen / kaum Schaden verursachen kann. Wenn er direkt in eine Tabelle der Datenbank schreibt, also nur ein GRANT auf die eine Tabelle.

Der Nutzer muss Daten lesen / schreiben / ändern / löschen können. Und ja, das ist auf den einen Table beschränkt, kein Zugriff auf die restliche Datenbank.

vor 5 Minuten schrieb arlegermi:

Wenn ihr durch 'ne (Web-)Schnittstelle geht, dann kann man da Filter implementieren. Sobald Hardware in der Hand "des Feindes" ist, ist alles, was darauf ist, grundsätzlich als kompromittiert zu betrachten.

An was für Filter denkst du dabei genau?

vor 8 Minuten schrieb arlegermi:

Was ist denn eigentlich das Szenario hier?

Eher das Gelegenheits-Scriptkiddie.