Dlaczego rsyncd jest zły i powinniście już dawno przestać z niego korzystać

dodał 21 listopada 2017 o 07:19 w kategorii HowTo  z tagami:
Dlaczego rsyncd jest zły i powinniście już dawno przestać z niego korzystać

W naszej serii poradników dla administratorów najczęściej opowiadamy o tym, jak rozwiązać jakiś problem lub skonfigurować usługę związaną z bezpieczeństwem. Tym razem jednak opowiemy Wam, czego zdecydowanie NIE robić.

Czy kogokolwiek z Was musimy przekonywać, że nie należy korzystać z usługi telnet? Chyba nie, a jednak… W polskiej sieci można trafić na liczne serwery usługi rsyncd, która, łagodnie rzecz ujmując, wcale bezpieczna nie jest. Co więcej, nie jest prosto ją chociażby odrobinę zabezpieczyć. Jak wspominaliśmy w naszych webinarach, błędy konfiguracyjne różnych usług sieciowych mogą stwarzać poważne problemy bezpieczeństwa. Niestety wielu administratorów do dnia dzisiejszego wykorzystuje usługę rsyncd do synchronizacji plików przez sieć, głównie do wykonywania kopii zapasowych. Omawialiśmy i opisywaliśmy różne podejścia do tworzenia bezpiecznych kopii zapasowych i zdecydowanie rsyncd nie jest jednym z narzędzi, które do tego celu rekomendujemy.

Artykuł pod patronatem Aruba Cloud

We współpracy z firmą ArubaCloud pokazaliśmy Wam, jak postawić swój serwer backupów, jak skonfigurować własny serwer VPN i podłączyć do niego komputer, telefony komórkowe oraz domowy ruter a także jak schować się przed cenzurą sieci i jak zacząć serwer zabezpieczać, jak postawić swój własny zdalny pulpitswój serwer WWWjak monitorować zmiany w plikachjak zablokować reklamy na komórce, jak skonfigurować bezpieczną kopię zapasowąjak zabezpieczyć logowanie do serwera za pomocą jednorazowych tokenów  lub za pomocą klucza Yubikey a także jak monitorować swoje systemy w dwóch odsłonach oraz jak postawić swój serwer Jabbera.

Jeśli nie macie jeszcze swojego własnego serwera, to jest to dobra okazja by się w taki wyposażyć. Aruba oferuje dwa miesiące korzystania ze swojego podstawowego serwera gratis – a po zakończeniu promocji będzie on Was kosztował zaledwie 4 złote miesięcznie. Co więcej Aruba ma już serwerownię w Warszawie. Instrukcję jak krok po kroku skorzystać z promocji i uruchomić swój serwer znajdziecie w tym artykule. Jeśli macie już swój serwer – to zapraszamy do lektury kolejnych akapitów.

rsync vs rsyncd

Na początek przyda się kilka słów wyjaśnienia. Rsync to narzędzie dostępne z wiersza poleceń w którym wszelkie parametry przekazywane są jako argumenty wywołania programu. Z kolei rsyncd nasłuchuje na określonym porcie jako usługa sieciowa. Usługa ta bazuje na pliku konfiguracyjnym (zazwyczaj /etc/rsyncd.conf). Plik konfiguracyjny składa się z modułów i parametrów. Moduł rozpoczyna się od nazwy modułu w nawiasach kwadratowych. Moduły zawierają parametry: „nazwa = wartość”.

Zanim przejdziemy do dalszej części artykułu, pamiętajmy o tym, że:

  • komunikacja za pomocą usługi rsyncd (873/tcp) odbywa się w sposób nieszyfrowany,
  • usługa podatna jest na ataki brute-force,
  • nie znajdujemy żadnego rozsądnego argumentu by w 2017 roku korzystać z usługi rsyncd.

Aby zrozumieć, dlaczego używanie rsyncd to zły pomysł, omówmy działanie tej usługi. Zacznijmy od podstawowych ustawień w pliku rsyncd.conf.

Zawartość pliku rsyncd.conf

Poniżej znajdziecie opis najważniejszych ustawień, opracowany na podstawie dokumentacji rsyncd.conf(5):

Globalna konfiguracja usługi:

  • motd file – Ten parametr umożliwia określenie „komunikatu dnia”, który będzie wyświetlany klientom przy każdym połączeniu. Zwykle zawiera informacje o serwerze i wszelkie uwagi prawne. Wartością domyślną jest brak pliku MOTD. Nic tak nie odstrasza potencjalnych atakujących jak MOTD na pół ekranu z informacjami prawnymi. Już w drzwiach warto informować gości, że dane na serwerze są poufne.
  • port – Domyślnie jest tcp/873. Możecie określić domyślny port usługi rsyncd, podając wartość. Jest to ignorowane, jeśli demon jest uruchamiany przez inetd. Zmiana portu może tymczasowo utrudnić kradzież danych z twojego serwera.
  • address – Możecie określić adres IP na którym usługa rsyncd będzie nasłuchiwała. Jeśli musisz ustawić adres IP, to wyłącznie publiczny. Jeśli ustawisz prywatny adres IP liczba odwiedzin może drastycznie spaść.

Konfiguracja modułu:

Po parametrach globalnych należy zdefiniować liczbę modułów, a każdy moduł eksportuje drzewo katalogów jako nazwę symboliczną. Moduły są eksportowane przez określenie nazwy modułu w nawiasach kwadratowych [moduł], a następnie określane są parametry dla tego modułu.

  • path – Ten parametr określa katalog w systemie plików, który ma być dostępny w tym module. Im krótsza ścieżka, tym szerszy dostęp dla potecjalnych gości. 
  • use chroot – Jeśli „use chroot” ma wartość true, usługa będzie chrootowała do „ścieżki” przed rozpoczęciem przesyłania pliku. Ma to tę zaletę, że zapewnia dodatkową ochronę przed ewentualnymi lukami w zabezpieczeniach implementacji usługi, ale ma wady wymagające uprawnień superużytkownika oraz braku możliwości podążania za symbolicznymi łączami, które są albo absolutne, albo poza ścieżką główną.
  • max connections – Ten parametr pozwala określić maksymalną liczbę dozwolonych jednoczesnych połączeń. Każdy klient łączący się po osiągnięciu maksimum otrzyma komunikat mówiąc mu, by spróbował później. Wartością domyślną jest 0, co oznacza brak limitu. Wartość ujemna wyłącza moduł.
  • log file – Gdy parametr „log file” jest ustawiony na niepusty łańcuch, usługa rsyncd będzie logowała komunikaty do wskazanego pliku, zamiast używać rejestru syslog. Jest to szczególnie przydatne w systemach takich jak np. AIX, gdzie syslog() nie działa w przypadku chrootowanych programów. Jeśli ta wartość jest ustawiona dla poszczególnych modułów zamiast globalnie, dziennik globalny nadal będzie zawierał wszelkie błędy autoryzacji lub komunikaty o błędach pliku konfiguracyjnego. Warto włączyć logowanie do pliku na rzecz sysloga aby mieć rozliczalność (po odpowiednio długim czasie) kogo gościliśmy na serwerze.
  • max verbosity – Ten parametr pozwala kontrolować maksymalną ilość pełnych informacji, które dasz generować usłudze (ponieważ informacja trafia do pliku logu).
  • read only – Ten parametr określa, czy klienci będą mogli przesyłać pliki, czy nie. Jeśli „read only” jest ustawione na true, każda próba przesłania nie powiedzie się. Jeśli „read only” jest ustawione na „false”, to przesłanie będzie możliwe, jeśli pozwalają na to uprawnienia do plików po stronie usługi. Domyślnie wszystkie moduły są tylko do odczytu.
  • write only – Ten parametr określa, czy klienci będą mogli pobierać pliki, czy nie. Jeśli „write only” jest ustawione na true, każda próba pobrania zakończy się niepowodzeniem. Jeśli „write only” jest false, pobieranie będzie możliwe, jeśli pozwolą na to uprawnienia do plików po stronie usługi. Wartością domyślną jest „false” – czym chata bogata.
  • auth users – Ten parametr określa rozdzielaną przecinkami i spacjami listę nazw użytkowników, które będą mogły łączyć się z tym modułem. Nazwy użytkowników nie muszą istnieć w systemie lokalnym. Jeśli ustawione zostanie „auth users”, klient będzie musiał podać nazwę użytkownika i hasło, aby połączyć się z modułem. Nazwy użytkownika i hasła w postaci zwykłego tekstu są przechowywane w pliku określonym przez parametr „secrets file”. Aby nie utrudniać potencjalnym odwiedzającym dostępu do naszych danych, domyślnie wszyscy użytkownicy mogą łączyć się bez hasła (nazywa się to „anonimowym rsyncd”).
  • secrets file – Ten parametr określa nazwę pliku, który zawiera pary nazwa użytkownika:hasło używane do uwierzytelniania dla modułu. Ten plik jest sprawdzany tylko wtedy, gdy parametr „auth users” został określony. Plik składa się z par nazwa użytkownika:hasło oddzielone pojedynczym dwukropkiem.

Standardowo nie ma wartości domyślnej dla parametru „secrets file”. Możesz (ale nie musisz) określić dowolny plik (np. /etc/rsyncd.secrets) w którym będą zdefiniowane niebezpieczne pary zapisane plaintextem.

Plik /etc/rsyncd.secrets wyglądałby tak:

  • hosts allow – Ten parametr pozwala określić listę wzorców dopasowanych do nazwy hosta połączenia i adresu IP klienta. Jeśli żaden z wzorców nie pasuje, połączenie zostaje odrzucone.
  • hosts deny – Ten parametr pozwala określić listę wzorców dopasowanych do nazwy hosta połączenia i adresu IP klienta. Jeśli wzorzec się zgadza, połączenie zostanie odrzucone. Wartością domyślną jest brak parametru „hosts deny”, co oznacza, że wszystkie hosty mogą się łączyć.
  • transfer logging – Ten parametr włącza logowanie plików które zostały pobrane/wysłane. Usługa rejestruje transfer na końcu, więc jeśli transfer zostanie przerwany, w pliku dziennika nie będzie żadnej wzmianki.

Analogia nowoczesności i bezpieczeństwa

Siła uwierzytelnienia

Jeśli opis dostępnych opcji Was jeszcze nie przekonał, że używanie rsyncd to nie jest najlepszy pomysł, to zobaczcie, jak wygląda uwierzytelnienie użytkownika. Protokół uwierzytelniania używany w rsyncd to skomplikowany 128-bitowy MD4 oparty na challenge-response. Jest to jednak dość słaba ochrona, więc jeśli chcecie naprawdę najwyższej jakości zabezpieczenia, zalecamy uruchomienie rsyncd przez SSH. Co prawda przyszła wersja rsyncd podobno będzie wykorzystywała bezpieczniejsze funkcje skrótu, to dzisiaj nie ma zbyt wielkiego wyboru.

Zauważcie też, że usługa rsyncd nie zapewnia obecnie żadnego szyfrowania danych przesyłanych przez sieć. Dostępne jest tylko uwierzytelnianie. Naprawdę lepiej skorzystać z innych protokołów do przesyłania danych. Przyszłe wersje rsyncd podobno będą mogły obsługiwać protokół SSL w celu lepszego uwierzytelniania i szyfrowania, ale dzisiaj taka funkcja nie jest dostępna.

Pentest protokołu rsyncd

Testowanie bezpieczeństwa usługi rsyncd nie jest zbyt skomplikowane. Nmap posiada skrypt „rsync-list-modules”, którego zadaniem jest pozyskanie wszystkich dostępnych modułów w usłudze rsyncd:

W repozytorium nmap znajduje się jeszcze jeden skrypt o nazwie rsync-brute, który wykonuje atak brute-force:

Korzystam z rsyncd w swojej firmie/organizacji…

Mamy nadzieję, że nie synchronizujecie jakichkolwiek danych za pomocą usługi rsyncd. Jeśli jest inaczej, poważnie rozważcie zmianę sposobu synchronizacji danych. Jest pełno lepszych opcji, np.

  • Kopiujcie dane za pomocą protokołu SSH. Autoryzujcie się za pomocą kluczy, a nie haseł.

Przykład transferu danych za pomocą polecenia (polecenia, nie usługi) rsync przez protokół SSH:

  • Stwórzcie tunel SSH/VPN pomiędzy klientem, a serwerem docelowym.

Dla Waszego bezpieczeństwa nie opublikujemy przykładowego bezpiecznego pliku konfiguracyjnego – przyjmijmy, że takowy nie istnieje.

Konkurs!

Jeśli uważacie, że da się bezpiecznie używać rsyncd, to czekamy na Wasze odpowiedzi w komentarzach. Osoba, która zdaniem komisji konkursowej poda najlepszy argument dlaczego należałoby korzystać z usługi rsyncd w 2017 roku otrzyma firmową koszulkę z3s.

Dla pełnej przejrzystości – nie zachęcamy do korzystania z usługi rsyncd w sieciach publicznych.  Za przygotowanie oraz opublikowanie powyższego artykułu otrzymujemy wynagrodzenie.