Esto puede constituir un pequeño desastre para todos los servicios que tengo montados, ya que hay que copiar todos los datos al nuevo servidor, tirar el servicio antes para que los datos no cambien, y levantar los servicios en el nuevo, asegurándose de que todo funcione… vale, por ahí, ya sé que van a ser un par de horas… pero el DNS… con su propia caché y demás, eso sí puede ser un gran problema.

Por ese motivo me puse a buscar y, a modo de post-it, me lo dejo aquí escrito para futuro, y por si alguien lo necesita también. Básicamente es: cómo redirigir el tráfico de un servidor a otro, empleando iptables.

Redirigiendo…

Vale, estoy en el antiguo servidor, tengo email y web. Los puertos por los que llega la comunicación, todos TCP, y posibilidad de SSL, pero en eso no hay mayor problema. En esencia tengo que cuidarme de las peticiones a los puertos: 80 (http), 443 (https), 25 (smtp), 465 (ssmtp), 110 (pop3), 995 (pop3s), 143 (imap) y 993 (imaps).

Buscando, vi esta web sobre como redireccionar tráfico, por lo que, escribí:

echo 1 >/proc/sys/net/ipv4/ip_forward
export IP=XXX.XXX.XXX.XXX
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination $IP
iptables -t nat -A POSTROUTING -p tcp -d $IP --dport 80 -j MASQUERADE

NOTA: como es lógico, hay que cambiar XXX.XXX.XXX.XXX por la IP del servidor al que se quieren redireccionar las peticiones al puerto 80.

Lo que hacen estos comandos es:

1. Indica al kernel que puede hacer forward de los paquetes que pasen por su interfaz de red.
2. Indica al sistema que los paquetes entrantes al puerto 80 sean dirigidos a la $IP indicada.
3. Indica al sistema que los paquetes que deban de salir, se emascaren modificando su IP de origen por la propia.

Con esto conseguimos que la comunicación hacia el puerto 80 pase sin problemas al otro servidor. Lo único, es que se desvirtúan las estadísticas, ya que para el servidor web, todas las peticiones son del servidor que redirecciona las peticiones, pero si es un recurso temporal (como es mi caso), no tiene mucha o mayor importancia

¿Cómo funciona el enrutado?

Encontré también otra página donde se explica bastante bien (aunque algo esquemática) la forma en que funciona el enrutado de paquetes empleando iptables, el gráfico:

Como puede verse, el paquete pasa por la cadena de reglas PREROUTING al entrar, es procesado y, cuando se detecta que es para otra máquina, se pasa a FORWARD y después a POSTROUTING, donde se pueden agregar reglas de modificación antes de que el paquete sea entregado a su destino.

Recomiendo echar un vistazo al enlace dado para ampliar más sobre el tema.

Conclusiones

Nada es perfecto al 100%, por ejemplo, esto mismo lo probé con XMPP, y no funciona correctamente, ya que la comunicación de s2s del protocolo espera que los mensajes lleguen del dominio (e IP) al que se solicita información, mientras que, estos mensajes, en su mayoría, al estar direccionados al dominio, no es la misma IP. No obstante, como medida temporal y sobretodo para HTTP, el apaño lo da.

Estimados, he decidido liberar la obra para que los interesados puedan disfrutarla de modo libre y distribuirla.

http://www.hackingetico.com

Espero que la disfruten, saludos.

Por lo que, tenemos ya a disposición de todo el mundo este increíble libro sobre seguridad y redes, de la mano de un autor que trabaja día a día en empresas de seguridad y sobre problemas de seguridad reales.

Lo que se trata en el libro, visto por capítulos es Cultura Hacker, Técnicas de búsqueda de información, Ingeniería social, Fuerza Bruta, Aplicaciones Web (XSS, Exploits, …), Inyección de SQL, Servidores Linux y Servidores Windows.

En esencia, son unas muy buenas lecciones sobre administración de sistemas, de cara a la seguridad y mantenerse alerta de por donde pueden venir los ataques más comunes. También tiene capítulos muy aconsejables para programadores, a nivel de codificación para evitar la creación de códigos maliciosos como exploits, o inyecciones de scripting o código SQL.

Debería de ser el libro de cabecera de todo administrador de redes y técnico en seguridad de todas las empresas TIC.

En un artículo sobre el tema, la alta disponibilidad, se decía que la disponibilidad de un servicio, servido únicamente por una máquina, normalmente es de un 90%, con lo que, a lo largo de un año (365 días) el servicio se ha mantenido en funcionamiento un máximo del 90%, aproximadamente, y ha tenido un tiempo de inactividad del 10% (más o menos unos 36 días).

Con sistemas de alta disponibilidad, es decir, teniendo más de una máquina siriviendo un servicio, la proporción se incrementa, pero siempre a razón de nueves. Es decir, con dos máquinas, tenemos una disponibilidad del 99%, con tres máquinas tenemos un 99,9%, con cuatro un 99,99% y así sucesivamente.

Como nota curiosa, hace poco leí que los sistemas desarrollados sobre Erlang/OTP tienen una alta disponibilidad de nueve nueves (99,9999999%), lo cual me parece algo increíble, pero totalmente cierto, ya que he probado la infraestructura y realmente es muy estable.

En lo que llevamos de año, se han sucedido grandes vulnerabilidades de seguridad. La primera ha afectado la protocolo DNS, la segunda al protocolo BGP y ha habido otra vulnerabilidad sobre SSL que ha afectado solo a las distribuciones Debian y derivadas del mismo.

Esta última vulnerabilidad afecta al TCP/IP, aunque matizan los expertos que, de momento, solo es supuesta y que no solo afecta a IP, sino al conjunto TCP/IP. De momento, hasta que sea publicada la vulnerabilidad de forma específica por la compañía sueca, estamos ante, incluso, un posible FUD.

De todas formas, Internet, la concepción de sus protocolos más usados (como DNS y SMTP), no estaban pensandos para ser seguros, sino prácticos, puesto que Internet era una red a la que pocos tenían acceso. Hoy en día, el enfoque ha cambiado, pero los protocolos siguen siendo los mismos y, quizás, el problema haya sido la forma de parcheo que se ha realizado sobre los protocolos existentes, en lugar de optar por desarrollar mejores protocolos orientados a las necesidades actuales.

¿Estamos ante una necesidad de cambio en los protocolos de Internet?, ¿se nos hunde Internet?, no lo creo… pero llegan momentos difíciles y quizás vientos de cambio