Na kterých portech OpenVPN Access Server skutečně naslouchá?

Spouštíte ss -lntup na hostiteli s Access Serverem a dostanete seznam dvakrát delší, než se čekalo. Polovina záznamů jsou porty ve tvaru démona, o kterých při instalaci nikdo nemluvil. Reflex je zavřít vše, co není 443 nebo 1194, a právě tak si lidé rozbijí vlastní klientský portál.

Access Server není jeden naslouchač. Je to VPN služba, webová služba a účastník clusteru a podle toho, kolik TCP démonů jste nakonfigurovali, může vytvářet další porty specifické pro démony a přesměrování firewallu.

Projděte inventář popořadě: přečtěte sockety, zmapujte známé, roztřiďte ostatní podle vlastníka a bindování a potom zkontrolujte, co je skutečně publikuje.

Začněte jediným příkazem jen pro čtení

sudo ss -lntup vám dá transport, místní adresu, port a vlastnící proces pro každý naslouchající socket. Přepínače jsou důležité: -l naslouchání, -n číselně, -t TCP, -u UDP, -p proces. Bez rootu dostanete sockety, ale ne názvy procesů, a to je přesně ten sloupec, který ke klasifikaci potřebujete.

Před vytvořením jakéhokoli názoru si u každého řádku poznamenejte čtyři pole: protokol, bindovací adresu, port a příkaz. Verzi Access Serveru a nakonfigurovaný počet démonů držte vedle tohoto seznamu, protože obojí mění to, co je očekávané.

Dva řádky, které vypadají stejně, stejné nejsou. TCP a UDP na stejném čísle jsou samostatné sockety se samostatnou expozicí a 0.0.0.0 a :: jsou samostatná bindování pro samostatné rodiny adres. Služba svázaná pouze s 127.0.0.1 není přímo dostupná z jiného hostitele, i když ji místní přesměrování stále může publikovat.

Naslouchače, které byste měli poznat

Tyto výchozí hodnoty pokrývají většinu nasazení a dávají vám základ pro srovnání. Jsou to výchozí hodnoty, ne úplný seznam povolených.

Všechno nad to potřebuje vysvětlení, ne předpoklad. Často uvidíte naslouchače jen pro místní přístup, které patří komponentám, jež produkt instaluje pro sebe. Potvrďte je pomocí PID a konfigurace služby, ne podle zapamatovaného čísla portu, a nepovažujte neznámý port za nepřátelský jen proto, že je neznámý.

Socket mimo známou dvojici také není automaticky zbytek. Když je nakonfigurováno více TCP démonů, Access Server vytváří naslouchače pro každého démona a přesměrovává na ně provoz, takže jejich počet a hodnoty portů odpovídají této konfiguraci.

Klasifikujte, než něco zavřete

U každého nejistého řádku odpovězte na tři otázky v tomto pořadí.

1. Vlastník a účel. Spárujte PID s unitem nebo procesem a přečtěte konfiguraci této služby. Pokud vlastníka nedokážete pojmenovat, nejste připraveni o socketu cokoli rozhodnout.
2. Rozsah bindování. Loopback je místní pro jmenný prostor. Wildcard bind je dostupný jen tehdy, pokud to dovolí směrování, filtrování hostitele a případná pravidla na úrovni cloudu, takže bindovací adresa je nutná, ale ne dostačující. Ověřte IPv4 a IPv6 jako samostatná rozhodnutí.
3. Publikovaná cesta. Hledejte přesměrování služby, přesměrování specifická pro démony, externí proxy a efektivní politiku firewallu. To je krok, který lidé vynechávají, a právě on mění neškodně vypadající backendový port v dostupnou administrativní cestu.

Stejná otázka se zvenčí hostitele čte jinak. Port bez pravidla firewallu hostitele může přesto zavřít cloudová bezpečnostní skupina a port s povolným pravidlem hostitele může být nedostupný, protože k němu nic nesměruje. Podívejte se na oba konce, než napíšete závěr inventáře.

Kde se publikovaná cesta liší od seznamu socketů

Vlastní dokumentace Access Serveru pokrývá případ, který působí největší zmatení: když běží několik TCP démonů, čelní port přesměrovává na porty specifické pro démony a viditelné uspořádání přestane odpovídat seznamu socketů. tutoriál k filtrování webového rozhraní popisuje tato pravidla a proč filtr napsaný jen pro zřejmý port může přesměrovanou cestu úplně minout.

Řízení clusteru je druhé místo, kde záleží na verzi. Ve 3.0 a novějších sdílí 943; starší konfigurace clusteru používaly 945. Otevření nebo zablokování jednoho z nich bez kontroly verze vytvoří inventář, který vypadá uklizeně a je špatný.

Externě viditelný povrch je tedy sjednocení tří věcí: naslouchajících socketů, pravidel přesměrování, která je znovu publikují, a síťových kontrol před hostitelem. Každý inventář, který zaznamenává jen první, je neúplný, a každá změna, která bere v úvahu jen první, buď nechá cestu otevřenou, nebo odřízne službu.

Po každé změně ověřte

Nastavení naslouchačů měňte přes podporovaného vlastníka konfigurace a během toho mějte otevřenou konzoli pro obnovu. Ztráta administrativního přístupu k webovému rozhraní na vzdáleném hostiteli se nedá obnovit přes VPN, kterou jste právě vypnuli.

Pak ověřte čtyři věci, které nasazení obvykle potřebuje: VPN klient se připojí, klientský portál se načte, administrativní přístup funguje a komunikace clusteru stále funguje, pokud provozujete více než jeden uzel. Test jen VPN pohodlně projde, zatímco portál je rozbitý.

Na závěr zapište povolenou cestu pro každou službu: který socket, které bindování, které pravidlo přesměrování, která síťová kontrola. Tento dokument je užitečný bezpečnostní výstup. Minimální počet socketů jím není, stejně jako hromadný reset, který zavírá naslouchače, jež nikdo nestačil identifikovat.