Expresiones regulares de NGINX

Hace poco me he encontrado con un problema en las redirecciones de NGINX la cual me hacía un bucle en una de las configuraciones.

Estas configuraciones son usadas por SEO para no dejar enlaces huérfanos o redirigir hacia alguna parte de la web por posicionamiento.

Pues bien no entendía bien lo que pasaba hasta que empecé a indagar un poco en la configuración.

Leer más

Configurando notificaciones email en Icinga2

Revisando uno de los Icinga2 que tengo configurado me di cuenta de que no llegaban las notificaciones correctamente y no entendía lo que ocurría.

Por lo tanto me puse a revisar cada una de las configuraciones hasta que di con la solución de ello.

Vamos a tener en cuenta 2 supuestos casos:

  1. Configuraciones sin ser un servidor maestro (standalone)
  2. Configuraciones siendo el servidor maestro (clientes de Icinga reportan a este servidor)
Leer más

Monitorizar HTTP o URL con Icinga2

El objetivo de esta guía es la de poder realizar monitorizaciones que sean reportadas de manera correcta al apartado de Icinga2 Web. Es bastante confusa la documentación que existe por Internet así que quise hacer un POST bastante claro con la explicación.

Vamos a explorar dos maneras de hacerlo:

  1. Módulo check_http
  2. Módulo WebInject

Debemos tener en cuenta que el servicio está montado como un servidor master (donde llegan los chequeos) y los clientes que son los que reportan a este.

Leer más

Icinga2 – No encuentra la tabla rememberme

Introducción

Antes de empezar hablar sobre el problema vamos a indicar el software del servidor:

  • Ubuntu 20.04
  • Icinga2 (2.13.1-1)
  • Icingaweb2 (2.9.3-1)

Esas son las versiones finales en las que quedó el servidor cuando procedí a actualizarlo. Una vez que lo hice todo estaba funcionando correctamente. Al día siguiente (tenía mis credenciales guardadas automáticamente) me saltó un error de que no encontraba la tabla «rememberme».

Me imaginé, por el nombre de la tabla, que tendría que ver con la parte de logarte automáticamente así que investigué un poco hasta encontrar la solución.

Leer más

Backup en PostgreSQL + Optimizaciones

Introducción

La verdad que nunca había trabajado con bases de datos PostgreSQL y he empezado relativamente hace poco por necesidades del trabajo. Pues bien en este caso nos vamos a centrar en una problemática que nos ha pasado y es realizar backup + restore.

Os preguntaréis, ¿Por qué tienes problemas al hacerlo? pues bien el problema viene dado porque si es una base de datos grande se puede llevar horas o día el proceso. Por lo tanto en mi cabeza lo primero que pasó fue un ¿Se puede optimizar los tiempos? ¿Cuál es la mejor manera de hacerlo? etc…

Así que en este artículo nos vamos a centrar en los distintos métodos que existen para realizar los backups y además optimizaciones siempre que se pueda.

Leer más

HAPROXY+Apache = Obtener IP Real

Introducción

Tenemos una plataforma montada de la siguiente manera:

INTERNET <-> HAPROXY <-> APACHE

Cuando una persona accede a la plataforma y revisamos los logs de APACHE vemos que nos está llegando la IP del balanceador. Lo que queremos es que llegue directamente la IP de la persona que se conecta.

Por lo tanto nuestro objetivo es que en APACHE llegue la IP pública que accede a nuestra plataforma/portal.

Si quieres ver el otro post de HAPROXY+NGINX = Obtener IP Real.

Leer más

HAPROXY+NGINX = Obtener IP Real

Introducción

Tenemos una plataforma montada de la siguiente manera:

INTERNET <-> HAPROXY <-> NGINX

Cuando una persona accede a la plataforma y revisamos los logs de NGINX vemos que nos está llegando la IP del balanceador. Lo que queremos es que llegue directamente la IP de la persona que se conecta.

Por lo tanto nuestro objetivo es que en NGINX llegue la IP pública que accede a nuestra plataforma/portal.

Leer más

Mod Evasive – Apache

Introducción

Hoy vamos a trabajar con el módulo de Apache Mod Evasive, el cual nos permitirá controlar el número de peticiones por IP.

Esto nos permite tener controlado si existe algún tipo de ataque de alta capacidad (DDOS y Brute Force) el cual nos puede saturar de conexiones los servidores Apache (frontales web).

Instalando Mod Evasive

Para empezar a trabajar:

  • Ubuntu 18.04
  • Apache instalado

Por lo tanto para todos los sistemas basados en Debian será compatible esta instalación.

 apt-get install libapache2-mod-evasive

Esto nos instalará el módulo en nuestro servidor Apache y además lo habilitará automáticamente.

Tened en cuenta, aunque lo haya habilitado, todas las configuraciones por defecto están comentadas.

Configurando Mod Evasive

Por defecto la configuración, una vez habilitado, se encuentra en el siguiente fichero:

/etc/apache2/mods-enabled/evasive.conf

La configuración por defecto:

<IfModule mod_evasive20.c>
 DOSHashTableSize 3097
 DOSPageCount     20
 DOSSiteCount     100
 DOSPageInterval  1
 DOSSiteInterval  1
 DOSBlockingPeriod   10
 
 DOSEmailNotify   xxx@ejemplo.com
 #DOSSystemCommand "su - someuser -c '/sbin/... %s ...'"
 DOSLogDir        "/var/log/mod_evasive"
</IfModule>

Explicación de los parámetros:

DOSHashTableSize: Si se baja la cantidad consume más recursos y revisa con mayor frecuencia. Sin embargo si tenemos el servidor muy sobrecargado se recomienda subir este parámetro para que no penalice la carga.

DOSPageCount: Cantidad de veces que ha accedido a la misma página esa IP en el intervalo definido por DOSPageInterval. Generalmente suele ser de 1 segundo.

DOSSiteCount: Numero de peticiones a la misma página web por IP por el intervalo definido por DOSSiteInterval.

DOSPageInterval: Es el intervalo en segundos que toma de referencia DOSPageCount. Por defecto es de 1 segundo.

DOSSiteInterval: Es el intervalo en segundos que toma de referencia DOSSiteCount. Por defecto es de 1 segundo.

DOSBlockingPeriod: La cantidad de tiempo en segundos en la que la persona será bloqueado. Por regla general es de 10 segundos. Este valor no hace falta aumentarlo tanto ya que cada vez que se recibe el ataque, si está bloqueado, el contador se reinicia a 0. Esto sigue el principio de que si es un ataque DDOS es evidente que el ataque suele ser continuado.

DOSEmailNotify: Se enviará un email por cada IP que ha sido bloqueada. Existe un mecanismo en /tmp que previene continuos envíos de email de la misma IP.

DOSSystemCommand: Esto es un comando que podemos ejecutar en el momento que la IP es incluida en una lista negra. Esto es bueno para cuando usamos un firewall externo o similar.

DOSLogDir: Directorio donde guardará los registros de la IP que bloquea.

DOSWhitelist: Si queremos meter en lista blanca, podemos poner una IP o Rango. Ejemplo:

DOSWhitelist 127.0.0.1
DOSWhitelist 127.0.0.*

Es decir no sigue la notificación CDIR.

Recordamos que después de aplicar la configuración debemos hacer un reload en Apache:

service apache2 reload

Probando Mod Evasive

En teoría existe un script que permite el testeo de esta configuración para que nos bloquee desde localhost. Pero cuando realizamos las pruebas directamente no nos funcionaba (nos daba BAD REQUEST).

La alternativa que hemos buscado es usar “ab” (Apache Benchmark) el cual nos permite realizar peticiones para ser bloqueados.

Por lo tanto para probar hemos ejecutado el siguiente comando:

 ab -n 300 -c 10 http://sitio-ejemplo.com/

-n: Indica la cantidad de peticiones.

-c: Cantidad de personas realizando las peticiones (concurrency).

Con este ejemplo nos bloqueará Mod Evasive enviándonos un correo si lo tenemos bien configurado en el servidor.

Conclusión

Ya sabéis que mientras mayor seguridad establezcamos en nuestro sistema mejor dormiremos por la noche.

Recordad que podéis visitar la categoría SEGURIDAD, para obtener otros artículos relacionados.

Si tenéis alguna duda, podéis comentar la entrada e intentaré resolverlas.

Seguridad HTTPS Apache

Introducción

En este artículo vamos a trabajar en la seguridad HTTPS Apache. Utilizaremos las tecnologías actuales hasta el momento (09/03/2020) para dejar nuestro sitio web ágil, seguro y confiable.

El resumen de lo que haremos:

  • TLS 1.3
  • HSTS
  • Configuraciones SSL
  • Comprobaciones Online

¡Vamos a ello!


Seguridad HTTPS Apache

Para empezar a trabajar:

  • Ubuntu 18.04
  • Versión de Apache >= 2.4.37

La versión de Apache por defecto en Ubuntu 18.04 es 2.4.18, por lo tanto no nos vale por defecto. Pero que no cunda el pánico, para todo tenemos solución.

Instalando repositorios Ondrej

Estos repositorios son bastante conocidos en la comunidad de Debian ya que nos permite tener varias versiones de PHP y además una versión actualizada de Apache.

add-apt-repository ppa:ondrej/apache2
apt-get update && apt-get -y upgrade

Nota: Si aparece los paquetes en keepback podemos desinstalarlo o forzar la instalación de los paquetes especificando los mismos.

En nuestro caso aparecían las versiones de Apache que hemos tenido que forzar a los nuevos de este repositorio. Por lo tanto tras instalar estos ya tenemos la nueva versión de Apache.

Con esta nueva versión ya tenemos la posibilidad de poder usar TLS 1.3 (último protocolo y más seguro).


HSTS

HSTS (HTTP Strict Transport Security) es una capa extra de seguridad para nuestra navegación en HTTPS que evita ataques man in the middle y posibles secuestros de sesiones.

# Requisitos

a2enmod headers
service apache2 restart

La siguiente línea la podemos poner por defecto en el fichero de configuración «conf-enabled/security.conf». Pero lo dejaremos a nivel de VirtualHost para que se controle desde el propio sitio web.

Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"

Configuraciones SSL

Aquí vamos a incluir políticas que dejaremos configuradas de manera genérica para todos los sitios webs. Este fichero se encuentra «mods-enabled/ssl.conf»

SSLCipherSuite

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

Nota: Los cifrados afectan sobre todo a los clientes más antiguos. A más restrictivos más posibilidades existe de que no funcionen correctamente por HTTPS.

Este es uno genérico que nos hará pasar las auditorias. En el caso de que no sea así simplemente se debe ir eliminando los cifrados que no necesitemos.

SSLHonorCipherOrder

Este parámetro fuerza que se usen los CipherSuite que hemos establecido en el servidor web (Apache).

SSLHonorCipherOrder on

SSLProtocol

Vamos a dejar deshabilitado el protocolo SSLv3 ya que ha sido uno de los que mayores agujeros de seguridad ha tenido. El resto de los protocolos los permitimos.

SSLProtocol all -SSLv3

Habilitando HTTP2

Recordamos que tenemos creado un artículo que explica cómo habilitar HTTP2 (la mayoría de los pasos los tenemos hecho)

Ver Habilitando HTTP2


Comprobaciones Online

Existen distintas webs que nos permiten revisar la seguridad de nuestro certificado. Os dejo estas dos webs que al menos a mi me funcionan muy bien:

Nota: Marcad siempre la casilla de que nuestro resultado no salgo públicamente si queremos mantener nuestro anonimato.


Conclusión

Hemos aprendido a implementar nuevas configuraciones de seguridad para respirar un día más con nuestros clientes. Además de ello hemos ganado velocidad, estar en la última tecnología y estar listos para varios años más en el mercado.

Recordad que podéis visitar la categoría SEGURIDAD, para obtener otros artículos relacionados.

Si tenéis alguna duda, podéis comentar la entrada e intentaré resolverlas.

Instalar Fail2BAN

Introducción

En el día a día del administrador de sistemas siempre nos preocupamos en la seguridad de nuestros servidores. Fail2BAN es una herramienta que nos permitirá automatizar la revisión de nuestros logs de nuestras principales aplicaciones del servidor.

Activar las jaulas o los logs que tiene que revisar es muy sencillo.

Web Oficial

Instalar Fail2BAN

La instalación la vamos a llevar a cabo en Ubuntu 18.04 LTS, por lo tanto cualquier sistema Debian es compatible.

apt-get install fail2ban

Configurar Fail2BAN

Accederemos a la carpeta de configuración de Fail2BAN y realizaremos una copia del fichero de configuración (el cual será el que modifiquemos).

cd /etc/fail2ban
cp jail.conf jail.local

Editaremos el fichero jail.local y solo habilitaremos aquellos logs de los servicios que tengamos instalados en nuestro sistema.

En el caso de habilitar algo que no encuentre, nuestro servicio de Fail2BAN no arrancará.

También recordar que por defecto habilita la jaula de «SSH», por lo tanto debería estar configurada. No obstante lo dejaremos en el fichero de configuración activo para que no se nos olvide.

Ejemplo habilitando jaulas:

[sshd]
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

[apache-auth]
enabled = true
port     = http,https
logpath  = %(apache_error_log)s

Como veis hemos habilitado la de SSH y Apache-Auth. Para habilitarlos solo tuve que añadir la línea «enabled = true».

Simple, ¿verdad?

¿Funciona Fail2BAN?

Para ver si está en funcionamiento revisaremos en 3 lugares:

service fail2ban status
ps -ef | grep fail2ban
tail -f /var/log/fail2ban.log

Solo hace falta revisar uno de ellos para ver si nuestro Fail2BAN está en ejecución en el sistema, pero os dejo tres para que elijáis el que más rabia os de.

Conclusión

Siempre es bueno de rodearse de buenas herramientas para mantener nuestro entorno seguro y esta es una de ellas.

Recordad que podéis visitar la categoría SEGURIDAD, para obtener otros artículos relacionados.

Si tenéis alguna duda, podéis comentar la entrada e intentaré resolverlas.