Gatewayer og fallgrubene in, out og on

I oppsett med en enkelt maskin er livet relativt enkelt. Trafikken du skaper, skal enten slippe ut til resten av verden eller ikke, og du bestemmer hva du vil slippe inn fra omverdenen.

Når du setter opp en gateway, blir perspektivet annerledes. Du går fra "meg mot nettverket der ute" til "jeg er den som bestemmer hva som skal passere meg eller ikke, til eller fra alle nettverkene jeg er koblet til". Maskinen har flere, eller i det minste to, nettverksgrensesnitt, og hvert av dem er koblet til et separat nett.

Nå er det helt naturlig å tenke at hvis du vil at trafikken skal flyte fra nettverket som er koblet til xl1 til maskiner i nettverket som er koblet til xl0, trenger du en regel som

pass in on xl1 from xl1:network to xl0:network \
     port $porter keep state

og dermed også holde på tilstandsinformasjon.[1]

Dessverre er det slik at en av de mest utbredte feilene i brannmurkonfigurering, og det som fører til mest klager, er å ikke innse at nøkkelordet "to" ikke i seg selv garanterer passasje hele veien frem. Regelen vi akkurat skrev, lar bare trafikken passere inn til gatewayen på det indre grensesnittet.

For å la pakkene komme litt videre, trenger du en tilsvarende regel som denne:

pass out on xl0 from xl1:network to xl0:network \
     port $porter keep state

Disse reglene vil virke, men virkningen er kanskje ikke det du hadde ønsket.

Hvis det finnes gode grunner til at du trenger å ha så spesifikke regler i regelsettet ditt, vet du at du trenger dem og hvorfor. For de enkle gateway-konfigurasjonene jeg behandler her, er det sannsynlig at det du vil ønske å bruke er en regel som denne

pass from xl1:network to any port $porter keep state

som lar ditt lokalnett få adgang til Internet, og så overlate detektivarbeidet til koden som ligger bak antispoof og scrub. Disse funksjonene er svært gode og pålitelige, og vi kommer tilbake til dem om en liten stund. Foreløpig bare godtar vi det som en sannhet at for enkle oppsett gir regler som er bundet til grensesnitt med in og out først og fremst gjør regelsettet mindre oversiktlig enn nødvendig.

For en travel nettverksadministrator er et lesbart regelsett et sikrere regelsett.

I resten av dette foredraget vil vi med noen få unntak holde reglene så enkle og lesbare som mulig.