14.2. Brannmur eller pakkefiltrering

En brannmur er en nettverksport for filtrering, og er bare effektiv på pakker som må gå gjennom den. Den kan derfor bare være effektiv når den eneste ruten for disse pakkene er gjennom brannmuren.

Mangelen på et standard oppsett (og «prosess, ikke produkt»-mottoet) forklarer mangelen av en nøkkelferdig løsning. Det fins derimot verktøy som gjør det enklere å sette opp nettfilter-brannmuren, med en grafisk representasjon av filterreglene. fwbuilder er utvilsomt blant de beste av dem.

Linux-kjernen inneholder nettfilter-brannmuren. Den kan kontrolleres fra brukerrommet med kommandoene iptables og ip6tables. Forskjellen mellom disse er at den første betjener IPv4-nettverket, mens den siste betjener IPv6. Siden begge nettverksprotokollene sannsynligvis vil fortsette å eksistere i årevis, vil begge verktøyene måtte brukes i parallell.

14.2.1. Oppførselen til netfilter

nettfilter bruker fire forskjellige tabeller for regler om tre typer pakkeoperasjoner:

filter for filterregler (aksepter, nekt, ignorer en pakke);
nat for oversetting av kilde- eller destinasjonsadresser og porter på pakker;
mangle for andre endringer av IP-pakker (inkludert felt og opsjoner for ToS — Type of Service);
raw tillater andre manuelle modifikasjoner av pakker før de når forbindelsessporingssystemet.

Hver tabell inneholder en liste av regler kalt kjeder. Brannmuren bruker standardkjeder til å håndtere pakker basert på predefinerte betingelser. Administratoren kan lage andre kjeder, som bare vil bli brukt når den refereres til av noen av standardkjedene (direkte eller indirekte).

filter tabellen har tre standardkjeder:

INPUT: gjelder pakker der destinasjon er brannmuren selv;
OUTPUT: gjelder pakker som er sendt ut fra brannmuren;
FORWARD: gjelder pakker i transitt gjennom brannmuren (som verken er kilden eller destinasjon deres).

Tabellen nat har også tre standardkjeder:

PREROUTING: å endre pakker så snart de ankommer;
POSTROUTING: å modifisere pakker når de er klare til utsendelse;
OUTPUT: å modifisere pakker som genereres av selve brannmuren.

Figur 14.1. Hvordan nettfilter-kjeder påkalles

Hver kjede er en liste med regler; hver regel er et sett av betingelser og en handling som skal utføres når vilkårene er oppfylt. Ved behandling av en pakke, skanner brannmur den riktige kjeden, en regel etter den andre; når vilkårene for en regel er oppfylt, «hopper» det (derav -j-alternativet i kommandoene) til det angitte tiltak for å fortsette prosessen. De vanligste handlingene er standardisert, med foreliggende øremerkede handlinger. Å ta én av disse standardhandlingene forstyrrer prosessen for kjeden, fordi pakkens skjebne allerede er fastsatt (bortsett fra unntaket som er nevnt nedenfor):

DET GRUNNLEGGENDE ICMP

ICMP (Internet Control Message Protocol) er protokollen som brukes til å overføre utfyllende informasjon om kommunikasjon. Den tillater å teste nettverkstilkobling med ping-kommandoen (som sender et ICMP echo request -budskap, som det er ment at mottakeren skal svare med et ICMP echo reply-budskap). Det signaliserer at en brannmur avviser en pakke, indikerer at en mottaksbuffer er overfylt, foreslår en bedre rute for de neste pakkene i forbindelsen, og så videre. Denne protokollen er definert i flere RFC-dokumenter; de opprinnelige RFC777 og RFC792 ble snart fullført og utvidet.

→ http://www.faqs.org/rfcs/rfc777.html

→ http://www.faqs.org/rfcs/rfc792.html

For referanse: En mottaksbuffer er en liten minnesone som lagrer data fra den tiden den kommer fra nettverket, og til den tid kjernen håndterer den. Hvis denne sonen er full, kan nye data ikke mottas, og ICMP signaliserer problemet, slik at senderen kan bremse ned sin overføringshastighet (som ideelt sett bør nå en likevekt etter en tid).

Merk at selv om et IPv4-nettverk kan fungere uten ICMP, er ICMPv6 strengt nødvendig for et IPv6-nettverk, siden det kombinerer flere funksjoner som var i IPv4-verdenen, spredt over ICMPv4, IGMP( Internet Group Membership Protocol) og ARP (Address Resolution Protocol). ICMPv6 er definert i RFC4443.

→ http://www.faqs.org/rfcs/rfc4443.html

ACCEPT: tillater pakken å fortsette på sin vei;
REJECT: avviser pakken med en ICMP-feilpakke (--reject-with type-valget til iptables tillater å velge typen feil);
DROP: slette (ignorere) pakken;
LOG: logg (via syslogd) en melding med en beskrivelse av pakken. Merk at denne handlingen ikke avbryter prosessen, og kjøringen av kjeden fortsetter med den neste regelen, som er grunnen til at logging av avslåtte pakker krever både en LOG-regel og en REJECT/DROP-regel;
ULOG: logger et budskap via ulogd, som kan tilpasses bedre og mer effektivt enn syslogd for håndtering av et stort antall meldinger. Merk at denne handlingen, slik som LOG, også returnerer prosessen til den neste regelen i påkallingskjeden;
kjede_navn: Hopper til den gitte kjeden og evaluerer dens regler;
RETURN: avbryter prosessen til den gjeldende kjeden, og går tilbake til den anropende kjeden; i tilfelle den aktuelle kjeden er standard, er det ingen påkallingskjede, slik at standardhandlingen (definert med -P-valget til iptables) kjøres i stedet;
SNAT (bare i nat-tabellen): bruk kilde-NAT (ekstra argumenter beskriver nøyaktig de endringene som skal brukes);
DNAT (bare i nat-tabellen): bruk endestasjon-NAT (ekstra argumenter beskriver nøyaktig de endringene som skal brukes);
MASQUERADE (bare i nat-tabellen): bruk maske (masquerading) (et spesialtilfelle av Source NAT (kilde NAT));
REDIRECT (bare i nat-tabellen): å omdirigere en pakke til en gitt port i brannmuren selv. Denne kan brukes til å sette opp en gjennomsiktig nettmellomtjener som fungerer uten oppsett på klientsiden, siden klienten tror den kobles til mottakeren, mens kommunikasjonen faktisk gå gjennom mellomtjeneren.

Andre handlinger, spesielt dem som gjelder mangle-tabellen, er utenfor formålet med teksten her. iptables(8) og ip6tables(8) har en omfattende liste.

14.2.2. Syntaksen til `iptables` og `ip6tables`

Kommandoene iptables og ip6tables kan håndtere tabeller, kjeder og regler. Alternativet deres -t tabell indikerer hvilken tabell en kan operere fra (som standard filter).

14.2.2.1. Kommandoer

-N kjede-valget lager en ny kjede. -X kjede sletter en tom eller ubrukt kjede. -A kjede regel legger til en regel ved slutten av en gitt kjede. -I kjede regel_nummer regel-valget setter inn en regel før regelnummeret regel_nummer. -D kjede regel_nummer (eller -D kjede regel)-valget sletter en regel i en kjede; den første syntaksen identifiserer regelen som skal slettet ut fra nummeret den har. -F kjede-alternativet tømmer en kjede (sletter alle dens regler); hvis ingen kjede er nevnt, er alle reglene i tabellen slettet. -L kjede-valget lister reglene i kjeden. Til slutt, -P kjede handling-valget definerer standardhandlingen, eller «policy», for en gitt kjede; Merk at bare standardkjeder kan ha en slik «policy».

14.2.2.2. Regler

Hver regel er uttrykt som forhold -j handling handlings_alternativer. Hvis flere betingelser er beskrevet i den samme regelen, da er kriteriet forbindelsen mellom betingelsene (logisk og), som er minst like restriktive som hver individuelle betingelse.

Betingelsen -p protokoll samsvarer med protokollfeltet i IP-pakken. De vanligste verdiene er tcp, udp, icmp, og icmpv6. Å forhåndsinnstille betingelsen med et utropstegn som benekter betingelsen, som deretter blir en oppgave for «noen pakker med en annen protokoll enn den spesifiserte». Denne negasjonsmekanismen er ikke spesiell for -p-alternativet, og det kan brukes på alle andre forhold også.

-s adresse eller -s nettverk/maske-betingelsen samsvarer med pakkens kildeadresse. Tilsvarende, -d adresse eller -d nettverk/maske samsvarer med måladressen.

Betingelsen -i grensesnitt velger pakker som kommer inn fra et bestemt nettverksgrensesnitt. -o grensesnitt velger pakker som går ut via et spesifikt grensesnitt.

Det er mer spesifikke betingelser, avhengig av de generelle betingelser som er beskrevet ovenfor. For eksempel kan -p tcp-betingelsen kompletteres med betingelser i TCP-portene, med klausuler som--source-port port og --destination-port port.

Betingelsen --state tilstand (status) samsvarer med tilstanden til en pakke i en forbindelse (dette krever kjernemodulen ipt_conntrack for koblingssporing). NEW-tilstanden beskriver en pakke som starter en ny forbindelse; ESTABLISHED samsvarer med pakker som tilhører en allerede eksisterende kobling, og RELATED samsvarer med pakker som initierer en ny tilkobling knyttet til en eksisterende (som er nyttig for ftp-data-forbindelsene i FTP-protokollens «aktivmodus»).

Den forrige seksjonen viser tilgjengelige handlinger, men ikke de respektive alternativene.LOG-handlingen har for eksempel de følgende valgene:

--log-level, med standardverdi warning, indikerer alvorlighetsgraden syslog;
--log-prefix tillater å spesifisere en tekst-forstavelse for å skille mellom loggede meldinger;
--log-tcp-sequence, --log-tcp-options og --log-ip-options indikerer ekstra data som skal integreres i meldingen: henholdsvis TCP-sekvensnummer, TCP-alternativer, og IP-alternativer.

DNAT-handlingen gir --to-destination adresse:port valget for å indikere den nye destinasjonens IP-adresse og/eller port. Tilsvarende, SNAT gir --to-source adresse:port for å indikere den nye kildens IP-adresse og/eller port.

REDIRECT-handlingen (bare hvis NAT er tilgjengelig) gir --to-ports port(er) valget for å angi porten, eller portområdet, dit pakkene skal omdirigeres.

14.2.3. Å lage regler

Hver regeletablering krever bruk av iptables/ip6tables. Å skrive disse kommandoene manuelt kan være kjedelig, så anropene lagres vanligvis i et skript slik at det samme oppsettet blir satt opp automatisk hver gang maskinen starter. Dette skriptet kan skrives for hånd, men det kan også være interessant å forberede det med et høynivå verktøy som fwbuilder.

# apt install fwbuilder

Prinsippet er enkelt. I det første trinnet må man beskrive alle elementene som involveres i selve reglene:

brannmuren selv, med sine nettverksgrensesnitt;
nettverkene, med sine tilhørende IP-serier;
tjenerne;
portene som tilhører de tjenestene som ligger på tjenerne.

Reglene blir deretter laget med enkle dra-og-slipp-handlinger på objektene. Noen kontekstmenyer kan endre betingelsen (nekte den, for eksempel). Deretter må handlingen velges og settes opp.

Såvidt det gjelder IPv6, kan man enten lage to forskjellige regelsett for IPv4 og IPv6, eller bare lage ett, og la fwbuilder oversette reglene ifølge de adressene som er tildelt stedene.

Figur 14.2. Fwbuilders hovedvindu

fwbuilder kan deretter generere et skript som setter opp brannmuren etter de regler som er angitt. Dens modulære arkitektur gir det muligheten til å generere skript rettet mot ulike systemer: iptables for Linux, ipf for FreeBSD, og pf for OpenBSD.

14.2.4. Å installere reglene ved hver oppstart

I andre tilfeller er den anbefalte måten å registrere skriptet i et up-direktiv av /etc/network/interfaces-fil. I det følgende eksemplet er skriptet lagret under /usr/local/etc/arrakis.fw.

Eksempel 14.1. interfaces-fil (grensesnittsfil) som påkaller et brannmursskript

auto eth0
iface eth0 inet static
    address 192.168.0.1
    network 192.168.0.0
    netmask 255.255.255.0
    broadcast 192.168.0.255
    up /usr/local/etc/arrakis.fw

Dette forutsetter selvsagt at du bruker ifupdown til å sette opp nettverksgrensesnittet. Hvis du bruker noe annet (som NetworkManager eller systemd-networkd), henvis deretter til deres respektive dokumentasjon for å finne ut måter til å kjøre et skript, etter at grensesnittet har blitt tatt opp.