Mälutõmmise ja kerneli analüüs Windowsi ja Unixi süsteemides

Informatec Digital » Ressursid » Mälutõmmise ja kerneli analüüs Windowsi ja Unixi süsteemides

Kui operatsioonisüsteem satub paanikasse või krahhib järsult, on ainus viis aru saada, mis juhtus... kerneli mälutõmmis ja sellele järgnev analüüsNeed prügimäed jäädvustavad süsteemi sisemise oleku rikke hetkel ning on toormaterjaliks keerukate vigade silumiseks, turvaintsidentide uurimiseks või kohtuekspertiisi läbiviimiseks.

Kuigi see võib tunduda väga "madala tasemega", ei ole mälutõmmise analüüsimine ainult kerneli arendajatele mõeldud. Süsteemiadministraatorid, tugiinsenerid ja isegi turvaaudiitorid saavad sellest kasu, kui nad tunnevad põhitõdesid. sobivaid tööriistu, prügimägede tüüpe ja põhilisi tõlgendamistehnikaidMe käsitleme kogu seda teed Windowsis, Unixis/Linuxis ja BSD-s, kasutades selliseid tööriistu nagu WinDbg, crash, kgdb ja LiME.

Mis on kerneli mälutõmmis ja miks seda tasub analüüsida?

Kerneli mälutõmmis (sageli nimetatakse Kerneli krahhitõmmis või lihtsalt krahhitõmmis) on fail, mis sisaldab mälu täielikku või osalist koopiat hetkel, kui süsteemis tekib kriitiline tõrge, näiteks tuuma paanika Unixis/Linuxis või sinine surmaekraan (BSOD) Windowsis.

Praktikas säästab seda tüüpi prügimägi sisemised kerneli struktuurid, väljakutsete pinud, protsessi kontekst ja laaditud draiveridTänu sellele saab pärast katastroofi teha "post mortem" analüüsi, mis on väga sarnane reaalajas süsteemi silumisega, kuid ilma surveta puudutada rikke ajal tootmismasinat.

Kerneli prügimägede põhjaliku uurimise põhjused on mitmekesised: alates siluda pealtnäha juhuslikke vigu ja vahelduvaid krahhe...isegi uurides, kas süsteemi on pahatahtlikult manipuleeritud või kas krahh võis kettale tundliku teabe jälgi jätta.

Lisaks täielikele kerneli prügimägedele on võimalik ka üksikute protsesside prügimägesid ekstraheerida (klassikaline põhimaterjalid), mis on väga kasulikud siis, kui see, mida me tahame, on probleemi piiramiseks konkreetse rakendusega või teenuse konfidentsiaalsusele avalduva mõju ülevaatamiseks nagu e-posti või sõnumside klient.

Mälutõmmiste tüübid Windowsis ja nende kasulikkus

Windowsi süsteemides saab operatsioonisüsteem ise STOP-vea ilmnemisel genereerida erinevat tüüpi prügimägesid. Igal tüübil on erinev detailsuse tase, seega on oluline teada, milliseid neist kasutada. Millist tüüpi prügimäge me vajame probleemi ja kettaruumi piirangute põhjal?.

Üks levinumaid vorminguid kasutajakeskkondades ja paljudes serverites on väike mälutõmmis (minidump)See võtab kõige vähem ruumi ja asub tavaliselt %SystemRoot%\Minidump, stiilis failidega MiniKKPPAA-01.dmp.

See miniprügimähis sisaldab väga spetsiifilist, kuid olulist teavet: STOP-veakood ja selle parameetrid, tõrke ajal laaditud draiverite loend, peatunud protsessori kontekst (PRCB), kaasatud protsessi ja lõime kontekstid (EPROCESS ja ETHREAD struktuurid) ning selle lõime kernel-režiimi väljakutsete pinu.

Tänu neile põhistruktuuridele on isegi minidumpi abil sageli võimalik tuvastada, milline draiver või moodul krahhe põhjustab, kuigi kogu probleemi ei ole alati võimalik leida, kui see pärineb kaugelt krahhi ajal töötavast lõimest. Saadaval olev kontekstuaalne teave on piiratud.

Windows saab genereerida ka kerneli mälutõmmiseid ja palju suuremaid täistõmmiseid, mis sisaldavad kogu füüsilist mälu või selle osi. Need on eriti kasulikud järgmistes olukordades: draiverite või süsteemi enda madala taseme analüüs, kohtuekspertiisi uuringud ja täiustatud silumine.

Mälutõmmiste seadistamine ja avamine Windowsis WinDbg ja KD abil

Windowsi prügimägede ärakasutamiseks on esimene asi, et valikud oleksid õigesti konfigureeritud. käivitamine ja taastamineJuhtpaneeli täpsemate süsteemiomaduste alt saate valida tõrke korral genereeritava mälutõmmise tüübi: näiteks „Väike mälutõmmis (256 KB)” ja tee, kuhu see salvestatakse.

Süsteem vajab ka vähemalt mõne megabaidise alglaadimismahuga lehefail prügimäe kirjutamiseks. Windowsi tänapäevastes versioonides loob iga krahh uue faili ja konfigureeritud kausta salvestatakse ajalugu, mis võimaldab varasemaid intsidente hõlpsalt üle vaadata.

Kui prügimäed on genereeritud, on mitu võimalust nende õigsuse kontrollimiseks. Üks klassikaline tööriist on Dumpchk.exemis võimaldab teil kontrollida faili põhilist terviklikkust ja printida kokkuvõtlikku teavet. Täpsema analüüsi jaoks kasutatakse järgmist: Windowsi silumisriistadmille hulka kuuluvad WinDbg (graafiline liides) ja KD (käsurea versioon).

Pärast silumispaketi installimist Microsofti veebisaidilt asuvad tööriistad tavaliselt sellises kaustas nagu C:\Program Files\Windowsi silumisriistadSealt saame avada käsuviiba ja laadida prügimäe WinDbg või KD parameetri -z abil faili määramiseks:

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Sümbolitee võib viidata a-le. sümboliserver kohaliku vahemälugaNäiteks:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Kuigi binaartee on tavaliselt midagi sellist C:\Windows\I386 või kaust, kuhu oleme kopeerinud süsteemi käivitatavad failid, mis vastavad versioonile, mis genereeris prügimäe. See on oluline, sest Minidump-failid ei sisalda kõiki binaarfaile, ainult viiteid neile, seega peab silur suutma need leida.

Windowsi kerneli krahhi mälutõmmise põhianalüüs

Kui mälutõmmis on WinDbg või KD abil laaditud, on kerneli krahhi mälutõmmise analüüsimine üsna sarnane pärast surma tehtud veaotsingu seansiga. Esimene käsk, mida peaaegu kõik käivitavad, on !analüüsima, mis käivitab automaatse analüüsi ja genereerib esialgse aruande.

Käsk !analyze -show näitab veakontrolli kood ja selle parameetridKuigi !analyze -v See annab palju detailsema väljundi: kahtlase mooduli, väljakutsete pinu, kontekstuaalse teabe ja paljudel juhtudel ka soovitused võimalike põhjuste või diagnostiliste sammude kohta.

Selle analüüsi täiendamiseks käsk .bugcheck See prindib uuesti veakoodi ja sellega seotud parameetrid, mida saab seejärel võrrelda veakontrolli koodi viide Microsoftilt, et saada teada iga väärtuse täpne tähendus ja tüüpilised põhjused.

Käsk lm N T (moodulite loend) võimaldab teil näha Laaditud moodulite loend koos nende tee, aadresside ja olekugaSee aitab kinnitada, kas automaatse analüüsi abil tuvastatud draiver on tegelikult mälus ja milline on selle versioon. See loend on eriti kasulik, kui kahtlustame kolmanda osapoole draivereid või turvakomponente, mis kerneliga suhtlevad.

Soovi korral saame prügimäe laadimise protsessi lihtsustada, luues a partiifail See peaks saama tee prügimäele ja käivitama KD või WinDbg sobivate parameetritega. Nii pead kirjutama vaid lühikese käsu, mis sisaldab faili asukohta, ja skript hoolitseb kõige muu eest.

WinDbg kasutamine sügavate kerneli prügimägede jaoks

Kerneli režiimi mälutõmmiste puhul pakub WinDbg ka võimalust töötada mitme faili ja seansiga. Mälutõmmiseid saab avada käsurealt käsuga -zvõi graafilise liidese kaudu menüükäsuga Fail > Ava mälutõmmis või kiirklahviga Ctrl + D.

Kui WinDbg on juba passiivses režiimis avatud, valige lihtsalt fail dialoogiboksis „Ava krahhi mälutõmmis”, määrates tee või sirvides ketast. Pärast laadimist saame seansi alustada käsuga g (Mine) teatud stsenaariumides või käivitada otse esimesed analüüsikäsud.

Lisaks klassikale !analyzeSoovitav on tutvuda siluri käskude viiteosaSee kirjeldab kõiki saadaolevaid käske sisemiste struktuuride lugemiseks, mälu uurimiseks, pinude tõlgendamiseks ja paljuks muuks. Paljusid neist tehnikatest saab rakendada nii reaalajas seansside kui ka võrguühenduseta prügimägede puhul.

WinDbg võimaldab teil töötada ka mitu paralleelset prügimägeKäsureale saame lisada mitu -z parameetrit, millele järgneb igaühele erinev failinimi, või lisada uusi sihtmärke käsuga .opendumpMitme sihtkoha silumine on kasulik korduvate tõrgete või aheldatud intsidentide võrdlemiseks.

Mõnes keskkonnas pakitakse mälutõmmised CAB-failidesse ruumi kokkuhoiuks või edastamise hõlbustamiseks. WinDbg saab otse avada .cab koos sees oleva prügimäega, kasutades nii -z kui ka koos .opendumpkuigi ta loeb See ekstraheerib ainult ühe tühjendatud failidest ja ei ekstraheeri teisi faile. mis võiks samasse paketti minna.

Unixis ja Linuxis tehtud krahhitõmmised: utiliit, tööriistad ja nõuded

Unixi ja GNU/Linuxi süsteemides on filosoofia sarnane, kuid tööriistade ökosüsteem erineb märkimisväärselt. Enamik Unixi-laadseid kerneleid pakub võimalust salvestage mälu koopia katastroofilise sündmuse korral, mida me teame kui põhitõmmis või kerneli krahhi prügimägi.

Kuigi nende peamine kasutusala on endiselt kerneli ja draiverite arendamine, on neil selge turvaaspekt. Krahhi võib põhjustada programmeerimisvigu, aga ka pahatahtlikke tegevusi ebaõnnestunud katsed süsteemi komponente manipuleerida või kohmakalt ära kasutada võistlustingimusi.

Hästi konfigureeritud Unixi süsteemis pole igapäevased krahhid tavalised, kuid kui need siiski juhtuvad, on tark omada varuplaani. prügimäe infrastruktuur, näiteks Kdump, LKCD või muud lahendused mis võimaldavad süsteemimälu jäädvustada. Siiski on vaja kaaluda nii mälutõmmise diagnostilist väärtust kui ka ohtu, et see sisaldab väga tundlikke andmeid.

Üks kõige täielikumaid ja levinumaid tööriistu seda tüüpi analüüsiks Linuxis on krahhAlgselt Red Hati poolt välja töötatud utiliidist on saanud tuuma prügimägede uurimise ja töötavate süsteemide analüüsimise de facto standard.

Krahh võib süsteemi reaalajas mälu vastu töötada järgmiste toimingute kaudu: /dev/mem või Red Hati ja tuletatud distributsioonides, kasutades konkreetset seadet /dev/crashSellegipoolest on tavaks tööriistale varustada mälutõmmise fail, mille on genereerinud sellised mehhanismid nagu Kdump, makedumpfile, Diskdump või arhitektuuripõhised prügimäed, näiteks s390/s390x või xendump virtualiseeritud keskkondades.

Krahhi roll ja vmlinuxi tähtsus Linuxis

Krahhi utiliit loodi osaliselt selleks, et ületada kasutamise piirangud gdb otse peal /proc/kcoreMuuhulgas võib juurdepääs sellele mälu pseudokujutisele olla piiratud ja lisaks raskendavad teatud kerneli kompileerimisvalikud sisemiste struktuuride korrektset tõlgendamist, kui meil on ainult tihendatud käivitatav binaarfail.

Selleks, et krahh toimiks korrektselt, on vajalikud kaks põhielementi: a vmlinux fail kompileeritud silumissümbolitega (tavaliselt lippudega nagu -g) ja kerneli mälutõmmis ise. See kombinatsioon võimaldab tööriistal kaardistada mäluaadresse funktsioonide, struktuuride ja koodiridadega.

Oluline on vahet teha vmlinux ja vmlinuzEnamikus süsteemides on nähtav ainult vmlinux, mis on kerneli tihendatud ja käivitatav versioon. Krahhi korral on vaja sümboolselt lahti pakitud vmlinuxit; ilma selleta, näiteks mälutõmmise laadimisel või /dev/mem Me kohtame tüüpi vigu Käivitatavat kerneli ei leitud — palun sisestage namelist argument.

Kuigi vmlinuzi käsitsi lahtipakkimine on võimalik, pole see protsess alati lihtne ja praktikas on see tavaliselt palju mugavam. Kompileeri kernel uuesti, et saada nii vmlinux kui ka vmlinuz paralleelselt. Tõsistes halduskeskkondades on hea tava säilitada igale nendel juhtudel juurutatud kerneli versioonile vastav vmlinux.

Kui nõuded on täidetud, on prügimäe krahhi tegemine suhteliselt lihtne: määrate sobiva vmlinuxi ja prügimäefaili ning tööriist avab interaktiivse seansi, kust saate läbida kerneli struktuure, loetleda protsesse, vaadata väljakutsete pinu ja hankida kohtuekspertiisi teavetNeed, kes soovivad veelgi sügavamale minna, saavad tutvuda spetsiaalse dokumentatsiooniga, näiteks tuntud tehnilise krahhi valge raamatuga.

/dev/mem piirangud ja esimesed lähenemisviisid Linuxis

Enne konkreetsete tööriistade kasutamist on paljud administraatorid ajalooliselt püüdnud mälutõmmist hankida. otse seadmest lugemine /dev/memSee lähenemisviis tundus lihtne: kasutage tööriista nagu mälutõmmis (mis saadab seadme standardväljundisse) või tõmbab selle välja dd if=/dev/mem of=volcado.mem.

Kuid tänapäevased tuumad pakuvad kompileerimisvõimalusi, näiteks CONFIG_STRICT_DEVMEMmis piirab oluliselt juurdepääsu kasutajaruumist /dev/memTüüpiline tulemus on see, et lugemine katkeb pärast väikest plokki (nt 1 MB) või halvimal juhul võib selle interaktsiooni viga lõppeda ... tuuma paanika kohene ja masina taaskäivitamine.

See kaitse on turvalisuse seisukohast täiesti mõistlik, kuid see sunnib meid otsima Muud viisid usaldusväärse ja täieliku prügimäe saamiseks ilma et see täielikult lootma hakkaks geneerilistele seadmetele, mis pole enam nii ligipääsetavad kui varem.

Seega on praegune trend toetuda spetsiifilistele moodulitele või integreeritud krahhitõmmiste infrastruktuurile, selle asemel, et lihtsalt proovida mälu "kraapida" kasutajaruumi tööriistadega, mis ei ole loodud kaasaegsete kerneli kaitsepoliitikatega koos eksisteerima.

LiME kohtuekspertiis: mälu ekstraheerimine Linuxis ja Androidis

Kohtuekspertiisi maailmas on väga võimas alternatiiv LiME (Linuxi mäluekstraktor)LiME on kerneli moodul, mis on spetsiaalselt loodud volatiilse mälu kontrollitud viisil ja ilma /dev/mem kausta mõjutavate piiranguteta jäädvustamiseks. LiME töötab kerneli ruumis, seega pääseb see RAM-ile palju otsesemalt ligi.

LiME levitatakse koos lähtekoodiga ja kompileeritakse selle vastu. kasutusel olevad kerneli päisedKompileerimisprotsess genereerib mooduli .ko spetsiifiline kerneli versioonile, kuhu see laaditakse. Pärast kompileerimist saame seda kontrollida selliste tööriistadega nagu file et veenduda meie arhitektuurile vastava ELF-mooduli korrektses genereerimises.

LiME kasutamiseks laadige moodul lihtsalt insmod root'ilt ja edastage sellele sobivad valikud, näiteks määrates a võrgu prügimäe sihtkoht TCP ja toorvormingu abil:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

Paralleelselt kuulame prügimäe vastuvõtval masinal konfigureeritud porti, kasutades sellist tööriista nagu ncväljundi ümbersuunamine faili:

nc <IP_origen> 4444 > volcado.mem

Mõne minuti pärast, olenevalt muutmälu hulgast ja võrgu jõudlusest, on meil fail, mille suurus vastab lähtekoodisüsteemi füüsilisele mälule. See on täielik RAM-i mälutõmmis, mida saame analüüsida kohtuekspertiisi tööriistade või isegi stringide või muude utiliitidega esimese sammuna huvitavate kettide leidmiseks.

Protsessi prügimäed ja andmetega kokkupuute riskid

Täielik kerneli mälutõmmis on äärmiselt informatiivne, kuid see võib olla ka liigne, kui meid huvitab ainult konkreetne protsess. Sellisel juhul on väga mõistlik pöörduda ... poole. üksikute protsesside prügimäed kasutades selliseid tööriistu nagu gcore Unixis/Linuxis.

Need protsessipõhised prügimäed on palju väiksemad ja paremini hallatavad ning võimaldavad teil analüüsi suunata konkreetsetele rakendustele, näiteks sõnumsidekliendile (näiteks Skype) või e-posti kliendile (näiteks Thunderbird), kus on suhteliselt lihtne leida. paroolid lihttekstina, seansi tunnustena või kontaktandmetena kui mälustringe uuritakse.

Arendaja seisukohast aitavad need põhiväljavõtted leida programmeerimisvigu, mälulekkeid või ebajärjekindlaid olekuid teenuses. Kuid turvalisuse seisukohast tekib probleem siis, kui Prügimähiseid genereeritakse rutiinselt ja need salvestatakse teistele kasutajatele ligipääsetavatesse kohtadesse.kas süsteemis endas või jagatud võrguressurssides.

Kui kasutaja näiteks ajastab ülesande cron Tundlike protsesside perioodiliste andmete jäädvustamise ja nende globaalselt loetavasse kataloogi jätmisega avab ründaja tohutu ukse kriitilise teabe avalikustamiseks. Paljudes auditistsenaariumides võimaldab nende failide analüüsimine ründajal taastada volitused, kontaktide nimekirjad, suhtlusajalugu ja muud privaatsed andmed suhteliselt väikese pingutusega.

Seetõttu on iga tõsise Unixi süsteemi auditi puhul soovitatav pühendada paar minutit sellele, et kontrollida, kas genereeritakse (täielikke või osalisi) prügimägesid, kus neid hoitakse, millised õigused neil on ja kas neid on. automatiseeritud protsess, mis jätab mälukoopiad volitamata kasutajatele kättesaadavaks.

FreeBSD-s tehtud prügimägede lahkamine kgdb abil

BSD maailmas ja eriti FreeBSD-s hõlmab post mortem analüüsi lähenemisviis järgmist: Luba süsteemis krahhitõmmised ja lase kernelil kompileerida silumissümbolitegaSeda juhitakse kerneli konfiguratsioonikataloogist, mis tavaliselt asub /usr/src/sys/<arq>/conf.

Vastavas konfiguratsioonifailis saab sümbolite genereerimise lubada sellise reaga:

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

Pärast konfiguratsiooni muutmist tuleb kernel uuesti kompileerida. Mõned objektid genereeritakse uuesti (näiteks trap.o) ehitusfailide muutmise tõttu. Eesmärk on saada kernel, millel on sama kood kui see, millel on probleeme, aga lisades vajaliku silumisteabeSoovitav on võrrelda vanu ja uusi suurusi käsuga size veendumaks, et binaarfailis pole toimunud ootamatuid muutusi.

Kui kernel on sümbolite abil installitud, saame nüüd prügimägesid uurida kgdb nagu ametlikus dokumentatsioonis kirjeldatud. Kõik sümbolid ei pruugi olla täielikud ja mõned funktsioonid võivad ilmuda ilma reanumbrite või argumentideta, kuid enamasti on detailsuse tase probleemi jälgimiseks piisav.

Puudub absoluutne garantii, et analüüs lahendab kõik intsidendid, kuid praktikas... See strateegia toimib üsna hästi suure osa stsenaariumide puhuleriti kui krahhiandmete kogumisele lisandub hiljutiste süsteemimuudatuste hea ülevaade.

Kerneli vigade analüüsimise ja dokumenteerimise parimad tavad

Olenemata operatsioonisüsteemist, kerneli prügimäe analüüs viib tavaliselt järgmise tulemuseni: tehniline dokumentatsioon, teadmusbaasid, erialafoorumid või isegi kerneli lähtekood ise sõnumite, veakoodide ja tundmatute sümbolite tõlgendamiseks.

Linuxis on väga kasulik toetuda ametlikule lähtekoodipuule, sisseehitatud dokumentatsioonile ja kogukonna ressurssidele. Paljud kerneli veateated on pärit täpsest failist, kust need pärinevad, mis aitab probleemi mõista. kontekst, milles BUG() või WARN() käivitatakse määratud.

Windowsi puhul pakuvad Microsofti dokumentatsioon, teadmusbaas (KB) ja tehnilised foorumid üksikasjalikke selgitusi veakontrolli koodid, lahendussoovitused ja teadaolevad veamustridSelle teabe kombineerimisel !analyze -v aruannetega on võimalik koostada mõistlik leevendusplaan.

Krahhiväljavõtte tegelik väärtus ilmneb siis, kui kogu see teave on omavahel ristviidetega võrreldav. põhjalikud teadmised operatsioonisüsteemist ja konkreetsest keskkonnast, kus tõrge tekkisAinult nii saab pakkuda püsivaid lahendusi ja ennekõike vältida sama probleemi kordumist tulevikus tõsisemate tagajärgedega.

Kerneli mälutõmmiste analüüs on lõppkokkuvõttes teaduse ja oskusteabe segu: see nõuab sobivaid tööriistu, eelnevat konfigureerimist (sümbolid, mälutõmmise valikud, turvaline salvestusruum) ja palju kogemusi pinude, struktuuride ja veakoodide lugemisel. Nende tehnikate valdamine võimaldab teil mitte ainult keerulisi intsidente siluda, vaid ka et oluliselt suurendada meie hallatavate süsteemide turvalisuse ja vastupidavuse taset.