Změna hesla VPN bez zamčení všech zařízení

Tři telefony, router a jedna kontrola monitoringu stále drží staré heslo a jeden z nich se každých devadesát sekund znovu připojuje. Heslo účtu bylo změněno před deseti minutami, takže každý z těchto klientů nyní posílá hodnotu, kterou server odmítá. To je okamžik, kdy mýtus praská: změna hesla se dotýká účtu, ne kopií staré hodnoty na každém zařízení. Následuje práce, kterou změna neudělala.

Mýtus: jedna změna, všude najednou

Přesvědčení je, že změna hesla odhlásí všechno a vynutí čisté nové přihlášení. Není to tak, protože server sleduje jen to, které přihlašovací údaje naposledy přijal, zatímco klienti si drží, co si uložili. Zařízení s uloženým heslem ho zkouší znovu podle svého rozvrhu a tiše selhává, dokud si někdo nevšimne, že je účet zamčený. Jakmile přijmete, že kopie žijí mimo účet, rotace přestane vypadat jako jediná akce.

Nic z toho není argument proti rotaci. Je to argument pro to brát uložené kopie jako součást změny, ne jako dodatečný nápad. Zamčení obvykle přichází z paralelních opakovaných pokusů: každé zařízení dál posílá starou hodnotu podle svého rozvrhu, dokud se nepřekročí počítadlo. Účet pak vypadá napadený, i když se mu jen nabízejí údaje, které nikdo nenahradil. Ten rozdíl je důležitý, protože řešením je seznam zařízení, ne přísnější politika zamykání.

Zmapujte kopie dřív, než začnete rotovat

Napište inventář dřív, než otevřete formulář hesla. Vypište každého klienta, skript, automatizaci a spravovaný profil, který se ověřuje jako tento účet: telefon, který se připojuje sám, router nastavený před dvěma lety, notebook, který se probouzí jen v pondělí, a kontrolu monitoringu, která to zkouší každou minutu. U každého poznamenejte, kde je údaj uložen, zda je zařízení během změny dosažitelné a jaká cesta obnovy existuje, když se nemůže znovu připojit. Právě tento seznam mění riskantní změnu v naplánovanou a musí existovat dřív, než staré heslo přestane fungovat.

Offline zařízení jsou klasické opomenutí. Notebook v šuplíku se vrátí o tři týdny později a předloží zastaralou hodnotu v nejhorší možný okamžik. Poznamenejte i jeho umístění a rozvrh, protože ho budete muset dohonit, ne na něj čekat.

V linuxové flotile je hledání mechanické, ne chytré. Hledejte profily, které odkazují na soubor s přihlašovacími údaji, pak samotné soubory údajů, protože druhý seznam je ten, který je třeba přepsat. Cvičení zopakujte pro stolní klienty a telefony, kde je úložištěm profil nebo položka v klíčence, ne cesta. Cílem je seznam, se kterým můžete pracovat, ne sken, který tvrdí, že najde každou kopii.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Porovnejte kopie s lidmi, kteří je vlastní. Zařízení, které si nikdo nenárokuje, je zařízení, které nikdo neaktualizuje, a zároveň to je to, které s největší pravděpodobností bude dál opakovat pokusy.

Které tajemství vlastně rotujete

Heslo účtu je jen jeden údaj v nasazení VPN. Přihlašovací fráze klíče, identita certifikátu a volitelné tajemství protějšku mají každé svou cestu nahrazení a svého vlastníka. Změna hesla účtu neudělá nic pro zařízení, které se ověřuje certifikátem, a opětovné vydání certifikátu neudělá nic pro klienta s uloženým heslem. Pojmenujte tajemství dřív, než pojmenujete řešení.

Pokud je rotace vedena podezřením a ne politikou, incidentní proces má přednost před plánem pohodlí. Odvolejte to, co důkazy vyžadují, a přijměte práci navíc na seznamu zařízení. To rozhodnutí patří vlastníkovi incidentu, ne tomu, kdo zrovna drží formulář pro reset hesla.

Nahraďte uloženou hodnotu tam, kde žije

Změňte údaj mechanismem, který služba dokumentuje, pak aktualizujte uloženou kopii nebo spusťte přihlašovací tok na každém zařízení, které chcete ponechat. Needitujte generovanou konfiguraci za správcem, který ji přepisuje, protože správce při příštím běhu obnoví starší hodnotu a úprava se stane odloženou závadou. Aktualizujte zdroj, který správce čte, nebo použijte vlastní úložiště údajů klienta. Ať tak či onak, zařízení musí skončit s novou hodnotou na místě, které klient skutečně čte.

Klient, který ukládá soubor s heslem, potřebuje přepsaný soubor, zatímco klient, který se ptá, potřebuje dokončené přihlášení. NetworkManager drží tajemství uvnitř profilu připojení, takže změna jde přes nmcli, ne přes textový editor:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

Profil, který čte soubor s údaji, je třetí případ. Nahraďte obsah toho souboru, ponechte jeho oprávnění uzavřená a znovu načtěte klienta místo editace profilu, který na něj ukazuje. Profil se nezměnil; změnilo se jen tajemství, které čte.

Znovu připojte každé zamýšlené zařízení jednou, záměrně, a sledujte, která selhávají. Pokud zařízení selhává dál, podívejte se na účet, na který ukazuje, a na úložiště, které čte, dřív než znovu změníte heslo, protože druhá změna znásobí kopie, které je třeba aktualizovat. Zařízení, které selže dvakrát, obvykle ukazuje na špatný účet nebo čte úložiště, které jste ještě nenašli. Opravte to a pak se znovu připojte.

Relace a tokeny přežívají heslo

Změna hesla nedokazuje, že stávající relace nebo samostatné certifikáty byly odvolány. Některé služby drží relaci živou, dokud nevyprší nebo není výslovně ukončena, a vydané tokeny mají vlastní životnost. Ověřte, co služba skutečně dělá, místo abyste předpokládali, že změna byla globální. Pokud byla změna vedena podezřením, ukončete relace výslovně a potvrďte výsledek.

Pokyny k životnímu cyklu údajů v NIST SP 800-63B drží autentikátory a relace v oddělených kategoriích, a proto jsou změna hesla a globální odhlášení různé operace. Berte je jako dva úkoly se dvěma kritérii dokončení. První skončí, když nová hodnota funguje, a druhý, když staré relace zmizí.

Zaznamenejte dokončení, aniž byste nové heslo zapsali do záznamu. Protokol rotace, který obsahuje údaj, je nový incident čekající na sdíleném disku. Poznamenejte datum, aktualizovaná zařízení a zařízení, která ještě zbývají.