Slik Avdekker Du Skjulte Linux-prosesser Med Unhide

2023 Forfatter: Kayla Nelson | [email protected]. Sist endret: 2023-08-25 08:19

Mens GNU / Linux er et ekstremt sikkert operativsystem, blir mange lokket inn i falsk følelse av sikkerhet. De har feil idet at ingenting noensinne kan skje fordi de jobber i sikre omgivelser. Det er sant at det er veldig lite skadelig programvare for Linux-miljøet, men det er fortsatt veldig mulig at Linux-installasjon til slutt kan bli kompromittert. Hvis ikke noe annet, er det å vurdere muligheten for rootkits og andre lignende angrep en viktig del av systemadministrasjonen. rootkit refererer til sett med verktøy tredjepartsbrukere etter at de får tilgang til datasystemet de ikke med rette har tilgang til. Dette settet kan deretter brukes til å endre filer uten kjennskap til de rettmessige brukerne. 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 pakkehåndteringskommandoer 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. Fedorand 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 å forsere 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 opphavsrettsmeldingen, vil skjul forklare kontrollene den utfører. Det vil være 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 nuller vil bli erstattet med gyldig nummer. Hvis det bare leser at det er en overgangsprosess, kan dette være falskt positivt. Kjør gjerne testen flere ganger til den gir rent resultat. Hvis det er ytterligere informasjon, kan det være berettiget oppfølgingskontroll. Hvis du trenger logg, kan du bruke -f-bryteren til å opprette 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 forutsetter 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 verbose modus.

Denne metoden vil returnere spørsmålet 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, kan du faktisk sammenligne / bin / ps og / proc Unix filtrelister mens 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 å sikre at alt på serveren er kopasetisk.

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 fortsatt ganske involvert test, og kan ta øyeblikk. Det returnerer tre separate linjer for utdata:

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

Metode 5: Kjøre hurtigskanning

Hvis du bare trenger å kjøre hurtigskanning uten å bekymre deg for grundige kontroller, bare skriv inn 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å sjekk som innebærer å sammenligne 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 du ser flere overgangsprosesser som kommer etter at du har kjørt denne skanningen.

Metode 6: Kjøre omvendt skanning

En utmerket teknikk for å snuse ut rootkits innebærer verifisering av alle ps-tråder. Hvis du kjører ps-kommandoen ved CLI-ledetekst, kan du se en liste over kommandokjøring fra 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 flott måte å sikre at 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

Til slutt 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 det gir så mange forskjellige linjer, kan det være lurt å bruke kommandoen -f log-to-file for å gjøre det lettere å se tilbake på alt den fant.