A minden portot továbbító szabályok elnyelhetik a WireGuard listeneredet

Egy nyilvános átjáró már futtat WireGuardot UDP 51820-on, SSH-t a 22-es porton és egy alkalmazást, amelynek elérhetőnek kell lennie az internetről. A csábító szabály minden portot továbbít a peernek, és késznek nyilvánítja a munkát. Egy WireGuard átjárón ez a szabály elkaphatja magának az alagútnak a forgalmát, és kizárhat abból a gépből, amely lezárja. A közzététel vezérlési sík kivételével hozott útválasztási döntés, nem egyetlen DNAT sor.

Nyilvános belépés vagy alagútbelépés: válassz egyet

Egy szolgáltatás közzététele új belépési pontot hoz létre az interneten. Ez nem ugyanaz, mint VPN-tagságot adni egy peernek, mert a látogató soha nem lép be az alagútba, és az átjáró lesz a háttérszolgáltatás nyilvános arca. Ez a különbség dönti el a szabály közönségét és a tanúsítványát.

Az adminisztratív felületek ritkán tartoznak oda. Az engedélyezett VPN-kliensek által elért adminisztrációs oldal az alagúton belül tartja a támadási felületet, és elkerüli, hogy egy bejelentkezési űrlapot tetszőleges vizsgálatnak tegyen ki. A nyilvános alkalmazásvégpontoknak továbbra is saját TLS-tanúsítványra, hitelesítésre és sebességkorlátozásra van szükségük; a titkosított WireGuard ugrás nem védi a látogató átjáróig tartó szakaszát.

Ha a szolgáltatásnak valóban nyilvánosnak kell lennie, írd le a hosztnevet, az azt lefedő tanúsítványt és azokat a látogatói tartományokat, amelyeknek el kell érniük. Ez a három tény dönti el később a szabály alakját és a szűrési szabályzatot. Minden, ami ezeken kívül esik, hatóköri túlterjeszkedés egy nyilvános listeneren.

Egy port be, egy háttérszolgáltatás ki

Használj egyetlen nyilvános portot és egyetlen háttérszolgáltatást. Ebben a példában az eth0 hordozza a nyilvános 198.51.100.20 címet, az átjáró alagútcíme 10.200.0.1, a peer pedig a 10.200.0.7-es címen futtatja az alkalmazást. A nyilvános TCP 9443 a peer TCP 8443-as portjára képeződik le:

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

Az SNAT-szabály illeszkedik a lefordított háttérszolgáltatásra és az eredeti nyilvános célra, így az ugyanahhoz a háttérszolgáltatáshoz menő másik kapcsolat e leképezésen kívül marad. Elrejti a látogató címét a peer elől is, és ez az a kompromisszum, amely miatt a forrást megőrző irányított visszaút külön tervezés. Az iptables-kiterjesztések referenciája mindkét célt és azok illesztési beállításait dokumentálja.

A továbbítást továbbra is engedélyezni kell, a szűrőláncnak pedig engedélyre van szüksége a lefordított célra és portra, valamint a létrejött válaszokra. A FORWARD lánc a DNAT utáni lefordított célt látja, ezért a nyilvános címre írt szabály nem illeszkedik a továbbított csomagra. Az engedélyt a háttérszolgáltatás rekordjára írd, ne a nyilvánosra.

A peernek el kell fogadnia a szolgáltatás kapcsolatát az átjáró alagútcíméről, és a választ az alagúton keresztül kell visszaküldenie. Az AllowedIPs-ének engedélyeznie kell azt a forrást, amelyet ténylegesen kap, ami forrásfordítás mellett az átjáró alagútcíme, és ehhez a tervezéshez nincs szükség széles 0.0.0.0/0 bejegyzésre minden peeren. A visszirányú forgalmat az dobja el, ha egy peer listájából hiányzik ez a cím, vagy ha egy forrásmegőrző tervezés a látogató saját címét továbbítja helyette, ezért azt a forrást ellenőrizd, amelyet a peer valóban lát, ne a szabályodban szereplőt.

Tartsd az átjáró saját listenerjeit a szabályon kívül

Cseréld a portillesztést minden TCP- és UDP-célra kiterjedő szabályra, és az átjáró saját WireGuard-socketje a hatókörébe esik. A célfordítás azelőtt történik, hogy a gép eldöntené, hogy egy csomag helyi, ezért az UDP 51820 a peerhez kerülhet ahelyett a folyamat helyett, amely minden peer-kapcsolatot tart. A szabály hibátlanul betöltődik, és az alagút meghal, ami a peer oldaláról nehezen olvasható hiba.

Az SSH, a megfigyelő ügynökök és minden más, az átjárón futó szolgáltatás ugyanilyen kitettséggel bír. A mindent továbbító szabály nem különbözteti meg a vezérlési síkot a közzétett alkalmazástól, és a módosítás utáni első újraindítás az a pillanat, amikor a kizárás nyilvánvalóvá válik. A mindent elkapó szabály nem figyelmeztet arra a szolgáltatásra, amelyet csendben átvesz. Akkor tudod meg, amikor a következő kapcsolat meghiúsul.

Ha a széles továbbítás valóban szükséges, foglald le a vezérlőportokat a mindent elkapó szabály előtt, vagy használj külön nyilvános címet a közzétételhez. A második lehetőség tisztább, mert a vezérlőcím megtartja saját szabályzatát, de a szolgáltatónak biztosítania kell azt a címet; egy DNS-rekord hozzáadása nem oszt ki címet.

A széles TCP- és UDP-továbbítás sem jelenti az összes protokollt. Az ICMP, az IPv6, a path-MTU visszajelzés és a külső VPN-forgalom saját szabályzatot igényel, és a TCP-t és UDP-t lefedő szabály ezeket az alapértelmezett láncra hagyja.

Válaszd ki a modellt, mielőtt szabályokat írsz

Négy forma lefedi az átjáróról történő közzétételek többségét, és a választás attól függ, hány szolgáltatást futtatsz, és mennyi vezérlési sík kockázatot tudsz elviselni. Az alábbi táblázat a legszűkebbtől a legszélesebbig rendezi őket.

Kezdd a szűk modellel akkor is, ha később több szolgáltatásra számítasz. Ezt a legkönnyebb auditálni, és egy szűk szabálykészletet átalakítani egy átnézett, mindent elkapó szabállyá egyszerűbb, mint kideríteni, melyik listenert kapta el egy széles szabály. Bármelyik modellt választod, a szabályokat a tűzfal tulajdonosánál tartsd. Az iptables-sorok alkalmazása egy olyan UFW- vagy nftables-konfiguráció mellett, amely ugyanazokat a láncokat kezeli, olyan szabályzatot eredményez, amely a rendszerindítás sorrendjétől függően változik.

Bizonyítsd a közzétételt és a vezérlési útvonalat is

Tesztelj egy engedélyezett külső kliensről a jóváhagyott hosztnévvel és az ahhoz érvényes tanúsítvánnyal. Erősítsd meg, melyik háttérszolgáltatás válaszolt, majd ellenőrizd, hogy a nem kapcsolódó nyilvános portok továbbra is elutasítottak. A letiltott tanúsítvány-ellenőrzés nem sikeres HTTPS-teszt, és a rossz háttérszolgáltatáshoz érkező kapcsolat rosszabb a sikertelennél.

Ezután ellenőrizd magát az átjárót: csatlakoztass egy WireGuard-peert, nyiss egy SSH-munkamenetet, és erősítsd meg, hogy a megfigyelés továbbra is jelent. A közzétett szolgáltatás akkor is működhet, amikor a vezérlési sík törött, ezért mindkét ellenőrzés ugyanabba a változtatási ablakba tartozik. Indítsd újra egyszer, hogy bizonyítsd a szabályok várt sorrendben történő újraalkalmazását, majd vond vissza a közzétételt, és erősítsd meg, hogy az eltávolítás valóban megfelel a hozzáadásnak. A rendszerindításkor végzett nagy számú hozzáadás hiányos takarítással az, ahogy egy ideiglenes teszt állandó nyílássá válik.