Požarni zid VPS: odprite samo vrata VPN in to nato dokažite

Ena vrata morajo ostati javna, sicer se ne poveže noben odjemalec. Zavrnite ostalo, posredovanje ločite od vhoda in pustite vnaprej preizkušeno pot za obnovitev.

Požarni zid, ki spusti samo vrata VPN, ni eno pravilo. To so tri ločene odločitve, ki se slučajno nanašajo na isto številko vrat: vhodna veriga odloča, kaj lahko doseže lokalni proces, veriga posredovanja odloča, kaj lahko v imenu odjemalcev tunela preide skozi gostitelja, in tabela NAT prepiše izvorni naslov na poti ven. Eno od tega zgrešite in rezultat je redko čista prekinitev. Dobite gostitelja, ki sprejema odjemalce, a ne naloži ničesar, ali gostitelja, ki je videti zaprt, dokler nekdo ne prebere vrstnega reda verig.

Edina vrata, ki jih ni mogoče zapreti

Poslušalec VPN mora sprejemati povezave z naslovov, ki jih ne morete predvideti, zato je po definiciji javna storitev. To je edina izjema, na kateri je zasnovan dizajn: ena vrata UDP za OpenVPN, ena vrata UDP za WireGuard, ena vrata TCP za VPN SSL. Vse drugo sodi za tunel, kar pomeni, da se morajo aplikacijske storitve vezati na naslov tunela ali na loopback, ne pa na vse vmesnike.

Vezava pa ni uveljavljanje. Proces, vezan na 0.0.0.0, je dosegljiv le, če ga pravilo spusti, privzeta politika pa je rezerva za promet, ki se ni ujemal z nobenim pravilom, ne pa pravilo, ki upravlja vrata. Dovoljenje, postavljeno nad vašo zavrnitvijo, ostane dovoljenje, in premik storitve z javnega naslova je samostojna izboljšava, ne nadomestilo za verigo.

Vhod, posredovanje in NAT odgovarjajo na različna vprašanja

Vhodni promet je namenjen gostitelju samemu, zato tam živita poslušalec VPN in upravna pot. Promet posredovanja prehaja skozi gostitelja in odjemalci tunela ga potrebujejo skupaj z net.ipv4.ip_forward=1. Klasična napol pokvarjena konfiguracija dovoli odhodni tok in pozabi na povratno smer, zato odjemalec dokonča rokovanje in nato nič ne naloži; pravilo conntrack za vzpostavljen in povezan promet pokrije to smer.

NAT je tretje vprašanje. Brez prepisa v postroutingu posredovani paketi odhajajo s privatim virom tunela in so višje zavrženi, ker nobeno omrežje onkraj gostitelja ne zna usmeriti bazena nazaj. Izvorna predpona v tem pravilu se mora ujemati z bazenom VPN, ne z lastnim naslovom gostitelja, in isto velja za pravilo posredovanja, ki imenuje podomrežje odjemalcev.

IPv6 je druga politika, ne poznejša misel. Gostitelj s strogo verigo IPv4 in odprto politiko na ip6tables ni ničesar zaprl; storitve so še vedno dosegljive prek druge družine. Ali preslikajte nabor pravil z ip6tables ali namerno izklopite IPv6 na javnem vmesniku, in zapišite, kaj ste izbrali.

Osnova, ki jo preberete v enem prehodu

Začnite z zavrnitvijo in nato dodajte le tisto, kar gostitelj potrebuje. Najprej loopback in odgovori, nato upravna pot, nato poslušalec tunela, nato politika posredovanja za odjemalce:

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

Imena vmesnikov, vrata in bazen so nadomestni znaki; preberite jih s strežnika, namesto da jih kopirate. Shranjevanje rezultata je enako pomembno kot pisanje, ker nabor pravil, ki živi le v pomnilniku, izgine ob naslednjem zagonu in tiho znova odpre gostitelja. Naredite ga trajnega z mehanizmom distribucije in hranite kopijo zunaj stroja za dan, ko se stroj ne bo zagnal.

Zapreti zadnja vrata, ne da bi izgubili gostitelja

V dizajnu je past. Če SSH obstaja le skozi tunel, okvarjena storitev VPN odnese s seboj tudi SSH, edina pot nazaj pa je morda konzola, ki je nikoli niste odprli. Preden zaprete zadnja javna vrata, potrdite, da ta konzola obstaja in da jo res lahko uporabljate, ali obdržite eno ozko upravno pot, ki ni odvisna od tunela: SSH s stalnega naslova, samo ključi, preverjanje gesla izklopljeno.

Spremembo uporabite iz že vzpostavljene seje, ne skozi povezavo, ki jo boste filtrirali. Načrtujte razveljavitev, da napaka poteče, namesto da postane trajna, na primer opravilo systemd-run --on-active=10min, ki obnovi prejšnji nabor pravil, in medtem ko preizkušate prvo, pustite odprto drugo sejo SSH. Nato preverite, ali se opravilo razveljavitve res sproži, kajti nepreizkušena obnovitev je isto kot nobena obnovitev.

Preverite pot, ne skripta

Berite naložena pravila, ne datoteke, ki bi jih morala naložiti. S pooblaščenega zunanjega gostitelja potrdite, da odgovarjajo samo predvidena vrata; od znotraj tunela potrdite, da so storitve, ki ste jih hoteli objaviti, dosegljive. Privzeta politika zavrnitve, ki blokira tudi promet tunela, je videti enako kot delujoča zaklenitev, dokler je nekdo ne poskusi uporabiti.

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

Zapišite dovoljena vrata, bazen odjemalcev, vmesnik tunela, upravni vir in postopek s konzolo ob konfiguraciji. Naslednja sprememba bazena ali imena vmesnika se mora uskladiti tako v filtru kot v pravilu NAT, sicer se gostitelj vrne v napol odprto stanje, ne da bi kdo to opazil.

Ena navada je vredna več kot nabor pravil: po vsaki spremembi dokažite pot posredovanja z zahtevo odjemalca in pot obnovitve z drugo sejo. Zaklep, ki ga niste uporabili, je le hipoteza.

Sorodni članki