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.
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 pulpit, swój serwer WWW, jak monitorować zmiany w plikach, jak 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:
tomek:faktura lukasz:cyber123
- 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:
# nmap -p 873 --script rsync-list-modules <ip>
W repozytorium nmap znajduje się jeszcze jeden skrypt o nazwie rsync-brute, który wykonuje atak brute-force:
# nmap -p 873 --script rsync-brute --script-args 'rsync-brute.module=<nazwa modułu>' <ip>
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:
# rsync -v -e "ssh" /tmp/plik.txt [email protected]:~/katalog/
- 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.
Komentarze
Dlaczego używać rsync? To proste. Transparentność działań firmy w dzisiejszych czasach to bardzo pożądana cecha na wyginięciu. Protokół rsync wydaje się do zapewnienia tej wartości idealnym rozwiązaniem. :)
pytali o rsyncd…
Moim zdaniem, jeżeli wykorzystuje się samodzielny rsyncd w intranecie, lub do zrzucania zawartości z serwerów frontendowych (backup? statystyki? logi?) – na serwer zapasowy – umieszczony na backendzie (bez dostępu publicznego) – to nie widzę żadnych przeciwskazań. Jeżeli chcemy wyjść poza intranet komunikację rsynd możemy zabezpieczyć stunnel – co daje nam już fajne bezpieczne rozwiązanie.
Wpuszczanie na firewallu ruchu do tej usługi tylko z określonych, zaufanych adresów (publicznych). Opcjonalnie postawienie serwera VPN i wpuszczanie ruchu tylko z adresacji wewnętrznej (VPN-owej).
Gentoo portage. Od lat
Jak dla mnie jeśli jesteś ciekawy jak szybko ktoś się zainteresuje twoją maszyną i będzie próbował się dostać do danych to jak najbardziej:)
Ponieważ rsync jest opensource i możesz sobie w nim grzebać ile chcesz i kiedy chcesz, ma tyle lat co piramidy w Egipcie ,jeżeli upcham go w kwantowym krypto kanale to moje dane są dalej moje.
(Słowem wstępu Chce zaznaczyć że jestem waszym stałym czytelnikiem.)
Czytając Adamie twoje posty od wielu lat, zawsze myślałem że waszym celem jest jakość i otwartość. Po dzisiejszym poście należało by postawić pytanie: Czy celem Z3S była chęć zdyskredytowania rozwiązań open sourcowych za garść srebrników?. Adamie.. my zapomniany lud GNU zapłacimy za napisanie rzetelnego artykułu o open sourcowych aplikacjach i pomysłach(best practice) na backup.
Niech społeczność internetowa czerpie wiadrami z tej studni, – niech się backupuje za darmo, bezpiecznie, i szczęśliwie przywraca.
Podaj proszę kwotę i adres portfela.
Pozdrawiam Opensourcewithlove
Cześć, skoro czytasz stronę to może poszukaj teraz w ramach zadania domowego poprzednich poradników z tej serii – chyba praktycznie w każdym polecamy rozwiązania otwartoźródłowe. rsyncd po prostu na to nie zasługuje i tyle.
Okey odrabiam lekcje
… używanie rsync to zły pomysł …
Hmmm a to chyba z waszego ostatniego poradnika.
„rsync –dry-run –remove-source-files -avz -e \
„ssh” –progress \
${DESTINATION_DIR} \
${REMOTE_USER}@${REMOTE_SERVER}:${REMOTE_DIR}”
Schizofrenia XXI wieku, lub literówka.
rsync upchany w coś, np w ssh jest cacy. stosować bez obaw.
Pozdrawiam
rsync vs rsyncd
Adamie…..jeszcze pokuta!
Na pokutę Panie Adamie wyznaczam:
– wygłoszenie charytatywnie wspaniałej prelekcji „O ochronie danych i prywatności w internecie dla najmłodszych.”,
,lub przesłanie charytatywnie wspaniałych koszulek (które przypominają mi moje lata dzieciństwa z atarii)
dla dzieciaków z domu dziecka w Rzeszowie.
http://www.dommieszko.pl/. (placówka wylosowana randomem)
Pamiętaj że rsyncd to DEMON! nie ma żartów….a cel i chwila podniosła.
Pozdrawiam i spadam …….
@Adamie popieram w 100%.
Dodam od siebie autor tematu chyba nie odrobił zadania domowego.
Rsyncd nie dość że działa lepiej to jeszcze można go puścić przez tunel ssh i po temacie!
Dla niewtajemniczonych rsuncd staje się wtedy na tyle bezpieczny na ile bezpieczny jest sam tunel ssh.
Przy poprawnej implementacji rsync=rsynd z tym, że ten drugi ma fajne ficzery których nie ma i nigdy nie będzie mieć rsync.
Autorowi daję ocenę 2 za wprowadzanie opinii w błąd i słabe a w zasadzie błędne przygotowanie merytoryczne tematu bezpieczeństwa Rsyncd.
Ah…Adamie zapomniałbym
Jeżeli trzymamy się etyki dziennikarsko/piśmienno/technicznej, to Prośba o changelog z edycji posta. Co było, a co się poprawiło. Może to być przekreślone,podkreślone, data, czas edycji, powód.
Będzie super przejrzyście i z szacunkiem.
Dziękuje!
Moglibyście dopisać coś o alternatywach: syncthing, btsync, itd?
BTSync nie zmienił nazwy na Resilio Sync? Ponadto wymaga chyba kontaktu z trackerem Resilio dla nawiązania połączeń.
To „rsync” czy „rsyncd”? W drugim akapicie dokonujecie rozróżnienia tych programów, żeby pod jego koniec napisać „(…) używanie rsync to zły pomysł (…)”.
Zakładając, że w pytaniu konkursowym piszecie o „rsync” to odpowiedź brzmi: po co używać „rsync”, skoro jest „rsync -e’ssh'”.
Jeżeli zaś kwestia rozchodzi się o „rsyncd”, to po co używać „rsyncd” skoro jest „rsync -e’ssh’ .)
Tekst ujednolicony pod kątem rsync vs rsyncd.
Osobiście używam rsyncd i zawsze podaję w host allow adres ip serwera który może się łączyć z usługą. Nie słyszałem o bugu który umożliwiał by łączenie się z innych ip więc uważam to za bezpieczne rozwiązanie.
Protokół rsync bywa dobrą alternatywą dla http w przypadku serwowania ogólnodostępnych plików. Jeśli do danych dostęp ma każdy i nie są one poufne, nie potrzebujemy uwierzytelniania ani szyfrowania. Poprawność pobranych w ten sposób danych można weryfikować sumami kontrolnymi i podpisami cyfrowymi.
Dobrym przykładem użycia rsyncd w ten sposób jest dystrybucja obrazów instalacyjnych systemu Linux, jak tu: http://www.knopper.net/knoppix-mirrors/index-en.html
Protokół rsync dla anonimowych klientów daje dużo większe możliwości niż http.
> Jeśli do danych dostęp ma każdy i nie są one poufne, nie potrzebujemy uwierzytelniania
– Zgadzam się.
> ani szyfrowania.
– W dzisiejszych czasach każde połączenie powinno być szyfrowane,
ze względu na możliwość ataku w locie „Man in the middle”
Nie polecałbym tylko SSL, bo życie pokazuje że co chwilę ma dziury.
Największym problemem rsyncd jest to, że klient nie jest w stanie uwierzytelnić serwera, o czym nie napisaliście. Można więc go używać tylko w „bezpiecznym” środowisku. Aby takie środowisko stworzyć należy użyć jakąś nakładkę stosując:
– OpenVPN (lub inny VPN)
– stunnel
Obydwa powyższe są w stanie zarówno uwierzytelniać się certyfikatami jak i szyfrować połączenia. Stunnel ma tą przewagę nad OpenVPN, że można uruchamiać klienta bez konieczności używania konta super użytkownika. Z kolei OpenVPN będzie bardziej pomocny przy słabej jakości łącz.
Nie potrzebujesz uwierzytelniania serwera, jeśli możesz uwierzytelnić payload (dystrybucja podpisanych pakietów rpm, na przykład).
„dlaczego należałoby korzystać z usługi rsync w 2017 roku”
Żeby skusić „zainteresowanych” do odwiedzenia naszego Honeypota ;)
Po co używać rsyncd? Żeby branża związana z bezpieczeństwem miała jakieś proste tzw. „quick win” ;)
Moje wrazenia odnosnie wpisu. Autor ostrzega przed rozwiazaniem ktore nie szyfruje komunikacji i nie szyfruje danych. Co jest oczywista oczywistoscia, ja moje backupy robie rsync przez ssh na luksa, czy dobrze robie?
rsync jest używany w portage. Tak nie ma sprawdzania integralności, lecz dzięki temu protokołowi jest możliwe zmniejszenie ruchu sieciowego ze względu na pobieranie tylko różnic (nawet w plikach binarnych)
Rsync nie jest ale był używany w Portage.
Drzewko Portage wzorem Funtoo zmigrowało tutaj:
https://github.com/gentoo-mirror/gentoo
Rsync jest genialnym narzędziem do kopiowania danych, pozwala przenosić cały system operacyjny na inną maszynę i tam go uruchomić, zachowuje uprawnienia,atrybuty ACL i sprawdza sumy kontrolne.
Ale prywatne i poufne dane się kopiuje przez tunele SSH albo VPN, a nie wystawia na świat,niezależnie od używanego protokołu sieciowego.
Rdiff-backup do kopii przyrostowych też bazuje protokole rsync.
pzdr
„dlaczego należałoby korzystać z usługi rsync w 2017 roku”
gdyż nie ma to jak dawka adrenaliny, kiedy to pliki serwera latają w necie jak Boeing 737 podczas turbulencji :D
Bezpieczniej używać rsyncd można chyba wraz z połączeniem rsync+ssh+gpg+duplicity+VPN.
Czyli jako serwer konfigurujemy rsyncd następnie przy pomocy duplicity wypychamy już zaszyfrowane przy użyciu gpg pliki. Dodatkowo można oczywiście do samego serwera rsyncd nadać dostęp tylko z konkretnych adresów, portów itd.
Tego typu rozwiązanie powinno umożliwić kompresje, pełne i przyrostowe kopie, szyfrowanie i podpisywanie. Oczywiście nie twierdze że nie ma ono żadnych minusów ale jeśli patrząc na samego rsyncd to w połączeniu z duplicity oraz gpg daje nam to poprawę bezpieczeństwa.
Bezpieczniej używać rsyncd można wraz z połączeniem rsync+ssh+gpg+duplicity+VPN.
Czyli jako serwer konfigurujemy rsyncd następnie przy pomocy duplicity wypychamy już zaszyfrowane przy użyciu gpg pliki. Dodatkowo można oczywiście do samego serwera rsyncd nadać dostęp tylko z konkretnych adresów, portów itd.
Tego typu rozwiązanie powinno umożliwić kompresje, pełne i przyrostowe kopie, szyfrowanie i podpisywanie. Oczywiście nie twierdze że nie ma ono żadnych minusów ale jeśli patrząc na samego rsyncd to w połączeniu z duplicity oraz gpg daje nam to poprawę bezpieczeństwa.
Ja swoje backupy (których zawartość ma pozostać tajna) na zdalny serwer robię następująco:
1. Montuję zdalny zasób przez sshfs przy użyciu klucza,
2. Montuję z tak podmontowanego zasobu kontener VeraCrypt,
3. Uruchamiam rsync.
Jak ktoś ma lepszy pomysł, chętnie wysłucham sugestii.
Dlaczego warto skorzystać czasem z rsync? Usunięcie za jego pomocą 500 000 plików z jednego katalogu (poprzez synchronizację z innym pustym) trwa szybciej niż rm -f * i w ogóle działa (rm się wywali) – miałem raz taki przypadek u klienta po nie czyszczeniu foleru z sesjami przez kilka lat.
W ramach jednej maszyny fizycznej ale rsyncd między wirtualkami nie jest chyba złym pomysłem. Ruch odbywa się w wirtualnym switchu i chyba jest raczej bezpieczny. Nie doszukuję się sensu takiego rozwiązania ale pewnie by się znalazł.
…czy się mylę?
1. rsyncd jest używany wewnętrznie w klastrach storage’u obiektowego Openstack Swift do replikacji wewnątrz klastra. Oznacza to, że zwykle dzieje się to w jakimś backendowym LAN. Nie wiem, czy można łatwo wymienić tu rsyncd na inne rozwiązanie. https://docs.openstack.org/newton/config-reference/object-storage/rsyncd.html
2. Wygląda na to, że część komentujących jednak kompletnie pogubiła się między rsyncd a rsync.
Myślę że użycie tego jako opcji przesyłania danych między kontenerami w Dockerze będzie dość bezpiecznym i szybkim rozwiązaniem. Dane wysyłane między kontenerami jak pamiętam są szyfrowane, a póki nie wystawimy portu ten nie będzie dostępny poza kontenerami.
W zgodzie z tym co w artykule – konkurs składa się z dwóch (a nie jednej!) części ;)
1. Czy da się bezpiecznie używać rsyncd?
2. Czy należałoby korzystać z usługi rsyncd w 2017 roku?
Odpowiedź na pytanie pierwsze jest banalna i jakże charakterystyczna dla naszej branży. Mianowicie: to zależy. W pewnych ściśle określonych warunkach da się, dlatego odpowiedź jest twierdząca.
Odpowiedź na pytanie drugie jest… banalna i jakże charakterystyczna dla naszej branży. Mianowicie: to zależy. Narzędzie dobiera się do zadania, istnieją zastosowania w których rsyncd się sprawdzi, dlatego odpowiedź jest twierdząca.
A teraz troszkę poważniej.
1. Rsyncd może stanowić lep. Odciągać uwagę od tego, co naprawdę ważne. Oczywiście jest to niewiele lepsze „zabezpieczenie” od zmiany portu z 22 na 2222, niemniej odpowiednio spreparowane może się przydać. Powiedzmy, że rsyncd to wyłącznie trigger dla systemu alarmowego – nie pełni jakiejkolwiek innej funkcji jak powiadamianie admina o tym, że ktoś dotknął rsyncd w jakikolwiek(!) sposób… a skoro tak, to jest „nienormalnym” użytkownikiem. Czyli Honeypot po prostu.
2. CPU! Brak szyfrowania wyklucza wystawianie gołego rsyncd w internecie, ale w sieci lokalnej nie przewidujemy chyba MITM, prawda? ;) Z powodzeniem można sobie w ten sposób spiąć kilka maszyn, które działają w malutkiej, (prawie?) całkowicie odciętej podsieci na zasadzie „nie będę sam sobie niczego kwitować” (por. Poszukiwany, Poszukiwana), a ich głównym założeniem jest brak zbędnych opóźnień i tyrania procesora ;)
3. Prostota.
4. Łatwość opakowywania – golasa można ubrać w prawie wszystko.
Chciałem się rozpisać, jednak najrozsądniej będzie po prostu podpisać się pod wypowiedzią kolegi @Hilary.
Dodam od siebie, że rsyncD wykorzystuję od lat w sposób bardzo intensywny. Jedyna różnica jest taka, że rsyncD uruchamiam zdalnie jedynie na czas transferu. Synchronizacja kilkunastu plików, po 50GB każdy – cudo :-)
Rsyncd pozwala zrobić hook na początek lub koniec transmisji. Doskonale się to nadaje do zrobienia snapshota zfs po rsyncu kopii zapasowej
Dlaczego nagroda konkursu jest premiowana za podanie rozwiązania, które wspiera niewskazane rozwiązanie? To powinien być konkurs na podanie najlepszej i najbezpieczniejszej alternatywy ;) Tak to szczęście w nieszczęściu!
ja tam korzystam cały czas z rsyncd, filtruję IP na routerze, firewallu i dodatkowo mam zrobione „hosts allow”
rsyncd jest dobrym rozwiązaniem, ale nie do wszystkiego. Do bezpiecznego przesyłania danych sam w sobie się nie nadaje, ale jeśli dane są publiczne i możemy w inny sposób zweryfikować autentyczność tych danych (podpis / skrót / itp) to jest to rozwiązanie równie dobre co ftp czy plaintext http.