AWS siempre está monitorizando cualquier uso no autorizado de sus/nuestros recursos. Si tienes docenas de servicios ejecutándose en AWS, en algún momento serás avisado de un incidente debido a varias razones como compartir accidentalmente una contraseña en Github, una mala configuración de un servidor que lo hace fácil de atacar, servicios con vulnerabilidades, DoS o DDoS, 0days, etc… Así que debes estar preparado para realizar un análisis forense y/o gestionar la respuesta ante incidentes de tu infraestructura en AWS.
Recuerda, encaso de incidente debes mantener la calma y procura seguir un procedimiento definido, no dejes este proceso en manos del azar porque probablemente tu o tu jefe este lo suficientemente nervioso como para no esperar ni pensar. Siempre es mucho mejor seguir una guía previamente testeada que tu intuición (que ya la usarás después).
ADVERTENCIA: si has llegado a este artículo de forma desesperada haciendo una búsqueda en Google, te recomiendo probar todos los comandos antes en un entorno controlado como tu laboratorio o sistemas de pruebas. Como decía, deberías tener una guia de respuesta a incidentes y proceso de análisis forense antes de que ocurra un incidente.
En este artículo quiero recomendar algunos pasos y trucos que nosotros hemos usado en algún momento. Doy por hecho que tienes el cliente de linea de comandos de AWS ya instalado, si no es así mira aquí: http://docs.aws.amazon.com/general/latest/gr/GetTheTools.html. Todos los comandos están basados en una posible instancia comprometida en EC2 (Linux), pero la mayoría de estos comandos “aws” se pueden usar también para servidores Windows aunque no lo he probado. Todas estas acciones también se pueden realizar mediante la AWS Cosole. Estos serían algunos de los pasos a tener en cuenta:
1) Desactiva o borra el Access Key. Si una AWS Access Key ha sido comprometida (AWS te lo hará saber en un correo electrónico u tu lo notarás pagando una gran factura) o te das cuenta que lo has publicado en Github:
aws iam list-access-keys
aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE \ --status Inactive --user-name Bob
aws iam delete-access-key --access-key AKIDPMS9RO4H3FEXAMPLE \ --user-name Bob
2) En caso de que la Key sea comprometida, comprueba si algún recurso ha sido creado usando esa Key, en todas las regiones. Es común ver que alguien ha usado tus claves para lanzar instancias EC2 en otras regiones de AWS así que comprueba todas buscando instancias que te parezcan sospechosas. Aquí un ejemplo para buscar instancias creadas en la región us-east-1 desde el 9 de Marzo de 2016:
aws ec2 describe-instances --region us-east-1 \
--query 'Reservations[].Instances[?LaunchTime>=`2016-03-9`][].{id: InstanceId, type: InstanceType, launched: LaunchTime}'
3) Contacta con el equipo de soporte de AWS y avísales del incidente, están siempre dispuestos a ayudar y en caso necesario escalarán al equipo de seguridad de AWS.
4) Aisla la instancia, en este caso cuando hablo de YOUR.IP.ADDRESS.HERE, puede ser la IP pública de tu oficina o un servidor intermedio donde saltar y hacer el análisis:
- Crea un security group para aislar la isntancia, ojo con la diferencia entre EC2-Classic y EC2-VPC, apunta el Group-ID
aws ec2 create-security-group --group-name isolation-sg \ --description "Security group to isolate EC2-Classic instances"
aws ec2 create-security-group --group-name isolation-sg \ --description "Security group to isolate a EC2-VPC instance" --vpc-id vpc-1a2b3c4d # where vpc-1a2b3c4d is the VPC ID that the instance is member of
- Configura una regla para permitir SSH solo desde tu IP pública, aunque primero debes saber tu IP pública:
dig +short myip.opendns.com @resolver1.opendns.com
aws ec2 authorize-security-group-ingress --group-name isolation-sg \ --protocol tcp --port 22 --cidr YOUR.IP.ADDRESS.HERE/32
aws ec2 authorize-security-group-ingress --group-id sg-BLOCK-ID \ --protocol tcp --port 22 --cidr YOUR.IP.ADDRESS.HERE/32 # note the difference between both commands in group-name \ and group-id, sg-BLOCK-ID is the ID of your isolation-sg
- Los EC2-Classic Security Groups no soportan reglas de trafico saliente (solo entrante). Sin embargo, para EC2-VPC Security Groups, reglas de trafico saliente se puede configurar con estos comandos:
aws ec2 revoke-security-group-egress --group-id sg-BLOCK-ID \ --protocol '-1' --port all --cidr '0.0.0.0/0’ # removed rule that allows all outbound traffic
aws ec2 authorize-security-group-egress --group-id sg-BLOCK-ID \ --protocol 'tcp' --port 80 --cidr '0.0.0.0/0’ # place a port or IP if you want to enable some other outbound \ traffic otherwise do not execute this command.
- Aplica ese Security Group a la instancia comprometida:
aws ec2 modify-instance-attribute --instance-id i-INSTANCE-ID \ --groups sg-BLOCK-ID # where sg-BLOCK-ID is the ID of your isolation-sg
- En caso de que quieras aislar también la cuenta IAM porque sospechas que las credenciales han podido ser robadas, aplica una política de NO-IAM, en lugar de editar políticas existentes simplemente plica esa política que bloquea todos los accesos (ver slide 23 y 30 aquí http://www.slideshare.net/AmazonWebServices/sec404-incident-response-in-the-cloud-aws-reinvent-2014)
aws iam put-user-policy --user-name MyUser --policy-name MyPowerUserRole \ --policy-document file://C:\Temp\MyPolicyFile.json
5) Etiqueta la instancia para marcarla como “en investigación”:
aws ec2 create-tags –-resources i-INSTANCE-ID \ –tags "Key=Environment, Value=Quarantine:REFERENCE-ID"
6) Guarda los metadatatos de la instancia:
- Más información sobre la instancia comprometida:
aws ec2 describe-instances --instance-ids i-INSTANCE-ID > forensic-metadata.log
or
aws ec2 describe-instances --filters "Name=ip-address,Values=xx.xx.xx.xx"
- La salida de consola, puede ser útil dependiendo del tipo de ataque o compromiso aunque recuerda que deberías tener un sistema de logs centralizado:
aws ec2 get-console-output --instance-id i-INSTANCE-ID
7) Crea un Snapshot del volumen o volúmenes de la instancia comprometida para el análisis forense:
aws ec2 create-snapshot –-volume-id vol-xxxx –-description "IR-ResponderName- Date-REFERENCE-ID"
- Ese snapshot no se modificará o montará, sino que trabajaremos con un volumen.
8) Ahora podemos seguir dos caminos, Parar la instancia:
aws ec2 stop-instances --instance-ids i-INSTANCE-ID
- o Dejarla ejecutándose, si podemos, en cuyo caso deberíamos aislarla también desde dentro (iptables) y hacer un volcado de la memoria RAM usando LiME.
9) Crea un Volume desde el snapshot:
- Piensa que región vas a usar, y otras opciones como –region us-east-1 –availability-zone us-east-1a –volume-type y personaliza los comandos siguientes:
aws ec2 create-volume --snapshot-id snap-abcd1234
- Toma nota del volumen:
aws ec2 describe-volumes
10) Monta ese volumen en tu distribución favorita de análisis forense y comienza la investigación.
Iré añadiendo más información en futuros artículos, por ahora esto es una introducción adecuada.
Si quieres aprender mucho más sobre este tema, voy a dar un curso online sobre Análisis forense en AWS, GCE y Azure en español con Securizame, más info aquí.
Algunas referencias que he usado:
https://securosis.com/blog/my-500-cloud-security-screwup
https://securosis.com/blog/cloud-forensics-101
http://sysforensics.org/2014/10/forensics-in-the-amazon-cloud-ec2/
