Nowatorskie narzędzie w hostingu współdzielonym - dostęp zdalny do backupu dla każdego użytkownika

[ahes 83]

A ja chciałbym poruszyć bardzo istotną kwestię.

 

Jak wasze znakomite systemy backupowe radzą sobie z włamaniami na konto użytkownika

lub włamaniem na wasze serwery, z których dane są backupowane?

 

Przykładowy scenariusz.

• Uzyskuję dostęp do maszyny www.
• Za pomocą crontab -l sprawdzam jak się nazywa skrypt backupowy.
• Zaglądam do środka i co widzę? Dane dostępowe do serwera backupowego.
• Loguję się do maszyny backupowej i daję rm -rf /
• Na serwerze www, do którego się włamałem także daję rm -rf /

 

Czyli firma zostaje:

1. bez serwera www
2. bez kopii zapasowej z serwera www

Scenariusz z punktu widzenia użytkownika.

• loguję się do panelu użytkownika zdobytym hasłem
• oglądam konfigurację backupu i pobieram dane uwierzytelniające do FTP
• loguję się na FTP i usuwam wszystko z serwera backupowego
• usuwam także wszystko z maszyny na której użytkownik ma konto

Czyli kolejny przykład, w którym backup staje się zupełnie bezwartościowy.

[Gość patrys]

Prosto: można backup wysłać via specjalne konto rsyncem na serwer backup'owy, klatka na koncie i snapshoty tego co jest w klatce w odrębne miejsce na systemie plików.

Włamanie na serwer główny i dojście jak wysyła się backup, a następne skasowanie go nic nie da.

No chyba, ze ktoś rozwali tą klatke na backupie

[Hekko.pl 239]

• Za pomocą crontab -l sprawdzam jak się nazywa skrypt backupowy.
  

Nie zobaczysz takowego. Ani w żadnym innymi pliku z zadaniami cron.. zatem pomijam dalsze kroki scenariusza..

 

• loguję się na FTP i usuwam wszystko z serwera backupowego

Czyli kolejny przykład, w którym backup staje się zupełnie bezwartościowy.

Backup jest tylko do odczytu.

Oba scenariusze obalone.

 

Oczywiście, istnieje masa innych możliwości jednak przed wszystkimi staramy się zabezpieczyć. Wszystko jednak ma swoją cenę..

[ahes 83]

@Patrys, ja wiem jak to zaimplementować, aby było bezpiecznie. Właściwie to już to zrobiłem.

Na moim blogasku<=tutaj kliknąć, poruszałem podobny problem.

 

@hekko, napisz więcej szczegółów bo z tym obalaniem jakiś bełkot wyszedł, zupełnie jakbyś obalił flaszkę wódki . Podsumowując maszyna, którą backupujesz nie posiada skryptu do backupu. To maszyna backupowa łączy się do maszyny backupowanej i pobiera dane, tak?

[Hekko.pl 239]

@hekko, napisz więcej szczegółów bo z tym obalaniem jakiś bełkot wyszedł, zupełnie jakbyś obalił flaszkę wódki . Podsumowując maszyna, którą backupujesz nie posiada skryptu do backupu. To maszyna backupowa łączy się do maszyny backupowanej i pobiera dane, tak?

 

Nawiązałem do Twojego posta. W skrócie napisałem, że żaden ze scenariuszy nie jest możliwy ze względu na posiadane zabezpieczenia. Niestety szczegółów więcej nie mogę udzielić co i jak - tutaj już każde słowo jest na wagę bezpieczeństwa - na pewno to rozumiesz.

 

Na jesieni planujemy także oddzielną lokalizację danych backupowych

[ahes 83]

Nawiązałem do Twojego posta. W skrócie napisałem, że żaden ze scenariuszy nie jest możliwy ze względu na posiadane zabezpieczenia. Niestety szczegółów więcej nie mogę udzielić co i jak - tutaj już każde słowo jest na wagę bezpieczeństwa - na pewno to rozumiesz.

 

 

Ee, jakieś bzdury. Security by obscurity nie zapewnia bezpieczeństwa.

Dobrą metodą jest:

• serwer backupowy łączy się po kluczach RSA do maszyny, z której ciągnie backup
• użytkownik na maszynie backupowanej w authorized_keys (do którego zapis ma jedynie root) ma ograniczenia do danego IP i do uruchomienia jedynie komendy rdiff-backup --server

Teraz dwa scenariusze:

1. przejęcie konta usera i rm -rf zniszczy mu jedynie dane, ale nie ma sposobu dostanie się do maszyny backupowej, ani też nie może spreparować pliku authorized_keys
2. przejęcie maszyny backupowej. Można wtedy kombinować z jakimś wywołaniem rdiff-backup które usuwa pliki zdalne. Rsync ma taką opcję więc prawdopodobnie też się da, ale nie sprawdzałem.

Jest jeszcze jeden scenariusz, że ktoś przejmuje całą maszynę backupowną i preparuje pliki authorized_keys - a właściwie to binarkę rdiff-backup z wywołaniem --server, tak aby uzyskać dostęp do maszyny backupowej. Raczej nie proste zadanie.

 

Scenariusz numer 2 bardzo niebezpieczny, więc dostęp do maszyny powinien być ustalany po kluczach z odpowiedniej lokalizacji i najlepiej aby nie oferowała żadnych innych usług oprócz SSH.