Cześć wszystkim! Nazywam się Dmitry Samsonov, pracuję jako wiodący administrator systemu w Odnoklassnikach. Mamy ponad 7 tysięcy serwerów fizycznych, 11 tysięcy kontenerów w naszej chmurze i 200 aplikacji, które w różnych konfiguracjach tworzą 700 różnych klastrów. Zdecydowana większość serwerów obsługuje CentOS 7.
14 sierpnia 2018 roku została opublikowana informacja o podatności FragmentSmack
() i SegmentSmack (). Są to luki o wektorze ataku sieciowego i dość wysokim wyniku (7.5), które grożą odmową usługi (DoS) z powodu wyczerpania zasobów (CPU). Nie zaproponowano wówczas poprawki jądra dla FragmentSmacka, a ponadto pojawiła się znacznie później niż publikacja informacji o luce. Aby wyeliminować SegmentSmack, zasugerowano aktualizację jądra. Sam pakiet aktualizacji został wydany tego samego dnia, pozostało tylko go zainstalować.
Nie, wcale nie jesteśmy przeciwni aktualizacji jądra! Są jednak niuanse...
Jak aktualizujemy jądro na produkcji
Ogólnie rzecz biorąc, nic skomplikowanego:
- Pobierz pakiety;
- Zainstaluj je na wielu serwerach (w tym na serwerach hostujących naszą chmurę);
- Upewnij się, że nic nie jest zepsute;
- Upewnij się, że wszystkie standardowe ustawienia jądra zostały zastosowane bez błędów;
- Poczekaj kilka dni;
- Sprawdź wydajność serwera;
- Przełącz wdrażanie nowych serwerów na nowe jądro;
- Aktualizuj wszystkie serwery według centrum danych (po jednym centrum danych na raz, aby zminimalizować wpływ problemów na użytkowników);
- Zrestartuj wszystkie serwery.
Powtórz tę czynność dla wszystkich gałęzi jąder, które mamy. W tej chwili jest to:
- Stock CentOS 7 3.10 - dla większości zwykłych serwerów;
- Wanilia 4.19 - dla nas , ponieważ potrzebujemy BFQ, BBR itp.;
- Elrepo kernel-ml 5.2 - dla , ponieważ wersja 4.19 zachowywała się niestabilnie, ale potrzebne są te same funkcje.
Jak można się domyślić, ponowne uruchomienie tysięcy serwerów zajmuje najwięcej czasu. Ponieważ nie wszystkie luki są krytyczne dla wszystkich serwerów, restartujemy tylko te, które są bezpośrednio dostępne z Internetu. W chmurze, aby nie ograniczać elastyczności, nie przywiązujemy dostępnych zewnętrznie kontenerów do poszczególnych serwerów nowym jądrem, ale restartujemy wszystkie hosty bez wyjątku. Na szczęście procedura jest tam prostsza niż w przypadku zwykłych serwerów. Na przykład kontenery bezstanowe można po prostu przenieść na inny serwer podczas ponownego uruchamiania.
Pracy jest jednak jeszcze sporo i może to zająć kilka tygodni, a w przypadku problemów z nową wersją nawet kilka miesięcy. Atakujący doskonale to rozumieją, dlatego potrzebują planu B.
FragmentSmack/SegmentSmack. Obejście
Na szczęście dla niektórych luk istnieje plan B i nazywa się to obejściem. Najczęściej jest to zmiana ustawień jądra/aplikacji, która może zminimalizować możliwy efekt lub całkowicie wyeliminować wykorzystanie luk.
W przypadku FragmentSmack/SegmentSmack to obejście:
«Możesz zmienić domyślne wartości 4MB i 3MB w net.ipv4.ipfrag_high_thresh i net.ipv4.ipfrag_low_thresh (oraz ich odpowiedniki dla ipv6 net.ipv6.ipfrag_high_thresh i net.ipv6.ipfrag_low_thresh) odpowiednio na 256 kB i 192 kB lub niżej. Testy wykazują od małych do znaczących spadków użycia procesora podczas ataku, w zależności od sprzętu, ustawień i warunków. Jednak ipfrag_high_thresh=262144 bajtów może mieć pewien wpływ na wydajność, ponieważ w kolejce ponownego składania jednocześnie mogą zmieścić się tylko dwa fragmenty o wielkości 64 KB. Na przykład istnieje ryzyko, że aplikacje współpracujące z dużymi pakietami UDP ulegną awarii".
Same parametry opisane w następujący sposób:
ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.
ipfrag_low_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
Nie mamy dużych UDP w usługach produkcyjnych. W sieci LAN nie ma fragmentarycznego ruchu, w sieci WAN występuje fragmentacja, ale nie jest ona znacząca. Nie ma żadnych znaków – możesz wdrożyć obejście!
FragmentSmack/SegmentSmack. Pierwsza krew
Pierwszym problemem, jaki napotkaliśmy, było to, że kontenery chmurowe czasami stosowały nowe ustawienia tylko częściowo (tylko ipfrag_low_thresh), a czasami w ogóle ich nie stosowały - po prostu zawieszały się na starcie. Nie udało się odtworzyć problemu w stabilny sposób (wszystkie ustawienia zostały zastosowane ręcznie bez żadnych trudności). Zrozumienie, dlaczego kontener ulega awarii na początku, również nie jest takie proste: nie znaleziono żadnych błędów. Jedno było pewne: przywrócenie ustawień rozwiązuje problem awarii kontenerów.
Dlaczego nie wystarczy zastosować Sysctl na hoście? Przynajmniej kontener żyje we własnej, dedykowanej przestrzeni nazw sieci w kontenerze może różnić się od hosta.
Jak dokładnie stosowane są ustawienia Sysctl w kontenerze? Ponieważ nasze kontenery są nieuprzywilejowane, nie będziesz mógł zmienić żadnego ustawienia Sysctl, przechodząc do samego kontenera - po prostu nie masz wystarczających uprawnień. Do uruchamiania kontenerów nasza chmura korzystała wówczas z Dockera (obecnie ). Parametry nowego kontenera zostały przekazane do Dockera poprzez API, łącznie z niezbędnymi ustawieniami Sysctl.
Przeglądając wersje okazało się, że Docker API nie zwróciło wszystkich błędów (przynajmniej w wersji 1.10). Kiedy próbowaliśmy uruchomić kontener za pomocą „uruchamiania okna dokowanego”, w końcu zobaczyliśmy przynajmniej coś:
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.
Wartość parametru jest nieprawidłowa. Ale dlaczego? A dlaczego nie jest to ważne tylko czasami? Okazało się, że Docker nie gwarantuje kolejności stosowania parametrów Sysctl (najnowsza testowana wersja to 1.13.1), więc czasem ipfrag_high_thresh próbowało ustawić na 256K, gdy ipfrag_low_thresh wynosiło jeszcze 3M, czyli górny limit był niższy niż dolna granica, co doprowadziło do błędu.
W tamtym czasie korzystaliśmy już z własnego mechanizmu rekonfiguracji kontenera po uruchomieniu (zamrożenie kontenera po i wykonywanie poleceń w przestrzeni nazw kontenera poprzez ), a do tej części dodaliśmy także pisanie parametrów Sysctl. Problem został rozwiązany.
FragmentSmack/SegmentSmack. Pierwsza krew 2
Zanim zdążyliśmy zrozumieć zastosowanie rozwiązania w chmurze, zaczęły napływać pierwsze rzadkie skargi od użytkowników. W tym czasie minęło kilka tygodni od rozpoczęcia stosowania Workaround na pierwszych serwerach. Wstępne dochodzenie wykazało, że otrzymano skargi dotyczące poszczególnych usług, a nie wszystkich serwerów tych usług. Problem znów stał się niezwykle niepewny.
Przede wszystkim próbowaliśmy oczywiście przywrócić ustawienia Sysctl, ale nie przyniosło to żadnego efektu. Nie pomogły też różne manipulacje ustawieniami serwera i aplikacji. Ponowne uruchomienie pomogło. Ponowne uruchomienie Linuksa jest tak samo nienaturalne, jak w dawnych czasach było normalne w systemie Windows. Jednak pomogło i przypisaliśmy to „usterce jądra” podczas stosowania nowych ustawień w Sysctl. Jakie to było niepoważne...
Po trzech tygodniach problem powrócił. Konfiguracja tych serwerów była dość prosta: Nginx w trybie proxy/balancera. Niewielki ruch. Nowa uwaga wstępna: liczba błędów 504 na klientach rośnie z każdym dniem (). Wykres pokazuje liczbę 504 błędów dziennie dla tej usługi:
Wszystkie błędy dotyczą tego samego backendu - mniej więcej tego, który znajduje się w chmurze. Wykres zużycia pamięci dla fragmentów pakietów na tym backendzie wyglądał następująco:
Jest to jeden z najbardziej oczywistych przejawów problemu na wykresach systemu operacyjnego. W chmurze w tym samym czasie został naprawiony kolejny problem sieciowy z ustawieniami QoS (Traffic Control). Na wykresie zużycia pamięci dla fragmentów pakietów wyglądało to dokładnie tak samo:
Założenie było proste: jeśli na wykresach wyglądają tak samo, to mają ten sam powód. Co więcej, jakiekolwiek problemy z tego typu pamięcią są niezwykle rzadkie.
Istotą rozwiązanego problemu było to, że użyliśmy harmonogramu pakietów fq z domyślnymi ustawieniami QoS. Domyślnie dla jednego połączenia pozwala na dodanie do kolejki 100 pakietów, a niektóre połączenia w sytuacjach braku kanału zaczęły zapychać kolejkę do granic możliwości. W takim przypadku pakiety są odrzucane. W statystykach tc (tc -s qdisc) można to zobaczyć w następujący sposób:
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
„464545 flows_plimit” to pakiety odrzucone z powodu przekroczenia limitu kolejki jednego połączenia, a „dropped 464545” to suma wszystkich odrzuconych pakietów tego harmonogramu. Po zwiększeniu długości kolejki do 1 tys. i ponownym uruchomieniu kontenerów problem ustał. Możesz usiąść i napić się smoothie.
FragmentSmack/SegmentSmack. Ostatnia krew
Po pierwsze, kilka miesięcy po ogłoszeniu luk w jądrze, w końcu pojawiła się poprawka dla FragmentSmacka (przypomnę, że wraz z zapowiedzią w sierpniu wypuszczono poprawkę tylko dla SegmentSmack), która dała nam szansę na porzucenie Obejścia, co sprawiło nam sporo kłopotów. W tym czasie udało nam się już przenieść część serwerów na nowe jądro i teraz trzeba było zaczynać od początku. Dlaczego zaktualizowaliśmy jądro bez czekania na poprawkę FragmentSmack? Faktem jest, że proces ochrony przed tymi lukami zbiegł się (i połączył) z procesem aktualizacji samego CentOS (co zajmuje jeszcze więcej czasu niż aktualizacja samego jądra). Ponadto SegmentSmack jest bardziej niebezpieczną luką i poprawka na nią pojawiła się natychmiast, więc i tak miało to sens. Nie mogliśmy jednak po prostu zaktualizować jądra w CentOS, ponieważ luka FragmentSmack, która pojawiła się w CentOS 7.5, została naprawiona dopiero w wersji 7.6, więc musieliśmy zatrzymać aktualizację do 7.5 i zacząć wszystko od nowa z aktualizacją do 7.6. I to też się zdarza.
Po drugie, wróciły do nas rzadkie skargi użytkowników dotyczące problemów. Teraz już wiemy na pewno, że wszystkie one mają związek z przesyłaniem plików od klientów na część naszych serwerów. Co więcej, przez te serwery przeszła bardzo niewielka liczba przesłanych plików z całej masy.
Jak pamiętamy z powyższej historii, przywrócenie Sysctl nie pomogło. Restart pomógł, ale chwilowo.
Podejrzenia dotyczące Sysctl nie zostały usunięte, jednak tym razem konieczne było zebranie jak największej ilości informacji. Wystąpił również ogromny brak możliwości odtworzenia problemu z przesyłaniem na kliencie, aby dokładniej zbadać, co się dzieje.
Analiza wszystkich dostępnych statystyk i logów nie przybliżyła nas ani trochę do zrozumienia co się dzieje. Wystąpił dotkliwy brak możliwości odtworzenia problemu, aby „poczuć” określone połączenie. Wreszcie twórcom, korzystając ze specjalnej wersji aplikacji, udało się uzyskać stabilną reprodukcję problemów na urządzeniu testowym po podłączeniu przez Wi-Fi. To był przełom w śledztwie. Klient połączył się z Nginxem, który pośredniczył do backendu, którym była nasza aplikacja Java.
Dialog dotyczący problemów wyglądał następująco (naprawiony po stronie proxy Nginx):
- Klient: żądanie otrzymania informacji o pobraniu pliku.
- Serwer Java: odpowiedź.
- Klient: POST z plikiem.
- Serwer Java: błąd.
Jednocześnie serwer Java zapisuje do logu, że od klienta odebrano 0 bajtów danych, a proxy Nginx zapisuje, że żądanie trwało ponad 30 sekund (30 sekund to limit czasu aplikacji klienckiej). Dlaczego przekroczono limit czasu i dlaczego 0 bajtów? Z perspektywy HTTP wszystko działa jak należy, jednak POST z plikiem zdaje się znikać z sieci. Co więcej, znika pomiędzy klientem a Nginx. Czas uzbroić się w Tcpdump! Ale najpierw musisz zrozumieć konfigurację sieci. Serwer proxy Nginx stoi za balanserem L3 . Tunelowanie służy do dostarczania pakietów z balansera L3 do serwera, który dodaje do pakietów swoje nagłówki:
W tym przypadku sieć przychodzi do tego serwera w postaci ruchu oznaczonego Vlanem, który również dodaje do pakietów własne pola:
A ten ruch również może zostać pofragmentowany (ten sam niewielki procent przychodzącego fragmentarycznego ruchu, o którym mówiliśmy przy ocenie ryzyka z Obejścia), co również zmienia treść nagłówków:
Jeszcze raz: pakiety są hermetyzowane tagiem Vlan, kapsułkowane tunelem, pofragmentowane. Aby lepiej zrozumieć, jak to się dzieje, prześledźmy trasę pakietu od klienta do proxy Nginx.
- Pakiet dociera do balansera L3. W celu prawidłowego routingu w centrum danych pakiet jest kapsułkowany w tunelu i wysyłany do karty sieciowej.
- Ponieważ nagłówki pakietu + tunelu nie mieszczą się w MTU, pakiet jest dzielony na fragmenty i wysyłany do sieci.
- Przełącznik za balanserem L3 po odebraniu pakietu dodaje do niego znacznik Vlan i wysyła go dalej.
- Przełącznik znajdujący się przed serwerem proxy Nginx widzi (na podstawie ustawień portu), że serwer oczekuje pakietu kapsułkowanego w sieci Vlan, więc wysyła go w niezmienionej postaci, bez usuwania znacznika Vlan.
- Linux pobiera fragmenty poszczególnych pakietów i łączy je w jeden duży pakiet.
- Następnie pakiet dociera do interfejsu Vlan, gdzie zostaje z niego usunięta pierwsza warstwa – enkapsulacja Vlan.
- Linux następnie wysyła go do interfejsu Tunnel, gdzie usuwana jest z niego kolejna warstwa – Hermetyzacja tunelu.
Trudność polega na przekazaniu tego wszystkiego jako parametrów do tcpdump.
Zacznijmy od końca: czy są czyste (bez zbędnych nagłówków) pakiety IP od klientów, z usuniętą enkapsulacją vlan i tunelem?
tcpdump host <ip клиента>
Nie, na serwerze nie było takich pakietów. Zatem problem musi pojawić się wcześniej. Czy są jakieś pakiety, w których usunięto tylko enkapsulację Vlan?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx to adres IP klienta w formacie szesnastkowym.
32:4 — adres i długość pola, w którym w pakiecie tunelowym zapisywany jest adres IP SCR.
Adres pola trzeba było wybrać brutalną siłą, ponieważ w Internecie piszą o 40, 44, 50, 54, ale tam nie było adresu IP. Możesz także spojrzeć na jeden z pakietów w formacie szesnastkowym (parametr -xx lub -XX w tcpdump) i obliczyć znany adres IP.
Czy zostały usunięte fragmenty pakietów bez enkapsulacji Vlan i tunelu?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Ta magia pokaże nam wszystkie fragmenty, łącznie z ostatnim. Prawdopodobnie to samo można filtrować według adresu IP, ale nie próbowałem, ponieważ takich pakietów nie jest zbyt wiele, a te, których potrzebowałem, można było łatwo znaleźć w ogólnym przepływie. Tutaj są:
14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........
14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............
Są to dwa fragmenty jednej paczki (ten sam nr ID 53652) ze zdjęciem (na pierwszej paczce widnieje napis Exif). Z uwagi na to, że na tym poziomie znajdują się pakiety, ale nie w formie scalonej na zrzutach, problem ewidentnie leży po stronie asemblera. Wreszcie mamy na to dokumentalny dowód!
Dekoder pakietów nie wykrył żadnych problemów, które uniemożliwiałyby kompilację. Próbowałem tutaj: . Na początku, gdy próbujesz coś tam upchnąć, dekoderowi nie podoba się format pakietu. Okazało się, że pomiędzy Srcmac i Ethertype istnieją dodatkowe dwa oktety (niezwiązane z informacją o fragmentach). Po ich usunięciu dekoder zaczął działać. Nie wykazało jednak żadnych problemów.
Cokolwiek można powiedzieć, nie znaleziono nic innego poza tymi Sysctl. Pozostało tylko znaleźć sposób na identyfikację problematycznych serwerów, aby zrozumieć skalę i podjąć decyzję o dalszych działaniach. Wymagany licznik został znaleziony wystarczająco szybko:
netstat -s | grep "packet reassembles failed”
Jest również w snmpd pod OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
„Liczba błędów wykrytych przez algorytm ponownego składania protokołu IP (z dowolnej przyczyny: przekroczenie limitu czasu, błędy itp.).”
Spośród grupy serwerów, na których badano problem, na dwóch licznik ten rósł szybciej, na dwóch wolniej, a na dwóch w ogóle nie rósł. Porównanie dynamiki tego licznika z dynamiką błędów HTTP na serwerze Java ujawniło korelację. Oznacza to, że licznik mógłby być monitorowany.
Posiadanie wiarygodnego wskaźnika problemów jest bardzo ważne, abyś mógł dokładnie określić, czy przywrócenie Sysctl pomoże, ponieważ z poprzedniej historii wiemy, że nie można tego od razu zrozumieć z aplikacji. Wskaźnik ten pozwoliłby nam zidentyfikować wszystkie problematyczne obszary w produkcji, zanim użytkownicy je odkryją.
Po przywróceniu Sysctl błędy monitorowania ustały, co potwierdziło przyczynę problemów i fakt, że wycofanie pomogło.
Cofnęliśmy ustawienia fragmentacji na innych serwerach, gdzie wszedł w grę nowy monitoring i gdzieś przydzieliliśmy jeszcze więcej pamięci na fragmenty niż było wcześniej domyślnie (były to statystyki UDP, których częściowa utrata nie była zauważalna na ogólnym tle) .
Najważniejsze pytania
Dlaczego pakiety są fragmentowane w naszym balanserze L3? Większość pakietów przychodzących od użytkowników do systemów równoważących to SYN i ACK. Rozmiary tych opakowań są niewielkie. Ponieważ jednak udział takich pakietów jest bardzo duży, na ich tle nie zauważyliśmy obecności dużych pakietów, które zaczęły się fragmentować.
Powodem był uszkodzony skrypt konfiguracyjny na serwerach z interfejsami Vlan (w tamtym czasie w produkcji było bardzo mało serwerów z ruchem tagowanym). Advmss pozwala nam przekazać klientowi informację, że pakiety w naszym kierunku powinny być mniejsze, aby po dołączeniu do nich nagłówków tunelu nie musiały ulegać fragmentacji.
Dlaczego wycofanie Sysctl nie pomogło, ale ponowne uruchomienie pomogło? Wycofywanie Sysctl zmieniło ilość pamięci dostępnej do łączenia pakietów. Jednocześnie najwyraźniej sam fakt przepełnienia pamięci fragmentami powodował spowolnienie połączeń, co skutkowało długim opóźnieniem fragmentów w kolejce. Oznacza to, że proces przebiegał cyklicznie.
Ponowne uruchomienie wyczyściło pamięć i wszystko wróciło do porządku.
Czy można było obejść się bez rozwiązania problemu? Tak, ale istnieje duże ryzyko pozostawienia użytkowników bez obsługi w przypadku ataku. Oczywiście zastosowanie Obejścia spowodowało różne problemy, w tym spowolnienie jednej z usług dla użytkowników, ale mimo to uważamy, że podjęte działania były uzasadnione.
Wielkie dzięki dla Andrieja Timofiejewa () o pomoc w prowadzeniu śledztwa, a także Aleksieja Krenewa () - za tytaniczną pracę polegającą na aktualizacji Centosu i jąder na serwerach. Procesu, który w tym przypadku trzeba było rozpoczynać kilkukrotnie od początku, przez co ciągnął się wiele miesięcy.
Źródło: www.habr.com