Czy dotyczy Cię CVE-2019-14899? Lista kontrolna dla jądra

Skaner oznacza CVE-2019-14899 na maszynie, która od lat korzysta z VPN, a pierwszym odruchem jest uznanie VPN za zepsuty. To zły schemat. Ujawniony problem dotyczy napastnika w sieci lokalnej ofiary, który wnioskuje o pewnych połączeniach TCP, a nie strony internetowej odszyfrowującej twój tunel.

Przejdź przez cztery kontrole poniżej po kolei. Każda albo zawęża problem, albo kończy dochodzenie.

Kontrola 1: czy biuletyn obejmuje twoje jądro

Sprawdź własny wpis swojej dystrybucji, a nie streszczenie daty wydania z bloga. Strona bezpieczeństwa Ubuntu dla tej CVE wymienia ogólny pakiet linux dla 18.04 LTS jako podatny z odroczoną poprawką i śledzi inne pakiety jądra w osobnych wierszach. Dopasuj działające wydanie i pakiet jądra do właściwego wiersza. Znajomo wyglądający numer wersji nie jest dopasowaniem.

Wynik skanera oznacza, że identyfikator dotyczy czegoś w twoim spisie. Nie oznacza, że sąsiednie urządzenie wykorzystało maszynę.

Kontrola 2: kto jest napastnikiem w modelu

Model zagrożeń zakłada sąsiedniego napastnika, który może oddziaływać na sieć dostępową ofiary. To konkretna pozycja, a nie dowolna usługa zdalna, której nie podoba się twój węzeł wyjściowy. Jeśli użytkownicy łączą się z kawiarni, założenie jest realistyczne; jeśli siedzą za zarządzaną siecią firmową, to inna rozmowa.

Zostaw otwarte pytanie o zaufanie do sieci lokalnej, nawet gdy tunel jest szyfrowany. Szyfrowanie odpowiada na inne pytanie niż sąsiedztwo.

Kontrola 3: na której warstwie polegasz

Poprawnie zweryfikowany HTTPS zapewnia własną ochronę rekordów aplikacji, a TLS 1.3 uwierzytelnia te dane od końca do końca. Nie obiecuje jednak, że napastnik nie może przerwać podstawowego połączenia TCP. Aplikacja może więc być bezpieczna do czytania, a mimo to przerywalna, a przerwanie nie jest tym samym wynikiem co ujawnienie. Rozdziel oba, zanim ocenisz ryzyko.

To rozróżnienie ma znaczenie dla raportu. Zamienia mgliste twierdzenie, że VPN jest niebezpieczny, w ograniczone stwierdzenie o tym, co sąsiedni napastnik mógł zaobserwować lub przerwać.

Kontrola 4: jakie ograniczenie faktycznie wdrożyłeś

Ujawnienie omawia ograniczenia routingu i filtrowania i jest wyraźne co do ich granic, w tym filtrowania odwrotnej ścieżki i tras asymetrycznych. Nie przyklejaj jednej wartości sysctl na każdym hoście VPN i nie mów, że naprawione. Filtrowanie odwrotnej ścieżki współdziała z routingiem, więc wartość pomagająca jednej topologii może zepsuć inną.

Weryfikacja to polecenie, a nie pole wyboru. sysctl net.ipv4.conf.all.rp_filter pokazuje wartość globalną, a sysctl net.ipv4.conf.tun0.rp_filter pokazuje wartość na interfejsie, która faktycznie obowiązuje. Przeczytaj obie przed i po każdej zmianie.

Użyj wskazówek dystrybucji i własnego projektu routingu, a następnie potwierdź ustawienie na interfejsie, który przenosi tunel, a nie w pliku, którego nikt nie wczytał.

Co zapisać

Zapisz założenie o sąsiednim napastniku, działający pakiet jądra, dopasowany wiersz biuletynu, wdrożone ograniczenie i miejsce jego zastosowania oraz istniejące zabezpieczenia aplikacji. Dodaj datę sprawdzenia biuletynu, bo te strony się zmieniają. Taka kombinacja to obronna ocena.

Data wydania systemu i działające połączenie VPN nie są oceną. To dwa fakty, które przypadkiem łatwo zebrać.