OpenVPN auth-nocache: co się dzieje przy następnym logowaniu

Włącz auth-nocache, a ostrzeżenie o buforowaniu hasła znika, wraz z kopią danych logowania, którą OpenVPN trzymał na potrzeby następnego renegocjowania. To, czy stanie się to pytaniem, cichą ponowną próbą czy zerwanym tunelem, zależy od tego, skąd dane logowania pojawią się za drugim razem. Dlatego to porównanie form wdrożenia, a nie wyrok w sprawie tej opcji. Przeczytaj formę, którą naprawdę uruchamiasz, zanim zmienisz jakikolwiek profil.

Skąd musi pochodzić drugi zestaw danych logowania

OpenVPN stosuje auth-nocache do sekretów zbieranych przez auth-user-pass i askpass: po użyciu proces je odrzuca, zamiast trzymać je do następnego uzgadniania. Renegocjowanie przychodzi według zegara, domyślnie raz na godzinę, więc drugie żądanie przychodzi długo po tym, jak osoba, która wpisała hasło, już odeszła. Ta luka to cała historia. Przy włączonym buforowaniu klient odtwarza zapisaną kopię, nikogo nie pytając; przy wyłączonym musi znaleźć sekret gdzie indziej albo ponieść porażkę.

Więc wypisz każde miejsce, z którego sekret mógłby w tym momencie pochodzić, i bądź szczery co do tego, które z nich istnieją na hoście. Osoba przy terminalu, plik, który auth-user-pass lub askpass mogą odczytać, albo token sesji wydany przez serwer to trzy, które się tu liczą. Jeśli żadne z nich nie jest dostępne, renegocjowanie kończy się niepowodzeniem godzinę po zmianie, a nie w momencie, w którym jej dokonałeś.

Trzy formy, trzy punkty awarii

Klient biurkowy z osobą przed nim to łagodny przypadek: pytanie wraca, ktoś wpisuje hasło ponownie, a ceną jest uwaga. Usługa, kontener lub router uruchamiający OpenVPN bez terminala to trudny przypadek, bo nie ma komu odpowiedzieć, a połączenie, które kiedyś było ciche, teraz kończy tunel. Hybryda leży pomiędzy nimi i zachowuje się jak przypadek biurkowy, dopóki nie zniknie sesja, która mogła odpowiedzieć na pytanie. Nie dzieli ich to, czy zainstalowano GUI, ale to, czy w chwili renegocjowania istnieje źródło danych logowania.

Przypisz swoje wdrożenie do jednej z tych trzech form, zanim cokolwiek zmienisz, bo porada, którą znajdziesz w internecie, prawie zawsze jest pisana dla pierwszej. Zastosowanie odpowiedzi biurkowej do usługi bez terminala to sposób, w jaki tunel, który działał miesiącami, zaczyna padać co godzinę.

Dyrektywa czy flaga: wybierz jedno i wiedz, którego użyłeś

Wewnątrz profilu auth-nocache to osobna linia; w wywołaniu, które wprost nazywa profil, jest flagą w tym wierszu poleceń, a podręcznik OpenVPN wymienia obie formy. Obie robią to samo z zatrzymywaniem danych logowania i żadna nie dotyka typu interfejsu ani nie naprawia niepowiązanego ostrzeżenia w tym samym logu. Różnica to trwałość: flaga obejmuje tylko to uruchomienie, więc usługa uruchomiona ponownie z pliku unit lub skryptu opakowującego nie będzie jej miała, chyba że opakowanie też ją przekaże.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Zdecyduj, który artefakt posiada ustawienie, zmień je tam i nigdzie indziej. Profil edytowany na laptopie plus jednostka systemd, która nadpisuje go flagą, to para, która po restarcie daje sprzeczne zachowanie.

Plik danych logowania przenosi sekret, zamiast go usuwać

Wskazanie auth-user-pass na plik daje każdemu późniejszemu renegocjowaniu źródło i umieszcza hasło w miejscu, które przeżywa restarty. Zapytaj, kto może czytać ten plik, czy demon nadal może go czytać po zrzeczeniu się uprawnień i co się dzieje, gdy system plików jest zamontowany tylko do odczytu albo widok kontenera ukrywa ścieżkę. Sekret na dysku i sekret w pamięci to różne problemy, a rozwiązanie jednego zostawia drugie na miejscu. Rotacja to krok, który się pomija: hasło zmienione na serwerze, ale nie w pliku, daje awarię, którą czyta się jak błąd sieci.

Trzymaj plik w posiadaniu konta, które uruchamia demona, nieczytelny dla nikogo innego i poza kopiami zapasowymi, które opuszczają host. Opcja auth-gen-token po stronie serwera OpenVPN przekazuje klientowi token sesji po udanym logowaniu, co jest mniejszą rzeczą do zostawienia niż hasło konta. Zapisz krok rotacji obok pliku tak czy inaczej, bo plik zwykle żyje dłużej niż osoba, która go utworzyła.

Rozciąganie renegocjowania przesuwa koszt, nie usuwa go

Inna sugestia to podniesienie reneg-sec, aż pytanie będzie wystarczająco rzadkie, by je ignorować. To przepisuje harmonogram rotacji kluczy sesji i spycha ten sam problem danych logowania na późniejszy, mniej przewidywalny moment; nie tworzy źródła danych logowania. Polityki, która z jakiegoś powodu odnawia klucze według harmonogramu, nie należy łagodzić tylko po to, by uniknąć wpisania hasła.

Testuj ponowne połączenie, a nie sesję, w której siedzisz, bo żywa sesja niczego nie dowodzi. Zerwij tunel po stronie serwera albo uruchom ponownie usługę klienta i obserwuj, co robi następne renegocjowanie, gdy przy klawiaturze nikogo nie ma. Jeśli połączy się ponownie, nazwij mechanizm, który dostarczył sekret; jeśli nie, znalazłeś rzeczywisty koszt tej opcji na tym hoście. Każdy wynik daje odpowiedź, która obowiązuje podczas awarii, a nie taką, która obowiązywała podczas testów.

W zarządzanej flocie właściciel wdrożenia powinien umieć nazwać trzy rzeczy: skąd pochodzą dane logowania, gdzie są przechowywane i kto je rotuje. Jeśli którąkolwiek z tych odpowiedzi jest osoba, która skonfigurowała host, opcja nie jest tam jeszcze bezpieczna.