DEV Community: Willie Reyes

Cloudfront Functions, WAF

Willie Reyes — Fri, 28 Nov 2025 16:26:19 +0000

Today we gonna to explain a particulary scenario in which the main idea is allow only specific ip address to reach a web site exposed using cloudfront.

this is the architecture

Before to start we need to explain differents resources inside aws

Simple Storage Service or S3 (buckets)
Is the most use service for object storage, you can save here any kind of file.

Cloudfront
Is the CDN or Content Delivery Network in AWS, this allows to that users around the globe use your web applications or apis in a faster and reliable way because the concept of CDN is to offer cache in the most near point of presence of aws, for example assume that you have clients in Europe and your application is hosted in Virginia, when you use cloudfront you application take less time to load at the final user than if you haven't this services.

Cloudfront functions
Is an improve options to allow deploy differents features to our sites, for example if you want to fix vulnerabilities related to HSTS in your sites you can use specific function to add this headers to our sites, or for example like this case if you want to allow only few ip address to reach your site and block the rest of the internet you can use specific functions to this.

WAF
Web Application Firewall native in AWS is the layer 7 security feature to protect our api web apps and others, this works with ALB, API gateway, Cloudfront and others resources inside AWS.

The common architecture for deploying statics sites in aws is using the architecture S3 bucket to public the site and integrate that with Cloudfront

To secure this architecture is important to never expose the bucket s3 to internet directly and that is the reason of using cloudfront.

You can configure this at origin option in cloudfront and copy the policy to the bucket s3 that has your web site

copy the policy OAC to the s3 bucket

In the s3 bucket you have this enable for S3 static website hosting

when you try to reach the url show a error message this is because the OAC configuration.

another security configuration is this one "Block public access" this is a must.

so once you have your application working using cloudfront + S3 now we explain the scenario.

Some X company wants to only allow a specific ip from a VPN services to reach the site exposed in cloudfront.

for doing this you can use WAF or cloudfront functions

In waf you can configure custom rules one for allow the specific ip address and then at default action you can put as block.

the expected behavior is that when you use the vpn the site loads correctly and without show a 403 error.

the whitelist rule is this

the default block is here

when I did the test show error whitout the vpn

and with the vpn works fine the site

be aware if you have some custom error pages at the cloudfront configuration because this can cause issues

Finally I check in waf console and see some blocks and some allow traffic

the other option is using cloudfronts functions

you need to create a function and associate with the cloudfront distribution

this is the function code

function handler(event) {
    var request = event.request;
    var clientIP = event.viewer.ip;

    // Tu IP de VPN (puedes agregar múltiples)
    var allowedIPs = [
        '45.45.45.45'
    ];

    // Verificar si la IP está permitida
    if (allowedIPs.indexOf(clientIP) === -1) {
        // IP no permitida - retornar 403
        return {
            statusCode: 403,
            statusDescription: 'Forbidden',
            headers: {
                'content-type': { value: 'text/html; charset=utf-8' },
                'cache-control': { value: 'no-store' }
            },
            body: {
                encoding: 'text',
                data: '<html><head><title>Access Denied</title></head><body><h1>403 - Access Denied</h1><p>VPN connection required to access this resource.</p></body></html>'
            }
        };
    }

    // IP permitida - continuar normalmente
    return request;
}

then you need to publish your function and associated with the distribution

finally do some test and works similar to aws WAF.

without vpn

with vpn

I hope that this help

to the next time.

Logs de AWS ALB with Athena

Willie Reyes — Fri, 28 Nov 2025 02:04:33 +0000

Un aspecto importante en seguridad es contar con logs, en AWS se pueden activar algunos logs importantes en diferentes recursos por ejemplo a nivel de Virtual Private Cloud VPC es mandatorio activar los flow logs para poder analizar trafico entre los recursos que se encuentran dentro de la VPC o que tienen una ENI o interfaz de red.

En este post vamos a realizar una configuracion para configurar logs en los ALB o Application Load Balancer, este recurso me permite poder exponer mis aplicaciones web hacia el internet o tambien de manera privada dentro de mi private subnet.

El ALB cuenta con dos configuraciones para logs una es los logs de acceso que registran las peticiones http dentro de los campos mas importantes tenemos el tipo de conexion el timestamp ip y puerto cliente asi como la direccion ip y puerto destino luego podemos revisar por codigo de respuesta asi como el uri path ,el user agent y el tipo de peticion POST GET estos logs nos sirve para ver con mayor detalle el tipo de request que esta recibiendo el balanceador y poder identificar patrones de ataque existen otros campos que a mas detalles lo puedes encontrar en este link. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html

Luego tenemos logs de conexion este nos facilita informacion detallada de las peticiones enviadas al balanceador este log nos da cierta informacion como direccion ip y puerto del cliente, el puerto listener las configuraciones de TLS entre otras que nos sirve para poder determinar algun tema de latencia o tiempo de respuesta, aqui el detalle de los campos del log de conexion.
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-connection-logs.html

ok entonces para poder revisar estos logs la primera acción es habilitar dicha configuración a nivel de los atributos del balanceador.

en la parte final de la configuracion de atributos o parametros encontramos la seccion de monitoreo

para modificar dichos parametros damos click en editar atributos y nos dirigimos al final en donde podemos configurar el bucket s3 destino que guardara todos los logs

En este caso solametne activare los logs de acceso.

Para esto ya se debe contar con un bucket s3 creado y configurar con una politica especifica que se detalla acontinuacion.

{
  "Version":"2012-10-17",                
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logdelivery.elasticloadbalancing.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix/AWSLogs/123456789012/*"
    }
  ]
}

Una vez creada esta configuracion en el balanceador se crearan carpetas dentro del s3 siguiendo este formato.

AWSLogs/#decuenta/elasticloadbalancing/region/2025/mes/dias

Dentro de la carpeta de cada ustedes visualizaran ya los diferentes archivos con formato del numero de cuenta el nombre del balanceador y con una extension log.gz, dependiendo de la cantidad de trafico que reciba su aplicacion pueden ser miles de archivos

Para poder realizar un analisis en estos archivos debemos usar el servicio de Athena

Amazon Athena es un servicio interactivo para realizar querys o consultas a datos que se encuentren en buckets S3 usando el estandar SQL.

Para activar la configuracion en athena ingresamos y buscamos la seccion de editor de querys

Aqui va a solicitar la creacion o el uso de un bucket s3 para guardar los resultados de las consultas que se realicen

Aqui seleccionamos el bucket s3 destino y asi nos dejara continuar con las configuraciones

Luego procedemos a crear nuestra base de datos para dentro de esta poder crear las tablas que se enlazaran a nuestros de logs de balanceador en el S3

Usamos el query. CREATE DATABASE AWSLOGS

Luego podemos crear la tabla utilizando el siguiente query

CREATE EXTERNAL TABLE IF NOT EXISTS alb_access_logs ( type string, time string, elb string, client_ip string, client_port int, target_ip string, target_port int, request_processing_time double, target_processing_time double, response_processing_time double, elb_status_code int, target_status_code string, received_bytes bigint, sent_bytes bigint, request_verb string, request_url string, request_proto string, user_agent string, ssl_cipher string, ssl_protocol string, target_group_arn string, trace_id string, domain_name string, chosen_cert_arn string, matched_rule_priority string, request_creation_time string, actions_executed string, redirect_url string, lambda_error_reason string, target_port_list string, target_status_code_list string, classification string, classification_reason string, conn_trace_id string ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe' WITH SERDEPROPERTIES ( 'serialization.format' = '1', 'input.regex' = '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) (.*) (- |[^ ]*)\" \"([^\"]*)\" ([A-Z0-9-_]+) ([A-Za-z0-9.-]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^\"]*)\" ([-.0-9]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^ ]*)\" \"([^\\s]+?)\" \"([^\\s]+)\" \"([^ ]*)\" \"([^ ]*)\" ?([^ ]*)? ?( .*)?' ) LOCATION 's3://amzn-s3-demo-bucket/access-log-folder-path/'

Aqui debemos editar la configuracion del S3

s3://logsawsalb/AWSLogs/123456789/elasticloadbalancing/us-east-1/'

una vez editado ejecutamos el query y posterior a esto ya podemos ejecutar diferentes querys para poder identificar por ejemplo las direcciones ip con mas trafico en un determinado tiempo

SELECT client_ip,
       COUNT(*) as request_count
FROM alb_access_logsnonpartioned
WHERE time >= '2025-11-27T13:30:00'
  AND time < '2025-11-27T13:40:00'
GROUP BY client_ip
ORDER BY request_count DESC;

o uno similar a este para poder ver los request en tiempo especifico.

SELECT *
FROM alb_access_logsnonpartioned
WHERE time >= '2025-11-27T13:30:00'
  AND time < '2025-11-27T13:40:00'
ORDER BY time DESC;

y de esta manera poder realizar un análisis adecuado para resolución de problemas o incidentes de seguridad.

Espero que les sea de utilidad.

hasta una proxima entrega

Creación de Peering Connections en AWS.

Willie Reyes — Wed, 05 Nov 2025 19:32:22 +0000

En este post vamos a detallar el paso a paso para la creacion de un peering conection en aws, que nos sirve para establecer la comunicacion entre dos VPC, esto es recomendado en casos de cuentas que tengan un numero limitado de vpc o para algun caso especifico que se requiera establecer la comunicacion, para multiples VPC o tambien para interconectar con Redes en Onpremise es mejor utilizar un transit gateway.

El escenario es el siguiente

Desde una ec2 en una vpc se quiere comunicar con otra ec2 en otra vpc

Los pasos para realizar esta comunicacion serian:

Identificar VPC Origen y VPC destino
Identificar Subnets de Ec2 asi como la direccion privada de las ec2.
Identificar puertos de comunicacion
Establecer el Peering Conection
Configurar las tablas de rutas
Configurar permisos en ACL si es el caso
Configurar permisos en Security Groups de las Instancias

Diagrama

Para realizar la configuracion nos ubicamos en VPC y buscamos la opcion Peering Connection

Damos click en la opcion crear peering connection
Configuramos las vpc requester y accepter aca podemos ver opciones de si se encuentra en la misma cuenta o misma region.

una vez realizado podemos ver que se establece pero hay que realizar una aceptacion esto ocurre dado que puede que la conexion puede realizar entre alguna otra cuenta que no tengas administracion ejemplo conexion entre dos empresas que tienen sus cargas de trabajo en aws.

Una vez realizado este paso identificamos las subnets y las tablas de rutas de cada vpc y configuramos las rutas para que puedan comunicar estas dos subnets a traves del nuevo peering conection que hemos creado.

Al configurar la ruta tenemos que agregar que para alcanzar la otra red se utilize el peering.

Si cuentan con ACLs a nivel de VPC tambien deben otorgar permisos y finalmente en los security groups de la instancia.

Finalmente podemos realizar pruebas de conectividad con telnet.

Reglas Personalizadas en Web Application Firewall nativo AWS

Willie Reyes — Sun, 02 Nov 2025 20:24:59 +0000

Este post es basado en la presentacion que realize en el evento de la comunidad de AWS Ecuador

Temas

Evolución de reglas básicas a custom rules avanzadas
Casos de uso reales de implementación
Integración con CloudFront, ALB
Métricas y monitoreo con CloudWatch

Características principales WAF

Protección en tiempo real
Filtrado de tráfico basado en reglas personalizables
Inspección profunda de headers, body y query strings
Respuesta automática a amenazas detectadas

Integración nativa con AWS

Compatible con CloudFront, Application Load Balancer, API Gateway
Despliegue rápido sin cambios en infraestructura
Escalabilidad automática según demanda

Control granular

Reglas personalizadas según necesidades específicas
Listas blancas y negras de IPs
Rate limiting para prevenir ataques DDoS

Monitoreo y visibilidad

Métricas en tiempo real en CloudWatch
Logs detallados de todas las solicitudes
Dashboards para análisis de seguridad

AWS Reglas Gestionadas (Managed Rules)

¿Qué son?
Reglas preconfiguradas mantenidas por AWS y terceros
Se actualizan automáticamente con nuevas amenazas
Fáciles de implementar sin experiencia en seguridad

AWS Reglas Gestionadas (Managed Rules)

Core Rule Set (CRS)

Protección contra vulnerabilidades OWASP Top 10
Inyección SQL, XSS, inclusión de archivos
Reglas generales para aplicaciones web

Known Bad Inputs

Bloquea patrones de ataque conocidos
Exploits comunes y técnicas de evasión
Firmas de malware y herramientas de hacking

Mejores prácticas

Comenzar en modo Count
Implementar gradualmente
Monitorear falsos positivos
Documentar configuraciones

Ventajas de las reglas gestionadas

Mantenimiento automático
Experiencia de expertos en seguridad
Implementación inmediata
Cobertura amplia de amenazas

Configuración de logging

Habilitar logs en Web ACL
Destino: CloudWatch Logs, S3, Kinesis
Formato JSON estructurado
Retención configurable

Hasta este punto todo puede ir perfecto en la configuración de WAF con solo un par de clicks al habilitar las reglas.

Desafíos al usar las reglas gestionadas por AWS.

Al usar reglas gestionadas por AWS pueden ocurrir problemas con el funcionamiento correcto de una aplicación por el bloqueo de tráfico legítimo debido a la complejidad de las diferentes aplicaciones y/o el uso de patrones no adecuados en el desarrollo de software, lo recomendable es validar con la acción contar antes del bloqueo y al activar las reglas de contar a bloqueo comenzar a monitorear la aplicación.

Aparecen los problemas ciertas opciones dentro del uso de la aplicación comienzan a fallar y todos te miran feo jaja

Solución

Identificar las reglas que ocasionaron problemas con la aplicación, analizar el request y los diferentes valores dentro del mismo como los métodos HTTP: GET, POST, PUT, DELETE, PATCH, etc. el URI/Path: La ruta del recurso solicitado el cuerpo del request en general, encontrar porque la regla administrada hizo match con el tráfico legítimo de la aplicación.
Revisar patrones de ataques recibidos
Revisar y revisar logs de tráfico.
Crear reglas personalizadas para comenzar a limpiar tráfico malicioso.

Configuración y Habilitación

La primera regla recomendada es regla basada en ip, esta regla me ayuda a bloquear o permitir tráfico, un caso de uso puede ser también configurar una lista blanca de direcciones ip para que tráfico legítimo de algún proceso no se vea afectado.

Antes de avanzar con la configuración de reglas personalizadas vamos a detallar qué son los WCU y qué impacto tienen en la facturación.

WCU en AWS WAF

Los WCU (Web ACL Capacity Units) son unidades de capacidad que miden la complejidad computacional de las reglas en AWS WAF.

¿Cómo funcionan?

Cada regla que añades a tu Web ACL consume una cantidad determinada de WCU según su complejidad:

Reglas simples: 1 WCU (ej: bloquear una IP específica)
Reglas con expresiones regulares: 3-10 WCU
Reglas de rate limiting: 2 WCU
Reglas administradas de AWS: varían (generalmente 10-50 WCU)
Reglas de grupos de terceros: pueden variar significativamente

Límites
Límite por defecto: 1,500 WCU por Web ACL
Puedes solicitar aumentos a AWS Support si necesitas más capacidad

Costos de AWS WAF

El modelo de precios incluye:

Web ACL: ~$5.00/mes por Web ACL
Reglas: ~$1.00/mes por regla
Requests: ~$0.60 por millón de requests

Nota importante sobre WCU y costos: Los WCU NO se cobran directamente. Son solo una medida de capacidad computacional para gestionar el límite de complejidad de tu Web ACL. Pagas por la cantidad de reglas y requests, no por los WCU consumidos.

La segunda regla recomendada es regla basada en tasas (rate based) ayuda a limitar la cantidad de request en una ventana específica de tiempo, para esto se puede analizar en promedio el tráfico que se recibe desde un cliente (IP) y analizar cuantos request por minuto envía, basado en un promedio se puede configurar por ejemplo 1000 request por minuto e ir evaluando el tráfico.
El request 1001 sera bloqueado automaticamente

Luego podemos ir agregando reglas basadas en ataques comunes, por ejemplo si las reglas administradas por aws no funcionan del todo se crean este tipo de reglas para limpiar tráfico malicioso.
Tienen opción de hacerlo directo en la consola o configurar en formato json.

Esta regla sirve para restringir peticiones comunes de ataques a servidores php wordpress entre otros.
Analiza por extensión de archivo .php o por texto dentro de la petición.

Parte fundamental para monitorear el trafico es la revisión de logs, pueden usar Data Firehose para luego ver con athena o enviar a cloudwatch grupo de logs o log groups y realizar sentencias SQL o Log Insights QL

En la configuración de la regla se activa el registro o log y se coloca como destino cloudwatch loggroups

Top IPs bloqueadas
sql
fields @timestamp, httpRequest.clientIp, action
| filter action = "BLOCK"
| stats count() by httpRequest.clientIp
| sort count desc
| limit 10

Análisis de reglas activadas
sql
fields @timestamp, terminatingRuleId, action
| filter action = "BLOCK"
| stats count() by terminatingRuleId
| sort count desc

Alertas recomendadas

Análisis de reglas activadas
sql
fields @timestamp, terminatingRuleId, action
| filter action = "BLOCK"
| stats count() by terminatingRuleId
| sort count desc

Reglas administradas AWS WAF Owasp Top Ten

Willie Reyes — Wed, 04 Jun 2025 16:22:25 +0000

El dia de hoy vamos a revisar el grupo de reglas administradas que existen dentro de Amazon Web Services del servicio de seguridad Web Application Firewall.

Amazon ofrece este servicio nativo para proteger las cargas de trabajo, se puede realizar una integracion entre los siguientes servicios.

CloudFront Distribución en Amazon
API de REST de Amazon API Gateway
Equilibrador de carga de aplicación
AWS AppSync API GraphQL
Grupo de usuarios de Amazon Cognito
AWS App Runner servicio
AWS Instancia de acceso verificado
AWS Amplify

AWS WAF es un firewall de aplicaciones web que permite revisar las peticiones http y https que se envian a sus aplicaciones o cargas de trabajo expuestas a internet.

Este servicio tiene multiples beneficios y configuraciones, pero hoy vamos a revisar un conjunto de reglas escencial para la proteccion de sus aplicaciones, este grupo de reglas del conjunto de reglas básicas (CRS) contiene reglas que son generalmente aplicables a las aplicaciones web. Este brinda protección contra la explotación de una amplia gama de vulnerabilidades, incluyendo algunas de las vulnerabilidades de alto riesgo y más comunes descritas en publicaciones de OWASP tales como Owasp Top 10.

Que es Owasp Top 10?

El Top 10 de OWASP es un documento estándar de concientización para desarrolladores y seguridad de aplicaciones web

Cada cierto tiempo este documento se actualiza en base a cambios de patrones de ataques mas comunes, el ultimo es del anio 2021

En esta pagina esta el detalle de cada una de las 10 vulnerabilidades mas comunes.

De igual manera en la siguiente pagina de aws se muestra el detalle de las reglas basicas que estan basadas en owasp top 10.

NoUserAgent_HEADER

Inspecciona las solicitudes a las que les falta el encabezado HTTP User-Agent.

UserAgent_BadBots_HEADER

Comprueba si hay valores de encabezado User-Agent comunes que indiquen que la solicitud es un badbot. Los patrones de ejemplo incluyen nessus y nmap. Para obtener información sobre la administración de bots, consulte también AWS WAF Grupo de reglas de control de bots.

SizeRestrictions_QUERYSTRING

Inspecciona las cadenas de consulta de URI que superen los 2048 bytes.

_SizeRestrictions_Cookie_HEADER _
Comprueba si los encabezados de las cookies tienen más de 10 240 bytes.

_SizeRestrictions_BODY _
Inspecciona los cuerpos de las solicitudes que pesen más de 8 KB (8192 bytes).

SizeRestrictions_URIPATH

Inspeccione las rutas de URI que superen los 1024 bytes.

EC2MetaDataSSRF_BODY

Inspecciona los intentos de extraer los metadatos de EC2 Amazon del cuerpo de la solicitud.

EC2MetaDataSSRF_COOKIE

Inspecciona los intentos de extraer los metadatos de EC2 Amazon de la cookie de solicitud.

EC2MetaDataSSRF_URIPATH

Inspecciona los intentos de extraer los metadatos de EC2 Amazon de la ruta del URI de la solicitud.

EC2MetaDataSSRF_QUERYARGUMENTS

Inspecciona los intentos de extraer los metadatos de EC2 Amazon de los argumentos de la consulta de la solicitud.

GenericLFI_QUERYARGUMENTS
Inspecciona la presencia de vulnerabilidades Local File Inclusion (LFI, Inclusión Local de Archivos) en los argumentos de la consulta. Los ejemplos incluyen los intentos de recorrido de ruta utilizando técnicas como ../../.

GenericLFI_URIPATH

Inspecciona la presencia de vulnerabilidades Local File Inclusion (LFI, Inclusión Local de Archivos) en la ruta del URI. Los ejemplos incluyen los intentos de recorrido de ruta utilizando técnicas como ../../.

GenericLFI_BODY

Inspecciona la presencia de vulnerabilidades Local File Inclusion (LFI, Inclusión Local de Archivos) en el cuerpo de la solicitud. Los ejemplos incluyen los intentos de recorrido de ruta utilizando técnicas como ../../.

RestrictedExtensions_URIPATH

Comprueba si hay solicitudes cuyas rutas de URI contengan extensiones de archivos del sistema que no sean seguras de leer o ejecutar. Los patrones de ejemplo incluyen extensiones como .log y .ini.

RestrictedExtensions_QUERYARGUMENTS

Inspecciona las solicitudes cuyos argumentos de consulta contienen extensiones de archivo cuya lectura es insegura. Los patrones de ejemplo incluyen extensiones como .log y .ini.

GenericRFI_QUERYARGUMENTS
Inspecciona los valores de todos los parámetros de consulta para detectar intentos de aprovechar la RFI (inclusión remota de archivos) en aplicaciones web mediante la incrustación URLs de direcciones. IPv4 Los ejemplos incluyen patrones comohttp://,https://, y ftp:// ftps://file://, con un encabezado de IPv4 host en el intento de explotación.

GenericRFI_BODY

Inspecciona el cuerpo de la solicitud para detectar intentos de aprovechar la RFI (inclusión remota de archivos) en aplicaciones web mediante incrustaciones URLs que contienen direcciones. IPv4 Los ejemplos incluyen patrones comohttp://,https://, y ftp:// ftps://file://, con un encabezado de IPv4 host en el intento de explotación.

GenericRFI_URIPATH

Inspecciona la ruta del URI para detectar intentos de aprovechar la RFI (inclusión remota de archivos) en aplicaciones web mediante incrustaciones URLs que contienen direcciones. IPv4 Los ejemplos incluyen patrones comohttp://,https://, y ftp:// ftps://file://, con un encabezado de IPv4 host en el intento de explotación.

CrossSiteScripting_COOKIE
Inspecciona los valores de los encabezados de las cookies para detectar patrones comunes de secuencias de comandos entre sitios (XSS) mediante la función integrada. AWS WAF Instrucción de regla de ataques de scripting entre sitios Los patrones de ejemplo incluyen scripts como alert("hello").

CrossSiteScripting_QUERYARGUMENTS
Inspecciona los valores de los argumentos de consulta para detectar patrones comunes de secuencias de comandos entre sitios (XSS) mediante la función integrada. AWS WAF Instrucción de regla de ataques de scripting entre sitios Los patrones de ejemplo incluyen scripts como alert("hello").

CrossSiteScripting_BODY

Inspecciona el cuerpo de la solicitud para detectar patrones comunes de secuencias de comandos entre sitios (XSS) mediante la función integrada. AWS WAF Instrucción de regla de ataques de scripting entre sitios Los patrones de ejemplo incluyen scripts como alert("hello").

CrossSiteScripting_URIPATH

Inspecciona el valor de la ruta URI en busca de patrones comunes de secuencias de comandos entre sitios (XSS) mediante la función integrada. AWS WAF Instrucción de regla de ataques de scripting entre sitios Los patrones de ejemplo incluyen scripts como alert("hello").

Lo recomendado es siempre probar estas reglas en ambientes controlados como puede ser desarrollo QA u otro ambiente en donde puedan evaluar la funcionalidad e identificar que estas reglas no afecten el correcto funcionamiento de la aplicacion web.

Las reglas tienen opciones de configuracion como son:

Allow— AWS WAF permite reenviar la solicitud al AWS recurso protegido para su procesamiento y respuesta. Se trata de una acción de finalización.

Block— AWS WAF bloquea la solicitud. Se trata de una acción de finalización. De forma predeterminada, el AWS recurso protegido responde con un código de 403 (Forbidden) estado HTTP.

Count— AWS WAF cuenta la solicitud pero no determina si se permite o se bloquea. Se trata de una acción no terminal. AWS WAF continúa procesando las reglas restantes en la ACL web.

CAPTCHA y Challenge— AWS WAF utiliza acertijos CAPTCHA y desafíos silenciosos para comprobar que la solicitud no proviene de un bot, y AWS WAF utiliza fichas para hacer un seguimiento de las respuestas recientes de los clientes que han obtenido buenos resultados.

Configuracion

Para este caso vamos a agregar el web application firewall en el recurso Cloudfront.

1.- Ingresamos a la consola de AWS y buscamos WAF

2.- Una vez dentro de esta opcion vamos a la seccion de "Create web ACL"

Y agregamos la informacion como es el nombre

automaticamente se anade la data de Cloudwatch Metric Name.

Esta parte es importante para luego poder analizar los logs que genera el WAF.

3.- Escogemos la distribucion de Cloudfront

Esta opcion la podemos modificar posteriormente dado que se debe analizar tambien los costos que genera la proteccion usando WAF

4.- En este punto agregamos las reglas o conjuntos de reglas, para nuestro ejemplo vamos a utilizar Reglas que son manejadas por AWS.

5.- Buscamos y escogemos las reglas Core Rule Set o conjunto de reglas basicas y hacemos click en "Add Rules" o Agregar Reglas.

6.- En este punto revisamos las reglas o conjunto de reglas que hemos agregado, tambien podemos visualizar el total de WCU (Web ACL Capacity Units) que es la unidad de medida que AWS utiliza para calcular cuanta capacidad consumen las reglas en una ACL especifica.

El uso de WCU afecta directamente al costo mensual de AWS WAF porque el precio se basa en dos factores principales:

Número de Web ACLs que creas.
Cantidad total de WCU consumidos por cada Web ACL.
Número de solicitudes web inspeccionadas (este es otro factor, no directamente relacionado con los WCU, pero también influye en el costo).

| Concepto                   | Precio estimado mensual |
| -------------------------- | ----------------------- |
| Web ACL (por ACL)          | \~\$5 USD               |
| Por cada WCU (mensual)     | \~\$0.60 USD            |
| Solicitudes inspeccionadas | \~\$0.60 por 1 millón   |

7.- En este punto detallamos las opciones de accion de la regla, como es un ambiente de pruebas vamos a colocar la accion de bloqueo.

8.- El siguiente paso es la prioridad de las reglas, como solamente hemos agregado una sola regla dejamos por defecto y damos en siguiente

9.- Como fue indicado anteriormente las metricas es necesario activarlas para poder analizar el trafico y la respuesta de cada request sobre las reglas.

10.- Como paso final vemos el resumen de todo lo que va a crear y damos click en "Crear Web ACL"

Luego podemos confirmar que en la seccion de seguridad de la distribucion de cloudfront se muestre la web ACL.

Esto seria todo por ahora, en una proxima entrega vamos a detallar como poder hacer analisis de logs y poder ir validando el funcionamiento de las diferentes reglas de WAF basadas en owasp top 10 y si requieren de un afinamiento o modificacion.

Espero que les haya gustado este post y que sea de utilidad para garantizar la proteccion de aplicaciones web que se exponen en sus organizaciones.

Entendiendo los Identificadores ARN y AIDA en AWS IAM

Willie Reyes — Thu, 21 Nov 2024 20:30:02 +0000

AWS Identity and Access Management (IAM) es la columna vertebral de la seguridad en AWS, y dos de sus identificadores más importantes son ARN (Amazon Resource Name) y AIDA (IAM User/Role ID). En este artículo, exploraremos qué son, para qué sirven y un dato importante sobre qué sucede si eliminas y vuelves a crear usuarios.

Amazon Resource Name (ARN)

¿Qué es un ARN?
Un ARN (Amazon Resource Name) es un identificador único que AWS utiliza para identificar cualquier recurso en su plataforma. Es esencial para las políticas de acceso y la auditoría, ya que permite especificar con precisión los recursos involucrados en una operación.

arn:partition:service:region:account-id:resource

Componentes principales:

partition: Especifica la partición de AWS, como aws, aws-cn (China) o aws-us-gov (GovCloud).
service: El servicio al que pertenece el recurso, como s3, ec2 o iam.
region: Región donde reside el recurso (puede estar vacío para recursos globales).
account-id: ID de la cuenta que posee el recurso.
resource: Identificador del recurso y su tipo.

Ejemplos:

arn:aws:iam::123456789012:user/mi-usuario

¿Qué pasa si eliminas y vuelves a crear un recurso con el mismo nombre?
El ARN se mantiene igual si recreas un usuario o recurso con el mismo nombre. Esto es útil para políticas preconfiguradas que apuntan a ese ARN. Sin embargo, no implica que el recurso sea el mismo; aquí entra el identificador AIDA.

Identificador AIDA

¿Qué es AIDA?
AIDA es el identificador único asignado a usuarios o roles en IAM. AWS lo utiliza internamente para rastrear acciones y permisos asociados a estas entidades.

"AWSAccessKeyId": "AIDAEXAMPLE123456"

Dato importante sobre AIDA y usuarios eliminados:
Si eliminas un usuario IAM y lo vuelves a crear con el mismo nombre, el ARN permanecerá igual porque se basa en el nombre. Sin embargo, el identificador AIDA será completamente nuevo, ya que este es único y no reutilizable.

Esto significa que cualquier referencia al AIDA anterior en auditorías o registros ya no será válida para el nuevo usuario.

Diferencias clave entre ARN y AIDA:
ARN

Identifica un recurso.
Es legible para humanos.
Se usa en políticas y configuraciones.
Se mantiene igual al recrear un recurso.

AIDA

1. Identifica un usuario o rol IAM.
2. No es fácilmente reconocible.
3. Se usa para auditorías e informes internos.
4. Cambia si el recurso es eliminado y recreado.

Mejores Prácticas para Usar ARN y AIDA

Usa ARNs en políticas con precisión: Limita accesos a recursos específicos para mejorar la seguridad.
Monitorea los registros de CloudTrail: Rastrea acciones utilizando AIDA para identificar usuarios específicos.
Ten cuidado al eliminar usuarios IAM: Si necesitas conservar referencias en auditorías, guarda el historial asociado al AIDA antes de eliminar.

Espero te sirva este post dejame tus comentarios si deseas agregar algo.

Fuente:https://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids

Exportar u Obtener Hallazgos en AWS Inspector

Willie Reyes — Fri, 01 Nov 2024 04:04:54 +0000

AWS Inspector permite analizar y escanear recursos en AWS para identificar vulnerabilidades y configuraciones inseguras. Para hacer un análisis más detallado o respaldar los hallazgos, es útil exportarlos directamente a un bucket en S3. Aquí te explico cómo hacerlo en pocos pasos.

Validar los permisos de tu usuario

Deberias contar con permisos para poder realizar esta configuracion, en aws los permisos son asignados por acciones y para este fin necesitas estos dos permisos

inspector2:ListFindings
inspector2:CreateFindingsReport

Para poder exportar tal como se visualiza en la imagen se requiere tambien el uso de una llave KMS (Key Management Service) y las acciones o permisos son los siguientes

kms:GetKeyPolicy
kms:PutKeyPolicy
kms:DescribeKey
kms:ListAliases

Finalmente para el bucket s3 requieres de estos permisos

s3:CreateBucket
s3:DeleteObject
s3:PutBucketAcl
s3:PutBucketPolicy
s3:PutBucketPublicAccessBlock
s3:PutObject
s3:PutObjectAcl

Configurar el Bucket S3

Crear el bucket s3 donde se va a almacenar el reporte de hallazgos, asegúrate de que el bucket S3 de destino esté configurado correctamente.

Permisos: Verifica que el bucket tenga permisos adecuados para que AWS Inspector pueda escribir en él. Puedes otorgar permisos específicos mediante la politica detallada mas adelante, en donde debes reemplazar los valores de cuenta asi como el nombre del bucket s3 creado.

Inicie sesión con sus credenciales y, a continuación, abra la consola de Amazon S3 en https://console.aws.amazon.com/s3.
En el panel de navegación, seleccione Buckets.
Seleccione el bucket de S3 en el que desea almacenar el informe de hallazgos.
Seleccione la pestaña Permisos.
En la sección Política de bucket, seleccione Editar y agregar la siguiente politica
Guardar los cambios.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "allow-inspector",
            "Effect": "Allow",
            "Principal": {
                "Service": "inspector2.amazonaws.com"
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:AbortMultipartUpload"
            ],
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:inspector2:Region:111122223333:report/*"
                }
            }
        }
    ]
}

Creacion de KMS para asociar a la exportacion de hallazgos

Inicie sesión con sus credenciales y, a continuación, abra la consola de Amazon S3 en https://console.aws.amazon.com/s3.
En el panel de navegación, seleccione KMS

Ubicarse en customer managed Keys e dar click en create key

Seguir de la siguiente manera

Escoger el usuario administrador de la llave y de uso para las dos opciones siguientes
Revisar que cuente con la siguiente configuracion y crear la llave.

Posterior a esto editar la politica de la kms y agregar la sigueinte politica que va a permitir el acceso a inspector de igual manera reemplazar los valores.

{
    "Sid": "Allow Amazon Inspector to use the key",
    "Effect": "Allow",
    "Principal": {
        "Service": "inspector2.amazonaws.com"
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:SourceAccount": "111122223333"
        },
        "ArnLike": {
            "aws:SourceArn": "arn:aws:inspector2:Region:111122223333:report/*"
        }
    }
}

Finalmente regresar a la opcion de inspector y escoger si deseas un reporte completo o solamente las vulnerabilidades activas

Asi tambien si deseas el archivo en formato json o csv.

En la opcion de bucket s3 y kms escogemos los recursos previamente creados y selecccionamos export,

esperamos unos minutos dependiendo tambien de la cantidad de recursos que tengas, recordemos que inspector revisa vulnerabilidades en los siguientes recursos

Imagenes de contenedores
Instancias Ec2
Funciones Lambda

espero te sirva este tutorial para tus procesos de seguridad.

Fuente
https://docs.aws.amazon.com/inspector/latest/user/findings-managing-exporting-reports.html

Politica para forzar la configuracion de Multifactor de autenticación en usuarios IAM de AWS.

Willie Reyes — Sat, 03 Aug 2024 17:17:28 +0000

La autenticación multifactor (MFA) es una capa adicional de seguridad para tus cuentas de AWS. Implementar MFA ayuda a proteger tus recursos al requerir no solo una contraseña, sino también un segundo factor de autenticación, como un código de una aplicación de autenticación. En este post, mostraremos cómo forzar el uso de MFA en los usuarios de IAM de AWS mediante una política de IAM asi garantizar que todos los usuarios activen esta funcionalidad.

Esta politica funciona independientemente de los permisos que tengan los usuarios, por ejemplo si un usuario solamente tiene un permiso de lectura en EC2 podra ingresar a IAM e ir a la opcion de "Añadir Multifactor de autenticación"

Requisitos:
Para los usuarios el unico requisito es contar con una aplicacion de Multifactor sea virtual o fisica.

Lo primero que realizaremos es crear la politica, para esta accion si se necesita que un usuario con permisos de administrador o permisos especificos en IAM para crear politicas.

A continuacion los pasos:

Ingresamos a la consola de aws

Ingresamos a IAM Identity and Access Management

Ingresamos a policies y damos click en Create Policy

El codigo de la politica es el siguiente

{
    "Statement": [
        {
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:GetAccountSummary",
                "iam:ListVirtualMFADevices"
            ],
            "Effect": "Allow",
            "Resource": "*",
            "Sid": "AllowViewAccountInfo"
        },
        {
            "Action": [
                "iam:ChangePassword",
                "iam:GetUser"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Sid": "AllowManageOwnPasswords"
        },
        {
            "Action": [
                "iam:CreateAccessKey",
                "iam:DeleteAccessKey",
                "iam:ListAccessKeys",
                "iam:UpdateAccessKey"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Sid": "AllowManageOwnAccessKeys"
        },
        {
            "Action": [
                "iam:DeleteSigningCertificate",
                "iam:ListSigningCertificates",
                "iam:UpdateSigningCertificate",
                "iam:UploadSigningCertificate"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Sid": "AllowManageOwnSigningCertificates"
        },
        {
            "Action": [
                "iam:DeleteSSHPublicKey",
                "iam:GetSSHPublicKey",
                "iam:ListSSHPublicKeys",
                "iam:UpdateSSHPublicKey",
                "iam:UploadSSHPublicKey"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Sid": "AllowManageOwnSSHPublicKeys"
        },
        {
            "Action": [
                "iam:CreateServiceSpecificCredential",
                "iam:DeleteServiceSpecificCredential",
                "iam:ListServiceSpecificCredentials",
                "iam:ResetServiceSpecificCredential",
                "iam:UpdateServiceSpecificCredential"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Sid": "AllowManageOwnGitCredentials"
        },
        {
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:iam::*:mfa/*",
            "Sid": "AllowManageOwnVirtualMFADevice"
        },
        {
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Sid": "AllowManageOwnUserMFA"
        },
        {
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            },
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice",
                "sts:GetSessionToken",
                "iam:ChangePassword",
                "iam:GetUser"
            ],
            "Resource": "*",
            "Sid": "DenyAllExceptListedIfNoMFA"
        }
    ],
    "Version": "2012-10-17"
}

Escogemos la opcion JSON y copiamos el codigo de la politica y damos click en Next.

Añadimos un nombre y una descripcion

Y damos click en Create Policy

Basicamente lo que hace esta politica es

Permite ver información general de la cuenta:

Ver la política de contraseñas de la cuenta
Ver el resumen de la cuenta
Listar dispositivos MFA virtuales

Permite a los usuarios gestionar sus propias credenciales:

Cambiar su propia contraseña
Gestionar sus propias claves de acceso (crear, eliminar, listar, actualizar)
Gestionar sus propios certificados de firma
Gestionar sus propias claves públicas SSH
Gestionar sus propias credenciales específicas de servicio (como para Git)

Permite a los usuarios gestionar sus propios dispositivos MFA:

Crear y eliminar dispositivos MFA virtuales
Activar, desactivar, listar y resincronizar dispositivos MFA

Implementa una política de seguridad estricta:

Deniega todas las acciones excepto las específicamente listadas si el MFA no está presente
Las únicas acciones permitidas sin MFA son las relacionadas con la configuración del MFA y el cambio de contraseña

Posterior lo que realizamos es la creación de un grupo y añadimos esta politica al grupo

Para esto ingresamos a IAM y escogemos la opcion de "user groups" y damos click en Create Group

Asignamos un nombre al grupo asi tambien como los usuarios a los que queremos aplicar esta politica.

asi tambien añadimos la politica a este grupo

Ahora podemos validar esta funcionalidad creando un usuario solo con acceso de lectura a Ec2

Para esto ingresamos a usuarios "create user"

Añadimos dos grupos al usuario uno en donde tiene el permiso de Ec2 y otro donde esta la politica que forza el uso de MFA

Para utilizar este acceso es preferible utilizar una ventana de incognito de tu navegador de preferencia

Ingreamos las credenciales y cambiamos la clave

Debido a que no tenemos permisos hasta activar el MFA se nos presenta toda la consola con error

El siguiente error explitico nos muestra en todos los recursos

You are not authorized to perform this operation. User: arn:aws:iam::XXXXXXX:user/pruebamfa is not authorized to perform: ec2:DescribeInstances with an explicit deny in an identity-based policy

Luego ingresamos a IAM y damos click en la opcion "Agregar MFA"

Realizamos la configuracion de mfa

Cerramos sesion y volvemos a ingresar y podemos ver las instancias en la cuenta de aws

De esta manera podemos garantizar que los usuarios activen el MFA y esta politica aplica tanto en el acceso de consola o via AWS CLI, en una proxima entrega veremos como usar el MFA usando AWS CLI.

Fortalece la Seguridad de tu AWS: Implementación de MFA para Usuarios IAM

Willie Reyes — Sat, 03 Aug 2024 16:16:15 +0000

La seguridad en la nube es primordial, y la autenticación multifactor (MFA) es una herramienta esencial para proteger tus recursos en AWS. Veamos por qué es importante y cómo implementarla.

¿Por qué es importante el MFA?

Añade una capa adicional de seguridad más allá de la contraseña.
Protege contra el acceso no autorizado, incluso si las credenciales se ven comprometidas.
Cumple con las mejores prácticas de seguridad y regulaciones.

Si cuentas con permisos correctos para poder visualizar recursos en IAM puedes seguir estos pasos para efectuar la habilitación, asi tambien necesitaras un aplicacion de multifactor entre las cuales tenemos:

Google Autheticator
Microsoft Authenticator
Authy

A continuacion los pasos para habilitar MFA en usuarios IAM:

Inicia sesión en la consola de AWS como administrador.

Ve a IAM en el panel de navegación.

Selecciona "Users" y elige el usuario para el que deseas habilitar MFA.
En la pestaña "Security credentials", haz clic en "Assign MFA device".
Sigue el asistente para configurar el dispositivo MFA (virtual, hardware o SMS).

Verifica la configuración ingresando dos códigos MFA consecutivos, finalmente se visualiza la configuración realizada.

En un proximo post explicare como poder aplicar una politica para que todos los usuarios de manera obligatoria configuren el MFA.

AWS Security Hub

Willie Reyes — Sat, 06 Jul 2024 16:29:16 +0000

Hace unas semanas tuve la oportunidad de compartir en el canal de youtube de AWS Women Colombia una charla acerca del servicio de seguridad en AWS llamado "Security Hub" este servicio nos ayuda para temas de postura de seguridad y cumplimiento de los recursos dentro de la infraestructura de AWS.

A traves de este portal compartire informacion acerca de los diferentes servicios de seguridad que existen dentro de Amazon Web Services.

Introduccion

Security hub proporciona una vista integral del estado de seguridad en tu entorno de AWS.
Agrega, organiza y prioriza hallazgos de multiples servicios de seguridad dentro de AWS.

Security Hub recopila datos de seguridad de todas las Cuentas de AWS, los Servicios de AWS y los productos compatibles de terceros y lo ayuda a analizar sus tendencias de seguridad y a identificar los problemas de seguridad de mayor prioridad

Beneficios de Security Hub

Monitorizacion constante
Cumplimiento Normativo
Respuestas automatizadas
Reduccion de riesgos.

https://aws.amazon.com/es/security-hub/?nc=sn&loc=1

Estandares de Seguridad

Security Hub admite varios estándares de seguridad. Cada estándar incluye varios controles de seguridad, cada uno de los cuales representa una práctica de seguridad recomendada. Security Hub ejecuta comprobaciones de los controles de seguridad y genera resultados de control para ayudarle a evaluar su cumplimiento de las mejores prácticas de seguridad.

Estadares dentro de AWS Security Hub

Practicas recomendadas de seguridad v1.0.0
Este estandar es creado por AWS, es un conjunto de comprobaciones de
seguridad automatizadas que detectan cuando las cuentas y los
recursos implementados de AWS.
Indicadores de referencia v1.2.0 - v1.4.0 - v3.0.0 CIS
El Center for Internet Security (CIS) conjunto de guías de
configuración de seguridad y mejores prácticas desarrolladas por el
Center for Internet Security (CIS). Estas guías están diseñadas para
ayudar a organizaciones a asegurar sus sistemas de información y
protegerse contra ciberataques.
Publicacion especial de Nist 800-53
El Este marco de cumplimiento lo ayuda a proteger la disponibilidad,
confidencialidad e integridad de sus sistemas de información y
recursos críticos.
PCI DSS v3.2.1
El principal objetivo del PCI DSS es proteger la información
sensible de las tarjetas de pago contra el fraude y el robo mediante
la implementación de controles de seguridad robustos

Pasos para habilitar el servicio de Security Hub

Se debe habilitar AWS Config para que puede obtener Security Hub ingesta de informacion de AWS Config que revisara el cumplimiento de todos los recursos dentro de AWS.

Para habilitar AWS Config puedes hacer la configuracion de un solo click o desplegar usando IAC (Infraestructure as Code) con el servicio de AWS Cloud Formation.

Una vez habilitado AWS Config, podemos habilitar Security Hub con los estandares que se requieran segun el giro de negocio.

Finalmente luego de unas horas que comienze a trabajar el servicio de security hub podemos ver el porcentaje de cumplimiento en cada estandar asi como de cada uno de ellos.

Para efectuar las remediaciones ingresamos a cada hallazgo y podemos ver a detalle el control asi como los estandares asociados a estos controles con su respectivo numeral o identificador.

Asi tambien podemos deshabilitar controles de acuerdo a las siguientes motivos, para esto se deberia contar con el detalle del porque se deshabilita para en caso de alguna auditoria presentar este respaldo

Tambien se puede suprimir el control si de manera temporal no queremos que nos afecte el porcentaje o en caso que se este trabajando en la remediacion de dicho control

AWS Security Hub te ayudara a tener control acerca de problemas de configuraciones erroneas o de falta de seguridad en todos los recursos de AWS, te ayudara en casos de auditoria asi como el cumplimiento para certificaciones o de estandares de seguridad, este proceso es constante y deberas efectuar remediaciones en forme vaya creciendo tu infraestructura.

Comentame que te parecio o que agregarias a este post.

Cuentame que te parece o que podria añadir a este post.