Kapitel 6. Firewall på Linux
6.1. Hvad er en firewall?
At forbinde sin virksomheds eller sit kollegiums lokale computernetværk direkte til internettet kan være en risikabel ting at gøre, for man åbner jo for trafik begge veje, altså også for trafik ind på det lokale netværk. Hvis man uden videre forbinder sit lokale netværk til internettet, kan man blive udsat for, at andre trænger ind på firmaets eller kollegiets interne computere, læser og ændrer følsomme data, får servere til at gå i stå osv. Ønsker man at give adgang for beboere og medarbejdere til e-post og den store mængde information, man kan finde på internettet uden at åbne for trafik den anden vej, kræver det en firewall.
Firewall er det engelske ord for en brandvæg eller en brandmur. I bygninger bruges en brandmur til at dele en bygning i sektioner. Hvis der opstår en brand i den ene sektion, kan brandmuren forhindre at branden breder sig (hurtigt) til andre sektioner.
En computer som firewall bruges til på lignende vis at opdele et netværk i sektioner, typisk i det, der er uden for lokalnetværket, og det, som er indenfor. Firewallen er først og fremmest et pakkefilter, som forhindrer pakker af bestemte typer i at slippe igennem fra det ene til det andet netværk. Linux firewallen kan imidlertid meget mere end det, og i denne sammenhæng er det vigtigt, at den kan lade trafik, som har oprindelse på lokalnettet, gå til nettet udenfor, det offentlige net, og vel at mærke tillade svarpakkerne at passere på tilbagevejen.
Man kan opnå en fremragende sikkerhed med en Linux box som firewall, men det er imidlertid bedst at kombinere firewallen med de forholdsregler for sikker opsætning af en computer, som er omtalt tidligere i bogen.
En firewall kan selvfølgelig også bruges til at adskille to eller flere lokalnetværk fra hinanden.
Der findes forskellige måder at opbygge en firewall, næste afsnit lister de vigtigste.
6.1.1. Firewall typer
-
Pakkefiltrering
-
Proxy, en applikation som optræder som mellemmand
-
Stateful Multi-Layer Inspection, SMLI, en kombination af pakkefilter, tilstands-betingelser og indholds-filtrering
Et pakkefilter ser på pakkens IP-adresse, den protokol-type, som den hører til, og eventuelt flere ting.
En proxy, som egentlig blot betyder en stedfortræder, var oprindeligt et program på en gateway, som man inde på lokalnettet henvendte sig til, og så kunne dette program sende forespørgsler videre, som om de kom fra proxy-maskinen. Det er en meget sikker, men også ret besværlig måde at skille lokalnet fra offentlige net, og det kræver en proxy for hver protokol, man ønsker at åbne for, http, ftp, ssh, og hvad det nu kunne være.
En mere moderne proxy kan fungere uden at man henvender sig specielt til den. Det kaldes en transparent proxy. Den lytter efter al trafik og videresender de pakker, som er tilladte, ligesom et pakkefilter, men i modsætning til pakkefilteret kan proxyen altså sende dem videre, som om de kom fra den selv, og desuden inspicere dem på indholdsniveau eller applikationslag.
I forbindelse med firewalls taler man ofte om netværkslag, fordi det gør det muligt at beskrive mere præcist, hvad der sker. Den forsimplede Department of Defence-model, DoD 4-lags modellen, er en god hjælp til de fleste formål:
6.1.1.1. Netværks-lag
Netværks-lag
+---------------------+
| Applikations-laget |
+---------------------+
| Transport eller |
| validering/flow |
+---------------------+
| Globale adresser |
+---------------------+
| Ethernet, backbone |
| tranceiver logik |
+---------------------+
Nogle vil måske foretrække at få en forklaring på, hvorfor man i det hele taget har lag, og så er det bedst at tage forklaringerne fra ledningerne, det fysiske netværk og opefter.
-
Fysisk link-lag, det vil sige ethernetkort og ledninger (der er egentlig også et par abstraktionslag her); ofte kaldes det for det nederste lag; det skyldes måske, at ledningerne som regel liger på gulvet og føres ud gennem kælderen - hvis man stadig brugte telefonstolper, ville man nok kalde det for det øverste lag;-))
-
netværkslaget, her finder man IP-numre, ping programmet og ICMP; dette lag har ansvaret for at en pakke kan komme fra Jylland til Australien, det vil sige ansvaret for at forbinde forskellige net med hinanden, herunder også fragmentering af pakker, som er for store til det underliggende fysiske net;
-
transportlaget, TCP, som er forskelligt fra IP-laget derved at det sørger for at data er valide, det vil sige at der oprettes handshake; nyere TCP implementationer kan også håndtere flow-kontrol: parametre på fysisk niveau kan styres indirekte af TCP oplysninger om, hvor meget modtageren kan klare, førend man får data galt i halsen; man kunne også kalde TCP laget for validerings- og flow control lag;
-
applikationslaget, higher level, for eksempel FTP og HTTP.
6.1.1.2. Filtrering på applikationslag
En proxy kan inspicere på applikationslaget. Den kan derfor kaldes for et censur-program, netværks-barnepige eller spion.
Stateful Multi Layer Inspection (SMLI) er den mest avancerede form for firewall. Det er faktisk muligt at lave den slags filtrering med Linux-kernen. Udvalgte pakker kan med iptables kommandoen sendes til et program, som inspicerer dem og som kan afgøre, om de skal sendes videre eller ej. En forudsætning for det er, at Linux' indbyggede pakkefilter har mulighed for at holde styr på det, man kalder en forbindelse (connection), det vil sige en session, hvor man indleder en konversation med en server, udveksler data og ender med at sige "nu er jeg færdig".
TCP benytter sådanne connection-meddelelser. Linux-kernen kan holde styr på status for en forbindelse. Derfor kaldes Linux Netfilter for et State Packet Filter, SPF.
Derved kan man bygge en SMLI firewall baseret på Linux Netfilter. Endvidere kan en user-applikation inkorporeres i kernen (for at effektivisere den), så man kan skam bygge tiptop professionelle SMLI-firewalls på basis af Linux.
6.1.2. Grundlæggende pakkefiltrering eller politiske overvejelser
Opsætningen af en firewall kan enten bygge på den grundlæggende antagelse, at alt, hvad der kommer udefra, er mistænkeligt og bør stoppes - eller, omvendt, at vi tror på det gode i netværket og kun spærrer af for de ting, som notorisk er nemme at misbruge.
6.1.2.1. Luk alt
Hvis man lukker for alt, er det selvfølgelig overflødigt med en netforbindelse ud af huset. Men det er nu alligevel den bedste måde at sikre systemet på (;-) For at få lidt glæde af netforbindelsen kan man så åbne for web-protokollen HTTP. En TCP/IP-pakke har ud over IP-nummeret et port-nummer med sig, som blot er et tal (16 bit) i TCP-pakkens header. På modtagermaskinen ser TCP-softwaren i kernen efter, hvilket portnummer der er, og om der er noget program, som har meldt sig som interesseret i pakker til dette portnummer. Det kalder man, at et program har registreret på den pågældende port. Et program, som lytter efter indkommende forbindelser, kaldes en server (eller somme tider et serverprogram.)
HTTP-protokollen er karakteristisk ved, at serveren som regel lytter på port 80. Vi kan derfor lave en firewall regel, som siger, at al trafik, som er til eller fra port 80 på en computer udenfor lokalnetværket skal have lov at passere. Det er en løsning, men en fattig løsning, idet man kommer til at mangle Domain Name Service, DNS, og endvidere kommer til at lide under, at nogle web-sites forventer, at man kan bruge FTP til download, eller ligefrem flytter brugerens forespørgsel til en server på et andet portnummer.
En netværksforbindelse mellem to applikationer defineres af IP-adresse plus portnummer. En sådan identificeret forbindelse kaldes en socket.
SOCKET-illustration Afsender (browser) Modtager (http-server) IP-adresse + portnummer IP-adresse + portnummer 201.2.3.4 51001 <-----> 193.88.44.22 80 En anden afsender (wget) Modtager (samme http-server) 201.2.3.4 47011 <-----> 193.88.44.22 80 En socket definerer en forbindelse, typisk fra applikation til applikation.
6.1.2.2. Lad alt være åbent - undtagen de farlige ting
For at undgå problemer kunne man så beslutte, at man lader det meste stå åbent og - selvfølgelig - lukker for de farlige services som telnet, remote shell og så videre.
Et eksempel kunne være, at man lokalt gerne må bruge telnet, men at det er sket at folk udefra har forsøgt at få forbindelse via telnet. Derfor kan det se ud som en løsning at lukke for port 23. Den løsning er dog heller ikke særlig god. Intrusion på en computer kan sagtens benytte sig af andre portnumre (og andre protokoller) og ved snedige, ulovlige datapakker forsøge at sætte en kæp i hjulet på de programmer, der lytter. Hvis vi var flittige og lappede alle hullerne i serverprogrammerne og i øvrigt overvågede maskinen døgnet rundt, så ville denne løsning være god nok, men den er dyr i arbejdstimer.
6.1.3. Den lukkede model bør vælges som udgangspunkt
Hverken den åbne eller helt lukkede model er særligt nyttige. Der skal mere til. Som udgangspunkt er den lukkede model imidlertid den sikreste, men den skal kombineres med connection-tracking.
Forhåbentlig fremgår det af ovenstående, at en firewall egentlig er et ret kompliceret stykke software. Man skal nu ikke lade sig skræmme væk af den grund. Det er i grunden ret nemt at skrive de nødvendige kommandoer og så blot kontrollere en gang i mellem, at det kører som det skal.
Man bruger iptables kommandoen til at opsætte firewall reglerne i kernen. Men man behøver ikke at kunne iptables kommando syntaksen, idet SuSE, Red Hat og andre lavet GUI-administration af firewall reglerne. Så hvis man holder sig til de gode, kendte distributioner eller på anden måde sørger for, at de nødvendige ting er til stede, så kan man blot krydse af, hvilke servere andre udefra skal have lov at bruge, om nogen. Er man af gør det selv typen, følger her en opskrift på, hvordan man kan lave en lille komplet firewall-opsætning.
6.1.3.1. Lynkursus
Senere bliver kommandoerne til en firewall beskrevet og forklaret grundigt, men for den utålmodige, som bare vil i gang, kan vi lige vise "Rusty's Really Quick Guide To Packet Filtering" fra packet-filtering-HOWTO. Vi antager, at maskinen har en modemforbindelse til en ISP og ikke ønsker, at man skal kunne tilgå maskinen udefra:
## Insert connection-tracking modules (not needed if built into kernel). # insmod ip_conntrack # insmod ip_conntrack_ftp ## Create chain which blocks new connections, except if coming from inside. # iptables -N block # iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT # iptables -A block -j DROP ## Jump to that chain from INPUT and FORWARD chains. # iptables -A INPUT -j block # iptables -A FORWARD -j block
De første kommandoer er nødvendige med de fleste distributionskerner. Det er ikke spor svært at lave sin egen superkerne, hvis man interesserer sig for, hvad en kerne er, og man har lært noget om, hvordan et operativsystem fungerer. Har man en kerne hvor alt er kompileret ind i kernen, vil systemet være en anelse hurtigere[1].
iptables -N block laver en kæde (en skuffe eller hylde) for et regelsæt. Regelsættene kaldes chains, fordi man bruger reglerne i den rækkefølge, de er sat ind i kæden. Kæden her hedder "block", blokér.
iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
-A block indsætter en regel i block-kæden, som siger, at man skal bruge tilstands-modulet, -m state , og undersøge, om pakken tilhører en forbindelse (connection), som allerede er startet, eller som er i slægt med en connection --state ESTABLISHED,RELATED, hvis det er tilfældet, skal pakken accepteres, d.v.s. regelfortolkeren jumper (-j) hopper til feltet for videresendelse af pakker, "ACCEPT".
Næste linje siger, at alle pakker, som ikke kommer udefra (i dette tilfælde fra et modem som bruger Point-to-Point-Protokollen, PPP), skal have lov at passere.
Alt andet smides simpelt hen væk! DROP!
Og de sidste par linjer bevirker, som kommentaren siger, at både pakker, som er INPUT og pakker og FORWARD pakker kommer igennem den regelkæde, som vi har dannet. Dette er, som nævnt, et eksempel for den utålmodige, men for den tålmodige er der en nærmere forklaring af kommandoen og mulighederne med netfilter i Afsnit 6.5.3.
Det er vigtigt at forstå, at en firewall ikke er spor sikker, hvis den er sat forkert op. Når firewallen er sat op, bør man grundigt teste, at den nu også gør, som man forventer. En vigtig del af sikkerheden omkring en firewall er desuden, at man registrerer og overvåger den trafik, der passerer igennem den. Hvis man glemmer at holde øje med de log-filer, firewallen genererer, er ens sikkerhed reelt væk (Se også Kapitel 5). Man kan så risikere, at man ikke opdager, at der har været indbrud. En firewall er aldrig helt sikker, og man bør kun sætte en firewall op, hvis man har i sinde at vedligeholde den.
En forkert opsat firewall eller en firewall, ingen holder øje med, kan være værre end ingen firewall! Tilstedeværelsen af en firewall giver let en falsk fornemmelse af tryghed, så man ikke er omhyggelig nok med at beskytte hver enkelt computer. Det er også meget vigtigt, at man holder sig ajour med nyheder om fejl i den software, der anvendes på firewallen (Se Afsnit 1.4).
Selvom man har sat en firewall op for at beskytte et netværk imod folk på internettet, bør man stadig være omhyggelig med sikkerheden i det lokale netværk. For det første kan det være, at nogen bryder igennem ens firewall, og dermed er der kun lokalnetværkets sikkerhed tilbage. For det andet beskytter en firewall ikke imod internt misbrug af ens netværk. I en virksomhed eller på et kollegium eller lignende kan man ikke altid stole på de lokale brugere. Opgørelser fra IBM peger på, at der ca. er ligeså mange interne netværksindbrud som eksterne.
Et andet problem inden for firewallen er lokale modems. Hvis en bruger har et modem, hvormed han kobler sig direkte til sin hjemmearbejdsplads, der ikke er sikret, så er der via denne hjemmeopkobling fri bane til virksomhedens net. Der er mange variationer på dette sikkerhedshul, for eksempel også at nogen medbringer en transportabel maskine og sætter den på kollegiets eller virksomhedens net. På Linux/GNU/BSD platforme sikrer man den enkelte maskine bedst ved at den er firewall for sig selv.
Så det er vigtigt at bemærke, at en firewall ikke er en universalløsning på sikkerhed, som mange tror i dag. Den er god at have, hvis man er indstillet på at gøre det ordentligt. Men den er ikke en erstatning for alle de andre sikkerhedsforanstaltninger på et netværk.
Man er aldrig helt sikker, selv med en firewall ...
