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
Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log into an unauthorized software system by performing multiple login attempts in a short period of time.
The best way to stop a brute-force attack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.
Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attempts to a log file. It can be found in the package fail2ban.
Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /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. Actions defining the commands for banning and “unbanning“ of IP addresses.
jail.conf. Her defineres jails, 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 will check for failed login attempts for sshd using Python regular expressions defined in /etc/fail2ban/filter.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths-common.conf. If Fail2Ban detects five failed login attempts within 10 minutes, it will ban the IP address where those attempts originated for 10 minutes.
For å aktivere, skru av, eller sette opp «jails» (~fengsel/innhegninger) 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 brute-force-angrep på, men det kan ikke beskytte mot distribuerte brute-force-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 brute-force-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
In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate /etc/systemd/system/ssh.service.d/override.conf override (which would be stored below /etc like any configuration change should be). It also lists multiple configuration files (identified by the "c" letter on the second field) that had been legitimately modified.
14.3.4.2. Kontroll av pakker: debsums og dens begrensninger
debsums is the ancestor of dpkg -V and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar workarounds).
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 can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpose or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /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 (in the Debian package of the same name) is an NIDS — a
Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in
/var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.
Configuring suricata involves reviewing and editing /etc/suricata/suricata.yaml, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (HOME_NET parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation.
On top of this, you should also edit it to define the network interface. You might also want to set LISTENMODE=pcap because the default LISTENMODE=nfqueue requires further configuration to work properly (the netfilter firewall must be configured to pass packets to some user-space queue handled by suricata via the NFQUEUE target).
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.
Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rule sets from external sources.
