Cloudová bezpečnostná skupina pre VPN: otvorte naslúchajúci port, nie všetko

Server VPN beží, klientovi vyprší časový limit a prvý inštinkt je pridať do bezpečnostnej skupiny pravidlo, ktoré povolí všetko. Niekedy to pomôže, a to je najhorší výsledok, pretože teraz nikto nevie, ktorá hranica sa vlastne zavrela. Medzi klientom a démonom stoja štyri samostatné filtre a iba jeden z nich je bezpečnostná skupina.

Pomenujte protokol skôr než pravidlo

Pravidlo je protokol, rozsah portov a zdroj. WireGuard počúva na UDP, zvyčajne 51820. OpenVPN je zvyčajne UDP alebo TCP 1194 podľa konfigurácie. IPsec potrebuje výmenu IKE na UDP 500 a 4500 plus samotný protokol ESP, ktorý je číslo protokolu, nie port. Hádanie TCP preto, že ostatné pravidlá sú TCP, vedie k pravidlu, ktoré vyzerá správne a na nič nesedí.

Čítajte naslúchač z bežiacej služby, nie z návodu. Démon viazaný na jednu adresu neprijme prevádzku prichádzajúcu na inú.

Obmedzte zdroj na rozsah klientov, ktorý návrh povoľuje, namiesto celého internetu.

Bezpečnostné skupiny sú stavové; podsieťové ACL nie

Bezpečnostné skupiny sú stavové a iba povoľujú: povolený prichádzajúci tok dostane odpovede automaticky a neexistuje pravidlo zamietnutia, o ktorom by sa uvažovalo. Podsieťové ACL sú bezstavové a vyhodnocujú sa v oboch smeroch, takže prichádzajúce povolenie bez zodpovedajúceho odchádzajúceho efemérneho rozsahu stále zlyhá. Ten rozdiel vysvetľuje mnohé pravidlá, ktoré v konzole vyzerajú správne.

Overte aj to, ktorá politika je pripojená k bežiacemu koncovému bodu, pretože inštancia môže mať viac ako jednu skupinu a pravidlo v nepripojenej skupine nič nemení.

Účinná politika je zjednotenie toho, čo je pripojené, nie súbor, ktorý ste upravovali.

Hostiteľský firewall je samostatná hranica

Cloudová politika prepustí prevádzku k sieťovému rozhraniu a potom operačný systém rozhodne, či ho démon uvidí. Hostiteľský firewall s predvolenou politikou zamietnutia zahodí paket, ktorý bezpečnostná skupina povolila, a cloudová konzola neukáže žiadne zamietnutie, pretože nikdy nemala názor. Skontrolujte oboje, v poradí, v akom paket na ne narazí.

Ak hostiteľ používa frontend firewallu z distribúcie, overte podkladové pravidlá, nie názov profilu, pretože profil môže byť aktívny, kým je port zatvorený.

Zachytenie na rozhraní vám povie, ktorá hranica paket zahodila.

Povoliť naslúchač nie je to isté ako smerovať klientov

VPN brána, ktorá preposiela klientsku prevádzku, potrebuje viac než otvorený port. Potrebuje preposielanie IP, politiku povoľujúcu tok z tunelového rozhrania do cieľovej siete a často vypnutú kontrolu zdroja a cieľa na rozhraní, aby platforma nezahadzovala prevádzku, ktorá jej nie je adresovaná. Nič z toho pravidlo pre naslúchač nevytvára.

Tu sa rozchádza funkčný handshake a rozbitá dátová cesta, a preto môže stav tunela vyzerať zdravo, keď sa nič nenačítava.

Opravte smerovanie ako samostatnú zmenu s vlastným overením a všimnite si, že preposielajúca brána potrebuje aj výstupnú politiku, ktorá cieľ povoľuje.

Nechajte si cestu späť a potom pravidlo zúžte

Pred zmenou vzdialenej politiky firewallu overte, že existuje nezávislá cesta správy, napríklad správca relácií, sériová konzola alebo sieť mimo pásma. Ak jediná cesta správy vedie cez pravidlo, ktoré upravujete, nemáte obnovu. Potom použite úzke pravidlo, otestujte zo skutočného klienta a pokus prepojte s dôkazmi na strane servera. Odpoveď inej služby na tom istom stroji nie je dôkaz, že naslúchač bol dosiahnutý.

Odstráňte akékoľvek experimentálne široké povolenie, hneď ako úzke funguje, a poznamenajte, prečo pravidlo existuje. AWS dokumentuje stavové správanie bezpečnostných skupín a práve tento dokument citujte, keď niekto navrhne široký rozsah ako skratku.

Zdokumentujte aj pripojenie, inak náhradné rozhranie politiku ticho stratí.