Sådan afdækkes skjulte Linux-processer med Unhide

Mens GNU / Linux er et ekstremt sikkert operativsystem, bliver mange mennesker lokket ind i en falsk følelse af sikkerhed. De har den forkerte idé om, at intet nogensinde kan ske, fordi de arbejder i et sikkert miljø. Det er rigtigt, at der findes meget lidt malware til Linux-miljøet, men det er stadig meget muligt, at en Linux-installation i sidste ende kan blive kompromitteret. Hvis ikke andet, så er det en vigtig del af systemadministrationen at overveje muligheden for rootkits og andre lignende angreb. Et rootkit refererer til et sæt værktøjer, som en tredjepartsbrugere har, efter at de får adgang til et computersystem, de ikke med rette har adgang til. Dette sæt kan derefter bruges til at ændre filer uden kendskab til de retmæssige brugere. Den skjulte pakke giver den nødvendige teknologi til hurtigt at finde sådan kompromitteret software.

Unhide er i repositories for de fleste af de store Linux-distributioner. Brug af en pakkehåndteringskommando som sudo apt-get install unhide er nok til at tvinge den til at installere på varianter af Debian og Ubuntu. Servere med GUI-adgang kunne bruge Synaptic Package Manager. Fedora- og Arch-distributioner har forudbyggede versioner af unhide til deres egne pakkehåndteringssystemer. Når unhide er installeret, skal systemadministratorer være i stand til at bruge det på flere forskellige måder.

Metode 1: Bruteforcing proces-id'er

Den mest basale teknik involverer brutalisering af hvert proces-id for at sikre, at ingen af ​​dem er skjult for brugeren. Medmindre du har rodadgang, skal du skrive sudo unhide brute -d ved CLI-prompten. D-indstillingen fordobler testen for at reducere antallet af rapporterede falske positive.

Output er ekstremt grundlæggende. Efter en ophavsretsmeddelelse forklarer skjulingen, hvilke kontroller den udfører. Der vil være en linje, der siger:

og en anden angiver:

Hvis der ikke er noget andet output, er der ingen grund til bekymring. Hvis programmets brutale subrutine finder noget, rapporterer det noget som:

Fundet HIDDEN PID: 0000

De fire nuller erstattes med et gyldigt tal. Hvis det blot læser, at det er en midlertidig proces, kan dette være en falsk positiv. Du er velkommen til at køre testen flere gange, indtil den giver et rent resultat. Hvis der er yderligere oplysninger, kan det muligvis berettige en opfølgningskontrol. Hvis du har brug for en log, kan du bruge -f-kontakten til at oprette en logfil i det aktuelle bibliotek. Nyere versioner af programmet kalder denne fil unhide-linux.log, og den har almindelig tekstoutput.

Metode 2: Sammenligning / proc og / bin / ps

Du kan i stedet direkte vise for at sammenligne / bin / ps og / proc-proceslisterne for at sikre, at disse to separate lister i Unix-filtræet matcher. Hvis der er noget galt, rapporterer programmet den usædvanlige PID. Unix-regler bestemmer, at kørende processer skal præsentere ID-numre på disse to lister. Skriv sudo unhide proc -v for at starte testen. Hvis du klikker på v, sættes programmet i detaljeret tilstand.

Denne metode returnerer en prompt med angivelse af:

Skulle noget usædvanligt forekomme, vises det efter denne tekstlinje.

Metode 3: Kombination af Proc og Procfs-teknikker

Hvis det er nødvendigt, kan du faktisk sammenligne / bin / ps og / proc Unix filtrelisterne, mens du også sammenligner al information fra / bin / ps-listen med de virtuelle procfs-poster. Dette kontrollerer både Unix-filtræets regler såvel som at proffere data. Skriv sudo unhide procall -v for at udføre denne test, hvilket kan tage nogen tid, da det skal scanne alle / proc-statistikker samt udføre flere andre tests. Det er en fremragende måde at sikre, at alt på en server er kopasetisk.

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

De tidligere tests er for involverede til de fleste applikationer, men du kan køre proc-filsystemkontrollerne uafhængigt for noget formål. Skriv sudo unhide procfs -m, som udfører disse kontroller plus flere flere kontroller leveret af tackling på -m.

Dette er stadig en temmelig involveret test og kan tage et øjeblik. Det returnerer tre separate linjer med output:

Husk at du kan oprette en fuld log med en af ​​disse tests ved at tilføje -f til kommandoen.

Metode 5: Kørsel af en hurtig scanning

Hvis du blot har brug for at køre en hurtig scanning uden at beskæftige dig med dybdegående kontrol, skal du blot skrive sudo unhide quick, hvilket skal køre så hurtigt som navnet antyder. Denne teknik scanner proc-lister såvel som proc-filsystemet. Det kører også en kontrol, der involverer sammenligning af information indsamlet fra / bin / ps med information leveret af opkald til systemressourcer. Dette giver en enkelt linje med output, men øger desværre risikoen for falske positive. Det er nyttigt at dobbelttjekke efter allerede gennemgang af tidligere resultater.

Output er som følger:

Du kan muligvis se flere midlertidige processer komme op efter at have kørt denne scanning.

Metode 6: Kørsel af en omvendt scanning

En fremragende teknik til at snuse rodkits indebærer verifikation af alle ps-tråde. Hvis du kører ps-kommandoen ved en CLI-prompt, kan du se en liste over kommandokørsel fra en terminal. Omvendt scanning bekræfter, at hver af processortrådene, som ps-billeder udviser gyldige systemopkald, og kan slås op i procfs-listen. Dette er en fantastisk måde at sikre, at et rootkit ikke har dræbt noget. Du skal blot skrive sudo unhide reverse for at køre denne kontrol. Det skal køre ekstremt hurtigt. Når det kører, skal programmet underrette dig om, at det leder efter falske processer.

Metode 7: Sammenligning / bin / ps med systemopkald

Endelig involverer den mest omfattende kontrol at sammenligne al information fra / bin / ps-listen med oplysninger taget fra gyldige systemopkald. Skriv sudo unhide sys for at starte denne test. Det vil mere end sandsynligt tage længere tid at løbe end de andre. Da det giver så mange forskellige linjer med output, kan det være en god idé at bruge kommandoen -f log-til-fil for at gøre det lettere at se tilbage på alt, hvad den fandt.