Kõiki porte hõlmav edastus võib sinu WireGuard-kuulaja alla neelata

Avalik lüüs käitab juba WireGuardi UDP pordil 51820, SSH-d pordil 22 ja üht rakendust, mis peab olema internetist kättesaadav. Ahvatlev reegel edastab iga pordi peerile ja loeb asja lõpetatuks. WireGuard-lüüsil võib see reegel haarata tunnelil enda transpordi ja lukustada sind välja masinast, mis selle lõpetab. Avaldamine on marsruutimisotsus juhtimistasandi erandiga, mitte üks DNAT-rida.

Avalik sissepääs, tunneli sissepääs: vali üks

Teenuse avaldamine loob uue interneti sissepääsupunkti. See ei ole sama, mis VPN-liikmelisuse andmine peerile, sest külastaja ei liitu kunagi tunneliga ja lüüsist saab backendi avalik nägu. See erinevus määrab reegli sihtrühma ja selle sertifikaadi.

Haldusliidesed kuuluvad sinna harva. Administraatori leht, kuhu jõuavad volitatud VPN-kliendid, hoiab ründepealispinna tunneli sees ja väldib sisselogimisvormi paljastamist suvalisele skaneerimisele. Avalikud rakenduse lõpp-punktid vajavad endiselt oma TLS-sertifikaati, autentimist ja kiiruse piiramist; krüpteeritud WireGuard-hüpe ei kaitse külastaja lõiku lüüsini.

Kui teenus peab tõesti avalik olema, kirjuta üles hostinimi, seda kattev sertifikaat ja külastajate vahemikud, mis peaksid selleni jõudma. Need kolm fakti määravad hiljem reegli kuju ja filtreerimispoliitika. Kõik väljaspool neid on ulatuse laienemine avalikul kuulajal.

Üks port sisse, üks backend välja

Kasuta üht avalikku porti ja üht backend-teenust. Selles näites kannab eth0 avalikku aadressi 198.51.100.20, lüüsi tunneli aadress on 10.200.0.1 ja peer käitab rakendust aadressil 10.200.0.7. Avalik TCP 9443 vastendatakse peeri TCP-le 8443:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

SNAT-reegel sobib tõlgitud backendiga ja algse avaliku sihtkohaga, nii et teine ühendus sama backend-teenusega jääb sellest vastendusest välja. See peidab ka külastaja aadressi peeri eest ja see on kompromiss, mis teeb allikat säilitava marsruuditud tagasipöördumise eraldi lahenduseks. iptablesi laienduste viide dokumenteerib mõlemad sihtmärgid ja nende sobivusvalikud.

Edastamine tuleb endiselt lubada ja filtrite ahel vajab luba tõlgitud sihtkoha ja pordi ning loodud vastuste jaoks. FORWARD-ahel näeb tõlgitud sihtkohta alles pärast DNAT-i, seega avaliku aadressi vastu kirjutatud reegel ei sobi edastatud paketiga. Kirjuta luba backendi korteeži vastu, mitte avaliku vastu.

Peer peab teenuseühenduse vastu võtma lüüsi tunneli aadressilt ja saatma vastuse tunneli kaudu tagasi. Selle AllowedIPs peab autoriseerima allika, mille see tegelikult vastu võtab, mis allika tõlkimise korral on lüüsi tunneli aadress, ja laia 0.0.0.0/0 kirjet igal peeril selle lahenduse jaoks ei ole vaja. Tagasiliikluse maha viskab peer, mille nimekiri selle aadressi välja jätab, või allikat säilitav lahendus, mis edastab hoopis külastaja enda aadressi, seega kontrolli allikat, mida peer tegelikult näeb, mitte seda, mis on sinu reeglis.

Hoia lüüsi enda kuulajad reeglist väljas

Asenda pordi sobivus reegliga, mis katab iga TCP ja UDP sihtkoha, ja lüüsi enda WireGuard-pesa jääb selle alla. Sihtkoha tõlkimine toimub enne, kui masin otsustab, et pakett on kohalik, seega UDP 51820 võib jõuda peerile, mitte protsessile, mis hoiab iga peeri ühendust. Reegel laaditakse edukalt ja tunnel sureb, mida on peeri poolelt raske lugeda.

SSH-l, monitooringuagentidel ja igal muul lüüsil majutatud teenusel on sama kokkupuude. Reegel, mis edastab kõik, ei erista juhtimistasandit avaldatud rakendusest ja esimene taaskäivitus pärast muudatust on hetk, mil lukustamine ilmseks saab. Kõike hõlmav reegel ei hoita teenuse eest, mille ta vaikselt üle võtab. Sa avastad selle siis, kui järgmine ühendus ebaõnnestub.

Kui lai edastus on tõesti vajalik, broneeri juhtimispordid enne kõike hõlmavat reeglit või kasuta avaldamiseks eraldi avalikku aadressi. Teine valik on puhtam, sest juhtimisaadress hoiab oma poliitikat, kuid teenusepakkuja peab selle aadressi andma; DNS-kirje lisamine ei eralda ühtegi.

Lai TCP ja UDP edastus ei ole samuti kõik protokollid. ICMP, IPv6, tee-MTU tagasiside ja väline VPN-transport vajavad oma poliitikat ning TCP-d ja UDP-d kattev reegel jätab need juhtumid vaikeahelale.

Vali mudel enne reeglite kirjutamist

Neli kuju katavad enamiku lüüsi avaldamistest ja valik sõltub sellest, kui palju teenuseid sa käitad ja kui palju juhtimistasandi riski talud. Allolev tabel järjestab need kõige kitsamast kõige laiemani.

Alusta kitsa mudeliga ka siis, kui ootad hiljem rohkem teenuseid. Seda on kõige lihtsam auditeerida ja kitsaste reeglite komplekti muutmine ülevaadatud kõike hõlmavaks reegliks on lihtsam kui avastada, millise kuulaja lai reegel haaras. Millise mudeli ka valiksid, hoia reeglid tulemüüri omaniku juures. iptablesi ridade rakendamine UFW või nftablesi konfiguratsiooni kõrval, mis haldab samu ahelaid, loob poliitika, mis muutub sõltuvalt alglaadimise järjekorrast.

Tõesta nii avaldamine kui ka juhtimistee

Testi volitatud väliskliendist heakskiidetud hostinime ja selle jaoks kehtiva sertifikaadiga. Kinnita, milline backend vastas, seejärel kontrolli, et seostamata avalikud pordid jäävad keelatuks. Deaktiveeritud sertifikaadikontroll ei ole läbitud HTTPS-test ja vale backendini jõudev ühendus on hullem kui ebaõnnestunud.

Pärast seda kontrolli lüüsi ennast: ühenda WireGuard-peer, ava SSH-sessioon ja kinnita, et monitooring ikka raporteerib. Avaldatud teenus võib töötada, kui juhtimistasand on katki, seega kuuluvad mõlemad kontrollid samasse muudatuste aknasse. Taaskäivita korra, et tõestada, et reeglid rakendatakse uuesti oodatud järjekorras, seejärel eemalda avaldamine ja kinnita, et eemaldamine tõesti vastab lisamisele. Suur hulk käivitamisaegseid lisamisi puuduliku eemaldamisega on viis, kuidas ajutine test muutub püsivaks avauseks.