Hogyan zárjuk le a Linux kimenetét, hogy ne szivárogjon semmi, amikor elszáll a VPN

Képzeljünk el egy médiaboxot otthoni kapcsolaton, amelynek csak alagúton keresztül szabad elérnie az internetet. Amikor az alagút elszáll, az alkalmazásnak meg kellene állnia, nem pedig csendben továbbmennie a fizikai interfészen. Ennek a viselkedésnek az elérése tűzfal- és nem útválasztási probléma, és a különbség számít, mert az útvonalat le lehet cserélni a démon újraindításával, míg a szűrő ott marad, ahová tettük. A következőkben azt nézzük meg, hogyan dönt valójában a csomag útja, majd azt, hogyan határoljuk be azokat a kivételeket, amelyek az alagutat újracsatlakoztatják.

A helyi kimenet másik horog, mint a továbbítás

Egy csomag, amely elhagyja a gépen futó alkalmazást, a kimeneti horgon halad át; egy csomag, amelyet a gép más hoszt számára irányít, a továbbításon halad át. Egy házirend, amely csak a forward-t említi, a másodikat korlátozza, az elsőt pedig teljesen nyitva hagyja, ezért látszik sok kimeneti zár helyesnek, és mégsem tesz semmit. Az interfész-egyeztetés ugyanabba a szabályba tartozik: a oifname "tun0" accept átengedi azt a forgalmat, amelyet már az alagúton keresztül irányítottak. Az útválasztás és a szűrés is külön döntés marad, így létezhet egy feltöltő útvonal, miközben a szűrő elutasítja a csomagot. Erre az elkülönítésre támaszkodunk.

Egy átjárónak, amely más eszközök számára továbbít, mindkét horogra szüksége van. Ha csak a kimenetet zárjuk le, a gép önmagát védjük, és minden lejjebb lévő ügyfelet szabadon hagyjuk szivárogni.

A kivétellistát a végponttól kifelé írjuk meg

Kezdjük az alagút végpontjával: egy célcím vagy egy kis jóváhagyott halmaz, a szállítási protokoll és a célport, például udp dport 1194 ip daddr 203.0.113.7 accept. Ha az ügyfél hosztnevet old fel, a kezdeti DNS-csere saját szabályt igényel, amely a feloldóra és az 53-as portra korlátozódik, nem pedig átfogó engedély arra a feloldó címére. Minden kivételnek meg kell neveznie az okot, amiért létezik. Az engedély a VPN portjára irányuló összes UDP-forgalomra jóval többet fed le, mint az az egyetlen hitelesített szolgáltatás, amelyre gondoltunk.

A kezdeti feloldás az a pont, ahol a zárak általában elrohadnak. Egy időzítővel frissülő címhalmaznak meghatározott viselkedésre van szüksége, amikor a frissítés meghiúsul, és ez a viselkedés nem lehet a kapcsolat megnyitása, amíg nem sikerül. Frissítsünk az alagúton keresztül, amíg az alagút áll, egyébként essünk vissza az utolsó ismert jó végpontra.

A helyi felügyelet ugyanezt a kezelést igényli. Egy felügyeleti alhálózat nem megbízható csak azért, mert a címei privátak, és egy szabály, amely megbízik benne, második utat hív meg a zár körül.

Az interfész-egyeztetés nem bizonyíték az egészséges alagútra

Azok a szabályok, amelyek mindent elfogadnak, ami a tun0 interfészen kilép, feltételezik, hogy az interfészen lévő csomag az alagútból jött. Az interfésznevek újra létrejönnek, és egy név nem kriptográfiai identitás. A partner is eltűnhet, miközben az interfész állva marad, ami a szabályt nagyon meggyőző semmittevéssé teszi.

A kapcsolatkövetés rokon csapdát hoz. A létrejött kapcsolatokra vonatkozó széles szabály újrajátssza azt az engedélyt, amelyet egy folyam korábban kapott, így az alagút elszállása előtt indult munkamenet utána is működik. Korlátozzuk az állapot alapú elfogadást azokra az interfészekre és címekre, amelyeket valóban értünk, különben olyan zárat építettünk, amely magától kinyílik. A bemeneti és kimeneti szabályok is más kérdésekre válaszolnak, és ha az egyiket megerősítjük, a másikat pedig figyelmen kívül hagyjuk, a gép abban az irányban marad elérhető, amelyre nem gondoltunk.

Mi él túl egy démon-összeomlást

Az a szűrő, amelyet egy olyan szkript telepít, amely az alagút feljövetele után fut, eltűnik az alagúttal együtt, éppen abban a pillanatban, amikor szükség volt rá. Töltsük be a zárat indításkor, és hagyjuk, hogy a démon csak a kivételeit kezelje.

Az alapértelmezett útvonal törlése sem helyettesítő. Az útvonal olyan állapot, amely a démon tulajdona és amelyet átír, és eltávolítása elveheti az újracsatlakozáshoz szükséges utat. Az IPv6 saját tervet igényel, mert a szomszédok felderítése és az útválasztó-hirdetések olyan kapcsolati szolgáltatások, amelyeknek a közönséges forgalom blokkolása mellett is működniük kell. A DHCP ugyanebbe a kategóriába tartozik. Írjuk ezeket célokkal rendelkező kivételekként, ahelyett hogy később kiesésként fedeznénk fel őket.

Helyreállítási útvonal az üzembe helyezés előtt

Teszteljük a zárat úgy, ahogy el fog szállni: indítás alagút nélkül, a démon leölése, a végpont megváltoztatása és az újracsatlakozás. Minden esetben meg kell állnia az alkalmazásoknak, és működőképesnek kell maradnia a helyreállítási csatornának. Konzolról tegyük, mert a távoli héj az a munkamenet, amelyet a saját szabályunk a legvalószínűbben kizár.

Utána ellenőrizzük, hova érhet még el egy közönséges alkalmazás, egy ártalmatlan céllal és egy ellenőrizhető kéréssel. A kívánt eredmény a feltöltő oldalon egy elutasítás és az alagúton keresztüli siker, nem pedig egy kétértelmű időtúllépés, amely bármelyiket jelentheti. Tartsuk a szabálykészletet ugyanazon tulajdonos alatt, mint a tűzfal többi részét, ahelyett hogy egy shell-szkriptből lecserélnénk az egész táblát. Egy házirend, amelyben minden engedély igazolni tudja magát, többet ér, mint egy hosszú szabálykészlet, amelyet senki sem tud megmagyarázni.