Pliki cookie SYN

Plik cookie SYN to technika używana do przeciwdziałania atakom typu SYN flood . Główny wynalazca tej techniki, Daniel J. Bernstein, definiuje pliki cookie SYN jako „szczególne wybory początkowych numerów sekwencyjnych TCP przez serwery TCP”. W szczególności użycie plików cookie SYN pozwala serwerowi uniknąć zrywania połączeń, gdy kolejka SYN się zapełni. Zamiast przechowywania dodatkowych połączeń, pozycja kolejki SYN jest kodowana w numerze sekwencyjnym wysłanym w SYN+ACK odpowiedź. Jeśli następnie serwer otrzyma kolejną odpowiedź ACK od klienta ze zwiększonym numerem sekwencyjnym, serwer jest w stanie zrekonstruować pozycję kolejki SYN przy użyciu informacji zakodowanych w numerze sekwencyjnym TCP i kontynuować połączenie w zwykły sposób.

Realizacja

W celu zainicjowania połączenia TCP klient wysyła do serwera pakiet TCP SYN. W odpowiedzi serwer wysyła pakiet TCP SYN+ACK z powrotem do klienta. Jedną z wartości w tym pakiecie jest numer kolejny , który jest używany przez protokół TCP do ponownego złożenia strumienia danych. Zgodnie ze specyfikacją TCP, ten pierwszy numer sekwencyjny wysłany przez punkt końcowy może być dowolną wartością określoną przez ten punkt końcowy. Ponieważ numer sekwencyjny jest wybierany przez nadawcę, zwracany przez odbiorcę i nie ma innej zdefiniowanej struktury wewnętrznej, może być przeciążony, aby przenosić dodatkowe dane. Poniżej opisano jedną możliwą implementację, jednak ponieważ nie ma publicznego standardu, którego należy przestrzegać, kolejność, długość i semantyka pól mogą się różnić w zależności od implementacji plików cookie SYN.

Pliki cookie SYN to początkowe numery sekwencyjne, które są starannie skonstruowane zgodnie z następującymi zasadami:

  • niech t będzie wolno rosnącym znacznikiem czasu (zwykle time() logicznie przesunięty w prawo o 6 pozycji, co daje rozdzielczość 64 sekund)
  • niech m będzie wartością maksymalnego rozmiaru segmentu (MSS), którą serwer przechowywałby we wpisie kolejki SYN
  • niech będzie wynikiem kryptograficznej funkcji skrótu obliczonej na podstawie adresu IP i numeru portu serwera, adresu IP i numeru portu klienta oraz wartości t . Zwracana wartość s musi być wartością 24-bitową.

Początkowy numer sekwencyjny TCP, czyli plik cookie SYN , jest obliczany w następujący sposób:

  • Top 5 bitów: t mod 32
  • Środkowe 3 bity: zakodowana wartość reprezentująca m
  • Dolne 24 bity: s

(Uwaga: ponieważ m musi być zakodowane przy użyciu 3 bitów, serwer jest ograniczony do wysyłania do 8 unikalnych wartości dla m , gdy używane są pliki cookie SYN.)

Kiedy klient odsyła pakiet TCP ACK do serwera w odpowiedzi na pakiet SYN+ACK serwera, klient musi (zgodnie ze specyfikacją TCP) użyć n+1 w numerze potwierdzenia pakietu, gdzie n jest początkowym wysłanym numerem sekwencyjnym przez serwer. Następnie serwer odejmuje 1 od numeru potwierdzenia, aby odsłonić plik cookie SYN wysłany do klienta.

Następnie serwer wykonuje następujące operacje.

  • Sprawdza wartość t względem bieżącego czasu, aby zobaczyć, czy połączenie wygasło.
  • Przelicza s, aby określić, czy rzeczywiście jest to prawidłowy plik cookie SYN.
  • Dekoduje wartość m z 3-bitowego kodowania w pliku cookie SYN, której następnie może użyć do zrekonstruowania pozycji kolejki SYN.

Od tego momentu połączenie przebiega normalnie.

Wady

Korzystanie z plików cookie SYN nie łamie żadnych specyfikacji protokołów, dlatego powinno być kompatybilne ze wszystkimi implementacjami protokołu TCP. Istnieją jednak dwa zastrzeżenia, które mają zastosowanie, gdy używane są pliki cookie SYN. Po pierwsze, serwer jest ograniczony tylko do 8 unikalnych wartości MSS, ponieważ tylko tyle można zakodować w 3 bitach. Po drugie, wczesne implementacje odrzucały wszystkie opcje TCP (takie jak duże okna lub znaczniki czasu), ponieważ serwer odrzucał pozycję kolejki SYN, w której inaczej byłyby przechowywane te informacje. jednak wersja 2.6.26 jądra Linuksa dodała częściową obsługę opcji TCP poprzez zakodowanie ich w opcji znacznika czasu . Wreszcie pliki cookie SYN powodują zwiększone obciążenie zasobów serwera. Szyfrowanie odpowiedzi jest kosztowne obliczeniowo. Plik cookie SYN nie ogranicza ruchu, co sprawia, że ​​jest nieskuteczny w przypadku ataków SYN flooding, których wektorem ataku jest przepustowość.

Chociaż te ograniczenia z konieczności prowadzą do nieoptymalnego doświadczenia, ich efekt jest rzadko zauważany przez klientów, ponieważ są one stosowane tylko wtedy, gdy są atakowane. W takiej sytuacji utrata opcji TCP w celu ratowania połączenia jest zwykle uważana za rozsądny kompromis.

Problem pojawia się, gdy pakiet ACK finalizujący połączenie wysłany przez klienta zostaje utracony, a protokół warstwy aplikacji wymaga, aby serwer mówił pierwszy (na przykład SMTP i SSH ). W takim przypadku klient zakłada, że ​​połączenie zostało nawiązane pomyślnie i czeka na wysłanie przez serwer swojego banera protokołu lub ponowne wysłanie pakietu SYN+ACK; jednak serwer nie jest świadomy sesji i nie wyśle ​​ponownie SYN+ACK, ponieważ odrzucił wpis kolejki zaległości, który umożliwiłby mu to. W końcu klient przerwie połączenie z powodu przekroczenia limitu czasu warstwy aplikacji, ale może to zająć stosunkowo dużo czasu.

TCP Cookie Transactions (TCPCT) został zaprojektowany w celu przezwyciężenia tych niedociągnięć plików cookie SYN i ulepszenia go w kilku aspektach. W przeciwieństwie do plików cookie SYN, protokół TCPCT jest rozszerzeniem protokołu TCP i wymaga wsparcia ze strony obu punktów końcowych. Został przeniesiony do statusu „Historyczny” przez RFC 7805 w 2016 roku.

Względy bezpieczeństwa

Proste zapory , które są skonfigurowane tak, aby zezwalać na wszystkie połączenia wychodzące , ale ograniczać porty, do których może dotrzeć połączenie przychodzące (na przykład zezwalać na połączenia przychodzące do serwera WWW na porcie 80, ale ograniczać wszystkie inne porty), działają poprzez blokowanie tylko przychodzących żądań SYN do niepożądanych porty. Jeśli działają pliki cookie SYN, należy uważać, aby osoba atakująca nie była w stanie ominąć takiej zapory ogniowej, zamiast tego fałszując potwierdzenia ACK, próbując losowych numerów sekwencyjnych, dopóki nie zostanie zaakceptowana. Pliki cookie SYN należy włączać i wyłączać dla poszczególnych portów tak, aby włączenie cookies SYN na porcie publicznym nie powodowało ich rozpoznawania na porcie niepublicznym. Oryginalna jądra Linuksa źle zrozumiała tę część opisu Bernsteina i użyła jednej zmiennej globalnej do włączenia plików cookie SYN dla wszystkich portów; zostało to wskazane przez jednego z badaczy, a następnie poprawione w CVE - 2001-0851 .

Historia

Technika została stworzona przez Daniela J. Bernsteina i Erica Schenka we wrześniu 1996 roku. Pierwsza implementacja (dla SunOS ) została wydana przez Jeffa Weisberga miesiąc później, a Eric Schenk wydał swoją implementację dla Linuksa w lutym 1997 roku. FreeBSD implementuje pliki syncookie od FreeBSD 4.5 ( styczeń 2002).

Zobacz też

  1. ^ [1] , Cr.yp.do września 1996
  2. ^ Patrick McManus, Improving Syncookies , lwn.net kwiecień 2008
  3. ^ András Korn, Mechanizmy obronne przed atakami sieciowymi i robakami (pdf) , 2011
  4. ^ Kleen, Andi (31 maja 1999). „Implementacja Syncookies dla jądra Linux (wersja 2.2.9)” . static unsigned long tcp_lastsynq_overflow
  5. ^ Brown, Silas S. (15 października 2001). „Sieć Linux: błąd bezpieczeństwa w plikach cookie SYN” . Zarchiwizowane od oryginału w dniu 2017-10-14. Rozwiązaniem (jak wskazał DJ Bernstein w prywatnej komunikacji w odpowiedzi na powyższe) jest uczynienie zmiennej tcp_lastsynq_overflow lokalną dla każdego portu nasłuchującego, zamiast być globalną.
  6. ^ „Jądro Linuksa wykorzystujące pliki cookie synchronizacji może pozwolić atakującemu na ominięcie filtrowania” . 2001. Zarchiwizowane od oryginału w dniu 2013-04-13 . Źródło 2013-03-17 .
  7. Bibliografia _ _

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=SYN_cookies&oldid=1065174011 ”