desarrollo-web-br-bd.com

Evaluaciones de dos planes de seguridad de wordpress contra el ataque de inyección de código php

Senario

He publicado un senario de inyección de código php de wordpress en SO antes, url: https://stackoverflow.com/questions/26826082/what-is-the-highly -eficiente-manera-de-eliminar-un-bloque-de-cadena-patrón-en-php-archivo

Descubrí que sucede con frecuencia en algunos sitios de WordPress, lo que tiene como consecuencia que se bloquee el complemento o que no pueda iniciar sesión/wp-admin hasta que haya eliminado todos los patrones de inyección de todos los archivos php, ya que utiliza el método que consume tiempo que mencioné en la publicación anterior, sin embargo, hasta ahora no sé dónde está la falla para que el atacante inyecte dicho código en wordpress.

Sin embargo, después de investigar, además de limpiar regularmente los archivos de copia de seguridad. Tengo a continuación los planes de seguridad de wordpress para evitar inyecciones:

Solución 1. Plan de actualización de wordpress.

        meaning always check out updates wordpress to latest version
        always check out updates making sure plugins to latest version.

Solución 2. configuración estricta de permisos de archivo/carpeta en wordpress [php, archivos normales, carpetas]

        never allow php file updates on production site, 
        Apache chmod set 
        all wordpress *.php files to chmod 644; 
        all normal files  *.js *.css *.html etc to 755; 
        wp-upload folder set chmod to 755
        rest wordpress folder set chmod to 644; 

Por estos dos approches,

Solución 1: (enfóquese en actualizar a la última versión, contando con los últimos parches, corregiremos las vulnerabilidades y dejaremos a chmod como permiso predeterminado cuando Wordpress/Plugin esté instalado).

en realidad, es una tarea que consume mucho trabajo porque hay tantas actualizaciones que cuidar y nunca se sabe si la actualización del complemento de Cetain causará problemas de compatibilidad con la versión de WordPress. y no creo que pueda abarcar todo para evitar la inyección en mi SO publicación. además, si el sitio ya se ha inyectado y no se ha modificado antes de iniciar un proceso de actualización, generalmente causará que el plugin se bloquee como lo he hecho muchas veces. Pero el plan de actualización es el método más popular para reforzar la seguridad de wordpress, pero requiere monitoreo y mantenimiento por parte de las personas durante las actualizaciones.

Solución 2: (enfóquese en personalizar los permisos de chmod para no permitir cambios en los archivos) Aquí hay un enlace de referencia del códice en la configuración de wordpress chmod: http://codex.wordpress.org/Changing_File_Permissions

parece razonable, pero definitivamente tendrá que probar si la sobreprotección de chmod causa incompatibilidades con los complementos que funcionan, etc. Como ciertos complementos requieren permisos inseguros para funcionar. También significa que se pueden hacer pequeños cambios en el sitio de producción según la configuración del permiso.

Entonces, muchachos, qué enfoque sugerirían para asegurar que los archivos php de wordpress no se inyecten. Cualquier comentario sobre las dos soluciones anteriores.

¿O algún plan mejor para luchar contra este tipo de inyecciones de código?

(Se prefieren las soluciones con menos involucramiento de monitoreo humano.)

1
BOBO

Primero, estas dos cosas (actualizaciones y permisos de archivos sanos) no son una opción "O" u opcional. Eso es lo que haces simplemente , porque si no lo haces tarde o temprano (incluso si mucho más tarde) vas a tener problemas por ello. Relativamente, diría que las actualizaciones son más importantes, porque los permisos de archivos defectuosos tienden a perjudicar cuando en un entorno ya comprometido (como un alojamiento compartido mal configurado).

Segundo, si usted repetidamente experimenta una infección de su (s) sitio (s), entonces ninguno de los dos haría nada para usted. Usted tiene un agujero serio en algún lugar, ya sea que se detecte fácilmente para ser explotado por escáneres automáticos o que alguien sepa y siga explotando manualmente. Antes de determinar qué ese agujero es y cómo cerrarlo, cualquier otra medida de seguridad es bastante discutible.

2
Rarst