Product SiteDocumentation Site

Kapittel 14. Sikkerhet

14.1. Å definere et sikkerhetsopplegg
14.2. Brannmur eller pakkefiltrering
14.2.1. nftables-oppførsel
14.2.2. Overgang fra iptables til nftables
14.2.3. Syntaksen til nft
14.2.4. Å installere reglene ved hver oppstart
14.3. Tilsyn: Forebygging, avdekking, avskrekking
14.3.1. Monitorering av logger med logcheck
14.3.2. Aktivitetsmonitorering
14.3.3. Unngå inntrenging
14.3.4. Å finne endringer
14.3.5. Å avdekke inntrenging (IDS/NIDS)
14.4. Introduksjon til AppArmor
14.4.1. Prinsipper
14.4.2. Å aktivere AppArmor og håndtere AppArmor-profiler
14.4.3. Å lage en ny profil
14.5. Introduksjon til SELinux
14.5.1. Prinsipper
14.5.2. Oppsett av SELinux
14.5.3. Å håndtere et SELinux-system
14.5.4. Å tilpasse reglene
14.6. Andre sikkerhetsrelaterte overveielser
14.6.1. Iboende risiko for nett-applikasjoner
14.6.2. Å vite hva som forventes
14.6.3. Kloke valg av programvare
14.6.4. Å håndtere en maskin som en helhet
14.6.5. Brukere er spillere
14.6.6. Fysisk sikkerhet
14.6.7. Juridisk ansvar
14.7. Å håndtere en kompromittert maskin
14.7.1. Avdekke og se innbruddet
14.7.2. Å sette tjeneren Off-Line
14.7.3. Beholde alt som kan brukes som bevis
14.7.4. Reinstallering
14.7.5. Rettslig analyse
14.7.6. Å rekonstruere et angrepsscenario
Et informasjonssystem kan ha varierende viktighet avhengig av omgivelsene. Noen ganger kan det være livsviktig for bedriftens overlevelse, og må derfor beskyttes mot forskjellige former for risiko. Prosessen med å evaluere disse risikoene, definere og implementere beskyttelsesmekanismer, kalles med et fellesord «sikkerhetsprosessen».

14.1. Å definere et sikkerhetsopplegg

Ordet «sikkerhet» dekker et vidt spekter av konsepter, verktøy, og prosedyrer; ingen av dem dekker alle aspekter. Å velge mellom dem krever en presis idé om hvilke mål man vil oppnå. Å sikre et system starter med å svare på noen få spørsmål. Raser man avgårde, og implementerer et vilkårlig sett av tiltak, risikerer man å fokusere på feil ting.
Den absolutt første tingen å avgjøre er derfor målet. En god tilnærming til å hjelpe til med denne avgjørelsen er å starte med disse spørsmålene:
  • Hva prøver man å beskytte? Sikkerhetsopplegget vil være forskjellig avhengig av om man vil beskytte maskiner eller data. I sistnevnte tilfelle må vi også vite hvilke data.
  • Hva prøver vi å beskytte mot? Er det lekkasje av sensitive data? Tap av data? Tap av inntekt som følge av forstyrrelser i tjenesten?
  • Dessuten, hvem prøver vi å beskytte oss mot? Sikkerhetstiltakene vil variere stort mellom det å beskytte mot skrivefeil fra brukeren av systemet, og angrep fra motiverte grupper utenfra.
Ordet «risiko», i sikkerhetsøyemed, brukes gjerne som samlebegrep for disse tre faktorene: Hva som må beskyttes, hva som må hindres fra å skje, og hvem som det må beskyttes mot. Å modellere risikoen krever svar på disse tre spørsmålene. Utfra en slik risikomodell kan et sikkerhetsopplegg konstrueres, og dette kan implementeres gjennom konkrete tiltak.
Andre begrensninger er også verdt å tenke på, ettersom de kan sette grenser for tilgjengelige sikkerhetsopplegg. Hvor langt er man villig til å gå for å sikre systemet? Dette spørsmålet har store konsekvenser for hva som skal implementeres. Det besvares altfor ofte kun utfra økonomi, selv om andre kriterier også bør tas i betraktning, som ulemper som påføres brukeren, og tap av ytelse.
Først når risikoen er kartlagt, kan man begynne å tenke på å lage et konkret sikkerhetsopplegg.
I de fleste tilfeller kan informasjonssystemet segmenteres i konsistente og stort sett uavhengige subsett. Hvert subsystem vil ha sine egne krav og begrensninger, så risikovurderingen og utformingen av sikkerhetsopplegget bør gjøres separat for hvert subsystem. Et godt prinsipp å huske på er at en kort og veldefinert forsvarslinje er enklere å forsvare enn en lang og buktende en. Nettverksorganisasjonen bør også utformes tilsvarende; sensitive tjenester bør konsentreres på et lite antall maskiner, og disse maskinene bør bare være tilgjengelige via et minimalt antall innfallsporter; beskytting av disse innfallsportene vil være enklere enn å beskytte alle de sensitive maskinene mot den store utenomverdenen. Det er her nettverksfiltrering (inkludert brannmurer) kommer inn. Denne filtreringen kan implementeres med dedikert maskinvare, men en mulig enklere og mer fleksibel løsning er å bruke en programvarebrannmur, som den som er integrert i Linux-kjernen.