Bezpieczeństwo TCP

Bezpieczeństwo TCP: Zakres i ograniczenia

Protokół sterowania transmisją (TCP) zapewnia uporządkowany i niezawodny strumień bajtów w sieci IP. Wykorzystuje numery sekwencyjne, potwierdzenia, sumy kontrolne, retransmisje oraz stan połączenia, aby obsługiwać zwykłe straty i zmiany kolejności segmentów. Mechanizmy te dotyczą niezawodności transportu. TCP nie uwierzytelnia punktów końcowych, nie szyfruje danych i nie potwierdza, że segment pochodzi od hosta wskazanego przez adres źródłowy.

TCP określano dla środowiska, w którym hosty i ścieżki miały współpracować. Projekt koncentrował się na utracie pakietów, kolejności danych i przeciążeniu. Złośliwy nadawca może wykorzystać tworzenie stanu podczas uzgadniania, odgadnąć lub obserwować informacje o sekwencji albo wstrzyknąć segment sterujący ze sfałszowanym adresem. Stanowy mechanizm TCP pomaga zapewnić niezawodność, lecz sam nie jest mechanizmem uwierzytelniania.

Analiza bezpieczeństwa TCP zaczyna się od mechanizmów transportu i założeń, na których się opierają. Zalew SYN, przewidywanie numerów sekwencyjnych i wstrzykiwanie RST ujawniają różne słabości, a współczesne implementacje stosują środki zaradcze dla określonych przypadków. Szyfrowanie i uwierzytelnianie punktów końcowych wymagają dodatkowych protokołów i pozostają poza zakresem TCP.

Zalew SYN: Wyczerpanie stanu oczekujących połączeń

SYN flood to klasyczny atak typu Denial-of-Service (DoS), który bezpośrednio wykorzystuje mechanikę trójetapowego uzgadniania TCP.

Analiza Podatności w Procesie Uzgadniania

Aby zrozumieć atak, przeanalizujmy zachowanie serwera podczas zwykłego uzgadniania.

1. Klient wysyła pakiet SYN do serwera.
2. Serwer odbiera SYN. Typowa implementacja przydziela zasoby dla stanu oczekującego, w tym Blok Kontrolny Transmisji (TCB) z adresami punktów końcowych, portami, informacjami o sekwencji i danymi liczników czasu. Umieszcza połączenie w stanie 'SYN_RCVD' oraz ogranicza liczbę takich wpisów w kolejce oczekujących połączeń.
3. Serwer odsyła pakiet SYN-ACK do klienta.
4. Serwer czeka na ostatnie potwierdzenie ACK od klienta, aby zakończyć uzgadnianie i przenieść połączenie do stanu 'ESTABLISHED'.

Narażenie powstaje w Kroku 2. Serwer angażuje pamięć i stan przed uzyskaniem informacji, że nadawca może odebrać SYN-ACK i zakończyć uzgadnianie. Wpis oczekujący pozostaje do nadejścia końcowego ACK albo do usunięcia przez licznik retransmisji.

Przeprowadzenie Ataku SYN Flood

Atakujący może wykorzystać tę zależność zasobów, wysyłając wiele nieukończonych uzgodnień.

1. Atakujący używa jednej lub wielu maszyn do wysłania dużej liczby pakietów SYN do docelowego serwera.
2. W częstym wariancie te pakiety SYN zawierają sfałszowany (fałszywy) źródłowy adres IP. Atakujący nie może odbierać odpowiedzi wysyłanych na te adresy, więc końcowe ACK nie wracają. Zalew SYN może także korzystać z osiągalnych źródeł, ponieważ spoofing nie jest konieczny do wyczerpania zasobów.
3. Serwer docelowy otrzymuje strumień SYN. Dla każdego zaakceptowanego żądania zapisuje półotwarte połączenie w stanie oczekującym i wysyła SYN-ACK na podany adres źródłowy.
4. W przypadku sfałszowanych źródeł pakiety SYN-ACK podróżują przez internet do nieistniejących lub niereagujących maszyn, więc końcowy ACK nie wraca do serwera.

Skutkiem jest presja na zasoby.Serwer może przechowywać wiele półotwartych połączeń w stanie 'SYN_RCVD'. Każdy wpis zużywa zasoby implementacji i miejsce w skończonej kolejce. Po osiągnięciu limitów nowe SYN mogą być opóźniane lub odrzucane, także te pochodzące od prawidłowych klientów. Usługa może wtedy stać się niedostępna albo odnotowywać dużą liczbę nieudanych połączeń. Wynik zależy od limitów implementacji i szybkości ataku.

Obrona: Ciasteczka SYN (SYN Cookies)

Serwer może ograniczyć to narażenie przez ciasteczka SYN. Mechanizm odpowiada na początkowy SYN bez zachowywania zwykłego stanu SYN-RECEIVED. Końcowe ACK zawiera informacje pozwalające odtworzyć i zweryfikować żądanie przed przydzieleniem pełnego stanu połączenia.

Jak Działają Ciasteczka SYN

1. Otrzymanie SYN: Kiedy serwer używający ciasteczek SYN otrzymuje pakiet SYN, nie zachowuje zwykłego oczekującego TCB dla tego żądania. Może jednak utrzymywać niewielkie, zależne od implementacji liczniki lub stan polityki.
2. Tworzenie Ciasteczka: Serwer wysyła obliczony Początkowy Numer Sekwencyjny (ISN), który koduje informacje potrzebne do późniejszej weryfikacji. Typowa konstrukcja łączy funkcję kluczowaną z parametrami połączenia i składnikiem zależnym od czasu. Dane wejściowe mogą obejmować ISN klienta oraz zakodowaną wartość MSS:
   • Źródłowy adres IP i numer portu klienta.
   • Docelowy adres IP i numer portu serwera.
   • Wartość czasu i tajny klucz znany tylko serwerowi.
3. Wysłanie SYN-ACK: Serwer wysyła standardowy SYN-ACK z obliczonym ISN i nie zachowuje zwykłego stanu połączenia oczekującego. Sposób kodowania ciasteczka zależy od implementacji. Niektóre opcje TCP lub dane przenoszone w początkowym SYN mogą być niedostępne albo obsłużone z ograniczeniami, gdy ciasteczka są aktywne.

Dwa Możliwe Scenariusze

• Jeśli nadawca użył sfałszowanego adresu: SYN-ACK jest wysyłany na podany adres, a końcowe ACK zwykle nie wraca. Serwer nie zachował zwykłego TCB, więc żądanie nie zajmuje tego stanu połączenia.
• Jeśli nadawca może odebrać odpowiedź: Klient otrzymuje SYN-ACK i wysyła końcowe ACK. Numer potwierdzenia jest równy ISN serwera, zawierającemu ciasteczko, powiększonemu o jeden. Ta wartość umożliwia weryfikację żądania.

Weryfikacja i Nawiązanie Połączenia

Gdy serwer otrzyma końcowe ACK, odejmuje jeden od numeru potwierdzenia, odzyskuje wartość ciasteczka i porównuje ją z obliczeniem opartym na adresach, portach, czasie, tajnym kluczu oraz zakodowanych opcjach. Prawidłowa wartość wskazuje, że nadawca otrzymał SYN-ACK albo uzyskał jego numer sekwencyjny. Dopiero po tej kontroli serwer odtwarza stan oczekujący i ustanawia połączenie.

Ciasteczka SYN ograniczają wyczerpanie stanu pojedynczych oczekujących połączeń, lecz nie usuwają kosztów procesora, przepustowości, kolejek ani limitów aplikacji. Mogą również ograniczać dostępność opcji TCP, dlatego implementacje często włączają je przy określonym poziomie obciążenia lub podczas ataku.

Przewidywanie Numerów Sekwencyjnych i Przejęcie Sesji TCP

Inna poważna klasa ataków na TCP polega na przewidywaniu numerów sekwencyjnych, których TCP używa do porządkowania i potwierdzania danych. Jeśli atakujący zdoła odgadnąć następny numer sekwencyjny w połączeniu, może wstrzyknąć złośliwe dane do konwersacji. Jest to znane jako Przejęcie Sesji TCP (ang. TCP Session Hijacking).

Podatność: Przewidywalne ISN

Reguły akceptowania segmentów TCP zakładają, że atakujący spoza ścieżki nie zna bieżących numerów sekwencyjnych ustanowionego połączenia. Samo połączenie jest identyfikowane przez 4-krotkę adresów i portów. Kontrola numerów sekwencyjnych zapewnia ograniczoną weryfikację pochodzenia segmentu, lecz nie uwierzytelnia punktu końcowego przed obserwatorem znajdującym się na ścieżce.

We wczesnych implementacjach TCP Początkowe Numery Sekwencyjne (ISN) mogły mieć przewidywalny wzorzec, na przykład postać globalnego licznika. Obecne zalecenia łączą składnik zależny od zegara z kluczowaną funkcją pseudolosową obliczaną dla krotki połączenia i tajnego klucza. Utrudnia to zgadywanie atakującemu spoza ścieżki, lecz obserwacja lub wstrzykiwanie ruchu na ścieżce pozostaje odrębnym zagrożeniem.

Atak Przejęcia Sesji w Praktyce

1. Legalny użytkownik ustanawia uwierzytelnione połączenie z serwerem (np. sesję Telnet po zalogowaniu).
2. Atakujący, który chce przejąć tę sesję, najpierw obserwuje ruch, aby poznać adresy IP i numery portów.
3. Następnie atakujący przeprowadza krótki atak DoS na legalnego klienta, aby go tymczasowo uciszyć. Jest to ważne, aby uniemożliwić prawdziwemu klientowi wysyłanie pakietów RST, które zabiłyby przejętą sesję.
4. Atakujący musi teraz wstrzyknąć dane. Przewiduje następny numer sekwencyjny, którego serwer oczekuje od klienta.
5. Atakujący tworzy złośliwy pakiet. Pakiet ten ma sfałszowany źródłowy adres IP klienta, prawidłowe porty oraz przewidziany numer sekwencyjny. Ładunek tego pakietu zawiera nieuprawnione polecenie aplikacyjne, na przykład polecenie zmieniające dane serwera.
6. Jeśli przewidywanie jest poprawne, serwer otrzymuje sfałszowany pakiet. Gdy 4-krotka, numer sekwencyjny i stan protokołu aplikacyjnego wyglądają prawidłowo, serwer może zaakceptować ładunek. Sfałszowany segment wpływa wtedy na sesję.

Obrona: Losowe ISN

Podstawową obroną przed przewidywaniem numerów sekwencyjnych jest algorytm ISN trudny do przewidzenia. Aktualne zalecenia TCP łączą wartość zależną od zegara z kluczowaną funkcją pseudolosową obliczaną dla lokalnych i zdalnych adresów, portów oraz tajnego klucza. Znacznie zmniejsza to szansę poprawnego zgadnięcia numeru przez atakującego spoza ścieżki. Nie chroni ruchu przed atakującym na ścieżce i nie zastępuje szyfrowania ani uwierzytelniania punktów końcowych.

Wstrzyknięcie segmentu RST

Sfałszowany segment z ustawioną flagą RST może przerwać istniejące połączenie TCP. Atakujący musi odtworzyć adresy IP, porty oraz numer sekwencyjny akceptowany przez punkt końcowy.

Walidacja numeru sekwencyjnego

Starsze zachowanie TCP pozwalało zaakceptować RST z numerem sekwencyjnym mieszczącym się w oknie odbiorczym. Mechanizm opisany w RFC 5961 zaostrza tę kontrolę. RST jest przyjmowany natychmiast tylko wtedy, gdy jego numer sekwencyjny jest równy oczekiwanej wartości RCV.NXT. Segment mieszczący się w oknie, ale niespełniający tego warunku, powoduje wysłanie challenge ACK i zostaje odrzucony.

Warunki przeprowadzenia ataku

1. Atakujący identyfikuje docelowe połączenie na podstawie jego źródłowych i docelowych adresów IP i portów.
2. Atakujący przygotowuje segment RST z adresem źródłowym drugiej strony połączenia.
3. Atakujący spoza ścieżki musi odgadnąć numer sekwencyjny. Walidacja zgodna z RFC 5961 znacznie zmniejsza prawdopodobieństwo powodzenia prób obejmujących całe okno odbiorcze.
4. Atakujący znajdujący się na ścieżce może obserwować parametry połączenia i dobrać poprawny numer sekwencyjny, dlatego sam mechanizm challenge ACK nie usuwa tego zagrożenia.
5. Po zaakceptowaniu RST punkt końcowy przerywa połączenie.

Atak ten może być użyty do zakłócania długotrwałych połączeń, takich jak transfery baz danych, duże pobieranie plików czy trwałe połączenia używane przez protokoły routingu, takie jak BGP.

Ochrona przed wstrzyknięciem RST

Podstawową ochronę zapewnia dokładna walidacja numeru sekwencyjnego i mechanizm challenge ACK opisany w RFC 5961. Filtrowanie sfałszowanych adresów źródłowych oraz monitorowanie nietypowych serii segmentów RST ograniczają możliwość wykonania ataku spoza ścieżki. TLS nie chroni przed wstrzyknięciem RST, ponieważ RST jest przetwarzany przez TCP poniżej warstwy TLS i nie stanowi szyfrowanego rekordu TLS. W zastosowaniach wymagających uwierzytelnienia segmentów TCP można rozważyć TCP-AO, a ochronę ruchu na warstwie sieciowej może zapewnić IPsec.

Podsumowanie: Warstwowe Podejście do Bezpieczeństwa

TCP zapewnia niezawodność transportu, lecz nie stanowi kompletnej granicy bezpieczeństwa. Zalew SYN, przejęcie sesji i wstrzyknięcie RST pokazują, jak można nadużyć tworzenia stanu, kontroli numerów sekwencyjnych oraz segmentów sterujących przy sfałszowanym albo obserwowanym ruchu.

Środki takie jak ciasteczka SYN, mniej przewidywalne ISN i zaostrzona kontrola RST zmniejszają określone ryzyka. Nie obejmują wszystkich ataków ani wszystkich limitów zasobów. Bezpieczeństwo sieci wymaga więc kilku warstw o rozdzielnych zadaniach, w tym kontroli transportu, protokołów kryptograficznych, konfiguracji hostów i monitorowania.

TLS może zapewniać poufność i uwierzytelnianie punktów końcowych nad TCP, a zapory oraz systemy wykrywania włamań mogą egzekwować reguły i rejestrować wzorce ruchu. TCP pozostaje warstwą niezawodnego transportu, natomiast wymagane właściwości bezpieczeństwa muszą zapewnić otaczające protokoły, hosty i mechanizmy sieciowe.