DDoS przez VPN: który adres jest naprawdę wystawiony?
Tunel ukrywa adres źródłowy przed jedną usługą, ale nie przed łączem dostępowym, wyjściem VPN ani przekierowanym portem. Nazwij cel, zanim zaplanujesz łagodzenie.
Zacznij od żądania, które ma wyrządzić szkodę. Może dotrzeć na Twoje łącze domowe, na wyjście VPN albo do opublikowanej aplikacji za tunelem. Każde miejsce docelowe ma inny limit pojemności i innego właściciela, który może filtrować ruch. Nazwanie celu to pierwszy użyteczny krok, a subskrypcja VPN odpowiada tylko na jedno z trzech.
Przejdź ekspozycję przed atakiem
Prześledź jedno żądanie przychodzące z internetu do zasobu, który ma wyczerpać. Jeśli celem jest adres domowy, limitem jest łącze dostępowe i brzeg dostawcy. Jeśli wyjście VPN, limit należy do operatora VPN. Jeśli przekierowany port, wąskim gardłem staje się własna obsługa aplikacji.
| Target | What saturates | Who can mitigate |
|---|---|---|
| Home connection address | The access link and provider edge | The access provider |
| VPN exit address | Provider capacity and filtering | The VPN operator |
| Published service | The application and its host | The service owner and hosting provider |
Trzy cele można atakować razem, ale łagodzi się je w różnych miejscach. Zapisz, który z nich Twój plan twierdzi, że chroni.
Twoje własne łącze dostępowe zachowuje swój adres
Kierowanie ruchu wychodzącego przez tunel zmienia to, co widzą usługi zdalne. Nie usuwa adresu, który ma Twoje łącze dostępowe, i nie przesuwa pojemności tego łącza.
Ruch skierowany na łącze nadal konkuruje z pakietami samego tunelu. Lokalna zapora może odrzucać pakiety po ich dotarciu, ale ograniczony upstream już je niesie. Ta różnica ma znaczenie, gdy łącze jest wysycone, ponieważ filtr nie może zwrócić pojemności, której nigdy nie kontrolował. Skontaktuj się z dostawcą dostępu przez jego procedurę incydentową, jeśli dowody wskazują na to łącze.
Wyjście VPN jest teraz współdzieloną zależnością
Każdy, kto obserwuje wyjście VPN, może wysłać tam niechciany ruch. To, czy dostawca go pochłonie, zależy od rzeczywistej pojemności, architektury i ewentualnej usługi łagodzenia, którą prowadzi, a nie od szyfrowania tunelu.
Współdzielone wyjście może też ucierpieć z powodu incydentu wymierzonego w innego klienta lub w otaczającą sieć dostawcy. Wytyczne CISA dotyczące odmowy usługi zauważają, że gdy atakowany jest dostawca internetu lub chmury, ciemnieć mogą także sieci, których nikt nie obrał za cel. W przypadku serwera zarządzanego samodzielnie dostawca hostingu nadal posiada pojemność upstreamu, która dociera, zanim Twoja maszyna zobaczy pakiet. Filtrowanie wewnątrz maszyny nie przywróci przepustowości już zużytej.
Opublikowany port wymaga planu usługi
Przekierowany port celowo wystawia aplikację, więc żądania wyglądające na legalne trafiają na jej ścieżkę obsługi, niezależnie od tego, jak kontrolowany jest dostęp na tunelu. Dostęp na tunelu, filtrowanie na hoście i autoryzacja aplikacji obejmują różne etapy i żadne z nich nie gwarantuje ochrony przed wyczerpaniem zasobów.
Korzystaj z obsługiwanych limitów usługi, monitorowania i łagodzenia po stronie upstreamu oraz wskaż, kto może poprosić o pomoc w trakcie incydentu. Konsumencka subskrypcja VPN nie jest dowodem, że te mechanizmy istnieją dla Twojej aplikacji.
Zachowaj proporcje w diagnozie. Wolne strony i zerwane połączenia wynikają też z konserwacji, rywalizacji o zasoby lub zwykłych awarii, więc zachowaj znaczniki czasu i ograniczone obserwacje dla odpowiedzialnego operatora. Nigdy nie potwierdzaj twierdzenia nieautoryzowaną powodzią i zamiast tego użyj zatwierdzonego planu z właścicielem infrastruktury.