Fatter du din netværkstrafik? Centraliser dine logs og tag skrammerne alvorligt

Centraliser logs og få et overblik over normaltrafikken, lyder nogle af ekspertanbefalingerne til at undgå ulykker på netværket.

Hvis du bemærker et pudsigt glitch i netværkstrafikken i dine logfiler, så lad være med at tænk noget i retning af: Nå, det var nok ikke noget.

Det mener leder af televirksomheden Verizons risk-team Lorenz Kuhlee. Han sammenligner uregelmæssigheder i netværkstrafikken med fysiske skader på døren til et hus.

»Tag skrammer alvorligt. Når nogen prøver at bryde din dør ned, kan det være, du ser nogle skrammer. Når dette er dit eget hus, så tænker du, nogen har forsøgt, og du holder hver dag øje med flere skrammer,« siger Kuhlee.

Og det samme bør ske i den digitale verden, påpeger han. Det vil sige, at hvis noget ser mærkeligt ud i netværkstrafikken, så bør den netværksansvarlige finde ud af, hvad det skyldes. Måske er det tegn på hackere, der prøver at finde en vej ind.

I forhold til at spotte eventuelle skrammer, så skal der styr på logs i organisationen. Og logfilerne skal ligge centraliserede.

På den måde undgår den netværksansvarlige bøvlet med at skulle hive logfiler ud af enkelte maskiner, forklarer Kuhlee. Og så er der også et sikkerhedsaspekt ved at køre med centraliserede logfiler.

»Når først en maskine er kompromitteret, så kan en angriber ændre eller slette logfiler. Men når det er centraliseret, så bliver det langt sværere at ændre filerne,« siger han.

Når der er styr på logfilerne er det også muligt at danne sig et overblik over, hvad der er normal trafik, så det er muligt at spotte den unormale netværksaktivitet, der kan indikere et angreb.

»Måske er det ok, at en ip taler med en filserver fra klokken otte om morgenen til klokken fire om eftermiddagen. Men hvis ip'en taler med filserveren omkring midnat, hvor ingen arbejder ... det kan være et automatiseret script, men når man detekterer dette, bør man følge op og finde ud af, hvorfor maskinen talte med filserveren ved midnat. Man bliver nødt til at forstå sit netværk, for at vide, hvad der er unormalt,« siger han.

Pas på ikke at log for meget

Manager i ERS Cyber Operations ved Digicure Deloitte, Henrik Falkenthros, er helt enig med Lorenz Kuhlee i, at centraliserede logs, er en vigtig forudsætning for at få overblikket på netværket, så det også er muligt at identificere eventuelle trusler.

Kunsten er imidlertid at finde ud af, hvor meget der skal logges.

»Udfordringen er at finde det rette logningsniveau. Man kan sætte det så højt, at enhederne og netværket dør. Det er svært at sætte niveauet rigtigt,« siger Henrik Falkenthros.

En ting er at finde det rette logningsniveau, noget andet er at logge de rigtige steder i netværket.

»Selvom 99 procent af hackerne forsøger hoveddøren, så vil den smarte hacker bruge en obskur vej ind i netværket, hvor man ikke har tænkt logning overhovedet.«

Og her er det kunsten at finde ud af, hvad der er værd at logge på, og hvad der ikke er, påpeger han.

»Nogen skal kigge på de rå komponenter og finde ud af, hvad de vil tillade, og hvad de ikke vil tillade.«

Henrik Falkenthros anbefaler ligesom Kuhlee at identificere normaltrafikken i organisationen.

Falkenthros fortæller, at det eksempelvis kan ske ved at tage afsæt i logs fra eksempelvis en periode på en måned. Og på den måde lægge en grundniveau for, hvordan eksempelvis trafikken til og fra en filserver bør se ud.

Dette grundniveau kan kombineres med det generelle netværksovervågningssystem, så der automatisk bliver udløst en alarm, hvis eksempelvis trafikmængden adskiller sig væsentligt fra normalen eller finder sted i et unormalt tidsrum.

Udover at holde øje med mængden af trafik, anbefaler Henrik Falkenthros at have forskellige logningsniveauer på forskellige typer data

»Hvis det er noget personhenførbart, kan man godt have et øget logningsniveau og lavere alarm-grænser i forhold til, hvis det er noget knapt så ømtåleligt,« siger han.

Henrik Falkenthros anbefaler at supplere netværks-logs med logs fra IDS (intrusion detection system), der kan sættes op til at udløse en realtidsalarm og samtidigt tilføje en record i den samlede log, hvis noget er på færde.

Hverken Henrik Falkenthros eller Lorenz Kuhle ønsker at anbefale specifikke produkter til håndtering og analysering af logfiler og netværkstrafik. Det står naturligvis Version2's læsre frit for at komme med bud på den slags værktøjer.

Center for Cybersikkerhed har udgivet en vejledning med anbefalinger til omgang med log-filer i forhold til at opdage og analysere cyberangreb. Vejledningen, som kan hentes her (PDF), kommer blandt andet ind på centralisering og arkivering af log-filer.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Morten Olsson

Fin artikel. Jeg savner dog tre punkter:

1) Logningsværktøjet må aldrig blive en sovepude. Det er vigtigt at holde sig for øje, at selv det bedst opsatte logningsværktøj ikke er bedre end de logs det får. Blot fordi man ikke får en alarm på noget, betyder det ikke nødvendigvis at man ikke har et problem.
2) Der bør opsamles logs fra firewalls. Det er ikke helt nok at nøjes med IDS/IPS i den forbindelse. Virksomhedens firewalls er centrale i den forstand at en velgennemtænkt logopsamling fra disse vil kunne give et mere komplet billede.
3) Glem ikke logs fra det trådløse netværk. Sandsynligheden for at det trådløse netværk er vektoren i et angreb stiger i disse år. Flere og flere enheder bliver trådløse, og mange virksomheder halter med sikkerheden i den trådløse infrastruktur.

Henrik Falkenthros

Enig i at FW logs kan være nyttige og skal være en del af log billedet. På flere FW er det muligt at sætte logningsniveauet 'passende' så man ikke dræner dens ressourcer fuldstændigt. Ydermere kan man ofte til- og fravælge hvilke regler man ønsker at foretage logning på.

Klavs Klavsen

For hvis man sikrer sig at ens interne servere KUN må tilgå det de SKAL og følger den basale sikkerhedsregel om at en server der kan nås af alle fra internettet - IKKE må kunne tilgå alt på internettet - så vil firewall'ens logs af afviste pakker, med høj sandsynlighed give en information hvis ens servere er blevet hacket (fordi de vil forsøge at connecte til noget på internettet som oftest).

ie. Følg "principal of least privilege" - og sørg for at i holder øje med afviste loggen - den bør være tom (for al andet end trafik FRA internettet - men den del skal håndteres seperat)

Jens Jönsson
Klavs Klavsen

Jeg satte for ca. ~17 år siden et netværk op, hvor jeg bare havde en linux som firewall - og alt desktop'ene skulle kunne tilgå lå på andre fælles netværk. På firewall'en havde jeg så sat en dæmon op der spærrede for ip'er der portscannede firewall'en.

Det fangede altid når nogen fik en virus (da den jo forsøger at sprede sig :) - forbløffende nemt. Og hvis man så sørger for at sætte sine switche op så de enkelte porte ikke får lov at snakke sammen (så de kun kan snakke med ting på andre netværk, igennem fw. - std. config på de ordentlige switche) - så vil der automatisk blive lukket ned for maskiner der er inficeret, så snart de prøver at tilgå sprede sig.

Det fanger ikke nødvendigvis de moderne "crypto" angreb - der skal man over i at have lidt mere styr på desktop'ens opførsel og unormal opførsel for at kunne lukke den ned (men det kan lidt automatiseret loganalyse - f.ex. limits på antal fil-writes på shares per 5 min. - og automatisk luk af netværk for den desktop). Faktisk ikke så svært at lave.

Log ind eller Opret konto for at kommentere