Nie dochodzi poczta z infrastruktury Hetzner, OVHcloud lub innego operatora? Wyjaśniamy przyczynę

Zdarza się, że wiadomość wysłana do osoby korzystającej z poczty utrzymywanej na naszym serwerze nie zostaje dostarczona. Nie ma jej w skrzynce odbiorczej, nie trafia do spamu, a nadawca jest przekonany, że e-mail został wysłany prawidłowo.

W części takich przypadków problem nie wynika z awarii skrzynki pocztowej ani z błędu po stronie odbiorcy. Połączenie zostaje odrzucone, ponieważ serwer nadawcy działa w infrastrukturze, z której wcześniej wielokrotnie odnotowywaliśmy ataki, automatyczne skanowanie, próby włamań, spam albo inny ruch zagrażający bezpieczeństwu i stabilności naszych usług.

Nie blokujemy takich połączeń dla wygody. Robimy to, ponieważ odpowiadamy za bezpieczeństwo danych, stabilność serwerów i jakość usług świadczonych naszym klientom.

Dlaczego czasami blokowana jest większa pula adresów?

Ataki na serwery rzadko są prowadzone długo z jednego, stałego adresu IP. Po zablokowaniu jednego adresu podobny ruch potrafi pojawić się z kolejnego serwera działającego w tej samej infrastrukturze.

W praktyce obserwujemy między innymi automatyczne wyszukiwanie podatności, skanowanie paneli administracyjnych, próby odczytu plików konfiguracyjnych, masowe próby logowania, skanowanie portów, uruchamianie złośliwych zapytań, generowanie nadmiernego obciążenia oraz wysyłkę spamu.

Przy dużej skali blokowanie każdego adresu osobno staje się działaniem pozornym. Zagrożenie nie znika, lecz przenosi się na kolejny adres. Dlatego w uzasadnionych przypadkach blokada może objąć większy fragment infrastruktury danego operatora.

Takie podejście nie jest niczym nadzwyczajnym. Spamhaus wskazuje, że reputacja dotyczy nie tylko pojedynczego adresu IP, ale również zakresów IP oraz kontekstu ich użycia: kto, co, gdzie i kiedy było powiązane z danym adresem lub zakresem.

Legalny serwer też może zostać objęty blokadą

Skutkiem ubocznym szerszej blokady może być odrzucenie połączenia z prawidłowo działającego serwera pocztowego. Nie oznacza to automatycznie, że aktualny właściciel tego serwera prowadził ataki lub rozsyłał spam.

Oznacza natomiast, że jego serwer znajduje się w infrastrukturze, której część była wcześniej wykorzystywana do nadużyć. Właściciel takiego serwera często nie ma na to wpływu. Ma jednak pecha korzystać z dostawcy, którego infrastruktura ma problem z reputacją albo z nadzorem nad nadużyciami.

Dlatego konkretny, zweryfikowany adres może zostać przez nas dodany do białej listy, ale nie oznacza to automatycznego odblokowania całej infrastruktury operatora.

Hetzner – powtarzające się ataki i skanowanie

Jednym z operatorów, których infrastruktura pojawiała się w naszych logach jako źródło niepożądanego ruchu, jest Hetzner.

Z adresów działających w tej infrastrukturze odnotowywaliśmy między innymi automatyczne skanowanie stron, próby dostępu do paneli i plików konfiguracyjnych, wyszukiwanie podatności oraz masowe zapytania obciążające serwery.

Nie chodzi o pojedynczy przypadek. Problem polega na powtarzalności. Po zablokowaniu jednego adresu podobny ruch potrafił pojawiać się z kolejnych adresów tej samej infrastruktury.

Sam Hetzner w swojej dokumentacji wskazuje, że powodem blokowania usług mogą być między innymi spam, phishing, malware, ataki prowadzone z serwera oraz skanowanie sieci. Operator deklaruje też, że blokady mogą być stosowane po to, aby zapobiec dalszym nadużyciom.

Taka dokumentacja pokazuje, że problem nadużyć w usługach serwerowych jest dobrze znany. Sama procedura nie wystarcza jednak, jeżeli z perspektywy administratora atakowanego serwera podobny ruch nadal pojawia się z kolejnych adresów.

Skala działalności operatora nie jest usprawiedliwieniem. Przeciwnie — im większa infrastruktura, tym większa odpowiedzialność za jej nadzorowanie.

OVHcloud – spam, czarne listy i przerzucanie problemu na klienta

Drugim szczególnie istotnym przykładem jest OVHcloud. Z tej infrastruktury wielokrotnie obserwowaliśmy spam oraz inny niepożądany ruch.

Spam nie jest drobną niedogodnością. Każda wiadomość musi zostać przyjęta, przetworzona i oceniona przez filtry. Przy dużej skali oznacza to obciążenie serwera oraz zwiększenie ryzyka dostarczenia phishingu, złośliwego załącznika albo linku prowadzącego do fałszywej strony.

Jeszcze poważniejszym problemem jest ponowne przydzielanie klientom adresów IP, które wcześniej były wykorzystywane do spamu lub innych nadużyć i trafiły na listy blokujące.

Mechanizm jest prosty. Spamer uruchamia serwer, niszczy reputację adresu IP, a następnie rezygnuje z usługi. Adres wraca do puli operatora i zostaje przydzielony kolejnemu klientowi. Nowy użytkownik nie ma nic wspólnego z wcześniejszym spamem, ale jego poczta od pierwszego dnia może być odrzucana albo kierowana do spamu, bo systemy antyspamowe nadal widzą ten sam adres IP i jego historię.

OVHcloud publikuje instrukcję dotyczącą usuwania adresów IP z list blokujących, w której wprost wskazuje, że poradnik dotyczy nowo zakupionych adresów IP. W tej samej dokumentacji OVHcloud przyznaje, że adres IP znajdujący się na liście blokującej może powodować problemy z dostarczaniem poczty — wiadomości mogą nie docierać do odbiorcy albo trafiać do spamu.

To nie jest powód do pochwały. To potwierdzenie, że operator przewiduje sytuację, w której nowo przydzielony adres IP może znajdować się na liście blokującej, a klient musi podejmować działania w celu usunięcia skutków wcześniejszego wykorzystania tego adresu.

To kpina z klienta.

Klient kupuje usługę, która od początku może mieć ograniczoną przydatność do obsługi poczty. Zamiast otrzymać czysty, przygotowany adres IP, dostaje cudzą historię spamu i problemów reputacyjnych.

To operator zarządza pulą adresów IP. To operator zna historię ich przydzielania. To operator powinien sprawdzać reputację adresu przed ponownym przekazaniem go klientowi. Nie jest rolą nowego użytkownika ustalanie po zakupie, czy dostał adres zniszczony przez poprzedniego spamera.

Czarne listy nie powstają bez powodu

Listy blokujące są narzędziem ochrony przed spamem, malware, phishingiem i infrastrukturą wykorzystywaną do nadużyć.

Spamhaus wskazuje, że jego SBL obejmuje adresy IP uznane za złośliwe, obserwowane między innymi przy wysyłaniu spamu, hostowaniu szkodliwych treści, działaniu typu bulletproof hosting lub przejmowaniu przestrzeni adresowej. Lista może obejmować zarówno pojedyncze adresy IP, jak i całe zakresy.

Operator nie może więc udawać, że reputacja IP jest sprawą drugorzędną. Publiczny adres IP jest częścią sprzedawanej usługi. Jeżeli jego reputacja uniemożliwia normalną wysyłkę poczty, usługa ma wadę funkcjonalną już w chwili uruchomienia.

Problem nie dotyczy wyłącznie dwóch firm

Hetzner i OVHcloud są najbardziej wyrazistymi przykładami z naszych doświadczeń, ale nie są jedynymi operatorami pojawiającymi się podczas analiz niepożądanego ruchu.

W konkretnych przypadkach podejrzany ruch, skanowanie, spam albo adresy wymagające blokady były powiązane również z infrastrukturą takich operatorów jak DigitalOcean, Contabo, Scaleway / Online SAS, Namecheap, GlobalConnect, Media Land, vdsina / Trivon, Microsoft / Azure, Google Cloud, M247, Systemia.pl, TECHOFF SRV czy F.N.S. HOLDINGS LIMITED.

Nie stawiamy wszystkich tych firm na jednej płaszczyźnie. Skala, charakter zdarzeń i rola poszczególnych podmiotów były różne. Wspólny jest jednak problem: infrastruktura dużych operatorów bywa wykorzystywana do działań, przed którymi administratorzy innych serwerów muszą się bronić.

Nie blokujemy firm za samą nazwę. Decyzje podejmujemy na podstawie rzeczywistego ruchu zarejestrowanego w logach, jego natężenia, powtarzalności i wpływu na bezpieczeństwo usług.

Nie publikujemy też dokładnych zakresów objętych naszymi regułami bezpieczeństwa. Ułatwianie osobom prowadzącym ataki sprawdzania, które fragmenty infrastruktury są dopuszczone, byłoby pozbawione sensu.

Dlaczego nie zgłaszamy już każdego kolejnego incydentu?

Początkowo zgłaszanie nadużyć operatorowi wydaje się właściwą drogą. Administrator zbiera logi, identyfikuje adres, opisuje zdarzenie i przesyła dokumentację do działu abuse.

Ma to sens tylko wtedy, gdy po drugiej stronie następuje skuteczna reakcja.

Jeżeli jednak kolejne zgłoszenia nie prowadzą do rozwiązania problemu, a podobny ruch nadal pojawia się z następnych adresów tej samej infrastruktury, dalsze pisanie staje się stratą czasu.

Administrator atakowanego serwera zaczyna wtedy wykonywać bezpłatną pracę za firmę hostingową, która sama powinna monitorować własną sieć.

Dlatego nie zgłaszamy już każdego kolejnego przypadku operatorom, wobec których wcześniejsze interwencje nie przynosiły widocznego rezultatu. Blokujemy źródło ruchu, a gdy jest to konieczne — również większą część infrastruktury.

Bezpieczeństwo naszych klientów nie może zależeć od tego, czy zewnętrzny operator zechce przeczytać kolejne zgłoszenie i podjąć skuteczne działania.

Jak blokada wpływa na dostarczanie poczty?

E-mail nie jest przekazywany bezpośrednio z komputera nadawcy do skrzynki odbiorcy. Najpierw trafia do serwera pocztowego obsługującego nadawcę. Dopiero ten serwer próbuje połączyć się z systemem, na którym znajduje się konto adresata.

Jeżeli adres IP serwera wysyłkowego znajduje się w zablokowanej części infrastruktury, połączenie może zostać odrzucone jeszcze przed przyjęciem wiadomości.

W takim przypadku wiadomość nie trafia do skrzynki odbiorczej, nie pojawia się w spamie i nie może zostać odzyskana ze skrzynki, ponieważ nasz serwer w ogóle jej nie przyjął.

Serwer nadawcy powinien ponowić próbę dostarczenia albo wygenerować komunikat zwrotny. Nie zawsze dzieje się to od razu, dlatego nadawca może przez pewien czas być przekonany, że wiadomość została wysłana prawidłowo.

Możemy dodać konkretny adres do białej listy

Jeżeli otrzymamy wiarygodne zgłoszenie dotyczące prawidłowo działającego serwera pocztowego, możemy sprawdzić jego adres IP oraz przyczynę odrzucania połączeń.

Konkretny adres może zostać dodany do białej listy bez zdejmowania blokady z pozostałej części infrastruktury.

Początkowo taki wyjątek może mieć charakter tymczasowy. Pozwala to przywrócić dostarczanie wiadomości i jednocześnie obserwować, czy z dopuszczonego adresu nie pochodzi ruch zagrażający bezpieczeństwu albo stabilności usług.

Jeżeli nie odnotujemy problemów, adres może pozostać na białej liście. Jeżeli jednak pojawią się z niego ataki, skanowanie, nadmierne obciążenie lub spam, wyjątek zostanie usunięty.

Co podać w zgłoszeniu?

Sama informacja, że „wiadomość nie doszła”, zwykle nie wystarczy do odnalezienia konkretnego połączenia w logach.

W zgłoszeniu należy podać adres nadawcy, adres odbiorcy, datę i możliwie dokładną godzinę wysłania wiadomości, pełną treść komunikatu o niedostarczeniu, nazwę serwera wysyłkowego oraz adres IP tego serwera, jeżeli jest znany.

Na tej podstawie możemy ustalić, czy problem wynika z blokady bezpieczeństwa, błędnej konfiguracji serwera nadawcy, obecności adresu na listach blokujących czy innej przyczyny.

Osobiście odradzam korzystanie z usług takich operatorów

Osobiście odradzam korzystanie — szczególnie do obsługi poczty — z usług operatorów, których infrastruktura regularnie pojawia się w logach jako źródło spamu, ataków, skanowania lub innych nadużyć.

Dotyczy to zwłaszcza sytuacji, w których operator nie reaguje skutecznie na zgłoszenia albo przerzuca na klientów skutki złej reputacji przydzielanych adresów IP.

To operator odpowiada za monitorowanie należących do niego adresów IP — zarówno w kontekście spamu, jak i innych niedozwolonych działań: ataków, skanowania serwerów, prób włamań, phishingu, utrzymywania złośliwych treści czy nadużyć sieciowych.

Operator zarządza pulą adresów, przydziela je klientom i ma techniczne możliwości analizowania ruchu pochodzącego ze swojej infrastruktury. Powinien więc wykrywać nadużycia, blokować sprawców oraz kontrolować reputację adresów przed ich ponownym przydzieleniem.

Nie można oczekiwać, że administratorzy atakowanych serwerów będą bez końca monitorować cudzą infrastrukturę, przygotowywać zgłoszenia i wykonywać pracę za działy bezpieczeństwa wielkich firm hostingowych.

Nie można też przerzucać na nowego klienta obowiązku usuwania z czarnych list adresu IP zniszczonego wcześniej przez spamera. Klient płaci operatorowi za działającą i pełnowartościową usługę, a nie za możliwość samodzielnego naprawiania skutków zaniedbań dostawcy.

Bezpieczeństwo i jakość usług mają pierwszeństwo

Całkowite wyłączenie blokad ograniczyłoby część problemów z dostarczaniem wiadomości. Jednocześnie ponownie otworzyłoby nasze serwery na ruch, który wcześniej powodował ataki, obciążenie usług, skanowanie i próby włamań.

Nie możemy zaakceptować takiego ryzyka.

Odpowiadamy nie tylko za możliwość odebrania pojedynczego e-maila, ale również za bezpieczeństwo danych klientów, stabilność serwerów, dostępność stron internetowych, ochronę kont pocztowych, wydajność usług oraz ograniczanie spamu i phishingu.

Nie będziemy usuwać uzasadnionych zabezpieczeń tylko dlatego, że zewnętrzny operator nie potrafi skutecznie kontrolować swoich klientów, ignoruje zgłoszenia albo ponownie przydziela adresy IP obciążone historią spamu.

Każdy wiarygodnie zgłoszony przypadek legalnego serwera analizujemy indywidualnie. Możemy dodać dla niego kontrolowany wyjątek, ale nie oznacza to odblokowania całej infrastruktury, z której wielokrotnie pochodziły zagrożenia.

To nie nasi klienci powinni ponosić ryzyko wynikające ze złej polityki bezpieczeństwa firm hostingowych.

Naszym obowiązkiem jest dbanie o jakość usług i bezpieczeństwo osób korzystających z naszych serwerów. Dlatego czasami blokujemy nie tylko pojedyncze adresy, ale również większe fragmenty infrastruktury, która była wykorzystywana do ataków, spamu i innych nadużyć.