Uncategorized
     

5 Consejos para proteger WordPress con NGINX

Proteger tu sitio no es tan agradable como escribir contenido, pero es igual de importante.

Busca en Internet “asegurando WordPress” y verás que no faltan artículos discutiendo varios plugins que prometen hacer tu sitio web más seguro. Muchos de lo que encontrarás es válido-incluso uso algunos plugins de este tipo. Sin embargo, los plugins sólo pueden hacer mucho. Administradores de WordPress de mentalidad de seguridad también deben tener cuidado de instalar demasiados plugins, ya que al hacerlo aumenta la superficie de ataque. Por estas razones, prefiero usar nginx como una capa de seguridad añadida para mis sitios de WordPress. A continuación se muestran 5 Consejos útiles para endurecer un sitio de WordPress con NGINX.

1. Usar HTTPS

Espero que ya estés haciendo esto, pero si no, por favor asegura tu sitio de WordPress con un certificado SSL. Google prioriza los sitios web HTTPS por una razón: son seguros y mejoran la privacidad de la navegación.  Los certificados SSL son baratos-con certificados de 1 año de precio menor que el costo de una comida de valor de Mcdonald’s no se puede culpar por su razón de no asegurar su sitio Web. Los servicios como Let ‘ s Encrypt también están disponibles, pero lo que se ahorra en el costo que puede hacer fácilmente en el tiempo. Por lo tanto, aunque yo personalmente uso vamos a cifrar para algunas de mis necesidades, no lo uso exclusivamente, y tampoco lo recomiendo a los individuos no técnicos. En su lugar, mire a ssls.com (propiedad del registrador namecheap). Allí usted puede encontrar certificados comodo rutinariamente por alrededor de $5 al año. Ahora que tiene un nuevo certificado SSL brillante, ¿Cómo protege WordPress? Con NGINX eso es fácil.  

La configuración anterior de nginx parece difícil de manejar, pero por suerte es más o menos algo que se puede copiar y pegar. La esencia de ello es que a pesar de la primera S en SSL que significa “seguro”, no todas las implementaciones de SSL son seguras. Numerosas vulnerabilidades de seguridad se han identificado con cifrados más antiguos y protocolos, y para asegurar correctamente un sitio que necesita para limitar correctamente Qué dialecto de SSL su servidor hablará. Para ayudar a visualizar esta fórmula críptica me gusta usar la prueba de servidor SSL de Qualys. Esta prueba gratuita inspeccionará la configuración de SSL de su servidor y la analizará en contra de las vulnerabilidades de conocimiento. El resultado final es un análisis de cuadro de mandos y desglose fácil de leer. A partir de la hora de esta escritura, la configuración anterior obtiene un A +

Calificación de A +, pero ¿por cuánto tiempo? La seguridad siempre es un objetivo en movimiento..

2. Redirigir HTTP a HTTPS

Con el paso 1 completo, podemos desactivar HTTP por completo! Solía haber un argumento para usar sólo HTTPS cuando era necesario (es decir, pantallas de inicio de sesión, banca, pago de comercio electrónico, etc.). Los desarrolladores saltaron a través de complicados aros para evitar servir inseguro (p. ej. HTTP) en una página segura, no sea que el navegador de un usuario les advierta de contenido inseguro. Todo esto se hizo en nombre de evitar, lo que en ese momento era, gravar los cálculos criptográficos. Afortunadamente, es el año 2019, no 1999, y no existe prácticamente ninguna razón para servir el contenido a través de HTTP por más tiempo.La configuración de ejemplo anterior es tan simple como se obtiene. Todo el tráfico HTTP será redirigido a HTTPS conservando los parámetros de URL. Si los usuarios teclear su nombre de dominio directamente en la barra de direcciones de su navegador, se redireccionarán sin problemas y automatizados. Mediante el uso de un 301-que es el código HTTP para una redirección permanente-su navegador almacenará en caché esta búsqueda, y los motores de búsqueda ignorarán por completo la versión HTTP de su sitio. ¡ Un triunfo!

3. Inicios de sesión con límite de velocidad

El número de intentos automatizados de hacking que recibe un sitio público es asombroso. La mayoría de estos son simplemente scripts automatizados en busca de sitios que tontamente dejaron cuentas de usuario predeterminadas y contraseña habilitada. Es probable que no en ningún riesgo, siempre que esté siguiendo la seguridad de contraseña adecuada (por ejemplo, el uso de un administrador de contraseñas como 1Password, y no volver a usar contraseñas entre sitios, etc), pero son molestos. No sólo molesto, pero pueden llenar rápidamente los registros del servidor, por lo que es difícil detectar intentos de piratería legítima. Afortunadamente hay una manera fácil de arreglar esto con NGINX-simplemente tasa límite de la página de inicio de sesión. Por la tarifa que limita la página de inicio de sesión usted fijó con eficacia un límite superior al número de intentos de inicio de sesión, un solo ordenador puede realizar durante un cierto período de tiempo. En Resumen, hace que los intentos forzosos brutos sean imprácticos. Ya que la mayoría de estos son intentos masivos automatizados para hackear, rápidamente se aburrirán del ritmo lento y pasar a otros sitios Web.  

Este ejemplo implica dos componentes distintos. El primero está en la línea 1, donde se define un limit_req_zone. Hay algunos componentes técnicos a esa línea que no voy a bucear en aquí-para aquellos curiosos, por favor, echa un vistazo a la documentación de nginx para limit_req_zone. Baste decir que esta configuración un poco de memoria (5 megabytes para ser exactos) y utiliza que para almacenar información sobre las direcciones IP que han golpeado recientemente el sitio Web. También define una tasa aceptable de no más de 5 solicitudes por minuto. La segunda parte de esta configuración está en la línea 10, con la configuración limit_req. No se habilita ninguna limitación de velocidad hasta que se especifica una directiva limit_req en un bloque de ubicación. En este ejemplo, estamos diciendo que la página de inicio de sesión de WordPress (/WP-login.php) debe ser de tarifa limitada utilizando la zona de memoria compartida llamada jason_whitehorn_us. La parte más confusa de esto es el último bit en la línea 10-la configuración de la ráfaga = 5 Nodelay. Los documentos nginx entrar en todos los detalles, pero el corto de ella es que esto permite a alguien a utilizar todas las 5 de sus peticiones de inmediato. De lo contrario, se interpreta que un límite de velocidad de 5 solicitudes por minuto significa “ninguna solicitud debe llegar antes de una cada 20 segundos”. Para algunos escenarios, esto podría tener sentido, para una página de inicio de sesión no lo hace. Considere el caso de uso en el que escribe erróneamente su contraseña y sólo se dan cuenta después de golpear enviar-¿esperaría 20 segundos, o de inmediato intentarlo de nuevo? Con esta configuración adicional, permitimos el escenario más razonable, siempre que el número total de intentos nunca supere los 5 en un período de 1 minuto.

4. Bloque XML-RPC

Si no sabes qué es XML-RPC, no estás solo. Es una característica oscura de WordPress que está en desuso. Hasta que se elimina completamente de WordPress, sin embargo, representa una fuente de abuso para los piratas informáticos. A menos que utilice la aplicación de administración de WordPress para móviles para iPhone o Android, hay poca razón para mantenerlo alrededor. Afortunadamente nginx puede bloquear fácilmente todo el acceso a ella con una configuración simple.Simplemente devolviendo un 404 derecho de nginx apagamos todo el acceso a la característica XML-RPC. Si usted está vacilante sobre el bloqueo absoluto-tal vez usted disfruta de la aplicación de administración móvil-entonces usted puede calificar fácilmente limitar este punto de edición utilizando la técnica mencionada anteriormente.

5. Certificados de cliente para login

Esta técnica no es para todos, pero para aquellos dispuestos a configurar el certificado de cliente auth en nginx los beneficios podrían valer la pena. Escribí una pieza a principios de este mes en todos los detalles Gory de la configuración de autenticación basada en el certificado de cliente con NGINX, así que no voy a repetir los aquí. Echemos un vistazo en su lugar a cómo se aplica esa técnica a WordPress.

Arriba se puede ver un ejemplo de la vida real de cómo estoy utilizando esta técnica en este blog. La URL de inicio de sesión protegida por la autenticación de certificado de cliente. Esto funciona para este sitio porque soy el único autor y nadie más tiene inicios de sesión. Para los sitios que permiten el registro de la cuenta esta técnica es poco práctica.

La gran imagen

Las 5 técnicas anteriores son sólo un ejemplo de cómo nginx puede proteger sitios web, incluyendo WordPress. Todos estos ejemplos se tomaron de la configuración de nginx real que alimenta este sitio web-que se puede ver en su totalidad en GitHub. Nginx puede hacer mucho más, así que no dude en explorar. Siempre estoy encontrando nuevas formas de ajustar mi configuración de nginx.

About Jason

Jason es un experimentado emprendedor y desarrollador de software con una historia demostrada de trabajar en la industria del petróleo y la energía. Experto en liderazgo, desarrollo móvil, sincronización de datos y arquitectura SaaS. Fuerte profesional de la ingeniería con una licenciatura en Ciencias (B.S.) en Ciencias de la computación de la Universidad Estatal de Arkansas.
View all posts by Jason →

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *