Ierobežot OpenVPN vārteju ar vienu LAN, izmantojot UFW noteikumus

Izlemiet atļauju pirms ugunsmūra faila atvēršanas: autentificēti klienti drīkst atvērt savienojumus uz vienu konkrētu apakštīklu, un vārtejai ir jānoraida jebkurš cits tranzīta ceļš, pat ja klients instalē papildu maršrutus. Šis teikums ir projekts, un katrs noteikums zemāk pastāv, lai to īstenotu. Kaut kas plašāks, piemēram, visa privātā adrešu telpa, izeja internetā caur tuneli vai vienādranga trafiks, ir cits projekts, kam nepieciešams savs lēmums. Noteikumi arī apzināti ir garlaicīgi, jo gudrs ugunsmūris ir tāds, kuru vēlāk neviens nevar auditēt.

Vispirms pierakstiet topoloģiju un atļauju

Piemērā izmantots Community OpenVPN serveris ar lietotāja telpas TUN ierīci, kas nosaukta tun0, klientu peldbaseins 10.77.0.0/24, un viens pievienots apakštīkls 192.168.60.0/24 saskarnē lan0. IPv4 pārforwardēšana jau darbojas, un LAN jau ir atgriešanās maršruts uz peldbaseinu, tāpēc nekas šeit nav atkarīgs no tulkošanas starp tiem.

Ugunsmūris šajā resursdatorā pieder UFW, un neviens konteineru noteikumu kopums vai atsevišķa nftables tabula nedrīkst uzstādīt agrāku pieņemšanas ceļu. Plūsmas atkraušanas apvedceļš, kas apiet filtru, padarītu aizsardzības ķēdes par dekorāciju, tāpēc pārliecinieties, ka neviena nav aktīva. Atstājiet OpenVPN paša client-to-client pārforwardēšanu izslēgtu, jo vienādranga trafiku, kas nekad nešķērso operētājsistēmas filtru, ar to nevar ierobežot. Ārējais klausītājs un administrēšanas noteikumi paliek kā ir, jo šī izmaiņa pārvalda atšifrētu tuneļa trafiku, nevis aizstāj ugunsmūri.

Novietojiet sargus pirms UFW agrīnajām pieņemšanām

Maršruta atļauja un tai sekojošs noraidījums nav pietiekams stingrai robežai. Standarta before noteikumi pieņem nodibinātu trafiku un dažus ICMP vēl pirms jebkura lietotāja noteikuma izskatīšanas, tāpēc pagājušajā nedēļā atļauta plūsma var palikt ārpus jaunā galamērķa ierobežojuma tikai tāpēc, ka tai vēl ir stāvoklis. Izveidojiet UFW failu dublējumu un pirms rediģēšanas turiet atvērtu ārpusjoslas konsoli.

Faila *filter sadaļā /etc/ufw/before.rules deklarējiet divas ķēdes blakus esošajām deklarācijām un pirms jebkuras noteikuma rindas.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Tūlīt pēc deklarācijām un pirms ievades un pārforwardēšanas atļaujām ielēciet tajās un definējiet, ko tās ielaiž.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Saglabājiet pārējo sadaļu un tās COMMIT rindu. Otras filtra tabulas ielīmēšana vai nesaistītu noteikumu dzēšana ir ceļš, kā ugunsmūra izmaiņa kļūst par pārtraukumu, un fails ir vienu pārstartēšanu no tā, lai kļūtu par vienīgo kopiju, kam ir nozīme.

Izlasiet, ko katrs sargs ielaiž un noraida

Pirmā ķēde turpina apstrādi tikai tad, kad avots ir peldbaseinā, galamērķis ir tas viens apakštīkls, izejas saskarne ir LAN un pakete pārvietojas sākotnējā savas plūsmas virzienā. Viss pārējais, kas nāk no tuneļa, tiek izmests, tostarp avots ārpus peldbaseina un jebkurš galamērķis aiz atļautā apakštīkla.

Vienādranga pakete ieiet un iziet tun0, tāpēc tā neiztur LAN saskarnes testu vēl pirms galamērķa pārbaudes. Jauni savienojumi no LAN uz klientiem arī neiztur atbildes virziena testu, kas pēc noklusējuma aizver apgriezto atzvanīšanas ceļu.

Mērķis RETURN saglabā parasto UFW politiku spēkā. Šīs ķēdes filtrē, un tālāk pievienotā maršruta atļauja joprojām izlemj, vai izdzīvojusī pakete tiks pieņemta. Tieši šī atdalīšana ļauj vēlāk vienā vietā mainīt atļauto apakštīklu. Ja sargi pieņemtu paketes tieši, katrs nākamais noteikums būtu jāpievieno divreiz.

Atļaujiet apakštīklu un aizveriet sānu durvis

Vispirms priekšskatiet maršruta atļauju, pēc tam noņemiet priekšskatījuma karodziņu, lai to piemērotu: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Pēc tam pārskatiet lietotāja noteikumu secību, jo agrāks noraidījums joprojām uzvar vēlāku atļauju. Atļauja visam apakštīklam arī ir nepareiza forma, kad jābūt pieejamam tikai viena resursdatora HTTPS portam.

Ievērojiet, ko dara ievades nomešana: tuneļa klienti nevar sasniegt nevienu pakalpojumu pašā vārtejā, tostarp DNS klausītāju, kas piesaistīts tās LAN adresei. DNS mitināšana tur prasa apzinātu izņēmumu pirms nomešanas un pārskatītu atļaujas līgumu. Ja UFW pārvalda IPv6, pievienojiet atbilstošas nomešanas arī tun0 failā before6.rules, jo IPv4 galamērķu saraksts neko nepasaka par IPv6 paketēm.

Pārbaudiet ielādēto politiku, nevis priekšskatījumu

Priekšskatiet pārlādi, piemērojiet to apkopes logā un izlasiet dzīvo noteikumu kopumu.

sudo ufw --dry-run reload
sudo ufw show raw

Pārliecinieties, ka tuneļa sargi parādās pirms noklusējuma stāvokļa un ICMP atļaujām. Vienkāršs ufw status nerāda ar roku rediģētus before noteikumus, tāpēc operatori secina, ka noteikums trūkst, lai gan tas patiesībā ir ielādēts. Lasiet neapstrādāto sarakstu no augšas uz leju, nevis meklējiet fragmentu. Ja sargi parādās pēc stāvokļa atļaujas, robeža nedara to, ko liek domāt fails.

Pēc tam testējiet uzvedību, nevis tekstu. Atveriet jaunu savienojumu ar atļautu resursdatoru un vērojiet atbildi, nosūtiet nekaitīgu pieprasījumu uz galamērķi ārpus apakštīkla un pārliecinieties, ka tas mirst, izmēģiniet vienādranga savienojumu, izmēģiniet vārtejā lokālu pakalpojumu un izmēģiniet nepieprasītu LAN-uz-klientu savienojumu. Iekļaujiet vienu ārpus tvēruma plūsmu, kas pastāvēja pirms izmaiņas, un notīriet tikai šo plūsmu, nevis iztukšojiet visu mašīnas izsekošanas tabulu.

Pierakstiet ierobežojumus blakus noteikumiem: tas ierobežo tranzītu un neko citu. Tas neliedz klientam izmantot savu interneta savienojumu, neliedz atļautam LAN resursdatoram pārsūtīt trafiku tālāk un neaizstāj autentifikāciju atļauto pakalpojumu iekšienē.