Slik avdekker du skjulte Linux-prosesser med Unhide

How Uncover Hidden Linux Processes With Unhide

Mens GNU / Linux er et ekstremt sikkert operativsystem, blir mange lokket inn i en falsk følelse av sikkerhet. De har feil ideer om at ingenting noensinne kan skje fordi de jobber i et sikkert miljø. Det er sant at det finnes svært lite skadelig programvare for Linux-miljøet, men det er fortsatt veldig mulig at en Linux-installasjon til slutt kan bli kompromittert. Hvis ikke annet, er det å vurdere muligheten for rootkits og andre lignende angrep en viktig del av systemadministrasjonen. Et rootkit refererer til et sett med verktøy tredjepartsbrukere etter at de får tilgang til et datasystem de ikke med rette har tilgang til. Dette settet kan deretter brukes til å endre filer uten kjennskap til rettmessige brukere. Den skjulte pakken gir den teknologien som trengs for raskt å finne slik kompromittert programvare.

Unhide er i repositoriene for de fleste av de store Linux-distribusjonene. Bruk av en pakkehåndteringskommando som sudo apt-get install unhide er nok til å tvinge den til å installere på smaker av Debian og Ubuntu. Servere med GUI-tilgang kan bruke Synaptic Package Manager. Fedora- og Arch-distribusjoner har forhåndsbygde versjoner av unhide for sine egne pakkehåndteringssystemer. Når unhide er installert, bør systemadministratorer kunne bruke det på flere forskjellige måter.



Metode 1: Bruteforcing prosess-IDer

Den mest grunnleggende teknikken innebærer å bryte hver prosess-ID for å sikre at ingen av dem har blitt skjult for brukeren. Med mindre du har root-tilgang, skriv sudo unhide brute -d ved CLI-ledeteksten. Alternativet d dobler testen for å redusere antall rapporterte falske positive.



Output er ekstremt grunnleggende. Etter en opphavsrettsmelding vil skjulingen forklare kontrollene den utfører. Det kommer en linje som sier:



[*] Starter skanning med brute force mot PIDS med gaffel ()

og en annen som sier:

[*] Starter skanning med brute force mot PIDS med pthread-funksjoner



Hvis det ikke er noe annet resultat, er det ingen grunn til bekymring. Hvis programmets brutale underrutine finner noe, vil det rapportere noe sånt som:

Fant HIDDEN PID: 0000

De fire nullene vil bli erstattet med et gyldig nummer. Hvis det bare leser at det er en midlertidig prosess, kan dette være falskt positivt. Kjør gjerne testen flere ganger til den gir et rent resultat. Hvis det er ytterligere informasjon, kan det kreve en oppfølgingskontroll. Hvis du trenger en logg, kan du bruke -f-bryteren til å opprette en loggfil i gjeldende katalog. Nyere versjoner av programmet kaller denne filen unhide-linux.log, og den har vanlig tekstutdata.

Metode 2: Sammenligning / proc og / bin / ps

Du kan i stedet dirigere visningen for å sammenligne / bin / ps og / proc-prosesslistene for å sikre at disse to separate listene i Unix-filtreet stemmer overens. Hvis det er noe galt, vil programmet rapportere den uvanlige PID. Unix-regler fastslår at kjørende prosesser må presentere ID-nummer i disse to listene. Skriv inn sudo unhide proc -v for å starte testen. Å slå på v vil sette programmet i detaljert modus.

Denne metoden vil returnere en melding om:

[*] Søker etter skjulte prosesser gjennom / proc stat scanning

Skulle noe uvanlig oppstå, vil det vises etter denne tekstlinjen.

Metode 3: Kombinere Proc og Procfs-teknikken

Hvis det er behov for det, kan du faktisk sammenligne / bin / ps og / proc Unix filtrelister samtidig som du også sammenligner all informasjon fra / bin / ps-listen med de virtuelle procfs-oppføringene. Dette sjekker både Unix-filtrereglene og anbringer data. Skriv sudo unhide procall -v for å utføre denne testen, noe som kan ta ganske lang tid, da det må skanne all / proc-statistikk, samt gjøre flere andre tester. Det er en utmerket måte å sørge for at alt på en server er kopasetisk.

2016-11-02_222832

Metode 4: Sammenligning av procfs-resultater med / bin / ps

De forrige testene er for involvert for de fleste applikasjoner, men du kan kjøre proc-filsystemkontrollene uavhengig for litt formål. Skriv sudo unhide procfs -m, som vil utføre disse kontrollene pluss flere flere kontroller levert av tacking på -m.

Dette er fremdeles en ganske involvert test, og kan ta et øyeblikk. Den returnerer tre separate linjer for utdata:

2016-11-02_223011

Husk at du kan opprette en full logg med noen av disse testene ved å legge til -f til kommandoen.

Metode 5: Kjøre en hurtigskanning

Hvis du bare trenger å kjøre en rask skanning uten å gjøre deg grundige sjekker, skriv bare sudo unhide quick, som skal kjøre så raskt som navnet antyder. Denne teknikken skanner både proc-lister og proc-filsystemet. Det kjører også en sjekk som involverer sammenligning av informasjon samlet fra / bin / ps med informasjon gitt av anrop til systemressurser. Dette gir en enkelt produksjonslinje, men øker dessverre risikoen for falske positive. Det er nyttig å dobbeltsjekke etter at du allerede har gjennomgått tidligere resultater.

Resultatet er som følger:

[*] Søke etter skjulte prosesser gjennom sammenligning av resultatene av systemanrop, proc, dir og ps

Det kan hende at du ser flere forbigående prosesser som kommer etter at du har kjørt denne skanningen.

Metode 6: Kjøre en omvendt skanning

En utmerket teknikk for å snuse ut rootkits innebærer verifisering av alle ps-tråder. Hvis du kjører ps-kommandoen ved en CLI-ledetekst, kan du se en liste over kommandokjøring fra en terminal. Omvendt skanning verifiserer at hver av prosessorens tråder som ps-bilder viser gyldige systemanrop og kan slås opp i procfs-oppføringen. Dette er en fin måte å sikre at et rootkit ikke har drept noe. Bare skriv sudo unhide reverse for å kjøre denne sjekken. Det skal løpe ekstremt raskt. Når det kjører, bør programmet varsle deg om at det leter etter falske prosesser.

Metode 7: Sammenligning / bin / ps med systemanrop

Endelig innebærer den mest omfattende kontrollen å sammenligne all informasjon fra / bin / ps-oppføringen med informasjon hentet fra gyldige systemanrop. Skriv inn sudo unhide sys for å starte denne testen. Det vil mer enn sannsynlig ta lengre tid å løpe enn de andre. Siden den gir så mange forskjellige linjer, kan det være lurt å bruke kommandoen -f logg til fil for å gjøre det lettere å se tilbake på alt den fant.

4 minutter lest