Blogul Devops restabilește serverul după hacking

Refacerea serverului după hacking

Deci, haideți să aruncăm o privire asupra unui exemplu de server care a fost hacked prin descărcarea unui exploit printr-o eroare în scriptul php, lansarea prin el și obținerea accesului la shell-ul cu drepturile serverului web. Acest lucru este elocvent evidențiat prin "urme" în directoarele disponibile pentru scriere pentru toată lumea: / tmp, / var / tmp, / dev / shm.







[anunțul # ad-5]

Hacking-ul ar putea fi evitat în acest stadiu prin instalarea partițiilor pentru fișierele temporare fără dreptul de a rula, dezactivând funcțiile php periculoase și doar un cod mai aprofundat în php. Cu toate acestea, nu sa făcut nimic.
Hackerul nu a pierdut timpul. El a încărcat o varietate de exploite, le-a compilat și după lansare a primit rădăcină de root, folosind unul dintre vulnerabilități.
Și în acest moment, puteți să-l opriți prin dezactivarea wget și compilatoare pentru utilizatorii neprituviți și punerea unui patch care împiedică executarea codului pe stivă sau libsafe. Dar, din păcate, nu sa făcut.
Situația era amestecată. Pe de o parte - date foarte importante, pierderile care sunt critice, pe de altă parte - problema backdor, atunci când un hacker ar putea veni de un utilizator sau prin trimiterea unui anumit set de pachete la daemon care asculta portul. Sa decis restaurarea serverului și monitorizarea acestuia cu atenție.
După ce au deconectat mai multe procese care aveau în mod clar ceva străin sistemului, primul lucru a fost instalat, actualizat și lansat rkhunter - un utilitar pentru vânătoarea de troieni.
Concluzia lui Rkhunter a fost dezamăgitoare - cel puțin două rootkit-uri, multe binare schimbate.
În această situație, un singur lucru vă va ajuta - înlocuind rootkitul infectat cu un rootkit cu unul curat. Cu toate acestea, trebuie să știți ce fișiere binare să le înlocuiți. Dar aici un pic norocos. Hacker-ul a pus atributele pe fișierele modificate care interzic schimbarea, ștergerea sau înlocuirea fișierului cu comanda de chat. Pentru neofitele familiare numai cu chmod, acest lucru ar crea un efect al controlului asupra sistemului de către binarele hacker-infectate nu suprascrie, deși drepturile de a scrie sunt.
După crearea listei de binare infectate, toate atributele au fost restaurate prin comenzi

chattr -iacsuASDd / bin / *
chattr -iacsuASDd / sin / *
chattr -iacsuASDd / sbin / *
chattr -iacsuASDd / usr / sbin / *






chattr -iacsuASDd / usr / bin / *
chattr -iacsuASDd / usr / local / bin / *
chattr -iacsuASDd / usr / local / sbin / *

Cu toate acestea, un număr de binare care nu au fost protejate de schimbare erau încă infectate. Acest lucru a fost demonstrat de rkhunter. Astfel, a devenit clar că este vorba despre un cracare extraordinar care a părăsit în mod special fișierele hackate pentru a le restabili. În consecință, sistemul are un backdor instalat.
De asemenea, un număr de echipe nu au funcționat, deși rkhunter nu a arătat-o. De exemplu, partea de sus nu a afișat un număr de procese prezente în sistem. Aparent, infecția sa produs la nivelul modulului kernel, care a oferit protecție stealth a binarelor infectate.
Cu toate acestea, hackerul nu a prevăzut că în distribuțiile Linux bazate pe rpm există posibilitatea de a afla dacă fișierul a fost modificat sau nu cu rpm.
Procedura este destul de simplă - mai întâi aflăm unde se află binarul suspect, de exemplu:

Această comandă va returna calea completă la utilitarul de sus / usr / bin / top. Acum cu rpm vom afla care pachet aparține acestui fișier:

rpm -qf / usr / bin / top

Această comandă vă va spune că utilitarul de vârf este inclus în pachetul procps. Reinstalați-l utilizând comanda apt:

apt-get -reinstall instala procps

În timpul instalării, a existat un mesaj care susține că topul precedent a fost legat de biblioteca /lib/libext-2.so.7. Poate că asta face parte din mecanismul de stealth. Solicitarea de informații despre bibliotecă cu rpm

rpm -qf /lib/libext-2.so.7

au fost primite informații că dosarul nu face parte din sistem. Firește, a fost șters:

chattr -iacsuASDd / lib / *
rm /lib/libext-2.so.7

Apoi, au fost descoperite mai multe procese ascunse, care au fost ucise cu ajutorul utilității killall.
Firește, a fost necesar să reinstalați nu numai procps, ci și alte pachete suspecte de hacking: util-linux, psmisc, net-tools, kernel, dev, initscripts și multe altele.
După înlocuirea kernelului, serverul a fost repornit și toate fișierele au fost verificate cu ajutorul comenzii

rpm -Va

Au existat indicații indirecte ale unui backdor în sistem. După câteva cercetări asupra sistemului, a fost descoperită backdoor-ul. De asemenea, a fost descoperit că toți utilizatorii sistemului au schimbat shell-ul în / bin / sh. În acest fel, a permis apelarea backdor în numele oricărui utilizator. Pentru a evita o astfel de situație, un număr de servicii nedorite au fost deconectate și un nou utilizator a fost creat, care poate trece prin rețea la shell-ul prin ssh. Restul au fost dezactivate.
În prezent, nu au fost observate încercări de acces neautorizat, ceea ce indică un nivel foarte ridicat al criminalului și refuzul acestuia de a se aprinde.

Acest istoric este descris cu acordul proprietarului serverului hacked. Potrivit lui, tot ce a făcut a fost să adauge suport pentru php în apache. Nici măcar nu era conștient de consecințele acestui lucru.

Fii vigilent! În timpul sărbătorilor de vară, există o mulțime de hacking. Protejați-vă serverul dedicat înainte de a fi hacked. Împiedicați hacking-ul la diferite niveluri. Și cel mai important - verificați periodic conținutul directoarelor pentru fișierele temporare. Este posibil să existe deja ceva acolo.

Fiți atenți mai ales la fișierele care încep cu un punct sau constau doar în spații - aceasta este o dovadă directă a succesului de hacking.







Trimiteți-le prietenilor: