Scripturi javascript rău intenționate. Cum să cauți cod rău intenționat fără antivirusuri și scanere. Cele mai frecvente probleme

Cod rău intenționat ajunge pe site din neglijență sau intenție rău intenționată. Scopurile codului rău intenționat variază, dar în esență provoacă daune sau interferează funcţionare normală site-ul. Pentru a elimina cod rău intenționat pe WordPress trebuie să-l găsiți mai întâi.

Ce este codul rău intenționat pe un site WordPress?

De aspect, cel mai adesea, codul rău intenționat este un set de litere și simboluri ale alfabetului latin. De fapt, acesta este un cod criptat prin care se realizează cutare sau cutare acțiune. Acțiunile pot fi foarte diferite, de exemplu, noile postări sunt publicate imediat pe o resursă terță parte. Acest lucru înseamnă, în esență, să vă furați conținutul. Codurile au și alte „sarcini”, de exemplu, plasarea de link-uri de ieșire pe paginile site-ului. Sarcinile pot fi cele mai sofisticate, dar un lucru este clar: codurile rău intenționate trebuie vânate și eliminate.

Cum ajung codurile rău intenționate pe un site web?

Există, de asemenea, multe lacune pentru ca codurile să intre pe site.

  • Cel mai adesea, acestea sunt teme și pluginuri descărcate din resurse „stânga”. Deși, o astfel de penetrare este tipică pentru așa-numitele legături criptate. Codul explicit nu ajunge pe site.
  • Pătrunderea unui virus atunci când un site este piratat este cea mai periculoasă. De regulă, piratarea unui site vă permite nu numai să plasați un „cod unic”, ci și să instalați cod cu elemente de malware (program rău intenționat). De exemplu, găsiți un cod și îl ștergeți, dar este restaurat după ceva timp. Din nou, există multe opțiuni.

    • Permiteți-mi să notez imediat că lupta împotriva unor astfel de viruși este dificilă, dar îndepărtarea manuală necesită cunoștințe. Există trei soluții la problemă: prima soluție este să folosiți pluginuri antivirus, de exemplu, un plugin numit BulletProof Security.

    Această soluție dă rezultate bune, dar necesită timp, deși puțin. Există o soluție mai radicală pentru a scăpa de codurile rău intenționate, inclusiv de viruși complecși, și anume de a restaura site-ul din copiile de rezervă făcute anterior ale site-ului.

    Deoarece un webmaster bun face acest lucru periodic, puteți reveni la o versiune neinfectată fără probleme. A treia soluție este pentru cei bogați și leneși, trebuie doar să contactați un „birou” specializat sau un specialist individual.

    Cum să cauți cod rău intenționat pe WordPress

    Este important să înțelegeți că codul rău intenționat de pe WordPress poate fi în orice fișier de pe site și nu neapărat în tema de lucru. El poate veni cu un plugin, o temă sau un cod „de casă” luat de pe Internet. Există mai multe moduri de a încerca să găsiți coduri rău intenționate.

    Metoda 1: manual. Parcurgeți toate fișierele site-ului și le comparați cu fișierele unei copii de rezervă neinfectate. Dacă găsiți codul altcuiva, ștergeți-l.

    Metoda 2: Utilizarea pluginurilor de securitate WordPress. De exemplu, . Acest plugin are o caracteristică excelentă, scanarea fișierelor site-ului pentru prezența codului altor persoane, iar pluginul face față perfect acestei sarcini.

    Metoda 3. Dacă aveți un suport rezonabil de găzduire și vi se pare că există altcineva pe site, cereți-i să vă scaneze site-ul cu antivirusul. Raportul lor va lista toate fișierele infectate. Apoi, deschideți aceste fișiere în editor de textși eliminați codul rău intenționat.

    Metoda 4. Dacă puteți lucra cu acces SSH la directorul site-ului, atunci mergeți mai departe, are propria sa bucătărie.

    Important! Indiferent de modul în care căutați cod rău intenționat, înainte de a căuta și apoi de a șterge codul, închideți accesul la fișierele site-ului (activați modul de întreținere). Amintiți-vă despre codurile care sunt restabilite atunci când sunt șterse.

    Căutați coduri rău intenționate folosind funcția eval

    Există așa ceva în php funcția de evaluare. Vă permite să executați orice cod pe linia sa. Mai mult, codul poate fi criptat. Din cauza codificării, codul rău intenționat arată ca un set de litere și simboluri. Două codificări populare sunt:

  • Baza64;
  • Rot13.

    • În consecință, în aceste codificări, funcția eval arată astfel:

    • eval(base64_decode(...))
    • eval (str_rot13 (...)) //în ghilimele interne, seturi lungi, neclare de litere și simboluri..

    Algoritmul de căutare a codului rău intenționat folosind funcția eval este următorul (lucrăm din panoul administrativ):

    • accesați editorul site-ului (Aspect→Editor).
    • copiați fișierul functions.php.
    • deschideți-l într-un editor de text (de exemplu, Notepad++) și căutați cuvântul: eval.
    • Dacă îl găsiți, nu vă grăbiți să ștergeți nimic. Trebuie să înțelegeți ce „cere” să fie îndeplinită această funcție. Pentru a înțelege acest lucru, codul trebuie decodat. Pentru decodare există instrumente online, numite decodoare.
    Decodoare/Codificatoare

    Decodorele funcționează simplu. Copiați codul pe care doriți să-l decriptați, îl lipiți în câmpul decodorului și decodați.

    La momentul scrierii, nu am găsit un singur cod criptat găsit în WordPress. Am găsit codul de pe site-ul Joomla. În principiu, nu există nicio diferență în înțelegerea decodării. Să ne uităm la fotografie.

    După cum puteți vedea în fotografie, funcția de eval, după decodare, nu a afișat un cod groaznic care amenință securitatea site-ului, ci un link de drepturi de autor criptat de la autorul șablonului. Poate fi, de asemenea, eliminat, dar va reveni după actualizarea șablonului dacă nu utilizați .

    În concluzie, aș dori să notez, pentru a nu primi un virus pe site:

    • Codul rău intenționat de pe WordPress vine adesea cu teme și pluginuri. Prin urmare, nu instalați șabloane și pluginuri din resurse „stânga”, neverificate, iar dacă o faceți, verificați-le cu atenție pentru prezența link-urilor și a funcțiilor executive ale PHP. După ce instalați pluginuri și teme din resurse „ilegale”, verificați site-ul cu software antivirus.
    • Asigurați-vă că faceți copii de rezervă periodice și efectuați altele.
    JavaScript rău intenționat

    Părerea mea, care este că este mai ușor și mai eficient să vă protejați împotriva scripturilor de browser rău injectate (atacuri XSS stocate) folosind instrumente de browser, a fost afirmată mai devreme: . Protecția browserului împotriva JavaScript, care constă în adăugarea de cod de filtrare la paginile html ale site-ului, este probabil de încredere, totuși, prezența unei astfel de protecție nu elimină necesitatea folosirii și a unui filtru de server; Pentru aceleași atacuri XSS, puteți organiza o linie suplimentară de apărare pe server. De asemenea, trebuie să ne amintim despre posibilitatea ca un atacator să introducă scripturi (php) nu bazate pe browser, ci pe server (php) în mesajul HTML trimis de pe site, pe care browserul nu le va putea recunoaște.

    Un script de atac, indiferent dacă este bazat pe browser sau pe server, este un program trebuie să ne gândim că programul va avea întotdeauna unele diferențe simbolice față de html-ul „pur”. Să încercăm să găsim astfel de diferențe și să le folosim pentru a construi un filtru HTML pe server. Mai jos sunt exemple de JavaScript rău intenționat.

    XSS:

    Un text


    Un text

    XSS criptat:

    Un text


    Un text

    Browserele recuperează textul din caractere primitive nu numai aflate în interiorul containerelor html (între etichetele de deschidere și de închidere), ci și în interiorul etichetelor în sine (între< и >). Codificarea URL este permisă în adresele http. Acest lucru face dificilă recunoașterea codului rău intenționat pe partea serverului, deoarece aceeași secvență de caractere poate fi reprezentată în moduri diferite.

    Viermi XSS:

    „+innerHTML.slice(action= (method="post")+".php",155)))">





    alert("xss");cu(noul XMLHttpRequest)open("POST","post.php"),send("content="+_.outerHTML)

    Viermii XSS de mai sus sunt doar câțiva dintre cei mulți trimiși la competiția lui Robert Hansen (alias RSnake) din ianuarie 2008 pentru cel mai scurt vierme JavaScript rău intenționat (rezultate ale concursului).

    Semne ale atacurilor XSS

    Un script XSS este un program care accesează obiecte DOM ( Obiect document Model) și metodele acestora. În caz contrar, este puțin probabil să fie dăunător în vreun fel. De exemplu, șir JavaScript
    onckick="var a = "xss""
    nu afectează modelul de obiect al documentului, deci chiar dacă este încorporat într-o etichetă html, un astfel de șir este inofensiv. Numai prin manipularea obiectelor documentelor HTML și a metodelor acestora, un hacker poate provoca daune semnificative unui site. De exemplu, linia
    onmousemove="document.getElementsByTagName("body").innerHTML="XSS""
    înlocuiește deja conținutul paginii.

    Un semn de acces la metodele DOM sunt parantezele, precum și punctele din stânga semnului egal. Parantezele pot fi folosite și în html pentru a seta o culoare în formatul rgb(), cu toate acestea, fontul și culorile de fundal în html sunt setate în cel puțin încă trei moduri. Prin urmare, parantezele pot fi sacrificate fără a compromite expresivitatea textului html. Este necesar să acceptăm ca regulă că parantezele sunt în interiorul etichetei (adică între< и >) - acest lucru este foarte periculos, dacă primim un mesaj de la un utilizator pe server, acest mesaj conține paranteze în interiorul etichetelor, atunci cel mai potrivit lucru pe care ar trebui să-l facem este să blocăm un astfel de mesaj.

    Punctul poate fi conținut în etichete html: când se specifică adresa linkului (tag ); când setați dimensiunea elementelor html (style="height:1.5in; width:2.5in;" ). Dar secvențe de caractere ale formei
    litera punct este egal
    nu poate fi în etichete html. Dacă secvența specificată este prezentă în interiorul unei etichete html, mesajul de la utilizator conține cel mai probabil un script și ar trebui blocat.

    Un alt semn de pericol evident este simbolul „+” din interiorul etichetei. Nu există așa ceva în html fără scripturi. Dacă găsim plusuri în interiorul etichetelor, blocăm fără milă mesajul.

    Pentru a cripta cu caractere primitive în interiorul etichetelor html, un utilizator bine intenționat a site-ului adăugând un comentariu folosind editor vizual, nu va veni niciodată în alergare. Utilizarea primitivelor simbolice în etichete nu oferă niciun beneficiu sub formă de mijloace expresive suplimentare, necesită doar timp suplimentar de scriere. În cele mai multe cazuri, s-ar crede că un utilizator bine intenționat nici măcar nu știe că există anumite caractere primitive în HTML. De aici și regula: un ampersand în interiorul unei etichete este dovada unui atac asupra site-ului. În consecință, dacă vedem acest lucru, blocăm mesajul.

    O regulă similară ar trebui adoptată în ceea ce privește simbolul „%”, care poate fi folosit în codificarea adreselor URL. Cu toate acestea, procentele sunt folosite și în html „pur” pentru a seta dimensiunile relative ale elementelor. Combinațiile periculoase sunt cele în care semnul „%” este imediat urmat de o literă sau un număr.

    Neutralizarea scripturilor de server

    Spre deosebire de interpreții JavaScript din browsere, interpretul PHP de pe server nu permite libertăți atunci când scrieți textul programului. Prin urmare, pentru a neutraliza un posibil script de server, este suficient să înlocuiți complet în mesajul HTML al utilizatorului toate caracterele care sunt esențiale atunci când scrieți un program PHP cu primitivele lor HTML. Cele care trebuie înlocuite sunt, în primul rând, semnele dolar și sublinierea, punctul, parantezele, parantezele pătrate și ondulate, semnele plus și minus și semnul backslash.

    Filtru PHP pentru mesaje HTML

    $message este mesajul html primit de la editorul vizual către server.

    // amintim lungimea mesajului $lenmessage = strlen($mesaj); // decupează eticheta de comentariu $message = preg_replace("//", "", $message); // decupează fiecare etichetă în care atributul „src” se referă la o resursă externă $message = preg_replace("/]+?src[\w\W]+\/\/[^>]+?>/i" , " ", $mesaj); // decupează fiecare etichetă care conține orice caracter, cu excepția: - a-z 0-9 / . : ; " = % # spațiu $message = preg_replace("/]+[^->a-z0-9\/\.\:\;\"\=\%\#\s]+[^>]+?> /i", "", $mesaj); // decupează fiecare etichetă care conține secvența „. a-z =" $message = preg_replace("/]+?\.+?\=[^>]+?>/i", "", $message); // decupează fiecare etichetă care conține secvența „% a-z” sau „% 0-9” $message = preg_replace("/]+?\%+?[^>]+?>/i", "", $ mesaj); // decupează fiecare etichetă care conține secvența "script" sau "js:" $message = preg_replace("/]*?script[^>]*?>/i", "", $message); $mesaj = preg_replace("/]*?js:[^>]*?>/i", "", $mesaj); // decupează fiecare etichetă care începe cu un alt caracter decât „a-z” sau „/” $message = preg_replace("/]*?>/i", "", $message); // verifica: daca mesajul este scurtat, atunci se incheie programul $lenmessage2 = strlen($message); if ($lenmessage != $lenmessage2) ( print "Mesajul nu poate fi adăugat"; exit; ) // efectuează înlocuirea de la capăt la capăt a caracterelor periculoase cu primitivele lor corespunzătoare $message = str_replace("$", "$" , $mesaj); $mesaj = str_inlocuire("_", "_", $mesaj); $mesaj = str_inlocuire(".", ".", $mesaj); $mesaj = str_inlocuire(chr(92), "\", $mesaj); // \ $mesaj = str_inlocuire("(", "(", $mesaj); $mesaj = str_inlocuire()", ")", $mesaj); $mesaj = str_inlocuire("[", "[", $mesaj); $mesaj = str_inlocuire("]", "]", $mesaj); $mesaj = str_inlocuire("(", "(", $mesaj); $mesaj = str_inlocuire()", ")", $mesaj); $mesaj = str_inlocuire("?", "?", $mesaj); // acum mesajul a fost verificat, scripturile din el au fost neutralizate

    Trebuie remarcat faptul că filtrul nu elimină etichetele asociate. Să zicem că am primit
    Click aici!
    Filtrul va tăia doar , dar eticheta asociată (de închidere) va rămâne. Dacă trimiteți către browser mesaje care conțin etichete fără perechi corespunzătoare, este posibil să aveți probleme sub forma unei „deformații” a site-ului. Nu se știe cu ce etichetă de deschidere browserul se va potrivi cu eticheta de închidere neîmperecheată rămasă. Prin urmare, și tot din motive de securitate, mesajele în care ceva a fost tăiat de filtru nu ar trebui să fie trimise deloc către browser. Este mai bine să tipăriți ceva de genul „Mesajul nu poate fi adăugat” și să părăsiți programul.

    Se așteaptă ca mesajul să fie scris într-un fișier (nu într-o bază de date).

    Discuţie

    Voi fi recunoscător pentru critici. Scrieți pe forumul de asistență, în secțiune

    1. Despachetați-l în folderul site-ului.
    2. urmați linkul your_site/fscure/
    3. totul

    Ce poate face?

    1. Căutare automată viruși prin semnături.
    2. Căutați un șir în fișiere
    3. Ștergerea fișierelor
    4. Corectați codul rău intenționat folosind expresii regulate

    Scriptul nu va face toată munca pentru dvs. și necesită cunoștințe minime. Este recomandat să faceți o copie de rezervă a site-ului înainte de lucru.

    Cum funcționează?

    La prima lansare, creează un index de fișiere. Fișierul fscure.lst se află în folder. Afișează o listă de fișiere care conțin semnături potențial rău intenționate. „Potențial rău intenționat” înseamnă că va trebui să decideți dacă este un virus sau nu. Lista semnăturilor este configurată în fișierul config.php, constantă SCAN_SIGN. Cu setările implicite, scriptul nu verifică fișierele js și nu conține semnături pentru acestea.

    Cel mai mult probleme comune

    1. nu creează indexul fscure.lst. Se poate întâmpla dacă nu există suficiente drepturi. Pune 777 în folderul fscure

    2. eroare 5xx. Cel mai adesea „504 Gateway Time-out”. Scriptul nu are timp să se finalizeze și se blochează din cauza unui timeout. În acest caz, există mai multe modalități de a-și accelera activitatea. Viteza depinde în primul rând de mărimea indexului. Este în fișierul fscure.lst. De obicei, un fișier de până la 5 MB poate fi procesat în 90% din cazuri. Dacă nu are timp, puteți reduce „lăcomia” scriptului interzicând scanarea *.jpg;*.png;*.css în configurație.
    În fișierul config.php.

    // separator; define("FILES_EXCLUDE","*.js;*.jpg;*.png;*.css");

    3. Gazduirea emite un avertisment ca
    (HEX)base64.inject.unclassed.6: u56565656: /var/www/u65656565/data/www/34535335353.ru/fscure/index.php

    Nu există niciun virus în script și nu a existat niciodată. Și (HEX)base64.inject.unclassed.6 este o construcție ca „echo base64_decode(” , care este adesea întâlnită și în sine este destul de inofensivă. Cu toate acestea, în ultima versiune, am înlocuit acest cod.

    Ce să faci dacă nu ai reușit să găsești singur virusul?

    Ma puteti contacta pentru ajutor. Tarifele mele sunt modeste. Imi garantez munca timp de 6 luni. Costul lucrării este de 800 de ruble. pentru 1 site. Dacă există mai multe site-uri în contul dvs., prețul este stabilit individual.

    Dacă ați reuși să faceți totul singur, v-aș fi recunoscător pentru o recompensă financiară sau un link către site-ul meu.

    Detaliile mele:
    yandex
    41001151597934

    webmoney
    Z959263622242
    R356304765617
    E172301357329

    Adevărul vieții este că site-ul poate fi spart mai devreme sau mai târziu. După ce a exploatat cu succes vulnerabilitatea, hackerul încearcă să se afișeze pe site prin plasarea shell-urilor web și a programelor de descărcare a hackerilor în directoarele de sistem și introducerea ușilor de spate în codul de script și baza de date CMS.

    Scanerele ajută la detectarea shell-urilor web încărcate, ușile din spate, paginile de phishing, e-mailurile de spam și alte tipuri de scripturi rău intenționate - tot ceea ce știu și este pre-adăugat la baza de date de semnături de coduri rău intenționate. Unele scanere, cum ar fi AI-BOLIT, au un set de reguli euristice care pot detecta fișiere cu cod suspect, care este adesea folosit în scripturi rău intenționate, sau fișiere cu atribute suspecte care pot fi descărcate de hackeri. Dar, din păcate, chiar dacă pe găzduire sunt folosite mai multe scanere, sunt posibile situații în care unele scripturi hacker rămân nedetectate, ceea ce înseamnă de fapt că atacatorul rămâne cu o „ușă din spate” și poate sparge site-ul și obține controlul asupra acestuia. control deplinîn orice moment.

    Scripturile moderne de malware și hacker sunt semnificativ diferite de cele de acum 4-5 ani. În prezent, dezvoltatorii de coduri rău intenționate combină ofuscarea, criptarea, descompunerea, încărcarea externă a codului rău intenționat și alte trucuri pentru a înșela software-ul antivirus. Prin urmare, probabilitatea de a lipsi noile programe malware este mult mai mare decât înainte.

    Ce se poate face în acest caz pentru a detecta mai eficient virușii de pe site și scripturile de hacker pe găzduire? Este necesar să se utilizeze o abordare integrată: scanare automată inițială și analiză manuală ulterioară. Acest articol va discuta opțiunile pentru detectarea codului rău intenționat fără scanere.

    Mai întâi, să ne uităm la ce anume ar trebui să cauți în timpul unui hack.

  • Scripturi hacker.
    Cel mai adesea, la piratare, fișierele care sunt descărcate sunt shell-uri web, backdoors, „uploaders”, scripturi pentru spam-uri, pagini de phishing + handler de formulare, uși și fișiere marcatoare de hacking (imagini din sigla grupului de hackeri, fișiere text cu un „mesaj” de la hackeri etc.)
  • Injecții (injecții de cod) în .
    Al doilea cel mai popular tip de plasare de cod rău intenționat și hacker este injecțiile. Redirecționările mobile și de căutare pot fi injectate în fișierele existente .htaccess ale site-ului, ușile din spate pot fi injectate în script-uri php/perl, fragmentele javascript virale sau redirecționările pot fi încorporate în șabloane .js și .html resurse ale terților. Injecțiile sunt posibile și în fișierele media, de exemplu.jpg sau. Adesea, codul rău intenționat constă din mai multe componente: codul rău intenționat în sine este stocat în antetul exif fișier jpg, dar este executat folosind un mic script de control, al cărui cod nu pare suspect pentru scaner.
  • Injecții în baze de date.
    Baza de date este a treia țintă pentru un hacker. Aici, sunt posibile inserții statice, , , , care redirecționează vizitatorii către resurse terțe, îi „spionează” sau infectează computerul/dispozitivul mobil al vizitatorului ca urmare a unui atac de tip drive-by.
    În plus, în multe CMS moderne (IPB, vBulletin, modx, etc.), motoarele de șabloane vă permit să executați cod PHP, iar șabloanele în sine sunt stocate în baza de date, astfel încât codul PHP al shell-urilor web și al ușilor din spate poate fi construit direct în baza de date.
  • Injecții în serviciile de caching.
    Ca rezultat al configurării incorecte sau nesigure a serviciilor de cache, de exemplu, memcached, sunt posibile injecții în datele din cache „din mers”. În unele cazuri, un hacker poate injecta cod rău intenționat în paginile unui site fără a pirata direct site-ul.
  • Injecții/elemente inițiate în componentele sistemului server.
    Dacă un hacker a obținut acces privilegiat (rădăcină) la server, el poate înlocui elemente ale serverului web sau ale serverului de cache cu unele infectate. Un astfel de server web va oferi, pe de o parte, controlul asupra serverului folosind comenzi de control și, pe de altă parte, va introduce din când în când redirecționări dinamice și cod rău intenționat în paginile site-ului. Ca și în cazul unei injecții într-un serviciu de cache, administratorul site-ului nu va putea detecta, cel mai probabil, faptul că site-ul a fost piratat, deoarece toate fișierele și baza de date vor fi originale. Această opțiune este cea mai dificil de tratat.

    • Deci, să presupunem că ați verificat deja fișierele de pe găzduire și dump-ul bazei de date cu scanere, dar nu au găsit nimic, iar virusul este încă pe pagină sau redirecționarea mobilă continuă să funcționeze la deschiderea paginilor. Cum să caut mai departe?

    Căutare manuală

    Pe Unix, este greu să găsești o pereche de comenzi mai valoroasă pentru a găsi fișiere și fragmente decât find/grep.

    găsi . -nume ‘*.ph*’ -mtime -7

    va găsi toate fișierele care au fost modificate în ultima săptămână. Uneori, hackerii „întorc” data modificării scripturilor pentru a nu detecta scripturi noi. Apoi puteți căuta fișiere php/phtml ale căror atribute s-au schimbat

    găsi . -nume ‘*.ph*’ -сtime -7

    Dacă trebuie să găsiți modificări într-un anumit interval de timp, puteți utiliza aceeași căutare

    găsi . -nume ‘*.ph*’ -newermt 25-01-2015 ! -newermt 2015-01-30 -ls

    Pentru a căuta fișiere, grep este indispensabil. Poate căuta recursiv prin fișiere un fragment specificat

    grep -ril „stummann.net/steffen/google-analytics/jquery-1.6.5.min.js” *

    Când piratați un server, este util să analizați fișierele care au marcajul guid/suid setat

    găsi / -perm -4000 -o -perm -2000

    Pentru a determina în ce scripturi rulează în acest momentși încărcați procesorul de găzduire, puteți apela

    lsof +r 1 -p `ps axww | grep httpd | grep -v grep | awk ‘ ( if(!str) ( str= ) else ( str=str”))END(print str)’` | grep vhosts | grep php

    Ne folosim creierul și mâinile pentru a analiza fișierele de pe găzduire
  • Mergem la directoarele de încărcare, cache, tmp, backup, jurnal, imagini, în care ceva este scris prin scripturi sau încărcat de utilizatori și scanăm conținutul pentru fișiere noi cu extensii suspecte. De exemplu, pentru joomla puteți verifica fișierele .php din directorul images:find ./images -name ‘*.ph*’ Cel mai probabil, dacă se găsește ceva, va fi malware.
    Pentru WordPress, este logic să verificați directorul wp-content/uploads, directoarele de teme de rezervă și cache pentru scripturi.
  • Caut fișiere cu nume ciudate
    De exemplu, php, fyi.php, n2fd2.php. Fișierele pot fi căutate
    • - prin combinații non-standard de caractere,
    • - prezența numerelor 3,4,5,6,7,8,9 în numele fișierului
  • Căutăm fișiere cu extensii neobișnuite
    Să presupunem că aveți un site web pe WordPress sau pentru ele fișierele cu extensii .py, .pl, .cgi, .so, .c, .phtml, .php3 nu vor fi chiar obișnuite. Dacă sunt detectate scripturi și fișiere cu aceste extensii, cel mai probabil acestea vor fi instrumente de hacker. Procentul de detecții false este posibil, dar nu este mare.
  • Căutăm fișiere cu atribute non-standard sau cu data creării
    Suspiciunea poate fi cauzată de fișiere cu atribute care diferă de cele existente pe server. De exemplu, toate scripturile .php au fost încărcate prin ftp/sftp și au utilizatorul utilizatorului, iar unele au fost create de utilizatorul www-data. Are sens să le verifici pe cele mai recente. Sau dacă data creării fișierului script este anterioară datei creării site-ului.
    Pentru a accelera căutarea fișierelor cu atribute suspecte, este convenabil să utilizați comanda Unix find.
  • Căutăm uși folosind un număr mare de fișiere .html sau .php
    Dacă există câteva mii de fișiere .php sau .html în director, acesta este cel mai probabil o ușă.
    • Jurnalele pentru a ajuta

    jurnalele serverului web, serviciul postalși FTP poate fi folosit pentru a detecta scripturi rău intenționate și hacker.

    • Corelarea datei și orei trimiterii scrisorii (care poate fi găsită din jurnal server de mail sau antetul serviciului unei scrisori de spam) cu solicitări de la access_log ajută la identificarea metodei de trimitere a spam-ului sau găsirea scriptului de expeditor de spam.
    • Analiza jurnalului de transfer FTP xferlog vă permite să înțelegeți ce fișiere au fost descărcate în momentul hackului, care au fost modificate și de către cine.
    • Într-un jurnal de server de e-mail configurat corect sau în antetul serviciului unui e-mail spam când setarea corectă PHP va fi numele sau calea completă către scriptul de trimitere, ceea ce ajută la determinarea sursei spam-ului.
    • Folosind jurnalele de protecție proactivă ale CMS-urilor și pluginurilor moderne, puteți determina ce atacuri au fost efectuate pe site și dacă CMS-ul a fost capabil să le reziste.
    • Folosind access_log și error_log, puteți analiza acțiunile unui hacker dacă cunoașteți numele scripturilor pe care le-a apelat, adresa IP sau Agent utilizator. Ca ultimă soluție, puteți vizualiza solicitările POST în ziua în care site-ul a fost piratat și infectat. Adesea, analiza vă permite să găsiți și alte scripturi hacker care au fost descărcate sau erau deja pe server în momentul hackului.
    Controlul integrității

    Este mult mai ușor să analizezi un hack și să cauți scripturi rău intenționate pe un site web dacă te ocupi în avans de securitatea acestuia. Procedura de verificare a integrității ajută la detectarea în timp util a modificărilor în găzduire și la determinarea faptului de hacking. Una dintre cele mai simple și moduri eficiente– pune site-ul sub sistem de control al versiunilor (git, svn, cvs). Dacă configurați corect .gitignore, procesul de control al modificării arată ca apelarea comenzii git status, iar căutarea de scripturi rău intenționate și fișiere modificate arată ca git diff.

    De asemenea, veți avea întotdeauna backup fișiere la care puteți „retroduce” site-ul în câteva secunde. Administratorii de server și webmasterii avansați pot utiliza inotify, tripwire, auditd și alte mecanisme pentru a urmări accesul la fișiere și directoare și pentru a monitoriza modificările din sistemul de fișiere.

    Din păcate, nu este întotdeauna posibil să se configureze un sistem de control al versiunilor sau servicii terților pe server. În cazul găzduirii partajate, nu va fi posibilă instalarea unui sistem de control al versiunilor și servicii de sistem. Dar nu contează, sunt multe soluții gata făcute pentru CMS. Puteți instala un plugin sau un script separat pe site care va urmări modificările în fișiere. Unele CMS implementează deja monitorizarea eficientă a schimbărilor și un mecanism de verificare a integrității (de exemplu, Bitrix, DLE). Ca ultimă soluție, dacă găzduirea are ssh, puteți crea un cast de referință sistem de fișiere echipă

    Promoția „2 la prețul de 1”

    Promoția este valabilă până la sfârșitul lunii.

    Când activați serviciul „Site sub supraveghere” pentru un site, al doilea pe același cont este conectat gratuit. Site-urile ulterioare din cont - 1.500 de ruble pe lună pentru fiecare site.