Korlátozza a VPN-figyelőt a szándékolt interfészekre

A VPN-szolgáltatás onnan érhető el, ahol a socketje kötve van, és ahol a tűzfala engedi. Ez két külön döntés, és az emberek általában csak az egyiket hozzák meg. A tényleges figyelő kiolvasása tíz másodpercet vesz igénybe, és eldönt egy kérdést, amelyet a találgatás nem tud eldönteni. Kezdje ott, majd egyszerre egy vezérlőt változtasson.

Az alábbiak mindegyike feltételezi, hogy root vagy sudo jogosultsággal futtathat parancsokat a gazdagépen.

Olvassa ki a socketeket, mielőtt bármit módosítana

Linuxon a ss -lunp felsorolja az UDP-figyelőket helyi címükkel, portjukkal és folyamatukkal, a ss -ltnp pedig ugyanezt teszi a TCP-nél. Keresse meg a VPN portját, és olvassa el figyelmesen a címoszlopot. A 0.0.0.0:51820 és a [::]:51820 minden interfészt jelent, míg a 10.0.0.5:51820 egy címet egy interfészen. Az ss kézikönyve dokumentálja az oszlopokat, ha a kimenet ismeretlen. Ha hiányzik a folyamat neve, futtassa ugyanazt a parancsot sudóval, mert a tulajdonos oszlophoz jogosultság kell.

Írja fel a címet. Ez az a tény, amelytől az útmutató többi része függ.

Címhez kössön, ne kívánsághoz

Az OpenVPN a local direktívájával egy adott címhez köti a figyelőt, és ez a támogatott módja annak folyamatszintű szűkítésének. Nem minden implementáció kínál megfelelőt, és a kötési lehetőség nélküli protokoll így nem szűkíthető. Ha az önében nincs ilyen, a tűzfal az egyetlen vezérlője, és a telepítési jegyzeteknek ezt egyértelműen ki kell mondaniuk. Több című gazdagépen ahhoz kössön, amelyik a tunel felé néz; a lebegő címhez kötés általában hiba.

A címváltozást túlélő szolgáltatásnak tervet kell adnia az elavult kötésre, nem csupán egy konfigurációs sort.

Ellenőrizze külön a címcsaládot

Az IPv4 és az IPv6 külön socketek. A 0.0.0.0-hoz kötött folyamat továbbra is fogadhat IPv6-ot kettős stackű socketen keresztül, vagy nem, a socket beállításától és a platform alapértelmezésétől függően. Csak az IPv4-sor olvasása több telepítési felülvizsgálatot is megtévesztett. Sorolja fel mindkét családot, mielőtt arra jut, hogy a figyelő szűk.

Ha az IPv6 nem része a tervezésnek, a socket szintű letiltása tisztább, mint remélni, hogy a tűzfal lefedi. Ez szakpolitikai döntés, ezért rögzítse az interfész-választások többi részével együtt.

Rétegezze a tűzfalat a kötés fölé

A szűk kötés nem helyettesít egy tűzfalszabályt, és a tűzfalszabály nem szűkíti a wildcard-kötést. Használja mindkettőt: kössön ott, ahol az implementáció támogatja, majd csak azokból a forrásokból engedje a portot, amelyeknek el kell érniük. A felhő biztonsági csoportjai a gazdagép tűzfala előtt állnak, ezért mindkettőt ellenőrizze, amikor az útvonal átlép egy VPC-határt. A tényleges szabály a kettő metszete, és minden réteg csak elvehet az elérhetőségből.

Teszteljen engedélyezett forrásból és szándékosan kizárt forrásból. A localhostról érkező kapcsolat semmit sem bizonyít a nyilvános határról.

Rögzítse, mit választott

Írja le a kötött címet, az őt birtokló interfészt, a tűzfalszabályt és annak célját. Egy csere-NIC vagy újrakiosztott felhőcím megváltoztathatja a kitettséget anélkül, hogy bárki szerkesztené a profilt. Dátumozza a jegyzetet, mert a felhőcímek a felülvizsgálatok között gyakrabban mozognak, mint az emberek várják.

Ez a jegyzet teszi a következő felülvizsgálatot összehasonlítássá egy régészeti projekt helyett.