Product SiteDocumentation Site

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å en standard konfigurasjon (og «prosess, ikke produkt»-mottoet) forklarer mangelen av en nøkkelferdig løsning. Det fins derimot verktøy som gjør det enklere å konfigurere 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 (akseptere, nekte, ignorere 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.
Hvordan nettfilter-kjeder påkalles

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):
  • 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 konfigurasjon 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 den samme konfigurasjonen 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 konfigureres.
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.
Fwbuilders hovedvindu

Figur 14.2. Fwbuilders hovedvindu

fwbuilder kan deretter generere et skript som konfigurerer 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 å konfigurere 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.