Brannmurreglar berre for NEW stenger ikkje alle WAN-vegar

Å avvise nye utgåande tilkoplingar på WAN ser ut som ein policy som lukkar ved feil, men det er eit snevrare løfte enn det verkar som. Pakkar som høyrer til straumar som allereie finst, passar ikkje på han, og det gjer heller ikkje mange svar. Dette gapet er lett å oversjå fordi regelen blir lesen som om han dekkjer grensesnittet og ikkje éin tilstand på det. Og å lese tilstandstreffet som ein dom er det som skapar ei falsk kjensle av lukking.

Tilstand er eit treffvilkår, ikkje ein dom

Tilkoplingssporing klassifiserer pakkar etter kva brannmuren allereie har sett, ikkje etter kva applikasjonen trur. Ein straum som blir observert i begge retningar, er etablert, og dei seinare pakkane blir verande etablerte sjølv når ruta under han skiftar frå ein tunnel til den vanlege oppstraumslinja. Eit svar på ei innkomande tilkopling kan òg vere etablert trafikk. Desse pakkane blir aldri nye igjen.

Difor kan ein regel som berre gjeld nye tilkoplingar, ikkje fastslå at kvar verna pakke blir blokkert. Han overlèt dei andre tilstandane til det resten av regelsettet gjer med dei, og det kan vere ei tillating plassert tidlegare i kjeda.

Les regelen i omgjevnadene

Ei brei tillating for etablert og relatert trafikk plassert før blokkeringa slepp ein pakke gjennom før blokkeringa i det heile blir vurdert. Å fjerne tilstandsvilkåret frå ein seinare regel endrar ikkje det, fordi vurderinga aldri når dit. Rekkjefølgja avgjer resultatet, og tilstandstreffet avgjer kva pakkar som når den rekkjefølgja.

Undersøk det effektive regelsettet i staden for fila du redigerte, inkludert hopp til andre kjeder og alt plattformen genererer. På ein iptables-styrt ruter viser opplisting av kjeda regeldefinisjonane, og kjedene ho viser til, må òg følgjast. Eit innfødd nftables-system krev at det eige regelsettet og krokprioriteringane blir undersøkte, sidan fastvaren sjeldan genererer identiske kjeder.

Teljarar viser kva regel som faktisk traff, og dei er vanlegvis meir informative enn ein pakkefangst teken etter avgjerda. Ein regel med teljar på null er ikkje nådd, uansett kva plasseringa antydar.

Uttrykk forbodet uavhengig av tilstand

Viss ei gruppe klientar aldri skal nå internett utanfor tunnelen, sei det direkte i staden for å tilnærme det med éin tilstand. Regelen må velje på kjelde, utgang og mål utan å avhenge av tilkoplingstilstand, og han må stå der inga tidlegare tillating kan omgå han. Då får administrativ tilgang og unntak for lokalnettet eigne eksplisitte reglar, slik at intensjonen er synleg i policyen.

Å velje reject i staden for drop endrar korleis den samsvarande trafikken feilar, og det utvidar ikkje settet med pakkar regelen vel. Ei avvist tilkopling og eit stille tidsavbrot er ulike symptom som peikar på same val.

Ein policy som med vilje tillèt svar på fjerninitiert tilgang over WAN, er forsvarleg. Han må berre skildrast slik i staden for å bli presentert som full isolasjon berre gjennom tunnelen.

Kontroller kven som faktisk er i gruppa

Dømet dekkjer vidaresend IPv4-trafikk frå eitt prefiks ut av eitt grensesnitt. Det seier ingenting om IPv6, ei andre oppstraumslinje eller trafikk ruteren sjølv startar. Ein ruter som fungerer som DNS-løysar, sender sine eigne oppstraumsspurnader, og dei går ikkje gjennom forward-kjeda i det heile.

Stadfest at dei verna klientane framleis har adresser innanfor det valde prefikset, fordi eining som har flytta ut av det, er direkte ved eit uhell og ikkje etter policy. Å utvide blokkeringa til heile LAN-et utan å gå gjennom unntaksdesignet har òg ein tendens til å fjerne din eigen administrative veg.

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

Deretter prøv ein gammal straum ved sida av ein ny. Eit ferskt tilkoplingsforsøk og ein allereie aktiv tovegs overføring oppfører seg ulikt under denne regelen, og berre å teste begge viser kva policy du faktisk har.