Kopie zapasowe w stylu rsyncd

Sat 14 November 2009 by admin

Nie trzeba przekonywać nikogo o słuszności robienia kopii zapasowych, podobnie jak ich bezpiecznego przechowywania. W przypadku gdy posiadamy kilka maszyn słusznie jest wydzielić do roli serwera składującego kopie zapasowych jedną z nich. Sposobów na wykonywanie kopii zapasowych, ich przesyłanie i składowanie jest wiele, w tym przypadku postaram sie przybliżyć popularne rozwiązanie rsyncd współpracujące z ssh.

Rsyncd nie jest częścią rozwiązania rsync służącego do synchronizacji plików przez sieć, działającego w oparciu o przesyłanie różnic. Rsyncd udostępnia zasoby, warunkuje do nich dostęp ograniczając go do wybranych użytkowników, tylko do określonych katalogów, dostęp możliwy jest w trybie do odczytu lub/i zapisu etc. Rsyncd nasłuchuje standardowo na porcie 873, cała transmisja jest nieszyfrowana a autoryzacja użytkowników w oparciu o 128 bit sumę MD4 co nie stanowi dobrego zabezpieczenia o czym wspomina już sam man rsyncd.conf:

The authentication protocol used in rsync is a 128 bit MD4 based challenge response system. This is fairly weak protection, though (with at least one brute-force hash-finding algorithm publicly available), so if you want really top-quality security, then I recommend that you run rsync over ssh. (Yes, a future version of rsync will switch over to a stronger hashing method.)

Zgodnie z zaleceniami warto przepuścić ruch do/z rsyncd przez tunel ssh, aby zestawić tunel ssh potrzebujemy użytkownika systemowego najlepiej autoryzowanego po kluczu publicznym (użytkownik ,,ssh'' to nie ten sam użytkownik co wymagany dodatkowo przez rsyncd). Jednak gdy stworzymy takiego użytkownika musimy ograniczyć mu możliwości w szczególności dostęp do shell'a ustawiając go np. na /sbin/nologin lub skorzystać z pliku authorized_keys odpowiednio go modyfikując:

from="192.168.1.11",command="echo 'restricted'" ssh-dss AAAAB3....

pole from ograniczy dostęp do konta z podanego adresu IP, zaś po zalogowaniu wykonane zostanie polecenie echo i użytkownik zostanie wylogowany. Zamiast polecenia echo możemy uruchomić na żądanie rsyncd, zsynchronizować pliki i skillować rsyncd. Jednak jeżeli zdecydowaliśmy się na centralny serwer backup to niech rsyncd będzie jednorazowo uruchamiany. Konfiguracja rsyncd przedstawia się następująco:

# rsyncd.conf
#

# Set this if you want to stop rsync daemon with rc.d scripts
pid file = /var/run/rsyncd.pid
address = 127.0.0.1

use chroot = yes
max connections = 4

[bkp1]
path = /home/bkp1
comment = Backup Place #1
auth users = witalis
read only = false
write only = true
secrets file = /usr/local/etc/rsyncd.secrets

rsyncd nasłuchuje jedynie na interfejsie lo0 tak aby nie był ,,widziany z zew.'', rsyncd działa w środowisku chroot dla zwiększenia bezpieczeństwa oraz do zasobu bpk1 dostęp z zapisem ma tylko użytkownik witalis, którego hasło zapisane jest w /usr/local/etc/rsyncd.secrets.
Aby zsynchronizować dane jednej z maszyn na centralny serwer backup wpierw zestawiamy tunel ssh:

$ ssh -f -N -L 1500:localhost:873 <adres_ip_bkp>

następnie synchronizujemy dane:

$ rsync -av --password-file=/path/to/pass . rsync://witalis@localhost:1500/bkp1

po pomyślnym zsynchronizowaniu danych zamykamy tunel. Tym prostym sposobem nasze dane przysyłane są w bezpieczny sposób, a dostęp do nich chroniony jest hasłem oraz kluczem dostępowym ssh. Do podobnych rozwiązań ograniczających dostęp jedynie do przysyłania plików możemy zaliczyć scponly jest to zamiennik systemowego shell'a, istnieje również jego zmodyfikowana wersja scponlyc pracująca w środowisku chroot, jednak wymaga ona ręcznego stworzenia takiego środowiska przez co jest trudniejsza w instalacji.


Comments