Que .htaccess canviï no significa automàticament malware. WordPress, plugins de seguretat o cache, panells d’hosting i desplegaments poden reescriure’l. La qüestió és identificar quin procés fa el canvi i si les regles resultants són legítimes.
Compara versions en lloc de restaurar el fitxer contínuament
Guarda una còpia fiable i compara cada recurrència per contingut, hash i hora de modificació. Creua el timestamp amb accions de plugins, desat de permalinks, desplegaments, cron i peticions entrants.
Classifica la regla que torna a aparèixer
- Blocs estàndard de rewrite de WordPress.
- Directives de cache o seguretat d’un plugin conegut.
- Regles gestionades per l’hosting.
- Redireccions o handlers desconeguts sense propietari legítim.
Identifica el propietari abans d’eliminar la regla
Si també es reescriuen fitxers arrel, compara la reinfecció d’index.php. Si forma part d’un conjunt més ampli de canvis, utilitza el triatge d’integritat.
Repara el component que genera el rewrite
- Conserva la versió sospitosa i els logs rellevants.
- Identifica plugin, desplegament, procés d’hosting o escriptor maliciós.
- Corregeix o elimina aquesta font en comptes de lluitar contra el fitxer generat.
- Restaura les regles previstes quan l’origen ja sigui clar.
No facis .htaccess immutable com a primera resposta
Pots trencar actualitzacions legítimes de permalinks, cache o seguretat i deixar l’escriptor actiu en altres llocs.
Verificació
El fitxer s’ha de mantenir estable durant permalinks, desplegaments, cron i trànsit normal, o canviar només segons el comportament documentat del propietari legítim.
CRITERI D’INCIDENT WP REPAIR
Com acotar l’error sense endevinar
El bloc afegit exacte, la data i l’hora i el context de procés determinen si s' espera automatització o compromís. Fer el fitxer immutabla abans de trobar l’escriptor pot trencar operacions vàlides.
Guardeu versions successives amb data i hores i hashes.
Separeu els blocs de punts WordPress de les directives afegides fora d’ells.
Correlacioneu els canvis amb les accions de gestió, cron, implementacions i accés a registres.
El codi de cerca per al fitxer escriu o la directiva injectada exacta.
Què ha de quedar verificat
- El fitxer roman a través d’emmagatzematges d’enllaç permanent, cron i implementació.
- Només són presents les regles documentades.
- En les respostes del servidor no apareix cap redirecció o gestor maliciós.
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 fer.htaccess només de lectura tan aviat com m'adono que segueix canviant?+
No abans d’identificar el que realment esteu escrivint a ell. Fer el fitxer immutable abans de trobar el procés responsable podeu trencar operacions legítimes com a regeneració de permalink o una seguretat plugin gestió redirecionaments, atès que els que neceswebn accés d’escriptura per a funcionar normalment.
Un fitxer.htaccess canviant sempre vol dir que el lloc està infectat?+
No. WordPress en si reescriu la seva secció marcada després de canvis en la configuració de permalink, i l’automatització d’implementació o seguretat i cau plugins també pot modificar legítimament el fitxer. El bloc afegit exacte, la seva marca de temps i el context del procés determinen si això és un comportament esperat o un compromís.
Està bé sobreescriure.htaccess amb una versió genèrica per omissió de WordPress per restablir-lo?+
No, això pot trencar el lloc. En fer-ho, es corre el risc de descartar les regles de seguretat personalitzades, l’enrutament multilingüe o les directives específiques de l’aplicació que es van afegir deliberadament, per la qual cosa qualsevol regla personalitzada ha de ser preservada abans de restablir el fitxer.
Com es poden saber els canvis legítims de plugin a.htaccess a part de la persistència de malware?+
L’activitat plugin legítima es mostra típicament com a redireccionació reconeixible, capçalera o blocs de regles d’accés correlacionats amb una acció d’administrador o una tasca plugin programada, mentre que la persistència malware tendeix a injectar repetidament codi de redirecció o manejador PHP fora de qualsevol bloc de punts esperat. Correlacionant els canvis amb les accions d’administrador, cron, implementacions i registres d’accés separa els dos.