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ásHoy 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).
Para empezar a trabajar:
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.
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
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.
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.
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:
¡Vamos a ello!
Para empezar a trabajar:
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.
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 (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;"
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 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.
Este parámetro fuerza que se usen los CipherSuite que hemos establecido en el servidor web (Apache).
SSLHonorCipherOrder on
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
Recordamos que tenemos creado un artículo que explica cómo habilitar HTTP2 (la mayoría de los pasos los tenemos hecho)
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.
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.
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.
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
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?
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.
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.
Se nos ha solicitado la instalación y configuración de Verdaccio. Verdaccio es un gestor de paquetes NPM de ámbito privado, es decir que será interno o privada para la propia empresa.
En este manual aprenderemos a su configuración desde un VPS desde 0 hasta dejarlo en completo funcionamiento.
Vamos a tener en cuenta que el entorno se compone de:
Antes de ello vamos a dividir el proceso en:
Cuando no tenemos más remedio (necesidades del cliente) tenemos que poner una solución evitando actualizaciones de paquetes apt.
A veces los clientes pueden tener algo instalado que en el caso de actualizar alguno de los paquetes deje de funcionar. Esto para los administradores de sistemas es un gran problema (dolores de cabeza).
Generalmente esto ocurre cuando las instalaciones están hechas de manera artesana (manual) y no muy bien configuradas. Igualmente nosotros estamos aquí para dar servicio y poder aprovechar las actualizaciones del sistema.
Desde sistemas siempre se recomienda utilizar las aplicaciones paquetizadas ya que mejoramos tanto la seguridad (actualizaciones) como la centralización del sistema.
Con estos comandos hacemos que se retengan los paquetes necesarios para que no se actualicen.
apt-mark hold package_name echo "package_name hold" | sudo dpkg --set-selections aptitude hold package_name
El que está en negrita es el comando que suelo usar, por lo tanto os aplico un ejemplo:
apt-mark hold chromium*
Con este comando hará un hold de todos los paquetes que comiencen por la palabra chromium.
dpkg --get-selections | grep "hold"
apt-mark unhold package_name echo "package_name install" | sudo dpkg --set-selections aptitude unhold package_name
Siguiendo el ejemplo cuando retuvimos el paquete chromium, podemos hacer lo mismo para poder actualizarlo.
apt-mark unhold chromium*
Hemos aprendido a gestionar paquetes con apt en nuestros sistemas Debian.
Recordad que no es buena practica usar programas que no están paquetizados ya que suele quedar en el olvido su actualización.
Recordad que podéis visitar la categoría SEGURIDAD, para obtener otros artículos relacionados.
¡Hola!
No sabía como empezar este POST ya que me encontré con una curiosidad el cual me hizo pensar para el uso de los servidores.
Sabemos que si disponemos de una plataforma, lo ideal es tener todos los servidores o servicios con la misma hora.
Antes usaba el servicio de NTP o NTPDATE para poder configurar la hora de acuerdo a los servicios NTP (urls) externas.
Mi cuestión o duda vino en el momento en el que me fije en la salida del comando timedatectl el cual me puso manos a la obra para investigar un poco acerca de su conexión con los NTP.
Lo primero que debemos hacer es preguntarnos acerca de esto, es decir como o cuando usar cada uno.
Digamos que es un servicio que nos resuelve nuestros problemas a la hora de sincronizar con los NTP (urls). Pero no solo nos da este servicio sino que a través del mismo podemos ser nosotros los que demos la hora. Es decir que podemos hacer de puente/servidor con otros clientes para que usen nuestra hora.
Comando por el cual podemos obtener o asignar la hora en nuestros servidores Linux. La parte de sincronización con servidores NTP lo usa para lo mínimo, es decir digamos que es un cliente más ligero que el propio NTPD.
Digamos que esto se creo como una alternativa más ligera o programada para ocupar el menor espacio/recursos.
Leer másHubo un cliente que quería actualizar su versión de Syspass, ya que lo habíamos hecho anteriormente y bueno esto es una guía para no morir en el intento.
Lo primero que vamos a decir es que nosotros tenemos la estructura del virtualhost del Syspass de la siguiente manera:
Una vez definido todo vamos a seguir el procedimiento oficial y lo ajustaremos a nuestra configuración del sistema.
Antes de comenzar todo esto, es recomendable realizar un backup a la base de datos (antes de la actualización). Esto es necesario por si acaso algo va mal y os quedéis sin vuestras contraseñas.
Además como hay actualización suele haber cambios en la base de datos y con versiones antiguas no funcionar.
Lo primero que haremos será acceder con nuestro usuario por SSH a nuestro virtualhost, así evitaremos que se creen con otros permisos. A su vez, generalmente, entraremos directamente en el directorio home del Syspass.
# Descargamos la versión 3.1 wget https://github.com/nuxsmin/sysPass/archive/v3.1.zip
# Descomprimimos # Ahora ya tendremos el directorio sysPass-3.1 unzip v3.1.zip ls sysPass-3.1
# Modificamos el enlace simbólico rm public_html ln -s sysPass-3.1 public_html
# Copiamos los archivos de configuración cp sysPass-3.0/app/config/* sysPass-3.1/app/config/
# Ajustamos los permisos
# Esto es fundamental, ya que sino te dará problemas de permisos en la web.
find . -type f -exec chmod 640 {} \;
find . -type d -exec chmod 750 {} \;
# Instalamos los paquetes a través del composer en el nuevo sysPass-3.1 cd sysPass-3.1 && composer install --no-dev
No cerréis la consola ya que necesitaremos una clave que la tendremos dentro del fichero sysPass-3.1/app/config/config.xml
Abrimos nuestra página web y nos pedirá un código de seguridad. Lo buscamos en nuestra shell:
grep upgradeKey sysPass-3.1/app/config/config.xml
Esta será la clave que debemos introducir a la hora de actualizar y no tardará más que 5 segundos.
Con esto hemos terminado la actualización del sysPass.
¡Hola a todos!
Se ha presentado un cliente con unas necesidades específicas de seguridad en una página web. Lo que quiere es que el acceso fuera restringido por aquellas personas que tuvieran un certificado válido X.
Para aquellos que no me hayan entendido lo que haremos en este caso es lo que hace la agencia tributaria de España.
Es decir, si quieres ver tus datos de hacienda/personales/etc … tienes que tener un certificado válido con la FNMT y tenerlo configurado en tu navegador (ya que te lo va a solicitar). Si es correcto te permite el acceso a tu área privada y sino fallará.
En realidad lo único que necesitas es tener un certificado y su CA para poder validar que el certificado con el que entras se le permite el acceso.
Os vamos a enseñar como realizar estas funciones con certificados autofirmados y luego os explicaremos como se realizaría si tuviéramos los certificados intermedios.
Leer másEn este manual vamos aprender ECR Repositorio de Imágenes.
Esto nos permite subir nuestras imágenes preparadas en un repositorio privado y gestionado por Amazon.
Vamos a suponer que ya tenemos la imagen subida en nuestro entorno local y lo que vamos hacer es reutilizarla para subirla a nuestro REPO de amazon.
Usaremos el nombre de admon-imagen
Si hemos realizado los pasos previos ya estamos listos para realizar los siguientes.
Esta será nuestra dirección de REPO:
000000000000.dkr.ecr.eu-central-1.amazonaws.com/admonrepo
Primero debemos hacer LOGIN
$(aws ecr get-login --no-include-email --region eu-central-1)
Recordamos que nuestra imagen están en el repositorio local de nuestra máquina, para ello lo comprobamos con:
docker images
Tagueamos la imagen en nuestro REPO
docker tag admon-imagen 000000000000.dkr.ecr.eu-central-1.amazonaws.com/admonrepo/admon-imagen:1.x
Siendo 1.x si queremos llegar un control de versión.
Subimos la imagen en nuestro REPO
docker push 000000000000.dkr.ecr.eu-central-1.amazonaws.com/admonrepo
Realizará una subida de la imagen en nuestro repo y se verá como la va subiendo en la shell.
The push refers to repository [000000000000.dkr.ecr.eu-central-1.amazonaws.com/admonrepo] 7453869b827a: Pushed 75e70aa52609: Pushed dda151859818: Pushed fbd2732ad777: Pushed ba9de9d8475e: Pushed
Con esto ya se puede subir las imágenes que sean necesarias para nuestro docker/eks dentro de Amazon.
Algunos de estos comandos os puede ser útil:
# Ver repositorios aws ecr describe-repositories # Ver imágenes de un repositorio aws ecr describe-images --repository-name NOMBRE-REPOSITORIO
Si continuas utilizando este sitio, aceptas el uso de las cookies. Más información
Las opciones de cookie en este sitio web están configuradas para "permitir cookies" para ofrecerte una mejor experiéncia de navegación. Si sigues utilizando este sitio web sin cambiar tus opciones o haces clic en "Aceptar" estarás consintiendo las cookies de este sitio.