NTP : no solo para la hora.

Viernes, 29 de enero de 2016 Comentarios desactivados

El protocolo NTP es utilizado para la sincronización de la hora en los equipos, necesario no solo para tener los logs bien sincronizados, sino cualquier otra aplicación que requiere tener la hora “exacta”  (controles de acceso, tarificación, etc), de hecho casi todos los sistemas operativos modernos emplean este protocolo para la sincronización horaria.

Por desgracia el protocolo NTP emplea UDP a la hora de realizar las consultas, lo que hace que este siendo muy utilizado para los ataques de denegación de servicio, como ya se comento en  una entrada de este blog,  , estos ataques se basan sobre todo en la posibilidad de falsificar el tráfico IP (spoofing) en algunas redes para así lanzar ataques contra servidores, que muchas veces no tienen NTP.

Por ejemplo la siguiente gráfica muestra dos ataques empleando NTP contra una organización conectada a RedIRIS , el verde aparece el trafico HTTP y HTTPS , mientras que en azul es el trafico NTP.

ntp-ataque

Se puede ver que cuando se produce el trafico NTP se reduce el trafico de ambos protocolos debido a que la saturación de la conexión hace que no se pueda recibir el trafico .

Asi mismo se puede utilizar NTP y otros protocolos  para descubrir equipos con IPv6 aun cuando empleen direccionamiento aleatorio, si los atacantes son capaces de controlar alguno de los servidores intermedios que se emplean públicamente para esta sincronización, aprovechando que en muchas organizaciones no se tiene establecido una jerarquía de sincronización NTP sino que muchos equipos se sincronizan directamente con los equipos de NTP configurados por defecto en los diversos sistemas operativos.

Para mitigar un poco estos ataques desde RedIRIS se pueden aplicar medidas que limiten el trafico NTP en las conexiones de las instituciones afiliadas pero se requiere que  haya definido una jerarquía de servidores a nivel interno de la organización y con RedIRIS de forma el número de equipos que realizan consultas NTP al exterior sea reducido.

Dentro de poco se ira públicando una serie de recomendaciones para la configuración de NTP en las instituciones afiliadas a RedIRIS.

Nueva edición del tutorial «Uniéndose a SIR2» durante las JT2015

Martes, 10 de noviembre de 2015 Comentarios desactivados

Tanto para aquellos que no pudieron asistir al tutorial «Uniéndose a SIR2» organizado la pasada primavera, como para aquellos que quieran avanzar en la instalación del que será su nuevo IdP SAML2int en SIR2, vamos a realizar una nueva edición de dicha sesión de formación, en la que contaremos de nuevo con la ayuda de compañeros de las universidades de Córdoba, Murcia, Málaga y Politécnica de Valencia.

La formación se desarrollará el lunes 23 de noviembre por la mañana, en la sala multiusos del Auditorio de Tenerife Adán Martín. Al día siguiente, 24 de noviembre, tendremos por la mañana la presentación sobre actualidad del Servicio de Identidad de RedIRIS, dentro de la sesión «Servicios de RedIRIS».

El contenido del tutorial no variará, si bien hemos corregido determinadas partes del mismo, y para la parte práctica queremos utilizar ya la infraestructura de SIR2, inclusive los SPs de pruebas de la misma. Repetimos de nuevo la lista de módulos del tutorial:

  1. Introducción a la federación de identidades
  2. El proveedor de identidad
  3. Proveedores de Servicio
  4. Atributos
  5. “Burocracia” para unirse a SIR2
  6. Interfederación: eduGAIN

Para la asistencia al tutorial se recomienda llevar:

  • Ordenador portátil
  • Navegador Firefox, con extensión SAMLTracer instalada
  • Cliente SSH

En esta ocasión disponemos de una sala grande, con sillas de tablero. Aunque se distribuirán enchufes por la sala, recomendamos a los asistentes que lleven su portátil con las baterías cargadas.

Si estás interesado en asistir al curso, la Persona de Enlace con RedIRIS (PER) que cursa tu inscripción a los Grupos de Trabajo y/o Jornadas Técnicas, debe marcar en el formulario de inscripción, que asistirás el lunes, 23 de noviembre.
Categories: SIR 2 Tags:

Fases de migración a SIR2

Lunes, 5 de octubre de 2015 Comentarios desactivados

SP de pruebas SAML2 en SIR2Dos preguntas recurrentes de cara a la migración a SIR2 de los Proveedores de Identidad actuales en la federación SIR (por diferenciar a la actual federación de la nueva, la llamaremos SIR1), son cuándo va a comenzar esta, y cuándo tendrá cada organización que actualizar su proveedor de identidad. En este breve artículo tratamos de describir el estado actual y explicar cómo será la migración.

Primero de todo quisiera aclarar en qué momento nos encontramos de la migración. Actualmente tenemos preparado un entorno que denominamos de validación, en el cual se encuentran probando, o están a punto de probar su conexión distintos grupos de organizaciones. La idea durante esta «pre-fase» o fase 0, es comprobar que la conexión de IdPs actuales PAPI al nuevo hub de SIR2 se realizará correctamente. Para esto hemos elegido diversos sabores del software instalado para realizar conexiones a los que serán los nuevos proveedores de servicio de pruebas en SIR2. También queremos comprobar en esta fase que además de estos proveedores de identidad PAPI, pueden convivir en el mismo hub y acceder de manera equivalente los proveedores de identidad con capacidad SAML2int existentes, que usan distintas implementaciones de SAML. Entre estos está el software de IdP de referencia, SimpleSAMLphp.

Dar fechas exactas del comienzo de la migración no es algo trivial, pues las pruebas a realizar son exhaustivas, y pudieran provocar retrasos adicionales, pero nuestra intención sería comenzar con la fase 1 de migración en las próximas semanas, o meses a lo sumo.

Respecto a la segunda pregunta que introducíamos al comienzo, hemos dividido el proceso de migración en 5 fases, donde las instituciones tendrán que implicarse en la migración de sus IdPs en las fases 1 a 3, especialmente durante la fase 3 que es la que implica actualizar el software de su IdP:
  • fase 1. Se conectarán todos los IdPs PAPI actuales de SIR1 al nuevo hub de SIR2 en su entorno de pruebas, sin perder en ningún momento la conexión existente a SIR1. El administrador de cada organización realizará pruebas de conexión al SP de pruebas PAPI en SIR2. Estas pruebas tienen como objetivo validar que los atributos que envía a dicho SP se corresponden con los que se envían actualmente en SIR1.
  • fase 2. Una vez realizadas las pruebas anteriores, el IdP PAPI en SIR1 se conecta con la entrada WAYFless del IdP PAPI en el entorno de producción de SIR2. De este modo, SIR2 comienza a funcionar, si bien inicialmente con los mismos IdPs PAPI que en SIR1, y utilizando el WAYF y pasarelas de SIR1, hacia SPs conectados también a SIR1.
  • fase 3. Seguidamente, las instituciones instalarán el software de IdP SAML2int, que sustituirá al componente PAPI que tenían desplegado hasta el momento. Todas las pruebas pertinentes se realizarán en el entorno de pruebas de SIR2, comprobando que el comportamiento del que será el nuevo IdP es equivalente al de su IdP PAPI.
  • fase 4. Los SPs conectados a SIR1 se irán migrando paulatinamente a SIR2. En el caso de todos los accesos de estos SPs, se utilizará al completo la federación SIR2. Esta fase puede solaparse sin problemas con la tercera en el tiempo.
  • fase 5. Por último, una vez se hayan desconectado todos los SPs de SIR1, se procederá al “apagado” de la antigua federación.

Aclarar que cada institución pasará por estas fases de manera independiente, por lo que en cada momento habrá instituciones en distintas fases. Indicar también que la fase 4, que implica la migración de SPs de SIR1 a SIR2, puede dar comienzo en paralelo a la fase 3.

Todas estas fases quedarán recogidas en una guía de migración de IdPs que estamos preparando, en la que se recogerá también una estimación del tiempo de duración de cada fase. Para la fase 3, estamos preparando también una guía de instalación del IdP de referencia, que anunciaremos en las próximas semanas.

En un próximo artículo, haré una comparación de los atributos en uso en SIR1, y los que se recomiendan en la nueva federación SIR2, incidiendo sobre cómo han de calcularse, su significado, y el uso dentro de la federación de los mismos.

Categories: Información general Tags:

Asimetrías de tráfico en Cortafuegos

Miércoles, 22 de julio de 2015 Comentarios desactivados

La mayoría de las veces los cortafuegos se ponen en modo “activo”, empleándose com router de interconexión de las diversas redes,  algo diferente a los cortafuegos de “aplicación” o pasarela como  FWTK o en su versión comercial (Gauntlet), que diferenciaban bien el tráfico, después se paso a utilizar los cortafuegos como routers y de ahí a pensar que las iptables son un firewall…

Ahora con los cortafuegos de “capa 7” (¿ cuando ha tenido TCP/IP 7 capas?) , se pueden poner muchas veces en “modo  trasparente” y esto hace que en muchas situaciones donde antes “no pasaba nada” ahora no funcione el tráfico , como puede  verse en el siguiente en el que un equipo dentro de una misma red hacía de router para una red interna distinta de la “ruta por defecto” y que no presentaba “problemas” hasta que se incluyo un cortafuegos de “nueva generación” transparente y en medio..

En el siguiente esquema se muestra como estaban situados los equipos:

red_interna

red_interna

En principio, no hay problemas hay un router y por defecto y el tráfico por defecto va al router y este llega va y vuelve sin problemas, el cortafuegos inspecciona el tráfico y no se ven problemas.

trafico_a_internet

tráfico a internet

El tráfico de las máquinas pasa por el cortafuegos con destino al router , este envía los paquetes IP a internet y la vuelta viene por el mismo sitio.

Para acceder a la red interna se tenían muchas opciones, pero lo “más cómodo” fue que el router principal tuviera una ruta definida de forma estática a esta red interna empleando un equipo interno que conectaba con la otra red, de forma que el tráfico a la red interna se enrutara por el equipo interno que hacía de router:

trafico_asimetrico

tráfico asimétrico

Ahora bien esto creaba un tráfico asimétrico los paquetes “de ida” de las estaciones de trabajo se dirigían al router (es su router por defecto), de ahí el router las reenviaba al equipo en la misma red interna que hacía routing y de ahí a la red interna, ahora bien el router interno no empleaba el router principal para reenviar los paquetes IP de vuelta, ya que al estar las máquinas en la misma red se enviaban directamente.

Al poner el cortafuegos en modo transparente este solamente veía los paquetes de ida (dos veces eso sí), por lo que por ejemplo para permitir el tráfico HTTP/HTTPS permitía el primer paquete (SIN) , que inspeccionaba, pero después al no tener el paquete de SIN/ACK , los siguientes paquetes no los enviaba al estar esperando este SIN/ACK.

En los equipos la conexión TCP/IP se establecía (ya que llegaba el SIN/ACK) pero después al bloquear el tráfico el cortafuegos no se podían enviar datos, ¿la forma final para depurar y comprobar que estaba pasando esto ?, emplear en el equipo de usuario una captura de paquetes y ver que la direcciones MAC que se empleaban en la comunicación no eran las que tenían que ser, ya que aunque los paquetes se enviaban al router principal era el router interno el que enviaba después a nivel interno el trafico.

trafico_macs

trafico_macs

Por defecto tcpdump no muestra la información de la direcciones MAC, por lo que hay que indicarlo con la opción -e y después comprobar en la tabla arp (arp -an ) a que equipo corresponde cada una de las MAC.

Se pueden establecer varias soluciones, que por diversos motivos se fueron descartando:

Poner rutas más especificas en los equipos de forma que no utilizarán el router principal para acceder a esta red sino que fueran directamente a la red interna, sin embargo los equipos se configuran por DHCPD y resulta que la opción de configurar varias rutas (RFC-3442 Classless Static Routes) no funciona en algunas de las estaciones de trabajo.

Forzar en el router interno a que el tráfico con destino la red de usuarios sea enviado al router principal, esto obligaría a emplear enrutamiento por fuente en este router (el routing normal suele ser por “destino”) y configurar el router principal para que cuando le llegue este tráfico no se queje mucho (algo raro que una máquina de la misma red envíe trafico a traves de el en vez de directamente.

Al final se decidió establecer una red de conexión “punto a punto” (un /30) entre los dos routers, de forma que el router secundario no estuviera en la misma red que los equipos de usuarios, estableciendo incluso una VLAN separada, de esta forma el tráfico al final pase por el cortafuegos siempre y no haya problemas de conexión.

IMG_20150717_110702

tráfico simétrico

Al final el tráfico pasa dos veces por el cortafuegos (qué se le va a hacer ), pero es un tráfico simétrico y el cortafuegos puede inspeccionarlo , comprobar que todo va correcto, no solo a nivel IP sino a nivel de aplicación y proteger de forma adecuada a los usuarios.

Categories: sistemas Tags: , ,

PGP hasta en las redes sociales

Martes, 2 de junio de 2015 Comentarios desactivados

Como paradoja de la vida, la ultima nota de fomento de PGP viene de la mano de FaceBook, que hoy ha anunciado que va a enviar los correos firmados con su clave PGP y que además si ponemos   nuestra clave PGP   en su servidor podemos recibir los correos de Facebook cifrados .

https://www.facebook.com/notes/protecting-the-graph/securing-email-communications-from-facebook/1611941762379302 

Una buena noticia para los amantes de la privacidad, que pueden recibir ahora sus notificaciones de Facebook con confidencialidad, veremos si esto sirve un poco para fomentar el uso de la criptografía en las comunicaciones por correo electrónico.

 

Categories: Criptografía Tags: ,