Blog: PHP2Shell, securitatea serverelor și asistență de urgență
Încadrarea situației, instrucțiuni pentru administratori și ajutoare de decizie pentru conducere. Sortate pe teme, fiecare articol cu surse.
Situația și încadrarea
17 articole
PHP2Shell: ce este dovedit și ce nu
O verificare a faptelor despre PHP2Shell: ce afirmații provin din surse primare, ce provin din relatări din presă și ce afirmații nu rezistă.
Citiți mai departe →002De ce a devenit cunoscută vulnerabilitatea PHP înainte de patch
Potrivit relatărilor, detalii despre PHP2Shell au devenit publice înainte de expirarea embargoului. Explicăm desfășurarea și ce înseamnă aceasta pentru planificarea patchurilor.
Citiți mai departe →003Autoritățile scot site-uri din rețea: ce învață companiile de aici
Mainz, guvernul landului Hessa și BKA au scos preventiv site-uri din rețea. Ce pot învăța companiile de aici pentru propria decizie.
Citiți mai departe →004Nivelul de alertă portocaliu BSI: ce înseamnă încadrarea
BSI încadrează PHP2Shell la 3 / portocaliu. Ce spune scara, ce nu spune și cum transformă companiile încadrarea în decizii.
Citiți mai departe →005Ce recomandă CERT-EU și CERT-Bund pentru PHP2Shell
Instituțiile oficiale sunt de acord: actualizați imediat, altfel izolați. Comparăm recomandările și arătăm cum arată izolarea în practică.
Citiți mai departe →006Regulile de protecție Cloudflare împotriva PHP2Shell: ce oferă și ce nu
Cloudflare a lansat devreme reguli de protecție împotriva PHP2Shell. De ce ajută, de ce nu înlocuiesc totuși actualizarea PHP și ce setări ar trebui să verificați.
Citiți mai departe →00722,6 milioane de instanțe expuse: încadrarea corectă a cifrelor
Unit 42, CybelAngel și alții indică cifre foarte diferite despre PHP2Shell. Explicăm ce a fost numărat și ce cifră contează cu adevărat pentru dumneavoastră.
Citiți mai departe →008PHP2Shell în cinci minute: briefing pentru conducere
Vulnerabilitatea PHP2Shell pe o pagină pentru factorii de decizie: situația, riscul, cinci întrebări pentru IT și deciziile pentru astăzi.
Citiți mai departe →009Vulnerabilitatea de securitate PHP explicată simplu
PHP2Shell pentru netehnicieni: cu imagini din viața de zi cu zi, un mic glosar și trei situații tipice de plecare, ce ar trebui să faceți ca proprietar de site.
Citiți mai departe →010PHP2Shell: 15 întrebări ale clienților de hosting
Site-ul dumneavoastră se află la un furnizor de hosting și vreți să știți ce trebuie să faceți singur la PHP2Shell? Iată cele 15 întrebări cele mai frecvente, cu răspunsuri scurte.
Citiți mai departe →011De ce o actualizare WordPress nu ajută împotriva PHP2Shell
După titluri, mulți operatori au actualizat WordPress și se simt în siguranță. De ce acest lucru nu duce la nimic la PHP2Shell și ce contează în schimb.
Citiți mai departe →012PHP2Shell și Log4Shell: ce au în comun vulnerabilitățile
Mulți compară PHP2Shell cu Log4Shell din 2021. Ce susține comparația, unde șchiopătează și ce lecții de atunci ajută astăzi.
Citiți mai departe →013Scanări în masă după PHP fără patch: cum decurg atacurile automatizate
După PHP2Shell, atacatorii scanează automatizat internetul după servere vulnerabile. Cum decurge, de ce dimensiunea nu contează și ce vă protejează.
Citiți mai departe →014Fereastra de timp dintre patch și atac
La PHP2Shell au existat încercări de atac încă dinaintea patchului. Explicăm fazele ferestrei de timp, cum o măsurați pe a dumneavoastră și cum o scurtați.
Citiți mai departe →015După PHP2Shell: de ce sunt probabile alte anunțuri
PHP2Shell nu este încheiat odată cu patchul din 21 octombrie. De ce sunt de așteptat anunțuri ulterioare și cum vă pregătiți echipa.
Citiți mai departe →016PHP2Shell: imaginea situației din prima săptămână
La o săptămână după prima încercare de atac observată: starea patchurilor, avertismentele autorităților, atacurile și opririle, separat curat pe surse.
Citiți mai departe →017Sfaturi false periculoase despre PHP2Shell care circulă acum
Blocarea cookie-urilor, ascunderea mesajelor de eroare, actualizarea doar a CMS-ului: nouă sfaturi despre PHP2Shell care creează o falsă siguranță și ce contează cu adevărat.
Citiți mai departe →Hosting și distribuții
18 articole
Schimbarea versiunii PHP în zona clientului de hosting
Cum schimbați versiunea PHP în zona clientului furnizorului dumneavoastră de hosting, ce versiune alegeți și ce verificați înainte și după.
Citiți mai departe →019Debian și Ubuntu: este pachetul meu PHP actualizat?
Ce pachete PHP au corectat Debian și Ubuntu împotriva PHP2Shell, cum comparați exact starea instalată și unde eșuează dovada.
Citiți mai departe →020RHEL, AlmaLinux și Rocky Linux: verificarea patchului PHP
Ce a publicat Red Hat despre PHP2Shell, cum dovediți nivelul pachetelor pe RHEL și pe clone și de ce o reîncărcare nu este suficientă.
Citiți mai departe →021Depozitul sury.org: pachete PHP dintr-o sursă terță
Multe servere Debian și Ubuntu obțin PHP din depozitul sury. Ce înseamnă aceasta pentru actualizări, dovezi și versiuni PHP vechi după PHP2Shell.
Citiți mai departe →022Depozitul Remi: PHP la zi pe sisteme RHEL
Remi livrează versiuni PHP actuale pentru familia RHEL, ca modul sau instalabile în paralel. Cum verificați starea după PHP2Shell și evitați ramurile uitate.
Citiți mai departe →023De ce php -v arată după actualizare același număr
Actualizarea s-a făcut, dar php -v indică versiunea veche. De regulă este un backport și nu o eroare. Cum deosebiți inofensivul de problemele reale.
Citiți mai departe →024Dovedirea numerelor CVE în changelog-ul pachetului
Cine trebuie să dovedească un patch PHP conducerii, auditorilor sau asigurătorilor are nevoie de mai mult decât un număr de versiune. Așa devine intrarea din changelog o dovadă.
Citiți mai departe →025Schimbarea furnizorului de hosting după un incident de securitate: la ce să fiți atenți?
După un incident, dorința de a schimba furnizorul de hosting este de înțeles. Pentru ca mutarea să nu ducă atacatorul cu ea, contează ordinea și alegerea.
Citiți mai departe →026Mai multe versiuni PHP pe un server: patch separat pentru fiecare
Pe multe servere rulează în paralel trei, patru sau mai multe instalări PHP. După PHP2Shell, fiecare trebuie găsită, actualizată și repornită.
Citiți mai departe →027Dezactivarea versiunilor PHP vechi în panoul de hosting
PHP2Shell este un bun prilej de a scăpa de versiunile PHP vechi. Procedați în trei faze, pentru ca niciun site și niciun cronjob să nu cedeze neobservat.
Citiți mai departe →028Plesk: înțelegerea handlerilor PHP (FPM, FastCGI, modul Apache)
Ce handler PHP folosește Plesk pentru un site decide izolarea, configurarea și riscul. O comparație cu privire la PHP2Shell.
Citiți mai departe →029CloudLinux și alt-php: ce ar trebui să știe clienții de hosting
Pe serverele CloudLinux, site-urile rulează adesea cu pachete proprii alt-php. Fiecare dintre aceste versiuni are nevoie de propriul patch, iar acesta poate fi aplicat doar de operatorul serverului.
Citiți mai departe →030PHP pe NAS, firewall-uri și appliance-uri: sistemele uitate
Nu doar serverele web folosesc PHP. Pot fi afectate și sistemele NAS, firewall-urile și dispozitivele specializate cu interfață web. Patchul îl poate aplica acolo de regulă doar producătorul, accesibilitatea o reglați dumneavoastră.
Citiți mai departe →031PHP la furnizori cloud și PaaS: cine actualizează runtime-ul?
La serviciile de platformă, patchul PHP depinde de modelul de operare. Decisiv este runtime-ul care livrează efectiv, nu mediul local sau codul aplicației.
Citiți mai departe →032Imagini Docker PHP oficiale: taguri, digest-uri și reconstruire
Un tag al imaginii PHP oficiale este un pointer care se mută în timp spre niveluri noi. Cine știe ce înseamnă tag, variantă și digest alege imaginea potrivită și poate dovedi nivelul de patch.
Citiți mai departe →033CI/CD: reconstruirea automată a imaginilor PHP
O imagine se depășește și fără modificări de cod. Cu build-uri programate, o verificare a versiunii și un rollout prin digest, patchurile PHP ajung sigur în producție.
Citiți mai departe →034Suport pe termen lung pentru versiunile PHP vechi: opțiuni și limite
Cine nu poate renunța imediat la PHP 8.1 sau mai vechi găsește suport pe termen lung la distribuții, la furnizori terți și la servicii comerciale. Ce oferă aceste căi, ce vă trebuie în scris și unde sunt limitele.
Citiți mai departe →035Actualizarea PHP pe Windows
Pe Windows nu există actualizare automată PHP. Cine alege varianta corectă, verifică descărcarea și repornește toate procesele aduce curat patchul PHP2Shell pe fiecare calculator.
Citiți mai departe →Detectare și criminalistică IT
18 articole
Semnal de alarmă: serverul web pornește un shell
Dacă un proces PHP-FPM sau al serverului web pornește un shell, este unul dintre cele mai puternice semnale de alarmă pentru o intruziune. Cum verificați arborele de procese, cum încadrați excepțiile și cum monitorizați permanent tiparul.
Citiți mai departe →037Găsirea proceselor suspecte pe serverele Linux
Procesele malițioase se deghizează cu nume inofensive, rulează din directoare temporare sau de la fișiere șterse. Cu câteva comenzi de citire găsiți anomaliile și le încadrați.
Citiți mai departe →038Recunoașterea cronjob-urilor ascunse ca ușă din spate
Atacatorii folosesc sarcini programate pentru a reveni după o curățare. Cum verificați complet crontab-urile, directoarele cron, timerele systemd și sarcinile at și cum recunoașteți intrările suspecte.
Citiți mai departe →039Găsirea fișierelor modificate recent pe serverul web
După o posibilă intruziune contează ce s-a schimbat pe server. Cum căutați după intervale de timp, folosiți corect mtime și ctime și comparați cu pachetele, Git și backupurile.
Citiți mai departe →040Fișiere PHP în directorul de upload: interpretarea corectă a constatărilor
Un fișier PHP în directorul de upload este aproape întotdeauna un semn de alarmă, dar nu orice fișier este cod malițios. Cum evaluați constatarea fără a distruge urme și cum clarificați dacă l-a apelat cineva.
Citiți mai departe →041Recunoașterea codului PHP ofuscat
Codul PHP ilizibil cu eval și base64_decode este un semn clasic de cod malițios introdus. Ce tipare căutați, cum le găsiți fără risc și când ofuscarea este legitimă.
Citiți mai departe →042Verificarea conexiunilor de ieșire ale unui server
Un server web răspunde în primul rând la cereri. Dacă el însuși stabilește conexiuni către ținte necunoscute, aceasta poate însemna control de către atacatori sau scurgere de date. Cum verificați și limitați traficul de ieșire.
Citiți mai departe →043Găsirea conturilor de administrator străine în CMS și server
Un administrator necunoscut este adesea cea mai simplă ușă din spate. Cum căutați, nivel cu nivel, conturi străine, inclusiv pe cele pe care interfața le ascunde.
Citiți mai departe →044Găsirea și eliminarea cheilor SSH necunoscute
O cheie SSH introdusă deschide atacatorilor ușa chiar dacă toate parolele au fost schimbate. Cum găsiți fiecare fișier authorized_keys și verificați fiecare intrare.
Citiți mai departe →045Criptominer pe serverul web: semne și mod de lucru
CPU plin permanent, fără ca să vină mai mulți vizitatori: poate fi un criptominer. Cum verificați încărcarea, găsiți procesul și mecanismele lui de repornire și procedați ordonat.
Citiți mai departe →046Serverul trimite spam: găsirea cauzelor
E-mailuri nelivrabile, liste de blocare, reclamații: când propriul server trimite spam, în spate se află de obicei un script sau o căsuță poștală deturnată. Cum găsiți sursa.
Citiți mai departe →047Spam SEO și pagini străine în indexul Google
Brusc, sub domeniul dumneavoastră se clasează pagini despre medicamente sau mărfuri de marcă. Cum aflați de unde vine spamul SEO și cum îl scoateți din nou din index.
Citiți mai departe →048Site-ul redirecționează către pagini străine
Vizitatorii ajung pe site-uri cu premii sau în magazine dubioase, iar dumneavoastră nu vedeți nimic? Cum găsiți stratul în care se ascunde redirecționarea și o eliminați.
Citiți mai departe →049Salvați probele înainte de a reinstala serverul
O reconstruire elimină atacatorul, dar și toate urmele. Cine investește mai întâi o oră în conservarea probelor poate spune ulterior ce s-a întâmplat.
Citiți mai departe →050Întocmirea cronologiei unui incident
Când a venit atacatorul, ce a făcut, când a fost observat? O cronologie curată răspunde la aceste întrebări și este baza pentru notificări, asigurare și raport.
Citiți mai departe →051Compararea fișierelor de bază ale CMS-ului cu originalul
Comparația cu un original curat arată fiecare fișier modificat, indiferent dacă un scanner îl cunoaște. Cum construiți comparația pentru WordPress, proiecte Composer și pachete de sistem.
Citiți mai departe →052Verificarea bazei de date pentru cod introdus
Cine verifică doar fișierele ratează jumătate. Cum căutați în conținutul, setările, trigger-ele și conturile bazei de date cod introdus, doar în citire și pe o copie.
Citiți mai departe →053Scannere de malware pentru site-uri: ce găsesc și ce nu
Scannerul nu raportează nimic, deci totul e în regulă? Nu neapărat. Ce tipuri de scannere de site-uri există, ce vede fiecare și ce nu poate vedea, în principiu.
Citiți mai departe →Securizare și configurare
20 articole
Izolarea pool-urilor PHP-FPM pentru fiecare site
Un pool propriu pentru fiecare site este începutul, nu sfârșitul. Cum verificați pool-urile existente și securizați socketurile, extensiile, paginile de stare, resursele și jurnalele.
Citiți mai departe →055Setarea corectă a memory_limit
memory_limit limitează memoria pentru fiecare cerere PHP. După PHP2Shell, php.net recomandă provizoriu contrariul. Ce se aplică în funcționarea normală, în perioada de tranziție și după actualizare.
Citiți mai departe →056Limitarea rezonabilă a post_max_size și upload_max_filesize
Limitele de upload acționează în trei locuri: în serverul web, în PHP și în aplicație. Cum stabiliți valorile coerent, inclusiv cu valorile provizorii de la php.net pentru PHP2Shell.
Citiți mai departe →057Dezactivarea session.upload_progress: corect și durabil
Remediul pentru CVE-2026-115560 și una dintre măsurile provizorii PHP2Shell se stabilește repede. Ca să reziste, trebuie să fie la locul potrivit, blocat și reverificat după fiecare actualizare.
Citiți mai departe →058expose_php și antetele Server: ascunderea indicațiilor de versiune
PHP, Nginx și Apache își indică implicit numărul versiunii în fiecare răspuns. Asta nu protejează de atacuri, dar oferă scannerelor o listă de ținte la îndemână. Cum opriți asta și păstrați totuși privirea de ansamblu.
Citiți mai departe →059display_errors off: dezactivarea ieșirilor de erori în producție
Mesajele de eroare PHP vizibile dezvăluie căi, nume de baze de date și versiuni. Cum le dezactivați în PHP, în framework și în serverul web, fără a pierde erorile din vedere.
Citiți mai departe →060php_admin_value: blocarea setărilor împotriva suprascrierii
O setare de securitate folosește puțin dacă aplicația o schimbă la loc cu un singur rând de cod. Cu php_admin_value și php_admin_flag fixați obligatoriu valorile pentru PHP-FPM și Apache.
Citiți mai departe →061Stabilirea limitelor de memorie cu systemd și cgroups
Ca măsură provizorie PHP2Shell, php.net recomandă memory_limit=-1 și o limită de memorie în afara PHP. Cum stabiliți această limită cu systemd și cgroups, fără ca un singur worker să tragă după el întregul serviciu.
Citiți mai departe →062Configurarea sigură a Nginx pentru PHP
Cele mai multe vulnerabilități din configurațiile Nginx pentru PHP nu se află în Nginx, ci în câteva rânduri din location-ul PHP. Cum configurați transmiterea către PHP-FPM astfel încât să fie executate doar scripturile dorite.
Citiți mai departe →063Configurarea sigură a Apache pentru PHP
Apache este flexibil, iar tocmai de aceea este vulnerabil la configurări greșite. Cum conectați PHP prin PHP-FPM, închideți .htaccess ca ușă dosnică și setați sigur cele mai importante opțiuni de bază.
Citiți mai departe →064Interzicerea execuției PHP în dosarele de upload
Un webshell are nevoie de două lucruri: un dosar în care poate fi scris și un server care îl execută. Cum îi luați al doilea element, în fiecare dosar scriibil, nu doar în uploads.
Citiți mai departe →065Filtrarea cererilor de upload la margine: oportunități și riscuri
Autori de specialitate propun blocarea la proxy a cererilor de upload în afara căilor reale de upload, până când PHP este patchuit. Asta poate ajuta, dar poate paraliza și formulare și comenzi. Cum procedați controlat.
Citiți mai departe →066Utilizarea ModSecurity și a OWASP Core Rule Set
Un Web Application Firewall propriu, cu ModSecurity și OWASP Core Rule Set, este gratuit și puternic, dar nu merge de la sine. Cum alegeți motorul, porniți fără căderi și reglați regulile.
Citiți mai departe →067Configurarea Fail2ban pentru servere web
Fail2ban blochează adresele care apar repetat în jurnale. Pentru servere web vine cu filtre gata făcute, iar cu câteva rânduri se adaugă filtre proprii. Cum îl configurați fără a vă bloca pe dumneavoastră sau pe clienți.
Citiți mai departe →068Firewall pentru servere web: deschideți doar porturile necesare
Un server web are nevoie spre exterior, de obicei, doar de două porturi. Totuși, pe multe servere ascultă în internet baze de date, PHP-FPM sau interfețe de administrare. Cum găsiți serviciile deschise și închideți ce nu este necesar.
Citiți mai departe →069Actualizări de securitate automate pe servere Linux
Potrivit rapoartelor, distribuțiile au livrat backporturile PHP parțial chiar la 21 octombrie 2026, ziua patchurilor. Cine folosește actualizări automate de securitate le-a avut repede pe server. Ca să și acționeze, sunt necesare reporniri, surse terțe și control.
Citiți mai departe →070Least Privilege: drepturile utilizatorului serverului web
Codul introdus pe ascuns rulează cu drepturile utilizatorului serverului web. Ce are voie să facă acest cont stabilește cât de departe ajunge un atacator. Iată cum limitați shell-ul, sudo, cron, baza de date și sistemul de fișiere la strictul necesar.
Citiți mai departe →071Izolarea zonelor de administrare prin IP, VPN sau protecție suplimentară
De ce backend-ul unui site nu trebuie să fie accesibil pentru toată lumea și cum îl izolați prin lista de IP-uri permise, VPN sau autentificare prealabilă, fără să vă blocați singuri accesul.
Citiți mai departe →072Configurarea corectă a TLS și HTTPS
Ce versiuni TLS și cipher suites ar trebui să ofere astăzi un server web, după ce se orientează recomandările și cum verificați Nginx, Apache și conexiunile PHP de ieșire.
Citiți mai departe →073Benchmark-uri CIS și module BSI pentru servere web
Ce standarde de întărire există pentru serverele web Linux, prin ce se deosebesc benchmark-urile CIS de modulele IT-Grundschutz și cum faceți din ele o cerință verificabilă pentru serverele dumneavoastră PHP.
Citiți mai departe →Dezvoltare sigură
16 articole
Stocarea sigură a parolelor în PHP: folosirea corectă a password_hash
Cum stochează dezvoltatorii parolele în PHP cu password_hash și password_verify, cum aleg procedeul potrivit și cum înlocuiesc hash-urile MD5 sau SHA-1 vechi fără resetarea parolei pentru toți utilizatorii.
Citiți mai departe →075Protecția CSRF în aplicațiile PHP
Cum previn dezvoltatorii Cross-Site Request Forgery în aplicațiile PHP: token-uri pentru fiecare cerere care modifică ceva, verificarea originii în antet și cookie-uri SameSite ca strat suplimentar.
Citiți mai departe →076Validarea și filtrarea intrărilor în PHP cu filter_var
Cum verifică dezvoltatorii intrările în PHP cu filter_var, filter_input_array și liste de permisiuni, ce filtre sunt depășite și de ce validarea nu înlocuiește prepared statements și codarea la ieșire.
Citiți mai departe →077Prevenirea Command Injection în PHP
Cum evită dezvoltatorii Command Injection în PHP: înlocuirea comenzilor de sistem cu funcții PHP, folosirea proc_open fără shell, verificarea argumentelor și găsirea locurilor periculoase din codul existent.
Citiți mai departe →078Prevenirea Server-Side Request Forgery (SSRF) în PHP
Cum împiedică dezvoltatorii ca o aplicație PHP să interogheze sisteme interne în numele unor terți: liste de permisiuni, restricționarea protocolului, verificarea adresei rezolvate și limite în rețea.
Citiți mai departe →079Prevenirea XML External Entities (XXE) în PHP
Cum procesează dezvoltatorii XML în siguranță în PHP: comportamentul implicit al libxml, opțiuni riscante precum LIBXML_NOENT, protecția cu entity loader și LIBXML_NO_XXE și intrările XML ascunse tipice.
Citiți mai departe →080Type Juggling în PHP: comparațiile lejere ca risc de securitate
De ce comparațiile lejere cu == în PHP pot duce la vulnerabilități, ce s-a schimbat cu PHP 8.0 și cum scrieți robust comparațiile în autentificări, token-uri și permisiuni.
Citiți mai departe →081Numere aleatorii și token-uri sigure în PHP cu random_bytes
Cum generează dezvoltatorii în PHP token-uri pentru linkuri de parolă, chei API și coduri unice: surse sigure criptografic, lungime suficientă, stocare ca hash și valabilitate limitată.
Citiți mai departe →082Protejarea corectă a datelor de acces și a fișierelor .env
Cum protejați parolele de baze de date, cheile API și alte secrete în proiectele PHP: fișiere .env în afara webroot-ului, blocări în serverul web, drepturi restrânse și înlocuire ordonată după un incident.
Citiți mai departe →083Director .git public: o scurgere de date subestimată
De ce un webroot distribuit prin Git poate dezvălui întregul cod sursă împreună cu istoricul, cum verificați acest lucru, îl blocați imediat și construiți durabil deployment-ul fără directorul .git.
Citiți mai departe →084Fișiere de backup în webroot: .zip, .sql și .bak
De ce dump-urile de baze de date, arhivele și copiile de siguranță din directorul public se numără printre cele mai frecvente scurgeri de date, cum le găsiți, le blocați și clarificați dacă au fost accesate.
Citiți mai departe →085Fișiere phpinfo(): de ce trebuie să dispară
După PHP2Shell, mulți administratori creează repede un info.php. De ce astfel de fișiere sunt o scurgere de date, cum le găsiți și ce căi de verificare sunt mai bune.
Citiți mai departe →086Dependențe la zi: Composer, npm și pluginuri
Un proiect constă din trei lumi de pachete: Composer, npm și pluginuri CMS. Cum le țineți la zi pe toate trei, cu un ritm fix, responsabilitate clară și teste.
Citiți mai departe →087Code review de securitate pentru proiecte PHP
Cum parcurg echipele țintit codul PHP propriu în căutarea vulnerabilităților: tipuri de review, funcții critice, instrumente utile și o listă de verificare.
Citiți mai departe →088Jurnalizare sigură: înregistrarea erorilor fără scurgeri de date
Jurnalele ajută la depanare și la analiza criminalistică, dar devin ele însele rapid o scurgere de date. Ce ar trebui să înregistreze aplicațiile PHP, ce niciodată și cum se protejează jurnalele.
Citiți mai departe →089Securizarea API-urilor REST în PHP
Interfețele sunt adesea mai prost protejate decât site-ul din fața lor. Cele mai importante reguli pentru API-urile REST în PHP, de la autorizarea pe obiect până la limitarea ratei.
Citiți mai departe →Management și juridic
14 articole
Contracte cu furnizorii IT: reglementarea clară a obligațiilor de securitate
PHP2Shell a arătat cât de des nu este clar cine trebuie să aplice patch-urile. Ce obligații de securitate aparțin în contractele cu agenția, furnizorul de hosting și furnizorul IT.
Citiți mai departe →091Prelucrarea datelor în numele operatorului, când furnizorii accesează serverele
Cine lasă terți să acceseze servere cu date ale clienților are de regulă nevoie de un acord de prelucrare. Ce cere art. 28 RGPD și cum organizați accesele în caz de urgență conform protecției datelor.
Citiți mai departe →092Managementul vulnerabilităților în întreprinderile mijlocii
Nicio întreprindere mijlocie nu poate trata imediat fiecare avertizare. Un ciclu simplu de înregistrare, evaluare, decizie și dovadă face ca lucrurile importante să se întâmple primele.
Citiți mai departe →093Să știți ce rulează: inventarul tuturor site-urilor și serverelor
La PHP2Shell, mulți nu au eșuat la patch, ci la întrebarea unde rulează de fapt PHP. Iată cum alcătuiți un inventar al tuturor site-urilor și serverelor.
Citiți mai departe →094Patch management ca proces, nu ca intervenție de urgență
Cine aplică patchuri doar când arde pierde timp în caz de urgență. Cum leagă un proces de patch management, cu clase, ferestre și dovezi fixe, rutina de urgență.
Citiți mai departe →095Contacte de urgență: cine trebuie informat și când?
În caz de urgență contează pe cine reușiți să contactați și când. Cum alcătuiți o listă a contactelor IT de urgență, cu declanșatori, înlocuitori și datele de care are nevoie fiecare apel.
Citiți mai departe →096Cât costă un server spart: posturile de cost
Un server web spart generează mai multe costuri decât repararea. Ce posturi de cost apar și cum justificați cu cifre proprii un buget pentru prevenție.
Citiți mai departe →097Informarea clienților după un incident
Obligație sau decizie voluntară: cum stabiliți după un incident pe cine informați, ce canale sunt sigure și cum este pregătit serviciul dumneavoastră pentru clienți.
Citiți mai departe →098Lanțul de aprovizionare web: agenție, furnizor de hosting, furnizori de pluginuri
PHP2Shell a arătat câte verigi se află între un patch și site-ul dumneavoastră. Cum cunoașteți și securizați lanțul site-ului și cum preluați căderea unor verigi.
Citiți mai departe →099Conștientizarea securității pentru administratori și redactori: security awareness în echipa web
Cine întreține site-uri decide zilnic asupra securității, adesea fără să observe. Iată cum instruiți administratorii și redactorii pe roluri și fără avalanșă de prezentări.
Citiți mai departe →100Exercițiu de urgență la masă: simularea unui incident pe serverul web
Un exercițiu la masă costă o după-amiază și arată dacă planul dumneavoastră de urgență rezistă. Aici găsiți un scenariu gata făcut pentru un incident pe un server web PHP.
Citiți mai departe →101ISO 27001 și TISAX: ce privește serverele web
Cine operează un SMSI conform ISO 27001 sau deține o etichetă TISAX trebuie să ia în calcul și serverele web. Iată ce cerințe le ating și ce dovezi contează după PHP2Shell.
Citiți mai departe →102VdS 10000: securitatea informațiilor pentru întreprinderile mici și mijlocii
VdS 10000 este un cadru suplu pentru securitatea informațiilor în întreprinderile mijlocii. Ce cere, ce a fost nou în 2025 și ce înseamnă pentru site-uri și servere web.
Citiți mai departe →103Lessons learned: cum deveniți mai buni după incident
După incident este înainte de următorul. O discuție structurată de final, fără acuzații, transformă o săptămână proastă într-un progres măsurabil.
Citiți mai departe →Ajutoare de decizie
10 articole
Actualizăm, oprim sau așteptăm? Un ajutor de decizie pentru breșa PHP
La o breșă critică în PHP, responsabilii trebuie să decidă rapid. Acest ajutor ordonează cele trei opțiuni, enumeră criterii și arată când așteptarea este justificabilă.
Citiți mai departe →105WAF sau actualizare: de ce aveți nevoie de ambele
Un Web Application Firewall poate opri atacuri, dar nu închide o breșă din interpretorul PHP. Când ajută un WAF, unde se oprește și cum le combinați sensibil pe ambele.
Citiți mai departe →106Reinstalăm serverul sau îl curățăm? Decizia după o infectare
După o intruziune sunt deschise două căi: curățați serverul sau îl reconstruiți. Ce criterii decid și de ce ordinea contează mai mult decât alegerea.
Citiți mai departe →107Remediați singuri sau apelați la un furnizor? O cântărire sinceră
Nu orice situație de securitate necesită ajutor extern. Cu aceste criterii și un scurt autotest decideți dacă echipa dumneavoastră se descurcă singură cu PHP2Shell sau are nevoie de sprijin.
Citiți mai departe →108Alegerea unui furnizor de servicii de securitate IT: 12 întrebări înainte de comandă
Să găsești sub presiunea timpului un furnizor bun de securitate este greu. Aceste douăsprezece întrebări ajută la compararea obiectivă a ofertelor, fără a cădea în promisiuni publicitare.
Citiți mai departe →109Hosting administrat sau server propriu? Comparația de securitate
PHP2Shell a fost un test de stres pentru fiecare model de operare. Comparația arată când hostingul administrat este mai sigur, când serverul propriu și ce forme mixte s-au dovedit utile.
Citiți mai departe →110Upgrade PHP sau backport? Decizia pentru sistemele vechi
Pentru versiunile PHP vechi există după PHP2Shell mai multe căi: backport al distribuției, sursă terță, patch din sursă, suport pe termen lung sau upgrade. Cât valorează fiecare cale și cât durează.
Citiți mai departe →111Schimbăm CMS-ul după atac? Când ajută și când nu
După o intruziune, încrederea în CMS dispare adesea. Dar un sistem nou rezolvă rareori cauza reală. Când este sensibilă schimbarea și cum reușește ea curat.
Citiți mai departe →112Site-uri statice: mai puțin PHP, mai puțină suprafață de atac
Un site static livrează fișiere HTML gata făcute și nu are nevoie de PHP pe server. Aceasta reduce clar suprafața de atac, dar aduce limite și obligații proprii.
Citiți mai departe →113Pentest, bug bounty sau scanare de vulnerabilități? Alegerea procedurii potrivite
Scanarea, testul de penetrare și bug bounty verifică site-urile în moduri foarte diferite. Ce oferă fiecare procedură, unde dă greș și ce ordine se potrivește companiei dumneavoastră.
Citiți mai departe →Fiecare oră contează. Scrieți-ne acum.
Descrieți pe scurt sistemul, versiunea PHP și ce ați observat. Ne vom face auziți, clarificăm situația și lucrăm la distanță până când incidentul este încheiat și documentat.