Product SiteDocumentation Site

14.3. Overvåking: Forebygging, avdekking, avskrekking

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

14.3.2.1. I sanntid

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.
When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.
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.

14.3.2.2. Historie

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.
This book deals with Munin in some detail (see Seksjon 12.4.1, «Oppsett av Munin») as part of Kapittel 12: «Avansert administrasjon». Debian also provides a similar tool, cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (/usr/share/doc/cacti/html/Table-of-Contents.html) should be considered a prerequisite.

14.3.3. Avoiding Intrusion

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 in to an unauthorised software system by performing multiple login attempts in a short period of time.
The best way to stop a brute-force atack 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 attemps 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. Global configuration (such as logging).
  • filter.d/*.conf. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.
  • action.d/*.conf. Actions defining the commands for banning and unbanning of IP addresses.
  • jail.conf. It is where jails, the combinations of filters and actions, are defined.
Let us have a look at the configuration of sshd in /etc/fail2ban/jail.conf to better understand how Fail2Ban works...
[...]
[DEFAULT]
[...]
bantime  = 10m
[...]
maxretry = 5
[...]
[sshd]
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban will check for failed login attepts for sshd using Python regular expressions defined in /etc/fail2ban/filters.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 in a row, it will ban the IP address where those attempts originated.
Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.
A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.

14.3.4. Å finne endringer

Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).

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 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.4.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.
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 purpuse or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /etc/debsums-ignore.

14.3.4.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.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.
Å 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).
To detect bad behavior, suricata needs a set of monitoring rules: you can find such rules in the snort-rules-default package. snort is the historical reference in the IDS ecosystem and suricata is able to reuse rules written for it.
Alternativt kan, oinkmaster (i pakken med samme navn) brukes til å laste ned Snort regelsett fra eksterne kilder.