14.3. Tilsyn: Forebygging, avdekking, avskrekking
Monitorering 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. Å følge med på det som skjer 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 å følge med på flere aspekter av et Debian-system. Som sådan, fullfører den
Seksjon 12.4, «Monitorering».
14.3.1. Monitorering av logger med logcheck
Programmet logcheck sjekker i utgangspunktet loggfiler hver time. Det sender uvanlige loggmeldinger i e-post til administratoren for videre analyse.
Listen over filer som sjekkes er lagret i /etc/logcheck/logcheck.logfiles; standardverdiene fungerer fint hvis /etc/rsyslog.conf-filen ikke har blitt fullstendig skrevet om.
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 tilfellene 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 anbefalt 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 klassifiseringen (/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. Aktivitetsmonitorering
top er et interaktivt verktøy som viser en liste over kjørende prosesser. Forvalgt 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 tillater stopping av en prosess ved å oppgi prosess-ID. Tasten r lar en endre nice-verdi (på engelsk også kalt 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 prosessene som bruker ressurser, samsvarer med reelle tjenester som maskinen faktisk tjener som vertskap for. En ukjent prosess som kjører som brukeren www-data, skal virkelig skille seg ut og undersøkes, da den sannsynligvis er et tilfelle av at programvare er installert og kjørt på systemet via en sårbarhet i et nett-program.
top er et svært fleksibelt verktøy, og den tilhørende manualsiden 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 tillater 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 (sjekk
Seksjon 12.4.1, «Oppsett av Munin») som er en del av
Kapittel 12: «Avansert administrasjon». Debian leverer også et lignende verktøy,
cacti. Å ta det i bruk er litt mer komplisert, siden det kun er basert på SNMP. Til tross for at det forefinnes et nettgrensesnitt, kreves det litt innsats å få tak på begrepene som inngår i oppsettet. Å lese HTML-dokumentasjon (
/usr/share/doc/cacti/html/Table-of-Contents.html) må betraktes som en forutsetning.
14.3.3. Unngå inntrenging
Angripere prøver å få tilgang til tjenere ved å gjette passord, og derfor må sterke passord alltid brukes. Selv da bør du også etablere tiltak mot rå makt-angrep. Et rå makt-angrep er et forsøk på å logge inn på et uautorisert programvaresystem ved å utføre atskillige påloggingsforsøk på kort tid.
Den beste måten å stoppe et råmaktsangrep på er å begrense antallet innloggingsforsøk som kommer fra samme kilde, vanligvis ved å midlertidig forby en IP-adresse.
Fail2Ban er en programvarepakke for å hindre innbrudd, som kan settes opp til å monitorere alle tjenester som skriver innloggingsforsøk til en loggfil. Den finnes i pakken fail2ban.
Fail2Ban settes opp ved hjelp av en enkel protokoll og fail2ban-client, som også leser oppsettfiler og sender inn aktuelle oppsettinstrukser til tjeneren, fail2ban-server. Den har fire oppsettfiltyper, alle lagret i /etc/fail2ban/:
fail2ban.conf. Globalt oppsett (for eksempel logging).
filter.d/*.conf. Filtre som angir hvordan du oppdager autentiseringsfeil. Debian-pakken inneholder allerede filtre for mange vanlige programmer.
action.d/*.conf. Handlinger som definerer kommandoene for stenging og gjenåpning av IP-adresser.
jail.conf. Her defineres fengsel, kombinasjonene av filtre og handlinger.
La oss se på oppsettet av sshd i /etc/fail2ban/jail.conf for å bedre forstå hvordan Fail2Ban fungerer ...
[...]
[DEFAULT]
[...]
bantime = 10m
[...]
findtime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban vil se etter mislykkede innloggingsforsøk for sshd ved hjelp av Pythons regulære uttrykk definert i /etc/fail2ban/filter.d/sshd.conf, opp mot loggfilen til sshd, som er definert i variabelen sshd_log i filen /etc/fail2ban/paths-common.conf. Hvis Fail2Ban oppdager fem mislykkede påloggingsforsøk i løpet av ti minutter så vil IP-adressen der disse forsøkene kom fra bli utestengt i ti minutter.
For å skru på, av, eller sette opp «jails» (fengsel) er det meningen at hovedoppsettsfilen, /etc/fail2ban/jail.conf ikke skal være endret. Istedenfor bør dette gjøres i /etc/fail2ban/jail.d/defaults-debian.conf eller i filer som er å finne i samme mappe.
Fail2Ban er en veldig enkel og effektiv måte å beskytte seg mot de vanligste rå makt-angrep på, men det kan ikke beskytte mot distribuerte rå makt-angrep, som er når en angriper bruker et stort antall maskiner spredt rundt på Internett.
En god måte å gi ekstra beskyttelse mot distribuerte rå makt-angrep på, er å kunstig øke påloggingstiden etter hvert mislykket forsøk.
14.3.4. Å 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, bortsett fra for data. 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 å følge med på filer, og advare administratoren når en uventet endring skjer (eller rett og slett for å liste slike endringer).
14.3.4.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 sjekksummene for filer som er byttet ut.
Å 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 fra rpm -V hvor hvert tegn betegner en test med noen spesifikke metadata. Dessverre lagrer ikke dpkg metadataen som trengs for de fleste testene, og vil dermed vise frem 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.d/override.conf-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 endret legitimt.
14.3.4.2. Kontroll av pakker: debsums og dens begrensninger
debsums er stamfaren til dpkg -V, og er dermed stort sett foreldet. Den lider av de samme begrensningene som dpkg. Heldigvis kan man komme seg rundt noen av begrensningene (mens dpkg ikke tilbyr tilsvarende mulige omgåelser).
Siden dataene på disken ikke er å stole på, tilbyr debsums å gjøre sine undersøkelser på grunnlag av .deb-filer i stedet for å stole på dpkgs database. Vi kan basere oss på APTs autentiserte nedlastinger for å laste ned pålitelige .deb-filer for alle installerte pakker. 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.
debsums kan ofte kjøres som en cronjob-innstilling CRON_CHECK i /etc/default/debsums. For å ignorere visse filer utenfor /etc-katalogen, som har blitt endret med hensikt eller som forventes å endres (som /usr/share/misc/pci.ids), kan du legge dem til i /etc/debsums-ignore.
14.3.4.3. Filmonitorering: 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)-manualsiden 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.5. Å 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.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 den for å definere nettverksgrensesnittet (interface). Du kan også ønske å sette LISTENMODE=pcap fordi forvalgt LISTENMODE=nfqueue krever ytterligere oppsett for å fungere riktig (nettfilterbrannmuren må settes opp til å videresende pakker til en brukerroms-kø som håndteres av suricata via NFQUEUE-målverdien).
For å oppdage feilaktig oppførsel trenger suricata et sett med monitoreringsregler: 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.
Alternativt kan oinkmaster (i pakken med samme navn) brukes til å laste ned Snort-regelsett fra eksterne kilder.
