jueves, 26 de abril de 2012

Nuevos vectores de ataque en HTML5

Con la llegada de HTML5 y sus  componentes, nuevas superficies de ataque a aplicaciones web se hacen posibles. Entre las funcionalidades mas destacables que incorpora HTML5 encontramos:

  • Soporte a través de plugins para otras tecnologías como Slirverlight y Flash
  • Nuevos TAGs html para multimedia, forumularios, iframes...
  • Funciones de red  a nivel de capa de trasporte ( websockets
  • XMLHttpRequest (XHR) Level 2, con  nuevas funciones como: peticiones entre dominios (cross-domain access), eventos de progreso y manejo de flujos de bytes (streams)
  • DOM -Level 3 
  • Soporte WebSQL que porporciona acceso a bases de datos a través del navegador
  • Sandboxing y aislamiento de i-frames via compartimentos lógicos dentro del navegador
  • Almacenamiento/Acceso a datos   a través de los objetos localstorage / sessionstorage 
  • Funcionalidades drag & drop 
La potencia de estas funcionalidades abre nuevas vias a vectores de ataque tradicionales y posibilita otras nuevas:

  • Ataques de Cross site a través de controles de XHR
  • Inyecciones DOM y ejecución de scripts
  • Inyecciones vía WebSQL
  • Inyección a través de los nuevos TAGs de HTML5
  • Manipulación de datos almacenados localmente y es sitios externos
  • Explotación DOM3 para ataques de hijacking 
  • Cross Site Request Forgery (CSFR) via XHR
  • Clickjacking via eventos DOM
  • Utilización malintencionada de redes sociales y widgets
Segmentos lógicos en un navegador HMTL5 y superficies de ataque posibles
En definitiva, algo muy a tener en cuenta por profesionales del desarrollo de aplicaciones web y especialistas en seguridad IT

domingo, 15 de abril de 2012

Certificacion eCCPT review


Bueno, mucho tiempo sin escribir algo por aquí. Suena a escusa , lo sé, pero la realidad es que el tiempo del que dispongo es cada vez mas escaso una vez cumplidas mis obligaciones laborales. Hoy me notificaron que habia superado la prueba para conseguir la certificación como "professional pentester" que emite la compañia eLearnSecurity. Esto me ha animado a contar brevemente algo sobre esta certificación online. eLearnSecurity es una empresa de seguridad IT enfocada a la formación en el campo de la seguridad de aplicaciones y comunicaciones. Dispone de varias modalidades según la experiencia del candidato. Una inicial para gente nueva en estas lides y que denominan Student-Course  que establecerá las bases para poder abordar con garantías (aunque no es necesario estrictamente) el curso eCPPT Silver , el cual  da acceso a  la certificación  eLearnSecurity Certified Professional Penetration Tester  o eCPPT.
Esta es la certificación que acabo de recibir. Sobre el curso, debo comentar que es 100% práctico y enfocado a saber reconocer y enfrentarse a las principales amenazas de seguridad de aplicaciones y de las comunicaciones. Con el curso se da acceso a una plataforma online que incluye multitud de presentaciones dinámicas  en flash donde se recorren  y se explican los diversos ataques y amenazas a los que se puede ver expuesta una aplicación o una red.

 Los temas se dividen en tres grandes grupos: Seguridad de Sistemas, Seguridad de Red y Seguridad de Aplicaciones Web.
En  Seguridad de sistemas se habla de criptografía, buffer overflows, malware y se dan indicaciones prácticas  de como escribir shellcodes y lograr explotarlas en aplicaciones vulnerables.

Un capitulo del grupo seguridad de Sistemas

 En la parte de Seguridad Web se explican los principales vectores de ataque y  vulnerabilidades de aplicaciones web (sql inyection, XSS, hijacking, File inclusion, etc). Además será la parte de más peso en la certificación puesto que el laboratorio que adjuntan (una maquina virtual con una aplicacion web vulnerable) se usará para hacer una auditoria y del informe resultante se compondrá un reporte a enviar a eLearnSecurity y sobre el que se evaluará si es merecedor de obtener la certificación.
 Finalmente, un tercer grupo de seguridad de red nos instruirá en el manejo de concepto de escaneos, ataques Man in the Middle, enumeración de recursos, sniffing de red, explotación de accesos y elevación de privilegios, etc ,etc.

Modulo5 del grupo de Seguridad de Red
 Durante todo el contenido del curso se indican y se instruye en el manejo de las herramientas más apropiadas para lograr el cometido buscado: burp proxy, nmap, nessus, sqlmap,  desensambladores como Immnity debbuger, metasploit etc,etc. Además se incluyen ficheros para practicar lo aprendido.

En general me ha parecido un curso muy bueno, y lo más importante muy,muy práctico con un enfoque real  y a la vez, divertido. Además, el examen te hace ponerte en un caso "real" como profesional en test de intrusion y auditoría, puesto que  se  debe estudiar el objetivo entregado en el laboratorio (una aplicación web vulnerable) y generar un informe acorde a las metodologías  de  reporting en seguridad IT como OSSTM , siguiendo guías de clasificación  de vulnerabilidades como OWASP  o CWE . El manejo de la información y como hacer el reporte también es explicado. En definitiva, recomendable, mas aún ahora que en su versión 2, incluye la posibilidad de acceder a una plataforma compuesta por múltiples sistemas en una red virtual que conforma un laboratorio perfecto donde realizar un test de intrusión muy cercano a lo que sería un test real.

martes, 13 de diciembre de 2011

NTFS y Alternate Data Streams. El peligro está oculto

El sistema de ficheros NTFS tiene un peculiaridad bastante llamativa derivada de proporcionar compatibilidad con HFS (Hierarchical File System) de Macintosh. En HFS la información de un fichero se almacena en bifurcaciones (forks) de datos y de recursos. Los forks de datos mantienen la información del contenido propiamente dicho mientras que los forks de recursos indican metadatos como por ejemplo tipo de fichero

 Esta propiedad provoca que un mismo recurso tenga varios identificadores y puede sacarse provecho para ocultar ficheros en NTFS. EL formato es conocido como Alternate Data Stream ADS.

 Mejor, veamoslo con un ejemplo.

La sintaxis de un ADS es sencilla. Para crear un ADS asociado con un fichero, basta con añadir el carácter dos puntos ":" al nombre del fichero, por ejemplo:
Creamos un fichero de texto:

C:\Users\Usuario\ADS>echo "Fichero de texto" > file.txt
C:\Users\Usuario\ADS>dir

 El volumen de la unidad C no tiene etiqueta.

13/12/2011 11:00 <DIR> .
13/12/2011 11:00 <DIR> ..
13/12/2011 11:00 21 file.txt

 1 archivos 21 bytes
 2 dirs 367.935.696.896 bytes libres
 

C:\Users\Usuario\ADS>type file.txt

"Fichero de texto"


Ahora utilizando la sintaxis apropiada creamos un fichero ADS:

C:\Users\Usuario\ADS>echo "Texto oculto" > file.txt:hidden


Comprobamos como, aparentemente nada ha cambiado:

C:\Users\Usuario\ADS>dir

  El volumen de la unidad C no tiene etiqueta.
 Directorio de C:\Users\Usuario\ADS

13/12/2011 11:00 <DIR> .
13/12/2011 11:00 <DIR> ..

13/12/2011 11:01 21 file.txt

 1 archivos 21 bytes
 2 dirs 367.935.696.896 bytes libres

C:\Users\Usuario\ADS>type file.txt
"Fichero de texto"


El fichero no existe con estructura como tal ....

C:\Users\Usuario\ADS>type file.txt:hidden

El nombre de archivo, el nombre de directorio o la sintaxis de la etiqueta del volumen no son correctos.

... pero podemos extraer el stream por ejemplo, haciendo uso de la redirección hacia el comando more:

C:\Users\Usuario\ADS> more < file.txt:hidden
"Texto oculto"



Como vemos, hemos podido "asociar" un stream a un fichero de modo que aparentemente sólo sea visible el fichero "file.txt" pero asociado a él existe el stream oculto "file.txt:hidden" con su propio contenido. Obsérvese que el tamaño del fichero no cambia ya que realmente sigue siendo el mismo. De hecho son independientes, es sólo una forma de demostrar que añadiendo los dos puntos ":" asociamos el data stream al mismo y será  invisible en un listado usual. Esta propiedad de los sistemas de ficheros NTFS contituye en cierto modo un  riesgo de seguridad  al permitir ocultar al usuario contenidos, permitiéndose incluso insertar de forma silenciosa archivos ejecutables.

Afinando un poco,  podemos listar y encontrar ADS usando la opción /R del comando DIR en windows:

C:\Users\Usuario\ADS> help DIR
Muestra la lista de subdirectorios y archivos de un directorio.

DIR [unidad:][ruta][archivo] [/A[[:]atributos]] [/B] [/C] [/D] [/L] [/N]

  [/O[:]orden]] [/P] [/Q] [/R] [/S] [/T[[:]fecha]] [/W] [/X] [/4]

...

..
  /R          Muestra las secuencias alternativas de datos del archivo.

..


De este modo, entonces:

C:\Users\Usuario\ADS>dir /R

El volumen de la unidad C no tiene etiqueta.
Directorio de C:\Users\Usuario\ADS

13/12/2011 11:00 <DIR> .
13/12/2011 11:00 <DIR> ..

13/12/2011 11:01             21 file.txt
13/12/2011 11:01           6.002 file.txt:hidden:$DATA






Existen varias herramientas para buscar y detectar cómodamente ficheros ADS. Por ejemplo Nirsoft, proporciona el programa AlternateDatastreamView que nos permite de forma muy sencilla escanear el disco en busca de este tipo de archivos:






Mas info:




lunes, 5 de diciembre de 2011

X Forwarding y túneles ssh


Puff, ya hacía tiempo que no posteaba. Mucho lío , poco tiempo , muchas cosas... o una combinación de todas.
Bueno pues voy a hablar del forwarding de X en sesiones ssh, cosa que más de una vez me ha "salvado la vida".

Tunelizando conexiones a servidor X


Cuando necesitemos acceso a otra máquina y hacer uso de herramientas gráficas, pero sólo podemos acceder vía ssh, podemos usar un túnel ssh y a través de la conexión  hacer  forwarding, de modo que las aplicaciones ejecutadas en la máquina remota tengan acceso al servidor X local.

El mecanismo es el siguiente:

Para establecer la sesión ssh con túnel para las x, ejecutaremos

ssh -X <host_remoto>  (*)
login: userx
Password:
Have a lot of fun...
/usr/bin/xauth:  creating new authority file /home/userx/.Xauthority
userx@server>$

(*) Si no inidcamos la opción -X, debemos tener habilitado el forwading  del servidor local de X (ForwardX11 yes) en el fichero de configuración del cliente ssh (/etc/ssh/ssh_config)

Con esto, el  cliente ssh local genera una cookie de autenticación y la envía al servidor ssh remoto que añadirá al fichero $HOME/.Xauthority de la máquina remota en la conexión.

El servidor remoto, abre el socket TCP 6010 en modo escucha. Además, inserta en el entorno del usuario que se logea la variable de entorno DISPLAY=localhost:10.0. En el caso de que el socket estuviese ya ocupado, asignará el siguiente (TCP 6011) y la correspondiente variable de entorno DISPLAY=11.0 y así sucesivamente.

Observemos la siguiente salida de netstat que nos muestra el estado de los sockets LISTEN en la máquina remota:

Sockets Listen en la máquina remota




Conexiones establecidas
Tenemos que:

Se crea una conexión ssh entre la máquina local 10.70.4.11 y la remota 10.70.4.4.  En la máquina remota se lanza una aplicacion gráfica (iceweasel). Esta  leerá la cookie del fichero $HOME/.Xauthority e iniciará una conexión TCP al socket local que corresponda, en este caso el 6010. El cliente recibirá la cookie y comprueba que, efectivamente, es la que él generó inicialmente. A continuación establece una conexión con el servidor X local. A partir de este momento el túnel está establecido.

En este ejemplo la sesión que abrió el socket 6010 y se  ejecutó iceweasel:

userx@server>$ pstree 15094
sshd----bash----iceweasel-----22*[{iceweasel}]

Conexión al servidor X. Tipos

La conexión de una aplicación al servidor X puede realizarse por varios métodos. En GNU/Linux los métodos son socket local (socket Unix)  y TCP. Es la aplicación cliente la que escoje el protocolo y la localización del servidor con la variable DISPLAY o bien con la opción --display.
En el caso de usar socket unix local , la variable DISPLAY será un signo de dos puntos seguido del número de display, generalmente 0 (aunque puede ser distinto si se ejecutan varios servidores de X). Opcionalmente puede añadirse un punto y número de pantalla (también suele ser cero salvo que el servidor X controle varias pantalllas) .Entonces DISPLAY tomará generalmente el valor :0 (o :0.0). El socket local se creará en /tmp/.X11-unix/Xn siendo n el número de display:

linux:/etc/ssh # ls -l /tmp/.X11-unix/
total 0
srwxrwxrwx 1 root root 0 Dec  5 10:53 X0

Cuando la conexión es por socket TCP, DISPLAY será el hostname o IP del servidor X seguido de dos puntos y el número de display. Al igual que antes puede añadirse punto y el numero de pantalla. Por ejemplo en una conexión local pero por TCP el valor será DISPLAY=localhost:0. El puerto TCP mas usado es el 6000 mas el número de display.
Téngase en cuenta que las comunicaciones con el servidor X no están cifradas por lo que si se usa TCP las comunicaciones pueden monitorizadas. Es por ello que GNU/Linux no permite la conexión al servidor X por TCP. Esto puede comprobarse observando el parámetro -nolisten tcp en el proceso X:

linux:/etc/ssh # ps -ef | grep X

root      4177  4163  0 10:53 tty7     00:00:07 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-APoml7/database -nolisten tcp vt7 

Nota: En el ejemplo, la conexión de la aplicación cliente (en la máquina remota) se conecta al servidor X a través de un túnel ssh, con lo cual realmente el puerto TCP 6010 (6000 + 10 display) remoto está redirigido al túnel ssh y  la conexión al servidor X local a través de él

sábado, 22 de octubre de 2011

Demo de Japitracing

Hola a todos. Mucho tiempo sin escribir nada, pero estas últimas semanas dispongo de poco tiempo. He sacado un ratito para colgar el enlace del video-demostración sobre el proyecto de Fin de Máster que realicé en la Universidad Europea de Madrid junto a mis compañeros Jon, Pedro e Isa (gracias Isa por currarte el video)
video
Espero os guste: Demostración de trazabilidad IP por envenamiento de la caché del navegador vía google-analitics.
También en vimeo: Japi Demo

martes, 20 de septiembre de 2011

Caché poisoning e inyección de javascript. Huella digital, Geolocalización y seguimiento a través de Google Analytics

El pasado 14 de Septiembre se presentaron en la Universidad Europea de Madrid los ultimos proyectos de Fin de Máster de Seguridad de la Información y las Telecomunicaciones.  En concreto yo, con mis compañeros presentamos el proyecto Japitracing sobre Geolocalización IP usando cache poisoning con inyección de javascript a través del servicio Google Analytics..
Portada de la memoria Fin de Master



Logo de la aplicación



En dicho proyecto se ha implementado la idea de hacer un envenamiento de la caché de los navegadores aprovechando la confianza que ofrece un servicio como Google Analytics. Este servicio se basa un un código javascript ( ga.js ) que es descargado desde la páginas que hacen uso de analytics y cuya función es recopilar información  variada del navegador y de aspectos de la navegación dentro de  la página para generar estadísticas que se envían al propietario de la  misma. Este script, es un objeto cacheable con una vida media de una o dos horas hasta que el navegador solicita actualización. Además está ampliamente extendido por internet, de modo que,  casi con total seguridad en una sesión de navegación normal se  visita una página que lo contiene. Esta situación se ha aprovechado para conseguir obtener información sobre una persona y su localización después de haber modificado el  script original ga.js de Gooogle Analytics y , tras una intervención en la comunicación, lograr inyectar en la caché del navegador de la "victima". La manipulación del ga.js ha sido de forma que al descargarse, se cachée con un tiempo largo de expiración para lograr  hacerlo "persistente" y que no sea de nuevo sustituido por el original una vez se deje de intervenir la comunicación (MiTM). El script modificado incluye un código que recogerá información sobre la IP ( y localización por tanto) , sobre el sistema operativo,  el navegador, sus plugins y su  historial. Una vez recopilada toda esa información será enviada, esquivado las restricciones de same origin policy  gracias a un  iFrame invisible que se crea en la carga de la página , a continuación, tras meter la información en un formulario se envía con POST hacia un servidor ajeno. Todo esto ocurre de forma transparente para el usuario cada vez que se visite una página con Analytics y el script ga.js (ya almacenado en caché) se invoque.

Una muestra de la información obtenida

En definitiva  un trabajo muy interesante, durante el cual hemos ido descubriendo las posibilidades que tiene javascript , la información del navegador ,su funcionamiento y caché para establecer un ataque que vulnere gravemente la privacidad del usuario. Todo ello incrementado aun más por las características particulares de las aplicaciones y configuraciones que cada usuario tiene y que conformarán lo que se da en llamar "huella digital". Para profundizar en este tema, las huellas digitales y la privacidad a la hora de navegar, que mejor que leer esta entrada en el blog de nuestro tutor en el proyecto.

Finalmente, agradecer públicamente el gran trabajo y la motivación de mis compañeros de máster asi como la ayuda de nuestros tutores en informática64, Pablo González y Chema Alonso.

jueves, 1 de septiembre de 2011

Cluster de alta disponibilidad + balanceo de carga


Hace un tiempo tuve que implementar un balanceo de carga con alta disponibilidad y me resultó una tarea interesante. Cuento un poco como lo hice.
Vamos a implementar un cluster de alta disponibilidad (ha) que mantenga un servicio de balanceo entre
dos servidores, en este caso y a modo de ejemplo dos servidores Web.
IP Virtual: 192.168.50.205
IP Nodo 1 ha: 192.168.50.215
IP Nodo 2 ha :192.168.50.225
IP servidor Web1: 192.168.50.211
IP servidor Web2: 192.168.50.221

Necesitaremos:

  • Alta disponibilidad : Heartbeat

Con este paquete se establece una comunicacion entre los miembros del cluster (nodos) y se
definen unos servicios que se quieran poner en alta disponibilidad. Uno de los nodos será el master y
será quien dé el servicio. Si se cae, el/los otros nodos tomarán el servicio hasta que se recupere.
Nosotros vamos a poner como servicio el ldirectord que es el que se encarga de balancear la carga
sobre los servidores Web.

  • Balanceo LVS: Ldirectord

Es el paquete que propiamente proporciona el balanceo de carga. Se configura definiendo una
IP Virtual que el servicio se encarga de mantener a la “escucha” y repartir las demandas sobre los
servidores reales (web).


  • IP_Forwarding:

Como el balanceador tiene que hacer forwarding de las peticiones sobre la IP virtual a las reales, es
requisito habilitar en el kernel esta característica:
# /etc/sysctl.conf
net.ipv4.ip_forward = 1

Instalación :

apt-get install heartbeat ldirectord (debian)
yum heartbeat ldirectord install (RedHat)

Configuración:

Ldirectord
Lo primero y como queremos que este servicio sea controlado por heartbeat y que sea éste quien lo
arranque, lo deshabilitamos del boot de la máquina:

update_rc.d ldirectord remove (debian)
chkconfig ldirectord off (RedHat)


Creamos el fichero de configuración : ldirectord.cf y lo ubicamos en /etc/ha.d/conf
En este caso va a tener la pinta:

(No entro a describir todos los parámetros puesto que es extensísmo, consultar man)


# vim /etc/ha.d/ldirectord.cf
checktimeout=10
checkinterval=2
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=yes
virtual=192.168.50.205:80
real=192.168.50.211:80 gate
real=192.168.50.221:80 gate
fallback=127.0.0.1:80 gate
#protocolo que se gestionará
service=http
#Scheduler es el algoritmo usado para hacer el reparto de carga rr=RoundRObin, lc= least
conections... etc (ver man ldirectrd)
scheduler=rr
protocol=tcp
#Checktype es la “prueba de vida” que hará el ldirectord para saber si el servidor real esta vivo, en
este caso negotiate que comprobará una respuesta (hay otros por ej connection..)
checktype=negotiate
#archivo que se solicitará en los servidores web para la prueba de vida, debe estar en DocumentRoot
request="test/ldirector.html"
#El archivo debe contener unicamente esta linea de texto para confirmar la validez del sitio
web
receive="Si, estoy vivo!"


Con esto el ldirectord creará una IP virtual 192.168.50.205:80 que repartirá a los servidores reales por
el método Direct Routing (gate). Existen 3 métodos: NAT ,Direct Routing e IP Tunneling.

  • NAT:

 Las peticiones entrantes llegan a la IP virtual y son reenviadas hacia los servidores reales
   cambiando la IP destino (NATeo). La respuesta de los servidores reales vuelve al balanceador
  quien de nuevo cambia la IP y reenviía al petcionario. Como todo el tráfico pasa por el
   balanceador suponde normalmente un cuello de botella para el cluster.

  •  IP Tunneling

   LVS manda las peticiones a los servidores reales a través de un tunel IP y los servidores
   responde directamente al peticionario a través de sus tablas de enrutamiento (necesitan pues de
   gateway).

  •   Direct routing

 Los paquetes del peticionario son enviados directamente a los servidores reales (forwarding).
Como el paquete IP no es modificado los servidores reales para aceptarlo necesitan una interfaz
virtual no-ARP ( para evitar conflictos de red al tener la misma IP que la virtual). La respuesta
se envía directamente al peticionario desde el servidor real.

Lo que hace Ldirectord:
Conecta cada 10 segundos (checkinterval) con cada servidor real y pide la prueba
192.168.50.205:80/test/ldirector.html (request/receive). Si no recibe la cadena que pusimos en ese
fichero (“Si, estoy vivo”) en un tiempo de 2 segundos (checktimeout), eliminara ese servidor del “pool”
de servidores disponilbles a los que mandar peticiones. Estará de nuevo disponible cuando el test sea
exitoso.
Copiamos este fichero de configuracion ldirectord.cf en /etc/ha.d/conf del resto de nodos
Una vez definido el servicio de balanceo, vamos a ponerlo en Alta Disponibilidad a través de
HeartBeat.

Hearbeat


Para establecer la comunicación entre los nodos hay que definir un método de autenticación que se
hace a través del ficherito /etc/ha.d/authkeys
#vim /etc/ha.d/authkeys
auth 1
1 md5 EstaEsmiClaveSecreta
Este fichero que contiene la clave de autenticacion y el método de encriptación (md5) lo protegemos
para que solo lo lea root:
#chmod 600 /etc/ha.d/authkeys


Otra cosa a tener en cuenta es que los nodos se “conozcan”, es decir editar /etc/hosts en ambos y poner
los nombres de los nodos del cluster. Poner el nombre que devuelva el comando : uname -n

# vi /etc/hosts
192.168.50.215 Nodo1 NODO1
192.168.50.225 Nodo2 NODO2


Definimos el cluster: /etc/ha.d/ha.cf (bastante simplificado)


#Fichero de log
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 30
initdead 120
# Tarjeta por la que se realizará el broadcast
bcast eth0
udpport 694
auto_failback on
#nombre de host (uname -n) de los equipos directores
node Nodo01
node Nodo02
Copiamos este fichero en /etc/ha.d/ del resto de nodos.
Nota: La definicion del cluster se puede simplificar bastante con la herramienta gráfica hb_gui
Por último ya solo queda definir los servicios en alta disponiblidad que en nuestro ejemplo será el
ldirectord.
Los recursos se definiran en /etc/ha/haresources

El formato viene bien descrito en los comentarios del propio fichero. En este ejemplo va a tener la
pinta:


#vi /etc/ha.d/haresources
Nodo01 IPaddr2::192.168.50.205/24/eth0/192.168.50.255 ldirectord::ldirectord.cf
LVSSyncDaemonSwap::master


El ficherito haresources será identico en todos los nodos del cluster. La referencia al nombre del nodo
es el nodo que será el preferido para actuar como master (en este caso el Nodo1).
El formato que vemos es:

Nodopreferido IP_para_el recurso1 recurso:parametro1.......
En el formato de la IP se ha especificado IP/mascara/interfaz/broadcast.
El recurso LVSSyncDaemonSwap es el demonio que habilita las capacidades de la alta disponibilidad.
Sincronización en te los nodos, commutación...

Configuración de los servidores reales


Debemos configurar los servidores reales de modo que acepten el forwarding que les envía el
balanceador LVS por la IP virtual.
Tenemos que configurar un alias virtual que levante la direccion virtual y además hacer que sea “sorda”
a ARP de modo que no desvele la IP y no entre en conflicto.
Los cambios a realizar en los parámetros del kernel de los sevidores reales serán:

# /etc/sysctl.conf
#habilitar la opcion de ignorar ARP
net.ipv4.conf.all.ARP_ignore = 1
#No responder a las solicitudes de ARP si la direccion IP esta configurada sobre el interfaz
“lo” (loopback) o cualquier otro interfaz virtual eth0:0
net.ipv4.conf.eth0.ARP_ignore = 1
#Habilitar la opcion de anuncio ARP
net.ipv4.conf.all.ARP_announce = 2

Como la fuente IP de la peticon ARP entrará en la cache ARP del destino esto tiene el efecto de
anunciar esta direccion. Esto no es deseable para “lo” o cualquier otro interfaz virtual ethx:0 de los
servidores reales. Usando este valor haremos que los servidores reales siempre que reciban una peticion
ARP usen la IP real como fuente de la peticion ARP.

net.ipv4.conf.eth0.ARP_announce = 2

Y cargamos los cambios con:

# sysctl -p


Una vez hechos estos cambios ya tendremos la posibilidad de levantar el interfaz virtual que nos sirva
la IP virtual sin conflictos.
Definimos en los servidores reales sobre lo, la interfaz virtual lo:0 añadiendo:


# /etc/network/interfaces
...
iface lo inet loopback
auto lo:0
iface lo:0 inet static
address 192.168.50.205
netmask 255.255.255.255
Esta interfaz será la encargada de recibir el forwarding del balanceador.

Gateway:
Hay que tener en cuenta que la respuesta de los servidores reales será directa a los usuarios con lo cual
estos deben tener el router en el default gateway.
Con esto ya queda acabada la configuración.
Finalmente, ya solo queda arrancar el cluster ejecutando en todos los nodos del cluster :

# service hearbeat start
.... Y a depurar, claro.