Umístěte VPN bránu vedle Windows XP, ne dovnitř
Ponechte starý host Windows XP jako koncový bod aplikace a přesuňte tunel, jeho klíče a aktualizace na udržovanou bránu vedle.
Někde v budově stojí stroj, který spouští aplikaci, již nikdo nedokáže nahradit, na operačním systému, který by se neměl připojovat k ničemu. Vyjít od síťového adaptéru tohoto hostu je nejrychlejší způsob, jak zjistit, kam tunel patří. Ve většině návrhů na host vůbec nepatří. Přesuňte ho o jeden krok stranou na udržovanou bránu a starý problém se zmenší zpět na aplikaci, se kterou začal.
Začněte u adaptéru hostu, ne u VPN klienta
Otevřete vlastnosti adaptéru a dejte hostu pevnou adresu v malém vyhrazeném segmentu, přičemž brána bude jeho výchozí trasou. Host pak nepotřebuje klienta tunelu, přihlašovací údaje tunelu ani záznamy v tabulce tras sahající do širší podnikové sítě. Pokud aplikace potřebuje jednu vzdálenou podsíť, přidejte přesně tuto jednu trasu.
C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p
Tento příkaz připne jediný cíl k bráně a vše ostatní nechá bez trasy, což je tvar, který chcete. Výsledek ověřte pomocí route print, místo abyste věřili návratovému kódu. Pak zkontrolujte, že aplikace stále překládá název svého serveru, protože starý host s rozbitým překladačem vypadá přesně jako síťová porucha, a oprava překladače je pětiminutová práce, zatímco přestavba aplikace po chybném síťovém zásahu ne. Každý cíl, na který se host nedostane, je o jednu věc méně, ke které lze starý síťový zásobník přemluvit k útoku.
Umístěte tunel na hardware, který můžete aktualizovat
Brána chce dvě rozhraní: jedno obrácené k segmentu hostu a jedno tam, kde žije aplikace, přičemž tunel končí na druhém. Toto zařízení může přijímat aktualizace firmwaru, měnit svou kryptografickou konfiguraci a zaznamenávat toky, aniž by se někdo dotkl starého stroje. Její dodavatel také dodává opravy implementace tunelu, které host nikdy nedostane. Dva stroje a termín nejsou důvodem kopírovat recept se statickým tajemstvím z příspěvku na fóru.
Dejte každé bráně vlastní identitu protějšku místo klonování jedné klientské konfigurace na celou flotilu. Když je jednotka vyměněna, zrušte starou identitu ve stejném okamžiku, kdy uvádíte novou online, jinak skončíte se dvěma nekontrolovanými kopiemi ověřujícími se vůči stejnému koncovému bodu. Ukládejte klíče tam, kde je očekává řídicí rovina brány, zacházejte se zálohou konfigurace jako s tajemstvím a prověřte, kdo může tuto konfiguraci odesílat, protože nyní rozhoduje o tom, kam se starý host dostane.
Povolte služby, ne sítě
Napište zásadu z hlediska protokolu, portu a směru mezi oběma připojeními. Jeden povolený port k jedné adrese aplikace je obvyklá odpověď a administrativní cesta přes odrazový host pokrývá zbytek.
Vzdálená správa starého hostu by neměla jet po stejném pravidle jako aplikace a testování odmítnutí je stejně důležité jako psaní pravidla. Pošlete jeden požadavek z hostu na cíl, u kterého očekáváte odmítnutí, a potvrďte, že odmítnutí přichází ze zásady, nikoli z chybějící trasy. Zaznamenávejte toky, které povolujete, dokud je návrh nový, abyste viděli, co aplikace skutečně používá, a ne co tvrdí její dokumentace. Sloučení dvou podsítí proto, že mostový návod vypadal kratší, je způsob, jak se starý segment tiše stane opěrným bodem.
Nevystavujte starý posluchač přímo internetu jako zkratku kolem brány. Držte administrativní cestu oddělenou od cesty aplikace, aby kompromitace jedné nepředala druhou. Pravidlo, které se nikdy necvičí, je pravidlo, které nikdo neověřil, a proto odmítnutý cíl patří do akceptačního běhu.
Obnova musí fungovat bez tunelu
Rozhodněte, kdo bránu aktualizuje a obnovuje, ještě před prvním výpadkem, a ujistěte se, že se k ní tato osoba dostane bez tunelu, který ukončuje. Konzolový přístup, místní správcovský port nebo mimopásmová cesta se všechny počítají jako odpovědi. Brána, kterou lze konfigurovat jen přes tunel, který poskytuje, je past, která trpělivě čeká na špatné nahrání firmwaru.
Napište runbook pro poruchu, se kterou se skutečně setkáte: tunel nefunguje, brána je mrtvá, disk hostu zmizel. Uchovávejte obnovovací obraz hostu v rámci jakékoli podpůrné dohody, která ještě existuje, a pamatujte, že obnova vrací i stav softwaru a přihlašovací údaje uvnitř tohoto obrazu. Nejprve obnovte na izolovaný segment, potvrďte, že aplikace startuje, a teprve potom cokoli znovu připojte; když se brána změní, aktualizujte runbook a inventář při stejné příležitosti.
Certifikáty, hodiny a varování o podpisu
Vypršení certifikátu instalátoru samo o sobě nepředpovídá, co dnes řekne kontrola podpisu. Pokyny Microsoftu k časovým razítkům Authenticode vysvětlují, že časové razítko může udržet podpis ověřitelný i po vypršení podpisového certifikátu a že ověření stále závisí na podpisu, řetězci důvěry a ověřovateli. Dva stroje s různými úložišti důvěry se proto mohou o stejném souboru neshodnout. Vypršelý podepisující subjekt není důkazem, že binárka je škodlivá, a platný podpis není důkazem, že software je udržovaný.
Neposouvejte systémové hodiny zpět ani nevypínejte kontroly podpisu, abyste spustili starý instalátor. Získejte autorizovaný artefakt od toho, kdo aplikaci stále podporuje, a nechte je říci, co platforma přijímá. Příspěvky tvrdící, že určitý build byl poslední pro XP, berte jako historii, ne jako cíl instalace, protože skutečný požadavek závisí na aplikaci; pokud je práce na zachování opravdu nutná, držte ji v izolovaném segmentu daleko od produkčního přístupu a zdokumentujte, proč existuje.