Overvåking er en integrert del av ethvert sikkerhetsopplegg av flere grunner. Blant dem er at målet om sikkerhet vanligvis ikke er begrenset til å garantere datakonfidensialitet, men det inkluderer også å sikre tjenestenes tilgjengelighet. Det er derfor viktig å sjekke at alt fungerer som forventet, og å i tide oppdage avvikende atferd eller endring i kvaliteten på tjenesten(e) som blir levert. Å overvåke aktivitet kan bidra til å oppdage inntrengningsforsøk, og muliggjøre en rask reaksjon før de forårsaker alvorlige konsekvenser. Denne delen vurderer noen verktøy som kan brukes til å overvåke flere aspekter av et Debian-systemet. Som sådan, fullfører den
Seksjon 12.4, «Overvåking».
14.3.1. Å overvåke logger med logcheck
Programmet logcheck overvåker loggfiler som standard hver time. Det sender uvanlige loggmeldinger i e-post til administratoren for videre analyse.
Listen over overvåkede filer lagres i /etc/logcheck/logcheck.logfiles; standardverdiene fungerer fint hvis /etc/rsyslog.conf-filen ikke har blitt fullstendig overhalt.
logcheck kan arbeide i en av tre mer eller mindre detaljerte modi: paranoid, tjener og arbeidsstasjon. Den første er veldig ordrik, og bør nok være begrenset til bestemte tjenere slike som brannmurer. Den andre (og standard) modus anbefales for de fleste tjenere. Den siste er beregnet for arbeidsstasjoner, og er mer finslipt (den filtrerer ut flere meldinger).
I alle tre tilfelle bør nok logcheck være tilpasset for å utelukke noen ekstra meldinger (avhengig av installerte tjenester), med mindre admin virkelig hver time ønsker å motta grupper av lange uinteressante e-poster. Siden utvalgsmekanismen for meldinger er ganske komplisert, er filen /usr/share/doc/logcheck-database/README.logcheck-database.gz anbfalt lesning, men utfordrende.
De anvendte reglene kan deles inn i flere typer:
de som kvalifiserer en melding som et inntrengningsforsøk (lagret i en fil i /etc/logcheck/cracking.d/-mappen);
de som de avbryter slik kvalifisering (/etc/logcheck/cracking.ignore.d/);
de som klassifiserer en melding som en sikkerhetsadvarsel (/etc/logcheck/violations.d/);
de som avbryter denne klassifisering (/etc/logcheck/violations.ignore.d/);
til slutt, de som andvendes til de gjenstående budskapene (ansett som systemhendelser).
En systemhendelse signaliseres alltid, med mindre en regel i en av /etc/logcheck/ignore.d.{paranoid,server,workstation}/-mappene fastslår at handlingen skal ignoreres. Det er selvfølgelig at de eneste mapper som tas i betraktning, er de som tilsvarer et detaljnivået likt eller større enn den valgte driftsmodus.
14.3.2. Overvåkningsaktivitet
top er et interaktivt verktøy som viser en liste over kjørende prosesser. Standard sortering er basert på gjeldende mengde prosessorbruk, og aktiveres med P-tasten. Andre sorteringsrekkefølger inkluderer minnebruk (M-tasten), samlet prosessortid (T-tasten), og etter prosess-id (N-tasten). k-tasten lar en å stoppe en prosess ved å oppgi prosess-id. Tasten r lar en endre nice-verdi renicing på en prosess, som betyr å endre dens prioritet.
Når systemet ser ut til å være overbelastet, er top et flott verktøy for å se hvilke prosesser som konkurrerer om prosessortid, eller bruker for mye minne. Spesielt er det ofte interessant å sjekke om de prosesser som bruker ressurser samsvarer med reelle tjenester som maskinen er kjent for å være vert for. En ukjent prosess som kjører som www-databruker skal virkelig være synlig og undersøkes, da den sannsynligvis er et tilfelle av at programvare er installert og kjørt på systemet via en sårbarhet i en nett-applikasjon.
top er et svært fleksibelt verktøy, og den tilhørende manual siden informerer om hvordan man tilpasser skjermen til personlige behov og vaner.
gnome-system-monitor-grafiske verktøy ligner top, og gir grovt sett de samme egenskapene.
Prosessorbelastning, nettverkstrafikk og ledig diskplass er informasjon som stadig varierer. Å beholde en historie med hvordan de endres er ofte nyttig for å bestemme nøyaktig hvordan datamaskinen brukes.
Det finnes mange øremerkede verktøy for denne oppgaven. De fleste kan hente data via SNMP (Simple Network Management Protocol) for å sentralisere denne informasjonen. En ekstra fordel er at dette gjør at henting av data fra nettverkselementer som kanskje ikke er datamaskiner med et generelt formål, som øremerkede nettverksrutere eller brytere.
Noe detaljert omhandler denne boken Munin (se
Seksjon 12.4.1, «Oppsett av Munin») som en del av
Kapittel 12: «Avansert administrasjon». Debian leverer også et lignende verktøy,
cacti. Utplasseringen er litt mer komplisert, siden det kun er basert på SNMP. Til tross for et nettgrensesnitt, kreves det litt innsats å få tak på begrepene som inngår i oppsettet. Å lese HTML-dokumentasjon (
/usr/share/doc/cacti/html/index.html) må betraktes som en forutsetning.
14.3.3. Å finne endringer
Når systemet er installert og satt opp, og sikkerhetsoppgraderinger oppdatert, er det vanligvis ingen grunn til å utvikle videre de fleste filer og kataloger, data unntatt. Det er derfor interessant å sørge for at filene faktisk ikke endres: Alle uventede endringer vil det derfor være verdt å undersøke. Denne delen presenterer noen verktøy som er i stand til å overvåke filer, og advare administratoren når en uventet endring skjer (eller rett og slett for å liste slike endringer).
14.3.3.1. Gjennomgå pakker med dpkg --verify
dpkg --verify (eller dpkg -V) er et interessant verktøy, siden det tillater å finne hvilke installerte filer som har blitt endret (potensielt av en angriper), men dette bør tas med en klype salt. For å gjøre jobben sin er den avhengig av sjekkesummer lagret i dpkgs egen database lagret på harddisken (de kan finnes i /var/lib/dpkg/info/pakke.md5sums); Derfor vil en grundig angriper oppdatere disse filene slik at de inneholder de nye kontrollsummene for nedbrutte filer.
Å kjøre dpkg -V vil bekrefte alle installerte pakker, og vil skrive ut en linje for hver fil med en sviktende test. Utgangsformatet er det samme som et fra rpm -V hvor hver figur betegner en test med noen spesifikke metadata. Dessverre dpkg lagrer ikke metadata som trengs for de fleste testene, og vil dermed gi spørsmålstegn for dem. Foreløpig kan bare sjekksumtesten levere en «5»-er på det tredje tegnet (når den feiler).
# dpkg -V
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster
I eksempelet ovenfor, rapporterer dpkg en endring i SSH-tjenestefil som administratoren har gjort i den pakkede filen i stedet for å bruke den hensiktsmessige /etc/systemd/system/ssh.service-overstyring (som ville bli lagret under /etc som alle oppsettsendringer skal). Den viser også flere oppsettsfiler (identifisert av «c»-bokstaven i det andre feltet) som er legitimt modifisert.
14.3.3.2. Overvåkingspakker: debsums og dens grenser
debsums er stamfaren til dpkg -V, og er dermed stort sett foreldet. Den lider av de samme begrensningene som dpkg. Heldigvis, noen av begrensningene kan man komme rundt (mens dpkg ikke tilbyr tilsvarende work-arounds (muligheten)).
Siden dataene på disken ikke er å stole på, debsums tilbyr å gjøre sine undersøkelser på grunnlag av .deb-filer i stedet for å stole på dpkgs database. For å laste ned pålitelige .deb-filer for alle installerte pakker, kan vi stole på APTs klarerte nedlastinger. Denne operasjonen kan være treg og omstendelig, og bør derfor ikke ansees som en proaktiv teknikk som skal brukes på jevnlig basis.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
Merk at dette eksemplet bruker grep-status-kommandoen fra dctrl-tools-pakken, som ikke er installert som standard.
14.3.3.3. Å overvåke filer: AIDE
AIDE-verktøyet (Advanced Intrusion Detection Environment) kan sjekke filens integritet, og oppdager alle endringer opp mot et tidligere innspilt bilde av systemet. Dette bildet er lagret som en database (/var/lib/aide/aide.db) som inneholder relevant informasjon om alle filene i systemet (fingeravtrykk, tillatelser, tidsstempler, og så videre). Denne databasen blir først initialisert med aideinit; og er så brukt daglig (med /etc/cron.daily/aide-skriptet) for å kontrollere om ingenting relevant er endret. Når det oppdages endringer, registrerer AIDE dem i loggfiler (/var/log/aide/*.log), og sender sine funn til administratoren med e-post.
Mange valg i /etc/default/aide kan bli brukt til å justere handlingene til aide-pakken. AIDE-oppsettet er lagret i /etc/aide/aide.conf og /etc/aide/aide.conf.d/ (disse filene er faktisk bare brukt av update-aide.conf for å generere /var/lib/aide/aide.conf.autogenerated). Oppsett indikerer hvilke egenskaper ved hvilke filer som må sjekkes. For eksempel kan innholdet i loggfiler endres rutinemessig, og slike endringer kan ignoreres så lenge rettighetene til disse filene forblir de samme, men både innhold og tillatelser for kjørbare programmer må være konstante. Selv om de ikke er veldig kompliserte, er ikke oppsettssyntaksen helt intuitiv, og lese aide.conf(5)-manualside er derfor anbefalt.
En ny versjon av databasen genereres hver dag i /var/lib/aide/aide.db.new; hvis alle registrerte endringer var legitime, kan den brukes til å erstatte referansedatabasen.
14.3.4. Å avdekke inntrenging (IDS/NIDS)
suricata (i Debian-pakken med samme navn) er et NIDS - et
Network Intrusion Detection System. Oppgaven er å lytte til nettverket, og prøve å oppdage infiltrasjonsforsøk og/ eller fiendtlige handlinger (inkludert tjenestenektangrep). Alle disse hendelsene blir logget i flere filer i
/var/log/suricata. Det er tredjepartsverktøy (Kibana/logstash) som bedre kan søke igjennom alle innsamlede data.
Å sette opp suricata innebærer å gjennomgå og redigere /etc/suricata/suricata-debian.yaml, som er veldig lang fordi hvert parameter er rikelig kommentert. Et minimalt oppsett krever beskrivelse av området med adresser som det lokale nettverket dekker (HOME_NET-parameter). I praksis betyr dette hele settet med mulige angrepsmål. Men å få det meste ut av den, krever å lese den i sin helhet, og tilpasse den til den lokale situasjonen.
På toppen av dette, må du også redigere /etc/default/suricata for å definere nettverksgrensesnittet som skal overvåke, og å aktivere init-skript (ved å sette RUN=yes). Du kan også ønske å sette LISTENMODE=pcap fordi standard LISTENMODE=nfqueue krever ytterligere oppsett for å fungere riktig (nettfilter brannmuren må settes opp til å videresende pakker til en brukerområde-kø som håndteres av suricata via NFQUEUE-målet).
For å oppdage feilaktig oppførsel trenger suricata et sett med overvåkingsregler: Du kan finne slike regler i snort-rules-default-pakken. snort er den historiske referansen i IDS-økosystemet ,og suricata kan gjenbruke regler skrevet for den. Dessverre mangler denne pakken i Debian Jessie, og bør hentes fra en annen Debian-utgivelse som Testing eller Unstable.
Alternativt kan, oinkmaster (i pakken med samme navn) brukes til å laste ned Snort regelsett fra eksterne kilder.
