Loggesentralisering med Logging Made Easy

Artikkelen beskriver Logging Made Easy (LME) - en guide for installasjon og konfigurering av loggsentralisering utarbeidet av NCSC-UK (den britiske CERT-en).

Publisert: 15.12.2021

Mange enheter i ett nettverk produserer logger. Disse loggene kan gi sikkerhetsanalytikere kritisk innsikt for å oppdage og håndtere hendelser. Dessverre blir disse ofte kun lagret på enhetene som produserer dem, noe som vanskeliggjør analyse og korrelasjon, og medfører en risiko dersom enhetene blir kryptert av løsepengevirus. Ved å automatisere innsamling av loggene omgås flere av disse problemene. Loggene sentraliseres på ett kontrollert sted hvor de er tilgjengelig for både manuell og automatisk analyse. Denne artikkelen gir en kort beskrivelse av ett system for loggsentralisering, samt noen anbefalinger og nyttig tips fra Kommune-CSIRT.

Logging Made Easy (LME) er en guide for installasjon og konfigurering av loggsentralisering. Den er skrevet av britiske NCSC, som er en del av GCHQ. Guiden beskriver hvordan en IT-organisasjon kan bruke funksjonalitet innebygd i programvare de alt har, sammen med åpen kilde programvare, til å produsere og sentralisere logger. I tillegg inneholder den prekonfigurerte dashbord som kan brukes for å se etter mistenkelig aktivitet i nettverket, utdatert programvare, hvem som logger på hvor, m.m.

Før vi går videre er det verdt å nevne at LME ikke er en full erstatning for en SIEM løsning, men ett viktig steg i riktig retting. Løsningen er beregnet på små til middels store organisasjoner som ikke har mulighet til å skaffe seg en SIEM løsning. LME er gratis (gitt att man alt har Windows og litt ledig serverkapasitet), og man må derfor gjøre arbeidet selv for å ta den i bruk.

Forkunnskaper som anbefales er:

  • installasjon av Windows Server og kobling til ett AD-domene
  • deployering av GPOer eller annen metode for distribuering av konfigurasjon
  • endring av brannmurregler
  • installasjon og konfigurasjon av en Linux-maskin

Skissen over viser vår anbefaling for hvordan LME settes opp i nettverket, samt brannmurregler mellom de ulike maskinene. Dette vil selvfølgelig variere mellom organisasjoner. Noen nøkkelpunkter: klientnettverket må kunne snakke med WEC(Windows Event Collector), men kun en port er nødvendig, og WEC trenger ikke å kunne koble seg tilbake til klientene eller ut på internett for å motta logger. WEC og management klienter må kunne koble seg til ELK, men bare på noen få porter, og ELK trenger ikke å kunne nå noe som helst. Denne arkitekturen skalerer svært bra, med mulighet for å sette inn flere WEC-maskiner for å håndtere flere klienter eller klienter i ulike soner, og brannmurreglene reduserer angrepsflaten mellom de ulike enheten.

LME benytter Sysmon til å produsere logger på Windows klienter og Servere, og Windows Event Forwarding (WEF) til å sende dem til en WEC. Konfigurasjon av hvilke Event Logger som skal sendes og oppsett av WEC distribueres via GPO. Disse templatene er inkludert i guiden. WEF kan konfigureres både som push, hvor kilden kobler seg til WEC og initierer sending av logger, og pull, hvor WEC kobler seg til kildene og henter loggene. Kommune-CSIRT anbefaler push konfigurasjon, da dette skalerer bedre i store nettverk. GPOene som ligger i LME gjør dette som standard, og linken om push-konfigurering under inneholder tips til feilsøking.

WEF overfører logger ved hjelp av WinRM protokollen, som bygger på HTTP. Både HTTP og HTTPS kan benyttes, og LME benytter HTTP som standard. Dette er ett av svært få tilfeller hvor vi i Kommune-CSIRT sier det er greit å bruke HTTP, da innholdet i meldingen som sendes blir kryptert vha. Kerberos. HTTPS har noen fordeler over HTTP i dette tilfellet, som f.eks. sertifikat-basert autentisering og tillate at maskiner som ikke er medlem av domenet kan sende inn logger, men krever litt mer konfigurering. Se notater under for tillegg på guiden for å endre til HTTPS. I tillegg har vi observert at Windows Server 2016 og nyere setter feil tilganger på HTTP(S) endepunktene når disse settes opp. Se link under for hvordan dette kan fikses.

Til slutt i rekken står ELK-stacken. ELK står for Elasticsearch, Logstash og Kibana, som er åpen-kilde verktøy for å søke i, prosessere og visualisere logger. Denne maskinen kjøre ett Linux basert operativsystem, og bruker Docker til å forenkle installasjon og oppsett. Ubuntu LTS 20.04 anbefales som operativsystem, og er det vi har brukt i testing. LME inneholder ett script som installerer Docker, laster ned de riktige containerene, og starter opp tjenestene. Vi anbefaler derfor å starte med en helt ren Ubuntu installasjon, med mindre man har erfaring med Docker.

Kibana brukes for å søke i og visualisere logger. Webtjenesten kjører på ELK maskinen, og passordet for pålogging genereres under installasjon. Maskinen må derfor også være tilgjengelig fra management nettverk, eller tilsvarende, slik at loggene kan analyseres. LME kommer også med en rekke forhåndslagede dashbord til f.eks. å se hvilke prosesser som kjører på hvilke maskiner og hvem som logger på hvor i nettverket. I tillegg har Kibana støtte for «Detection rules», som er regler som kjøres over innkommende logger og produserer alarmer. Reglene som ligger inne som standard oppdager f.eks. prosesser som startes på mistenkelige måter og forsøk på nettverksenumerering.

Helt til slutt vil vi ta med ett avsnitt om logg-retention, det vil si hvor lenge logger lagres og er søkbare. Å lagre logger lenge krever mye lagringsplass. Som standard, lager LME en retention-policy ved installasjon basert på å bruke 80% av ledig disk-kapasitet. Det vil si at den starter å overskrive logger når 80% av kapasiteten er brukt, uavhengig av hvor mange dager som har gått. Guiden beskriver hvordan dette kan endres, og man kan sette X antall dager eller Y antall GB. Her har vi ikke gjennomført grundige tester, da ulike maskiner og brukere produserer veldig forskjellig mengde logger. Vi ønsker tilbakemelding fra de som tar i bruk LME på hvor mye logger som produseres i gjennomsnitt per maskin, for å gjør det enklere for ande å planlegge lagringen sin.

Event-forwarding over HTTPS

For å benytte HTTPS, gjør følgende endringer:

Før punkt 1.3.1:

  • Opprett ett sertifikat for WinRM på WEC
  • Dette kan være self-signed, så lenge klientene stoler på det og det har riktig FQDN
    • GPO kan brukes til å distribuere sertifikatet
  • Sertifikatet må legges til certstore på WEC

Punkt 1.3.1:

  • Når du endrer FQDN i klient-GPOen, endre også protokollen til HTTPS og porten til 5986

Punkt 1.3.2:

  • Før du kjører wecutil cs lme_wec_config.xml, endre verdien i feltet <TransportName> fra «HTTP» til «HTTPS»
  • Når du kjører kommandoen etter å ha endre filen kan den rapportere feil. Det er fordi det ikke eksisterer en HTTPS listener. Bruk kommandoen under for å opprette en, og så «wecutil rs lme» for å restarte event-forwardingen. (Sertifikatet er det du opprettet over).

winrm create winrm/config/Listener?Address=*+Transport=HTTPS '@{Hostname=”WEC_DNS_NAME”; CertificateThumbprint=”CERTIFICATE_THUMBPRINT”}'

Nyttige lenker:

Logging Made Easy (selve guiden): https://github.com/ukncsc/lme

Microsoft sin guide for oppsett av WEF: https://docs.microsoft.com/en-us/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection

Fikse feil tilganger på WinRM URLer: https://docs.microsoft.com/en-US/troubleshoot/windows-server/admin-development/events-not-forwarded-by-windows-server-collector

WEF push konfigurasjon (og feilsøking): https://docs.microsoft.com/en-us/windows/win32/wec/setting-up-a-source-initiated-subscription

Guide til WinRM med HTTPS: https://cloudblogs.microsoft.com/industry-blog/en-gb/technetuk/2016/02/11/configuring-winrm-over-https-to-enable-powershell-remoting/

Sysmon: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

ELK stacken: https://www.elastic.co/what-is/elk-stack