TCP Split Handshake

Que mejor forma de retomar el blog que mandando un afectuoso salud a mis apreciados lectores, si los tuviera delante haríamos algo tal que así:

GigA --------->Hola:Lector

GigA:Hola + Mano<----------Lector

GigA:Mano<---------------->Mano:Lector

Etc.

Esto por si no lo habéis entendido es un saludo normal y corriente, que da paso a una conversación. Los humanos, fieles copiadores de lo que vemos en el mundo real decidimos trasladar esta forma de saludo a la informática, para que dos ordenadores pudieran iniciar su conversación lo harán de la misma forma. Es lo que conocemos como ThreeWay-Handsake , que originales somos:

Lo gracioso es que en el mundo virtual, al igual que en el real, pasamos del saludo a 3 bandas y pillamos a alguien desprevenido y le damos una colleja diciéndole: ¡ay maestro agujas!, ¡como vá capataz! (resto de saludos José Mota©), sin dejarle hablar ni nada. Esto entre colegas e incluso desconocidos puede ser gracioso, pero entre frías máquinas sin corazón es desastroso, tanto como que pueden reaccionar de formas raras, reiniciándose, parándose, ignorándote o accediendo a un nivel superior de funcionalidad (muchas veces esto también puede ocurrir con las mujeres), así una máquina se queda algo confusa cuando se le intenta abrir una conexión por ejemplo un SYN SEQ 1000, te responde con un SYN ACK 1000+1 SEQ 1500, y tu ignoras completamente su respuesta y vuelves a hacer otro SYN, y otro, y otro, y vas cambiando puerto, o le saturas un servicio a intentos de conexión, etc. Son muchas de las variedades de handshake que se pueden hacer en un escaner de puertos (para lo que vendría bien recordar esta entrada).

Sin embargo parecía que estaba todo inventado en lo que a saludos se refiere, cual es mi sorpresa cuando ayer me encontré esta interesante investigación de la gente de Macrothink, el TCP Split Handshake. Trasladado al lenguaje humano sería como realizar el saludo de forma normal, pero definir y recalcar cada una de las fases sin hacer nunca 2 cosas a la vez (¿?¿?), vale. Os pongo la imagen y me explico:

¿Qué es lo que se ha hecho?, separar el SYN, ACK que hace el servidor en dos pasos bien diferenciados, en dos paquetes distintos, algo que recoge perfectamente la RFC 793 en su página 27. Algo tan inocente como esto se ha probado con IDS/ IPS, routers, servidores, etc. con resultados más que soprendentes, y es que un servidor que tenga el protocolo de establecimiento de conexiones TCP alterado puede comprometer a sus clientes en una infinidad de casos. Veamos como reacciona el cliente cuando el servidor hace el split:

Lo que era un ThreeWay Handshake acaba convirtiéndose un FiveWay,,, de esto no decía nada la RFC 793. Otras curiosidades de esta particular forma de saludarse son que algunos IPS (lo probaron con un Juniper) no detectaron el ataque, sirviendo el splits tcp como técnica de evasión ya que, al no detectar la conexión como establecida no detectaba ataque alguno. En caso de NAT se encuentra de todo, desde un PIX-515 que era incapaz de hacer NAT y salir hacia otras redes con el splits TCP a un Cisco 2631 que se metía hasta Internet, luego parece que dependiendo del caso el NAT a priori no nos protegerá de este tipo de intentos de conexión. Finalmente, si estás ofreciendo un servicio en un puerto cualquiera, digamos el 22, y tu máquina es sometida a un escáner de red con un NMAP o similares no reaccionará tampoco de la forma habitual, pudiendo quedar oculto ese servicio o mal identificado:

Efectivamente esto para un atacante persistente no es un problema pero por ejemplo, para un barrido de un virus puede ser una “medida de seguridad”.

En resumen, este comportamiento anómalo en el establecimiento de conexiones por Split Handshake va a obligar a todo tipo de proveedores de equipos de comunicaciones, servidores, appliances de seguridad, etc. a añadir una excepción más o a contemplar que el ThreeWay Handshake no es la única forma de establecer una conexión TCP. Parece mentira que algo que lleva tantos años usándose no haya sido evaluado por muchos fabricantes en el 2010.

Ah, si queréis jugar tenéis scripts de ejemplo y capturas de Wireshark aquí, está hecho en Ruby y necesitareis las librerías libpcap para poder ejecutarlo.

Salu2

Trusted Network Connect

Cuando a principios de Octubre hablamos de Trusted Execution / Trusted Plataform dentro del marco de arquitectura de procesadores segura dimos alguna pincelada de un término que a día de hoy es crucial en toda corporación, Trusted Network Connect.

Actualmente la ubicación del puesto de trabajo es dinámica, y cada vez lo es mucho más. Nuestro personal está sentado en sus oficinas, pero también está desplazado en un cliente y requiere conectividad contra servicios y recursos que tiene en su puesto de trabajo, también viaja y probablemente tanga una BlackBerry o similares con la que necesita revisar el correo corporativo, esto es solo la punta del iceberg: No todos los empleados son iguales, hay desarrolladores, gente de sistemas, comerciales, jefes, gerentes y directores. Becarios recién contratados y externos, muchos externos, ya que también hacemos Outsourcing. Este personal ajeno también necesita conectividad para dar su servicio, es más, probablemente lo hará todo desde sus propias oficinas o quizás tengamos un hueco para ellos en nuestra empresa.

El perímetro de la organización es maleable y se corre el riesgo de que no se puede dar una solución de acceso a sistemas y servicios segura y robusta. En definitiva, un problemón para los arquitectos de red y el personal de seguridad que requiere de soluciones. Es aquí cuando entran en juego los accesos de confianza.

El Trusted Computing Group da una serie de directrices genéricas independientes de la tecnología para orientarnos un poco en como deben ser esos accesos.

Network Access Control

Este concepto simplificado al extremo trata de que un “cualquiera” que llegue a tu organización no sea capaz de enchufarse a tu red bien, por que ahí hay una roseta vacía o bien por que la Wifi está abierta a invitados. Esto hoy en día es sencillamente intolerable, pero el NAC va mucho más allá definiéndose como un conjunto de medidas de seguridad que nos aseguren que solo accederá a nuestra red aquel que tenga los correspondientes permisos y cumpla con un mínimo de políticas de seguridad, NAC es:

• 802.1X
• DHCP
• VPN
• Cumplimiento GpO.
• Actualizaciones y parches del Sistema Operativo.
• Antivirus actualizado y homologado.

Pero esto no es todo, debemos ser capaces de proveer u

na infraestructura de acceso que a parte de cumplir con todo lo anterior sea capaz de dar acceso a los recursos necesarios según el perfil / rol del usuario, esto se debe apoyar de forma indudable en una arquitectura de red segura (con todo lo que implica a nivel de VLANs, firewall, routing, etc.). Además los permisos de acceso deben ir alineados con los recursos accedidos, probablemente una persona de desarrollo necesite ser administrador en su equipo y trabajar en un entorno aislado alejado de producción, de igual forma se debe evitar que un administrador de BBDD sea capaz de modificar los datos que gestiona, siendo esta capacidad exclusiva de sus usuarios (esto creo que lo llamaban segregación de funciones).

Ahora bien, todo esto no es nuevo, las conexiones de confianza pueden llegar mucho más lejos y alcanzar a todos los dispositivos de mi red, impresoras, telefonía VoIP, cámaras de seguridad, etc. cuya actividad también deberá estar regulada. De manera adicional se instalarán sondas, IDS/IPS que controlen y detecten la actividad de los dispositivos / usuarios en la red, aquí es cuando surge un elemento adicional, el IF-MAP (Interface Metadata Access Point) Para no perdernos echemos un ojo a la siguiente imagen:

En la misma tenemos nuestros clientes “de confianza”, seguridad a nivel de red 802.1x, switches, routers, radius, firewalls, Policy Decision Point y, como capa adicional antes de llegar a los controles de seguridad aparece IF-MAP, ¿Qué es esto?, Con IF-MAP tenemos un protocolo cliente – servidor basado en XML y que utiliza SOAP + HTTPS. Su misión principal es recolectar datos de los dispositivos de red, metadatos que nos den una idea de quien es, a qué accede, que está solicitando y haciendo, etc. La estructura de los mensajes que maneja es la siguiente:

• ip-adddress (v4 or v6)
• mac-address
• identity aik-name:

1. dns-name
2. email-address
3. kerberos-principal
4. trusted-platform-module
5. username
6. sip-uri
7. tel-uri
8. other (vendor defined)

• access-request
• device

Como imagináis esto abre un abanico de posibilidades a la hora de controlar los accesos a la red que delega en el Metadata Access Point controles de seguridad que en tiempo real detectan accesos inapropiados, dispositivos que tratan de acceder a recursos que no deben, alarmas (falsas o no) alineadas con el resto de dispositivos, etc. No han sido pocos los fabricantes que se han subido al carro del IF-MAP, en esta pequeña diapositiva se pueden ver algunos de ellos.

El paradigma de acceso a la red seguro con un servicio de confianza está cambiando continuamente, hay mucha tela para cortar aquí ya que estamos hablando de confianza extremo a extremo, multitud de capas de acceso, ingeniería de conocimiento y redes bayesianas para decidir cómo actuar sobre un dispositivo, etc. Por suerte hay mucha información disponible en la red, herramientas Open Source como FreeRadius, OpenSea 802.1X, el proyecto libTNC, etc.

Precaución, amigo conductor (happy bridge).

Salu2!

Firewall Suizo

Jamon de York, mantequilla, un firewall y pan de molde, eso sí es un buen sándwich.

Respuesta: Sólo si el firewall es Suizo.

Hoy vamos a hablar de una tecnología nueva en el mundo de la Seguridad de la Información, concretamente en el capítulo de “Seguridad de las comunicaciones”.  Exacto, vamos a hablar de los Firewall (y no, no me refiero a la película de Harrison Ford). ¿Por qué digo nueva? Bueno, principalmente por que considero que estos dispositivos tienen que estar al día siempre. Un firewall tiene que ser tan nuevo como los servicios de nuestra empresas, o mejor dicho, sus políticas de seguridad.

Repasemos, un cortafuegos sirve (a muy grosso modo) para separar redes distintas dejando tan solo los flujos de comunicación que consideremos legítimos o válidos. Por ejemplo, el firewall que nos separe del mundo Internet tendrá prohibido todo el tráfico de entrada, excepto algún servicio que publiquemos al mundo, llámese mi página Web. Lo mismo ocurrirá con los flujos de salida. Estos filtrados pueden hacerse de muchas formas dependiendo del nivel al que trabaje el cortafuegos:

1.- Filtrado de paquetes (1ª generación): Analiza los paquetes de entrada y ver si hay alguna regla definida que los deje pasar (suponemos que todo se rechaza por defecto). Vulnerables a IP Spoofing. Nivel 3 OSI.

2.- Filtrado por estado (2ª generación): Estos cortafuegos mantienen “en memoria” el rastro de cada conexión que se permite, detectando comportamientos anómalos o sospechosos como un ataque DOS. Pueden llegar al Nivel 7 OSI.

3.-  Proxy – Firewall (3ª generación): Trabajando en la capa de aplicación estos dispositivos son capaces de inspeccionar el tráfico de protocolos y servicios que trabajan a este nivel, detectando posibles exploits, comandos no permitidos, etc.

4.- Kernel Proxy – Firewall (4ª generación): Incluyen inspección profunda de paquetes, tecnología de detección / prevención de intrusiones, etc.

 Independientemente de que generación sea nuestro firewall, tendrá una base de reglas que a buen seguro habrá que revisar periódicamente. Estas reglas deben basarse en unos pocos principios básicos:

-          Todo se rechaza por defecto.

-          Solo se autoriza tráfico para servicios reconocidos en la organización.

-          La regla debe ser tan restrictiva como sea posible, a nivel de puertos (conociendo los puertos que manejan los servicios) y a nivel de IP (conociendo quienes van a demandar estos servicios).

-          Si un servicio se da de baja o cambia, deben cambiar o darse de baja las reglas asociadas al servicio (llamémosle gestión de cambios controlada).

Si no trabajamos con estos principios, nos encontraremos con cositas como esta:

Tiene pinta de ser un FWSM suizo. 

En mi experiencia el principal problema que he encontrado ha sido el de reglas obsoletas, que cubren servicios inexistentes o para máquinas que han migrado o simplemente desaparecido. Una solución es establecer un periodo de caducidad para las reglas, de tal forma que una alerta te avise el día que estas caduquen, no obstante esto se puede volver inmanejable en organizaciones que tengan decenas de firewall y por tanto cientos de reglas. No es un problema de fácil solución, la caducidad es una buena idea ya que obliga a revisar lo implantado, ahora bien, ¿Cuáles revisar de todas las decenas que pueden caducar en un día sin que el  administrador se vuelva loco? Se me ocurre comenzar por aquellas reglas por las que no pasa tráfico, estableciendo mecanismos como la baja automática en aquellas que no se produce un “match” durante 3 meses, siendo ese periodo configurable según la criticidad de las redes que se separan, no es lo mismo una red de ofimática que una de gestión, ni cuanto menos una red de datos (y todo ello sin provocarte DOS).

Mantener unas políticas acordes a nuestra arquitectura de red es crítico para la seguridad de nuestras redes, establecer los controles para verificar que se cumplen las políticas, también. Es la única forma de que nuestro queso tenga los agujeros que necesita, ni uno más, ni uno menos.

Más info en:

http://www.conectronica.com/200812052004/Nuevos-enfoques-en-el-an%E1lisis-de-la-tecnolog%EDa-firewall-componente-esencial-para-la-seguridad-red.html

http://en.wikipedia.org/wiki/Firewall

Salu2!! (Y cuidado en la vuelta de vacas xD)

Intrusiones y demás amistades.

En los últimos coletazos de 2008, primeros de 2009 tuve la oportunidad de participar en varias sesiones comerciales de los distintos distribuidores de IPS / IDS que hay en el mercado, en concreto estuve en charlas de Juniper, Tipping-point y Checkpoint. Independientemente de las bondades que cada uno de los productos podía ofrecer y de cual podía ser mejor según que red o que compañía pude encontrar frases de bombo y platillo como “mi producto no ofrece falsos positivos”, algo que a mi particularmente me impactó, no obstante tenía razón el comercial, el IPS solo detectaba los ataques que coincidían con firmas o patrones de ataque conocidos, lo que ocurre es que en ciertos entornos, por ejemplo desarrollo, es necesario hacer ciertas consultas que quizás no sean un ataque (al menos en ese entorno específico en esas circunstancias).

IPS Tipping Point
Familia IPS Juniper

IPS de Checkpoint, no veais el ruido que hacen los cacharros xD

Falsos positivos aparte, lo que me quedó bastante claro es que el despliegue de los IDS/IPS suponían una capa de seguridad adicional que formaba parte de la arquitectura de seguridad que estábamos aplicando. Por ejemplo nunca podrá suplir ni detener la propagación de un virus (archivo .exe normalmente) ya que suelen trabajar a nivel 3 de la pila de protocolos TCP/IP.

Otras preguntas que nos planteabamos eran, ¿Dónde lo ubicaremos?, ¿delante de nuestro router de salida a Internet?, ¿delante del firewall que protege al router?, ¿en tal DMZ?, Una forma de saber la respuesta a esta pregunta es hacernos otra, ¿qué queremos proteger?, ¿los Proxy, router, switch, granja de servidores?, ¿puestos de trabajo?, Es fundamental saber la grunularidad que vamos a dar, no es lo mismo saber que este ataque provino de la VLAN 118 que saber que el PC 191.168.10.99 de fulanito está haciendo SYN FLOOD a nuestro switch y tiene a todos los compañeros tomando café y roscón de reyes. Por que no lo olvidemos, ataques desde dentro o ataques desde fuera, siguen siendo ataques al fin y al cabo.

Cambiemos de tercio, ya tenemos el flamante detector de intrusiones (que también previene) en producción, ¿qué políticas aplicamos?, hay que recordar que lo más importante es proteger los servicios, ¿seguro que queremos cortar cierto tipo de tráfico con origen o destino nuestras granjas de servidores?. Es fundamental que un equipo de trabajo analice / estudie la ingente cantidad de información que va a generar nuestro aparato, la filtre, separe el trigo de la paja y “tunee” las políticas, constantemente. Primero cada semana (modo monitor, fail-open activado, lo que necesitemos), cada 15 días, cada meses (existen flujos que solo se dan una vez al mes, o al año), así hasta que todo quede perfectamente engrasado, los flujos que se corten deben ser bien conocidos, inteligentes, la información de las alarmas debe ser util, las estadísticas también, etc.

Solo entonces comenzaremos a tener esa capa adicional de seguridad, solo entonces nos sentaremos un poquito más cómodos, pero sin relajarnos mucho ;-)

Salu2.