Podsumowanie
14 października 2020, między 02:41 a 02:52 UTC, każda instancja w AMS-01 była nieosiągalna. Atak objętościowy wymierzony w pojedynczy adres klienta osiągnął szczyt 340 Gbit/s i nasycił łącza serwisu. Rozwiązaliśmy to, prosząc dostawcę upstream o odrzucanie całego ruchu do adresu docelowego, co przywróciło działanie serwisu, pozostawiając tego jednego klienta offline przez kolejne pięćdziesiąt minut. Żadne dane nie zostały utracone i żadna instancja nie została naruszona. Serwis nie miał wówczas żadnych zdolności czyszczenia ruchu, a to była decyzja zakupowa, a nie przypadek.
Oś czasu
Wszystkie godziny UTC, 14 października 2020.
| Czas | Zdarzenie |
|---|---|
| 02:41:04 | Ruch do pojedynczego adresu klienta wzrasta z około 200 Mbit/s do 90 Gbit/s w mniej niż dwadzieścia sekund. |
| 02:41:30 | Oba łącza upstream serwisu nasycają się. Utrata pakietów staje się całkowita dla wszystkich prefiksów w serwisie, nie tylko docelowego. |
| 02:42 | Automatyczne alerty wyzwalają się na osiągalność z trzech zewnętrznych sond. |
| 02:44 | Dyżurny inżynier online. Atak jest widoczny na wykresach portów i nigdzie indziej, ponieważ nasza kolekcja przepływów była próbkowana w tempie, które nie mogło nadążyć. |
| 02:46 | Szczyt zmierzony na 340 Gbit/s. Skład to odbite UDP, głównie DNS i NTP, z dziesiątek tysięcy źródeł. |
| 02:47 | Podjęto decyzję o złożeniu wniosku o odrzucenie przez upstream całego ruchu do adresu docelowego. To było jedyne dostępne nam narzędzie. |
| 02:49 | Odrzucenie propaguje się u pierwszego dostawcy upstream. |
| 02:51 | Drugi dostawca upstream stosuje je. Wykorzystanie łącza spada poniżej przepustowości. |
| 02:52:10 | Serwis w pełni osiągalny. Całkowita przerwa widoczna dla klienta, jedenaście minut i sześć sekund. |
| 03:20 | Skontaktowano się z dotkniętym klientem i zaproponowano mu nowy adres. |
| 03:42 | Klient przeniesiony na nowy adres; ich usługa wraca. |
Przyczyna źródłowa
Bezpośrednią przyczyną był atak, którego nie mogliśmy wchłonąć. Tym, co go faktycznie spowodowało, było to, że sprzedawaliśmy hosting w mieście, gdzie ataki tej wielkości były na porządku dziennym, z dwustu gigabitami łącza i bez żadnego filtrowania, i traktowaliśmy umowę o odrzuceniu przez upstream jako plan.
To nie pech. To była decyzja, podjęta w 2019 roku na korzyść wydania pieniędzy na sprzęt, i była błędna.
Dwie wtórne usterki pogorszyły sytuację. Nasza kolekcja przepływów była próbkowana w tempie, które nie dawało nam użytecznych szczegółów podczas prawdziwego zdarzenia, więc pierwsze cztery minuty spędziliśmy na czytaniu liczników interfejsów. A odrzucenie było ręczne, wymagające człowieka, który jest na jawie, uwierzytelniony i pewny siebie, co to trzy wymagania za dużo o trzeciej nad ranem.
Co to kosztowało klienta
Mówiąc wprost: rozwiązaliśmy nasz problem, wyłączając ich usługę. Trasa odrzucenia to decyzja, że jeden klient będzie nieosiągalny, aby wszyscy inni nie byli. To była właściwa decyzja przy dostępnych nam narzędziach, to wciąż była ich przerwa, a nie nasza, i nie kupili od nas żadnego produktu, który obiecywałby inaczej.
Zostali. Nie obciążyliśmy ich za październik.
Co zmieniliśmy
- Zawsze włączone czyszczenie na brzegu sieci, zakupione w ciągu trzech tygodni, zaczynając od przepustowości 1.2 Tbit/s. Filtrowanie znajduje się trwale w ścieżce, więc nie ma opóźnienia w wykrywaniu i nie ma przycisku dla nikogo do naciśnięcia o 02:47. To jest teraz standardem w każdym serwisie, do 12 Tbit/s w największym.
- Podniesienie łącza w AMS-01, najpierw o 200 Gbit/s dodatkowej przepustowości, a później do 400 Gbit/s, które serwis ma dziś.
- Telemetria przepływów bez próbkowania na każdym brzegu serwisu, przechowywana do celów operacyjnych przez siedem dni. To metadane ruchu dla naszych własnych portów; to nie jest ruch instancji ani zawartość czegokolwiek.
- Trasa odrzucenia stała się automatyczna, z udokumentowanym progiem, ogłoszoną polityką i wiadomością do dotkniętego klienta w ciągu sześćdziesięciu sekund, a nie trzydziestu dziewięciu minut.
- Ataki są publikowane na stronie statusu, z rozmiarem i czasem trwania, niezależnie od tego, czy ktoś zauważył.
Czego nie zmieniliśmy i dlaczego
Nie zaczęliśmy pobierać opłat za filtrowanie. Podstawowe czyszczenie jest zawarte w każdym planie w każdym serwisie i zawsze było od dnia, w którym je kupiliśmy. Atak nie jest usługą, o którą prosiła ofiara. Filtrowanie warstwy 7 z niestandardowymi regułami istnieje jako dodatek, ponieważ wymaga człowieka po naszej stronie, a to co innego niż powódź objętościowa.
Nie usunęliśmy trasy odrzucenia. Dwanaście terabitów na sekundę to liczba, a nie nieskończoność, i udawanie, że nigdy więcej nie będziemy potrzebować tego prostego narzędzia, byłoby nieuczciwe. Zmieniło się to, że jest to teraz udokumentowany ostateczny środek, a nie jedyny krok.
Nie narzuciliśmy limitów ruchu na klienta. Ograniczenie prędkości każdego klienta do bezpiecznej części łącza zapobiegłoby temu, ale także zdławiłoby każdy legalny skok. Filtrowanie należy do brzegu sieci, na atak, a nie na klienta.
Nie przenieśliśmy klienta na inny produkt. Używali tego, za co zapłacili, w planie, który im odpowiadał, i to nie ich wina, że ktoś wycelował w nich botnet.