Cloudová bezpečnostní skupina pro VPN: otevřete naslouchající port, ne všechno

Server VPN běží, klientovi vyprší časový limit a první instinkt je přidat do bezpečnostní skupiny pravidlo, které povolí vše. Někdy to pomůže, a to je nejhorší výsledek, protože teď nikdo neví, která hranice se vlastně zavřela. Mezi klientem a démonem stojí čtyři samostatné filtry a jen jeden z nich je bezpečnostní skupina.

Pojmenujte protokol dřív než pravidlo

Pravidlo je protokol, rozsah portů a zdroj. WireGuard naslouchá na UDP, obvykle 51820. OpenVPN je obvykle UDP nebo TCP 1194 podle konfigurace. IPsec potřebuje výměnu IKE na UDP 500 a 4500 plus samotný protokol ESP, což je číslo protokolu, ne port. Hádání TCP proto, že ostatní pravidla jsou TCP, vede k pravidlu, které vypadá správně a na nic nesedí.

Čtěte naslouchač z běžící služby, ne z návodu. Démon vázaný na jednu adresu nepřijme provoz přicházející na jinou.

Omezte zdroj na rozsah klientů, který návrh povoluje, místo celého internetu.

Bezpečnostní skupiny jsou stavové; podsíťové ACL ne

Bezpečnostní skupiny jsou stavové a pouze povolují: povolený příchozí tok dostane odpovědi automaticky a neexistuje pravidlo zamítnutí, o kterém by se dalo uvažovat. Podsíťové ACL jsou bezstavové a vyhodnocují se v obou směrech, takže příchozí povolení bez odpovídajícího odchozího efemerního rozsahu stále selže. Ten rozdíl vysvětluje mnoho pravidel, která v konzoli vypadají správně.

Ověřte také, která zásada je připojena k běžícímu koncovému bodu, protože instance může mít více skupin a pravidlo v nepřipojené skupině nic nezmění.

Účinná zásada je sjednocení toho, co je připojeno, ne soubor, který jste upravovali.

Hostitelský firewall je samostatná hranice

Cloudová zásada propustí provoz k síťovému rozhraní a pak operační systém rozhodne, zda ho démon uvidí. Hostitelský firewall se zásadou výchozího zamítnutí zahodí paket, který bezpečnostní skupina povolila, a cloudová konzole neukáže žádné zamítnutí, protože nikdy neměla názor. Zkontrolujte obojí, v pořadí, v jakém paket narazí na ně.

Pokud hostitel používá frontend firewallu z distribuce, ověřte podkladová pravidla, ne název profilu, protože profil může být aktivní, zatímco port je zavřený.

Zachycení na rozhraní vám řekne, která hranice paket zahodila.

Povolit naslouchač není totéž jako směrovat klienty

VPN brána, která přeposílá klientský provoz, potřebuje víc než otevřený port. Potřebuje přeposílání IP, zásadu povolující tok z tunelového rozhraní do cílové sítě a často vypnutou kontrolu zdroje a cíle na rozhraní, aby platforma nezahazovala provoz, který jí není adresován. Nic z toho pravidlo pro naslouchač nevytvoří.

Tady se rozchází funkční handshake a rozbitá datová cesta, a proto může stav tunelu vypadat zdravě, když se nic nenačítá.

Opravte směrování jako samostatnou změnu s vlastním ověřením a všimněte si, že přeposílající brána potřebuje také výstupní zásadu, která cíl povolí.

Nechte si cestu zpět a pak pravidlo zúžte

Před změnou vzdálené zásady firewallu ověřte, že existuje nezávislá cesta správy, například správce relací, sériová konzole nebo mimopásmová síť. Pokud jediná cesta správy vede přes pravidlo, které upravujete, nemáte obnovu. Potom použijte úzké pravidlo, otestujte ze skutečného klienta a pokus propojte s důkazy na straně serveru. Odpověď jiné služby na stejném stroji není důkaz, že naslouchač byl dosažen.

Odstraňte jakékoli experimentální široké povolení, jakmile úzké funguje, a poznamenejte, proč pravidlo existuje. AWS dokumentuje stavové chování bezpečnostních skupin a právě tento dokument citujte, když někdo navrhne široký rozsah jako zkratku.

Zdokumentujte i připojení, jinak náhradní rozhraní zásadu tiše ztratí.