Tcp on Morfitronik

Czy brak wsparcia dla SYNPROXY w nftables jest problemem

Mikhail Morfikov — Sat, 16 Feb 2019 10:20:52 +0000

Przenosząc swoje reguły z iptables na nftables zauważyłem, że jedna z nich (gdyby tylko jedna) nie została przetłumaczona przez ten dedykowany translator do reguł. Chodzi o mechanizm SYNPROXY, który jest zwykle wykorzystywany do ograniczenia skali ataków DDOS z wykorzystaniem pakietów SYN. Co by nie mówić, to ochrona jaką daje SYNPROXY jest jak najbardziej pożądana z perspektywy serwerów. Dlaczego zatem, gdy się zajrzy na stronę wspieranych rzeczy w nftables, to przy SYNPROXY widnieje bliżej nieokreślone sformułowanie consider native interface ? Po rozmowach z deweloperami udało się ustalić, że ten zapis oznacza brak wsparcia dla SYNPROXY w nftables . Jeśli zatem ktoś wykorzystuje ten mechanizm mając dodane stosowne reguły w iptables , to czy powinien się on obawiać przejścia na nftables ?

Mechanizm SYN cookies w protokole TCP

Mikhail Morfikov — Sat, 24 Oct 2015 20:22:02 +0000

Atak SYN flood to rodzaj ataku DoS, którego celem jest wyczerpanie zasobów serwera uniemożliwiając mu tym samym poprawne realizowanie danej usługi, do której został oddelegowany. Jest to dość popularne zjawisko i w przypadku, gdy mamy postawioną jakąś maszynę na publicznym adresie IP, przydałoby się nieco zainteresować tym problem, który może wystąpić w najmniej oczekiwanym momencie. W tym wpisie rzucimy okiem na mechanizm SYN cookies.

Unikanie ataków DDoS z SYNproxy

Mikhail Morfikov — Sat, 24 Oct 2015 17:39:24 +0000

Internet nie jest zbyt przyjaznym miejscem i jest wielce prawdopodobne, że prędzej czy później ktoś zaatakuje jedną z naszych maszyn, która świadczy w nim jakieś usługi. Są różne typy ataków, w tym przypadku chodzi o ataki DDoS z wykorzystaniem pakietów wchodzących w proces potrójnego witania (three way handshake) przy nawiązywaniu połączenia w protokole TCP, tj. pakiety SYN , SYN-ACK i ACK . Istnieje szereg mechanizmów, które adresują problem SYN flooding'u ale żaden z nich nie jest doskonały. Jakiś czas temu, do kernela linux'owego trafił patch implementujący mechanizm SYNproxy i w tym wpisie obadamy go sobie nieco dokładniej.

Retransmisja i duplikaty pakietów w TCP

Mikhail Morfikov — Wed, 23 Sep 2015 19:31:27 +0000

Retransmisja pakietu w przypadku sieci opartych na protokołach TCP/IP nie jest niczym niezwykłym. Oczywiście, pozostaje kwestia samego realizowania tego przedsięwzięcia ale generalnie rzecz biorąc, systemy linux'owe mają szereg opcji w kernelu, które możemy sobie dostosować konfigurując tym samym, to w jaki sposób nasz system reaguje na zjawisko utraty pakietów podczas ich przesyłu między dwoma punktami sieciowymi.

Wolny start połączeń w protokole TCP

Mikhail Morfikov — Tue, 07 Jul 2015 19:33:16 +0000

Wolny start jest wynikiem braku zaufania maszyny nadawczej do utworzonego kanału przesyłowego -- połączenia. Nie wie ona czy to łącze jest bowiem w stanie obsłużyć taką porcję danych, którą ma zamiar przesłać bez czekania na pakiet ACK . W przypadku bufora odbiorczego, wszystko jest proste, bo dane dotyczące wielkości okien są zdefiniowane w nagłówku pakietów, do których ma wgląd druga ze stron. W przypadku gdy nadawca przesyła dane, prędkość z jaką to robi zależy głównie od niego.

Bufor połączeń w protokole TCP

Mikhail Morfikov — Wed, 01 Jul 2015 10:20:16 +0000

Wraz ze zwiększaniem zapotrzebowania na szybsze łącza internetowe, ograniczenia wynikające z protokółu TCP zaczęły powoli dawać się ludziom we znaki. Problemem była bariera prędkości, którą ciężko było pokonać mając do dyspozycji domyślną formę nagłówka protokołu TCP. Było w nim zwyczajnie za mało miejsca, co zapoczątkowało jego rozbudowę kosztem ilości danych, które można było przesłać w pojedynczym segmencie. W tym wpisie skupię się głównie na dwóch opcjach jakie zostały dodane do nagłówka TCP, tj. dynamiczne skalowanie okien oraz znaczniki czasu, bo te dwa parametry nie mogą wręcz bez siebie istnieć, zwłaszcza gdy rozmawiamy o łączach pokroju 1 czy 10 gbit/s.

SACK, czyli selektywne potwierdzenia pakietów

Mikhail Morfikov — Wed, 01 Jul 2015 06:04:18 +0000

Protokół TCP jest tak zbudowany by zapewnić rzetelny transfer danych między dwoma komunikującymi się punktami. Z początku jednak, ta cecha tego protokołu powodowała marnowanie dość sporych ilości zasobów jeśli chodzi o przepustowość łącza. Stało się to widoczne przy większych prędkościach połączeń, gdzie skalowany był bufor (okno) TCP, co umożliwiło przesyłanie szeregu segmentów bez potrzeby czekania na ich potwierdzenie przez odbiorcę. To zwiększyło, co prawda, transfer danych ale pojawił się problem z zagubionymi pakietami.

TSO, czyli odciążenie segmentacji TCP

Mikhail Morfikov — Tue, 30 Jun 2015 21:15:08 +0000

Stawiając sobie środowisko testowe pod wireshark'a w celu analizy pakietów sieciowych, zauważyłem, że coś mi się nie zgadza odnośnie wielkości przesyłanych pakietów między interfejsami kontenerów LXC. Jakby nie patrzeć, środowisko testowe ma być odwzorowaniem środowiska produkcyjnego i w tym przypadku wszelkie zasady dotyczące, np. podziału danych na segmenty, muszą być takie same. Generalnie rzecz biorąc rozmiar pakietu powinien wynosić 1514 bajtów, a był parokrotnie większy. Okazało się, że jest to za sprawą odciążenia segmentacji w protokole TCP (TCP Segmentation Offload).

Fragmentacja pakietu i zmiana wartości MTU

Mikhail Morfikov — Mon, 29 Jun 2015 21:35:12 +0000

MTU (Maximum Transmission Unit) to maksymalna długość pakietu jaki może zostać przesłany przez sieć. Może ona wynosić do 64KiB ale większość punktów sieciowych, takich jak routery, wymusza o wiele mniejsze rozmiary pakietów. Domyślna wartość MTU dla protokołu Ethernet to 1500 bajtów, oczywiście bez nagłówka warstwy fizycznej, który ma dodatkowe 14 bajtów. Czasami te standardowe ustawienia mogą powodować problemy w przypadku pewnych konfiguracji sieci i gdy ich doświadczamy, przydałoby się zmienić rozmiar MTU przesyłanych pakietów.

Znacznik czasu (timestamp) w protokole TCP

Mikhail Morfikov — Sun, 28 Jun 2015 17:33:54 +0000

O znacznikach czasu (timestamp) wspominałem już raz w ramach omawiania mechanizmu jakim jest bufor połączenia, a konkretnie rozchodziło się o skalowanie okien TCP. Generalnie rzecz biorąc, przy wyższych prędkościach, rzędu 1 gbit/s, nie ma innej opcji jak skorzystanie z opcji znaczników czasu, które są niejako rozszerzeniem czegoś co widnieje pod nazwą numery sekwencyjne . Z jednej strony może i mamy możliwość implementacji łącz o większej przepustowości ale z drugiej te znaczniki czasu w pakietach TCP mogą zagrozić bezpieczeństwu stacji roboczej.

Numery sekwencyjne w strumieniu TCP

Mikhail Morfikov — Thu, 25 Jun 2015 21:24:41 +0000

Jeśli zastanawialiście się czym są numery sekwencyjne i potwierdzeń w strumieniach protokołu TCP, to nie jesteście jedyni, którym to zagadnienie spędza sen z powiek. Dlatego też poniżej postanowiłem opisać najdokładniej jak umiem proces jaki zachodzi przy przesyłaniu danych z jednego punktu sieciowego na drugi. Bez zaprzęgnięcia sniffera sieciowego raczej nie da się zrozumieć tego tematu i poniższy przykład zawiera szereg odwołań do programu wireshark.

Flagi TCP i przełączanie stanów połączeń

Mikhail Morfikov — Wed, 24 Jun 2015 21:44:42 +0000

Jakiś czas temu opisywałem jak zaprojektować swój własny firewall, wobec czego postanowiłem nieco bardziej pochylić się nad zagadnieniem stanów połączeń i je dokładniej przeanalizować. Ten wpis dotyczy głównie protokołu TCP, bo ten UDP jest bezpołączeniowy, więc nie ma tam żadnych stanów. Dodatkowo opiszę tutaj poszczególne flagi, które mogą zostać ustawione w pakietach zmieniając tym samym stan połączenia.