Skocz do zawartości


 

Zdjęcie

Backup - użytkownik tylko do odczytu

Backup - użytkownik tylko do odczytu

  • Proszę się zalogować aby odpowiedzieć
16 odpowiedzi na ten temat

Backup - użytkownik tylko do odczytu

#1 Desavil

Desavil

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 565 postów
  • Skąd:/dev/random
  • Imię:Wojtek

Napisany 19 kwiecień 2016 - 16:56

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!


  • 0

#2 ksk

ksk

    Rugot

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 1444 postów
  • Skąd:Sosnowiec
  • Firma:ING Services Polska
  • Imię:Tomasz
  • Nazwisko:Kisielewski

Napisany 19 kwiecień 2016 - 20:37

ACL ? Zarządzanie grupami ?


  • 0

#3 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 19 kwiecień 2016 - 21:14

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.


Edytowany przez Archi, 19 kwiecień 2016 - 21:16.

  • 1

#4 Desavil

Desavil

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 565 postów
  • Skąd:/dev/random
  • Imię:Wojtek

Napisany 19 kwiecień 2016 - 21:30

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


Edytowany przez Desavil, 19 kwiecień 2016 - 21:32.

  • 0

#5 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 19 kwiecień 2016 - 22:00

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.


  • 0

#6 Desavil

Desavil

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 565 postów
  • Skąd:/dev/random
  • Imię:Wojtek

Napisany 20 kwiecień 2016 - 10:18

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ę?


Edytowany przez Desavil, 20 kwiecień 2016 - 11:05.

  • 0

#7 likufanele

likufanele

    Stały użytkownik

  • Użytkownicy
  • PipPipPipPipPip
  • 232 postów

Napisany 20 kwiecień 2016 - 10:18

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.


  • 0

#8 Desavil

Desavil

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 565 postów
  • Skąd:/dev/random
  • Imię:Wojtek

Napisany 20 kwiecień 2016 - 10:21

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)


  • 0

#9 likufanele

likufanele

    Stały użytkownik

  • Użytkownicy
  • PipPipPipPipPip
  • 232 postów

Napisany 20 kwiecień 2016 - 10:40

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.sour...root_be_avoided

 

Tutaj też znalazłem ciekawe rozwiązanie: https://learninginli...r-side-options/


Edytowany przez likufanele, 20 kwiecień 2016 - 10:50.

  • 0

#10 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 20 kwiecień 2016 - 13:43

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.


  • 0

#11 Marek607

Marek607

    Weteran WHT

  • WHT+
  • PipPipPipPipPipPipPipPip
  • 1876 postów
  • Imię:Marek
  • Nazwisko:Drzewiecki

Napisany 20 kwiecień 2016 - 13:57

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 :)


  • 1

#12 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 20 kwiecień 2016 - 14:01

 

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.


  • 0

#13 Desavil

Desavil

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 565 postów
  • Skąd:/dev/random
  • Imię:Wojtek

Napisany 20 kwiecień 2016 - 14:14

 

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


  • 0

#14 Marek607

Marek607

    Weteran WHT

  • WHT+
  • PipPipPipPipPipPipPipPip
  • 1876 postów
  • Imię:Marek
  • Nazwisko:Drzewiecki

Napisany 20 kwiecień 2016 - 14:37

 

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


  • 0

#15 Desavil

Desavil

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 565 postów
  • Skąd:/dev/random
  • Imię:Wojtek

Napisany 20 kwiecień 2016 - 14:46

 

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?


  • 0

#16 Marek607

Marek607

    Weteran WHT

  • WHT+
  • PipPipPipPipPipPipPipPip
  • 1876 postów
  • Imię:Marek
  • Nazwisko:Drzewiecki

Napisany 20 kwiecień 2016 - 14:58

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


  • 0

#17 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 20 kwiecień 2016 - 15:18

 

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.


  • 0





0 użytkowników czyta ten temat

0 użytkowników, 0 gości, 0 anonimowych użytkowników