Jump to content
  • 0
Melde dich an, um diesem Inhalt zu folgen  

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

Frage

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 von RubberDog

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

10 Antworten auf diese Frage

Empfohlene Beiträge

  • 2

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

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
  • 1

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
  • 1

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
  • 1

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 von arlegermi

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
  • 1
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).

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
  • 1

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
  • 0
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.. 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
  • 0
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..

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
  • 0
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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Gast
Du kommentierst als Gast. Wenn du bereits einen Account hast kannst du dich hier anmelden.
Diese Frage beantworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Melde dich an, um diesem Inhalt zu folgen  

Fachinformatiker.de, 2018 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung