Metoder og verktøy i operativt sikkerhetsarbeid IRT-kurs UNINETT CERT
Tradisjonelt trusselbilde
Moderne trusselbilde
Eksempel fra USA 12 May 2017 SLIDE 4
Mandiant M-trends rapport l l I snitt tar det 99 dager før en organisasjon oppdager at den er kompromittert (2016) l 146 dager i 2015 l 205 dager i 2014 l 416 dager i 2012 Mandiant s Red Team: l admin-rettigheter i snitt oppnådd innen 3 dager etter at de først har klart å kompromittere et nettverk
Mulige datakilder IP-adresseoversikt Netflow DNS-logg Mail-log authlog http.log Syslog Suricata Trusseldata Sårbarhetsdata Passiv DNS Zabbix NAV Xymon Informasjon fra AD 12 May 2017 SLIDE 6
Tradisjonell graving i logger Kommandolinje grep awk nfdump Støtteverktøy Gnuplot Excel SQL Web-grensesnitt Nfsen Zabbix Xymon NAV Kibana Fremdeles nyttig, men blir logger analysert og brukt effektivt? 12 May 2017 SLIDE 7
Hvorfor berikelse? Alarm fra Sikkerhetsanalyse alert ET trojan malware information leak 192.168.10.4:43666 -> 88.88.88.88:80 http.hostname: veryinnocentsite.com Payload_printable: fjasfjasfjasfjasfjasfjasfjas; file:random_file.doc; fjasfjasfjasfjasfjas Ikke spesielt enkelt å si om dette er en reell hendelse eller om det er en falsk positiv! 12 May 2017 SLIDE 8
Hvorfor berikelse? Intern IP-adresse: - Alarm Sett fra i tidligere Sikkerhetsanalyse saker? - Hvilket nett? (student/ansatt/server) http.hostname: veryinnocentsite.com - Fillagringsserver? - Økonomidirektør? - Verdensledende forsker? - Student? -?? -?? alert ET trojan malware information leak 192.168.10.4:43666 -> 88.88.88.88:80 Payload_printable: fjasfjasfjasfjasfjasfjasfjas; file:random_file.doc; fjasfjasfjasfjasfjas Ikke spesielt enkelt å si om dette er en reell hendelse eller om det er en falsk positiv! 12 May 2017 SLIDE 9
Hvorfor berikelse? Ekstern IP-adresse: -Alarm Sett frai Sikkerhetsanalyse tidligere saker? - Sett av andre UH-inst? - Sett i kjente http.hostname: veryinnocentsite.com rapporter/trusselanalyser? - Hvilke domener har pekt til denne adressen? (passiv dns) -?? alert ET trojan malware information leak 192.168.10.4:43666 -> 88.88.88.88:80 Payload_printable: fjasfjasfjasfjasfjasfjasfjas; file:random_file.doc; fjasfjasfjasfjasfjas Ikke spesielt enkelt å si om dette er en reell hendelse eller om det er en falsk positiv! 12 May 2017 SLIDE 10
Hvorfor berikelse? Domene: Alarm fra Sikkerhetsanalyse - Sett i tidligere alert ET trojan malware information leak saker? 192.168.10.4:43666 -> 88.88.88.88:80 - Sett av andre UHinst? - Sett i kjente fjasfjasfjasfjasfjas rapporter/trusselan Ikke spesielt enkelt å si om dette er en alyser? reell hendelse eller om det er en falsk positiv! - Fast-flux domene? - Passiv DNS -?? http.hostname: veryinnocentsite.com Payload_printable: fjasfjasfjasfjasfjasfjasfjas; file:random_file.doc; 12 May 2017 SLIDE 11
Hvorfor berikelse? Alarm fra Sikkerhetsanalyse alert ET trojan malware information leak 192.168.10.4:43666 -> 88.88.88.88:80 http.hostname: veryinnocentsite.com Payload_printable: fjasfjasfjasfjasfjasfjasfjas; file:random_file.doc; fjasfjasfjasfjasfjas Innhold i pakker: - Hva om det hadde stått password_file.txt? -?? Ikke spesielt enkelt å si om dette er en reell hendelse eller om det er en falsk positiv! 12 May 2017 SLIDE 12
Hvorfor berikelse? Beriket alarm fra Sikkerhetsanalyse alert ET trojan malware information leak <IP-adresse til Roger rakettforsker> -> <IP-adresse knyttet til Nord-koreansk etterretning, og har også resolvet til domenet notsoveryinnocentsite.com> http.hostname: veryinnocentsite.com (fast-flux, pekt på 30 ulike IPadresser den siste uka.) Payload_printable: fjasfjasfjasfjasfjasfjasfjas; file:ultra-innovative-fancyrocketengine.doc; fjasfjasfjasfjasfjas Litt enklere å ta en beslutning på hva som bør gjøres! 12 May 2017 SLIDE 13
SIEM (Security Information and Event Management) Vi ser et stort behov for et såkalt SIEM Relevante data/logger er tilgjengelig fra en plass Korrelering av data Setter oss i stand til å ta raskere og bedre beslutninger Kan vi samarbeide om dette? (Felles berikelse?) Dette er i utgangspunktet veldig komplekse system, og det er slettes ikke sikkert at det er mulig å få til et samarbeid? (vil uansett kreve veldig klare definerte API) 12 May 2017 SLIDE 14
Netflow innsamling og utnyttelse Kritisk avhengig av netflow i analysearbeid Samplet data fra kjernenett (1 av 100 eller 1 av 1000) Full netflow på verktøykasser Nfsen/Nfdump fungerer stort sett som det skal abandonware? Enkle script fanger opp en del scannere, spammere og DDoS Kunne gjort mye mer med analyse og utnyttelse Vi har fått satt opp SiLK, og går snart over til det. 12 May 2017 SLIDE 15
Sårbarhetsscanning Vi har altfor mange åpne sårbare tjenester i sektoren. Vi må lukke de! Finne sårbarheter før de blir utnyttet. Aktiv scanning fra: sentral server prober internt på campus Felles tjeneste for sektoren? (Vi kan fronte tjenesten og gjøre innkjøp på vegne av sektoren!) 12 May 2017 SLIDE 16
Sårbarhetsscanning - utfordringer Mange tester skjer på versjonsnummer Mange sikkerhetsoppdateringer skjer med backporting Resultat: mange falske positive Scan på en høgskole: Første rapport var på 1300 sider! 2130 sårbarheter Automatisk fjerning av sårbarheter som er fikset i Debian security feed 70-80% blir fjernet Mange sårbarheter blir ikke fikset! F.eks. https://security-tracker.debian.org/tracker/cve-2011-4718 12 May 2017 SLIDE 17
DDoS mitigering Vi har etablert en enkel statisk filtrering og ratebegrensing som basisvern på utenlandslinker en løsning for å stoppe de mest vanlige volumetriske og refleksive angrep fungerer bra NORDUnet på lag med oss, aktiv i å begrense effekt av angrep. Normalstørrelse DDoS-angrep fyller ikke utenlandslinker lenger (10G->100G) Kan bistå med ratebegrensning eller blackholing mot spesifikke mål for volumangrep UNINETT dagpersonell og beredskapsvakt håndterer hendelser 18
Sinkholing Fikk på plass løsning nå i januar 2017 Logger alt av web-oppkoblinger Brukt under årets torrentlocker kampanjer (posten/telenor-phish) Ga oss innsikt i hvem (IP-adresser) som trykte på phishing-lenker Rapporterte dette til de aktuelle kundene Gir dere mulighet til brukeropplæring for konkrete brukere Sinkholing/nullruting er en metode vi kun bruker i større hendelser for å beskytte hele sektoren Kan brukes til å finne allerede kompromitterte maskiner Pga. skalering vil denne ikke bli brukt i enkelt-saker for enkelt-kunder! En utfordring dersom fast-flux er brukt. Da må vi hele tiden endre hvilke IP-adresser vi sinkholer. 12 May 2017 SLIDE 19
Sentral mail filtrering NSM helhetlig IKT-risikobilde 2016: NSM registrerer fortsatt at den vanligste angreps-metoden i vellykkede, målrettede angrep er epost til brukere i virksomheten som rammes. Disse brukerne fungerer videre som brohoder til annen infrastruktur. I kraft av å være sektorcert mottar vi ganske ofte informasjon om forskjellige type angrep gjort per epost Målrettede angrep fra spesifikke avsendere Phishing fra spesifikke avsendere CEO-fraud fra spesifikke avsendere Cryptolocker fra spesifikke avsendere Idag får vi ikke nyttiggjort oss denne informasjonen 12 May 2017 SLIDE 20
Sentral mail filtrering (forts.) Hva om vi hadde en sentral koordinert måte å få sperra ned denne epost-flyten? Nye angrep/adresser kan varsles inn sentralt og forløpende analyseres og sperres slik at andre i sektoren blir skjermet i tillegg til reputation feed UiO og UNINETT starter nå å ser på et samarbeid om en sentral MX tjeneste for sektoren. Bare initielle samtaler foreløpig, men det ligger an til at UNINETT gjør det merkantile, og UiO driver tjenesten. UiO CERT og UNINETT CERT samarbeider om sperringer. 12 May 2017 SLIDE 21
DNS RPZ Stort sett alle oppkoblinger på internett starter med et DNS-oppslag Hva om vi kunne stoppe oppslag til domener brukt til slemvare via DNS? 12 May 2017 SLIDE 22
12 May 2017 SLIDE 23
12 May 2017 SLIDE 24
DNS query log Analysearbeid stopper opp fordi vi ikke kan finne ut hvilken klient som har slått opp hvilket domene Ser dette veldig ofte fra tjenesten Sikkerhetsanalyse hvor rekursive navnetjenere har slått opp domener vi vet er forbundet med slemvare. Men vi vet ikke hvilken klient som har spurt Vi selv kjører DNS query log på våre rekursive navnetjenere Vi oppfordrer flere kunder til å gjøre dette Men. Utfordring: Potensielt juridiske utfordringer? Potensielt sensitive data! Utfordring: Tilgang til dataene må begrenses og kontrolleres godt Interessant med en UNINETT fagspesifikasjon (UFS) for DNS query log? 12 May 2017 SLIDE 25
Passiv DNS data Logging av DNS-svar som rekursive navnetjenere får fra andre DNS-servere Altså en historisk oversikt/logg over hvilke IP-adresser oppslåtte domener peker til Logger ikke hvilken klient som spurte Passiv DNS data er ofte veldig nyttig i analysearbeid. (Berikelse av data) Eksempler https://threatcrowd.org/ https://passivedns.mnemonic.no/ 12 May 2017 SLIDE 26
Logganalyse https://www.uninett.no/tjenester/logganalyse 12 May 2017 SLIDE 27
Sikkerhetsanalyse https://www.uninett.no/sikkerhetsanalyse 12 May 2017 SLIDE 28
Kontaktinfo cert-info@uninett.no http://cert.uninett.no Arne Øslebø, arne.oslebo@uninett.no Rune Sydskjør, rune.sydskjor@uninett.no UNINETT CERT 12 May 2017 SLIDE 29