Nav tun0? Saskaņojiet atšifrēto IPsec nftables ar meta ipsec

Jūs gaidāt tuneļa saskarni, meklējat to, un ugunsmūrī nav nekā, ar ko saskaņot. Tas ir normāli uz politikām balstītai vārtejai: šifrētā apmaiņa pienāk uz fizisko saskarni, un atšifrētais iekšējais pakets, kas pēc tam tiek pārsūtīts, arī tiek novērots kā pienākošs uz tās pašas saskarnes. tun0 nav, jo nekas to nav izveidojis.

Iekšējais pieprasījums joprojām ir atsevišķs pakets ar savu avotu, galamērķi un pakalpojumu, un kodols zina, no kuras drošības asociācijas tas iznāca. Tieši šīs zināšanas ugunsmūra noteikums var saskaņot.

Divi paketi, viena saskarne

Iedomājieties ienākošo virzienu. Pienāk ESP vai UDP iekapsulēts pakets, kodols atrod atbilstošo politiku, atšifrē to un nodod skaidro paketu pārsūtīšanas ceļam. Noteikums, kas skatās tikai uz saskarnes nosaukumu, nevar atšķirt šo paketu no jebkuras citas plūsmas, kas pienāk pa to pašu vadu.

To atšķir paketam pievienotais ienākošā drošības ceļa konteksts. nftables to parāda kā meta ipsec exists, kas ir patiess, kad pakets pienācis pa IPsec drošības ceļu. Apvienojiet to ar klientu kopu, galamērķi un pakalpojumu, un noteikums kļūst pietiekami konkrēts, lai būtu drošs.

Konteksta izlaišana ir izplatīta kļūda, un tā ir drošības, nevis kosmētiska kļūda. Noteikums, kas pieņem visu no klientu kopas, tikpat labprāt pieņem viltotu paketu no vietējā tīkla, jo avota adrese pati par sevi nav nekā pierādījums. Drošības ceļa konteksts ir lētākais veids, kā padarīt avotu jēgpilnu. Rakstiet noteikumu ar to jau no sākuma, nevis pievienojiet pēc audita.

Uzrakstiet pārsūtīšanas noteikumu

Pieņemsim, ka ir autentificēts IPv4 attālinātās piekļuves pakalpojums ar klientiem 10.90.0.0/24 tīklā un viens apstiprināts galamērķis 203.0.113.40 adresē. Šīs plūsmas noteikuma fragments izskatās šādi.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Adreses un saskarne ir aizstājami piemēri. Ievietojiet pārbaudīto ekvivalentu pārsūtīšanas politikā pirms noteikuma, kas citādi noraidītu plūsmu, un neiztīriet esošo noteikumu kopu, lai to instalētu; vārteja nav tīras telpas eksperiments.

Terminu oifname ir vērts paturēt. Tas dokumentē izejas lēmumu un neļauj noteikumam saskaņoties virzienā, kuru neesat paredzējis, un tas ir svarīgi vārtejā ar vairākiem ceļiem uz internetu. Viena augšupielādes kanāla testa kastē termins šķiet lieks, un tieši tāpēc to noņem, pirms kaste iegūst otru kanālu.

Atļaujas ārējai apmaiņai ir atsevišķas. Vārtejas ievades ceļam ir vajadzīgi tie IKE un ESP vai UDP iekapsulēšanas porti, ko tā faktiski izmanto, un šīs atļaujas neko neļauj attiecībā uz iekšējo atšifrēto paketu. Abu sajaukšana ir ceļš, kā strādājošs tunelis nonāk pie ugunsmūra, kas pārsūta visu.

Ienākošais konteksts nav izejošais konteksts

Tā pati izteiksmju saime aptver otru virzienu ar rt ipsec, kas apraksta izejošo drošības asociāciju, ko pakets izmantos. Tas atbild uz citu jautājumu: nevis no kurienes šis pakets nāca, bet vai tas būs aizsargāts nākamajā posmā.

Šī atšķirība ir svarīga vārtejā, kas vienlaikus pabeidz vienu tuneli un pārsūta uz citu. Pakets var pienākt atšifrēts un tomēr tam jāiziet šifrētam, un pieņemšana, kas rakstīta tikai ienākošajam kontekstam, neko neizsaka par izejošo prasību. Ja politika prasa šo aizsardzību, noteikumu kopai tas jāizsaka, nevis jāpieņem, ka maršrutēšana to atrisinās.

Turiet abus jautājumus atsevišķos noteikumos, lai lasītājs redzētu, kurš tiek piemērots. Viens gudrs noteikums, kas pārbauda abus, ir grūtāk pārskatāms un daudz grūtāk atkļūdojams, kad viena tā puse pārstāj saskaņoties. Divi noteikumi ar skaitītājiem arī pasaka, kura prasība neizpildās, ko viens apvienots noteikums nekad neizdarīs.

NAT nav ugunsmūra lēmums

Plūsmai uz internetu no privātas klientu kopas parasti vajadzīga avota tulkošana, lai atbilde atrastu ceļu atpakaļ. Bet plūsmai, kas izvēlēta citai izejošai IPsec politikai, jāsaglabā nepieciešamais izņēmums, un katra privātā avota maskēšana, nedomājot par nākamo aizsardzības lēmumu, to salauž.

Pieņemšana NAT ķēdē arī nav vispārēja atļauja. NAT un filtrēšanai ir dažādi uzdevumi, un NAT ķēde nepārbauda katru vēlāko izveidotas plūsmas paketu, un tieši tāpēc paļaušanās uz to drošības jautājumos rada noteikumus, kas šķietami darbojas testā un neizdodas slodzes laikā.

Pretējais arī ir taisnība un pārsteidz cilvēkus: pieņemšanai kaut kur vienā filtra pamatķēdē nav nekāda svara pret vēlāku noraidīšanu citā piemērojamā ķēdē. Rezultātu izšķir secība un ķēdes apjoms, nevis pieņemšanas esamība failā.

Pārbaudiet precīzo iekšējo pakalpojumu

Pārbaudiet konkrēto galamērķi un portu, ko atļāvāt, no reāla klienta un apstipriniet, ka atbilde nāk atpakaļ. Pēc tam pārbaudiet kaut ko tādu, ko neesat atļāvis, un pārliecinieties, ka tas neiziet, jo pārāk plašs noteikums iztur pirmo testu tikpat labi kā pareizs. Pieprasījums, kas nekad neiziet no klienta, arī nav ugunsmūra rezultāts, tāpēc lasiet skaitītājus, lai redzētu, vai pakets vispār tika novērtēts. Divi testi un viens skaitītāja nolasījums pateiks vairāk nekā visa pēcpusdiena, kas pavadīta, lasot noteikumu kopu.

nftables uzziņa dokumentē meta ipsec, rt ipsec un virzienam raksturīgās izteiksmes, un tieši tur jāpārbauda sintakse pret instalēto versiju. Un turiet apjomu skaidru: šis ir IPv4 piemērs, tas neko neizsaka par IPv6 un nepārvērš patvaļīgu publisko portu pārsūtīšanu par VPN pakalpojuma daļu.