Cómo sortear el "bug" de Amazon basado en las AMIs de RHEL 6.4.

Las AMIs de Amazon para RHEL 6.4, traen consigo un bug, dicho bug pertenece a la aplicación cloud-init y una mala configuración del rc.local.

El bug se basa en lo siguiente, al iniciar una ami, basada en una que has creado, esta no se inicia correctamente, por que se han añadido en el fichero sshd_config, 2 líneas de forma errónea, estas líneas son:

UseDNS no

PermitRootLogin without-password

Que debido al error, aparecen almacenadas de la siguiente forma:

UseDNS no

PermitRootLogin without-passwordUseDNS no

Esto provoca que la máquina no se levante correctamente. Si te pasa esto y necesitas acceder a esa máquina, la solución es que conectes el volumen de la máquina que falla, como secundario en otra máquina que si se inicie, una vez conectado el volumen, accedes a él desde la máquina y modifica el sshd_config para eliminar las líneas extrañas.

#vi /etc/ssh/sshd_config

Una vez modificado, vuelves a adjuntar el volumen a tu máquina y se debería conectar correctamente.

Para solucionarlo definitivamente, has de eliminar las siguientes líneas del fichero /etc/rc.local :

cat <> /etc/ssh/sshd_config
UseDNS no
PermitRootLogin without-password

Por supuesto, cuando modifiquéis las líneas del sshd_config, reiniciar el servicio de ssh.

Vamos ahora al segundo bug, levantas tu ami, que sabes que tiene un usuario creado, intentas acceder a ella y te dice que “acceso denegado”, lo intentas con los certificados de Amazon y te deja perfectamente.

Tu estás completamente seguro, que antes de crear la ami, podías acceder con un usuario que has creado, ¿por qué ahora no puedes acceder?

Fácil y sencillo, simplemente por que el “cloud-init” ha modificado por ti la variable “PasswordAuthentication” y le ha puesto un no.

La solución rápida, entrar con el certificado, cambiar la opción a yes y reiniciar el servicio ssh.

La solución definitiva, editar el fichero /etc/cloud/cloud.cfg

y cambiar la variable “ssh_pwauth:” a 1, ya que por defecto está a 0.

Y esto es lo que provoca, que cuando levantas una ami basada en RHEL 6.4 no puedas acceder a ella.

Espero que os sirva chicos!!

Problemas de bloqueo en Drupal con Load Balancer de Amazon

La versión 7 de Drupal, trae como característica el bloqueo de ataques de fuerza bruta, es decir, cuando una IP falla el login, Drupal mete la IP en la tabla ‘flood’ de MySQL; cuando se llega a X intentos, Drupal bloquea el acceso a dicha IP y no podrá volver a hacer login en X tiempo (todo esto es configurable en settings.php).

Dicha característica está muy bien cuando el frontal web está de cara al público y no se encuentra tras un Proxy o Balanceador, en este último caso, dicha “feature” se puede convertir en un infierno, ya que los intentos fallidos para Drupal, se muestran con la IP interna del Proxy o Balanceador y esto puede provocar, que si hay un bloqueo por intentos fallidos, absolutamente tooooodos los usuarios de Drupal, estén donde estén, sean bloqueados y no puedan hacer login en la aplicación.

La ñapa de esto, es hacer un ‘TRUNCATE’ de la tabla flood, al vaciarla, se volverá a acceder.

La solución a esto, es utilizar la variable X-FORWARDED-FOR para que Drupal vea exactamente la ip origen del cliente y bloquee correctamente las IPs (toda la info de esta variable se encuentra en el settings.php).

Ahora demos una vuelta de tuerca más, si la web está tras un Proxy o un Balanceador, tendremos todas sus IPs y será fácil de configurar, pero que pasa, si nuestro Drupal está en una instancia tras un Load Balancer de Amazon.

Pues que tenemos un problema.

Amazon es muy divertido y bonito para muchas cosas, pero como esas cosas son suyas, hay elementos a los que les cambia la IP como le apetece y cuando le apetece.

Por otro lado, todos podemos conocer la IP pública de un Balanceador de Amazon, sin embargo, no podemos saber realmente la IP interna de dicho Balanceador, eso si, nos aparecerá en todos los logs de acceso de las aplicaciones que tengamos y en la tabla ‘flood’ de Drupal, también. XD

Si echáis un vistazo a la configuración de X-FORWARDED-FOR en el settings.php, veréis que nos pide una IP fija, pero no la tenemos.

Gracias al IRC de #drupal-es y a NITEMAN en especial que me atendió y me dio muchísima información, pude sacar la solución.

Esta solución se basa en este link:

http://www.nonsie.com/blog/12/11/drupal_mollom_and_amazon_web_services_elastic_load_balancer

Y un poco modificado, hizo que las IPs de origen, fueran realmente las de los clientes, provocando así un bloqueo real de las IPs.

Mi configuración final en el settings.php de Drupal, ha sido la siguiente:

*/Hay que descomentar esta línea y marcarla como TRUE para que active este modo.

$conf['reverse_proxy'] = TRUE;

/**

* Specify every reverse proxy IP address in your environment.

* This setting is required if $conf['reverse_proxy'] is TRUE.

*/

#Se agregan estas líneas para que Drupal no bloquee todos los accesos, ya que solo verificaba la IP interna del balanceador

#Esta línea captura la IP interna del balanceador.

$conf['reverse_proxy_addresses'] = array_map('gethostbyname', array_map('gethostbyaddr', gethostbynamel($_SERVER['REMOTE_ADDR'])));

/**

* Set this value if your proxy server sends the client IP in a header

* other than X-Forwarded-For.

*/

#Esta línea, cambia la IP interna del balanceador por la IP origen del cliente.

$conf['reverse_proxy_header'] = 'HTTP_X_FORWARDED_FOR';

#Información adicional sobre las variables utilizadas:

#Tanto REMOTE_ADDR como HTTP_X_FORWARDED_FOR se ha sacado del acceso a Drupal, en la siguiente ruta

#Informes -> Informe de estado -> PHP ** clikar en "mas información"

#se abrirá el PHPINFO de Drupal y en Apache Environment, tendremos estas variables.

#REMOTE_ADDR tendrá que indicarnos la IP interna del Balanceador

#HTTP_X_FORWARDED_FOR tiene que darnos la IP origen del cliente.

Con estos cambios que hemos realizado, al hacer un login fallido, en la tabla ‘flood’ de Drupal, deberían aparecer las IP origen del cliente.

Espero que os sirva a esos que estáis empezando a implementar Drupal en Amazon con Balanceadores!!

Un saludo a todos.


ACTUALIZACIÓN: Es muy importante, que si utilizáis esto verifiquéis, que el acceso a esta web, solamente se puede hacer a través del balanceador. Si un usuario malintencionado averigua la IP real de la máquina y tiene acceso vía web, puede enviar cabeceras modificadas y hacer cositas con nuestra web.

Script para que otros puedan ver tus Snapshots.

Una de las cosas molonas que tiene Amazon, es que los snapshots que hagas, los puedes compartir, gráficamente haces click derecho sobre el snapshot -> Snapshots permissions  y añades el id de la cuenta de Amazon con la que quieres compartir este Snapshot.

Pero........

que pasa si tienes un script para que genere los snapshots automáticamente y quieres que se agreguen estos permisos automágicamente.....

Simplemente añadir estas líneas al script:

#Se agregan permisos de otro id de amazon a los 2 últimos snapshots creados.

SNAP_ID=`/opt/api-tools/bin/ec2-describe-snapshots | sort -k5 | (head -5 |tail -1) |awk '{printf $2}'`

/opt/api-tools/bin/ec2-modify-snapshot-attribute $SNAP_ID  -c --add id-cuenta-amazon

Lo que hace es, describir los snapshots que hay hechos, los ordena por fecha y coge el id del snapshot que se encuentra en la última línea, en mi caso suele haber 5 snapshots (head -5), en el caso de que tengáis mas o menos tendréis que modificar ese 5 por el número que os vaya mejor.

Ese id que ha cogido, lo mete en la variable SNAP_ID, que usamos en la siguiente línea, esto lo que hace es ejecutar el comando para agregar permisos, al id del snapshot correspondiente y da permisos al id de la cuenta de Amazon que queramos.

Si mejoro el script, automatizándolo mas todavía, lo actualizo.

Un saludo!!