WordPress es, hasta la fecha, el CMS más popular con más del 30% de cuota de mercado en 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 de WordPress, es mejor tomar algunas medidas para reforzar la seguridad de su sitio.
1. Limitar el acceso a XMLRPC
El archivo 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ías, así:
|
1 2 3 4 |
location ~* /xmlrpc.php$ { allow 172.0.1.1; deny all; } |
Una vez que se agrega lo anterior, deberías ver la respuesta del código de error 403 al cargar xmlrpc.php en el navegador.
2. Limitar los tipos de solicitud
La mayoría de las veces tu sitio web solo puede realizar dos tipos de solicitudes, es decir, get recupera datos de tu sitio y post sube datos a tu 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; } |
3. Acceso directo a archivos PHP
Si de alguna manera, un ciberdelincuente ingresa con éxito un archivo PHP en tu 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; } |
4. Archivos de configuración
Similar al archivo PHP, un dotfile o archivo de configuración como .htaccess, .user.ini y .git puede contener información sensible. 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; } |
5. 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 una versión particular de Ningx o PHP tenga vulnerabilidad expuesta, el atacante no podrá conocerlo fácilmente desde tu sitio. Para ocultar la versión de Nginx debes hacer lo siguiente:
|
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; |
6. Encabezados de seguridad
Los encabezados de seguridad proporcionan una capa adicional de seguridad al dictar el comportamiento del navegador. Por ejemplo, X-Frame-Options evitará que tu sitio se cargue desde un iframe, a menos que sea desde tu propio sitio. Strict-Transport-Security obligará al navegador a cargar tu 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"; |
7. Bloquear el acceso a subdirectorios
Si tu 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 estará bloqueado.
|
1 2 3 4 5 |
location ~ ^/(?!(blog)/?) { deny all; access_log off; log_not_found off; } |
8. Reducir el spam
Los comentarios de spam, aunque puede que no dañen tu sitio, inundarán tu base de datos con contenido basura o un contenido malicioso. Este posiblemente podría aprovecharse como un vector. Para reducir las entradas de spam, puedes agregar las siguientes reglas a tu configuración de Nginx junto con un plugin 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; } |
9. Límite 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 tu sitio enviando múltiples combinaciones de nombre de usuario y contraseña. 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; } |
10. Deshabilitar listado de directorio
Por último, pero no menos importante, debes deshabilitar la lista de directorios 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; |