BUK zum Linux Backup

Hallo Leute,

ich bin gerade dabei ein automatisches Backup unter Linux zu realisieren.
Da in diesem Fall die Sicherheit eine Rolle spielt und gängige Lösungen die Sicherheit nicht garantieren habe ich folgende Idee und wende mit der Bitte um Kommentar (BUK) an euch.

Im folgenden ein Ausschnitt einer Mail von mir zu diesem Thema.


  1. Überblick

Es gibt einen Backup/Updateserver dieser sichert die hosts in dem er mit
hilfe der ssh eine Verbindung aufbaut, sobald diese Verbindung zustande
gekommen ist liefert der Hosts einen verschlüsselten Stream, dieser Stream
wird dann als Datei auf der Festplatte des Backupservers gespeichert.
Pro host werden ingesammt 3 Generationen Online vorgehalten.
Jedes Backup wird per samba auf einen NT Server übertragen und dort wird
es dann über die Standardbackupmechanismen gesichert.
Wichtig hierbei ist das ein Rückgriff auf die Daten für mindestens 6 Monate besser für 1 Jahr sichergestellt wird.

  1. Das backup auf dem hosts.

Das backup auf dem Hosts erfolgt per tar befehl, da für ein Vollbackup
root rechte nötig sind. Liegt es nahe das man sich direkt mit root auf dem
hosts einloggt bzw. den tar befehl remote ausführt.
Da dies aber aufgrund der Sicherheitssriskien (siehe Punkt 4) nicht
wünschenswert ist:smile:, kommt ein extra User (zb. backup) zum Einsatz.
Der User backup hat dann die Möglichkeit ein (wrapper)-Script namens
mach_mich_backup.sh:smile: aufzurufen und dieses Script wird dann den
Befehl tar als root ausführen (Für alle interessierten das Script ist
setuid und es wird bei der Programmierung selbstverstänlich an die
Sicherheit gedacht:smile:.

  1. ssh im Überblick

Der Aufbau der ssh-verbindung wird per publickey verfahren gesichert. Da
das Backup script auf den secretkey zugreifen muss, macht es wenig sinn das
dieser durch ein passphrase geschützt ist, da der passphrase dann
soweiso auf dem backup-srv hinterlegt sein müsste. Mit anderen Worten ein
Passphrase würde kein _Mehr_ an Sicherheit bringen und Security by
Obscurity ist nie eine Lösung.

Es ist allerdings auch unsicher wenn man einen secrect-key ohne Passwort
speichert. Da es somit in der Standardkonfiguration möglich ist sich auf
dem zu sicherdem Hosts einzulogen (Gottseidank nicht als root siehe Punkt
3).
Um dieses Sicherheitsrisko auszuschliessen wird ssh so konfiguriert, das
es das script mach_mich_backup.sh ausführt wenn man sich mit diesem
bestimmten ssh-key einloggen will, eine interative Anmeldung
(shell-access) wird unterbunden.

Das script mach_mich_backup.sh wird dann den Backupstream erzeugen.

Da das erwähnte Verfahren leider noch die Sicherheitslücke hat,
das jeder der im besitzt des Secrect key ist, ein backup anstossen kann.
Wird der Backupstream mit hilfe von gpg verschlüsselt.

  1. gpg im Überblick

Das propgram gpg (gnupg) wird den Datenstream den es vom tarbefehl
erhält, mit hife des publickeyverfahrens verschlüsseln.
Es verwendet dafür 2 publickeys. Der erste ist der Work-restore-key und
wird wie der Name schon sagt, als Arbeitsschlüssel eingesetzt.
Der zweite ist der fallback-key, dieser wird idealerweisse in einem
feuerfesten Tresor hinterlegt.
Die Aufbewahrung der geheimen-schlüssel erfolgt

a) beim Work-key auf diskette und evtl. Auf dem Admin Linux Rechner.
Der Work-key ist durch ein Passphrase geschützt.

b) beim Fallbackkey auf diskette und als Printout in 2 Facherkopie. Ein
Printout wird der diskette beigefügt. Das andere wird wird irgendwo anders
hinterlegt.
Wichtig hierbei ist das der Fallbackkey _ohne_ passphrase vorliegt!!!

  1. Restore

Das Restore kann auf verschieden Möglickeiten erfolgen.

Eine davon könnte sein.

Das Restore erfolg mit hilfe einer Boot-CD.
Der Administrator legt per hand die nötigen Partionen an und zieht sich
dann das aktuelle Backup per ssh vom backupserver.

[…]

  1. ENDE

----snap

Anmerkung: Beim Linux Admin Hosts handelt es sich um eine spezielle gehärtete Workstation. Unteranderm wird kein Dienst angeboten.

Für konstruktive Kritik bin ich dankbar:smile:

polarbear

Pro host werden ingesammt 3 Generationen Online vorgehalten.
Jedes Backup wird per samba auf einen NT Server übertragen

unverschlüsselt?

  1. Das backup auf dem hosts.

Das backup auf dem Hosts erfolgt per tar befehl, da für ein
Vollbackup
root rechte nötig sind. Liegt es nahe das man sich direkt mit
root auf dem
hosts einloggt bzw. den tar befehl remote ausführt.
Da dies aber aufgrund der Sicherheitssriskien (siehe Punkt 4)
nicht
wünschenswert ist:smile:, kommt ein extra User (zb. backup) zum
Einsatz.

Gut.

Der User backup hat dann die Möglichkeit ein (wrapper)-Script
namens
mach_mich_backup.sh:smile: aufzurufen und dieses Script wird dann
den
Befehl tar als root ausführen

Hm. Oder das Script mit sudo aufrufen. „irgenwie“ erscheint mir das netter.

(Für alle interessierten das
Script ist
setuid und es wird bei der Programmierung selbstverstänlich an
die
Sicherheit gedacht:smile:.

Nimm sudo, dann brauchst Du kein suid.

Es ist allerdings auch unsicher wenn man einen secrect-key
ohne Passwort
speichert. Da es somit in der Standardkonfiguration möglich
ist sich auf
dem zu sicherdem Hosts einzulogen (Gottseidank nicht als root
siehe Punkt
3).
Um dieses Sicherheitsrisko auszuschliessen wird ssh so
konfiguriert, das
es das script mach_mich_backup.sh ausführt wenn man sich mit
diesem
bestimmten ssh-key einloggen will, eine interative Anmeldung
(shell-access) wird unterbunden.

Hm. Oder eien SSH-Tunnel bauen und den mit einem weiteren User aufbauen? Nur so ein wild in die Gegend geworfener Gedanke.

Das script mach_mich_backup.sh wird dann den Backupstream
erzeugen.

Da das erwähnte Verfahren leider noch die Sicherheitslücke
hat,
das jeder der im besitzt des Secrect key ist, ein backup
anstossen kann.
Wird der Backupstream mit hilfe von gpg verschlüsselt.

Aha. Gut.

  1. gpg im Überblick

Das propgram gpg (gnupg) wird den Datenstream den es vom
tarbefehl
erhält, mit hife des publickeyverfahrens verschlüsseln.
Es verwendet dafür 2 publickeys. Der erste ist der
Work-restore-key und
wird wie der Name schon sagt, als Arbeitsschlüssel eingesetzt.
Der zweite ist der fallback-key, dieser wird idealerweisse in
einem
feuerfesten Tresor hinterlegt.
Die Aufbewahrung der geheimen-schlüssel erfolgt

a) beim Work-key auf diskette und evtl. Auf dem Admin Linux
Rechner.
Der Work-key ist durch ein Passphrase geschützt.

b) beim Fallbackkey auf diskette und als Printout in 2
Facherkopie. Ein
Printout wird der diskette beigefügt. Das andere wird wird
irgendwo anders
hinterlegt.
Wichtig hierbei ist das der Fallbackkey _ohne_ passphrase
vorliegt!!!

Damit ist Samba unverschlüsselt kein Problem mehr…

Sebastian

sdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd rsbbs

Überlistet, W-W-W!

Moin Sebastian,

Der User backup hat dann die Möglichkeit ein (wrapper)-Script
namens
mach_mich_backup.sh:smile: aufzurufen und dieses Script wird dann
den
Befehl tar als root ausführen

Hm. Oder das Script mit sudo aufrufen. „irgenwie“ erscheint
mir das netter.

Habe ich auch schon überlegt. (sudo nur für den tar befehl mit speziellen optionen für den User Backup)
Allerdings hat ja sudo derzeit häufiger sec-bugs gehabt und ich habe auf den entsprechenden Servern kein sudo installiert. Da ich es normalerweise nicht brauche. Und welches Script/Prog jetz setuid ist oder nicht ist eigentlich egal. Aber ist mein eigenes Script wird so klein gehalten das bugs eher unwahrscheinlich sind.

BTW
Auf meiner Workstation setzte ich sudo ein.

3).
Um dieses Sicherheitsrisko auszuschliessen wird ssh so
konfiguriert, das
es das script mach_mich_backup.sh ausführt wenn man sich mit
diesem
bestimmten ssh-key einloggen will, eine interative Anmeldung
(shell-access) wird unterbunden.

Hm. Oder eien SSH-Tunnel bauen und den mit einem weiteren User
aufbauen? Nur so ein wild in die Gegend geworfener Gedanke.

Macht es aber auch nicht sicherer.

sdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbs

Überlistet, W-W-W!

Danke für dein Kommentar:smile:
Auch wenn ich nicht weiß was du mir mit den Letzten Zeilen sagen wolltest:smile:*grins

Man kann doch auf ein Vollquoting bestehen.

cu

polarbear

Moin Eisbär,

Hm. Oder eien SSH-Tunnel bauen und den mit einem weiteren User
aufbauen? Nur so ein wild in die Gegend geworfener Gedanke.

Macht es aber auch nicht sicherer.

Ich neige gerne dazu, für viele Aufgaben viele User einzurichten :smile:

So ist es prinzipieller schwerer, eine unter dem User laufende Software auszutricksen, die dann ungepasswortetet SSH-Keys verschickt.

sdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbssdadasef eafadg fvgfwd
rsbbssdadasef eafadg fvgfwd rsbbs

Überlistet, W-W-W!

Danke für dein Kommentar:smile:
Auch wenn ich nicht weiß was du mir mit den Letzten Zeilen
sagen wolltest:smile:*grins

Beware of buggy browsers.

http://www.wer-weiss-was.de/cgi-bin/forum/showarticl…

Man kann doch auf ein Vollquoting bestehen.

Solange Du mich nicht als Vollquottel bezeichnest…

Sebastian

Moin Eisbär,

Hm. Oder eien SSH-Tunnel bauen und den mit einem weiteren User
aufbauen? Nur so ein wild in die Gegend geworfener Gedanke.

Macht es aber auch nicht sicherer.

Ich neige gerne dazu, für viele Aufgaben viele User
einzurichten :smile:

So ist es prinzipieller schwerer, eine unter dem User laufende
Software auszutricksen, die dann ungepasswortetet SSH-Keys
verschickt

Ich nenne das Security by Obscurity und das bring IMHO kein mehr an Sicherheit, nur ein mehr an Administrationsaufwand.

In diesem Sinne

polarbear