Nasjonal sikkerhetsmyndighet

Transkript

1 Nasjonal sikkerhetsmyndighet IT-veiledning for ugradert nr 11 (U-11) Oppdatert ELK-stakken Systemovervåking ved bruk av ELK-stakken Hvordan bruke Elasticsearch, Logstash og Kibana på Linux-plattformen til systemovervåking. Dette dokumentet beskriver systemovervåking av et IT-system ved bruk av ELK-stakken. ELK-stakken kombinerer programmene Elasticsearch, Logstash og Kibana. Dokumentet beskriver bruksområder og fordeler ved ELK-stakken på Linux-plattformen. Dokumentet anbefaler tiltak for sikring av ELK-stakken og beskriver en stegvis eksempelinstallasjon. Målgruppen for dokumentet er personell som designer, utvikler og administrerer ugraderte IT-systemer.

2 Nasjonal sikkerhetsmyndighet Nasjonal sikkerhetsmyndighet er tverrsektoriell fag- og tilsynsmyndighet innenfor forebyggende sikkerhetstjeneste i Norge og forvalter lov om forebyggende sikkerhet av 20. mars Hensikten med forebyggende sikkerhet er å motvirke trusler mot rikets selvstendighet og sikkerhet og andre vitale nasjonale sikkerhetsinteresser, primært spionasje, sabotasje og terrorhandlinger. Forebyggende sikkerhetstiltak skal ikke være mer inngripende enn strengt nødvendig, og skal bidra til et robust og sikkert samfunn. Hensikt med veiledning NSM sin veiledningsvirksomhet skal bygge kompetanse og øke sikkerhetsnivået i virksomhetene, gjennom økt motivasjon, evne og vilje til å gjennomføre sikkerhetstiltak. NSM gir jevnlig ut veiledninger til hjelp for implementering av de krav sikkerhetsloven stiller. NSM publiserer også veiledninger innen andre fagområder relatert til forebyggende sikkerhetsarbeid. Postadresse Sivil telefon/telefaks Militær telefon/telefaks Internettadresse Postboks / / Sandvika E-postadresse post@nsm.stat.no Systemovervåking ved bruk av ELK-stakken Side 2 av 21

3 Innhold 1 Innledning Oversikt Om ELK-stakken Oversikt Logstash Elasticsearch Kibana SHIELD Anbefalte tiltak for sikring av ELK-stakken Bruk sikkerhetskomponenten SHIELD Bruk SHIELD sin rollebaserte tilgangskontroll Bruk SHIELD mot eksisterende LDAP eller AD brukerdatabaser i systemet Bruk sertifikater i SHIELD for å etablerere sikker ELK-kommunikasjon Bruk HTTPS i SHIELD for sikker kommunikasjon mellom ELK-brukeren og Kibana Bruk SHIELD for å registrere innloggingshendelser på Kibana Bruk SHIELD for å hviteliste loggkilder som har lov til å sende loggdata til Logstash Verifiser korrekt implementasjon og konfigurasjon av ELK-stakken Ta backup av Elasticsearch-loggdatabasen Hold ELK-programvaren oppdatert Vedlegg A Oppsummering Vedlegg B Eksempelinstallasjon B.1 Oversikt B.2 Steg 1: Elasticsearch B.3 Steg 2: Logstash B.4 Steg 3: Kibana B.5 Steg 4: Pek syslog-ng til Logstash Vedlegg C Brannmurregler Vedlegg D Referanser Vedlegg E Dokumenthistorie Systemovervåking ved bruk av ELK-stakken Side 3 av 21

4 Systemovervåking ved bruk av ELK-stakken Side 4 av 21

5 1 Innledning Dette dokumentet beskriver systemovervåking av et IT-system ved bruk av ELK-stakken. ELK-stakken kombinerer programmene Elasticsearch, Logstash og Kibana. Dokumentet beskriver bruksområder og fordeler ved ELK-stakken på Linux-plattformen. Dokumentet anbefaler tiltak for sikring av ELK-stakken og beskriver en stegvis eksempelinstallasjon. Målgruppen for dokumentet er personell som designer, utvikler og administrerer ugraderte IT-systemer. Kontaktpunkt for denne veiledninger er Kommentarer mottas med takk. Fordeler med systemovervåking. Det kan gi stor verdi for en virksomhet å etablere systemovervåkning av virksomhetens IT-system. Denne verdien øker i takt med systemets størrelse og aktivitetsnivå. ITavdelingen til virksomheten kan bruke innsamlede loggdata for å danne seg et bilde av tilstanden til IT-systemet. Et systemovervåkingsverktøy som i nær sanntid samler inn, sammenstiller og analyserer loggdata gjør IT-avdelingen i stand til å: Raskt detektere uønsket aktivitet, ytelsesproblemer og feil Holde oversikt over endringer, f eks ny maskin- og programvare Kartlegge faktisk aktivitet/belastning og behov for endring av systemet Samle inn og arkivere logger, f eks til bruk ifm feilsøking og feilretting Utilstrekkelig systemovervåking av et IT-system kan få forretningskritiske konsekvenser dersom problemer ikke raskt oppdages og nødvendige mottiltak blir iverksatt i tide. Fordeler ved bruk av ELK-stakken. ELK-stakken: Støtter populære loggformater, f eks syslog Støtter et bredt og voksende utvalg av loggkilder Normaliserer loggdata fra ulike kilder til et standardisert JSON-format Lagrer de normaliserte loggdataene i en indeksert og søkbar nosql-database Produserer grafiske rapporter som kan brukes til trendanalyse Er gratis tilgjengelig under Apache License 2.0 ELK-stakkens utviklere, Elastic[2], tilbyr også en tilleggsmodul, SHIELD. Denne modulen både hjelper administratorer med å implementere eksisterende ELK-sikkerhetsfunksjonalitet og tilbyr ytterligere sikkerhetsfunksjonalitet, blant annet rollebasert tilgangskontroll. Systemovervåking ved bruk av ELK-stakken Side 5 av 21

6 2 Oversikt Dette dokumentet beskriver hvordan ELK-stakken fungerer og anbefaler tiltak for grunnsikring. Vedlagt er en stegvis eksempelinstallasjon og brannmurregler. Kapittel 3 beskriver ELK-stakken og går nærmere innpå komponentene Elasticsearch, Logstash, Kibana og SHIELD. Det beskrives hvordan det anbefales å implementere ELK-stakken og hvor i IT-systemet de forskjellige komponenten bør plasseres. Vi følger dataflyten igjennom ELK-stakken og forklarer hva som skjer i hver enkelt systemkomponent. Rollen til sikkerhetskomponenten SHIELD beskrives også i forhold til dataflyten. Kapittel 4 beskriver hvordan man kan: Bruke SHIELD sin rollebaserte tilgangskontroll Koble SHIELD mot eksisterende LDAP eller AD brukerdatabaser i systemet Bruke sertifikater i SHIELD for å etablere sikker ELK-kommunikasjon Bruke HTTPS i SHIELD for sikker kommunikasjon mellom ELK-brukeren og Kibana Bruke SHIELD for å registrere innloggingshendelser på Kibana Bruke SHIELD for å hviteliste enheter som skal kunne sende loggdata til Logstash Det anbefales også å verifisere korrekt implementasjon og konfigurasjon, ta backup av Elasticsearchloggdatabasen og holde ELK-programvaren oppdatert. Vedlegg A oppsummerer dokumentet. Ved å bruke ELK-stakken kan man holde oversikt over endringer i IT-systemet, oppdage uønsket aktivitet og kartlegge aktivitet. Vedlegg B gir en stegvis beskrivelse av vår eksempelinstallasjon av ELK-stakken. Stegene beskriver nedlasting, installasjon og konfigurasjon av ELK-stakken. For å generere test-data til ELK-stakken bruker vi en BIND DNS-server som leverer sine loggdata til Logstash via DNS-serverens syslog-ng-tjeneste. Vedlegg C beskriver hvilke nettverksporter som ELK-stakken bruker og hvordan man kan åpne for disse nettverksportene i brannmuren SuSEfirewall2 / iptables. Vedlegg D angir referansene som er brukt i dette dokumentet. Vedlegg E inneholder dokumenthistorikken. Systemovervåking ved bruk av ELK-stakken Side 6 av 21

7 3 Om ELK-stakken ELK-stakken er et utbredt systemovervåkingsverktøy som blant annet brukes av aktører som Microsoft [4], Cisco [5], Mozilla [6], Facebook [7], Netflix [8], NASA [9], Soundcloud [10], Github [11], CERN [12] og Stack Exchange [13]. ELK-stakken brukes også av National Security Agency (NSA) i deres System Integrity Management Platform (SIMP) [14]. ELK-stakken får sitt navn fra komponentene den består av: Elasticsearch, Logstash og Kibana. Logstash konverterer loggdata fra ulike kilder til ett felles Java Script Object Notation (JSON)-format. Elasticsearch indekserer og lagrer JSON-loggdata i en sentral database. Kibana presenterer loggdata grafisk til brukeren i nettleseren. Den første versjonen av ELK-stakken ble utgitt i 2010 av Shay Banon [1] og videreutvikles kontinuerlig av firmaet Elastic [2]. Ny funksjonalitet og sikkerhetsoppdateringer produseres og utgis jevnlig. Komponentene i ELK-stakken er åpen kildekode som er tilgjengelig på nettsiden til Elastic [2]. ELK-stakken kjører på alle operativsystemer som støtter Java, inkludert Windows, Linux og Mac OS X. ELK-stakken har en egen tilleggsmodul for sikkerhet (SHIELD) som tilbyr viktig sikkerhetsfunksjonalitet. Se Figur 1 og Kapittel 3.5 for flere detaljer. 3.1 Oversikt Figur 1 viser dataflyten mellom ELK-komponentene, samt hvor SHIELD bidrar til å sikre ELK-stakken: Figur 1: Dataflyt i ELK-stakken Påfølgende tekst beskriver aktiviteter knyttet til dataflyten i Figur 1. Merk at nummereringen på avsnittene samsvarer med tilsvarende nummererte elementer i Figur 1. Systemovervåking ved bruk av ELK-stakken Side 7 av 21

8 1. Hver enkelt loggkilde som bruker syslog-ng (eller andre systemloggere) sender en kopi av sine loggdata til Logstash. Logstash lytter på standardporten for syslog (TCP/UDP 514) og behandler fortløpende mottatte loggdata. Logstash kan ha en hviteliste over servere som den aksepterer loggdata fra. 2. Logstash gjenkjenner forskjellige typer loggdata ved hjelp av sine mange utvidelser. Utvidelsene konverterer loggdata til et felles format, JSON som videresendes til Elasticsearch for videre behandling. 3. Elasticsearch lagrer JSON som mottas fra Logstash i en indeksert nosql database optimalisert for søking. 4. Kibana henter ut loggdata fra Elasticsearch-databasen ved hjelp av JSON spørringer. Spørringene genereres av brukeren ved hjelp av et web-grensesnitt. Web-grensesnittet leveres til ELKbrukere i HTML 5 og Cascading Style Sheet (CSS) som kan åpnes i alle populære nettlesere som f eks Firefox. For å gi brukeren et oppdatert bilde av loggdata, sendes logghendelser fortløpende fra loggkildene til Logstash. Fortløpende betyr at logghendelser sendes en-etter-en og ikke samles opp og sendes aggregert til Logstash, men sendes en-etter-en. Det anbefales at hver enkel loggkilde har en lokal kopi av sine loggdata for å unngå å miste data dersom nettverksproblemer oppstår. På steder hvor logger blir lagret er det viktig å konfigurere logg-rotasjon slik at ikke disken fylles opp og dermed stopper videre logging. I Figur 1 trenger ikke ELK-stakken å installere egen programvare på hver enkel loggkilde fordi syslogng brukes i Linux. Dataflyten i nettverket kan kontrolleres ved hjelp av brannmurer som deler opp nettverket. Det anbefales å konfigurere brannmuren slik at ELK-brukere ikke har tilgang til Elasticsearch direkte, kun via Kibana. For å beskytte integriteten til innsamlede loggdata bør loggkildene ha minst mulig tilgang til ELK utover å sende loggdata. 3.2 Logstash Logstash er et logginnsamlingsverktøy som brukes for å samle inn loggdata i ulike loggformater, filtrere og konvertere til JSON-format. Logstash er en bakgrunnsprosess (daemon) som kontinuerlig lytter etter loggdata på standardporten til syslog (port 514) eller port Syslog-ng bruker vanligvis UDPprotokollen, men kan også bruke TCP. Forklart under er prosessen som utføres når gang Logstash mottar logghendelser. Figur 2: Logstash dataflyt Påfølgende tekst gir en stegvis forklaring av Figur 2: 1. Logstash mottar forskjellige typer loggdata fra loggkilder i nettverket. 2. Filter (f eks DNS-filter) gjenkjenner loggdata og filtrerer bort unyttig tekst Systemovervåking ved bruk av ELK-stakken Side 8 av 21

9 3. Loggdata konverteres til JSON-format ved hjelp av en kodek 4. JSON sendes til Elasticsearch for indeksering og lagring i databasen Logstash har over 200 utvidelser som kan brukes til tolking av forskjellige loggformater. Utvidelsene er laget for å kjenne igjen loggdata fra de fleste servere som brukes i dag. Hvis man har egne applikasjoner som ikke gjenkjennes av utvidelsene kan man lage egne utvidelser i programmeringsspråket Ruby. Utvidelsen GROK kan brukes til REGEX-liknende tekstgjenkjenning. En oppdatert liste over utvidelsene finnes i online-dokumentasjonen [15] til Logstash. 3.3 Elasticsearch Elasticsearch er et søke- og analyseverktøy basert på Apache Lucene [16]. Elasticsearch benytter Schema-free databasestruktur og data er lagret i JSON-format. For å kommunisere med Elasticsearch brukes et RESTful web-application Programming Interface (API). Man kan kommunisere med databasen til Elasticsearch direkte ved å sende forespørsler i JSON-format. Dette gjør Elasticsearch fleksibel fordi kommunikasjon ikke er låst til Kibana. Man kan lage egne applikasjoner som kommuniserer ved databasen ved hjelp av web-apiet. For å spre belastningen i forbindelse med behandling av loggdata kan man starte flere forekomster av Elasticsearch. Forekomster av Elasticsearch kan være spredt på flere maskiner i nettverket. 3.4 Kibana Kibana presenterer loggdata til brukeren i form av grafiske websider. Disse websidene kan brukes til systemovervåking og kan oppdateres i sanntid. Kibana er konfigurerbar slik at brukeren selv kan velge hvilke data som skal hentes ut fra Elasticsearch databasen og hvordan de skal presenteres. Kibana gjør det lettere å definere tidsperioden man vil se på data fra og hvor ofte siden skal oppdateres. HTML 5 kombinert med Cascading Style Sheet (CSS) brukes til å produsere flere ulike grafer og diagrammer for representasjon av data. Designet kan utformes til å skape en sømløs integrasjon med eksisterende intranettsider. I Kibana kan man opprette skreddersydde kontrollpanel til ulike bruksområder. Kibana kombinert med SHIELD styrer tilgangen til kontrollpanel etter need-to-know prinsippet. Dokumentasjon [15] om hvordan man utformer kontrollpanel finner man på nettsiden til Elastic. Man kan også bruke søkeordene kibana og Dashboard i søkemotorer. Kibana tilbyr en funksjon for å eksportere oppsett av et kontrollpanel til en fil som man enkelt kan ta med seg eller sikkerhetskopiere. 3.5 SHIELD Elastic ga i 2015 ut tilleggsmodulen SHIELD til ELK-stakken. SHIELD inneholder et sikkerhets-api som legger seg på toppen av ELK-stakken og fungerer som et sikkerhetslag. SHIELD har følgende hovedfunksjoner: Autentisering Autorisering Sikker nettverkskommunikasjon IP-filtrering Sporbarhet Du kan lese mer om sikkerhetsfunksjonaliteten i kapittel 4. Systemovervåking ved bruk av ELK-stakken Side 9 av 21

10 4 Anbefalte tiltak for sikring av ELK-stakken Dette kapittelet anbefaler tiltak for sikring av ELK-stakken. 4.1 Bruk sikkerhetskomponenten SHIELD Utgiveren av ELK-stakken har utviklet en egen komponent som tilbyr sikkerhetsfunksjonalitet som går utover standardfunksjonaliteten til ELK. NSM anbefaler følgende bruk av SHIELD: Bruk SHIELD sin rollebaserte tilgangskontroll Koble SHIELD mot eksisterende LDAP eller AD brukerdatabaser i systemet Bruk sertifikater i SHIELD for å etablere sikker ELK-kommunikasjon Bruk HTTPS i SHIELD for sikker kommunikasjon mellom ELK-brukeren og Kibana Bruk SHIELD for å registrere innloggingshendelser på Kibana Bruk SHIELD for å hviteliste enheter som skal kunne sende loggdata til Logstash I motsetning til ELK-stakken er SHIELD et kommersielt produkt Bruk SHIELD sin rollebaserte tilgangskontroll Ved å bruke rollebasert tilgangskontroll kan man gjøre administrasjon av rettigheter mye enklere. Man kan definere sikkerhetsgrupper med gitte tilganger som brukere kan være medlem av. Dette gjør at det er mye lettere å tildele og fjerne rettigheter til brukere. Det er også mye lettere å oppdatere tilganger hos flere brukere på en gang. I ELK-stakken kan man for eksempel ha en tilgangsrolle per kontrollpanel. Forenkling av administrasjon øker sikkerheten fordi det minsker sjansen for feilkonfigurasjon Bruk SHIELD mot eksisterende LDAP eller AD brukerdatabaser i systemet Fordi ELK-stakken støtter bruken av en eksisterende brukerdatabase slipper man å vedlikeholde flere brukerdatabaser. Dette øker sikkerheten fordi flere databaser øker risikoen for feilkonfigurasjon og skaper ekstra administrasjonsarbeid Bruk sertifikater i SHIELD for å etablerere sikker ELK-kommunikasjon ELK-stakken bruker sertifikater for å etablere tiltro til servere på nettverket. Servere kan autentisere hverandre på nettverket ved hjelp av sertifikater som er signert av en felles root certificate authority. X.509 sertifikater gjør det mulig å bruke public key kryptografi til nøkkelutveksling Bruk HTTPS i SHIELD for sikker kommunikasjon mellom ELK-brukeren og Kibana Kibana har støtte for å bruke HTTPS protokollen for å sende web-trafikk sikkert til brukeren ved hjelp av kryptering og autentisering. Dette gjøres ved å installere et X.509 sertifikat i Kibana som er signert av en Certificate Authority (CA) klientene har tillit til. Fordi sertifikatet er signert av en CA som klientene har tillit til kan klientene verifisere identiteten til Kibana. Dette gjør at man har tillit til at informasjonen som kommer fra Kibana ikke er endret ved hjelp av et «man in the middle angrep» og at ingen kan avlytte trafikken. Kibana får tillit til klientene når de har logget inn med brukernavn og passord. Systemovervåking ved bruk av ELK-stakken Side 10 av 21

11 4.1.5 Bruk SHIELD for å registrere innloggingshendelser på Kibana Kibana bruker autentiseringslogging for å registrere når noen logger på eller prøver å logge på. Denne mekanismen gjør at man kan oppdage når noen logger in på mistenkelige tidspunkter eller mislykkede påloggingsforsøk. Hvis kompromitterte klienter prøver brute force angrep for å knekke passord kan dette oppdages ved hjelp av autentiseringslogging Bruk SHIELD for å hviteliste loggkilder som har lov til å sende loggdata til Logstash Ved å bruke en hviteliste over hvilke loggkilder som kan sende loggdata til Logstash kan man hindre at Logstash mottar data fra ikke-autoriserte enheter. For å bruke SHIELD kreves det en aktiv lisens som kan kjøpes på nettsiden til Elastic. Elastic tilbyr tre lisenstyper som gir tilgang til pakkeløsninger med SHIELD inkludert. Ved kjøp av en lisens får man blant annet tilgang til Marvel, Watcher og kundesupport. Marvel er en tilleggskomponent som tilbyr maskinvare-overvåking av komponenter i ELK-stakken. Watcher er en tilleggskomponent som gir beskjed via eller andre kommunikasjonskanaler dersom forhånds-konfigurerte hendelser oppstår i ELK-stakken. Den offisielle SHIELD dokumentasjonen ligger på nettsiden til Elastic [17]. 4.2 Verifiser korrekt implementasjon og konfigurasjon av ELK-stakken For å ha tiltro til programvaren som brukes i et IT-system er det viktig at det kommer fra en sikker kilde og er konfigurert og implementert riktig. Aldri last ned programvare fra ukjente kilder fordi denne kan inneholde ondsinnet kode. For å forsikre seg om at ELK-stakkens komponenter ikke er endret av noen andre enn Elastic er det viktig å kun laste ned fra en sikker kilde (Elastic sin nettside) ved bruk av HTTPS. HTTPS øker tiltro til at innholdet man laster ned ikke har blir endret på veien. Pakkeadministrasjonssystemet til OpenSUSE anses også som en sikker kilde fordi pakkene er testet og signert. Sikker nedlasting gjelder også når man laster ned tilleggskomponenter og filtere. Testing er en konkret prosedyre for å sikre at installasjon og konfigurasjon har blitt riktig utført. Under følger noen få eksempeltester som kan brukes til verifikasjon. Verifiser at Elasticsearch kjører. For å sjekke statusmeldinger og at Elasticsearch kjører kan man bruke kommandolinje verktøyet CURL. Bruk følgende kommando: curl localhost:9200 Ønsket svar: { "status" : 200, "name" : "Supernalia", "cluster_name" : "elasticsearch", "version" : { "number" : "1.4.3", "build_hash" : "36a29a7144cfde87a960ba039091d40856fcb9af", "build_timestamp" : " T14:23:15Z", "build_snapshot" : false, Systemovervåking ved bruk av ELK-stakken Side 11 av 21

12 "lucene_version" : "4.10.3" }, "tagline" : "You Know, for Search" } Ved å kjøre kommandoen over får man et svar som likner dette hvis alt er som det skal. Her vil man få informasjon som status, kompileringstidspunkt og versjonsinformasjon om kjørende Elasticsearch. En spesielt viktig attributt her er status. Hvis man får en feil når man kjører denne kommandoen bør man hoppe videre til neste test. Undersøk logger. Når man har startet Elasticsearch kan man verifisere at ingen feil oppstod ved å undersøke lokale systemlogger. Hvis man bruker operativsystemet OpenSUSE kan man se loggene ved hjelp av kommandoen journalctl og søke etter elk eller Elasticsearch. Elasticsearch gjør detaljert logging av oppstartsprosessen og man får en god pekepinne på hvor potensielle problemer oppstår. Logginformasjon er alltid et godt utgangspunkt for videre feilsøking. Hendelsesaggregeringstest. For å forsikre seg om at loggdata blir sendt over nettverket og ender i Elasticsearch databasen kan man for eksempel generere en DNS-forespørsel til en DNS-server som er konfigurert til å sende logger til Logstash. Dette kan gjøre fra kommandolinja ved å bruke nslookup. nslookup nsm.stat.no Man kan følge med i debug-konsollen til Logstash for å se forespørslene i sanntid. Nettverkskrypteringstest. For å verifisere at SHIELD er implementert riktig og at nettverkstrafikken er kryptert kan Wireshark eller tcpdump brukes til å observere (sniffe) nettverkstrafikken. Hvis man kan lese DNS-forespørslene fra forrige test i klartekst blir ikke trafikken kryptert og man bør sjekke loggene. 4.3 Ta backup av Elasticsearch-loggdatabasen En prosess for sikkerhetskopiering av data er viktig i de fleste IT-system. Elasticsearch databasen og konfigurasjonsfiler bør inkluderes i sikkerhetskopieringsprosessen. For å ta backup av loggdatabasen kan man gjøre dette med en enkel CURL kommando: curl -XPUT ' -d '{ }' "type": "fs", "settings": { } "location": "/mount/backups/min_backup", "compress": true Navnet på sikkerhetskopien er i dette eksempelet min_backup og plasseres i /mount/backups/ katalogen. Navnet kan man endre til det man vil og compress angir om man vil at arkivet skal komprimeres eller ikke. Gjenoppretting av en sikkerhetskopi kan man gjøre med følgende kommando: curl -XPOST "localhost:9200/_snapshot/min_backup/snapshot_1/_restore" Systemovervåking ved bruk av ELK-stakken Side 12 av 21

13 4.4 Hold ELK-programvaren oppdatert For å beskytte seg mot angrep som utnytter sårbarheter i programvare er det viktig å holde programvare oppdatert. For å oppgradere til nyeste programvare kan man bruke pakkesystemene aptitude eller yum. Binærpakker kan også lastes ned over HTTPS fra nettsiden [18]. Mer informasjon om oppdateringsprosessen finner man i dokumentasjonen på nettsidene til Elastic [15]. Elastic har ingen fast dato hvor oppdateringer publiseres men man kan følge med på nettsidene. Elastic sender ut gratis nyhetsbrev en gang i uken med informasjon om oppdateringer. Det anbefales å ta backup av ELK-database før oppdatering. Systemovervåking ved bruk av ELK-stakken Side 13 av 21

14 Vedlegg A Oppsummering Å etablerer systemovervåking av IT-systemer kan gi stor verdi for organisasjoner av alle størrelser. For å opprettholde daglig drift trenger organisasjoner en måte å oppdage uønskede hendelser i IT-systemet så raskt som mulig. Det er også viktig å identifisere årsakene til uønskede hendelser slik at tiltak kan iverksettes for å forhindrer at uønskede hendelser gjentar seg. Ved å bruke ELK-stakken til systemovervåking av IT-system kan man oppdage uønsket aktivitet, holde oversikt over endringer i maskin- og programvare og kartlegge aktivitet. Utilstrekkelig systemovervåking kan få forretningskritiske konsekvenser dersom problemer ikke raskt oppdages. Logstash støtter populære loggkilder og standardiserer til JSON-format. Elasticsearch indekserer og lagrer loggdata i en søkbar nosql-database. Kibana produserer grafiske rapporter som kan brukes til trendanalyse. Det anbefales også at man bruker sikkerhetskomponenten SHIELD Bruk SHIELD sin rollebaserte tilgangskontroll Koble SHIELD mot eksisterende LDAP eller AD brukerdatabaser i systemet Bruk sertifikater i SHIELD for å etablere sikker ELK-kommunikasjon Bruk HTTPS i SHIELD for sikker kommunikasjon mellom ELK-brukeren og Kibana Bruk SHIELD for å registrere innloggingshendelser på Kibana Bruk SHIELD for å hviteliste enheter som skal kunne sende loggdata til Logstash SHIELD utvikles og vedlikeholdes av Elastic og tilbyr grunnleggende sikkerhetsfunksjonalitet. ELK-stakken anbefales av NSM og brukes av mange store aktører som blant annet National Security Agency (NSA). Systemovervåking ved bruk av ELK-stakken Side 14 av 21

15 Vedlegg B Eksempelinstallasjon Dette vedlegget beskriver en stegvis beskrivelse av en eksempelinstallasjon satt opp i et virtuelt VMware-miljø. B.1 OVERSIKT I vår eksempelinstallasjon har vi valgt å installere alle komponentene til ELK-stakken på samme virtuelle maskin for enkeltheten sin skyld. I et produksjonsmiljø anbefaler vi en logisk avgrensing i nettverk og dedikerte virtuelle eller fysiske maskiner. Vi går igjennom stegene som skal til for å installere og konfigurere komponentene slik at alt fungerer som det skal. Det anbefales å ikke kjøre noen av komponentene i denne eksempelinstallasjonen med root-privileger. Vi tar i bruk to virtuelle maskiner på et isolert nettverkssegment i vårt eksempel. Maskin 1: ELK-stakken. Virtuell maskin hvor vi installerer alle komponentene av ELK-stakken. Siden ELK-stakken er pakket i Java-pakker må vi også installere Java Development Kit (JDK). Maskin 2: DNS-server. Virtuell maskin hvor BIND DNS-server er installert og Syslog-ng som systemlogger. Denne maskinen bruker vi til å produsere DNS-forespørsler som logges og sendes til Logstash via Syslog-ng. ELK-stakken er ikke avhengig av en DNS-server og den brukes i vår eksempelinstallasjon kun for å produsere test-data. Følgende må være på plass før du går videre: OpenSUSE Linux operativsystem på begge maskinene Maskinene må være koblet sammen i et virtuelt nettverk Root-tilgang på begge maskinene Java JDK installert på maskin 1 BIND DNS som bruker syslog-ng systemlogger på maskin 2 Når dette er på plass er du klar til å starte installasjonsprosessen. B.2 STEG 1: ELASTICSEARCH Vi starter med å installere Elasticsearch før Logstash og Kibana fordi Elasticsearch trengs av de andre komponentene. ELK-stakken må installeres på den virtuelle maskinen hvor JDK er installert. Lag Elasticsearch bruker. Vi anbefaler å lage en egen bruker for hver komponent i ELK-stakken for å kontrollere aksess og ha bedre struktur. Elasticsearch installeres på hjemmeområdet til elasticsearch brukeren (/home/elasticsearch). sudo adduser elasticsearch su elasticsearch Last ned Elasticsearch. Elasticsearch er tilgjengelig på nettsiden til Elastic og kan lastes ned sikkert ved å bruke HTTPS derfra. Det anbefales alltid å bruke den siste stabile utgitte versjonen. cd ~/ & wget tar xvzf elasticsearch tar.gz Systemovervåking ved bruk av ELK-stakken Side 15 av 21

16 Tilpass systemet. For at Elasticsearch skal fungere optimalt må man øke antall filer Elasticsearch har lov til å åpne samtidig. Dette er et veldig vanlig krav for databaseapplikasjoner som behandler store mengder data. Rediger /etc/security/limits.conf med root-privileger og legg til følgende linjer: elasticsearch soft nofile elasticsearch hard nofile root soft nofile root hard nofile Rediger også /etc/sysctl.conf og legg til følgende line: fs.file-max = Når disse endringene er gjort er Elasticsearch klar til å startes. Elasticsearch startes ved å kjøre binærfilen Elasticsearch som ligger i bin katalogen. Husk å starte Elasticsearch med elasticsearch brukeren og ikke som root. Man kan verifisere at Elasticsearch kjører ved å bruke denne kommandoen: curl Hvis alt fungerer som det skal vil man få et svar som ligner dette: { } "status" : 200, "name" : "Whistler", "cluster_name" : "elasticsearch", "version" : { }, "number" : "1.6.0", "build_hash" : "cdd3ac4dde4f69524ec0a14de3828cb95bbb86d0", "build_timestamp" : " T13:36:34Z", "build_snapshot" : false, "lucene_version" : "4.10.4" "tagline" : "You Know, for Search" Det som er viktigs å legge merke til er at status har verdien 200. B.3 STEG 2: LOGSTASH Når Elasticsearch er på plass kan vi installere Logstash. Også for Logstash starter vi med å opprette en ny bruker. Lag Logstash bruker. Logstash installeres på hjemmeområdet til den nye brukeren (/home/logstash). Sudo adduser logstash Su logstash Last ned Logstash. Logstash er tilgjengelig på nettsiden til Elastic og kan lastes ned sikkert ved å bruke HTTPS derfra. Det anbefales alltid å bruke den siste stabile utgitte versjonen. Systemovervåking ved bruk av ELK-stakken Side 16 av 21

17 cd ~/ & Wget tar xvzf logstash tar.gz Konfigurer Logstash. For å konfigurere Logstash må vi opprette en konfigurasjonsfil som spesifiserer hvordan Logstash skal lytte etter hendelser og hvor de skal sendes. Navnet og plassering av denne filen kan man velge selv men formatet er JSON. Vi har valgt å kalle filen for logstash.conf og plassere den på hjemmeområdet. Vi må fortelle Logstash hvilke porter som skal brukes, hvilke filter som skal brukes og hvor data skal sendes. Under viser vi hvordan vår konfigurasjonsfil ser ut: input { } tcp { } port => 1999 filter { dns { type => 'type' reverse => [ "source_host", "field_with_address" ] resolve => [ "field_with_fqdn" ] action => "replace" } } output { } elasticsearch { host => localhost } stdout { codec => rubydebug } Når man installerer og tester kan det være lurt å sende utdata også til konsollen slik at man kan følge med på hva som skjer. Dette bør fjernes når man er ferdig å teste. Man kan skru debuglogging av og på ved å ta bort eller legge til denne linjen: stdout { codec => rubydebug } Vi bruker DNS-filteret fordi vi bruker en DNS-server til å produsere test-data i vår eksempelinstallasjon. Filtere kan man legge til etter behov slik at Logstash kjenner igjen loggdata som kommer inn. Full liste over tilgjengelige filtre finner man på nettsiden til Elastic under dokumentasjon. Start Logstash. For å fortelle Logstash om konfigurasjonsfilen som vi akkurat opprettet må vi spesifisere sti til filen ved oppstart slik: ~/bin/logstash f ~/logstash.conf Hvis vi har aktivert rubydebug kan vi nå se innkommende logger i konsollen i sanntid. Systemovervåking ved bruk av ELK-stakken Side 17 av 21

18 B.4 STEG 3: KIBANA Lag kibana bruker. Sudo adduser kibana Su kibana Last ned Kibana. Kibana installeres på hjemmeområdet til brukeren (/home/kibana). Cd ~/ & wget Tar xvzf kibana linux-x64.tar.gz Konfigurer Kibana. Kibana bruker konfigurasjonsfilen kibana.yml som du finner i config katalogen. I konfigurasjonsfilen må vi fortelle Kibana hvor Elasticsearch-databasen holder til. Vi kan spesifiserer dette i variabelen elasticsearch_url. Ved å redigere kibana.yml og sette elasticsearch_url til vil Kibana kunne kontakte Elasticsearch. Hvis Elasticsearch og Kibana kjører på samme maskin kan vi bruker localhost i stedet for IP adressen. Elasticsearch_url: Start Kibana. Kibana startes ved å kjøre binærfilen kibana. ~/bin/kibana Kibana kan nå aksesseres ved å peke nettleseren til IP]:5601 B.5 STEG 4: PEK SYSLOG-NG TIL LOGSTASH Nå som ELK-stakken er installert og kjører som den skal må vi fortelle systemloggeren syslog-ng om å sende en kopi av sine logger til ELK-stakken. Dette steget repeteres på alle servere som skal sende logger til ELK-stakken. I vår eksempelinstallasjon har vi allerede satt opp en DNS-server som bruker syslog-ng som systemlogger. Sørg for at dette er på plass før du går videre. Rediger syslog-ng.conf. syslog-ng.conf finner du vanligvis i /etc/syslog/ eller /etc/ katalogen. Vi må legge til en ny destinasjon og fortelle syslog om å sende logger hit. Let etter eksisterende destinasjoner i din konfigurasjonsfil og legg til den nye destinasjonen rett under den siste. Her er destinasjonen fra vår fil: destination logstash { }; tcp("[ip TIL ELK-Stakken]" port(1999)); log { source(src); destination(logstash); }; Bruk dette som mal og erstatt [IP TIL ELK-Stakken] med ip-adressen til maskinen hvor Logstash kjører. Den siste linjen forteller syslog at den skal bruke den nye destinasjonen. Når du har lagret endringene må syslog-ng startes på nytt for at endringene skal tre i kraft. Potensielle feil som oppstår finner du i /var/log/messages eller tilsvarende. Husk at dette steget må gjøres på alle servere man vil skal logge til ELK-stakken. Systemovervåking ved bruk av ELK-stakken Side 18 av 21

19 Vedlegg C Brannmurregler I vår eksempelinstallasjon av ELK-stakken bruker vi følgende tjenester og porter: Tjeneste Port Retning Elasticsearch 9200 Inn Logstash 1999 Inn Kibana 5601 Inn BIND DNS 53 Ut Syslog-ng 514 Ut I oppsettet vi bruker i vår eksempelinstallasjon kjører alle tjenestene på samme virtuelle maskin så vi trenger ikke åpne alle portene i brannmuren. Det er bare tjenestene Logstash, Kibana og BIND DNS som trenger å kunne snakke med noen på utsiden av brannmuren. Bortsett fra nevnte porter blokkeres alle nye innkommende forespørsler mens alle nye utgående forespørsler tillates. Alle portene vi har brukt i vårt eksempel kan forandres etter behov. OpenSUSE bruker verktøyet SuSEfirewall2 for å administrere iptables brannmuren. For å konfigurere SuSEfirewall2 redigerer man konfigurasjonsfilen som man finner her: /etc/sysconfig/susefirewall2. Som standard blokkeres alle innkommende forespørsler og alle utgående tillates. OpenSUSE lager automatiske brannmurregler for tjenester som installeres sammen med operativsystemet. Hvis man installerer komponentene på forskjellige maskiner må man redigere SuSEfirewall2 på hver enkelt maskin. For å åpne for tjenestene vi bruker i brannmuren må vi legge til følgende linjer nederst i konfigurasjonsfilen: FW_SERVICES_EXT_TCP='5601' FW_SERVICES_EXT_TCP='1999' FW_SERVICES_EXT_UDP='1999' FW_SERVICES_EXT_UDP='53' Husk å starte tjeneste på nytt slik at konfigurasjonen skal tre i kraft med: $SuSEfirewall2 stop $SuSEfirewall2 start Systemovervåking ved bruk av ELK-stakken Side 19 av 21

20 Vedlegg D Referanser [1] Shay Banon, 2010, [2] Elastic, 2015, [3] Apache License 2.0, 2015, [4] Microsoft, 2015, [5] Cisco, 2015, [6] Mozilla, 2015, [7] Facebook, 2015, [8] Netflix, 2015, [9] NASA, 2015, [10] Soundcloud, 2015, [11] Github, 2015, [12] CERN, 2015, [13] Stack Exchange, 2015, [14] System Integrity Management Platform (SIMP), 2015, [15] Online dokumentasjon, 2015, [16] Apache Lucene, 2015, [17] SHIELD, 2015, [18] Elastic nedlastingsside, 2015, Systemovervåking ved bruk av ELK-stakken Side 20 av 21

21 Vedlegg E Dokumenthistorie Internhøring Publisert Systemovervåking ved bruk av ELK-stakken Side 21 av 21