Zaštitni zid na VPS-u: otvorite samo VPN port, zatim to dokažite

Jedan port mora ostati javan, inače se nijedan klijent ne povezuje. Odbijte sve ostalo, držite prosljeđivanje odvojeno od ulaza i ostavite put oporavka koji ste unaprijed isprobali.

Zaštitni zid koji propušta samo VPN port nije jedno pravilo. To su tri odvojene odluke koje se slučajno tiču istog broja porta: lanac za ulaz odlučuje što može doći do lokalnog procesa, lanac za prosljeđivanje odlučuje što može proći kroz host u ime klijenata tunela, a NAT tablica prepisuje adresu izvora na izlazu. Pogriješite li u jednoj, rezultat rijetko je čist prekid. Dobit ćete host koji prihvaća klijente, ali ništa ne učitava, ili host koji izgleda zatvoren dok netko ne pročita redoslijed lanaca.

Jedini port koji se ne može zatvoriti

Slušatelj VPN-a mora prihvaćati veze s adresa koje ne možete predvidjeti, pa je po definiciji javna usluga. To je jedina iznimka na kojoj je dizajn izgrađen: jedan UDP port za OpenVPN, jedan UDP port za WireGuard, jedan TCP port za SSL VPN. Sve ostalo pripada iza tunela, što znači da se aplikacijske usluge trebaju vezati na adresu tunela ili na loopback, a ne na svako sučelje.

Vezanje, međutim, nije provedba. Proces vezan na 0.0.0.0 dostupan je samo ako ga pravilo propušta, a zadano pravilo je rezerva za promet koji nije uhvatilo nijedno pravilo, a ne pravilo koje upravlja portom. Pravilo propuštanja iznad vašeg odbacivanja i dalje je propuštanje, a premještanje usluge s javne adrese nezavisno je poboljšanje, a ne zamjena za lanac.

Ulaz, prosljeđivanje i NAT odgovaraju na različita pitanja

Ulazni promet namijenjen je samom hostu, pa tu žive slušatelj VPN-a i administrativni put. Promet za prosljeđivanje prolazi kroz host i klijentima tunela treba on, plus net.ipv4.ip_forward=1. Klasična napola ispravna konfiguracija propušta odlazni tok i zaboravlja povratni smjer, pa klijent završi rukovanje i zatim se ništa ne učitava; pravilo conntrack za uspostavljeni i povezani promet pokriva taj smjer.

NAT je treće pitanje. Bez prepisivanja u postroutingu proslijeđeni paketi odlaze s privatnim izvorom tunela i bivaju odbačeni dalje uzvodno, jer nijedna mreža izvan hosta ne zna usmjeriti bazen natrag. Izvorni prefiks u tom pravilu mora odgovarati bazenu VPN-a, a ne vlastitoj adresi hosta, i isto vrijedi za pravilo prosljeđivanja koje imenuje podmrežu klijenata.

IPv6 je druga politika, a ne naknadna misao. Host sa strogim lancem IPv4 i otvorenom politikom ip6tables nije ništa zatvorio; usluge su i dalje dostupne kroz drugu adresnu obitelj. Ili preslikajte skup pravila s ip6tables ili namjerno isključite IPv6 na javnom sučelju, i zapišite što ste odabrali.

Osnovna linija koju pročitate u jednom prolazu

Počnite od odbacivanja, zatim dodajte samo ono što hostu treba. Prvo loopback i odgovori, zatim administrativni put, zatim slušatelj tunela, zatim politika prosljeđivanja za klijente:

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

Nazivi sučelja, port i bazen su rezervirana mjesta; pročitajte ih s poslužitelja umjesto da ih kopirate. Spremanje rezultata jednako je važno kao i pisanje, jer skup pravila koji živi samo u memoriji nestaje pri sljedećem podizanju sustava i tiho ponovno otvara host. Učinite ga trajnim mehanizmom svoje distribucije i držite kopiju izvan stroja za dan kada se stroj ne bude mogao podići.

Zatvaranje posljednjeg porta bez gubitka hosta

U dizajnu postoji zamka. Ako SSH postoji samo kroz tunel, neuspjela VPN usluga odnosi SSH sa sobom, a jedini put natrag može biti konzola koju nikada niste otvorili. Prije nego zatvorite posljednji javni port, provjerite da ta konzola postoji i da je doista možete koristiti, ili zadržite jedan uski administrativni put koji ne ovisi o tunelu: SSH s fiksne adrese, samo ključevi, autentifikacija lozinkom isključena.

Primijenite promjenu iz već uspostavljene sesije, a ne kroz vezu koju ćete filtrirati. Zakažite vraćanje kako bi pogreška istekla umjesto da postane trajna, na primjer posao systemd-run --on-active=10min koji vraća prethodni skup pravila, i držite drugu SSH sesiju otvorenom dok testirate prvu. Zatim provjerite da se posao vraćanja doista pokreće, jer neprovjereni oporavak isto je što i nikakav oporavak.

Provjerite put, a ne skriptu

Čitajte učitana pravila, a ne datoteku koja ih je trebala učitati. S ovlaštenog vanjskog hosta potvrdite da odgovaraju samo predviđeni portovi; iz unutrašnjosti tunela potvrdite da su usluge koje ste htjeli objaviti dostupne. Politika odbacivanja po zadanom koja blokira i promet tunela izgleda jednako kao radno zatvaranje dok je netko ne pokuša koristiti.

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

Zapišite dopušteni port, bazen klijenata, sučelje tunela, administrativni izvor i postupak s konzolom uz konfiguraciju. Sljedeća promjena bazena ili naziva sučelja mora se uskladiti i u filtru i u NAT pravilu, inače se host vraća u napola otvoreno stanje, a da to nitko ne primijeti.

Jedna navika vrijedi više od skupa pravila: nakon svake promjene dokažite put prosljeđivanja klijentskim zahtjevom, a put oporavka drugom sesijom. Zatvaranje koje niste koristili samo je hipoteza.

Povezani članci