Jak działają połączenia TCP/IP
Transmission Control Protocol/Internet Protocol (TCP/IP) jest kluczową technologią dla nowoczesnych sieci komputerowych. W ten sposób (przez większość czasu) komputer często żąda i odbiera informacje w sieci oraz w Internecie. W komplecie z kontrolą błędów, retransmisją brakujących/uszkodzonych danych i kilkoma innymi ważnymi funkcjami, które dosłownie sprawiają, że Internet, jaki znamy, jest niezawodny i funkcjonalny. Jednak, aby zrozumieć, jak jest nadużywany, musimy najpierw zrozumieć, jak działa.
Dla zwięzłości, nie będziemy zagłębiać się w cały proces połączenia TCP/IP. Skupimy się jedynie na początkowym procesie TCP three-way handshake, ponieważ jest to wszystko, co jest istotne dla tematu tego artykułu.
Hostowie w sieci, którzy chcą wymieniać dane przy użyciu TCP, muszą najpierw wynegocjować połączenie. W tym miejscu do gry wchodzi trójstronny uścisk dłoni TCP. Proces handshake pozwala obu hostom potwierdzić pomyślne wysłanie i odebranie komunikacji sieciowej, jak również ustawić ich odpowiednią sesję w oczekiwaniu na wymianę danych aplikacji.
Fig. 1) TCP three-way handshake
Na rysunku 1 widzimy Klienta nawiązującego połączenie TCP z Serwerem. Pierwszym krokiem jest wysłanie przez Klienta pakietu synchronizującego SYN. Pakiet ten ma dwie podstawowe role, pierwszą jest sprawdzenie możliwości dotarcia do zdalnego zasobu. Jeżeli pakiet ten zostanie pomyślnie przesłany, informuje on również Serwer, że zdalny Klient chce rozpocząć proces negocjacji połączenia w celu wymiany danych. Serwer odpowiada wydaniem pakietu Synchronization and Acknowledgment, lub SYN-ACK, skierowanego z powrotem do Klienta inicjującego połączenie. Końcową częścią trójstronnego uścisku dłoni jest odpowiedź klienta na pakiet SYN-ACK w postaci pakietu ACK (ang. Acknowledgement). Po zakończeniu tego procesu, połączenie jest gotowe do użycia przez aplikację do dwukierunkowej transmisji danych.
Najczęstszą metodą transportu komunikacji TCP jest protokół internetowy lub IP. Oznacza to, że pakiety TCP są przekazywane pomiędzy klientem a serwerem przy użyciu datagramów IP, adresowanych przy użyciu adresów IP dla każdego z urządzeń.
Jak działa ten atak
Atakujący wykorzystują ten proces handshake poprzez spoofing źródłowych adresów IP pakietów SYN. To spoofing powoduje, że serwer wysyła pakiet SYN-ACK do IP ofiary, który według serwera żąda inicjalizacji sesji, działając jak reflektor.
Fig. 2) Odbicie SYN-ACK
Na rysunku 2 można zobaczyć bardzo prostą wizualizację tego ataku. Nie pokazuje ona jednak, jak wygląda prawdziwy scenariusz ataku. W rzeczywistości TCP został zaprojektowany do pracy w niepewnych sieciach, co oznacza, że pojedynczy spoofed SYN może spowodować, że serwer wyśle wiele SYN-ACK w szybkim tempie, jeśli nie otrzyma końcowego ACK z handshake. Liczba wysyłanych pakietów SYN-ACK i szybkość ich wysyłania jest konfigurowalną metryką, więc trudno jest dokładnie oszacować, ile pakietów SYN-ACK może otrzymać ofiara w stosunku do ilości spoofed SYN wysłanych przez atakujących.
Niska przepustowość vs wysoki PPS
Ataki SYN-ACK nie są typowymi atakami refleksyjnymi. Jedną z głównych atrakcji ataków refleksyjnych opartych na UDP jest ich współczynnik wzmocnienia, czyli rozmiar pakietu, który dociera do ofiary w porównaniu z rozmiarem pakietu, który musi wysłać atakujący. W wielu przypadkach współczynnik amplifikacji jest wielokrotnie większy od oryginalnego żądania. Na przykład, w przypadku odbicia CLDAP, wynikowy pakiet jest około 50-70 razy większy niż pakiet, który atakujący musi wysłać, aby wywołać odbicie. Ataki amplifikacyjne są często uważane za wolumetryczne, a ich celem jest nasycenie łączy sieciowych wykorzystywanych przez atakowane serwery i aplikacje.
W przypadku odbić SYN-ACK, rozmiar pakietu dostarczanego do ofiary jest prawie taki sam, jak rozmiar pakietu wysłanego przez atakującego. Mówimy „prawie taki sam rozmiar”, ponieważ jest możliwe, a nawet bardzo prawdopodobne, że podczas gdy atakujący wysyła pakiet SYN o minimalnej długości, niektóre routery w sieci pomiędzy atakującym a ofiarą mogą również zmodyfikować pakiet TCP, aby dodać dodatkowe informacje o łączu, takie jak opcja Maximum Segment Size (MSS) TCP, zwiększając bezwzględny rozmiar ruchu obserwowanego przez ofiarę. Opcja ta odpowiada za dodatkowe 4 bajty w pakiecie w porównaniu do tego, co wysłał atakujący.
20:56:32.296905 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xfa7c (correct), seq 1000, win 8192, urg 0, length 0
20:56:32.315637 IP (tos 0x0, ttl 124, id 4894, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6e18 (correct), seq 3609252029, ack 1001, win 60720,
options , length 0
Fig. 3) 4-bajtowe wzmocnienie SYN-ACK
Nie oznacza to jednak, że atak ten nie jest zagrożeniem. Podczas kilku skoordynowanych ataków na klientów Akamai, zaobserwowano wiele przypadków zalewu z dużą ilością pakietów na sekundę (PPS) przy użyciu odbitego ruchu SYN-ACK. Podczas gdy ruch o niskiej przepustowości jest mniej prawdopodobne, aby nasycić łącza, wysoki PPS może powodować problemy dla sprzętu sieciowego próbującego przetwarzać i kierować zalew SYN-ACKS pędzący przez sieci.
Co atakujący może i czego nie może kontrolować
Atakujący SYN-ACK są zależni od konfiguracji TCP swoich reflektorów i sposobu, w jaki obsługują one połączenia TCP. Oznacza to, że atakujący są ograniczeni w tym, co mogą odbić do ofiary. Naukowcy z Akamai spędzili czas na testowaniu kilku usług opartych na TCP, które znajdują się na maszynach w całym Internecie, aby sprawdzić, jaka kombinacja flag TCP & może skutkować najbardziej skutecznymi scenariuszami ataku. Omówimy kilka scenariuszy ataków, jak się one różnią i jak atakujący mogą wykorzystać ataki SYN-ACK w przyszłości.
Opcje TCP i wyściełane SYN-ACKS
Atakujący nie mogą kontrolować zawartości pakietu SYN-ACK. Podczas gdy widzieliśmy padded SYN floods przez lata, pomysł padded SYN-ACK nie jest czymś, czego się spodziewamy. W prawdziwym świecie, gdy przeprowadzano ataki SYN-ACK, pakiety, które docierały do sieci ofiar miały przewidywalną długość 44 bajtów. Jak już wcześniej wspomniano, informuje nas to, że atakujący najprawdopodobniej wypychali bezopcyjne pakiety SYN o długości 40 bajtów, przy czym opcje MSS były najprawdopodobniej ustawiane przez sprzęt sieciowy na ścieżce tranzytu. Daje to niewielki współczynnik amplifikacji, ale chcieliśmy sprawdzić, jak duże SYN-ACK można uzyskać z prawdziwych serwerów.
Testy zostały przeprowadzone przy użyciu różnych wariantów opcji TCP. Celem testów była możliwość zidentyfikowania opcji, które mogłyby być wiarygodnie użyte i skutkować większą odpowiedzią SYN-ACK od losowo wybranych serwerów w Internecie. Opcje, które mogłyby zostać użyte przez atakującego, skutkując większymi SYN-ACK to Maximum Segment Size (MSS), Timestamp (TS) , Selective ACK (SAckOK), Window Scale (WScale), & TCP Fast Open (TFO) cookies.
Po prostu używając odpowiednich opcji, atakujący mógł zużyć około 62% więcej pasma niż w przypadku minimalnego pakietu SYN (72 bajty vs. 44 bajty). Wykorzystanie tych opcji, nagłówków zmniejsza współczynnik wzmocnienia (10% wzmocnienia staje się 6-7%); jednakże, nadal możliwe jest osiągnięcie wzmocnienia poprzez pominięcie opcji MSS, ponieważ zostanie ona ustawiona w tranzycie, niezależnie od tego, czy atakujący ją wyśle, czy nie.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options
, length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win
60192, options , length 0
Fig. 4) SYN-ACK padding with TFO
Podczas testów udało się wykorzystać TS, SAckOK, WSCale, & TFO TCP options (and NOP padding) to issue a 68 byte SYN packet that resulted in a 72 byte SYN-ACK response that was delivered to the victim, as seen in figure 4. Jeśli host nie obsługuje TFO, atakujący nadal może wysłać 56-bajtowy pakiet SYN, który skutkuje 60-bajtowym SYN-ACK kierowanym do sieci ofiary, jak widać na rysunku 5.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options
, length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192,
iv
options , length 0
Fig. 5) SYN-ACK padding minus TFO
SYN-ACK Amplification
Niewielkie wzmocnienie jest możliwe przy użyciu ataków SYN-ACK, ale możliwe jest zwiększenie tego współczynnika wzmocnienia poprzez ukierunkowanie na przestrzeń IP, która jest przydzielona, ale nie jest zajęta (co oznacza, że IP jest routowalne, ale żadna maszyna nie jest obecnie wdrożona i/lub nie obsługuje ruchu sieciowego). Taki scenariusz pozwala atakującym w pełni wykorzystać wysiłki retransmisji TCP, co z kolei zwiększa współczynniki wzmocnienia i zużycie pasma.
Gdy normalna maszyna otrzymuje out-of-state SYN-ACK od reflektora, odpowie pakietem RST, jak pokazano poniżej na Rysunku 6. Pakiet RST zostanie odebrany przez reflektor, a sesja TCP na reflektorze zostanie zakończona.
21:33:15.173204 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xfa7b (correct), seq 1000, win 8192, urg 0, length 0
21:33:15.191517 IP (tos 0x0, ttl 124, id 46635, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xb751 (correct), seq 1209013908, ack 1001, win
60720, options , length 0
21:33:15.191558 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 6) SYN-ACK poza stanem wywołuje odpowiedź RST
Je¶li ten pakiet SYN-ACK jest przeznaczony dla adresu IP, który jest przydzielony, ale nie jest zajęty, SYN-ACK zostanie przekierowany (wpływaj±c po drodze na sprzęt sieciowy), ale nigdy nie dotrze do prawdziwej maszyny, która mogłaby wydać RST. Ten brak pakietu RST spowoduje, że reflektor przyjmie, że dostarczenie SYN-ACK nie powiodło się i rozpocznie próby retransmisji.
W czasie testów, liczba prób retransmisji wynosi zazwyczaj pomiędzy 5 a 7 pakietów SYN-ACK wysyłanych do ofiary na każdy wysłany SYN. Jeśli założymy, że atakujący wysyła 40-bajtowy SYN, możemy spodziewać się 5-7 44-bajtowych pakietów SYN-ACK przemierzających sieć ofiary. W najgorszym przypadku, gdy otrzymamy 7 pakietów, oznacza to, że 40-bajtowe żądanie generuje 308 bajtów pakietów docierających do granic ofiary, co stanowi współczynnik amplifikacji wynoszący 770%. Wykorzystując nagłówki opcji TCP do generowania większych SYN-ACK, atakujący mógłby zwiększyć te liczby do 56 bajtów, co skutkowałoby 420 bajtami odbitego ruchu, co stanowi współczynnik wzmocnienia 750%.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options , length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:24.965713 IP (tos 0x0, ttl 124, id 46784, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfd96 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:26.965689 IP (tos 0x0, ttl 124, id 47738, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf5c6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:30.965750 IP (tos 0x0, ttl 124, id 49898, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xe626 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:38.965701 IP (tos 0x0, ttl 124, id 53757, offset 0, flags , proto TCP (6), length 60)
21:12:38.965701 IP (tos 0x0, ttl 124, id 53757, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xc6e6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:54.965710 IP (tos 0x0, ttl 124, id 61887, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x8866 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
Fig. 7) SYN skutkuje 6 SYN-ACKS
TFO, padding i amplifikacja
TCP Fast Open (TFO) jest tutaj omówione bardziej szczegółowo, aby pokryć kilka interesujących przypadków brzegowych zaobserwowanych podczas testów. Używając ciasteczek TFO, możliwe jest wywołanie większych odpowiedzi (dodatkowe 12 bajtów na SYN-ACK); jednakże, z powodu niedopatrzeń w implementacji TFO, środki te mogą zmienić współczynniki amplifikacji i, w różnych scenariuszach, ataki z włączoną obsługą TFO mogą być bardziej pożądane.
Atakujący próbujący wykorzystać reflektory z włączoną obsługą TFO mogą uznać to za owocne tylko w pewnych okolicznościach. Jeśli atakujący musi skierować odbite pakiety SYN-ACK do prawdziwych maszyn, które odpowiedzą pakietami RST, wzmocnienie retransmisji TCP jest w zasadzie bez znaczenia, ponieważ reflektor przestanie wysyłać SYN-ACK po otrzymaniu odpowiedzi RST od maszyn ofiary.
Aby uczynić tę propozycję jeszcze mniej pożądaną, hosty obsługujące TFO nie będą zawierały 12-bajtowego nagłówka dla ciasteczka TFO w dodatkowych pakietach SYN-ACK poza pierwszym pakietem. W skrócie oznacza to, że amplifikacja w tym scenariuszu nie jest serią 72-bajtowych pakietów trafiających w ofiarę. W rzeczywistych testach zaobserwowano, że pierwszy SYN-ACK będzie miał 72 bajty, ale kolejne 5-6 prób retransmisji pominie tę opcję TCP i w rezultacie otrzymamy pakiet 60 bajtowy. W tym przypadku, 72-bajtowy pakiet skutkuje 432-bajtowym odbiciem; zasadniczo, jedyną korzyścią jest 12 dodatkowych bajtów pierwszego pakietu w porównaniu do odbicia pomniejszonego o opcję ciasteczka TFO.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options , length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:46.651887 IP (tos 0x0, ttl 124, id 51447, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6bb0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:48.651862 IP (tos 0x0, ttl 124, id 52323, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x63e0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:52.651854 IP (tos 0x0, ttl 124, id 54181, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x5440 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:00.651876 IP (tos 0x0, ttl 124, id 58527, offset 0, flags , proto TCP (6), length 60)
20:52:00.651876 IP (tos 0x0, ttl 124, id 58527, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x3500 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:16.651862 IP (tos 0x0, ttl 124, id 2147, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf67f (correct), seq 3436032873, ack 1001, win 60192, options , length 0
Fig. 8) Pominięcie ciasteczka TFO po pierwszej odpowiedzi
Hostery obsługujące TFO resetują swoje ciasteczka handshake po otrzymaniu RST od atakowanej maszyny (maszyn). Oznacza to, że atakujący atakujący prawdziwe maszyny używające reflektorów z włączoną obsługą TFO może w niezawodny sposób spowodować serię 72-bajtowych pakietów SYN-ACK przychodzących do punktów końcowych ofiary.
Współczynnik wzmocnienia wynosi tylko 4 bajty, zakładając, że 68-bajtowe żądanie od atakującego powoduje 72-bajtowy SYN-ACK przychodzący do ofiary, po którym następuje pakiet RST od ofiary do reflektora. Jeżeli taka sytuacja ma miejsce w sposób ciągły, to sesje TCP inicjowane na reflektorze przez atakującego zawsze będą kończyły się pakietem SYN-ACK zawierającym dodatkowe bajty będące opcją cookie TFO.
20:54:41.611605 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x8762 (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:41.629518 IP (tos 0x0, ttl 124, id 14354, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6ade (correct), seq 3714341928, ack 1001, win 60192, options , length 0
20:54:41.629548 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:42.664171 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xc1bd (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:42.682391 IP (tos 0x0, ttl 124, id 15171, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6d0a (correct), seq 3730789605, ack 1001, win 60192, options , length 0
20:54:42.682440 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:43.781512 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:43.800464 IP (tos 0x0, ttl 124, id 15726, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xf5fe (correct), seq 3748251272, ack 1001, win 60192, options , length 0
20:54:43.800534 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 9) TFO cookie inclusion after RST
Wątpliwości dotyczące łagodzenia skutków
Złagodzenie skutków odbicia SYN-ACK może być trudne i musi być wykonane ostrożnie. Bardzo łatwo jest przesadzić z łagodzeniem tego typu ataku i spowodować szkody dla prawdziwych klientów i sesji TCP w sieciach produkcyjnych. Uszkodzone sesje przekładają się na problemy z łącznością, obniżoną wydajność i blokowanie legalnych hostów/użytkowników w sieci. Te nadmierne środki łagodzące mogą mieć dłuższe i bardziej dotkliwe skutki niż sam atak.
W wielu przypadkach nadmierne łagodzenie ataków wpływających na TCP może mieć również nieoczekiwane rezultaty dla ofiar. Podczas ataków SYN flood, na przykład, często zdarza się, że gdy prawdziwe usługi zaczynają mieć problemy z łącznością, w sieci pojawia się wtórna fala ataków. W takich przypadkach, „druga fala” jest niczym innym, jak wynikiem nieudanych prób nawiązania legalnego połączenia przez prawdziwych klientów/użytkowników, co przekłada się na wzrost liczby pakietów SYN powyżej normalnego poziomu, ponieważ dotknięci klienci próbują retransmitować niepotwierdzone pakiety SYN.
Nadmierne łagodzenie ataku SYN-ACK może prawdopodobnie spowodować problemy i podobne rezultaty, szczególnie jeśli łagodzenie ma miejsce w punkcie sieci, w którym prawdziwi klienci wykonują legalne żądania wychodzące.
PRAWDZIWA poprawka dla ataków typu reflection
Jak w przypadku większości ataków typu spoofing, prawdziwa poprawka nie jest czymś, co znajduje się pod kontrolą pojedynczej organizacji. Aby naprawdę rozwiązać ten i inne problemy związane z możliwościami spoofingu, musimy zwrócić się do IETF i operatorów sieci. IETF opublikował BCP38, który opisuje w jaki sposób operatorzy sieci mogą identyfikować i zapobiegać routingowi ruchu spoofingowego. Na koniec dnia, jest to coś, co operatorzy sieci muszą wdrożyć i egzekwować, jeśli naprawdę mamy nadzieję, że tego typu ataki typu spoofed/reflected znikną, lub przynajmniej staną się znacznie trudniejsze do zaaranżowania.
Podsumowanie
Odbite ataki SYN-ACK nie są czymś nowym; są właściwie czymś tak starym jak sam TCP. Ich brak popularności ma więcej wspólnego z innymi odbijanymi atakami opartymi na UDP, które są o wiele bardziej niepokojące i wpływowe oraz ogólnie stanowią lepszy zestaw narzędzi dla atakujących. Nie są one efektem ubocznym wadliwej implementacji, nie są exploitem, są symptomem tego, że spoofing IP w Internecie jest nadal możliwy prawie 20 lat po tym, jak proponowane rozwiązanie dla właścicieli i operatorów sieci zostało opracowane i sfinalizowane.
Niestety, stare ataki nadal mogą być bolesne, a odbite SYN-ACK nie są wyjątkiem. Organizacje powinny rozważyć przyjrzenie się swoim możliwościom i opcjom łagodzenia ataków, ponieważ sprzęt sieciowy może mieć problemy z obsługą zalewu ruchu o wysokim PPS przez granice i sieci.
Ważne jest, aby podkreślić realną możliwość nadmiernego łagodzenia ataków tego typu i zapewnić, że próby zwalczania tego typu ataków nie będą skutkowały samoistnymi przestojami… zadanie, o którym łatwiej powiedzieć niż zrobić.