6.5. Linux som firewall

6.5.1. GUI: Anvendelse af grafisk-interface ved installation af firewall

Findes der ikke noget nemmere? hører man ofte en Linux begynder spørge, med rette, for det er i grunden meget få oplysninger der skal til at lave en meget fornuftig firewall, som kan bruges af de fleste. Derfor har distributioner som Red Hat, Fedora, SuSE og Mandrake alle et spørgsmål om man ønsker at maskinen skal være åben eller om der skal lukkes for services. Benytter man en anden distribution (og dem er der jo mange af) kan det hænde, at man selv skal konfigurere firewall.

Det kan også ske, at man selv vil raffinere opsætningen af firewall. Nogen vil derfor gå på jagt efter et værktøj til opsætning og selv installere dette. Her er et par eksempler: Firestarter og Lokkit.

Der mange andre gode front ends til iptables kommandoen. Allerede under installationen kan man på mange distributioner indsætte et firewall filter af medium styrke. Derefter kan man begynde med en GUI som for eksempel Red Hats systemopsætningsværktøj, setup eller /usr/sbin/lokkit. Disse nemme programmer er front-ends til den bagvedliggende mekanisme og fungerer bravt. De er til stede efter en normal installation. Firestarter kan man selv hente i forskellige grydeklare versioner, så den er også nem at komme igang med.

Hvis man vil noget særligt eller bare vil prøve kommandoerne direkte, så står der mere om det i de efterfølgende afsnit, som beskriver iptables anvendelse[1].

Firestarter er en generel front-end, som er meget nem at bruge, fordi den ligesom Red Hats installations program har nogle meget fornuftige default værdier, hvis man bruger troldmand/hjælpe systemet til opsætning af sin første firewall.

Grafikken er rigtig pæn, og let at læse. I første vindue står en pingvin med en tændstik, og sådan noget kan godt gøre mig lidt urolog. Pingvinen ser dog ikke umiddelbart ud til at være i gang med ildspåsættelse!

I andet vindue skal man fortælle, hvilke netkort (d.v.s. interfaces) reglerne skal gælde for. De kan også gælde for modem opkobling med Point-to-Point Protocol (PPP), hvilket også er forklaret. Man lades ikke i stikken!

Det er meget fine forklaringer, også på det næste skærmbillede, hvor man rådes til i første omgang at lukke for alle "offentlige" services (disable public access to all services), så intet er tilgængeligt udefra. Så kan man åbne for dem senere, hvis man får brug for dem. Der burde stå, at man ikke bør åbne for telnet, men derimod kan klare de fleste opgaver med ssh.

Der er et par skærmbilleder mere, som på en overskuelig måde tilbyder at justere på trafikken af forskellige typer. Denne form for justering vil blive meget mere almindelig i fremtiden, fordi mange typer service kræver en jævn datastrøm, men som udgangspunkt kan man blot acceptere default indstillingerne.

Ønsker man dansk tekst i sin GUI er guarddog (GPL) det klare valg. Gunner Poulsen har oversat til dansk, og man kan hente denne fra http://www.simonzone.com/software/guarddog/#download Guarddog kan skelne mellem lokalnet og demilitariseret zone, som er et område udenfor lokalnettet, hvor man har anbragt sine servere - tilbørligt sikrede, men der skal jo være en åben dør, for at folk kan komme ind og se på éns dejlige web-sider. Man kan selv definere flere zoner og zonetyper.

Læg mærke til, at guarddog styrer protokollerne pr. zone. Det vil sige, at man kan lukke for alt fra for eksempel externe numre og åbne for sine lokale 4 maskiner. Man kan have flere zoner, for eksempel kan en anden afdeling huset få adgang til noget specielt, som de har brug for.

Et andet fremragende GUI firewall-protection program er lokkit, som er bruges ved installation af Red Hat og ved kørsel af setup programmet.

Her skal man blot angive for eksempel maximum sikkerhed og så åbne for den eller de services, som skal være tilgængelige udefra. (De skal jo så være sikret på anden måde, pas især på CGI scripting i Apache hvis den kører som root.)

Hvis du selv vil opdatere din kerne med source fra www.kernel.org så kommer nedenfor nogle screenshots som svarer til make xconfig . Her kan du se, hvor i menuerne du skal klikke; husk at læse help teksterne, det er gode forklaringer.

iptables kommandoen skal bygges, så den passer til den kerne, man bruger, eller rettere, så den passer til den version af netfilter, som er i kernen. Også det er gjort i alle distributioner.

iptables indsætter som nævnt regler i kernens netfilter tabeller, hvilket betyder, at reglerne går tabt ved reboot. Du kan prøve at bruge kommandoerne iptables-save og iptables-restore.

Hvis man har en opsætning, som man gerne vil gemme, så kan det lade sig gøre uanset om det er en "håndlavet opsætning" eller om den kommer fra et af de nævnte GUI-tools. Man bruger simpelthen iptables-save.

Resultat-filen gemmer man, fx. i /etc/init.d eller /etc/rc.d og så sætter man en overordnet kommando ind i et start/stop script, som køres af rc kommandoen ved opstart. Det er måske lidt for vanskeligt for en GUI bruger, men med lidt hjælp udefra skal det nok kunne lade sig gøre.

Man skal i så fald huske at få scriptet til at foretage sig noget fornuftigt, hvis en af iptables kommandoerne fejler; normalt vil det fornuftigste være at starte /sbin/sulogin for så kan system-administrator se, at der er noget galt, og systemet går ikke videre (på nettet) uden at denne fejl er løst. For mere avancerede anvendelser, hvor ubemandet opstart er en nødvendighed, må man finde en anden måde at systemet kommer videre på, det kunne fx. være at tilbyde login til en overvågningsmaskine på lokalnettet.

6.5.2. Iptables og netfilter i kerne 2.4 og 2.6

I Linux er pakkefiltrering i en avanceret version indbygget i kernen; kernedelen kaldes netfilter, og programmet iptables kommunikerer vores ønsker om hvad kernen skal foretage sig fra user-space til kerne-space.

For at kunne bruge kernens netfilter og iptables kommandoen, skal kernen være bygget med netfilter, og, hvis man planlægger at sikre en maskine, må det stærkt anbefales at man også inkluderer connection tracking. Det koster lidt belastning, men giver mange fordele. De fleste standard kerner fra distributioner med kerne 2.4.18 og frem har den slags. Det kan kontrolleres med ls -l /proc/net/ip_conntrack

                            _____
  Incoming                 /     \         Outgoing
         -->[Routing ]--->|FORWARD|------->
            [Decision]     \_____/        ^
                 |                        |
                 v                       ____
                ___                     /    \
               /   \                   |OUTPUT|
              |INPUT|                   \____/
               \___/                      ^
                 |                        |
                  ----> Local Process ----

6.5.3. Anvendelse af iptables kommandoen

iptables kommandoen har en ret detailleret manual side ( man iptables ) hvis du har brug for oplysninger om specielle ting.

Der er mange ting, man kan gøre med iptables kommandoen. Man begynder med at have de tre indbyggede kæder, INPUT, FORWARD og OUTPUT, som man ikke kan slette. Lad os først se på hvordan man administrerer hele kæder.

• -N : Opretter en ny kæde.

• -X : Sletter en tom kæde.

• -P : Ændrer policy for en kæde.

• -L : Lister regler i en kæde.

• -F : Flusher, sletter reglerne i en kæde.

• -Z : Nulstiller tællerne for en kæde.

Brugerdefinerede kæder bruges til at strukturere filtreringen og demonstreres senere. Her er et simpelt eksempel på en kæde-kommando, som nulstiller tællerne i INPUT kæden. Prøv at liste før og efter med iptables -L INPUT -v :

[root@hven /]# iptables -Z INPUT

Der er fire kommandoer til at manipulere reglerne i en kæde:

• -A <kæde> Tilføj (append) regel

• -D <kæde> [nummer] Slet (delete) regel

• -R <kæde> [nummer] Erstat (replace) regel

• -I <kæde> [nummer] Indsæt (insert) regel

En regel er en beskrivelse plus en handling.

Beskrivelsen er et match-udtryk og kan være sammensat af mange del-udtryk: Hvis pakken kommer fra adresse 44.55.66.77 og skal videre gennem interface eth1 ... Det ville man skrive sådan: --source 44.55.66.77 --out-interface eth1 .

En handling er et "jump", og det svarer til at tage en bestemmelse om, hvad der skal ske med pakken. Det, man hopper til, kaldes et mål eller target, og to af de indbyggede targes er de samme som de policy, vi tidligere har set, DROP, ACCEPT. At tage beslutning om at droppe en pakke skrives -j DROP

Man kan sætte flere match udtryk sammen. Nedenfor ses efter pakker, som kommer fra host 44.55.66.77 og som skal ud gennem interface eth1. Alle pakker, som har de to egenskaber, droppes:

[root@hven /]# iptables -A OUTPUT --source 44.55.66.77 --out-interface eth1 -j DROP 

Endvidere kan man hoppe til en anden, brugeroprettet kæde, eller man kan returnere fra en kæde (med -j RETURN ). Der er et REJECT target, som dog kræver at kernen er kompileret med support for det. Der er andre inbyggede targets, som kræver tilvalg i kernen: QUEUE beder kernen om at sende pakkerne til en pseudo-device, som et program i userspace kan lytte på, og så er der bl.a. også REDIRECT, SNAT, DNAT og LOG targets. (Lad være med at studere listen i detailler! Bladr frem.)

1. ACCEPT

   Pakken sendes videre uden yderligere test og dermed uden yderligere tidsforbrug.

2. DROP

   Pakken ignoreres ("smides væk").

3. RETURN

   Der hoppes tilbage til den kæde, man kom fra eller for indbyggede kæder til default policy.

4. REJECT

   Pakken droppes men der sendes en ICMP pakke til modtageren med besked.

5. QUEUE

   Pakken lægges i kø til pseudodevice der tillader data at blive hentet til userspace.

6. REDIRECT

   En -t nat funktion. Modtageradressen ændres, så pakken sendes til maskinen selv (lokalhost); for tcp/udp kan portnummer ændres. Bruges til proxy-funktionalitet.

7. SNAT

   Kun for nat-tabellen, POSTROUTING kæden, specificerer at afsenderadresse skal ændres for denne og alle fremtidige pakker i denne forbindelse.

8. DNAT

   Modtager adressen ændres for denne og følgende pakker i samme forbindelse.

9. LOG

   Begynd kernel-logging for matchende pakker. Reglen behøver ikke at have noget target. Netfilter fortsætter med næste regel. Bruges til at analysere.

10. MARK

    Bruges i mangle tabellen i forbindelse med iproute2.

11. MASQUERADE

    Bruges til NAT-ing med dynamiske adresser.

12. TCPMSS

    En speciel funktionalitet for fragmentering af ICMP pakker, som ens ISP ellers kasserer.

13. TOS

    For mangle tabellen, ændring af Type Of Service (TOS) feltet i TCP headeren.

14. ULOG

    Pakken multicastes til userspace for logging/analyse.

15. DSCP

    Nyere version TOS mangling.

16. ECN

    For løsning af problem med Explicit Congestion Notification.

17. MIRROR

    Kun for forsøg, bytter om på afsender/modtager adresserne.

Listen er ordnet efter hvad jeg synes er vigtigst. Se manual page for nærmere detailler om targets. Lige nu er de vigtigste ACCEPT, DROP og SNAT, som kun kan bruges i nat-tabellens POSTROUTING chain.

Opsummerende kan vi sige, at en regel består af består af en eller flere kommandoparametre, som beskriver en egenskab ved en netværkspakke, samt (som regel) en besked om, hvad der skal ske med pakker, som beskrivelsen passer på. Hvis en beskrivelse passer, siger man at pakken matcher.

De vigtigste kommandoparametre til match er

• --protocol [icmp|tcp|udp|all]

  Man kan også bruge et navn fra /etc/protocols . Hvis man ønsker at matche alle pakker, som ikke tilhører en bestemt protokol, negeres med udråbstegn. Fx. iptables -A INPUT --protocol ! tcp -j ACCEPT accepterer alt undtagen TCP-pakker. Kan forkortes til -p.

• --source [!] adresse[/netmaske]

  Angiver oprindelsesadressen. Kan forkortes til -s. Eksempel: iptables -A INPUT --source 123.45.67.89 -j ACCEPT vil bevirke at vi accepterer alt, hvad der kommer fra 123.45.67.89 - og formentlig dropper alt andet.

• --destination [!] address[/mask]

  matcher på slutadressen, destinationen. Forkortes -d.

• -i, --in-interface [!] name

  hvor name kan være eth0, eth1, ppp0 m.v. kan bruges til at selektere alle pakker, som kommer fra ydersiden eller indersiden af firewallen.

• -o, --out-interface [!] name

  som -i, bruges til at selektere på alle pakker, der skal sendes ud via et bestemt interface.

• -m state

  bruges til at fortælle kernen at tilstandsmodulet (connection tracking) skal bruges. Derefter kan man specificere, at pakker, som er ESTABLISHED eller RELATED til en forbindelse, som er i gang, skal have lov at passere. Det er den måde, man åbner for al trafik indefra.

Næsten alle options har en kort form, for eksempel -s i stedet for --source.

Adresser til --source og --destination kan specificeres på fire måder:

• Som domaine-navn, www.kernel.org, linuxbog.dk, www.netfilter.org

• Som IP-adresse: 127.0.0.1, 193.88.44.22

• Som netværksadresse med skråstreg + antal signifikante bits: 10.11.128.0/17

• Netværksadresse med skråstreg+bitmaske, 10.11.128.0/255.255.128.0

Man kan selektere alle pakker, som ikke kommer fra en adresse ved at negere adresse udtrykket, hertil bruges et udråbstegn, som skal have space før og efter: -s ! localhost vil matche alle pakker, som ikke kommer fra localhost.

[root@hven /]# iptables -N udefra 

[root@hven /]# iptables -A INPUT -i eth1 -j udefra 

                  __________
                _|  udefra  |--> regel 1 --> regel 2 ... 
               ^ |__________|                                    
              _|_____                                            
             /if eth1\                                           
            |  else   |                                          
             \_______/ _                                         
               ^        |   
   ______      |        v   
__|input |--> regel 1   regel 2 --> regel 3
  |______|
   ______
__|output|
  |______|
   _______
__|forward|
  |_______|

   if (pakke_source == device_eth1) {
       tjek_reglerne_i_kaede_eth1();
   }
   else {
       fortsaet_med rule2();
   }

[root@hven /]# iptables -A udefra -p tcp --dport 80 -j ACCEPT 

[root@hven /]# iptables -A udefra -j DROP 

[root@hven /]# iptables -I udefra -m state --state ESTABLISHED,RELATED -j ACCEPT 

[root@hven /]# iptables -I udefra 2 -m state --state ESTABLISHED,RELATED -j ACCEPT 

     +-----------------------------------------------------------
    _|  udefra  ---> udefra-regel1 --> udefra-regel2 ---->regel3
   ^ |  kæden        PORT 80?          RELATED?           DROP!
   | +------------   ACCEPT            ACCEPT
  _|_____               |                 |
 /if eth1\              |                 |
|  else   |             |                 |
 \_______/------------> +-----------------+----------> Sendes videre
   |     
   |        
INPUT-chain

Lidt forsimplet af pladshensyn, man skal spørge både på
ESTABLISHED og RELATED i regel 1 i  "udefra"  regel kæden.

[root@hven /]# iptables -I INPUT -p tcp --dport 23 -j DROP 

6.5.4. Opsætning af NAT

NAT og Masquerading sker i nat-tabellens FORWARD kæde, når en datapakke skal til at forlade maskinen. Det kan kun ske her. Source adressen, som skal NATtes, er den interne eller private adresse, men man kan også angive netværket ved at skrive 0 for den sidste byte i en almindelig 192.168 - adresse og også angive netmaske, typisk 192.168.1.0/24, så vil alle de lokale adresser blive NAT-ede.

iptables har mange måder at angive adresser på, navne, numre, netværk, og for NAT også intervaller m.v., så hvis der opstår specielle behov, så kig lige en gang ekstra på manual page for iptables. Det er bedre at nøjes med én regel, som dækker flere adresser, end at have flere regler med hver deres adresse.

[root@hven /]# iptables -t nat -A POSTROUTING --src 192.168.1.0/24  -o eth1 -j SNAT --to x.y.w.z   

Hvis man får en dynamisk IP adresse fra sin internet leverandør, skal kommandoen se lidt anderledes ud, og så bruger man betegnelsen masquerading om metoden. Dynamiske adresser benyttes typisk med modemforbindelser, eller når man har en Point-to-Point Protocol (PPP) forbindelse til sin ISP. Man får en ny adresse hver gang. Linux kan tage denne adresse og bruge som den officielle adresse for NAT-ing af interne maskiner. Masquerading er oftest dynamisk NAT, med kun en ekstern adresse.

MASQUERADE target er kun muligt i nat tabellen, og kun i POSTROUTING kæden. Dette target bør kun benyttes med dynamiske IP-adresser.

# Eksempel på anvendelse af MASQUERADE target:

       # Masquerade out ppp0
       iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

       # Disallow NEW and INVALID incoming or forwarded packets from ppp0.
       iptables -A INPUT -i ppp0 -m state --state NEW,INVALID -j DROP
       iptables -A FORWARD -i ppp0 -m state --state NEW,INVALID -j DROP

       # Turn on IP forwarding
       echo 1 > /proc/sys/net/ipv4/ip_forward

Man kan godt bestemme, hvilken port-range, som må bruges til nat tabellen. Hvorfor skulle man gøre det? I nogle tilfælde laver man huller i firewallen for at sikre folk adgang til en bestemt protokol. Det er klart, at dette er en sikkerhedsfaktor, men hvis man skal have glæde af en server, så må der jo åbnes. Det kan evt. aftales med kendte brugere, at man kun holder et mindre port-interval åbent for bestemte protokoller.

DNS forespørgsler kan bruges som eksempel. Vi vil sætte en intern DNS server op, en hjælpeserver, som husker nyligt brugte adresser, så alle maskinerne på vores lille netværk ikke behøver at spørge igen og igen ud over det overbelastede ISP link. Alle på det interne net kan spørge denne maskine, men den skal være fuldstændig lukket udadtil, bortset fra, at den skal kunne spørge en remote DNS server. Det kaldes en DNS caching server. Til DNS benyttes User Datagram Protokol, UDP, som let kan udsættes for spoofing. Det ønsker vi at gøre alt for at forhindre. Det forbedrer selvfølgelig sikkerheden at køre en DNS caching server på en maskine for sig selv.

Når hjælpeserveren skal foretage en forespørgsel, bruger den som afsenderport et nummer som den får tildelt lidt tilfældigt, men det vil ligge i intervallet 1024 - 65535. Det kaldes de ikke-priviligerede porte. Netfilter skelner mellem 1-511, som er såkaldt privilegerede, velkendte portnumre, som kun kræver root privilegier, og som typisk bruges af specielle serverprogrammer som for eksempel httpd, 512-1023, som også er priviligerede, og så 1024 - 65535, der kan anvendes til alt. Netfilter mapper ikke portnumre fra en gruppe til en anden. (At mappe = at spejle eller sige a svarer til X, b svarer til Y, c svarer til Z og så fremdeles, en af de få ting, en computer er god til.) Man vil kunne begrænse DNS-klienten til at bruge ganske få portnumre for forespørgsler, og derved yderligere skærpe sikkerheden, men det er ikke netfilters område.

De eksterne DNS servere sender svar til det portnummer, som klienten brugte til at spørge.

Her kommer kommandoen, som tillader alle remote DNS servere at svare til vores maskines eksterne netkort på en ikke-priviligeret port:

[root@hven /]#  iptables -A INPUT -p udp -s 0/0 --source-port 53 -d 66.14.136.144/32 --destination-port 1024:65535 

Det ville være væsentligt bedre, hvis vi kun brugte en enkelt server udenfor firewallen, men så begynder det at blive et stort setup. Med den foreslåede lokale caching server kan anvendelsen af udp på alle lokale maskiner begrænses til, at de kun må lave UDP til denne specifikke IP-adresse. Her kommer kommandoerne, som kan gøre det, idet vi antager, at caching serveren har lokalnummeret 192.168.1.2:

[root@hven /]#  iptables -A INPUT -p udp -s 192.168.0.0/16 --destination-port 53 -d 192.168.136.144 -j ACCEPT
[root@hven /]#  iptables -A INPUT -p udp -s 192.168.1.2/16 --source-port 53 -d 192.168.0.0/16 1024:65535 -j ACCEPT
[root@hven /]#  iptables -A INPUT -p udp -j DROP

Som man kan se er det lidt mere besværligt at kontrollere UDP, fordi man ikke kan regne med connections - alle pakker er som en enkeltstående begivenhed. Det er en statusløs protokol. Rækkefølgen er kritisk. Det ville være en god idé at bruge -i for interface specifikation, så firewallen styrer på IP nummer og hardware.

Ligesom for tcp protokollen loades der et extension modul, når vi specificerer -p udp. De ekstra kriterier, som dette modul giver mulighed for, er dog kun portnumre for hhv. source og destination. Det ovenstående eksempel specificerer, at alle inputporte over 1023 må bruges. Det ville være meget bedre at sige til DNS-forwarder programmet at det kun må bruge for eksempel port 32109. Ved at bruge fast portnummer for hjælpeserverens udgående trafik kan antallet af åbne porte begrænses meget.

[root@hven /]#  iptables -A INPUT -p tcp ! --syn --source-port 20 --destination-port 1024:65535 -j ACCEPT 

Her vises en måde at åbne for alle FTP-pakker udefra, som ikke forsøger at indlede en konversation. Optionen --syn betyder, at pakker, som ikkehar syn-flaget (synkroniserings-request) sat, skal have lov at passere. Det er en anden måde at specificere, at maskiner indenfor firewallen skal have lov til at gøre alt, men alligevel beskyttes de såkaldt priviligerede porte i intervallet 1 - 1024. En angriber kan godt sende en pakke, som ikke har syn flaget sat, men det er jo sværere at komme igennem til noget sårbart, når man nu ikke kan sende til portnumre under 1024.

En måske mere avanceret anvendelse af port-ranges er at åbne for et mindre område ved source NAT-ing; man reserverer et interval til et bestemt formål og kan på remote maskinen filtrere alle andre afsenderporte fra. Mange netværksprogrammer har en mulighed for at brugeren specificerer, hvilke porte, der må bruges.

[root@hven /]#  iptables -t nat -A
POSTROUTING -j SNAT --to 129.142.141.140:47000-49000

Et eksempel på anvendelse af multiport extension, hvor der åbnes for (kendte) serverporte i et hug (mere effektivt, mindre load på firewall):

[root@hven /]#  iptables -A INPUT -p tcp -m multiport --dport 21,25,80,110,143,443 -j ACCEPT 

I det efterfølgende eksempel bliver port specifikationer brugt til at omdirigere trafikken, en stærk feature, når man vil lave en HTML proxy.

6.5.5. Source/Destination NAT og omdirigering

I det følgende ses på henholdsvis source NAT og destination NAT. I source NAT er det afsenderens adresse+port, som oversættes til gateway-adresse + en anden port. I Destination NAT sendes pakker, som egentlig er til a.b.c.d i stedet til x.y.z.q, hvilket jo strengt taget blot er en omdirigering.

Destination NAT rummer imidlertid mange muligheder, og er nødvendigt, når for eksempel 1000 klienter i sekundet spørger på Google, der i snit måske er 1/100 sekund om at svare. Man kan hurtigt regne ud, at de har mange servere kørende!

# iptables -t nat -A PREROUTING -i eth1 -j DNAT --to 1.2.3.4-1.2.3.6

# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \ 
-j REDIRECT --to-port 3128

6.5.6. En komplet firewall

Selv om der allerede er givet eksempler på en firewall Afsnit 6.1.3.1 så vises her en lidt større opsætning af en firewall. Eksemplet er valgt ud fra det kriterium, at det skal være en opsætning, som har fungeret og har vist sig at være stabil.

Setuppet er, at vi har en maskine, som har forbindelse til vores ISP med fast (eller næsten fast) adresse, 130.3.2.99. Den skal være gateway og firewall. Desuden står der et antal maskiner i vores lille computerworkshop, og de må gerne snakke med internettet gennem vores gateway/firewall, men da de ikke har "private adresser" må vi også sørge for, at firewallen laver NAT. Desuden vil vi gerne have, at firewallen er web-server. Dette er ikke realistisk for en virksomhed, som ønsker high-speed, ultimativ sikkerhed, her ville man sørge for at fordele belastningen på flere maskiner, men realistisk nok for at demonstrere mange pointer.

Firewall maskinen har 2 netkort, eth0 og eth1. På eth0 er den forbundet til en hub på det interne net, og på eth1 er der hul til ISP'ens gateway, der har nummer 130.3.2.1, en såkaldt klasse B adresse, som har netmaske 255.255.255.0 så den fungerer som en klasse C adresse, med max 255 maskiner i netværket.

Det interne net har adresser i området 192.168.67.0 - 255. Det er for at være lidt på tværs, at jeg altid anbefaler andet end 192.168.1.1-254 om ikke andet, så kan de værste root-kit til intrusion på lokalnet herved vanskeligere få adgang ved spoofing.

Vi starter med at konstatere, at man ikke kan lave en default policy som kun gælder for det ene netkort. Derfor adskilles trafikken, således at alt input fra eth1 ledes igennem en kæde, som kaldes door1.

Door1 skal ende med at droppe al trafik, som vi ikke ønsker ind i vores netværk. De ting, som vi gerne vil have med, skal accepteres med en kommando -j ACCEPT.

Det aller første, scriptet gør, er at sikre, at netfilter delen i kernen er i en kendt tilstand, d.v.s. vi flusher alle regler i alle kæder og sætter alle default policies. Hvis man prøver at optimere ved kun at foretage de nødvendige ting for ens opsætning efter et boot, så skal man lige sørge for at have en version liggende, som kan klare alle situationer.

Det næste, der sker, er at kæden door1 slettes. Det sker selvfølgelig for at sikre, at der ikke ligger rester af andre regler i door1.

Det kan gøres på mange mange andre måder, men denne her metode er valgt efter lidt eksperimenteren. Man får også nulstillet tællerne for door1, og fejlene er ikke nogen, som får systemet til at hænge, hvilket vistnok har kunnet forekomme med nogle af de iptables options, som giver fejl, hvis man kører dem selv om de ikke er nødvendige. Læseren kan eksperimentere med at flushe kæden door1 i stedet for (også hvis den ikke findes).

Næste skridt er så at oprette kæden door1. Nu er den tom - ingen regler, ingen forbindelse med andre kæder. Lister man med -L kommandoen, får man at vide "no references", svarende til død kode eller ubrugt variabel.

Nu installeres regel efter regel i firewallen. De vigtigste er stadig dem, som tillader brugere indefra at kommunikere frit, men man skal lige huske, at denne trafik altid starter med input fra eth0, som vi slet ikke ser i denne door1 kæde. Indtil videre er der fri passage indefra og ud. Det er først til sidst, at der etableres en regel som siger, at al indadgående trafik fra eth1 skal via door1. Det kunne lige så godt have været først, og under alle omstændigheder må man kun aktivere eth1, når alle reglerne i firewallen er opsat. Man kan godt opsætte regler for et interface, som er "down", ifconfig eth1 down .

Der åbnes for al trafik til ssh-porten, både den indefra-ud og udefra-ind. Ligeledes åbnes der for al trafik til http porten.

Næste regel åbner for indkommende trafik, der stammer fra port 53, nameservere.

Nu kommer en regel, som kun skal benyttes, hvis ISP benytter DHCP til kontrol af IP, nameservices og routing. Det er en god ting og forhindrer slet ikke, at man selv styrer opsætningen.

Der åbnes også for ping. Det er ikke et krav for en firewall, men er ok at gøre på en maskine, der står udenfor en firewall men inden en gateway. I eksemplet her er gateway og firewall den samme, men det er ok at åbne for ping/ICMP, hvis man holder øje med trafikken.

Endelig kommer de spændende linier, hvor der åbnes for indgang for alt, hvad der er svar på forbindelser etableret indefra.

Dernæst er der kun opsætning af NAT-ing og aktivering af forwarding.

#/bin/ksh

iptables -t filter -F
iptables -t nat    -F
iptables -t mangle -F
iptables -X door1 2> /dev/null 1>&2
iptables -N door1

iptables -A door1 -m state --state INVALID -j DROP
# åbne for al ssh og http
iptables -A door1 -p tcp --sport ssh  -j ACCEPT
iptables -A door1 -p tcp --dport ssh  -j ACCEPT
iptables -A door1 -p tcp --sport http -j ACCEPT
iptables -A door1 -p tcp --dport http -j ACCEPT
# åbne for svar fra nameserere, DNS.
iptables -A door1 -p udp --sport 53   -j ACCEPT
# der åbnes for konversation med dhcp serveren på gatewayen.
iptables -A door1 -p udp --source 130.3.2.1 --dport bootps -j ACCEPT
# åbne for ping (mange vil foretrække at lukke i stedet!)
iptables -A door1 -p icmp             -j ACCEPT
# Alt, hvad der er etableret indefra, accepteres.
iptables -A door1 -m state --state ESTABLISHED,RELATED  -j ACCEPT
# alt andet smides væk.
iptables -A door1 -j DROP

# Hop til door1 hvis input er fra eth1
iptables -A INPUT -i eth1 -j door1

# NAT-ing sættes op, så alt, hvad der kommer fra lokalnettet,
# bliver videresendt som om det kommer fra firewallen.
iptables -t nat -A POSTROUTING --src 192.168.67.0/24 \
         -o eth1 -j SNAT --to 130.3.2.99

# for at det skal fungere, må vi aktivere forwarding:
echo 1 >> /proc/sys/net/ipv4/ip_forward

Der er mange andre ting, man kan foretage sig, for at maskinen bliver sikret: http://www.bastille-linux.org/. Det kaldes også "hardening", hærdning, af et system. For eksempel anbefales det på udsatte systemer at fjerne de tools, som en systemadministrator bruger til sletning, kopiering og omdøbning af filer, mount, diskformatering, oprettelse af filsystemer mv. Hvis en cracker opnår root-privilegier, vil aktionsmulighederne derved være begrænset. Men det vil for de fleste private medføre irritationsmomenter i det daglige arbejde. Man kunne selvfølgelig have en supplements-server stående, som man lige kunne hooke op når man havde brug for det ...

Sådan er der så mange ting, man kunne gøre. De fleste af disse tiltag beskrives i sidste afsnit

Kommentarer til ovenstående firewall er velkomne, særligt hvis der er konkrete ting, som er afprøvet, men også kommentarer, som bevæger sig i yderkanten af emnet.

6.5.7. Linux som proxy server

I det følgende beskrives den situation, at en virksomhed med 40 ihærdige brugere på en 2 Megabit forbindelse ønsker at forbedre browser-response, således, at når en person har hentet en web-side, så kan de andre hente den samme web-information lokalt fra en server med buffer, en såkaldt caching proxy.

#squid.conf -  Basal opsætning

#Laveste niveau af logging
debug_options ALL,1

#Gruppe af IP numre, som kan tilgå Squid (Access Control List) 
#Vil man kun give access til netværket 192.168.0.0/255.255.255.0
#så brug følgende linje
acl all src 192.168.0.0/255.255.255.0

#Skal alle kunne bruge Squid så udkommenter følgende linje.
#acl all src 0.0.0.0/0.0.0.0

#Port, man anvender til opsætning af Netscape klienter
http_port 3128

#Lad alle i ACL bruge Squid til HTTP
http_access allow  all

#test følgende sites for at tjeke, om maskinen er koblet til internettet
dns_testnames internic.net usc.edu cs.colorado.edu mit.edu yale.edu

#Kør som effektiv bruger squid og gruppe squid
cache_effective_user squid squid

# Squid vil oftest bruge to-tre gange denne RAM størrelse. Vil man max
# bruge 24 Mb RAM til Squid, så sæt cache_ram til 8 Mb. 
# Jo mere cache_mem desto hurtige er cachen (mindre diskaccess).
cache_mem  8 MB

#Maximal størrelse på object i cache
maximum_object_size 4096 KB

# Næste parameter-opsætning er disk cache struktur. Parametre er
#  Dirname - hvor på disken er disk cache, dvs. spool dir
#  Mbytes under spool dir - hvor mange Mb må gemmes i disk cache.
#  Level-1 dir antal - Antal underkataloger under Dirname
#  Level2 dir antal - Antal underkataloger for hver Level-1 kataloger
# Sæt ikke produktet mellem de to sidste vildt højt!
cache_dir /var/spool/squid 100 16 256

#rpm -ivh squid-2.2.STABLE5-1.i386.rpm

[root@sherwood root]# /usr/sbin/squid -z

setenv http_proxy http://proxy.herne.dk:3128/
setenv gopher_proxy http://proxy.herne.dk:3128/
setenv ftp_proxy http://proxy.herne.dk:3128/ 

6.5.8. Masquerading med ipchains (kerne 2.2)

I Linux-kerne 2.2 hedder firewall kommandoen ipchains , og denne kommando bruges også til opsætning af masquerading.

Forwardkæden sættes op med en default target MASQ eller, hvis default politik (policy). Den kan stadig væk smide væk, men i ipchains hedder det DENY.

Den simple og hurtige måde at sætte IP masquerading op på er:

[root@myhost /root]# ipchains -A forward -i ppp0 -j MASQ
[root@myhost /root]# ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
[root@myhost /root]# echo 1 > /proc/sys/net/ipv4/ip_forward

hvor ppp0 er det interface, der peger ud imod verden, imod internettet, imod det net, man vil give sine maskiner adgang til via masquerading.

Det kan også give mening at sætte timeouts for masquerading forbindelserne:

[root@myhost /root]# ipchains -M -S 7200 10 160

Det første tal er timeout for en tcp forbindelse, det næste er hvor længe en tcp forbindelse skal kunne eksistere efter modtagelsen af en FIN pakke, og det sidste er timeout for UDP. Timeout tiderne er i sekunder. Default timeout er 15 minutter, og det kan være lidt kort for en tcp session.

Nu sættes de andre maskiner i lokalnetværket til at bruge myhost som default gateway, og voila! Man kan komme på internettet fra de andre maskiner.

[root@myhost /root]# /sbin/modprobe ip_masq_ftp
[root@myhost /root]# /sbin/modprobe ip_masq_raudio

route add default gw myhost