Firewallregler kun for NEW lukker ikke alle WAN-veje

At afvise nye udgående forbindelser på WAN ligner en politik med lukket fejl, men det er et snævrere løfte, end det ser ud til. Pakker, der hører til flows, som allerede findes, matcher den ikke, og det gør mange svar heller ikke. Hullet er let at overse, fordi reglen læses, som om den dækker grænsefladen og ikke én forbindelsestilstand på den. Og at læse tilstandsmatchningen som en dom er det, der skaber en falsk følelse af lukkethed.

Tilstand er en matchbetingelse, ikke en dom

Forbindelsessporing klassificerer pakker efter, hvad firewallingen allerede har set, ikke efter hvad applikationen tror. Et flow, der ses i begge retninger, er etableret, og dets senere pakker forbliver etablerede, selv når ruten nedenunder skifter fra en tunnel til den almindelige uplink. Et svar på en indgående forbindelse kan også være etableret trafik. De pakker bliver aldrig nye igen.

Derfor kan en regel, der kun gælder nye forbindelser, ikke fastslå, at hver beskyttet pakke blokeres. Den overlader de andre tilstande til, hvad resten af regelsættet gør ved dem, og det kan være en accept, der er placeret tidligere i kæden.

Læs reglen i dens omgivelser

En bred accept af etableret og relateret trafik, der er placeret før blokeringen, lukker en pakke igennem, før blokeringen overhovedet vurderes. At fjerne tilstandsbetingelsen fra en senere regel ændrer ikke det, fordi vurderingen aldrig når derhen. Rækkefølgen afgør resultatet, og tilstandsmatchningen afgør, hvilke pakker der når den pågældende rækkefølge.

Undersøg det effektive regelsæt i stedet for den fil, du redigerede, inklusive spring til andre kæder og alt, hvad platformen genererer. På en iptables-styret router viser en oplistning af kæden regeldefinitionerne, og de kæder, den henviser til, skal også følges. Et oprindeligt nftables-system kræver, at dets eget regelsæt og dets hookprioriteter undersøges, da firmware sjældent genererer identiske kæder.

Tællere fortæller, hvilken regel der faktisk matchede, og de er normalt mere oplysende end en pakkefangst taget efter beslutningen. En regel med en tæller på nul er ikke nået, uanset hvad dens placering antyder.

Udtryk forbuddet uafhængigt af tilstand

Hvis en gruppe klienter aldrig må nå internettet uden for tunnelen, så sig det direkte i stedet for at tilnærme det med én tilstand. Reglen skal vælge på kilde, udgang og destination uden at afhænge af forbindelsestilstand, og den skal stå, hvor ingen tidligere accept kan omgå den. Så får administrativ adgang og undtagelser for lokalnettet deres egne eksplicitte regler, og hensigten er synlig i politikken.

At vælge reject frem for drop ændrer, hvordan det matchede trafik fejler, og det udvider ikke det sæt pakker, reglen vælger. En afvist forbindelse og en stille timeout er forskellige symptomer, der peger på samme valg.

En politik, der med vilje tillader svar på fjerninitieret adgang over WAN, er forsvarlig. Den skal bare beskrives sådan i stedet for at blive fremstillet som total isolering kun gennem tunnelen.

Kontroller, hvem der faktisk er i gruppen

Eksemplet dækker videresendt IPv4-trafik fra et præfiks ud af én grænseflade. Det siger intet om IPv6, en anden uplink eller trafik, som routeren selv starter. En router, der fungerer som DNS-resolver, sender sine egne opstrømsforespørgsler, og de passerer slet ikke forward-kæden.

Bekræft, at de beskyttede klienter stadig har adresser inden for det valgte præfiks, fordi en enhed, der er flyttet ud af det, er direkte ved et uheld og ikke efter politik. At udvide blokeringen til hele LAN’et uden at gennemgå undtagelsesdesignet har også tendens til at fjerne din egen administrative vej.

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

Afprøv derefter et gammelt flow ved siden af et nyt. Et frisk forbindelsesforsøg og en allerede aktiv tovejsoverførsel opfører sig forskelligt under denne regel, og kun test af begge viser, hvilken politik du rent faktisk har.