Jak zabezpieczyć formularz przed subscription bombing

Czym jest subscription bombing?

Subscription bombing to atak wykorzystujący formularz rejestracyjny do zasypania skrzynki odbiorczej innej osoby. Atakujący pobiera adres e-mail ofiary i w krótkim czasie przesyła go do setek lub tysięcy niezabezpieczonych formularzy. Każda z tych witryn wysyła na ten adres wiadomość powitalną lub potwierdzenie. Łącznie wiadomości te ukrywają korespondencję, którą ofiara faktycznie musi przeczytać.

Celem jest właściciel skrzynki odbiorczej. Podczas gdy zapełnia się ona potwierdzeniami subskrypcji, atakujący wydaje środki z karty tej osoby lub resetuje hasło do jednego z jej kont. Powiadomienie o oszustwie z banku nadal dociera. Trafia jednak pod dwa tysiące innych wiadomości, które wpłynęły w tej samej godzinie, więc nikt nie zauważa go na czas.

Twój serwer jest narzędziem, na którym opiera się ten atak. Nic na Twojej maszynie nie jest uszkodzone. Żadne Twoje konto nie zostało przejęte. Ktoś wpisał adres w publiczny formularz, a Twoje oprogramowanie wykonało swoje zadanie: wysłało wiadomość na ten adres. To właśnie sprawia, że atak jest trudny do wykrycia. W logach nie ma śladu włamania, ponieważ do żadnego włamania nie doszło.

Jak wygląda atak z Twojej perspektywy

Atak przybiera jedną z dwóch form.

Forma głośna to nagły skok ruchu. Kilkaset żądań POST trafia do jednego formularza w ciągu kilku minut, pochodząc z wielu różnych adresów IP i zawierając adresy e-mail w domenach, na które nigdy wcześniej nie wysyłano wiadomości. Ten typ ataku jest łatwy do wykrycia po przejrzeniu logów.

Forma cicha jest tą, którą łatwo przeoczyć. Atakujący dysponuje listą tysięcy podatnych formularzy, więc Twój formularz generuje tylko jedno lub dwa zgłoszenia na godzinę. Jye Cusch opisał atak dokładnie o takim charakterze na prowadzonej przez siebie stronie: brak skoku ruchu, jedynie stały napływ rejestracji w godzinach niedopasowanych do aktywności odbiorców. Pojedynczy formularz wygląda niewinnie, ponieważ wykonuje znikomą pracę. Szkoda jest sumą działań przeprowadzonych na wszystkich formularzach z listy atakującego.

Obie formy ataku mają jedną wspólną cechę: brak dalszych działań. Adresy nigdy nie potwierdzają subskrypcji. Nie otwierają wiadomości i nie klikają w linki. Na liście z potwierdzoną subskrypcją (confirmed opt-in) pozostają w statusie unconfirmed na zawsze, a ten zbiór jest najczytelniejszym dowodem ataku, jaki możesz uzyskać.

Zacznij od zliczenia zgłoszeń na minutę w logu dostępu.

sudo awk '/POST \/subscription\/form/ {print substr($4, 2, 17)}' \
  /var/log/nginx/access.log | uniq -c | sort -rn | head

$4 w domyślnym formacie logu combined to znacznik czasu w nawiasach, więc to polecenie wyświetla liczbę zgłoszeń dla każdej minuty, zaczynając od najwyższej wartości. Formularz, który zazwyczaj rejestruje cztery zgłoszenia dziennie, a nagle wykazuje sześćdziesiąt w ciągu jednej minuty, jest wyraźnym sygnałem problemu.

Potwierdzona subskrypcja: najskuteczniejsza metoda ochrony

Potwierdzona subskrypcja, nazywana zazwyczaj double opt-in, oznacza, że adres nie staje się subskrybentem, dopóki osoba nie kliknie linku w wiadomości wysłanej na ten adres. Po włączeniu tej funkcji każdy przesłany adres generuje dokładnie jedną wiadomość. Adres nigdy nie trafia na listę, więc nie otrzymuje kampanii ani sekwencji powitalnej.

W listmonk, self-hosted newsletter server jest to ustawienie indywidualne dla każdej listy: lista może działać w trybie single opt-in lub double opt-in. Dokumentacja jasno określa różnicę. Na liście double opt-in subskrybenci „wyraźnie akceptują subskrypcję, klikając w otrzymany e-mail potwierdzający. Do tego momentu nie otrzymują wiadomości z kampanii”. Subskrybent znajduje się w stanie unconfirmed, przechodzi do confirmed po kliknięciu, a tylko subskrybenci confirmed na liście opt-in otrzymują wiadomości z kampanii.

Należy uczciwie ocenić korzyści tego rozwiązania. Potwierdzona subskrypcja nie redukuje liczby niechcianych zgłoszeń do zera. Ogranicza ją jednak do jednej wiadomości na adres. Ofiara nadal otrzymuje tę wiadomość, a jedna wiadomość z tysiąca różnych witryn stanowi istotę ataku. Potwierdzona subskrypcja eliminuje wszystko, co następuje później: lista pozostaje czysta, a użytkownik nigdy nie otrzyma drugiej wiadomości, jeśli nie wyraził zgody na pierwszą.

Dwa dodatkowe ustawienia mają kluczowe znaczenie i łatwo o nich zapomnieć. Po pierwsze, należy ograniczyć liczbę ponownych wysyłek potwierdzenia. Jeśli ten sam adres może zostać przesłany ponownie i za każdym razem wywołać wysyłkę e-maila, atakujący nie potrzebuje tysiąca formularzy, ponieważ jeden formularz wyśle tysiąc wiadomości. Adres znajdujący się już w stanie unconfirmed na danej liście nie powinien otrzymywać niczego więcej przez co najmniej dobę. Po drugie, należy usuwać niepotwierdzone rekordy zgodnie z harmonogramem. Adres, który nie został potwierdzony w ciągu 30 dni, nie jest oczekującym subskrybentem. Przechowywanie go stwarza jedynie ryzyko przypadkowej wysyłki w przyszłości.

Ograniczanie częstotliwości żądań (rate limiting) formularza rejestracji na reverse proxy

Wprowadź limit przed aplikacją, a nie wewnątrz niej. Żądanie zablokowane na poziomie proxy nie otwiera połączenia z bazą danych ani nie inicjuje sesji SMTP (simple mail transfer protocol). Limit wewnątrz aplikacji uruchamia się dopiero po tym, jak żądanie zajmie proces roboczy i wykona zapytanie, a w wielu stosach technologicznych wiadomość trafia do kolejki przed sprawdzeniem nadużyć. Limit na poziomie proxy przetrwa również aktualizację aplikacji, ponieważ nie znajduje się w kodzie, który jest zastępowany.

Poniższy przykład dotyczy nginx. Koncepcja jest uniwersalna dla każdego reverse proxy działającego przed aplikacją, choć nazwy dyrektyw mogą się różnić.

Umieść to w bloku http, w pliku takim jak /etc/nginx/conf.d/signup-limit.conf:

map $request_method $signup_key {
    POST    $binary_remote_addr;
    default "";
}

limit_req_zone $signup_key zone=signup:10m rate=2r/m;
limit_req_status 429;
limit_req_log_level warn;

Dyrektywa map wykonuje właściwą pracę. nginx nie zlicza żądań, których klucz jest pustym ciągiem znaków, więc do strefy trafiają tylko żądania POST. Użytkownik wczytujący stronę rejestracji wielokrotnie nie zużywa limitu. Bez tej mapy osoba, która odświeżyła stronę dwukrotnie, wyczerpałaby swój budżet przed wysłaniem jakichkolwiek danych.

$binary_remote_addr to adres klienta w formie spakowanej, dlatego strefa o rozmiarze 10 megabajtów mieści około 160 000 wpisów. rate=2r/m pozwala na jedno przesłanie formularza co trzydzieści sekund. limit_req_status 429 zwraca kod HTTP 429 Too Many Requests zamiast domyślnego dla nginx 503; jest to właściwy kod, którego oczekują biblioteki klienckie.

Następnie w bloku server dla Twojej witryny:

location = /subscription/form {
    limit_req zone=signup burst=3 nodelay;
    proxy_pass http://127.0.0.1:9000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

burst=3 nodelay pozwala na dwukrotne kliknięcie przycisku przez użytkownika, a czwarte żądanie odrzuca natychmiast, zamiast ustawiać je w kolejce.

sudo nginx -t && sudo systemctl reload nginx

nginx -t powinno zwrócić configuration file /etc/nginx/nginx.conf test is successful. Teraz prześlij formularz pięć razy szybko i obserwuj dziennik błędów:

sudo tail -f /var/log/nginx/error.log

Zablokowane żądanie zapisuje jedną linię; szukaj następującego ciągu znaków:

2026/08/13 09:14:22 [warn] 812#812: *4412 limiting requests, excess: 3.400 by zone "signup", client: 203.0.113.10, server: news.example.com, request: "POST /subscription/form HTTP/1.1", host: "news.example.com"

Brak linii oznacza, że limit nie jest stosowany. Najczęstszą przyczyną jest umieszczenie limit_req w bloku location, do którego żądanie nigdy nie dociera. Sprawdź to za pomocą curl -si -X POST https://news.example.com/subscription/form kilka razy z rzędu i upewnij się, że otrzymujesz 429.

Przed poleganiem na limicie per-IP warto znać dwie pułapki.

Za siecią CDN lub innym proxy, $binary_remote_addr jest adresem tego proxy. Wszyscy odwiedzający trafiają do jednego worka, więc pierwsze kilka przesłań formularza w każdej minucie blokuje wszystkich pozostałych. Rozwiąż to za pomocą modułu real IP: set_real_ip_from dla każdego z opublikowanych zakresów Twojego CDN (Cloudflare publikuje swoje na cloudflare.com/ips) oraz real_ip_header CF-Connecting-IP. Potwierdź poprawkę, odczytując $remote_addr w dzienniku dostępu i sprawdzając, czy jest to adres odwiedzającego, a nie Twojego CDN.

IPv6 osłabia limit per-adres. $binary_remote_addr przechowuje pełne /128, a przydział IPv6 dla użytkownika domowego to zazwyczaj /64 lub więcej. To znacznie więcej adresów, niż atakujący jest w stanie wykorzystać, a każdy z nich ma własny czysty budżet. Dodaj drugą strefę jako górny limit dla samego punktu końcowego, kluczowaną stałą wartością, aby formularz miał całkowity limit niezależnie od liczby użytych adresów źródłowych:

map $request_method $signup_total_key {
    POST    "signup";
    default "";
}

limit_req_zone $signup_total_key zone=signup_total:1m rate=30r/m;

Dodaj limit_req zone=signup_total burst=10 nodelay; do tego samego location. Ustaw limit powyżej wartości dla najbardziej obciążonej godziny pracy, z pewnym zapasem. Jest to surowa kontrola: podczas ataku odrzuca ona również poprawne rejestracje. Jest to właściwy kompromis, ponieważ alternatywą jest wysyłanie poczty przez Twój serwer.

Dlaczego limit na adres nie może być obsługiwany przez proxy

Adres e-mail znajduje się w treści żądania POST, a Nginx nie analizuje treści żądań. Każda zmienna, na której może bazować limit_req_zone, pochodzi z linii żądania, nagłówków lub połączenia. Dlatego reguła typu „ten adres może otrzymać maksymalnie jedno potwierdzenie dziennie” musi znajdować się w pierwszym komponencie, który odczytuje treść żądania, czyli w Twojej aplikacji.

Nie należy obchodzić tego ograniczenia poprzez przenoszenie adresu do ciągu zapytania (query string), aby zmienna $arg_email stała się dostępna. Powoduje to zapisywanie adresu każdego subskrybenta w logach dostępu w postaci otwartego tekstu oraz w każdym systemie przesyłającym logi znajdującym się dalej. W ten sposób zamieniasz limit szybkości na problem z prywatnością.

Istnieje jeden rzeczywisty wyjątek. Moduł Nginx JavaScript, njs, potrafi odczytać treść żądania i ustawić na jej podstawie zmienną, co pozwala na utworzenie klucza opartego na adresie na poziomie proxy. Jest to realna opcja, która jednak wprowadza nowy kod w ścieżce przetwarzania żądania. W przypadku większości witryn limit na adres powinien znajdować się obok bazy danych, która już posiada informację, czy dla danego adresu oczekuje na potwierdzenie, podczas gdy proxy obsługuje limity na adres IP oraz na punkt końcowy, w czym sprawdza się najlepiej.

Unikanie powtarzania danych wejściowych

Nie należy powtarzać w wiadomościach przesłanego tekstu. Istnieją dwa niezależne powody, dla których jest to niebezpieczne, a oba są wykorzystywane w praktyce.

Jeśli wiadomość potwierdzająca wita czytelnika imieniem pobranym z formularza, atakujący może wpisać własną treść w pole imienia. Serwer dostarczy wówczas ten tekst ofierze, wysyłając go z Twojej domeny i podpisując kluczem DKIM (DomainKeys Identified Mail). Witryna staje się narzędziem do rozsyłania nadużyć, a dostawcy poczty przypisują te działania Twojej domenie.

Drugi powód jest poważniejszy. Jeśli jakiekolwiek przesłane pole jest ręcznie dołączane do nagłówka wiadomości, znak nowej linii w tym polu pozwala atakującemu na dodanie dowolnych nagłówków, w tym Bcc. Nowoczesne biblioteki pocztowe odrzucają znaki nowej linii w wartościach nagłówków. Kod przekazujący tekst do sendmail za pomocą skryptu powłoki często tego nie robi.

Bezpieczna wiadomość potwierdzająca zawiera nazwę witryny, jeden odnośnik oraz jedno zdanie wyjaśnienia. Adres odbiorcy powinien znajdować się wyłącznie w miejscu wymaganym przez agenta transferu poczty, czyli w nagłówku To. Należy to przetestować: wyślij formularz, wpisując w polu imienia znak nowej linii oraz widoczny odnośnik, a następnie odczytaj surową treść otrzymanej wiadomości za pomocą less i upewnij się, że żaden z tych elementów nie został przetworzony.

Przy okazji należy zadbać o to, aby strona z potwierdzeniem sukcesu wyświetlała ten sam komunikat dla każdego adresu. Strona informująca o tym, że "adres jest już zasubskrybowany" dla jednego użytkownika, a "sprawdź skrzynkę odbiorczą" dla innego, zmienia formularz w narzędzie do weryfikacji członkostwa dla każdego, kto posiada listę adresów do przetestowania.

Który mechanizm weryfikacji botów wybrać?

Wybierając rozwiązanie, należy kierować się dostępnością w takim samym stopniu, co skutecznością. Użytkownik niewidomy nie rozwiąże testu typu captcha opartego na wyborze obrazów, a alternatywa dźwiękowa jest trudna dla osób o przeciętnym słuchu. Mechanizm, który uniemożliwia rejestrację uprawnionemu użytkownikowi, stanowi zabezpieczenie, które generuje realne straty. Poniżej przedstawiono cztery opcje w kolejności zalecanej do wdrożenia.

Proof of work w przeglądarce. Przeglądarka oblicza skrót, który serwer może tanio zweryfikować, a użytkownik nie musi wykonywać żadnych zadań. listmonk oferuje tę funkcjonalność w sekcji Settings, a następnie Security, wykorzystując ALTCHA, co nie wymaga usług stron trzecich. Według stanu na sierpień 2026 jest to rozwiązanie rekomendowane przez listmonk zamiast wycofywanej opcji hCaptcha. Koszt obliczeniowy ponosi ten, kto wysyła najwięcej żądań, czyli atakujący.

Zarządzana weryfikacja nieinteraktywna. Cloudflare Turnstile w większości przypadków nie wyświetla użytkownikowi żadnych komunikatów i aktywuje wyzwanie tylko wtedy, gdy sygnały wskazują na podejrzany ruch. Jest to rozwiązanie skuteczne, jednak wprowadza zależność od zewnętrznego dostawcy w procesie rejestracji.

Pole typu honeypot. Pole tekstowe, którego użytkownik nie widzi, a które jest wypełniane przez naiwne boty. Należy nadać mu nazwę, która nie jest używana w formularzu, oraz ustawić autocomplete="off", tabindex="-1" i aria-hidden="true", aby menedżer haseł go nie wypełnił, a czytnik ekranu go nie odczytał. Pole o nazwie email2 lub address jest automatycznie uzupełniane przez przeglądarkę, co prowadzi do odrzucania zgłoszeń od rzeczywistych osób.

<div style="position:absolute; left:-9999px;" aria-hidden="true">
  <label for="hp_ref">Leave this field empty</label>
  <input type="text" id="hp_ref" name="hp_ref" autocomplete="off" tabindex="-1">
</div>

Weryfikacja czasu przesłania. Podczas renderowania strony należy umieścić w ukrytym polu podpisany znacznik czasu i odrzucać zgłoszenia, które dotrą w czasie krótszym niż dwie sekundy. Człowiek nie jest w stanie przeczytać formularza i wpisać adresu w tak krótkim czasie. Znacznik czasu musi być podpisany, w przeciwnym razie bot wyśle po prostu stary znacznik.

Niezależnie od wybranej metody, należy zweryfikować jedną kwestię: token musi być jednorazowy. Jeśli skrypt może rozwiązać test raz i użyć tego samego tokena do wysłania tysiąca zgłoszeń, weryfikacja potwierdza jedynie, że przeglądarka została uruchomiona raz, a nie chroni przed atakiem.

Jak wykryć problem, zanim nadejdzie zgłoszenie o nadużyciu?

Własne wykresy powinny informować o problemach, a nie dział abuse dostawcy hostingu. Należy monitorować dwa parametry.

Należy zliczyć zgłoszenia z poszczególnych adresów źródłowych w logach:

sudo awk '/POST \/subscription\/form/ {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

Następnie należy skonfigurować fail2ban, aby odczytywał te same linie limiting requests, które zapisuje nginx, i blokował powtarzających się sprawców. fail2ban zawiera gotowy filtr do tego celu. Należy utworzyć /etc/fail2ban/jail.d/nginx-limit-req.local:

[nginx-limit-req]
enabled  = true
filter   = nginx-limit-req
port     = http,https
logpath  = /var/log/nginx/error.log
findtime = 600
maxretry = 10
bantime  = 3600

sudo systemctl reload fail2ban
sudo fail2ban-client status nginx-limit-req

Dane wyjściowe statusu wyświetlają filtr jaila oraz aktualną liczbę nieudanych prób i zablokowanych adresów. Wartość Currently banned: 0 w spokojny dzień jest prawidłowa. Jeśli jail w ogóle się nie pojawia, oznacza to, że fail2ban nie wczytał pliku, a sudo fail2ban-client -d | grep nginx-limit-req wyświetla konfigurację, która została faktycznie przeanalizowana. Dostarczony filtr dopasowuje każdą strefę limit_req. Należy ograniczyć go do strefy rejestracji, ustawiając ngx_limit_req_zones = signup w sekcji [Definition] pliku /etc/fail2ban/filter.d/nginx-limit-req.local. Układ plików jaila oraz polecenia blokujące zostały szczegółowo opisane w przewodniku po fail2ban dla Ubuntu 24.04.

Drugim sygnałem jest wskaźnik, który nie wymaga dodatkowego oprogramowania: liczba zgłoszeń podzielona przez liczbę potwierdzeń. W przypadku zdrowej listy większość osób przesyłających adres klika w link, zazwyczaj ponad połowa z nich. Gdy ten wskaźnik spada przy jednoczesnym wzroście liczby zgłoszeń, system jest wykorzystywany do nadużyć. Należy porównać liczbę subskrybentów unconfirmed utworzonych w ostatniej godzinie z liczbą subskrybentów confirmed, zgodnie z harmonogramem generowania raportów.

Koszty: reputacja nadawcy i czarne listy

To właśnie ten etap zmienia uciążliwy problem w realne straty.

Listy adresowe wykorzystywane do ataków typu bombing są pozyskiwane automatycznie, a takie zbiory zawierają tzw. spamtrapy: adresy, które nigdy nie wyraziły zgody na otrzymywanie wiadomości i zostały opublikowane wyłącznie w celu wykrywania nadawców wysyłających pocztę bez zezwolenia. Twoja wiadomość potwierdzająca trafia na taki adres. Dla niektórych operatorów czarnych list to wystarczający powód do wpisania na listę.

Odbiorcy, którzy nie prosili o wiadomość, nie klikają w przycisk rezygnacji z subskrypcji. Klikają „zgłoś spam”. Zasady Google dla masowych nadawców, obowiązujące od lutego 2024 roku, wymagają od podmiotów wysyłających 5000 lub więcej wiadomości dziennie do Gmaila utrzymywania wskaźnika zgłoszeń spamu w Postmaster Tools poniżej 0,3%. Mniejsi nadawcy nie są rozliczani z tej konkretnej wartości, jednak ten sam sygnał o zgłoszeniach wpływa na decyzje filtrów, które kierują Twoją pocztę bezpośrednio do folderu ze spamem. Fałszywe adresy w bazie generują również błędy typu hard bounce, a rosnący wskaźnik takich odrzuceń jest dla każdego dużego dostawcy sygnałem o niskiej reputacji.

Jeśli utrzymujesz własny serwer pocztowy na VPS z mailcow, wpis na czarną listę dotyczy Twojego adresu IP oraz domeny. Usunięcie z listy u operatora takiego jak Spamhaus wiąże się z wypełnieniem formularza i oczekiwaniem, a w tym czasie Twoje faktury oraz powiadomienia o zresetowaniu hasła również nie dotrą do adresatów. Jeśli korzystasz z usług współdzielonego dostawcy, spodziewaj się, że najpierw zawiesi on Twoje konto, a dopiero potem zapozna się z wyjaśnieniami, ponieważ Twój ruch stanowi zagrożenie dla każdego innego nadawcy korzystającego z tego samego adresu IP.

W zestawieniu z tymi konsekwencjami nakład pracy jest niewielki. Włącz potwierdzoną subskrypcję (confirmed opt-in) już dziś, ponieważ jest to tylko jedno ustawienie na listę. Następnie dodaj limit szybkości dla proxy, ponieważ wymaga to edycji jednego pliku i przeładowania konfiguracji. Weryfikację botów oraz system powiadomień możesz wdrożyć w tym tygodniu.

FAQ

Czy mechanizm double opt-in chroni przed atakiem typu subscription bombing?

Mechanizm ten zapobiega zanieczyszczeniu listy mailingowej i ogranicza udział w ataku do jednej wiadomości na przesłany adres, co stanowi najskuteczniejsze dostępne zabezpieczenie. Nie powstrzymuje on jednak zapełniania skrzynki odbiorczej ofiary, ponieważ atak polega na wysłaniu pojedynczej wiadomości z tysięcy różnych serwisów. Należy połączyć go z limitowaniem liczby żądań na adres IP (rate limit) na poziomie proxy oraz ograniczeniem liczby ponownych wysyłek potwierdzeń, aby ten sam adres przesłany dwukrotnie nie generował drugiej wiadomości.

Jak odróżnić atak od dużej liczby rzeczywistych rejestracji?

Należy obserwować zdarzenia następujące po przesłaniu formularza. Rzeczywiści użytkownicy potwierdzają rejestrację, zazwyczaj w ciągu kilku godzin. Atak typu bombing pozostawia bazę adresów, które nigdy nie zostają potwierdzone, nie są otwierane ani nie generują kliknięć. Zgłoszenia w ramach ataku wykazują również nietypowe skupiska: wiele adresów źródłowych, których wcześniej nie odnotowano, domeny odbiorców, do których zazwyczaj nie wysyła się wiadomości, oraz czas nadejścia zgłoszeń rozłożony równomiernie na całą dobę, zamiast podążać za aktywnością odbiorców w ciągu dnia.

Czy należy usuwać przesłane adresy?

Tak. Należy usuwać niepotwierdzone rekordy starsze niż około 30 dni, najlepiej w sposób zautomatyzowany, a nie ręczny. Nie należy wysyłać na te adresy żadnych dodatkowych wiadomości, w tym przeprosin czy zapytań typu "czy to ty?", ponieważ stanowi to drugą niechcianą wiadomość dla osoby, która już została nimi zasypana. Jeśli którykolwiek z tych adresów był pułapką antyspamową (spamtrap), wysłanie kolejnej wiadomości jest potwierdzeniem, na które czeka operator czarnej listy.

Czy limitowanie liczby żądań odrzuci rzeczywistych subskrybentów?

Limit jednego zgłoszenia na 30 sekund z możliwością wysłania serii trzech żądań (burst) jest niezauważalny dla osoby wypełniającej formularz. Staje się on widoczny, gdy wiele osób korzysta z jednego adresu IP, na przykład w biurze za wspólną bramą NAT (network address translation), lub gdy proxy widzi adres IP sieci CDN zamiast adresu odwiedzającego. Przed zaostrzeniem restrykcji należy przeanalizować $remote_addr w logach dostępu i utrzymać limit dla punktu końcowego powyżej szczytowego obciążenia w najbardziej aktywnych godzinach.

Mój adres IP wysyłający trafił na czarną listę po ataku. Co zrobić w pierwszej kolejności?

Przed podjęciem jakichkolwiek działań należy wstrzymać wysyłkę z tego adresu. Należy zatrzymać kolejkę kampanii, naprawić formularz i usunąć niepotwierdzone adresy, ponieważ usunięcie z listy, po którym następuje ten sam ruch, skutkuje szybszym ponownym wpisaniem na listę niż za pierwszym razem. Następnie należy sprawdzić, na której liście znajduje się adres IP – większość operatorów udostępnia stronę weryfikacyjną – i postępować zgodnie z ich procedurą usuwania. Należy przygotować się na czas oczekiwania liczony w dniach i wykorzystać go na weryfikację poprawności rekordu SPF (sender policy framework) oraz podpisywania DKIM.