Wzmacnianie VPN w Windows: najpierw popraw uwierzytelnianie, potem tunel

Twój serwer VPN w Windows prosi o nazwę użytkownika i hasło, a ten jeden dialog ukrywa trzy niezależne zadania. Jedno dowodzi, kim jest osoba, jedno nie pozwala komuś, kto obserwuje łącze, użyć tego dowodu ponownie, a jedno decyduje, do których adresów może potem dotrzeć. Większość małych wdrożeń najpierw wzmacnia tunel, a pierwsze dwa zadania zostawia na wartościach domyślnych, i to jest zła kolejność.

Pracuj w kolejności, w jakiej pracuje atakujący. Najpierw to, co można przechwycić z łącza. Potem to, co można później odtworzyć z tym nagraniem. Na końcu to, do czego uwierzytelniony atakujący może dotrzeć, gdy już jest w środku.

Trzy zadania, jeden dialog

Tożsamość to część, o której myślą ludzie, i stanowi tylko jedną trzecią problemu. Dowód tożsamości musi przetrwać obserwatora, który nagrywa wymianę i później próbuje ponownie. Autoryzacja to osobna decyzja, którą serwer podejmuje po ustaleniu tożsamości, a Windows trzyma ją w innej usłudze niż ta, która weryfikuje poświadczenia.

Gdy wszystkie trzy mieszkają w jednym mentalnym wiadrze, zwykłym wynikiem jest serwer, który mocno uwierzytelnia, a potem pozwala użytkownikowi dotrzeć do wszystkiego. Naprawienie tego później jest trudniejsze niż ustalenie polityki teraz, bo do tego czasu profil zapory, pula adresów i trasy kodują już stare założenie.

Rozdziel trzy rzeczy w notatkach, zanim dotkniesz jakiegokolwiek ustawienia, a potem naprawiaj je od najsłabszego ogniwa w górę.

Dlaczego MS-CHAPv2 nie przechodzi testu odtwarzania

Jeśli serwer nadal akceptuje PPTP z MS-CHAPv2, tunel nie chroni hasła w żadnym istotnym sensie. Wyzwanie i odpowiedź można przechwycić i zaatakować offline, a w 2012 roku publiczna usługa łamania pokazała odzyskanie z takiego uścisku dłoni w około jeden dzień dla typowego hasła. Dłuższe i bardziej złożone hasło podnosi koszt; nie usuwa materiału, którego atakujący potrzebuje z sieci.

Potrzebujesz poświadczenia, którego nie można odtworzyć. EAP-TLS z certyfikatami klienta daje każdemu urządzeniu własną tożsamość i pozwala unieważnić dokładnie jedno urządzenie.

Wdrożenie certyfikatów to prawdziwa praca: prywatny CA, ścieżka unieważniania sprawdzana przez klientów i plan odnowień, który przetrwa rotację personelu. Traktuj tę pracę jako projekt, a nie jako przeszkodę między tobą a działającym tunelem. Zaplanuj na nią budżet tak, jak planowałbyś wymianę zapory. Współdzielone hasło jest tańsze tylko do pierwszego unieważnienia.

Klucz wstępnie współdzielony uwierzytelnia parę, nie osobę

L2TP/IPsec z kluczem wstępnie współdzielonym dowodzi, że dwie bramy znają ten sam sekret. Nie mówi nic o tym, który człowiek się łączy, i nie potrafi na tej warstwie odróżnić jednego pracownika od drugiego. Użyj długiej losowej wartości, znacznie powyżej dziesięciu znaków sugerowanych przez niektóre poradniki, bo kto przechwyci uścisk dłoni, może zaatakować klucz offline.

Każdy klient w tym profilu dzieli sekret, więc usunięcie jednej osoby oznacza rozdanie go wszystkim pozostałym. Utrzymuj osobny krok uwierzytelniania użytkownika nad sekretem na poziomie maszyny i przechodź na certyfikaty w miarę wzrostu liczby klientów. Klucz wstępnie współdzielony w połączeniu z MS-CHAPv2 to dwie słabe warstwy, a druga niweczy pierwszą.

Autoryzacja należy do Network Policy Server

NPS w Windows decyduje, kto może się połączyć, i robi to po tym, jak uwierzytelnianie już się powiodło. To rozdzielenie jest najbardziej użyteczną kontrolą wzmacniania w produkcie, a wiele wdrożeń pozostawia ją nietkniętą.

Używaj warunków zasad, które odzwierciedlają realne ograniczenia: przynależność do grupy, okno czasowe, w którym wsparcie ma personel, i stan urządzenia z kontroli kondycji. Dodaj drugi czynnik tam, gdzie dane uzasadniają tarcie, i pamiętaj, że zasada jest oceniana przy każdej próbie połączenia, co czyni ją żywą kontrolą, a nie dokumentem.

Rozliczanie RADIUS daje też jeden zapis, kto i kiedy się połączył. Ten dziennik to różnica między przeglądem incydentu a domysłem, i istnieje niezależnie od tego, czy ktoś go kiedyś przeczyta.

Ogranicz, do czego może dotrzeć udane logowanie

Adapter VPN powinien trafiać do profilu zapory, który dopuszcza usługi potrzebne jego roli, a nie całą podsieć. Kwestia routingu jest odrębna od filtrowania. Pełny tunel chroni urządzenie klienta i przepycha każdy bajt przez twoje łącze wyjściowe, natomiast tunel dzielony utrzymuje ruch lokalny lokalnie i wystawia urządzenie na dowolną sieć, w której się znajduje.

Żaden z tych wyborów nie jest domyślnym ustawieniem bezpieczeństwa. Oba trzeba zapisać obok profilu zapory, który zakładają.

Sprawdź ścieżki awarii

Przetestuj, co powinno się zepsuć: błędne hasło, wygasły certyfikat, unieważnione urządzenie, użytkownik spoza grupy. Każdy przypadek powinien zawieść w innym punkcie, a dziennik powinien powiedzieć, który to był. Uruchom zestaw najpierw na koncie testowym, a potem powtórz go dla rzeczywistego użytkownika. Odrzucenie, które bez powodu trafia do dziennika zdarzeń, warto naprawić znacznie wcześniej, niż będziesz potrzebować tego zapisu.

Następnie potwierdź, które porty są publikowane i dlaczego. PPTP potrzebuje TCP 1723 i GRE jako protokołu IP, a nie portu, IKEv2 potrzebuje UDP 500 i 4500, a L2TP potrzebuje UDP 1701 oraz IPsec. Wystawienie interfejsu zarządzania, żeby klient się połączył, nie jest naprawą, to drugi incydent czekający na odkrycie.

Na koniec zdecyduj, co serwer rejestruje i jak długo. Punkt końcowy bez historii uwierzytelniania nie potrafi odpowiedzieć na pierwsze pytanie po incydencie, a mianowicie, czy próba była kiedykolwiek autoryzowana.