Script: Verschlüsselten Ordner via Keyfile (.key) entschlüsseln

[peterhoffmann]

Es gibt viele Wege nach Rom.
Der Weg über eine Triggerdatei und inotify wäre eins davon. Die könnte man noch verfeinern, z.B. nur spezielle Ordner mounten, je nachdem wie man die Triggerdatei benennt.

Ich für mich habe den Weg über einen Messenger (Telegram) gewählt. Dort habe ich einen Bot erstellt und das NAS kann Nachrichten an mich versenden. Die bekomme ich dank dem Messenger sofort.
Angefangen hat es mit diesem Script hier:
https://github.com/fabianonline/telegram.sh
Das hat sehr gut funktioniert, kann ich nur empfehlen.
Inzwischen nutze ich es nicht mehr, da ich die API von Telegram direkt anspreche. Das brachte mir noch mehr Möglichkeiten, z.B. ich kann auch (ausgewählte) Befehle über Telegram absetzen, die das NAS liest und bearbeitet.

 

[stevenfreiburg]

WOW, Du kannst über Telegram das Script anstossen welches verschlüsselte Ordner öffnet/einhängt ?

 

[peterhoffmann]

Es wäre möglich jeden beliebigen Konsolenbefehl über Telegram abzusetzen und das NAS führt das aus. Aber das habe ich so natürlich nicht gemacht, alleine schon aus Sicherheitsgründen. Wer Macht über den Telegram-Bot hat, könnte dann das NAS steuern, sprich auch alles löschen, was natürlich fatal wäre.

Meine Vorgehensweise:
Zuerst habe ich mir eine Liste von Dingen erstellt, die ich aus der Ferne auslösen möchte. Z.B. Status (Temp, Smart, Belegung HDDs), Sicherung XYZ anstoßen, Netzwerk scannen, Ausgabe aller Clients im Netzwerk, Herunterfahren, usw. Es ist mit voller Absicht nichts an Abläufen dabei, die die Daten oder das NAS gefährden.
Für jeden dieser Dinge habe ich mir einen Befehl ausgedacht. Wenn ich den Befehl im Bot absetze, liest das NAS das und löst die passende Aufgabe aus (einfaches if).

Beispiel:

 

[Tommes]

@peterhoffmann
Das ist schon ziemlich cool, was du da gezaubert hast. Vor allem finde ich den grafischen Balken sehr charmant. Ich habe sowas ähnliches schon mal in bash und html/css umgesetzt, aber noch nie auf der Konsole bzw. als reines Shell-Script. Könntest du mir freundlicherweise evtl. den Codeschnipsel zukommen lassen, wie solch ein Balken definiert wird. Das wäre wirklich toll.

 

[peterhoffmann]

Codeschnipsel

Na klar... Ursprung für mein Script war wahrscheinlich wohl mal das hier:
https://github.com/fearside/ProgressBar/

Normalerweise notiere ich mir die Herkunft von Codeschnipseln, hier war ich aber nachlässig.

Ich habe heute keine Zeit mehr, ich schaue morgen noch mal genauer.

 

[peterhoffmann]

Doch noch etwas Zeit gefunden.

Der Anlass für das Script war, dass die Ansicht von Werten in einer optischen Form (Balken) einem einen viel schnelleren Überblick verschafft. Nicht nur in der s/w-Version in Logdateien oder per Telegram, sondern auch farblich in der Konsole, wo man die Höhe vom Prozentwert auch noch farblich anders gestalten kann.

Meine Balkenversion (balken.sh) aus 10/2023 berücksichtigt:

• Untergrenze (muss nicht 0 sein) und Obergrenze
• Breite / Zeichenzahl (10,20,30, usw. )
• Begrenzungszeichen (rechts u. links)
• Optik => Farbe (Konsole) oder S/W für Telegram und Logdateien
• Optik => verschiedene Farben für Prozentwerte (z.B. grün bis 50%, orange bis 70%, rot darüber)

Über konstruktive Kritik, Verbesserungsvorschläge, Ideen und auch verbesserte Versionen würde ich mich sehr freuen.

Viel Spaß beim Basteln.

#!/bin/bash

###### Erläuterung #################################### Oktober 2023
#
# Aufrufbeispiel => . ./balken.sh 40 0 100 2 Klammer 1 30 70
#
# Wert1 => aktueller Wert (Zahl)
# Wert2 => untere Grenze (Zahl)
# Wert3 => obere Grenze (Zahl)
# Wert4 => Schritte (1=10, 2=20, usw.)
# Wert5 => Anfang und Ende (Klammer oder Horizontal)
# Wert6 => Optik (1=Farbe oder 2=sw)
# Wert7 => |- Farbe => %-Wert für Orange
# Wert8 => |- Farbe => %-Wert für Rot
#
# Mindestens Wert1 muss vorhanden sein.
#
#######################################################

###### CONFIG ######################################### Oktober 2023
BARRED="\033[38;5;160m"
BARORANGE="\033[38;5;220m"
BARGREEN="\033[38;5;34m"
BARDGREY="\033[1;30;40m"
BARDGREY2="\033[38;5;234m"
BARNOCOLOR="\033[0m"
#######################################################

## Prüfung Wert1
if [[ ${1} = "" ]]; then
BALKEN="|- FEHLER -|"
else
## Prüfung Wert2
BARUGRENZE=${2}
if [[ ${BARUGRENZE} = "" ]]; then BARUGRENZE="0"; fi
## Prüfung Wert3
BAROGRENZE=${3}
if [[ ${BAROGRENZE} = "" ]]; then let BAROGRENZE=(${1}*2); fi
## Prüfung Wert4
BARTEIL1=${4}
if [[ ${BARTEIL1} = "" ]]; then BARTEIL1="1"; fi
let BARTEIL2=(${BARTEIL1}*10)
## Prüfung Wert5
BARTRENNER=${5}
if [[ ${BARTRENNER} = "horizontal" ]]; then BARTRENNER1="|"; BARTRENNER2="|";
elif [[ ${BARTRENNER} = "Klammer" ]]; then BARTRENNER1="["; BARTRENNER2="]";
else BARTRENNER="horizontal"; BARTRENNER1="|"; BARTRENNER2="|";
fi
## Prüfung Wert6
BAROPTIK=${6}
if [[ ${BAROPTIK} = "" ]]; then BAROPTIK="0"; fi
## Prüfung Wert7
BARGRENZE1=${7}
if [[ ${BARGRENZE1} = "" ]]; then BARGRENZE1="100"; fi
## Prüfung Wert8
BARGRENZE2=${8}
if [[ ${BARGRENZE2} = "" ]]; then BARGRENZE2="100"; fi

## Berechnung
let BARERGEBNIS1=(${1}-${BARUGRENZE})
let BARERGEBNIS2=(${BAROGRENZE}-${BARUGRENZE})
let BAR_PROGRESS=(${BARERGEBNIS1}*100/${BARERGEBNIS2}*100)/100
        let BAR_done=(${BAR_PROGRESS}*${BARTEIL1})/10
        let BAR_left=${BARTEIL2}-$BAR_done
# Build progressbar string lengths
        BAR_done=$(printf "%${BAR_done}s")
        BAR_left=$(printf "%${BAR_left}s")

## Debug (Ausgabe der Werte)
#echo "${1} | ${BARUGRENZE} | ${BAROGRENZE} | ${BARTEIL1} | ${BARTRENNER} | ${BAROPTIK} | ${BARGRENZE1} | ${BARGRENZE2} | ${BAR_PROGRESS}%"

# 1.2 Build progressbar strings and print the ProgressBar line
if [[ $BAR_PROGRESS -gt ${BARGRENZE2} ]]; then BARFARBE=$BARRED;
elif [[ $BAR_PROGRESS -gt ${BARGRENZE1} ]]; then BARFARBE=$BARORANGE;
else BARFARBE=$BARGREEN
fi

if [[ ${BAROPTIK} = "1" ]]; then
    BALKEN=$(printf "$BARDGREY${BARTRENNER1}${BARFARBE}${BAR_done// /■}${BAR_left// /${BARDGREY2}■}$BARDGREY${BARTRENNER2}${BARNOCOLOR}")
elif [[ ${BAROPTIK} = "2" ]]; then
    BALKEN=$(printf "${BARTRENNER1}${BAR_done// /■}${BAR_left// /□}${BARTRENNER2}")
else
    BALKEN=$(printf "${BARTRENNER1}${BAR_done// /■}${BAR_left// /□}${BARTRENNER2}")
fi

fi

 

[peterhoffmann]

Beispiel für Logdateien:


Beispiel für Konsole:

Die Balken verfärben sich beim Erreichen von eingestellten Grenzwerten in orange oder rot.

 

[Tommes]

Vielen lieben Dank für den Link, das Script sowie die tollen Screenshots. Ich setzt das gleich mal auf meine Liste mit Dingen, dich ich mal ausprobieren möchte.

 

[Tommes]

Hi!

Gerne würde ich das Script zum Öffnen und Schliessen verschlüsselter Ordner zusätzlich per "Klick" auf dem Desktop ausführen können [...] Einzige Lösung, die ich gefunden habe, wäre Auslösen des Scripts mittels einer "Triggerdatei", deren Existenz oder Nicht-Existenz von einem Script überwacht wird [...]

Ich habe mich vorhin mal mit dem Thema auseinandergesetzt und kann bereits einen gewissen Erfolg vermelden. Was habe ich gemacht? Nun, ich habe in meinem Benutzer-Home-Ordner eine leere Trigger-Datei erstellt. Dann lasse ich mit inotifywait, welches im Paket inotify-tools enthalten ist, den Inhalt der Trigger-Datei überwachen. Wenn ich z.B. in die Datei das Wort "verbinden" hineinschreibe und die Datei abspeichere, dann wird mir ein zuvor definierter, verschlüsselter Ordner eingehängt. Schreibe ich in die Datei das Wort "trennen" und speichere abermals, wird der verschlüsselte Ordner wieder getrennt.

Ich würde das Script auch bereits veröffentlichen, jedoch muss ich mir noch Gedanken darüber machen, wie ich das Überwachungs-Script selbst - und damit inotifywait - ein- bzw. ausschalten kann. Über die Konsole geht das recht einfach mit STRG+C, aber über den Aufgabenplaner geht das so natürlich nicht und würde nach dem einmaligen Start bis zum Neustart der DS immer weiter laufen. Keine Ahnung, ob ich das morgen bereits hinbekomme, oder erst am WE. Aber ich bin dran.

Bis dahin eine Frage an @stevenfreiburg : Wäre das vom Prinzip her das, was du dir vorgestellt hast und womit du was anfangen könntest?

Noch ein Nachtrag: Dadurch, das die Trigger-Datei im Benutzer-Home-Ordner liegt, kann diese natürlich auch von einem Client-PC aus verändert werden. Wenn man das weiter spinnt, könnten auf diese Weise normale DSM Benutzer zugewiesene verschlüsselte Ordner eigenständig einhängen und trennen.

Noch ein weiterer Nachtrag: Ich könnte die Trigger-Datei auch dazu nutzen, die Überwachung mit z.B. dem Wort „Deaktivierung“ zu stoppen. Das Einschalten der Überwachung müsste dann aber wieder über den Aufgsbenplaner erfolgen, indem die Aufgabe wieder einmalig ausführt werden müsste.

Tommes

 

[Hellraiser123]

Ich persönlich würde mir semaphoreui installieren und es dann über ein Ansible Playbook lösen. In semaphoreui kannst du verschiedene User anlegen und dann festlegen wer das auch ausführen darf. Das geht dann über jedes Gerät wo ein Browser läuft. Man kann auch mehrere Playbooks definieren zum entschlüsseln, Verschlüssen oder auch jede beliebige Aufgabe.

 

[Tommes]

@Hellraiser123 Danke, aber ich persönlich hab da keinen Bedarf. Ich arbeite mich an dem Script auch nur ab, weil mich das Thema interessiert und um nicht aus der Übung zu kommen. Wirklich brauchen tu ich das alles nicht.

 

[stevenfreiburg]

Hallo Tommes, genial, das ist genau der workaround um leidige Passworteingaben zu vermeiden und zusätzlich können damit ausgewählte User für sie angelegte verschlüsselte Ordner ein- und aushängen. Was von Synology ja gar nicht vorgesehen ist und derzeit auch nicht möglich ist (s. hier ).
Ich nutze verschlüsselte Ordner und Container nach Bedarf. Aufmachen, damit arbeiten, Dateien editieren/abspeichern und wieder schliessen.
Mir persönlich reicht daher ein Script das über simple txt Triggerdateien funktioniert, genutzt vom Admin und wenigen ausgewählten Usern.
Die Möglichkeit von extern über Fileupload einer Triggerdatei einen verschlüsselten Ordner zu öffnen und zu schliessen ist definitiv eine Arbeitserleichterung für mich.

"inotify" nutzt sicher nicht allzuviel Kapazitäten, könnte also durchaus permanent laufen, oder? Dieses Triggerdateiscript zu perfektionieren und daraus eine rund laufende Sache zu machen, ist garantiert viel Arbeit. Dafür müssten deulich mehr Leute den Wunsch danach äußern.

Und klar, was PeterHoffmann hier grade gezeigt hat, ist natürlich die Ferrari Version. Würde ich gerne nutzen, aber sowas fange ich gar nicht erst an. Denn um meinen Schwimmbadvergleich zu zitieren mit Plaschbecken-Nichtschwimmer-Schwimmer-Sprung- & Tauchbecken: Das ist was für Leute die Salto vom 10 Meter Turm springen können, aber nix für Leute im Nichtschwimmerbecken .

 

[Tommes]

Schön, das dir meine Vorgehensweise gefällt und du etwas damit anfangen könntest.

Wie gesagt, ich würde die Trigger-Datei gerne an die Benutzer-Home-Ordner binden, dann bräuchte man im Überwachungsscript nur den Namen des Benutzers angeben und das Script erstellt die Trigger-Datei dann automatisch in dessen Benutzer-Home-Ordner. Die Werte für das einhängen und trennen verschlüsselter Ordner können frei gewählt werden, es geht also z.B. auch 0 und 1 oder an und aus.

Inotify selbst arbeitet nach dem, was ich bisher gelesen habe sehr Ressourcen schonend, trotzdem werde ich einen weiteren Trigger im Script einbauen, der die Überwachung stoppt. Ich muss nur prüfen, ob ich dann den Prozess killen muss oder ob ein einfaches exit ausreicht.

Eventuell baue ich auch noch eine Überprüfung ein, ob ein verschlüsselter Ordner bereits eingehängt ist oder nicht, damit Befehle nicht unnötig ausgeführt werden.

Das einzig blöde ist bei der Sache nur, das das Passwort zum einhängen des verschlüsselten Ordners in das Überwachungsscript geschrieben werden muss und das im Klartext. Sicherlich könnte man das auch anders lösen, aber dann wird das Script wirklich zu komplex. Das muss dann jeder für sich entscheiden, wie er das lösen möchte. Aber vielleicht fällt mir dazu auch noch was kleveres ein.

Tommes

 

[stevenfreiburg]

Triggerdatei in Home Verzeichnissen ist voll ok.
Das mit dem Passwort in Klartext aber leider nicht.

Denn das ist ja genau das Thema, als Absicherung gegen Datendiebstahl will ich das Passwort (wie hier von PeterHoffmann beschrieben) aus einer externen und einer internen Quelle zusammensetzen. Die interne Adresse steht nicht zur Verfügung, wenn das NAS gestohlen wird (=Daten sind sicher) und über die externe behalte ich auch von außerhalb die Kontrolle. Das Konzept finde ich sicher.

Intern auf USB Sick (an Kabel in Schlüsselbox):
teil1=`cut -b 11-14 //volumeUSB1/usbshare/10000-1.txt`

Extern auf einem meiner Hostingpakete:
file2=`curl https://domain.com/syn01/10000-2.txt`
teil2=`echo $file2 | cut -b 3606-3610`

"cut" deswegen , da ich Dateien mit 10000 sinnlosen Zeichen habe in denen irgendwo die Passwortteile stehen ( hiermit erzeugt ).
Selbst jemand der beiden Dateien hat, kann nichts daraus erkennen.
Das aus $teil1 & $teil2 zusammengesetzte vollständige Passwort wird dann benutzt um den Ordner zu entschlüsseln wie hier.

Da ich inotify bislang nicht kannte/habe, hatte ich versucht den Aufgabenplaner hiermit
im Minutentakt laufen zu lassen um das Script zu starten.
Aber damit bin ich bisher nur (vielfach) gescheitert, ich bekomme nicht mal das zum Laufen.
Und Script auf Klick laufen zu lassen übersteigt leider eben auch meine Kenntnisse und Fähigkeiten.

 

[Tommes]

Naja, wie genau das Passwort gebildet wird bzw. woher du Teile des Passwortes auch immer holst und wie zusammensetzt ist ja ziemlich egal. Am Ende muss die Variable ${password} irgendwoher ihre Daten bekommen um einen verschlüsselten Ordner einhängen zu können. Das kann ja jeder nach Belieben so handhaben, wie er das möchte.

Aber wie gesagt… ich schau mir das alles an und entscheide dann, was ich in mein Script aufnehme und was nicht. Der Rest ist dann jedem selbst überlassen.

Man schauen, was das Wochenende so zu Tage bringt

 

[Tommes]

Ich hab da mal was vorbereitet...

​

Einhängen und trennen verschlüsselter Ordner als DSM-Benutzer​

Lest euch die Anleitung in Ruhe durch und beachtet vor allem die Einschränkung, das das Editieren der sogenannten "Ereignisdatei" aktuell nur über den DSM Text-Editor (oder halt über die Konsole mit z.B. nano, vi etc.) funktioniert. Meine Versuche, Änderungen an der Ereignisdatei über den Dateiexplorer meines Clientbetriebssystems durchzuführen, scheiterten bisher. Solltet ihr es trotzdem versuchen wollen und ihr scheitert, dann löscht die Ereignisdatei nochmal und startet das Überwachungsscript über den Aufgabenplaner nochmal neu.

Und wie immer gilt: Ihr macht das alles auf eure eigene Kappe und ich übernehme keine Verantwortung, sollte trotz intensiver Tests irgendetwas schiefgehen.

Viel Spaß und macht damit, was ihr wollt

 

[stevenfreiburg]

Vielen Dank!!
Das ist deutlich mehr und viel besser als ich gehofft hatte.
Vielen Dank auch, dass du dir die Arbeit gemacht hast eine Schritt für Schritt Anleitung zu schreiben .

Komme leider erst Ende der Woche zum Installieren/Testen/Anwenden.
Spricht irgendetwas dagegen meine beiden Scriptschnipsel einzubauen und zwei Passwortteile aus einer internen und einer externen Quelle zu ziehen und dann zusammenzusetzen?

 

[Tommes]

Hi!

Das mit dem Passwort sollte einfach umsetzbar sein indem du...

...
..
# Name des verschlüsselten, freigegebenen Ordners
share="ORDNERNAME"

# Intern auf USB Sick (an Kabel in Schlüsselbox):
teil1=`cut -b 11-14 //volumeUSB1/usbshare/10000-1.txt`

# Extern auf einem meiner Hostingpakete:
file2=`curl https://domain.com/syn01/10000-2.txt`
teil2=`echo $file2 | cut -b 3606-3610`

# Verschüsselungsschlüssel
password="${teil1}${teil2}"
..
...

... die Variable ${password} einfach mit den Ergebnissen deiner Variablen ${teil1} und ${teil2} fütterst. (ungetestet). Du kannst deinen Codeschnipsel demnach problemlos in das Überwachungsscript einbauen. Das ist genau das, was ich meinte, als ich sagte...

...wie genau das Passwort gebildet wird bzw. woher du Teile des Passwortes auch immer holst und wie zusammensetzt ist ja ziemlich egal. Am Ende muss die Variable ${password} irgendwoher ihre Daten bekommen...

Und wie immer gilt... nur kein Stress. Teste das, wann immer du Lust und Zeit hast und sollte es Probleme geben, kannst du dich gerne hier melden.

Tommes

 

[Tommes]

Kleine Randinformation bezüglich meines Überwachungsscripts.

Ich habe mittlerweile herausgefunden, wieso ich die "Ereignisdatei" zwar im DSM selbst, nicht jedoch auf meinem Client-Betriebssystem mit SMB-Anbindung davon überzeugen kann, Änderungen umzusetzten. Das Problem liegt an inotify selbst, da das Tool nicht den Dateinamen überwacht, sondern dessen inote Eintrag im Dateisystem und der inode Eintrag ändert sich, sobald ich die Datei versuche, von woanders aus zu verändern. Das lässt sich mit...

inotifywait -m EVENTFILE.txt

... sehr gut beobachten und mit...

stat EVENTFILE.txt

... sehr gut auswerten, da hier u.a. der inode der Datei ausgegeben wird... und dieser ändert sich, wie gesagt.

Leider habe ich noch keine Lösung für das Problem gefunden. Aber ich habe zumindest schon mal den Übeltäter ermittelt.

 

[Tommes]

Ich glaub, ich hab's tatsächlich hinbekommen. Zumindest funktioniert bei mir nun das wechselseitige Penetrieren der Ereignisdatei direkt auf dem Synology-NAS und per SMB-Verbindung von meinem Client-Betriebsystem aus. Ich habe das Script bereits auf meiner GitHub-Seite aktualisiert. Wer es also mal ausprobieren möchte... hier noch mal der entsprechende der Link

So. Feierabend für heute. Ziel erreicht