Skocz do zawartości
Desavil

Backup - użytkownik tylko do odczytu

Polecane posty

Witam. Konfiguruję backup na serwerze, do kopii używam narzędzia rsync, kopia wykonywana oczywiście jest z serwera backupowego, nie odwrotnie.

 

Na serwerze, który będzie backupowany chciałbym utworzyć dla bezpieczeństwa użytkownika, który mógłby tylko odczytywać określone lub wszystkie pliki/katalogi. Za pomocą samych chmodów niestety tego nie osiągnę, gdyż różne aplikacje, mają różne wymagania co do właśnie chmodów i nie można ich wszędzie zmienić, tak aby użytkownik o nazwie np. "backup" miał dostęp do takich plików/katalogów. Ze względów bezpieczeństwa nie chcę również używać do tego celu użytkownika "root".

 

Czy można takie coś osiągnąć? Jak najlepiej to zrobić?

 

Pozdrawiam!

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

ACL ? Zarządzanie grupami ?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

A jak nie chcesz robić tego co ksk zastosował wyżej to możesz zrobić metodę najprostszą, czyli utworzyć nowe konto userowi, i rsynować rootem do jego folderu, a stamtąd ciągnąć backupem na inny serwer. Plus masz taki, że nie musisz się bawić z dostępami w zasadzie w ogóle, minus taki że musisz gdzieś wrzucić skrypt co tego rsynca będzie robił, dodatkowo do tego co ciągnie backupy.

 

To rozwiązanie ma jednak plus w prostocie i tym, że jest łatwe do zrealizowania zwykłym cronem i rsynciem. Nie masz zależności - zadziała wszędzie tam gdzie jest rsync i cron (czyli wszędzie). Zabawa z ACL czy grupami jednak chwilę trwa.

Edytowano przez Archi (zobacz historię edycji)
  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Archi, w sumie bardzo ciekawe rozwiązanie, że też sam na to nie wpadłem. :D

Pewnie z dowiązaniami też można by przy tym pokombinować, żeby nie kopiować plików.

 

Właśnie nie chciałem kombinować z ACL (co swoją drogą nie jest czymś mega skomplikowanym).

Edytowano przez Desavil (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dowiązania mają ten problem, że to tylko link symboliczny, chyba że byś robił hardlinki, ale to się sprowadza dokładnie do tego samego co robiłby rsync. Poza tym opcja z rsynciem jest bezpieczniejsza - user jako taki w żaden sposób nie może wpłynąć na dane źródłowe, a tylko na ich kopię. Z linkami jest różnie.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Próbowałem z ACL, ale coś nie działa to tak jak początkowo myślałem.

setfacl -R -m d:u:backup:rx /var/www (domyślne uprawnienie dla nowych plików i folderów)
setfacl -R -m u:backup:rx /var/www

Przed zastosowaniem powyższej komendy:

getfacl /var/www
getfacl: Removing leading '/' from absolute path names
# file: var/www
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Po wprowadzeniu:

getfacl /var/www
getfacl: Removing leading '/' from absolute path names
# file: var/www
# owner: www-data
# group: www-data
user::rwx
user:backup:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:backup:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

Przy usunięciu:

setfacl -R -x d:u:backup /var/www
setfacl -R -x u:backup /var/www
getfacl /var/www
getfacl: Usunięcie wiodącego '/' ze ścieżek bezwzględnych
# file: var/www
# owner: www-data
# group: www-data
user::rwx
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:group::r-x
default:mask::r-x
default:other::r-x

Dlaczego on potworzył jeszcze inne "default", zmienił "owner" oraz "group"? Czy mogę powrócić jakoś do pierwszej konfiguracji, tzn. żeby pozostały tylko te ustawienia:

user::rwx
group::r-x
other::r-x

Przez to teraz w ogóle jest problem z uprawnieniami. Dlaczego nie dodał po prostu kolejnego użytkownika "backup" z prawem rx (jakie nadałem), tylko wprowadził jeszcze inne zmiany. Być może źle to konfiguruję?

Edytowano przez Desavil (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Minus tego jest taki, że jak masz dużo danych do zbackupowania to musisz mieć też dużo wolnego miejsca na zrobienie kopii. Gdy z jakiegoś powodu (ktoś ci wrzuci jakiś ogromy plik - jeśli udostępniasz upload plików; jakiś atak wyprodukuje dużą ilość logów; etc.) wielkość backupowanych plików przekroczy ci wielkość dostępnej wolnej przestrzeni, to taką kopią nie tylko nie zbackupujesz wszystkiego ale także "zablokujesz" sobie serwer. Musisz się przed tym zabezpieczyć w twoim skrypcie.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Minus tego jest taki, że jak masz dużo danych do zbackupowania to musisz mieć też dużo wolnego miejsca na zrobienie kopii. Gdy z jakiegoś powodu (ktoś ci wrzuci jakiś ogromy plik - jeśli udostępniasz upload plików; jakiś atak wyprodukuje dużą ilość logów; etc.) wielkość backupowanych plików przekroczy ci wielkość dostępnej wolnej przestrzeni, to taką kopią nie tylko nie zbackupujesz wszystkiego ale także "zablokujesz" sobie serwer. Musisz się przed tym zabezpieczyć w twoim skrypcie.

 

Dlatego mimo wszystko postanowiłem zainteresować się ACL, no ale... (post wyżej)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Możesz też na backupowanym systemie utworzyć nieuprzywilejowanego użytkownika, ustawić mu logowanie za pomocą kluczy i uruchamiać z niego rsync za pomocą sudo. W ten sposób działa BackupPC: http://backuppc.sourceforge.net/faq/ssh.html#how_can_client_access_as_root_be_avoided

 

Tutaj też znalazłem ciekawe rozwiązanie: https://learninginlinux.wordpress.com/2009/05/07/rsync-fixed-server-side-options/

Edytowano przez likufanele (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ale kombinujesz :D.

 

Jak ACL ci nie śmiga można równie dobrze pojechać jeszcze w inny sposób - zrzucić logikę robienia backupów na serwer źródłowy, a po stronie serwera backupowego odpalać crona, który przerzuci to co wrzucił user źródłowy do bezpiecznego miejsca. Osiągasz w zasadzie to samo tylko inną drogą, i nie masz żadnych niepotrzebnych kopii, bo wynik końcowy zwyczajnie przenosisz (mv) według swojej własnej ustalonej logiki.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ale kombinujesz :D.

 

Jak ACL ci nie śmiga można równie dobrze pojechać jeszcze w inny sposób - zrzucić logikę robienia backupów na serwer źródłowy, a po stronie serwera backupowego odpalać crona, który przerzuci to co wrzucił user źródłowy do bezpiecznego miejsca. Osiągasz w zasadzie to samo tylko inną drogą, i nie masz żadnych niepotrzebnych kopii, bo wynik końcowy zwyczajnie przenosisz (mv) według swojej własnej ustalonej logiki.

 

Ale o ile dobrze rozumiem autora chodzi o to by backup był inicjowany z zewnętrznego serwera, czyli by serwer B(ackupu) miał dostęp do określonych zasobów serwera G(łównego), ale by serwer G nie mógł sam nawiązać połączenia z serwerem B.

jak mu ktoś zrootuje serwer to się backup chociaż uchowa :)

  • Upvote 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Ale o ile dobrze rozumiem autora chodzi o to by backup był inicjowany z zewnętrznego serwera, czyli by serwer B(ackupu) miał dostęp do określonych zasobów serwera G(łównego), ale by serwer G nie mógł sam nawiązać połączenia z serwerem B.

jak mu ktoś zrootuje serwer to się backup chociaż uchowa :)

 

W tym wypadku również, bo user źródłowy nie ma dostępu root do serwera backupowego, a serwer backupowy sam ma logikę co robić z plikami wrzucanymi przez usera źródłowego.

 

I tak, rozumiem zamysł autora, i nie widzę jak rozwiązanie wyżej jest w jakikolwiek sposób gorsze od zmiany inicjatora, zakładając, że admin zastosuje się do całości mojego posta, a nie tylko jego części.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Ale o ile dobrze rozumiem autora chodzi o to by backup był inicjowany z zewnętrznego serwera, czyli by serwer B(ackupu) miał dostęp do określonych zasobów serwera G(łównego), ale by serwer G nie mógł sam nawiązać połączenia z serwerem B.

jak mu ktoś zrootuje serwer to się backup chociaż uchowa :)

 

Zgadza się, mimo wszystko nie chcę, aby to serwer G wysyłał backup na serwer B, tylko odwrotnie.

I robię backup backupu też. :D

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

W tym wypadku również, bo user źródłowy nie ma dostępu root do serwera backupowego, a serwer backupowy sam ma logikę co robić z plikami wrzucanymi przez usera źródłowego.

 

I tak, rozumiem zamysł autora, i nie widzę jak rozwiązanie wyżej jest w jakikolwiek sposób gorsze od zmiany inicjatora, zakładając, że admin zastosuje się do całości mojego posta, a nie tylko jego części.

 

Jeśli ktoś będzie tak ambitny że połączy sie do serwera backupowego, to i będzie na tyle ambitny by na G wgrać shella lub inne g..... i poczekać aż sie wyśle/samemu wysłać na backupowy i poczekać aż na backupie przeniesie się w "bezpieczne miejsce" i dalej działać.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Jeśli ktoś będzie tak ambitny że połączy sie do serwera backupowego, to i będzie na tyle ambitny by na G wgrać shella lub inne g..... i poczekać aż sie wyśle/samemu wysłać na backupowy i poczekać aż na backupie przeniesie się w "bezpieczne miejsce" i dalej działać.

 

Oczywiście, tylko chyba większa jest szansa, że jak już mieliby się połączyć to połączą się z którymś z serwerów G (a ich będzie kilkanaście/kilkadziesiąt), niż z jednym serwerem B.

 

A chyba dobrą praktyką jest, że to serwer B pobiera sobie backup z G, a nie że serwery G wysyłają backup na serwer B?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

tak, to jest prawidłowa praktyka i o tym mówie, zawsze lepiej jak B ma dostęp do G a nie odwrotnie :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

 

Jeśli ktoś będzie tak ambitny że połączy sie do serwera backupowego, to i będzie na tyle ambitny by na G wgrać shella lub inne g..... i poczekać aż sie wyśle/samemu wysłać na backupowy i poczekać aż na backupie przeniesie się w "bezpieczne miejsce" i dalej działać.

 

Podobnie ambitny człowiek podmieni źródła lub to, co serwer backupowy zasysa do siebie i wytworzy dokładnie tą samą sytuację. Nic się nie zmienia.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×