Jak opanować trwający atak subscription-bombing?
Kohortę zapisów utworzoną po domniemanym początku ataku poddaj kwarantannie, zanim trafi do kampanii — fałszywe zapisy mogą zepsuć dane o odbiorcach oraz obniżyć jakość listy i dostarczalność. Zabezpiecz endpoint zapisów: ustaw limity żądań wyznaczone na podstawie ruchu bazowego, dodaj mechanizmy weryfikacji użytkownika i przeglądarki (CAPTCHA, challenge) oraz wprowadź potwierdzanie zapisu (double opt-in). Nie usuwaj niesprawdzonych kontaktów; zachowaj prawdziwe zgody i dowody nadużyć zgodnie z polityką retencji organizacji.
Pierwsze 15 minut
- Poddaj kwarantannie kontakty utworzone po domniemanym początku ataku i posegmentuj je do przeglądu według czasu zapisu i źródła.
- Zastosuj na endpoincie zapisów regułę limitowania żądań z progami wyznaczonymi na podstawie poziomu bazowego prawdziwych zapisów.
- Sprawdź, czy platforma hostowana już nie ograniczyła tempa dla adresów wielokrotnie dodawanych do wielu grup odbiorców w krótkim czasie.
Teraz
- Poddaj kwarantannie kohortę z okresu ataku, posegmentuj ją do przeglądu i zachowaj zgody oraz dowody nadużyć.
Najbliższe 24 godziny
- Włącz lub napraw mechanizmy weryfikacji użytkownika (challenge) i zabezpieczenia honeypot oraz wymagaj potwierdzenia zapisu, zanim zgłoszenie stanie się subskrypcją.
Najbliższe 7 dni
- Dostrój limity żądań endpointu zapisów na podstawie poziomu bazowego prawdziwego ruchu i przetestuj klucze agregacji pod kątem wpływu na współdzielone sieci.
Kontrole techniczne
Inżynieria
- Zmierz normalny ruch zapisów i przetestuj odpowiednio zawężone klucze agregacji WAF, zanim włączysz na endpoincie zapisów regułę limitowania żądań.
Marketing / CRM
- Potwierdź, że obecny kod formularza włącza udokumentowane zabezpieczenia reCAPTCHA i honeypot, albo że własne integracje API mają równoważną ochronę.
Kryteria weryfikacji
- Zweryfikuj, czy zawężona reguła limitu żądań oraz mechanizmy weryfikacji użytkownika i przeglądarki odrzucają zgłoszenia przypominające boty, nie blokując poziomu bazowego prawdziwych zapisów.
- Potwierdź, że zgłoszenia nie stają się subskrypcjami, dopóki potwierdzenie się nie powiedzie, i że usuwane są tylko sprawdzone rekordy spamu.
Kryteria eskalacji
- Eskaluj sprawę do zespołu bezpieczeństwa oraz właściciela formularza lub WAF, gdy atak omija przetestowane klucze agregacji albo gdy wolumen potwierdzeń i skutki biznesowe wymagają szerszego wstrzymania wysyłki.
Zapobieganie
- Utrzymuj włączone mechanizmy weryfikacji użytkownika i zabezpieczenia honeypot w obecnym kodzie formularza — albo równoważne zabezpieczenia we własnych ścieżkach zapisu przez API.
- Stosuj potwierdzanie zapisu i limity żądań endpointu wyznaczone na podstawie ruchu bazowego, a nie jeden uniwersalny próg.
Wpływ na biznes
- Duża kohorta fałszywych zapisów może zniekształcić statystyki grupy odbiorców oraz obniżyć jakość listy i dostarczalność.
Uwagi dostawcy
- Mailchimp potrafi na 24 godziny ograniczyć tempo dodawania jednego adresu do wielu grup odbiorców w krótkim czasie, ale to zachowanie wersji hostowanej, a nie uniwersalny mechanizm ESP.
Otwarte pytania
- Nie znamy początku ataku, atakowanych adresów, endpointów zapisów, rozkładu żądań, wolumenu potwierdzeń ani odsetka prawdziwych zapisów.
- Hostowane formularze, formularze osadzone, własne API, throttling ESP, klucze agregacji WAF i procesy potwierdzania zapisu różnią się między sobą; mechanizmy Mailchimp i AWS to tylko przykłady o wąskim zakresie.
Źródła (6)
- About Fake Signups — What are spambots?Mailchimp
- About Fake Signups — How we prevent it > ThrottlingMailchimp
- About Fake Signups — How we prevent it > ReCAPTCHA and Honeypot fieldsMailchimp
- About Double Opt-in — How double opt-in works and Customize the double opt-in processMailchimp
- Using rate-based rule statements in AWS WAF — Rate-based rule overview and scope-down statementAWS WAF
- About Fake Signups — How to delete spam signupsMailchimp


