Backup - użytkownik tylko do odczytu

[Desavil 88]

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!

[ksk 67]

ACL ? Zarządzanie grupami ?

[Pan Kot 1535]

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 Kwiecień 19, 2016 przez Archi (zobacz historię edycji)

[Desavil 88]

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

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 Kwiecień 19, 2016 przez Desavil (zobacz historię edycji)

[Pan Kot 1535]

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.

[Desavil 88]

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 Kwiecień 20, 2016 przez Desavil (zobacz historię edycji)

[likufanele 77]

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.

[Desavil 88]

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)

[likufanele 77]

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 Kwiecień 20, 2016 przez likufanele (zobacz historię edycji)

[Pan Kot 1535]

Ale kombinujesz .

 

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.

[Marek607 655]

Ale kombinujesz .

 

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

[Pan Kot 1535]

 

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.

[Desavil 88]

 

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ż.

[Marek607 655]

 

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ć.

[Desavil 88]

 

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?

[Marek607 655]

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

[Pan Kot 1535]

 

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.