Brannmurregler bare for NEW stenger ikke alle WAN-veier

Å avvise nye utgående tilkoblinger på WAN ser ut som en policy som lukker ved feil, men det er et snevrere løfte enn det virker som. Pakker som hører til strømmer som allerede finnes, passer ikke på den, og det gjør heller ikke mange svar. Dette gapet er lett å overse fordi regelen leses som om den dekker grensesnittet og ikke én tilstand på det. Og å lese tilstandstreffet som en dom er det som skaper en falsk følelse av lukkethet.

Tilstand er en treffbetingelse, ikke en dom

Tilkoblingssporing klassifiserer pakker etter hva brannmuren allerede har sett, ikke etter hva applikasjonen tror. En strøm som observeres i begge retninger, er etablert, og de senere pakkene forblir etablerte selv når ruten under den skifter fra en tunnel til den vanlige oppstrømslinjen. Et svar på en innkommende tilkobling kan også være etablert trafikk. Disse pakkene blir aldri nye igjen.

Derfor kan en regel som bare gjelder nye tilkoblinger, ikke fastslå at hver beskyttet pakke blokkeres. Den overlater de andre tilstandene til det resten av regelsettet gjør med dem, og det kan være en tillatelse plassert tidligere i kjeden.

Les regelen i omgivelsene

En bred tillatelse for etablert og relatert trafikk plassert før blokkeringen slipper en pakke gjennom før blokkeringen i det hele tatt vurderes. Å fjerne tilstandsbetingelsen fra en senere regel endrer ikke det, fordi vurderingen aldri når dit. Rekkefølgen avgjør resultatet, og tilstandstreffet avgjør hvilke pakker som når den rekkefølgen.

Undersøk det effektive regelsettet i stedet for filen du redigerte, inkludert hopp til andre kjeder og alt plattformen genererer. På en iptables-styrt ruter viser opplisting av kjeden regeldefinisjonene, og kjedene den viser til, må også følges. Et innfødt nftables-system krever at dets eget regelsett og krokprioriteringene undersøkes, siden fastvaren sjelden genererer identiske kjeder.

Tellere viser hvilken regel som faktisk traff, og de er vanligvis mer informative enn en pakkefangst tatt etter avgjørelsen. En regel med teller på null er ikke nådd, uansett hva plasseringen antyder.

Uttrykk forbudet uavhengig av tilstand

Hvis en gruppe klienter aldri skal nå internett utenfor tunnelen, si det direkte i stedet for å tilnærme det med én tilstand. Regelen må velge på kilde, utgang og mål uten å avhenge av tilkoblingstilstand, og den må stå der ingen tidligere tillatelse kan omgå den. Da får administrativ tilgang og unntak for lokalnettet egne eksplisitte regler, slik at intensjonen er synlig i policyen.

Å velge reject i stedet for drop endrer hvordan den samsvarende trafikken feiler, og det utvider ikke settet med pakker regelen velger. En avvist tilkobling og en stille tidsavbrudd er forskjellige symptomer som peker på samme valg.

En policy som med vilje tillater svar på fjerninitiert tilgang over WAN, er forsvarlig. Den må bare beskrives slik i stedet for å presenteres som full isolasjon bare gjennom tunnelen.

Kontroller hvem som faktisk er i gruppen

Eksempelet dekker videresendt IPv4-trafikk fra ett prefiks ut av ett grensesnitt. Det sier ingenting om IPv6, en andre oppstrømslinje eller trafikk ruteren selv starter. En ruter som fungerer som DNS-løser, sender sine egne oppstrømsforespørsler, og de går ikke gjennom forward-kjeden i det hele tatt.

Bekreft at de beskyttede klientene fortsatt har adresser innenfor det valgte prefikset, fordi en enhet som har flyttet ut av det, er direkte ved et uhell og ikke etter policy. Å utvide blokkeringen til hele LAN-et uten å gjennomgå unntaksdesignet har også en tendens til å fjerne din egen administrative vei.

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

Deretter prøv en gammel strøm ved siden av en ny. Et ferskt tilkoblingsforsøk og en allerede aktiv toveis overføring oppfører seg forskjellig under denne regelen, og bare å teste begge viser hvilken policy du faktisk har.