[linux-l] Passwort bei rsync

Olaf Radicke briefkasten at olaf-radicke.de
Di Okt 4 07:50:39 CEST 2011


Hi!


Volker Grabsch <vog at notjusthosting.com> hat am 4. Oktober 2011 um 02:48
geschrieben:
> Hallo Olaf,
>
> Olaf Radicke schrieb:
> > Ich würde er ein Konzept ähnlich wie bei einem FTP-Server machen:
> >  
> > A schiebt per Chron-Job seine Backups in das Verzeichnis eines
> > Unprivilegierten
> > User. Gibt es mehrere Rechner, die ihre Backups auf B schieben, hat jeder
> > für
> > sich einen eigenen User-Account. Der Backupserver hat einen Bachup-User der
> > Mitglied in den Gruppen ist, zu den er Zutritt braucht. Der backupserver hat
> > ein
> > oder mehrere Chron-Jobs die dann Reium die hochgeladenen Backups auf
> > Plausibilität (Name, Alter, Größe, Ping, Signatur...) prüfen und
> > einsammeln/weiterverarbeiten, also auf das Storage schreiben...
> >  
> > Bei dem Szenario ist keiner der beiden Seiten "Allmächtig".
>
> Genau daran habe ich früher auch mal gedacht, habe das
> Konzept aber über den Haufen geworfen, weil dann beim
> Backup Informationen verloren gehen, nämlich die Datei-
> Eigentümer. (Die Datei-Rechte hingegen werden übertragen.)
 
Das ist unerheblich. Es ist nicht zugesichert das auf ein wiederhergestellten
System die User wieder die selben UIS haben. Das tut auch nicht weiter weh, weil
es für die Umstellung nur ein einzigen Befehl braucht. Zu Note baust du mit
Hilfe der Passwd ein Bash-5-Zeiler um die die UID des Systems wieder zu richten.
Der Admin, der an dieser Aufgabe scheiter, dem ist e' nicht mehr zu helfen.
 
Gruß
 
Olaf 
 
> > Denn der unprivilegierte Backup-User darf ja keine Dateien
> anlegen, die einem "fremden" User gehören. Das darf nur Root.
>
> Ich bin deshalb dazu übergegangen, anstelle der Gruppen
> einfach virtuelle Maschinen zu nehmen, in denen nichts
> läuft außer SSH/Rsync. In diese Maschinen kann man sich
> zwar als Root einloggen, aber außer dem Backup befindet
> sich nichts darin. Somit kann ein Angreifer nicht viel
> mehr tun als er im Falle des unprivilegierten Users tun
> kann, nämlich das eine Backup klauen bzw. kaputt machen.
>
> Login ist natürlich nur über den einen SSH-Key möglich,
> inbesondere ist das Root-Passwort gesperrt. (passwd -l root)
>
> Ich bin mit dieser Lösung nicht ganz zufrieden, aber sie
> ist bisher das beste, was ich habe.
>
> Ansonsten war mir noch eingefallen, dass man ein großes,
> unkomprimiertes Tar-Archiv auf dem Server regelmäßig
> erzeugen könnte, und dieses dann per Rsync auf den Backup-
> Server überträgt. Das ist zwar eine riesige Datei, aber
> RSync braucht ja nur die Teile davon zu übertragen,
> die sich tatsächlich geändert haben. Dennoch ist die
> Performance immer noch deutlich schlechter als beim
> direkten RSync, und ich sehe in Sachen Security keine
> wirkliche Verbesserung gegenüber der virtuellen Maschine.
>
> Trotzdem habe ich das Gefühl, dass es noch bessere
> Lösungen geben muss. Vielleicht hat da ja noch
> jemand was?
>
>
> Gruß
> Volker
>
> --
> Volker Grabsch
> ---<<(())>>---
> _______________________________________________
> linux-l mailing list
> linux-l at mlists.in-berlin.de
> Die Mailingliste der BeLUG (Berliner Linux User Group)
>
> Wenn du diese Mailingliste  abbestellen willst, gehe bitte auf
> https://mlists.in-berlin.de/mailman/listinfo/linux-l-mlists.in-berlin.de
> und trage dich dort bitte aus
>



Mehr Informationen über die Mailingliste linux-l