Hur man avslöjar dolda Linux-processer med Unhide



Prova Vårt Instrument För Att Eliminera Problem

GNU / Linux är ett extremt säkert operativsystem, men många lockas till en falsk känsla av säkerhet. De har fel idé att ingenting någonsin kan hända eftersom de arbetar i en säker miljö. Det är sant att det finns mycket lite skadlig programvara för Linux-miljön, men det är fortfarande mycket möjligt att en Linux-installation i slutändan kan äventyras. Om inget annat är det en viktig del av systemadministrationen att överväga möjligheten till rootkits och andra liknande attacker. En rootkit hänvisar till en uppsättning verktyg som tredjepartsanvändare efter att de får tillgång till ett datorsystem som de inte har rätt till. Detta kit kan sedan användas för att modifiera filer utan kunskap från rättmätiga användare. Dölj paketet ger den teknik som behövs för att snabbt hitta sådan komprometterad programvara.



Unhide finns i förvaret för de flesta av de större Linux-distributionerna. Användning av ett pakethanterarkommando som sudo apt-get install unhide räcker för att tvinga det att installera på smaker från Debian och Ubuntu. Servrar med GUI-åtkomst kan använda Synaptic Package Manager. Fedora- och Arch-distributioner har förbyggda versioner av unhide för sina egna pakethanteringssystem. När unhide har installerats bör systemadministratörer kunna använda det på flera olika sätt.



Metod 1: Bruteforcing-process-ID

Den mest grundläggande tekniken innebär att man tvingar varje process-ID att se till att ingen av dem har döljts för användaren. Om du inte har rootåtkomst skriver du sudo unhide brute -d vid CLI-prompten. Alternativet d fördubblar testet för att minska antalet rapporterade falska positiva resultat.



Output är extremt grundläggande. Efter ett meddelande om upphovsrätt kommer förklaring att förklara vilka kontroller det utför. Det kommer att finnas en rad som säger:

[*] Börja skanna med brute force mot PIDS med gaffel ()

och en annan som säger:



[*] Börja skanna med brute force mot PIDS med pthread-funktioner

Om det inte finns någon annan utgång finns det ingen anledning till oro. Om programmets brutala subrutin hittar något, rapporterar det något som:

Hittade HIDDEN PID: 0000

De fyra nollarna skulle ersättas med ett giltigt nummer. Om det bara läser att det är en övergående process kan det vara falskt positivt. Kör gärna testet flera gånger tills det ger ett rent resultat. Om det finns ytterligare information kan det kräva en uppföljningskontroll. Om du behöver en logg kan du använda -f-omkopplaren för att skapa en loggfil i den aktuella katalogen. Nyare versioner av programmet kallar denna fil unhide-linux.log, och den har enkel textutmatning.

Metod 2: Jämföra / proc och / bin / ps

Du kan istället dirigera bort för att jämföra processerna / bin / ps och / proc för att säkerställa att dessa två separata listor i Unix-filträdet matchar. Om det är något fel kommer programmet att rapportera den ovanliga PID. Unix-regler anger att körningsprocesser måste presentera ID-nummer i dessa två listor. Skriv sudo unhide proc -v för att starta testet. Att slå på v kommer att sätta programmet i ett ordentligt läge.

Denna metod kommer att returnera en uppmaning om:

[*] Söker efter dolda processer genom / proc stat scanning

Om något ovanligt skulle inträffa skulle det visas efter denna textrad.

Metod 3: Kombinera Proc och Procfs-tekniken

Om det behövs kan du faktiskt jämföra filerna / bin / ps och / proc Unix-filträdet samtidigt som du också jämför all information från listan / bin / ps med de virtuella procfs-posterna. Detta kontrollerar såväl Unix-filtrets regler som proffs-data. Skriv sudo unhide procall -v för att utföra detta test, vilket kan ta ganska lång tid eftersom det måste skanna all / proc-statistik samt göra flera andra tester. Det är ett utmärkt sätt att se till att allt på en server är kopasetiskt.

2016-11-02_222832

Metod 4: Jämföra procfs-resultat med / bin / ps

De tidigare testerna är för involverade för de flesta applikationer, men du kan köra proc-filsystemskontrollerna oberoende för att det är lämpligt. Skriv sudo unhide procfs -m, som kommer att utföra dessa kontroller plus flera fler kontroller som tillhandahålls genom att tackla på -m.

Detta är fortfarande ett ganska involverat test och kan ta en stund. Det returnerar tre separata utgångsrader:

2016-11-02_223011

Tänk på att du kan skapa en fullständig logg med någon av dessa tester genom att lägga till -f till kommandot.

Metod 5: Köra en snabbsökning

Om du bara behöver köra en snabbsökning utan att göra dig djupgående kontroller, skriv bara sudo unhide quick, vilket ska köras så snabbt som namnet antyder. Denna teknik skannar proc-listor såväl som proc-filsystemet. Det kör också en kontroll som innefattar att jämföra information som samlats in från / bin / ps med information som tillhandahålls av samtal till systemresurser. Detta ger en enda produktionsrad, men ökar tyvärr risken för falska positiva effekter. Det är användbart att dubbelkontrollera efter att ha granskat tidigare resultat.

Resultatet är som följer:

[*] Söka efter dolda processer genom jämförelse av resultaten av systemanrop, proc, dir och ps

Du kan se att flera övergående processer kommer upp efter att ha skannat.

Metod 6: Köra en omvänd skanning

En utmärkt teknik för att sniffa ut rootkits innebär verifiering av alla ps-trådar. Om du kör ps-kommandot vid en CLI-prompt kan du se en lista över kommandokörningar från en terminal. Omvänd skanning verifierar att var och en av processortrådarna att ps-bilder uppvisar giltiga systemanrop och kan letas upp i procfs-listan. Detta är ett utmärkt sätt att säkerställa att ett rootkit inte har dödat något. Skriv bara sudo unhide reverse för att köra den här kontrollen. Det ska gå extremt snabbt. När det körs ska programmet meddela att det letar efter falska processer.

Metod 7: Jämföra / bin / ps med systemanrop

Slutligen innefattar den mest omfattande kontrollen att jämföra all information från / bin / ps-listan med information hämtad från giltiga systemanrop. Skriv sudo unhide sys för att starta detta test. Det kommer mer än troligt att det tar längre tid att springa än de andra. Eftersom det ger så många olika utdata kan du använda kommandot -f log-to-file för att göra det lättare att se igenom allt det hittade.

4 minuter läst