felsökning med Linux-loggar

felsökning är en av de främsta anledningarna till att människor skapar loggar. När ett problem uppstår vill du diagnostisera det för att förstå varför det hände och vad orsaken var. Ett felmeddelande eller en sekvens av händelser kan ge dig ledtrådar till grundorsaken, ange hur du reproducerar problemet och vägleda dig mot lösningar. Det här avsnittet presenterar scenarier där du kan använda Linux-loggar för felsökning.,

misslyckas

inloggningsfel

för säkerhetsändamål kanske du vill veta vilka användare som har loggat in eller försökt logga in på ditt system. Du kan kontrollera dina autentiseringsloggar för misslyckade försök, som inträffar när användare tillhandahåller felaktiga autentiseringsuppgifter eller inte har behörighet att logga in. Detta inträffar ofta när du använder SSH för fjärråtkomst eller när du använder su-kommandot för att köra ett kommando som en annan användare. Dessa typer av autentiseringshändelser loggas av pluggable authentication module (PAM)., Misslyckade händelser innehåller ofta strängar som ”misslyckat lösenord ”och” användare okänt”, medan framgångsrika autentiseringshändelser innehåller ofta strängar som” accepterat lösenord ”och” session öppnas.”

exempel på felhändelser inkluderar:

exempel på framgångsrika inloggningar inkluderar:

om vi vill ta reda på vilka användarkonton som har de mest misslyckade inloggningarna måste vi först extrahera användarnamnet från auth-loggen. Vi använder grep, cut, sort, och uniq kommandon för att göra detta., Grep returnerar rader som innehåller ”ogiltig användare”, cut extraherar användarnamn, sorterar order listan med namn, och uniq räknar antalet unika namn:

andra program och tjänster kan använda olika format, så du måste anpassa detta kommando för varje applikation. Log management systems kan effektivt göra detta för dig genom att automatiskt tolka fält som användarnamn. Detta gör att du snabbt visa och filtrera på misslyckade inloggningar med ett enda klick. I det här exemplet kan vi se root-användaren försökte logga in över 300 gånger.,

användarnamn associerade med misslyckade inloggningsförsök som visas i loggly dynamic field explorer.

Logghanteringssystem låter dig också se diagram över tiden för att upptäcka ovanliga trender. Om någon hade en eller två misslyckade inloggningar inom några minuter kan det vara så att en riktig användare glömde sitt lösenord. Men om det finns hundratals misslyckade inloggningar eller de är alla olika användarnamn, är det mer troligt att någon försöker attackera systemet. Här kan du se en plötslig ökning av försök till inloggningar som administratör., Detta är uppenbarligen inte en legitim användning av systemet.

uppsving i försök till rot inloggningar. © 2019 Början Till Början, Inc. Alla rättigheter förbehållna.

orsak

orsak till omstart

Ibland kan en server sluta på grund av en systemkrasch eller omstart. Hur vet du när det hände och vem gjorde det?

Avstängningskommando

om någon körde avstängningskommandot manuellt kan du se det i auth-loggfilen. Här kan du se att någon på distans inloggad som användaren ubuntu och sedan stänga av systemet.,

Kernel initierar

om du vill se när servern startas om oavsett orsak (inklusive krascher), kan du söka i kernel log-filen (/var/log/kern.log). Syslog tillämpar också” kern ” – anläggningen till kärnloggar. Följande loggar genererades omedelbart efter uppstart. Obs! tidsstämpeln mellan parenteserna är 0: detta spårar tiden sedan kärnan startade. Du kan också hitta startloggar genom att söka efter ”BOOT_IMAGE”.,

upptäck

Upptäck minnesproblem

det finns flera anledningar till att en server kan krascha, men en vanlig orsak börjar ta slut på minnet.

När RAM och växlingsutrymme är helt uttömda börjar kärnan döda processer-vanligtvis de som använder mest minne och mest kortlivade. Felet uppstår när ditt system använder allt minne, och en ny eller befintlig process försöker komma åt ytterligare minne. Titta i dina loggfiler för strängar som ”Out of Memory” eller för kernel varningar., Dessa strängar indikerar att ditt system avsiktligt dödade processen eller applikationen istället för att låta processen krascha.

exempel:

tänk på att grep själv använder minne, så du kan orsaka ett fel i minnet bara genom att köra grep. Detta är en annan anledning till varför det är en fantastisk idé att centralisera dina loggar!

cron

loggning Cron jobb fel

cron demonen är en schemaläggare som kör kommandon vid angivna datum och tider. Om processen misslyckas med att köra eller misslyckas med att avsluta, visas ett cron-fel i dina loggfiler., Du hittar dessa filer i /var/log/cron, /var/log/messages och /var/log/syslog beroende på din distribution. Det finns många skäl en cron jobb kan misslyckas. Vanligtvis ligger problemen med processen snarare än cron-demonen själv.

som standard matas cron-jobb ut till syslog och visas i filen /var/log/syslog. Du kan också omdirigera utmatningen från dina cron-kommandon till en annan destination, till exempel standardutmatning eller en annan fil. I det här exemplet rör vi ”Hello world” till logger-kommandot., Detta skapar två logghändelser: en från cron och en från logger-kommandot. Parametern-t anger appnamnet till ”helloCron”::

$ crontab -e*/5 * * * * echo 'Hello World' 2>&1 | /usr/bin/logger -t helloCron

vilket skapar loggposterna:

varje cron-jobb loggar olika baserat på den specifika typen av jobb och hur det matar ut data. Förhoppningsvis finns det ledtrådar till orsaken till problem inom loggarna, eller så kan du lägga till ytterligare loggning efter behov. I de flesta fall bör du helt enkelt låta cron logga utsignalen från dina kommandon.