Serverlogs lezen en centraliseren
Kort antwoord
Op Linux komen inlogpogingen terecht in /var/log/auth.log of /var/log/secure, algemene systeemmeldingen in /var/log/syslog of via journalctl op systemd-distributies, en de meeste applicaties houden hun eigen logs bij onder /var/log/<applicatie>/. Op Windows staat dezelfde informatie in Event Viewer, of is die op te vragen vanuit PowerShell met Get-WinEvent of Get-EventLog. Zodra je meer dan een server of twee draait, maakt het centraliseren van die logs buiten de servers zelf het pas echt mogelijk om een incident te onderzoeken.
Elke server houdt zijn eigen verslag bij van wat erop is gebeurd, maar waar dat verslag staat en hoe lang het bewaard blijft, verschilt per besturingssysteem. Weten waar je moet kijken is de eerste helft van het probleem. De tweede helft speelt zodra je meer dan een server hebt: lokale logs alleen zijn dan niet meer genoeg.
Waar je moet kijken op Linux
| Log | Gebruikelijke locatie | Wat erin staat |
|---|---|---|
| Authenticatie | /var/log/auth.log (Debian/Ubuntu) of /var/log/secure (RHEL-familie) | SSH-logins, sudo-gebruik, mislukte authenticatiepogingen |
| Algemene systeemmeldingen | /var/log/syslog, of journalctl op systemd-gebaseerde distributies | Kernelmeldingen, start/stop-events van services, algemene systeemactiviteit |
| Applicatielogs | Meestal onder /var/log/<applicatie>/, bijvoorbeeld /var/log/nginx/ | Wat de betreffende applicatie zelf besluit te loggen, de opmaak verschilt per applicatie |
Op een systemd-gebaseerde distributie is journalctl meestal de snelste ingang: het bundelt bootmeldingen, service-output en kernellogs op een plek, en is te filteren op service, tijdsbereik of prioriteit. Op oudere of niet-systemd-systemen staat diezelfde informatie verspreid over de platte-tekstbestanden onder /var/log/.
Waar je moet kijken op Windows
Windows centraliseert het meeste hiervan in Event Viewer, ingedeeld in logs zoals Application, Security en System. Voor alles wat je wilt doorzoeken, filteren of scripten is PowerShell meestal sneller dan klikken door de Event Viewer-interface:
Get-WinEventis de moderne cmdlet, werkt met het nieuwere gestructureerde eventlog-formaat en ondersteunt filteren op lognaam, event-ID en tijdsbereik.Get-EventLogis de oudere cmdlet, nog steeds veel gebruikt in bestaande scripts, en werkt met de klassieke event logs.
Beide manieren leveren dezelfde onderliggende events op die Event Viewer laat zien, alleen in een vorm die je kunt filteren, exporteren of naar een andere tool voeren.
Waarom centraliseren van logs belangrijk wordt zodra je meer dan een of twee servers hebt
Logs lezen op een enkele server is prima te doen. Het probleem ontstaat zodra een incident meerdere machines raakt, en dat geldt voor de meeste incidenten die er echt toe doen. Als de logs van elke server alleen lokaal bestaan, is het bijna onmogelijk om te achterhalen wat er op meerdere servers is gebeurd, in de juiste volgorde en op de juiste tijdstippen: je logt dan op elke server apart in, vergelijkt tijdstempels met de hand, en hoopt dat geen van de relevante regels al is weggeroteerd. De meeste systemen bewaren lokale logs maar een paar dagen voordat oudere regels worden geroteerd of verwijderd, dus tegen de tijd dat je een probleem opmerkt, kan een deel van het bewijs al verdwenen zijn.
Een centraal logplatform pakt beide problemen tegelijk aan. Logs van elke server worden verstuurd naar een andere plek zodra ze ontstaan, zodat ze doorzoekbaar blijven over de hele vloot vanaf een plek, ze bewaard kunnen blijven zolang jij zelf kiest in plaats van zo lang als lokale rotatie toelaat, en, cruciaal, ze blijven bestaan zelfs als de server die ze genereerde volledig uitvalt of gecompromitteerd raakt. Dat laatste punt is vooral belangrijk bij incidentonderzoek: als een aanvaller controle heeft over een server, zijn de lokale logs op diezelfde server niet te vertrouwen, logs die al elders zijn opgeslagen vóór de inbraak wel.
Het algemene patroon voor centraal loggen
De precieze werkwijze verschilt per tool, maar het onderliggende patroon is steeds hetzelfde: een lichte agent of forwarder draait op elke server, houdt de relevante logbronnen in de gaten en stuurt nieuwe regels door naar een centrale bestemming zodra ze verschijnen, in plaats van te wachten tot iemand ze komt ophalen. Die bestemming is doorgaans gebouwd om volledige tekstzoekopdrachten, retentiebeleid en dashboards of alerting op de binnenkomende logstroom aan te kunnen. Dit is een patroon, geen specifiek product: welke tool het beste past hangt af van je bestaande stack en hoeveel logvolume je te verwerken hebt. Nauwkeurige tijdstempels op elke server zijn hierbij ook belangrijk, want events over machines heen correleren werkt alleen als hun klokken gelijklopen, zie Waarom nauwkeurige servertijd belangrijk is (NTP-basis).