LSS - Lecture VIIIa - Linux logging.pdf

# Authenticatie- en sessielogbestanden Dit gedeelte behandelt de verschillende logbestanden die worden gebruikt voor het bijhouden van authenticatieactiviteiten van gebruikers, inclusief inlogpogingen, succesvolle en mislukte sessies, en de commando's om deze logboeken te benaderen [2](#page=2). ### 1.1 Authenticatie logbestanden Authenticatielogbestanden registreren de inlogactiviteiten van gebruikers. De locatie en het beheer van deze logboeken kunnen per distributie verschillen [3](#page=3). #### 1.1.1 Locaties van authenticatielogbestanden * **Debian & afgeleiden:** * `/var/log/auth.log`: Dit bestand werd gebruikt in oudere versies van Debian. Sinds Debian 12 wordt dit vervangen door `systemd-journald`. Het kan echter nog steeds aanwezig zijn als `rsyslog` is geïnstalleerd [3](#page=3). * **RHEL & afgeleiden:** * `/var/log/secure`: Dit bestand bevat authenticatiegerelateerde gebeurtenissen [3](#page=3). #### 1.1.2 Gebruiksscenario's voor authenticatielogboeken ##### 1.1.2.1 Logs van `sudo` authenticatie De `sudo` opdracht maakt gebruik van het `pam_unix` module in de authenticatiestack van zijn PAM configuratiebestand [14](#page=14). * **Verkeerd sudo wachtwoord:** Dit wordt gelogd en kan worden teruggevonden in de betreffende logbestanden [14](#page=14). * **Correct sudo wachtwoord:** Succesvolle authenticatie via `sudo` wordt ook geregistreerd [14](#page=14). * **Niet in `sudoers` bestand of `sudo`/`wheel` groep:** Wanneer een gebruiker probeert `sudo` te gebruiken zonder de juiste permissies, wordt dit gelogd met de melding "This incident will be reported". Deze gebeurtenissen worden geregistreerd in `systemd-journald` en/of `/var/log/secure` [16](#page=16). ##### 1.1.2.2 Logs van `su` authenticatie Het gebruik van de `su` opdracht om supergebruiker te worden, wordt vergelijkbaar met `sudo` gelogd. De `pam_unix` module wordt gebruikt in de sessiestack voor `su` [17](#page=17). * **Correct `su` gebruik:** Succesvolle overgang naar de root-sessie wordt gelogd. In tegenstelling tot `sudo`, wordt er nog geen "session closed" melding geregistreerd omdat de sessie als root actief blijft [17](#page=17). ##### 1.1.2.3 Logs van `ssh` authenticatie SSH-authenticatiepogingen, zowel mislukt als succesvol, worden geregistreerd [18](#page=18) [19](#page=19). * **Verkeerd SSH wachtwoord:** Mislukte SSH-inlogpogingen worden gelogd en bevatten vaak informatie over de externe host (IP-adres). De `pam_unix` module in de authenticatiestack voor `sshd` is hierbij betrokken [18](#page=18). * **Succesvolle SSH login/logout:** Succesvolle SSH-logins en -logouts worden ook gelogd, inclusief tijdstempels die sessietracering mogelijk maken. Tools zoals `last` en `lastb` kunnen worden gebruikt om deze informatie te analyseren [19](#page=19). ### 1.2 Login/sessielogbestanden Naast authenticatiegerelateerde gebeurtenissen, registreren login- en sessielogbestanden informatie over de aanmeldingen en sessies van gebruikers op het systeem [20](#page=20). #### 1.2.1 `/var/log/lastlog` * Dit logbestand bevat de meest recente inloggegevens van gebruikers [21](#page=21). * Het is standaard ingeschakeld op de meeste distributies [21](#page=21). * Het logboek is opgeslagen in een binair formaat [21](#page=21). * Om dit logboek te lezen, kunnen de commando's `lastlog` of `lslogins` worden gebruikt [21](#page=21). * **Opmerking:** De standaarduitvoer toont alleen gebruikers die in `/etc/passwd` staan. Verwijderde gebruikers en niet-lokale gebruikers (bijvoorbeeld via SSSD) worden niet standaard weergegeven, maar kunnen wel specifiek worden opgevraagd [21](#page=21). #### 1.2.2 `/var/log/btmp` * Dit logbestand houdt de laatste mislukte inlogpogingen bij [23](#page=23). * Het is standaard ingeschakeld op de meeste distributies [23](#page=23). * Het logboek is opgeslagen in een binair formaat [23](#page=23). * Om dit logboek te lezen, kunnen de commando's `lastb` of `lslogins --failed` worden gebruikt [23](#page=23). * **Opmerking:** Vergelijkbaar met `lastlog`, toont de standaarduitvoer alleen gebruikers uit `/etc/passwd`. Verwijderde en niet-lokale gebruikers worden niet standaard weergegeven [23](#page=23). * Voor forensisch onderzoek op een niet-live systeem kan het commando `lastb -f ` worden gebruikt [24](#page=24). #### 1.2.3 Y2K38 bug * Het `btmp` logbestand, net als andere binaire logbestanden, kan last hebben van de Y2K38 bug, die problemen kan veroorzaken met tijdstempels na het jaar 2038 [25](#page=25). #### 1.2.4 `/var/log/faillog` * Dit logbestand registreert de pogingen die worden beheerd door `pam_faillock.so` [26](#page=26). * De `pam_faillock` module houdt een lijst bij van mislukte authenticatiepogingen per gebruiker gedurende een gespecificeerd interval en vergrendelt het account als er meer dan een gedefinieerd aantal ("deny") opeenvolgende mislukte authenticaties plaatsvinden [26](#page=26). * Deze functie is niet standaard ingeschakeld op Debian/RHEL [26](#page=26). * Het logboek is opgeslagen in een binair formaat [26](#page=26). * Om dit logboek te lezen, kan het commando `faillog` worden gebruikt [26](#page=26). #### 1.2.5 `/var/log/wtmp` * Dit logbestand bevat informatie over alle succesvolle logins, logouts en systeemreboots [27](#page=27). * Het is standaard ingeschakeld op de meeste distributies [27](#page=27). * Het logboek is opgeslagen in een binair formaat [27](#page=27). * Om dit logboek te lezen, kan het commando `last` worden gebruikt [27](#page=27). * **Opmerking:** In tegenstelling tot `lastlog` en `lastb`, worden hier ook verwijderde en niet-lokale gebruikers weergegeven [27](#page=27). * Voor forensisch onderzoek op een niet-live systeem kan het commando `last -f ` worden gebruikt [28](#page=28). #### 1.2.6 `/run/utmp` * Dit bestand bevat informatie over gebruikers die momenteel zijn ingelogd op het systeem [29](#page=29). * Het is standaard ingeschakeld op de meeste distributies [29](#page=29). * Het logboek is opgeslagen in een binair formaat [29](#page=29). * Om dit logboek te lezen, kunnen de commando's `who` of `w` worden gebruikt. Het `w` commando biedt aanvullende informatie ten opzichte van `who`, zoals de huidige processen en CPU-tijd die door de gebruiker worden gebruikt [29](#page=29). ### 1.3 Samenvatting van login/sessie commando's * `who`: Toont wie er is ingelogd [31](#page=31). * `w`: Toont wie er is ingelogd en wat ze aan het doen zijn [31](#page=31). * `last`: Rapporteert de meest recente logins en boot tijden [31](#page=31). * `lastb` / `lslogins --failed`: Toont een lijst van de laatste mislukte logins [31](#page=31). * `lastlog` / `lslogins`: Toont een lijst van de laatste inlogtijd van gebruikers [31](#page=31). * `faillog`: Toont een lijst van het aantal mislukte logins van gebruikers vóór een lockout (indien ingeschakeld) [31](#page=31). --- # De systemd-journal De systemd-journal biedt een beveiligd en gestructureerd alternatief voor traditionele tekstgebaseerde logboeksystemen door middel van cryptografische hashing en verbeterde permissiebeheer [5](#page=5) [9](#page=9). ### 2.1 Structuur en opslagformaat De systemd-journal slaat logboekvermeldingen op in binaire bestanden, die doorgaans te vinden zijn in de submap `/var/log/journal/`. De kern van de beveiligingsvoordelen ligt in de manier waarop deze logboeken worden opgeslagen. Geïnspireerd door systemen zoals Git, worden alle logboekvermeldingen cryptografisch gehasht, waarbij elke vermelding de hash van de voorgaande vermelding bevat. Dit creëert een keten van vermeldingen, waardoor elke vermelding alle voorgaande authenticeert. Door de meest recente hash veilig op te slaan, bijvoorbeeld op een write-once locatie, kan de integriteit van de gehele logboekketen worden gewaarborgd, waardoor manipulaties door aanvallers gemakkelijk detecteerbaar zijn [5](#page=5) [7](#page=7) [8](#page=8). #### 2.1.1 Bestandseigenschappen en permissies De logboekbestanden in `/var/log/journal/` zijn eigendom van root, maar de groep `systemd-journal` heeft speciale permissies [9](#page=9). * **SetGID permissie (`drwxr-sr-x+`):** Deze permissie zorgt ervoor dat alle bestanden die in deze map worden aangemaakt, automatisch de groep `systemd-journal` krijgen. Dit betekent dat leden van de `systemd-journal` groep volledige toegang hebben tot de logbestanden zonder dat ze sudo-permissies nodig hebben [9](#page=9). * **Extended Attributes (ACLs):** Naast de standaard UNIX-permissies kunnen er ook extended attributes (xattr) aanwezig zijn in de `system` namespace. Deze worden gebruikt voor Access Control Lists (ACLs) wat verder verfijnt wie toegang heeft tot de logbestanden [10](#page=10) [11](#page=11). > **Tip:** De SetGID-permissie op de journal-map is een belangrijke beveiligingsfunctie die geautoriseerde gebruikers toegang geeft tot loggegevens zonder de noodzaak van verhoogde privileges [9](#page=9). ### 2.2 Configuratie en distributiespecifieke verschillen De systemd-journal wordt beheerd door de `systemd-journald` service, geconfigureerd via `journald.conf` (meestal in `/etc/systemd/`). Er zijn enkele verschillen in hoe de journal wordt gebruikt en geconfigureerd tussen verschillende Linux-distributies [6](#page=6). #### 2.2.1 RHEL (Red Hat Enterprise Linux) In RHEL, dat ook systemd gebruikt, bevat de systemd-journal de beveiligingsberichten en andere gebeurtenissen die men normaal zou vinden in `/var/log/secure` [12](#page=12). * **Persistentie:** Een belangrijk verschil is dat de systemd-journal in RHEL standaard *niet persistent* is en de logboeken worden opgeslagen in `/run/log/journal/`. Dit kan echter worden aangepast via het `journald.conf` bestand om de journal persistent te maken [12](#page=12). * **Permissies en ACLs:** Leden van de `wheel` groep hebben in RHEL ook leesrechten tot alle journalbestanden, wat betekent dat ze zonder sudo-permissies alle logboekvermeldingen kunnen bekijken. Verder kunnen journalbestanden extended attributes bevatten voor ACLs en SELinux-contexten [13](#page=13). #### 2.2.2 Debian en vergelijkbare distributies In distributies zoals Debian worden de journalbestanden doorgaans opgeslagen in `/var/log/journal/` en zijn ze standaard persistent. De permissiebeheer via de `systemd-journal` groep is ook hier van toepassing [7](#page=7) [9](#page=9). > **Tip:** Het is cruciaal om de distributiespecifieke configuratie van `journald.conf` te controleren, vooral met betrekking tot de persistentie van logboeken in omgevingen zoals RHEL [12](#page=12). ### 2.3 Beveiligingsvoordelen ten opzichte van traditionele tekstlogboeken De systemd-journal biedt aanzienlijke beveiligingsvoordelen ten opzichte van traditionele platte tekstlogboeken die via syslog worden beheerd [5](#page=5). * **Integriteit:** De cryptografische hashing-keten zorgt ervoor dat de integriteit van logboeken gegarandeerd kan worden. Elke poging tot het wijzigen van een logboekvermelding zou de hash van dat item en alle volgende items ongeldig maken, wat de manipulatie direct zichtbaar maakt [5](#page=5). * **Authenticatie:** De hash-keten fungeert als een vorm van authenticatie, waardoor logboekvermeldingen kunnen worden geverifieerd als authentiek en ongewijzigd [5](#page=5). * **Verbeterd permissiebeheer:** De speciale groep `systemd-journal` en de ondersteuning voor ACLs maken een fijnmaziger controle van toegang tot loggegevens mogelijk, wat kan helpen bij het beperken van onbevoegde toegang [10](#page=10) [9](#page=9). > **Voorbeeld:** Stel dat een aanvaller probeert om zijn toegang tot een systeem te verbergen door logboeken te wissen of te wijzigen. Met traditionele tekstbestanden kan dit relatief onopgemerkt gebeuren. Met de systemd-journal zal een dergelijke wijziging de cryptografische keten verbreken, waardoor het systeembeheerder dit direct kan detecteren [5](#page=5). --- # Systeemeen kernellogboeken This section details system-wide logging mechanisms, focusing on general system logs like syslog and messages, and the kernel ring buffer used for capturing boot-time information [32](#page=32) [35](#page=35). ### 3.1 System logs System logs provide a centralized location for recording events and messages generated by the operating system and its services. These logs are crucial for monitoring system health, diagnosing issues, and auditing activities [33](#page=33). #### 3.1.1 Log file locations The specific location of system log files can vary between Linux distributions. * **Debian and derivatives:** Historically, logs were found in `/var/log/syslog`. However, since Debian 12, the `systemd-journald` service has largely replaced this with its own logging system, which can be accessed using `journalctl`. It's important not to confuse the `syslog` log file with the `(r)syslog` daemon itself [33](#page=33). * **RHEL and derivatives:** In Red Hat Enterprise Linux and its derivatives, the primary system log file is located at `/var/log/messages` [33](#page=33) [34](#page=34). #### 3.1.2 Accessing system logs While specific log files are important, the `journalctl` command is a modern and powerful tool for accessing logs, especially on systems using `systemd` [33](#page=33). ### 3.2 Kernel ring buffer The kernel ring buffer is a dedicated mechanism for capturing messages generated during the system's boot process and by the kernel itself [36](#page=36). #### 3.2.1 Purpose and function During system startup, a significant amount of information is displayed on the console, detailing hardware events, driver initialization, boot processes, and other low-level system occurrences. To prevent the loss of these critical early messages, the kernel employs a ring buffer [36](#page=36). * **Message Storage:** This buffer stores all messages, including boot-time messages, that are generated by the `printk()` function within the kernel code [36](#page=36). * **"Ring" Concept:** The term "ring" refers to the buffer's nature as a cyclic data structure with a fixed, hard-coded size within the kernel. When the buffer becomes full, new incoming data overwrites the oldest data, ensuring that the most recent information is always available [36](#page=36). #### 3.2.2 Accessing the kernel ring buffer The kernel ring buffer's contents can be accessed through several methods: * **Character Device:** It is available as the character device `/dev/kmsg` [37](#page=37) [39](#page=39). * **Legacy Files:** Older distributions might have stored kernel messages in files like `/var/log/dmesg` or `/var/log/kern.log` [37](#page=37). * **Tools:** * `dmesg` (diagnostic message): This command is a common utility to display messages from the kernel ring buffer [37](#page=37) [38](#page=38). * `journalctl -k`: This command, part of the `systemd` journal system, specifically displays kernel messages [37](#page=37). * `journalctl --dmesg`: An alternative `journalctl` command to view messages equivalent to `dmesg` [37](#page=37). > **Tip:** The kernel ring buffer is essential for understanding the very first moments of your system's operation, making it invaluable for debugging boot failures or hardware initialization problems. --- # Applicatie- en logbeheer Dit gedeelte behandelt de mechanismen voor het beheren van applicatielogs, inclusief protocollen zoals syslog, implementaties zoals rsyslog, en logrotatie met logrotate en journald. ### 4.1 Applicatielogs Applicaties genereren diverse logbestanden die cruciaal zijn voor monitoring en troubleshooting. Standaard worden deze logs vaak opgeslagen in de `/var/log/` directory [40](#page=40) [41](#page=41). #### 4.1.1 Locaties van applicatielogs Verschillende applicaties hebben hun eigen specifieke loglocaties: * **Apache2 webserver:** * RHEL-gebaseerde systemen: `/var/log/httpd/*` [41](#page=41). * Debian-gebaseerde systemen: `/var/log/apache2/*` [41](#page=41). * **NGINX webserver:** `/var/log/nginx/*` [41](#page=41). * **Fail2Ban:** `/var/log/fail2ban.log` [41](#page=41). * **ufw (Uncomplicated Firewall):** `/var/log/ufw.log` [41](#page=41). * **Apache Tomcat:** `/opt/tomcat/logs/*` (voor Java-applicatieservers) [43](#page=43). Voorbeelden van de inhoud van deze logs zijn te vinden in bestanden zoals `/var/log/httpd/access.log` [42](#page=42). #### 4.1.2 Andere logmechanismen Naast het opslaan in platte tekstbestanden, kunnen applicaties ook gebruik maken van `systemd-journald` voor hun logging. Een voorbeeld hiervan is de OpenSSH server, waarvan de logs bevraagd kunnen worden met `journalctl -u sshd` [43](#page=43). ### 4.2 Logbeheer: rsyslog Rsyslog is een implementatie van het syslog-protocol dat wordt gebruikt voor het verzamelen en routeren van logberichten van verschillende bronnen [45](#page=45). #### 4.2.1 Syslog protocol Het syslog-protocol (nu gestandaardiseerd in RFC 5424) scheidt logberichten van de software die ze genereert en de software die ze analyseert. Door de jaren heen zijn er verschillende implementaties geweest [45](#page=45): * **Syslog (jaren '80):** Geïntroduceerd in UNIX-systemen om berichten van de kernel en applicaties te loggen [45](#page=45). * **Syslog-ng:** Breidde syslog uit met functies zoals filtering en aangepaste opmaak [45](#page=45). * **Rsyslog:** Voegde functies toe zoals hoge prestaties en database-integratie. De 'r' staat voor 'rocket fast' en 'remote log shipping' [45](#page=45). #### 4.2.2 Rsyslog in moderne distributies * **Debian:** Sinds Debian 12 wordt rsyslog niet standaard geïnstalleerd. Basis lokale logging wordt afgehandeld door `systemd-journald`, waardoor rsyslog voor deze taak overbodig werd. Het is echter nog steeds beschikbaar in de repositories en kan worden geïnstalleerd voor externe syslog-behoeften of software die het nog vereist [46](#page=46). * **RHEL (Red Hat Enterprise Linux):** Rsyslog is standaard beschikbaar [46](#page=46). Het rsyslog-daemon is verantwoordelijk voor het verwerken van logberichten. De configuratie van rsyslog vindt plaats in het bestand `/etc/rsyslog.conf` [47](#page=47) [48](#page=48). #### 4.2.3 Facility codes en severity levels Rsyslog gebruikt "facility codes" en "severity levels" om logberichten te categoriseren en prioriteren [49](#page=49). * **Facility:** Specificeert de bron van het logbericht (bv. kernel, mail, auth) [49](#page=49). * **Severity:** Geeft het belang van het logbericht aan (bv. debug, info, warning, error) [49](#page=49). Deze codes en levels worden gebruikt voor het filteren, routeren en beheren van logs [49](#page=49). > **Tip:** Het begrijpen van facility codes en severity levels is essentieel voor het effectief filteren en analyseren van logbestanden [49](#page=49) [50](#page=50). ### 4.3 Logbeheer: logrotate Logrotate is een tool die wordt gebruikt om de groei van logbestanden te beheren door ze periodiek te roteren. Het werkt met platte tekstlogbestanden en niet met de `systemd-journald` logs [52](#page=52). #### 4.3.1 Functies van logrotate Logrotate voert de volgende taken uit: * **Rollen:** Start een nieuw logbestand na een bepaalde periode (roteren) [52](#page=52). * **Compressie:** Optioneel kan het geroteerde logbestanden comprimeren [52](#page=52). * **Verwijderen:** Verwijdert oude logs op basis van ingestelde retentieperiodes [52](#page=52). Logrotate wordt typisch dagelijks uitgevoerd, vaak getriggerd door `cron` of een `systemd timer` [52](#page=52). #### 4.3.2 Configuratie van logrotate De configuratie van logrotate is onderverdeeld in twee locaties: * **/etc/logrotate.conf:** Definieert de standaardinstellingen, zoals wekelijkse rotatie en een retentieperiode van vier weken. Een voorbeeld hiervan is het beheer van `/var/log/secure` op RHEL-systemen [52](#page=52) [55](#page=55). * **/etc/logrotate.d/:** Bevat specifieke configuratiebestanden voor individuele logbestanden. Dit wordt gebruikt om specifieke instellingen te definiëren voor bepaalde logs, zoals de `/var/log/btmp` bestanden die worden gebruikt door commando's als `lastb` [52](#page=52) [56](#page=56). > **Example:** Een configuratie in `/etc/logrotate.d/apache2` kan specificeren dat het access log dagelijks geroteerd moet worden, gecomprimeerd na rotatie, en dat er 7 dagen aan logs bewaard moeten blijven [54](#page=54). ### 4.4 Logbeheer: systemd-journald `systemd-journald` is een logboekbeheerservice die deel uitmaakt van `systemd`. Het beheert logs op een andere manier dan traditionele syslog-implementaties, doorgaans niet in platte tekstbestanden [58](#page=58). #### 4.4.1 Configuratie van journald De instellingen voor het roteren van de journallogs worden beheerd in het configuratiebestand `/etc/systemd/journald.conf` [58](#page=58). #### 4.4.2 Logrotatie bij tijdswijzigingen Logrotatie kan ook worden getriggerd door abrupte (backward) tijdswijzigingen. Dit is bijvoorbeeld relevant bij het starten van virtuele machines waarbij de systeemtijd mogelijk niet correct is gesynchroniseerd met het hostsysteem. Door de logs in een apart bestand te bewaren, worden problemen door uit-de-orde-geplaatste logboekvermeldingen voorkomen, wat de logintegriteit en de tijdlijn van gebeurtenissen verbetert [59](#page=59). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | Authenticatie logboeken | Logbestanden die informatie bevatten over de inlogactiviteiten van gebruikers, zoals pogingen tot inloggen en de resultaten daarvan. Dit helpt bij het volgen van wie, wanneer en hoe toegang heeft verkregen tot het systeem. | | systemd-journald | Een systeemcomponent die verantwoordelijk is voor het verzamelen, opslaan en doorsturen van logberichten in een gestructureerd binair formaat, wat zorgt voor betere integriteit en efficiëntie vergeleken met traditionele platte tekstlogboeken. | | journalctl | Een commando-regelprogramma dat wordt gebruikt om logboeken uit de systemd-journal uit te lezen en te manipuleren. Het biedt krachtige filter- en sorteeropties. | | cryptografisch gehasht | Een proces waarbij data wordt omgezet in een unieke, vaste-lengte string (hash) met behulp van cryptografische algoritmen. Dit wordt gebruikt om de integriteit van gegevens te waarborgen, aangezien elke wijziging in de originele data resulteert in een andere hash. | | setgid (set group ID) | Een speciale bestandspermissie in Unix-achtige systemen die ervoor zorgt dat een uitgevoerd programma de groepseigendom van de uitvoerder overneemt, in plaats van het groepseigendom van de eigenaar van het uitvoerbare bestand. In de context van logbestanden kan dit gebruikers toegang verlenen zonder directe sudo-rechten. | | Access Control List (ACL) | Een uitbreiding op de traditionele Unix-bestandspermissies die gedetailleerdere controle biedt over wie toegang heeft tot bestanden en mappen, en welke acties ze mogen uitvoeren. ACL's worden opgeslagen in 'extended attributes'. | | Extended attributes (xattr) | Metagegevens die gekoppeld zijn aan bestanden en directories, bovenop de standaard Unix-permissies. Deze kunnen onder andere ACL's, SELinux-contexten of andere specifieke informatie bevatten. | | Kernel ring buffer | Een cyclische datastructuur met een vaste grootte die berichten opslaat die door de kernel worden gegenereerd tijdens het opstarten en tijdens de normale werking van het systeem. Nieuwe berichten overschrijven de oudste wanneer de buffer vol is. | | dmesg | Een commando dat wordt gebruikt om de kernelringbuffer uit te lezen. Het toont diagnostische berichten van de kernel, die nuttig zijn voor het oplossen van problemen met hardware en stuurprogramma's. | | syslog | Een gestandaardiseerd netwerkprotocol voor het verzenden van logberichten van verschillende bronnen naar een centrale logserver. Het definieert logboekberichten op basis van 'facility' (bron) en 'severity' (ernst). | | rsyslog | Een verbeterde implementatie van het syslog-protocol, bekend om zijn hoge prestaties en ondersteuning voor functies zoals database-integratie en remote log shipping. | | facility code | Een indicator in een logbericht die de bron of categorie van het bericht aangeeft, zoals de kernel, gebruikersprocessen of specifieke daemons. | | severity level | Een indicator in een logbericht die de ernst van het gebeuren beschrijft, variërend van debug-informatie tot kritieke fouten en noodsituaties. | | logrotate | Een hulpprogramma dat wordt gebruikt om logbestanden automatisch te beheren door ze te roteren (nieuwe bestanden aanmaken), te comprimeren en oude logboeken te verwijderen volgens gedefinieerde regels, om schijfruimte te besparen en logbestanden hanteerbaar te houden. | | log retention policy | Een beleid dat bepaalt hoe lang logbestanden worden bewaard voordat ze worden verwijderd of gearchiveerd. Dit is cruciaal voor compliance, beveiligingsaudits en het beheren van schijfruimte. | | /var/log/lastlog | Een binair logbestand dat de meest recente login-informatie voor elke gebruiker op het systeem opslaat. Het wordt gelezen met het commando 'lastlog'. | | /var/log/btmp | Een binair logbestand dat mislukte login-pogingen bijhoudt. Het wordt gelezen met het commando 'lastb'. | | /var/log/wtmp | Een binair logbestand dat alle succesvolle logins en logouts, evenals systeemherstarts, registreert. Het wordt gelezen met het commando 'last'. | | /run/utmp | Een binair logbestand dat informatie bevat over gebruikers die momenteel op het systeem zijn ingelogd. Het wordt gelezen met de commando's 'who' of 'w'. | | Y2K38 bug | Een probleem dat vergelijkbaar is met de Y2K-bug, waarbij tijdstempels die worden opgeslagen met een 32-bit 'signed integer' de waarde van het jaar 2038 zullen overschrijden, wat kan leiden tot onverwacht gedrag in software die deze tijdstempels gebruikt. | | PAM (Pluggable Authentication Modules) | Een flexibel framework dat applicaties in staat stelt om authenticatie- en autorisatiemechanismen te gebruiken die configureerbaar zijn zonder de applicatie zelf te hoeven wijzigen. |