Firewall na VPS: otvorte iba port VPN a potom to dokážte

Firewall, ktorý prepustí iba port VPN, nie je jedno pravidlo. Sú to tri oddelené rozhodnutia, ktoré sa náhodou týkajú rovnakého čísla portu: vstupný reťazec rozhoduje, čo sa môže dostať k miestnemu procesu, presmerovací reťazec rozhoduje, čo môže prejsť cez hostiteľa v mene klientov tunela, a tabuľka NAT prepisuje zdrojovú adresu na ceste von. Pomýlite sa v jednom z nich a výsledkom je málokedy čistý výpadok. Dostanete hostiteľa, ktorý prijíma klientov, ale nič nenačíta, alebo hostiteľa, ktorý vyzerá uzavretý, kým niekto neprečíta poradie reťazcov.

Jediný port, ktorý nemožno zatvoriť

Naslúchač VPN musí prijímať spojenia z adries, ktoré neviete predvídať, takže je podľa definície verejnou službou. To je jediná výnimka, na ktorej je návrh postavený: jeden port UDP pre OpenVPN, jeden port UDP pre WireGuard, jeden port TCP pre SSL VPN. Všetko ostatné patrí za tunel, čo znamená, že aplikačné služby sa majú viazať na adresu tunela alebo na loopback, nie na všetky rozhrania.

Viazanie však nie je vynucovanie. Proces viazaný na 0.0.0.0 je dostupný len vtedy, keď ho pravidlo pustí, a predvolená politika je záloha pre prevádzku, ktorá nevyhovovala žiadnemu pravidlu, nie pravidlo, ktoré riadi port. Povolenie umiestnené nad vaším zakázaním je stále povolenie a presun služby z verejnej adresy je samostatné zlepšenie, nie náhrada za reťazec.

Vstup, presmerovanie a NAT odpovedajú na rôzne otázky

Vstupná prevádzka je určená samotnému hostiteľovi, takže tam žijú naslúchač VPN a administratívna cesta. Prevádzka presmerovania prechádza hostiteľom a klienti tunela ju potrebujú spolu s net.ipv4.ip_forward=1. Klasická polofunkčná konfigurácia povolí odchádzajúci tok a zabudne na spätný smer, takže klient dokončí handshake a potom sa nič nenačíta; pravidlo conntrack pre nadviazanú a súvisiacu prevádzku ten smer pokrýva.

NAT je tretia otázka. Bez prepisu v postroutingu odchádzajú presmerované pakety s privátnym zdrojom tunela a vyššie sa zahadzujú, pretože žiadna sieť za hostiteľom nevie smerovať pool späť. Zdrojový prefix v tom pravidle musí zodpovedať poolu VPN, nie vlastnej adrese hostiteľa, a to isté platí pre pravidlo presmerovania, ktoré pomenúva podsieti klientov.

IPv6 je druhá politika, nie dodatočná myšlienka. Hostiteľ s prísnym reťazcom IPv4 a otvorenou politikou na ip6tables nič neuzavrel; služby sú stále dostupné cez druhú rodinu. Buď zrkadlite sadu pravidiel pomocou ip6tables, alebo IPv6 na verejnom rozhraní vedome vypnite, a napíšte, ktorú možnosť ste zvolili.

Základ, ktorý prečítate na jeden prechod

Začnite zakázaním a potom pridajte iba to, čo hostiteľ potrebuje. Najprv loopback a odpovede, potom administratívnu cestu, potom naslúchač tunela, potom politiku presmerovania pre klientov:

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

Názvy rozhraní, port a pool sú zástupné; čítajte ich zo servera namiesto kopírovania. Uloženie výsledku je rovnako dôležité ako jeho napísanie, pretože sada pravidiel žijúca len v pamäti zmizne pri ďalšom reštarte a potichu hostiteľa znova otvorí. Zabezpečte trvalosť mechanizmom distribúcie a kópiu držte mimo stroja pre deň, keď sa stroj nenabootuje.

Zatvoriť posledný port bez straty hostiteľa

V návrhu je háčik. Ak SSH existuje iba cez tunel, zlyhaná služba VPN vezme SSH so sebou a jediná cesta späť môže byť konzola, ktorú ste nikdy neotvorili. Pred zatvorením posledného verejného portu overte, že tá konzola existuje a že ju naozaj viete použiť, alebo si ponechajte jednu úzku administratívnu cestu nezávislú od tunela: SSH z pevnej adresy, iba kľúče, autentifikácia heslom vypnutá.

Zmenu aplikujte z už nadviazanej relácie, nie cez spojenie, ktoré sa chystáte filtrovať. Naplánujte návrat, aby chyba vypršala, a nie aby sa stala trvalou, napríklad úlohu systemd-run --on-active=10min, ktorá obnoví predchádzajúcu sadu pravidiel, a druhú SSH reláciu držte otvorenú, kým testujete prvú. Potom overte, že úloha návratu sa skutočne spustí, pretože netestované obnovenie je to isté ako žiadne obnovenie.

Overte cestu, nie skript

Čítajte načítané pravidlá, nie súbor, ktorý ich mal načítať. Z oprávneného vonkajšieho hostiteľa potvrďte, že odpovedajú iba zamýšľané porty; zvnútra tunela potvrďte, že služby, ktoré ste chceli publikovať, sú dostupné. Politika zakázania v predvolenom nastavení, ktorá blokuje aj prevádzku tunela, vyzerá rovnako ako fungujúce uzamknutie, kým to niekto neskúsi použiť.

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

Zapíšte povolený port, pool klientov, rozhranie tunela, administratívny zdroj a postup s konzolou vedľa konfigurácie. Ďalšia zmena poolu alebo názvu rozhrania sa musí prejaviť vo filtri aj v pravidle NAT, inak sa hostiteľ vráti do polootvoreného stavu, a nikto si to nevšimne.

Jeden zvyk je cennejší ako sada pravidiel: po každej zmene dokážte cestu presmerovania požiadavkou klienta a cestu obnovy druhou reláciou. Uzamknutie, ktoré ste nepoužili, je iba hypotéza.