Sniffing a protocolos FIX (Financial Information eXchange) [por A. Portabales]

Dentro de los reports de este año destacar también "Sniffing a protocolos FIX. Programando un plugin para ettercap", de Adrián Portabales Goberna. Referente a los FIX, señalar que estamos ante un protocolo en el ámbito de los servicios financieros.

Sniffing open WiFi networks is not wiretapping, judge says

http://arstechnica.com/tech-policy/2012/09/sniffing-open-wifi-networks-is-not-wiretapping-judge-says/

[Fuente.: P. Arias, gracias]

Bitácora de PSI.: Póntela, pónsela

Analizada la problemática del "sniffing", es la hora de hablar de protección (póntela, pónsela).

Iniciamos esta nueva aventura con dos posibilidades de detección, la primera mediante IDSs, IPSs, sensores y demás familia a nivel de red integrados en la forma de "hardware" dedicado y, la segunda, mediante el uso de "mirroring" entre puertos de los activos de red (port span), y el uso de I[DP]Ss y demás familia asociados en el ámbito freeware. La posiblidad de "port span" de varios puertos, o toda una VLAN, contra un puerto, facilita las tareas de detección a nivel de red con un mínimo gasto. Para evitar cuellos de botella se puede asociar el "port span" al "trunk" de puertos. Obviamente, esto supone un coste para la matriz de conmutación del activo y de posibles cuellos de botella. A nivel operativo, se muestra la implementación de "port span" en los activos cisco.

Otro aspecto a considerar se debe centrar en evitar los llamados "reinos de taifas". Aspectos de importancia como la definición de VLANs, segmentación, filtrado, "firewalling" y seguridad perimetral (no es la panacea pero ayuda), I[DP]Ss, cifrado [a nivel 3 o de aplicación], control-administración total sobre las máquinas de la organización, entro otras, están siempre presentes.

Supongamos una organización que ha invertido muchos recursos en seguridad (€ y humanos), y que presumiblemente todo parece bien organizado y securizado. Dentro de sus muchas redes, servidores y cientos de PCs, un día un usuario con capacidades de administración en su equipo ubicado en una red interna, sea directamente o mediante el uso de un "live-cd", decide conectar su equipo a internet por medio de una conexión propia (cable, 3G+, etc.), pudiendo montar todo tipo de software, proxys, NAT, etc., que enmascare las conexiones exteriores. Claramente tendríamos un problema. Sin el control total de todos los equipos es prácticamente imposible detectar este tipo de actuaciones. Unido a esto, es aconsejable tener una política de seguridad, que incluya un acuerdo firmado con el personal en el que quede claramente reflejado lo que se puede y no se puede hacer. Dejar las normas claras es la mejor herramienta de trabajo, tanto para los directivos de las empresas y departamentos, como para los propios trabajadores.

Un sistema comprometido debe tratarse como tal. No es normal ver que "profesionales" que detectan en su organización sistemas comprometidos, o que tienen un comportamiento poco normal, los dejen como última tarea en su ponderación de trabajos, y que pasen los meses y dichos equipos sigan en la misma situación. Claramente están comprometiendo la información de todos los usuarios y de otros muchos sistemas. El buscar un equilibrio-acuerdo con el no-invitado, y no hacer nada a no ser que el sistema deje de funcionar o dar servicio, no es aceptable. Recuerda que hay que seleccionar entre la "pastilla roja" o la "azul", y que en muchas ocasiones "la ignorancia es la felicidad". Sin duda alguna nadie es infalible, ni mucho menos, pero debemos poner lo que esté en nuestra manos para solucionar problemas, antes de generar otros nuevos. No hemos hablado de ingeniería social en clase, otra de nuestras amigas inseparables, pero siempre deberá estar muy presente.

Continuando con los mecanismos de seguridad analizamos el llamado "port security". Antes de nada, se estudia el funcionamiento de los conmutadores de red y la forma en la que gestionan las conexiones a nivel 2. Además, se muestra la implementación de "port security" en los activos cisco, sus opciones, implicaciones y la necesidad de su integración en los sistemas de gestión de red.

Se presentan otras herramientas de gran utilidad contra el "ARP Spoofing", como "arpalert", "darpwatch", "xarp" y "arpwatch". A nivel operativo, se analiza el funcionamiento de "arpwatch", su configuración y esquema de funcionamiento.

--
- La curiosidad mata la ignorancia
- La curiosidad impulsa a los seres a buscar la información y la interacción con su ambiente natural y con otros seres en su vecindad
- El estilo de vida de las ciudades es un claro enemigo de la curiosidad

Bitácora de PSI.: Logs

Hoy terminamos la aventura del "sniffing". Cerramos el tema con las técnicas de detección.

En primer lugar se analizan las técnicas de detección de interfaces en modo "promisc", aspecto directamente relacionado con el "sniffing" en medio compartido. Señalar que muchas de las técnicas de "sniffing" en medio conmutado no requieren este cambio en el interface de red. En concreto, se estudian las técnicas etherping test, ARP test, DNS test y test ICMP ping de latencia. Además, se presentan algunas herramientas relacionadas, como CPM (Check Promiscuos Mode), NEPED (Network Promiscuos Ethernet Detector), Antisniff, SnifDet o NAST.

En un segundo punto se repasan las técnicas contra el "sniffing" en medio conmutado.: detectores (a nivel de host y, o, red), filtrado, port security, cifrado, formación del usuario, etc.

En este punto, y tomando como partida una pregunta planteada por un alumno, iniciamos un pequeño módulo dedicado al servicio de "logs" centralizados. En uno de los apartados de la práctica 1 se pide que la información de "log" de vuestra máquina virtual se envíe a otra. Un alumno pregunta, ¿esto es para que los del otro equipo sepan lo que le pasa a mi máquina?. Saber hacer las cosas está bien, para saber además cuando se deben hacer, la utilidad de las mismas, etc., está mucho mejor. Como es habitual, casi nunca encontraremos dos implementaciones iguales, que siempre dependerán del entorno de trabajo, entre otros muchos factores. Por lo tanto, iniciamos una pequeña pero nueva aventura por el apasionante mundo de los servidores de "log".

En primer lugar se incluyen varias ideas relacionadas.:

- Sin información de lo que acontece en los sistemas estamos ciegos. En este punto no debemos olvidarnos de una toma de decisión desde el punto de vista que "la ignorancia muchas veces es la felicidad".
- La facilidad que nos proporciona para "correr", por ejemplo, IDSs de host sobre toda la información centralizada.
- Facilita las alertas en "tiempo real"
- Las posibilidades de auditoría, trazas antes ataques y como herramienta para una análisis forense. Se mejora considerablemente el seguimiento y correlación de eventos con varios equipos involucrados.
- Dificulta el borrado de información de "log" después una intrusión en un sistema.
- Para tareas de análisis de "performance", "tunning" y administración.
- Facilita el proceso de "backup" de la información de log.
- Servicio habitualmente vinculado al puerto 514, que puede ir tanto en UDP como en TCP.
- Necesidad de usar servidores redundantes de log con una adecuada ubicación que incremente la disponibilidad del servicio.
- Todo servidor debe hacer "log", máquinas linux-unix, máquinas windows, activos de red, etc., etc. En muchas ocasiones nosotros no seleccionamos las plataformas con las que tenemos que trabajar y es nuestra función administrar y securizar todas por igual.
- Necesidad de securizar los servidores de "log", entre otras, incluyéndolos en un segmento de red "seguro", con detección y filtrado en el acceso a segmento y, o, host, con un sistema operativo "seguro" (parcheado, capado, únicamente puerto 514) y "hardenizado" (toma traducción) [incorporar herramientas y, o, parches para fortalecer la seguridad del sistema].
- Necesidad de sincronización de relojes mediante, por ejemplo, NTP (Network Time Protocol).

En cuanto al subsistema de log, se muestras y describen los distintos niveles (EMERG, ALERT, CRIT, ERR, WARNING, NOTICE, INFO, DEBUG), así como los subsistemas generadores (AUTHPRIV, CRON, DAEMON, KERNEL, LOCAL0..9, LPR, MAIL, NEWS, SYSLOG, USER, etc.)

Analizadas las ventajas e implicaciones, incluimos una sección práctica basada en la herramientas syslog-ng, que incluye.:

- daemons y ficheros de configuración básicos
- formato y opciones del fichero de configuración /etc/syslog-ng.conf (options, source, filter, destination, log)

En este apartado finaliza la aventura de hoy. Nos quedan por delante 2 apasionantes horas en el laboratorio de prácticas dedicadas a la resolución de todo tipo de problemas prácticos. Señalar que es hora de dar por terminada la práctica 1 e iniciar los trabajos de la 2, por lo que se invita a todos los alumnos a que vayan pensando en defenderla.

Sed buenos, o al menos intentarlo

Bitácora de PSI.: Sniff & modificación

En este nuevo capítulo de una historia de buenos y malos, de malos que parecen buenos, y buenos que parecen malos, hoy nos dedicamos al lado malo.

Ha llegado el momento, y la práctica dos ha salido de la tostadora. Esta nueva versión ha crecido y presenta una primera parte, especializada en diversos temas de “sniffing” y mecanismos de protección, y una segunda, sobre “OS fingerprinting”, “host discovery”, “port scanning”, “rootkits”, DoS, mantenimiento de integridad en sistemas, etc. Se hace una presentación comentada de la misma a la clase, delimitando los objetivos de cada apartado. Dejamos esto aquí dado que esta es otra historia que generará futuras entradas.

Despues de analizar los aspectos teóricos involucrados en la problemática del "sniffing" y los mecanismos de protección, continuamos nuestra andadura presentando varias herramientas de “sniffing”, entre ellas, airsnort y aircrack (orientadas del mundo wifi), o específicas, como snmpsniff o websniff. Tomando la herramienta sniffit como referencia, se analizan sus principales opciones, ficheros de configuración, etc. También se referencian otras clásicas, como ethereal, tcpdump, entre otras.

En este punto surge una pregunta que se repite año tras año. El “sniffing” sobre tráfico en claro, no cifrado, no supone problema alguno, es rápido y directo pero, ¿se puede hacer “sniffing” y conseguir algo inteligible sobre protocolos seguros del tipo HTTPS?. Al respecto se ha incluido el clásico MITM HTTPS. Poniendo como ejemplo una red y mediante ARP spoofing entre una máquina o conjunto de máquinas a atacar, y el “router” del segmento, se define paso por paso el proceso para, entre otras cosas, capturar password en sesiones https. El proceso se fundamenta en la inyección de un certificado en el proceso de sniffing. Obviamente el tema está en el conocimiento del usuario de las herramientas y que acepte o no dicho certificado. Este ataque requiere el uso de herramientas como dnsspoof (para interceptar la paquetería DNS de retorno [origen puerto 53] de ciertos equipos-dominios para que resuelva sobre la IP del atacante), webmitm (para crear e inyectar el certificado) y, entre otras posibilidades de uso, el ettercap para el proceso de “sniffing”. Finalmente, el ssldump nos hará el trabajo sucio para obtener información de la-s sesión-es HTTPS que incluirá, entre otras, usuarios y “passwords”. Existen otras posibilidades de hacer un MITM para captura de HTTPS. El ettercap dispone de un “pluggin” para tal tarea, disponiendo de un certificado propio en el caso de que no se le proporcione uno. Si bien la primera opción la he probado en distintos entornos, el “pluggin” de ettercap no. Si alguien quiere animarse, siempre será una nueva experiencia.

Otra posibilidad de reciente aparición es la herramienta “sslstrip”, que mediante un MITM utiliza, en el caso de sesiones HTTPS, tráfico en claro (HTTP) con la máquina o máquinas atacadas, y HTTPS con el lado servidor. Como es lógico, todo ello acompañado de las correspondientes modificaciones en el tráfico con el atacado para que los sentidos del usuario-víctima presencie una sesión segura. Nuevamente estamos ante el problema de la baja fiabilidad de lo que perciben los sentidos. Sin duda alguna, curiosa herramienta que hace mucho más fácil el “sniffing” en HTTPS.

Otra herramienta de “sniffing” presentada es dsniff, que incluye un buen conjunto de herramientas, como arpspoof, dnsspoof, filesnarf, macaf, mailsnarf, tcpkill, urlsnarf, webmitm, webspy, etc.

Finalizamos la andadura por las herramientas con el ettercap, sus posibilidades, “pluggins”, filtros, etc. Para unificar herramientas, se recomienda utilizar el ettercap en las prácticas que, de ser necesario, se podrá complementar con otras.

Al final de la clase, un alumno, ante tal situación, pregunta por la solución, por los mecanismos de seguridad. En esta ocasión he querido darle la vuelta a la tortilla, empezando por las soluciones antes que con el problema, como un ejercicio para relacionar en inversa las temáticas. Para buscar alguna de las posibles soluciones remito a los alumnos a la clase del día anterior, haciendo un breve repaso de los posibles mecanismos de protección. Normalmente estamos acostumbrados a que se nos plantee un problema y posteriormente busquemos soluciones, en este caso he querido empezar la casa por el tejado. La curiosidad es la mejor herramiena del conocimiento.

Bitácora de PSI.: Sniffing y el lado oscuro

Analizada la problemática del "sniffing" (lado oscuro), el lado de la luz se debe centrar en las posibilidades-mecanismos de protección.

Iniciamos esta nueva aventura analizando dos posibilidades de detección, la primera mediante IDSs a nivel de red integrados en la forma de "hardware" dedicado y, la segunda, mediante el uso de "mirroring" entre puertos de los activos de red (port span), y el uso de IDSs asociados. La posiblidad de "port span" de varios puertos, o toda una VLAN, contra un puerto, facilita las tareas de detección a nivel de red con un mínimo gasto. Para evitar cuellos de botella se puede asociar el "port span" al "trunk" de puertos. A nivel operativo, se muestra la implementación de "port span" en los activos cisco.

Otro aspecto a considerar se debe centrar en evitar los llamados "reinos de taifas". Aspectos de importancia como la definición de VLANs, segmentación, filtrado, "firewalling" y seguridad perimetral (no es la panacea pero ayuda), IDSs, cifrado [a nivel 3 o de aplicación], control-administración total sobre las máquinas de la organización, entro otras, están siempre presentes.
Supongamos una organización que ha invertido muchos recursos en seguridad (€ y humanos), y que presumiblemente todo parece bien organizado y securizado. Dentro de sus muchas redes, servidores y cientos de PCs, un día un usuario con capacidades de administración en su equipo ubicado en una red interna, sea directamente o mediante el uso de un "live-cd", decide conectar su equipo a internet por medio de una conexión propia (cable, 3G+, etc.), pudiendo montar todo tipo de software, proxys, NAT, etc., que enmascare las conexiones exteriores. Claramente tendríamos un problema. Obviamente, sin el control total de todos los equipos es prácticamente imposible detectar este tipo de actuaciones. Unido a esto, es aconsejable tener una política de seguridad, que incluya un acuerdo firmado con el personal en el que quede claramente reflejado lo que se puede y no se puede hacer. Dejar las normas claras es la mejor herramienta de trabajo, tanto para los directivos de las empresas y departamentos, como para los propios trabajadores.

Un sistema comprometido debe tratarse como tal. No es normal ver que "profesionales" que detectan en su organización sistemas comprometidos, o que tienen un comportamiento poco normal, los dejen como última tarea en su ponderación de trabajos, y que pasen los meses y dichos equipos sigan en la misma situación. Claramente están comprometiendo la información de todos los usuarios y de otros muchos sistemas. El buscar un equilibrio-acuerdo con el no-invitado, y no hacer nada a no ser que el sistema deje de funcionar o dar servicio, no es aceptable. Recuerda que hay que seleccionar entre la "pastilla roja" o la "azul", y que en muchas ocasiones "la ignorancia es la felicidad". Sin duda alguna nadie es infalible, ni mucho menos, pero debemos poner lo que esté en nuestra manos para solucionar problemas, antes de generar otros nuevos. No hemos hablado de ingeniería social en clase, otra de nuestras amigas inseparables, pero siempre deberá estar muy presente.

Continuando con los mecanismos de seguridad analizamos el llamado "port security", y sus implicaciones contra el "MAC Flooding", "MAC Spoofing" y "ARP Spoofing". Antes de nada, se estudia el funcionamiento de los conmutadores de red y la forma en la que gestionan las conexiones a nivel 2. Además, se muestra la implementación de "port security" en los activos cisco, sus opciones, implicaciones y la necesidad de su integración en los sistemas de gestión de red.

Se presentan otras herramientas de gran utilidad contra el "ARP Spoofing", como "arpalert", "darpwatch", "xarp" y "arpwatch". A nivel operativo, se analiza el funcionamiento de "arpwatch", su configuración y esquema de funcionamiento.

En cuanto a la problemática derivada del "routing" en nuestras redes, únicamente los "routers oficiales" deben tener dicha capacidad. Ninguna estación debe tener capacidades de "routing" y, de ser el caso, se deberán tener las herramientas de detección oportunas para identificarlas. Y, por encima de todo, cifrar, cifrar y cifrar todo. Pero no de cualquier forma. Siempre con un buen esquema de cifrado, y formando a los usuarios (punto más débil), para que conozcan el funcionamiento de dichos protocolos y lo que se puede y no hacer. En pocas palabras, pon un buen cifrador en tu vida. Y recuerda que los usuarios también pueden estar en el lado oscuro.

En nuestra vida profesional deberemos tomar muchas decisiones, tal y como nos plantea Morfeo en Matrix, una de ellas será la pastilla a tomar, la roja (del conocimiento), o la azul (de la ignorancia "feliz"). Pero el camino de la luz no es fácil, y lo que en una empresa-organización puede ser rojo y azul, en otra el rojo se convierte en azul y el azul rojo. No todo es binario en este planeta. Identificar el código de colores de una empresa es una tarea compleja que requiere entrenamiento. Como ejemplo, lo que para Morfeo es rojo y azul, en el mundo de las estrellas en guerra el rojo se convierte en azul y viceversa. En la guerra de las galaxias, un mundo mucho más parecido al entorno empresarial actual que el de la enterprise, una espada láser verde o azul significa que utilizas la fuerza para bien, mientras la rojo es para los que utilizan la fuerza para el mal o que están en el lado oscuro. Recuerda que existen excepciones y otros muchos colores, como el violeta, que tiene mucho de azul y un poco de rojo, o el blanca, morado o amarillo. No te olvides que en el modelo RGB todos los colores se pueden obtener con los RGB, y que las tentaciones son muchas y es muy fácil pasarte al lado oscuro. Una vez en el lado oscuro, el regreso a la luz es prácticamente imposible. Finalmente, señalar que en la actualidad todo parece más binario que nunca, el mundo RBG no se estila, más bien o estás en un lado o en el otro, aspecto que sin duda alguna está en contradicción con el conocimiento, la razón y la profesionalidad.

[Un poco de humor en todo lo que se hace siempre está bien]

Bitácora de PSI.: Sniff, sniff (segunda parte)

Iniciamos el capítulo con un resumen de la clase anterior, analizando la técnica básica de "sniffing" en redes de medio compartido. En este punto se trata el concepto de interface en modo promisc, y sus implicaciones.

En un segundo punto, se analizan las implicaciones de un sistema comprometido, en el que no podremos fiarnos de nuestros sentidos, lo que vemos o procesamos, y la necesidad de integridad en nuestros sistemas. En la actualidad existe todo tipo de rootkits que permiten, entre otros, ocultar ficheros, procesos y conexiones de red, hacer accesibles recursos del sistema, etc., dificultando la detección del no-invitado.

A nivel operativo, se ha visto la posibilidad de "matar" una determinada conexión, o la habilidad para manejar el ancho de banda de una determinada conexión. También se analizan las diferencias entre "firewalls" y TCPwrappers.

Se hace un análisis de las técnicas clásicas de "sniffing" en redes de medio conmutado. En concreto, las técnicas de ARP spoofing, MAC flooding y MAC duplicating.

Bitácora de PSI.: Sniff

Para concluir las aventuras de capítulos anteriores, se hace una estudio del artículo “Host Discovery with nmap” de Mark Wolfgang. Este artículo, del año 2002, aunque nada técnico, presenta un cierto interés didáctico, tanto en el análisis básico de lo que ocurre en un proceso de “host discovery”, como en el estudio de las funciones básicas de un “firewall”.

Se inicia una nueva aventura que, unida al tema de categorías de ataques, nos llevará a seleccionar dos casos para estudio. El primero de ellos se centra en la categoría de intercepción y, como no, hablamos del “sniffing”. Iniciamos esta nueva aventura recordando algunos conceptos básicos (paquetería de red, comunicaciones en medio compartido [quedan pocas redes] y medio conmutado (swtiched)], los objetivos y utilidades del “sniffing” [tanto las del lado oscuro, como las del lado de la luz], etc. Se incluye una referencia de interés, "Linux Cross Reference", y se comenta su posible utilidad, tanto a nivel académico, como profesional.


Antes de iniciar esta nueva aventuras de "sniffing", también se hace un repaso al concepto de segmento de red y VLANs, incluyendo la descripción de protocolos como el 802.1q, 802.1d, o los conceptos de "trunking" y la gestión de varios interfaces virtuales sobre un interface físico, entre otras. Si te has perdido esta parte del capítulo de hoy, puedes repetir algunas jugadas aquí (trabajo de José Alejandro Pérez Rubio, de la Universidad Jaume I).

Y con todos estos conceptos, dejamos la trama dispuesta para un futuro desenlace en próximos capítulos.