Puncte:0

Fișierul piratat se regenerează ori de câte ori este șters - ubuntu/apache2

drapel ph

Tocmai am avut un site piratat semnalat de Sucuri

Au fost semnalate o serie de fișiere PHP de tip backdoor, pe care AM reușit să le șterg

Cu toate acestea, fișierul index.php are un link de spam injectat în partea de jos a acestuia.

Am încercat să-l șterg - ceea ce FUNcționează, dar fișierul se regenerează instantaneu.

Am încercat să schimb permisiunile (este setat la -rw-r--r-- www-data:www-data) pentru a roota și edita fișierul - se schimbă instantaneu la permisiunile de mai sus la salvare, iar editarea mea este plecat

Sucuri semnalează acum site-ul ca curat, adică nu mai este prezentă ușa din spate, DAR în mod evident există ceva acolo care încă face asta.

Serverul are și o mulțime de alte site-uri pe el și niciunul dintre acestea nu este compromis (oricum, evident) - și așa pare să fie ceva responsabil în folderul acestui site specific.

Există o modalitate de a monitoriza CE manipulează fișierul index.php pentru a urmări de unde este generată problema? Alte idei? (Altul decât să încep din nou de la zero, ceea ce POT să fac, dar nu ușor).

Orice contribuție binevenită - mulțumesc!

drapel ph
Nu sunt sigur cine a închis acest lucru, dar nu sunt de acord că acesta este un duplicat. Sunt conștient că există un proces pentru a trata un server compromis, dar pun o întrebare specifică despre cum să identific ce fișier modifică acest fișier - care este un lucru separat și nu cred că ajuți pe altcineva care ar putea experimentați această problemă doar închizându-se ca duplicat
John Mahowald avatar
drapel cn
Mulți de pe Server Fault nu vor atinge întrebările de sistem compromise și au păreri puternice că singurul răspuns este instalarea curată a software-ului cunoscut bun, restaurarea copiei de rezervă și schimbarea tuturor parolelor. Mai ales când nu este clar, ați investigat pe deplin cum ar putea persista amenințările. Poate discutați despre meta Server Fault?
drapel us
Problema cu căutarea sursei modificărilor este că malware-ul ascunde lucrurile în mai multe moduri. Nu puteți fi sigur că sistemul dumneavoastră este curat în alt mod decât reinstalarea din starea curată. Orice altă acțiune nu este profesională și, prin urmare, este offtopic pentru acest site.
Puncte:1
drapel in

Cu un indicator de acces 644, scrierea vine din contul de utilizator, să zicem apache. Poate că poți juca un truc pe APT-ul ascuns.

Fă mișcarea nebună de a da acest fișier 406 (r-----wr-) permisiunea și folosiți un cont de la alții grup pentru a edita fișierul. Dacă schimbarea rămâne, auditarea accesului la fișiere de configurare, reveniți la permisiunile la 644 și vedeți.

Dacă fișierul se modifică în ciuda permisiunilor 406, APT-ul dvs. are probabil acces root și ar trebui să începeți reconstrucția. Nu mai este serverul tău.

Mult succes si felicitari pentru curatenia facuta pana acum...

drapel ph
Mulțumesc - link-ul de auditare a accesului la fișier a fost de mare ajutor... Deci, folosind acest lucru, pot vedea că este usr/sbin/apache2 care actualizează fișierul înapoi la starea sa anterioară după ce îl editez. Dintr-un capriciu am oprit apache și APOI am editat fișierul - și nu a fost suprascris, chiar și după repornirea apache. Deci spam-ul a dispărut, dar nu sunt sigur unde pot căuta în jurnalele Apache pentru a afla exact CE fișier folosea apache pentru a-l suprascrie?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.