Lo que vas a encontrar...
WordPress es, hasta la fecha, el CMS más popular con más del 30% de cuota de mercado de la web. Con tal cantidad de cuota de mercado, WordPress a menudo se convierte en blanco de amenazas de seguridad. Entonces, para el propietario de un sitio en WordPress, es mejor tomar algunas medidas para reforzar la seguridad en este popular CMS.
Como miles de sitios web se ejecutan en Nginx, he reunido algunos consejos básicos o reglas de Nginx para mejorar la seguridad de su sitio en WordPress.
Limitar el acceso XMLRPC
XMLRPC en WordPress se usa para permitir que una aplicación externa interactúe con los datos de WordPress. Por ejemplo, puede permitir agregar, crear o eliminar una publicación. Sin embargo, XMLRPC también es un vector de ataque común en el que el atacante puede realizar esas operaciones sin autorización. Es mejor permitir la solicitud a XMLRPC desde una IP autorizada en la que confía, de esta manera:
|
1 2 3 4 |
location ~* /xmlrpc.php$ { allow 172.0.1.1; deny all; } |
Una vez que se agrega lo anterior, debería ver la respuesta del código de error 403 al cargar xmlrpc.php en el navegador.
Limitar tipos de peticiones
La mayoría de las veces su sitio web solo puede realizar dos tipos de solicitudes, es decir, GET para recuperar datos de su sitio y POST para cargar datos en su sitio. Limitar el tipo de solicitud que nuestro sitio puede manejar solo a estos dos suena como una buena idea aquí.
|
1 2 3 |
if ($request_method !~ ^(GET|POST)$ ) { return 444; } |
Acceso directo a archivos PHP
Si de alguna manera, un pirata informático ingresa con éxito un archivo PHP en su sitio, podrá ejecutar este archivo cargando el archivo que efectivamente se convierte en una puerta trasera para infiltrarse en su sitio. Deberíamos deshabilitar el acceso directo a cualquier archivo PHP agregando las siguientes reglas:
|
1 2 3 4 5 |
location ~* /(?:uploads|files|wp-content|wp-includes|akismet)/.*.php$ { deny all; access_log off; log_not_found off; } |
Dotfiles
Similar al archivo PHP, un archivo de puntos como .htaccess, .user.ini y .git puede contener información confidencial. Para estar más seguro, es mejor deshabilitar el acceso directo a estos archivos.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
location ~ /\.(svn|git)/* { deny all; access_log off; log_not_found off; } location ~ /\.ht { deny all; access_log off; log_not_found off; } location ~ /\.user.ini { deny all; access_log off; log_not_found off; } |
Ocultar versiones de Nginx y PHP
Es mejor que cierta información no se exponga, como la versión de Nginx y la versión de PHP. Esto no evitará el ataque en sí. Sin embargo, suponiendo que resulte una versión particular de Ningx o PHP que tenga una vulnerabilidad expuesta, el atacante no podrá conocerlo fácilmente desde su sitio. Para ocultar la versión de Nginx:
|
1 2 3 4 5 6 |
#Hide the nginx version. server_tokens off; #Hide the PHP version. fastcgi_hide_header X-Powered-By; proxy_hide_header X-Powered-By; |
Encabezados de seguridad
Los encabezados de seguridad proporcionan una capa adicional de seguridad al dictar el comportamiento del navegador. Las opciones de X-Frame, por ejemplo, evitarán que su sitio se cargue desde un iframe, a menos que sea de su propio sitio. Strict-Transport-Security exigirá que el navegador cargue su sitio desde HTTPS.
|
1 2 3 4 |
add_header X-Frame-Options SAMEORIGIN; add_header Strict-Transport-Security "max-age=31536000"; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; |
Bloquear acceso a subdirectorio
Si su sitio se ejecuta en un subdirectorio como /blog, es mejor permitir el acceso a este subdirectorio. Significa que cualquier acceso oscuro a otros directorios que un atacante siempre busca, por ejemplo, /82jdkj/?.php están bloqueados.
|
1 2 3 4 5 |
location ~ ^/(?!(blog)/?) { deny all; access_log off; log_not_found off; } |
Reducir el spam
Los comentarios de spam en wordpress, no podrán romper su sitio, inundará su base de datos con contenido basura o contenido malicioso que podría aprovecharse como un vector. Para reducir las entradas de spam, puede agregar las siguientes reglas a su configuración de Nginx junto con un complemento de protección contra spam como Akismet.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
set $comment_flagged 0; set $comment_request_method 0; set $comment_request_uri 0; set $comment_referrer 1; if ($request_method ~ "POST"){ set $comment_request_method 1; } if ($request_uri ~ "/wp-comments-post\.php$"){ set $comment_request_method 1; } if ($http_referer !~ "^https?://(([^/]+\.)?site\.com|jetpack\.wordpress\.com/jetpack-comment)(/|$)"){ set $comment_referrer 0; } set $comment_flagged "${comment_request_method}${comment_request_uri}${comment_referrer}"; if ($comment_flagged = "111") { return 403; } |
Limite de solicitudes
La página de inicio de sesión de WordPress, wp-login.php, es un punto final común para un ataque de fuerza bruta. El atacante intentará abrirse paso en su sitio enviando múltiples combinaciones de nombre de usuario y contraseña, y esto generalmente se hace varias veces en un segundo.
Para esto, podemos aplicar una regla que limitará la cantidad de solicitudes que la página puede manejar por segundo. Aquí establecemos el límite en 2 solicitudes por segundo; de lo contrario, la solicitud se bloqueará.
|
1 2 3 4 |
limit_req_zone $binary_remote_addr zone=WPRATELIMIT:10m rate=2r/s; location ~ \wp-login.php$ { limit_req zone=WPRATELIMIT; } |
Deshabilitar listado de directorio
Por último, pero no menos importante, debe deshabilitar la lista del directorio para que el atacante no sepa qué hay en el directorio. Hay muy pocas razones por las que sé dónde es útil el listado de directorios en un sitio de WordPress.
|
1 |
autoindex off; |
Ahora esto mismo pero en htacces como o sería?