Więcej miejsc do posłuchania:
WERSJA TEKSTOWA
Cześć. Witam Cię w dzisiejszym odcinku. Temat dzisiejszy to fragmentacja pakietów IP, TCP i UDP. Zacznijmy od tego po co jest w ogóle takie zjawisko czy hasło jak fragmentacja. Jeśli chodzi o sieci Ethernetowe, założenie jest takie, że maksymalna wielkość ramki, czyli to co się mieści w ramce Ethernetowej a mówimy tu dzisiaj głównie o umieszczeniu pakietu IP w ramce Ethernetowej, to że wielkość tego pakietu IP w ramach ramki nie przekroczy 1500 b. Tak mówi standard dotyczący ramki Ethernetowej i jeśli chcemy się go trzymać i urządzenia, które mają pracować w ramach tego standardu mają spełniać minimalnie przekazywanie ramek o takiej wielkości.
Czy można przekazywać ramki większe? Można. Są urządzenia, które to wspierają natomiast jest to już rozwiązanie odbiegające od standardu. Czyli jeżeli dany producent urządzenia włączył taką funkcję (domyślnie lub jako opcję), najczęściej nazywa się ona Jumbo Frame, to możemy przekazywać dużo większą ramkę. Jumbo Frame są najczęściej powyżej 9 000 bajtów. Więc jeśli mamy aplikacje, które przesyłają dużą ilość danych, które lepiej będą przenoszone w dużych ramkach, to wykorzystanie tych Jumbo Frame będzie korzystne. Przykład? Przesyłanie video jest takim elementem, który bardzo dobrze może być przesyłany z wykorzystaniem większych ramek. Wtedy po prostu wydajność procesora, który przetwarza nagłówki dla danych pakietów są mniejsze wymagania procesora, albo większa wydajność, w zależności od tego na co stawiamy. Oczywiście wydajność versus cena to jest coś co ze sobą konkuruje. W przypadku gdy chcemy mieć większą wydajność to oczywiście najczęściej musimy zapłacić więcej za dane rozwiązanie. W związku z tym optymalizacja tej wielkości ramki jest dość istotna.
Czy to jest coś na co mamy wpływ jako administratorzy? Najczęściej nie. Dlatego, że wielkość ramki, czyli wielkość tego payload-u, który w ramkach jest umieszczany jest najczęściej określana przez programistów danej aplikacji. Czyli aplikacja powinna odpowiednio wykorzystywać mechanizm pakowania tych danych w ramki. Dobrą praktyką, taką rekomendacją jest utrzymywanie ilości danych w ramach jednej takiej paczki na poziomie 573 bajtów, ale nie jest to coś, co jest zestandaryzowane i zależy tutaj od danego programisty czy dana aplikacja będzie używać większych ramek. Jeżeli mamy aplikację, która używa załóżmy takiej ramki, która się mieści maksymalnie pod ten limit związany ze standardowym payload-em, czyli standardową wielkością pakietu, to nam to wszystko działa. Jednak z punktu widzenia administratora sieciowego problem się pojawia w momencie, kiedy zaczynamy taki pakiet, maksymalny wg standardu, przekazywać do tunelu. Tunel, np VXLAN, IPsec i inne typu tunelów, wszystko co jest dodatkowo opakowywane dokłada swój nagłówek, czyli takie tunelowanie protokołu powoduje, że do każdego pakietu dokładany jest dodatkowy nakład iluś bajtów, w zależności od protokołu, jako nagłówek. Oznacza to też, że jeżeli mamy z punktu widzenia aplikacji, maksymalną dozwoloną wielkość umieszczaną w pakiecie i ten pakiet jest następnie umieszczany (próba umieszczenia) w jakimś tunelu, to dodatkowe dane są dodawane i może się okazać, że taki pakiet, który jest przekazywany do kolejnego urządzenia sieciowego, przekracza 1500 bajtów nie będzie zaakceptowany przez następne urządzenie sieciowe.
Co się wtedy dzieje? Wtedy może zadziać się jedna z dwóch rzeczy. To urządzenie, które nie akceptuje większych ramek może pofragmentować pakiet lub opcja druga – może go po prostu odrzucić, najczęściej ze zwrotną informacją ICMP, czyli protokołu sieciowego diagnostycznego, że ten Payloud, ta ramka, była za duża do obsłużenia na tym urządzeniu. Jeżeli chodzi o możliwości oznaczenia tych zdarzeń to mamy tutaj takie dwie flagi, które w pakiecie IP mogą występować, czyli: DF – Don’t Fragment – to jest flaga, która mówi, że jeżeli pakiet jest przekazywany i urządzenie chciałoby pofragmentować, czyli podzielić ten jeden fragment na więcej mniejszych to nie powinno tego zrobić, jeśli flaga DF jest ustawiona. Natomiast, gdy dane urządzenie sieciowe pofragmentuje ten pakiet, czyli podzieli go na więcej mniejszych, to dla tych mniejszych pakietów ustawi flagę, że jest to pakiet pofragmentowany i będzie oznaczony jako MO fragments. Dzięki temu, kolejne urządzenie, które otrzymuje takie sfragmentowane pakiety wie, że to jest jeden z elementów a może się ich spodziewać więcej, które z kolei powinny być złożone w jeden pakiet. Taki jest scenariusz, jeśli chodzi o koncepcję oznaczania i fragmentowania.
W przypadku określania wielkości pakietów to na różnych poziomach to określenie ma różne nazwy. Pakiet IP – tu posługujemy się nazwą MTU – Maximum Transmission Unit, natomiast z poziomu TCP mówimy o MSS – Maximum Segment Size. Czyli mówimy o tym, że na poziomie pakietu TCP maksymalna wielkość danych umieszonych w payloudzie samym, nie licząc nagłówka, to jest ten parametr MSS. Natomiast mówiąc o pakiecie IP (MTU) to jest całość pakietu razem z nagłówkami IP, w całości określane jako MTU. To jest coś, co jest wkładane później do ramki Ethernetowej.
W sytuacji, gdy przechodzi nam pakiet do danego urządzenia, tym razem niech to będzie pakiet UDP, co ten kolejny router ma z tym pakietem zrobić, jeżeli nie może przekazać tak dużej ramki? Może wykonać dwie wymienione wcześniej akcje, tj pofragmentować, wysłać dalej lub odrzucić i odesłać informację zwrotną po ICMP. Jednak w przypadku protokołu UDP, jest to protokół nie sesyjny, czyli łatwiej jest i nie musimy w zasadzie się o to martwić, że na poziomie UDP pakiety zostaną pofragmentowane i wysłane dalej. Oczywiście jest tutaj pewien haczyk tzn jeśli fragmentujemy pakiety i wysyłamy je w sieć to ta sieć może mieć różną jakość i gdy się zdarzy tak, że nam ta sieć będzie powodowała przychodzenie pakietów pofragmentowanych w różnej kolejności, to urządzenie musi w jakiś sposób sobie z tym poradzić. Tu w zależności od implementacji również aplikacja czasem będzie musiała mieć jakiś mechanizm, który sobie z tym poradzi. W przypadku protokołu UDP nie ma na poziomie protokołu żadnych mechanizmów retransmisji, sprawdzania kolejności, w związku z tym to na poziomie aplikacyjnym musiałoby być zastosowane. Natomiast jeśli chodzi o TCP, tutaj jak wspomniałem mamy poziom IP i TCP i różnej wielkości tego payload-u, który ze sobą jest skorelowany. Jak mamy większą ilość danych w pakiecie TCP i on jest potem wkładany jako payload do tego pakietu IP, to automatycznie pakiet IP jest większy o te nagłówki, ale jest skorelowany z wielkością TCP.
Jeślibyśmy chcieli konfigurować na urządzeniu sieciowym jak ma fragmentować pakiety i mówimy o sesji TCP, to powinniśmy mieć skorelowane to dzielenie payload-u na poziomie protokołu TCP, który jest potem enkapsulowany, czyli wkładany do pakietu IP. Dzięki temu będziemy mieli spójność tej komunikacji. Jest to o tyle istotne, że te pakiety TCP są protokołem połączeniowym w związku z tym cała sekwencja musi przejść potwierdzenie, że dana grupa pakietów przeszła i jest prawidłowa, ewentualnie żądanie o retransmisję. W związku z tym, jeżeli fragmentujemy to to musi być ze sobą uwzględnione. Tu mówimy nadal o poziomie takiej implementacji, czyli raczej nie będzie to zadanie administratora, natomiast dobrze jest wiedzieć z punktu widzenia administracyjnego jak cały mechanizm działa i czego się można spodziewać.
Jest jeszcze jeden element, jeżeli chodzi o fragmentowanie pakietów. To jest też jeden z elementów, który jest wykonywany dość często do próby ominięcia zabezpieczeń. Gdy wyobrazisz sobie taką sytuację, że masz urządzenie bezpieczeństwa, które analizuje pakiety w locie. Czyli mówimy tu o urządzeniu typu IPS – Intrusion Prevention System. To urządzenie stara się złożyć z poszczególnych pakietów sesję TCP i sesję aplikacyjną, tak żeby móc ją przeanalizować. Jeżeli dane rozwiązanie czy atak jest przeprowadzony w taki sposób, że fragmentuje pakiety i próbuje jeszcze modyfikować w taki sposób tą fragmentację pakietów, żeby utrudnić analizowanie takiemu inline-owemu urządzeniu to to jest oczywiście podwyższanie poziomu trudności. A ponieważ te inline systemy bezpieczeństwa z założenia mają działać szybko, nie mają mieć ogromnych buforów, mają działać w sposób możliwie transparentny dla aplikacji, które są używane to fragmentowanie pakietów, ustawianie ich w różnej kolejności, wysyłanie w taki sposób, który jest trudny do przetworzenia. Może się okazać, że dane urządzenie bezpieczeństwa przepuści taki ruch. O to nam właśnie chodzi, jeżeli próbujemy zaatakować. Atakujący chcą wykorzystać tego typu właśnie ułomność systemów bezpieczeństwa. Jest to też jeden z elementów, które są czasem wykorzystywane. W przypadku jak chcielibyśmy z punktu widzenia aplikacji zapobiec takim zdarzeniom, to oczywiście do każdego pakietu, który jest stworzony powinna być dodawana flaga, że nie akceptujemy fragmentowania. Nadal mówimy tu o kwestii bardziej deweloperskiej, jak będziemy procesować dane pakiety dla naszej aplikacji i przez sieć, która służy za medium transmisyjne. Na dziś to tyle, dziękuję Ci za uwagę i do usłyszenia już za tydzień.
