VPS-tűzfal: csak a VPN-portot nyissa ki, aztán bizonyítsa

Egy tűzfal, amely csak a VPN-portot engedi át, nem egyetlen szabály. Három külön döntés, amelyek véletlenül ugyanarra a portszámra vonatkoznak: a bemeneti lánc dönti el, mi érhet el egy helyi folyamatot, a továbbítási lánc dönti el, mi haladhat át a gazdagépen az alagút klienseinek nevében, és a NAT-tábla átírja a forrás címet kifelé menet. Ha egyet elront, az eredmény ritkán tiszta kiesés. Olyan gazdagépet kap, amely elfogadja a klienseket, de semmit nem tölt be, vagy olyat, amely zártnak látszik, amíg valaki el nem olvassa a láncok sorrendjét.

Az egyetlen port, amelyet nem lehet bezárni

A VPN-figyelőnek kiszámíthatatlan címekről kell kapcsolatokat fogadnia, tehát definíció szerint nyilvános szolgáltatás. Ez az egyetlen kivétel, amelyre a tervezés épül: egy UDP-port az OpenVPN számára, egy UDP-port a WireGuardnak, egy TCP-port egy SSL VPN-nek. Minden más az alagút mögé tartozik, ami azt jelenti, hogy az alkalmazásszolgáltatásokat az alagút címéhez vagy a loopbackhez kell kötni, nem minden interfészhez.

A kötés azonban nem kényszerítés. Egy 0.0.0.0-hoz kötött folyamat csak akkor érhető el, ha egy szabály átengedi, és az alapértelmezett házirend a tartalék az olyan forgalomhoz, amelyre egyetlen szabály sem illeszkedett, nem a portot irányító szabály. A drop fölé helyezett accept továbbra is accept, és egy szolgáltatás nyilvános címről való elmozdítása önálló javítás, nem a lánc helyettesítője.

A bemenet, a továbbítás és a NAT külön kérdésekre válaszol

A bemeneti forgalom magának a gazdagépnek szól, tehát ott él a VPN-figyelő és az adminisztratív útvonal. A továbbítási forgalom áthalad a gazdagépen, és az alagút klienseinek erre szükségük van a net.ipv4.ip_forward=1 mellett. A klasszikus félig törött konfiguráció engedi a kimenő folyamot, és megfeledkezik a visszirányról, így a kliens befejezi a kézfogást, majd semmi nem töltődik be; a létrehozott és kapcsolódó forgalomra vonatkozó conntrack-szabály lefedi ezt az irányt.

A NAT a harmadik kérdés. Postrouting-átírás nélkül a továbbított csomagok az alagút privát forrásával lépnek ki, és feljebb eldobódnak, mert a gazdagépen túl egyetlen hálózat sem tudja visszafelé irányítani a poolt. A szabály forrás-előtagjának a VPN poolhoz kell illeszkednie, nem a gazdagép saját címéhez, és ugyanez igaz a kliens alhálózatát megnevező továbbítási szabályra.

Az IPv6 egy második házirend, nem utólagos gondolat. Egy szigorú IPv4-lánccal és nyitott ip6tables-házirenddel rendelkező gazdagép semmit nem zárt be; a szolgáltatások a másik családon át továbbra is elérhetők. Vagy tükrözze a szabálykészletet a ip6tables-tal, vagy szándékosan kapcsolja ki az IPv6-ot a nyilvános interfészen, és írja le, melyiket választotta.

Egy alapvonal, amely egy menetben olvasható

Kezdje a tagadással, majd csak azt adja hozzá, amire a gazdagépnek szüksége van. Először a loopback és a válaszok, aztán az adminisztratív útvonal, aztán az alagút figyelője, aztán a továbbítási házirend a klienseknek:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Az interfésznevek, a port és a pool helyőrzők; olvassa ki őket a szerverről, ahelyett hogy lemásolná. Az eredmény mentése ugyanolyan fontos, mint a megírása, mert a csak memóriában élő szabálykészlet eltűnik a következő újraindításkor, és csendesen újra megnyitja a gazdagépet. Tegye tartóssá a disztribúció mechanizmusával, és tartson másolatot a gépen kívül arra a napra, amikor a gép nem indul el.

Az utolsó port bezárása a gazdagép elvesztése nélkül

Van egy horog a tervezésben. Ha az SSH csak az alagúton keresztül létezik, egy meghibásodott VPN-szolgáltatás magával viszi az SSH-t, és az egyetlen visszaút egy olyan konzol lehet, amelyet soha nem nyitott meg. Mielőtt bezárja az utolsó nyilvános portot, erősítse meg, hogy az a konzol létezik, és tényleg tudja használni, vagy tartson egy szűk adminisztratív útvonalat, amely nem függ az alagúttól: SSH fix címről, csak kulcsok, jelszavas hitelesítés kikapcsolva.

A változtatást egy már létrehozott munkamenetből alkalmazza, ne azon a kapcsolaton keresztül, amelyet épp szűrni fog. Ütemezzen visszaállítást, hogy egy hiba lejárjon ahelyett, hogy véglegessé válna, például egy systemd-run --on-active=10min feladatot, amely visszaállítja az előző szabálykészletet, és tartsa nyitva a második SSH-munkamenetet, miközben az elsőt teszteli. Aztán ellenőrizze, hogy a visszaállítási feladat tényleg lefut, mert a ki nem próbált helyreállítás ugyanaz, mint a semmilyen helyreállítás.

Az útvonalat ellenőrizze, ne a szkriptet

A betöltött szabályokat olvassa, ne a fájlt, amelynek be kellett volna töltenie őket. Egy engedélyezett külső gazdagépről erősítse meg, hogy csak a szándékolt portok válaszolnak; az alagúton belülről erősítse meg, hogy a közzétenni kívánt szolgáltatások elérhetők. Az alapértelmezett tagadó házirend, amely az alagút forgalmát is blokkolja, pontosan úgy néz ki, mint egy működő lezárás, amíg valaki meg nem próbálja használni.

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

Jegyezze fel az engedélyezett portot, a kliens poolt, az alagút interfészét, az adminisztratív forrást és a konzol eljárását a konfiguráció mellé. A pool vagy az interfész nevének következő változását a szűrőben és a NAT-szabályban is át kell vezetni, különben a gazdagép észrevétlenül visszatér egy félig nyitott állapotba.

Egy szokás többet ér a szabálykészletnél: minden változtatás után bizonyítsa a továbbítási útvonalat egy klienskéréssel, a helyreállítási útvonalat pedig egy második munkamenettel. Egy lezárás, amelyet nem használt, csak feltevés.