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.
The list of monitored files is stored in /etc/logcheck/logcheck.logfiles and /etc/logcheck/logcheck.logfiles.d/; the default values work fine with systemd and rsyslog if their configuration files have not been completely overhauled.
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.
The gnome-system-monitor graphical tool is similar to top and it provides roughly the same features. Alternatives are atop and htop, which provide similar functionality, but differ in usability features, like the scrolling ability.
Processor load, memory usage, network traffic and free disk space are information that are constantly varying. Keeping a history of their evolution is often useful in determining exactly how the computer is used.
There are many dedicated tools for this task. The sysstat package, for example, collects and displays system performance statistics locally. The data can then be visualized with the sar command. Most tools, though, can fetch data via SNMP (Simple Network Management Protocol) in order to centralize this information. An added benefit is that this allows fetching data from network elements that may not be general-purpose computers, such as dedicated network routers or switches.
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 is an intrusion prevention software suite that can be configured to monitor any service that writes login attempts to a log file or the system journal. It can be found in the package 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 and fail2ban.d/*.conf. Global configuration (such as 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 and jail.d/*.conf. It is where jails, the combinations of filters and actions, are defined.
La oss se på oppsettet av sshd i /etc/fail2ban/jail.conf for å bedre forstå hvordan Fail2Ban fungerer ...
[...]
[DEFAULT]
[...]
bantime = 1h
[...]
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 1 hour.
The default backend used now is systemd. The old log files, like auth.log are only available if rsyslog has been installed and enabled.
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.
If docker containers are involved, the rules injected into iptables by fail2ban to block traffic from specific IPs must be applied to the right chain by chain = DOCKER-USER. Otherwise, the ban will not work.
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.
A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt. It is also possible to increase the block time with each ban for the same IP.
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 (or dpkg -V) is an interesting tool since it allows finding what installed files have been modified (potentially by an attacker), but this should be taken with a grain of salt. To do its job it relies on checksums stored in dpkg's own database which is stored on the hard disk (they can be found in /var/lib/dpkg/info/package.md5sums); a thorough attacker will therefore update these files so they contain the new checksums for the subverted files. The same is true for debsums.
Å 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?????? c /etc/logcheck/logcheck.logfiles.d/syslog.logfiles
??5?????? c /etc/logrotate.d/apt
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/systemd/journald.conf
??5?????? c /etc/lvm/lvm.conf
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 (in the Debian package of the same name) is a 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. The tool can be considered the successor of
snort, which has been removed from Debian.
Å 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.
On top of this, you should also edit to define the network interface. You might also want to set LISTENMODE=pcap in /etc/default/suricata 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.
Alternativt kan oinkmaster (i pakken med samme navn) brukes til å laste ned Snort-regelsett fra eksterne kilder.
Unfortunately, the mentioned packages are not part of the current Debian
Bookworm release. But they can still be retrieved via the Debian package search or from the Debian snapshot archive.
