Blog de Amazon Web Services (AWS)
Proteja sus Bases de Datos RDS con Amazon GuardDuty.
Por Jhonattan Vega, arquitecto de soluciones
Introducción:
Las bases de datos albergan información crítica para las compañías, que incluye datos personales e información sensible de los usuarios. Esta situación las convierte en un objetivo principal para los atacantes que buscan afectar, robar o secuestrar los datos con el propósito de obtener una recompensa a cambio de su recuperación o simplemente destruir los datos para dañar la reputación. Amazon GuardDuty es un servicio de supervisión y detección de amenazas que le ayuda a analizar y perfilar inicios de sesión en sus bases de datos RDS lo cual le permite identificar inicios de sesión sospechosos o anómalos.
Nota: En este ejercicio se utilizan herramientas y configuraciones no recomendados o que no siguen las buenas prácticas y se indican claramente al momento de su explicación, esto solamente para propósitos demostrativos del ejercicio.
Descripción del funcionamiento de Amazon GuardDuty
Amazon GuardDuty es un servicio de monitoreo de seguridad que analiza y procesa fuentes de datos, como eventos de AWS CloudTrail, registros de flujo de VPC y registros de DNS. También procesa funciones como los registros de auditoría de Kubernetes, la actividad de inicio de sesión de RDS, los registros de S3, los volúmenes de EBS, y los registros de actividad de Lambda. Utiliza fuentes de inteligencia de amenazas, como listas de direcciones IP, dominios maliciosos y aprendizaje automático para identificar actividades inesperadas, potencialmente no autorizadas y maliciosas dentro de su entorno.
RDS Protection en Amazon GuardDuty analiza y perfila la actividad de inicio de sesión de RDS para encontrar posibles amenazas de acceso a sus bases de datos de Amazon Aurora (Amazon Aurora MySQL-Compatible Edition y Aurora PostgreSQL-Compatible Edition). Esta función le permite identificar comportamientos de inicio de sesión potencialmente sospechosos. RDS Protection no requiere infraestructura adicional; está diseñado para no afectar el rendimiento de las instancias de su base de datos.
Nota:
Cuando habilita la protección de RDS por primera vez o tiene una instancia de base de datos recién creada, se requiere un período de aprendizaje para establecer la base de referencia del comportamiento normal. Por este motivo, es posible que las instancias de bases de datos recién habilitadas o creadas no tengan un hallazgo de inicio de sesión anómalo asociado durante un máximo de dos semanas.
Recomendamos validar los costos asociados tanto para Amazon RDS, como para Amazon GuardDuty.
Tutorial:
Este tutorial incluye el uso de los servicios Amazon RDS (Relational Database Service), Amazon CloudWatch Logs, Amazon GuardDuty y herramientas de Penetration Test.
Requisitos Previos:
1- Una cuenta de AWS.
2- Rol o usuario que tenga acceso para la creación de los recursos de AWS: Amazon RDS (Relational Database Service), Amazon CloudWatch Logs, Amazon GuardDuty. Sugerimos revisar y seguir las prácticas recomendadas de seguridad en IAM (Identity Access Management).
3- Software para acceder y administrar las bases de datos, en este caso se sugiere usar pgAdmin (Opcional).
4- En este caso específico, se emplean herramientas de penetration testing, siendo el tutorial enfocado en el uso de Hydra en Kali Linux para llevar a cabo un ataque de fuerza bruta. Sugerimos revisar la política de “Penetration Test” de AWS antes de avanzar.
5- Configuración de VPC, Subnets, NACLs y Security Groups que permitan acceso desde el exterior a la instancia de base de datos RDS-
Guía
1- Creación Base de datos Amazon Aurora PostgreSQL.
– Ir a Amazon RDS y hacer clic en “Create Database”
– Seleccionar la opción de “Aurora (PostgreSQL compatible).
– Seleccionar una versión soportada por Amazon GuardDuty, en este caso usaremos la versión 14.6.
– Luego crearemos los datos de acceso a nuestra base de datos, usuario y contraseña.
– Para nuestro ejercicio vamos dejar nuestra base de datos con acceso a Público.
Nota:
Como práctica recomendada de seguridad, sus instancias de RDS solo deben exponerse internamente a través de su VPC y grupo de seguridad únicamente a las instancias que necesitan comunicarse con la base de datos.
A menos que exista un requisito comercial específico, las instancias de RDS no deben tener un punto final público.
Nota: recordar la configuración de la VPC, Subnets, Security Groups y NACL que permitan acceso desde el exterior (revisar prerrequisitos punto 4).
– Activamos la opción de Log exports / PostgreSQL Log
Las demás configuraciones se deben dejar por defecto.
– Finalmente hacemos clic en el botón de “Create Database”.
– Debemos esperar a que concluya la creación de la base de datos y el “status” indique que está disponible.
2- Activación del servicio de Amazon GuardDuty: (en caso de estar activo el servicio por favor ir al apartado “RDS Protection” que está dos puntos adelante).
– En la barra de búsqueda de la consola de AWS, buscar Amazon GuardDuty y luego hacer clic en el botón
– Revisar los permisos que activa y requiere el servicio de Amazon GuardDuty, luego clic en “Enable GuardDuty”.
– Vamos en el menú de la izquierda a la opción de “RDS Protection” y verificamos que la característica este activa, de lo contrario procedemos a activarla.
3- Probar la conexión usando el administrador de bases de datos pgAdmin. (Paso opcional)
– Agregamos un nuevo servidor en la consola de administración.
– Indicamos un nombre de servidor
– Agregamos los datos de conexión a la instancia de base de datos RDS, indicando Hostname, que es el endpoint en la consola de AWS, Puerto, Username y Password
– Finalmente hacemos clic en “Save” para ver el acceso a la base de datos.
4- Prueba de ataque de acceso a la base de datos de un ataque de fuerza bruta “penetration testing” usando Hydra.
Nota: Para este ejercicio usaremos el entrono gráfico de Hydra, sin embargo, también es posible ejecutar estas tareas usando la CLI.
Recordar que es posible que las instancias de bases de datos recién habilitadas o creadas no tengan un hallazgo de inicio de sesión anómalo asociado durante un máximo de dos semanas.
– En la pestaña target, vamos a agregar la información de los siguientes campos:
Single Target: Indicar el endpoint de la base de datos.
Port: 5432
Protocol: Postgres
– En la pestaña Passwords, vamos a cargar un diccionario de usuarios y de contraseñas con las que la herramienta va a intentar el ataque de fuerza bruta a la base de datos.
Nota: En este caso se va a utilizar el diccionario que viene por defecto en Hydra, sin embargo, se puede usar cualquier diccionario soportado por la herramienta.
– Finalmente en la pestaña “Start” hacemos clic en “Start” para iniciar la prueba.
– Después de un momento podremos ver los intentos de Hydra para autenticarse en la base de datos:
Luego del ataque simulado con Hydra, tendremos visibilidad de estos intentos de acceso no autorizado detectados y analizados por Amazon GuardDuty, con lo cual podemos ver el reporte del hallazgo y el análisis realizado.
5- Monitoreo de los Logs usando Amazon CloudWatch Logs (Paso opcional)
– Verificación de los intentos mediante los Logs de Amazon CloudWatch Logs, para esto buscamos el Log Stream con el nombre de la instancia de base de datos de RDS.
Podremos ver la información de los intentos, incluidos fecha, hora, IP de origen y resultado del intento.
6- Detección y visualización del ataque de fuerza bruta usando Amazon GuardDuty.
– Hallazgo de Amazon GuardDuty ante el intento de ataque de fuerza bruta, en este nos indicará el recurso que está siendo atacado (instancia de base de datos RDS), tipo de hallazgo (Ataque de fuerza bruta), información adicional como hora y fecha del intento y si el resultado del ataque fue satisfactorio o fue un intento.
– Adicionalmente Amazon GuardDuty entrega información detallada tanto del intento de ataque como de la información del recurso que fue atacado.
– La información encontrada en el hallazgo incluye por Amazon GuardDuty incluye:
- Nombre del tipo de hallazgo: esta es una categoría que se da basado en el tipo de ataque o anomalía detectada, ver la descripción completa y categorías en el siguiente enlace.
- Descripción del tipo de hallazgo, Una descripción detallada del hallazgo describiendo el tipo de ataque o anomalía y el recurso afectado.
- Severidad del hallazgo: Amazon GuardDuty categoriza la severidad en nivel Bajo, Medio y Alto de la siguiente manera, Bajo: si el nombre de usuario asociado con este hallazgo intentó inició sesión desde una dirección IP asociada con una red privada. Medio: si el nombre de usuario asociado con este hallazgo intentó inició sesión desde una dirección IP pública y Alto: si hay un patrón constante de intentos fallidos de inicio de sesión desde direcciones IP públicas que indican políticas de acceso demasiado permisivas.
- Región y zona de disponibilidad donde se detectó el hallazgo.
- Detalles del recurso afectado, como ARN, nombre y tipo de recurso.
- Hora y fecha del hallazgo.
Nota: Amazon GuardDuty permite detectar y reportar los hallazgos, adicional tiene la posibilidad de crear un flujo completo de acción a seguir que van desde notificaciones a los equipos involucrados en el incidente como planes de remediación automatizados, revisar opciones completas en el siguiente enlace.
7-Limpieza:
Algunos elementos utilizados en este taller generan un costo por su uso, por lo que sí está realizando este taller en una cuenta personal con fines de aprendizaje, recomendamos desactivar estos servicios:
– Desactivar Amazon GuardDuty:
Desde la consola, vaya a Amazon GuardDuty/Settings, luego haga clic en Disable GuardDuty.
– Elimine la instancia de base de datos RDS (Solo en caso la instancia haya sido creada específicamente para este taller):
Referirse a la documentación de como eliminar una instancia en RDS.
Conclusión:
En esta simulación, se han identificado varios tipos de ataques, como Intentos de acceso anómalos y Ataque de fuerza bruta, lo que subraya la importancia de contar con una sólida estrategia de seguridad. Para estar preparados ante cualquier amenaza, es fundamental seguir las recomendaciones de seguridad de Amazon RDS. Estas directrices nos permitirán proteger aspectos críticos como el proceso de autenticación, la rotación automatizada de credenciales, la protección de datos en reposo y en tránsito, el cumplimiento normativo y la seguridad a nivel de redes, entre otros aspectos esenciales.»
Sobre el Autor:
Jhonattan Vega es un arquitecto de soluciones para partners en Colombia, se especializa en temas de gestión de infraestructura y seguridad informática. Apasionado por la tecnología y los deportes.