Ugunsmūra noteikumi tikai NEW neaizver visus WAN ceļus

Jaunu izejošo savienojumu noraidīšana WAN tīklā izskatās kā politika, kas aizveras kļūmes gadījumā, taču tas ir šaurāks solījums, nekā šķiet. Paketes, kas pieder jau esošām plūsmām, tam neatbilst, un arī daudzas atbildes. Šo robu ir viegli palaist garām, jo noteikums tiek lasīts tā, it kā tas aptvertu saskarni, nevis vienu savienojuma stāvokli uz tās. Un stāvokļa atbilstības lasīšana kā sprieduma rada nepatiesu aizvērtības sajūtu.

Stāvoklis ir atbilstības nosacījums, nevis spriedums

Savienojumu izsekošana klasificē paketes pēc tā, ko ugunsmūris jau ir redzējis, nevis pēc tā, kam tic lietojumprogramma. Plūsma, kas novērota abos virzienos, ir izveidota, un tās vēlākās paketes paliek izveidotas arī tad, kad maršruts zem tās mainās no tuneļa uz parasto augšupējo līniju. Arī atbilde uz ienākošu savienojumu var būt izveidota plūsma. Šīs paketes nekad atkal nekļūst jaunas.

Tāpēc noteikums, kas attiecas tikai uz jauniem savienojumiem, nevar pierādīt, ka katra aizsargātā pakete tiek bloķēta. Tas atstāj pārējos stāvokļus tam, ko ar tiem dara pārējais noteikumu kopums, un tas var būt atļauja, kas ievietota agrāk ķēdē.

Lasiet noteikumu tā apkārtnē

Plaša atļauja izveidotajai un saistītajai plūsmai, kas ievietota pirms bloķēšanas, palaiž paketi garām, pirms bloķēšana vispār tiek novērtēta. Stāvokļa nosacījuma noņemšana no vēlāka noteikuma to nemainīs, jo novērtējums nekad to nesasniedz. Rezultātu izšķir secība, un to, kuras paketes sasniedz šo secību, izšķir stāvokļa atbilstība.

Pārbaudiet faktisko noteikumu kopumu, nevis failu, ko rediģējāt, tostarp lēcienus citās ķēdēs un visu, ko ģenerē platforma. Maršrutētājā, ko pārvalda iptables, ķēdes uzskaitījums parāda noteikumu definīcijas, un arī ķēdes, uz kurām tas atsaucas, ir jāseko. Vietējai nftables sistēmai ir jāpārbauda savs noteikumu kopums un āķu prioritātes, jo programmaparatūra reti ģenerē identiskas ķēdes.

Skaitītāji parāda, kurš noteikums faktiski atbilda, un tie parasti ir informatīvāki par pakešu uztveršanu, kas veikta pēc lēmuma. Noteikums ar nulles skaitītāju nav sasniegts, lai ko arī liecinātu tā pozīcija.

Izsakiet aizliegumu neatkarīgi no stāvokļa

Ja klientu grupai nekad nav jāsasniedz internets ārpus tuneļa, sakiet to tieši, nevis tuviniet ar vienu stāvokli. Noteikumam ir jāatlasa pēc avota, izejas un galamērķa, neatskaroties no savienojuma stāvokļa, un tam jāatrodas tur, kur neviena agrāka atļauja to nevar apiet. Tad pārvaldības piekļuve un vietējā tīkla izņēmumi iegūst savus skaidros noteikumus, tāpēc nodoms ir redzams politikā.

Izvēloties reject, nevis drop, mainās tas, kā neizdodas atbilstošā plūsma, un tas nepaplašina pakešu kopu, ko noteikums atlasa. Noraidīts savienojums un kluss noildze ir dažādi simptomi, kas norāda uz vienu un to pašu izvēli.

Politika, kas apzināti atļauj atbildes uz attālināti uzsāktu piekļuvi pāri WAN, ir aizstāvama. Tā vienkārši ir jāapraksta šādi, nevis jāpasniedz kā pilnīga izolācija tikai caur tuneli.

Pārbaudiet, kas patiešām ir grupā

Piemērs aptver pārsūtīto IPv4 plūsmu no viena prefiksa caur vienu saskarni. Tas neko nepasaka par IPv6, otru augšupējo līniju vai plūsmu, ko rada pats maršrutētājs. Maršrutētājs, kas darbojas kā DNS atrisinātājs, sūta savus augšupējos vaicājumus, un tie vispār neiet caur forward ķēdi.

Apstipriniet, ka aizsargātajiem klientiem joprojām ir adreses izvēlētā prefiksa ietvaros, jo ierīce, kas no tā izgājusi, ir tieša nejauši, nevis pēc politikas. Bloka paplašināšana uz visu LAN, nepārskatot izņēmumu dizainu, arī mēdz noņemt jūsu paša administratīvo ceļu.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Pēc tam izmēģiniet vecu plūsmu līdzās jaunai. Jauns savienojuma mēģinājums un jau aktīva divvirzienu pārnese uzvedas atšķirīgi saskaņā ar šo noteikumu, un tikai abu pārbaude parāda, kāda politika jums patiešām ir.