Una alerta d’integritat és evidència, no una sentència: saber que un fitxer ha canviat només és útil si pots comparar-lo amb un desplegament esperat, una versió oficial o una edició autoritzada.
Compara els canvis amb una font de confiança
Exporta el conjunt complet de fitxers afegits, modificats i eliminats amb hashes i timestamps. Creua’l amb actualitzacions, desplegaments i activitat d’administradors abans de restaurar res.
Conserva el canvi abans de substituir-lo
Un reemplaçament immediat pot esborrar una hotfix legítima o evidència d’un atac. Guarda els fitxers sospitosos i els logs relacionats, especialment si el canvi no té un actor conegut.
Prioritza les rutes amb més risc
- PHP executable dins d’uploads.
- Arrel del lloc i fitxers de bootstrap.
mu-pluginsi plugins modificats.- Directoris recentment escrivibles o amb propietat inesperada.
Actualització legítima, hotfix o escriptura inexplicada?
Una actualització controlada ha de correspondre a una release i una finestra de desplegament. Una hotfix manual pot ser legítima, però ha de tenir autor. Un canvi sense paquet, operador ni justificació requereix investigar compromís o desplegament fallit.
Relaciona l’alerta amb el tipus de fitxer
Si afecta core, compara amb els checksums oficials de WordPress. Si és .htaccess i el fitxer torna a canviar després de restaurar-lo, segueix el diagnòstic de .htaccess que es reescriu contínuament.
No aprovis un nou baseline mentre quedi cap canvi sense explicar
Si ho fas, converteixes el fitxer sospitós en “conegut com a bo” i perds una de les senyals més valuoses de recurrència.
Com validar el nou baseline
Cada fitxer modificat ha de tenir una font documentada o haver estat retirat, els paquets de confiança han de coincidir amb el disc i el monitoratge no ha de detectar escriptures inexplicades durant actualitzacions i trànsit normals.
CRITERI D’INCIDENT WP REPAIR
Seqüència d’intervenció segura
Restaurar cada fitxer canviat pot esborrar l’evidència de treball legítim o atacant. Rutes, hashes, propietari i historial de processos ajuden a separar els canvis de rutina de les escriptures no autoritzades.
- Exporta el conjunt de canvis complets amb hashes antics/ nou i data i hores.
- Compa- ho amb l’activitat d’implementació, actualització i administrador.
- Verifica els fitxers nucli, plugin i tema contra paquets de confiança exactes.
- Prioritza fitxers executes en càrregues, root, mu- plugins i rutes d’escriptura recent.
Què ha de quedar verificat
- Cada fitxer canviat té una font documentada o s' elimina.
- Les comprovacions de confiança i els manifestos de desplegament coincideixen.
- No es produeix cap escriptura inexplicable després de la nova línia de base neta.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
He de restaurar cada fitxer un monitor de integritat banderes com a canviat?+
No. Restaura cada fitxer canviat indiscriminadament pot esborrar el treball legítim amb la mateixa facilitat que elimina l’evidència de l’atacant, atès que les actualitzacions, les correccions manuals i les implementacions fallides produeixen el mateix tipus d’alerta. Compareu les rutes, els hashes, el propietari i l’historial del procés amb els seus registres de desplegament abans de restaurar qualsevol cosa.
Quina és la diferència entre un desplegament fallit i un compromís real aquí?+
Una implementació fallida mostra només una part d’una versió esperada va ser copiada, la qual cosa es pot confirmar comparant el conjunt de canvis amb els registres d’implementació i actualització. Un compromís genuí mostra un codi desconegut o canvis sense cap actor legítim darrere d’ells, de manera que exportar el conjunt de canvis complet amb hashes i marques de temps abans d’actuar és el pas diagnòstic clau.
Està bé aprovar una nova línia de base d'internació una vegada que les alertes deixin d'aparèixer?+
No, això s'anomena com un error per evitar. Aprovar una nova línia de base mentre que canvis inexplicables encara existeixen efectivament reitiqueta els fitxers atacants com a ben conegut, de manera que cada fitxer canviat necessita una font documentada o eliminació abans de restablir la línia de base.
Quins fitxers canviats mereixen l’atenció més urgent?+
Donar prioritat als fitxers executables en les càrregues, el root del lloc, els mu-plugins i les rutes d’escriptura recent, ja que aquestes són les ubicacions més propenses a executar codi atacant en comptes de mantenir actius estàtics.