Archivo

Archivo del autor

Seminario Práctico de gestión de crisis en Redes Académicas

miércoles, 19 de julio de 2017 Comentarios desactivados

Una crisis puede suceder en cualquier momento en una organización compleja como son las redes académicas (NREN, por sus siglas en inglés), ya sea por motivos intencionados (por ejemplo un ataque informático) o por temas fortuitos como puede ser una catástrofe natural u otras causas diversas. Por este motivo cada vez es más importante preparar, de forma preventiva, a las organizaciones sobre cómo afrontar estas crisis, ya que al final pueden producirse.

Para concienciar a las NRENS europeas, desde GÉANT se está organizando un seminario práctico de gestión de crisis que se celebrará en Málaga los días 20 y 21 de noviembre de 2017.  Está abierto el plazo de inscripciones, al que se accede desde esta URL: https://eventr.geant.org/events/2691

 

El objetivo de este seminario es mejorar los planes de gestión de crisis que las distintas NRENs tienen implementados y ver como puede GÉANT como comunidad de redes académicas y de investigación europeas reaccionar ante una crisis a nivel paneuropeo.

El evento contará con miembros de las distintas NRENS europeas a nivel de operación de Red (NOC), comunicación y equipos de seguridad (CSIRT).

RedIRIS, que colabora en la organización del seminario, quiera agradecer a la universidad de Málaga su propuesta de alojar este evento.

Categories: Sin categoría Tags: ,

Seminario Práctico de gestión de crisis en Redes Académicas

miércoles, 19 de julio de 2017 Comentarios desactivados

Una crisis puede suceder en cualquier momento en una organización compleja como son las redes académicas (NREN, por sus siglas en inglés), ya sea por motivos intencionados (por ejemplo un ataque informático) o por temas fortuitos como puede ser una catástrofe natural u otras causas diversas. Por este motivo cada vez es más importante preparar, de forma preventiva, a las organizaciones sobre cómo afrontar estas crisis, ya que al final pueden producirse.

Para concienciar a las NRENS europeas, desde GÉANT se está organizando un seminario práctico de gestión de crisis que se celebrará en Málaga los días 20 y 21 de noviembre de 2017.  Está abierto el plazo de inscripciones, al que se accede desde esta URL: https://eventr.geant.org/events/2691

El objetivo de este seminario es mejorar los planes de gestión de crisis que las distintas NRENs tienen implementados y ver como puede GÉANT como comunidad de redes académicas y de investigación europeas reaccionar ante una crisis a nivel paneuropeo.

El evento contará con miembros de las distintas NRENS europeas a nivel de operación de Red (NOC), comunicación y equipos de seguridad (CSIRT).

RedIRIS, que colabora en la organización del seminario, quiera agradecer a la universidad de Málaga su propuesta de alojar este evento.

Categories: Sin categoría Tags: ,

Protegido: Seminario Práctico de gestión de crisis en Redes Académicas

miércoles, 19 de julio de 2017 Comentarios desactivados

Este contenido está protegido por contraseña. Para verlo introduce tu contraseña a continuación:

Categories: Información general Tags:

¿Por qué el PGP Keyid “corto” no es suficiente ?

miércoles, 24 de agosto de 2016 Comentarios desactivados

Cuando se genera un par de claves PGP se tiene entre otras cosas un identificador de clave (“KeyID”) de 8 caracteres, que se suele emplear muchas veces para referenciar la clave, por ejemplo :

gpg -kv seguridad@rediris.es
gpg: using PGP trust model
pub 8192R/84CE6AC8 2014-05-06
uid [ultimate] Seguridad <seguridad@rediris.es>
sub 8192R/BB3F1160 2014-05-06
sub 4096R/9F0213FD 2014-05-06

El “84CE6AC8” es lo que se suele indicar como identificar de clave y para indicar que es hexadecimal se suele poner con 0x84CE6AC8

En el RFC 4880 donde se especifica la implantación de PGP se indica como se obtiene este KeyID https://tools.ietf.org/html/rfc4880#section-12.2  , existe la opción de generar un KeyId largo (16 caracteres indicando la opciòn –keyid-format long al Gnupg:

 gpg -kv --keyid-format 0xlong seguridad@rediris.es
gpg: using PGP trust model
pub 8192R/0xB3C8DD8484CE6AC8 2014-05-06
uid [ultimate] Seguridad <seguridad@rediris.es>
sub 8192R/0xDDBA3D64BB3F1160 2014-05-06
sub 4096R/0x35C65CFE9F0213FD 2014-05-06

Mucha gente emplea el KeyId a la hora de buscar la clave, sin embargo desde hace algún tiempo se lleva advirtiendo de que es posible generar par de claves PGP que contengan el mismo KeyId que otra ya existente, este par de claves no podría usarse para descifrar mensajes de la clave original, pero podrían servir para falsificar la identidad de una, persona o dirección.

Por ejemplo si alguien recibe un correo de seguridad@rediris.es  firmado con una clave PGP que tenga el mismo KeyId corto que seguridad@rediris.es podría tomar este correo como válido aunque fuera un phising o un ataque dirigido,  ya que muchas veces no se comprueba “la red de confianza “(Web of Trust), de PGP https://es.wikipedia.org/wiki/Anillo_de_confianza .

Todo esto se conocía de forma teórica. pero el 15 de Agosto, salto este correo en la lista de desarrollo del kernel de Linux,  ( https://lkml.org/lkml/2016/8/15/445 )  indicando la existencia de varias claves PGP falsas de algunos de los desarrolladores más importantes.

mail-pgp

En algunos sitios, como http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html  se comentan, pero  tras una semana no hay mucha información, aunque buscando en los servidores de claves PGP la clave de Linux Torvards, 0x00411886 , aparece una serie de datos curiosos  https://pgp.rediris.es/pks/lookup?search=0x004118861&op=vindex :

  • La clave PGP “falsa” tiene mucha firmas asociadas, pero todas son del mismo día (2014-08-05)
  • Estas claves PGP que han firmado la clave son también falsas, parece que se intenta “clonar” la red de confianza de forma que se pueda engañar a los usuarios.
  • La clave PGP fue revocada el día 16 de Agosto, al igual que las claves falsas,

La red de confianza generada para esta clave PGP falsa de Linux Torvards y para el resto de claves , se puede ver en los siguientes gráficos , generados utilizando sig2dot.pl , https://github.com/francisco-monserrat/sig2dot , haciendo lo siguiente:

  • En un keyring vacio de GnuPG se añade la clave PGP falsa.
  • Sacamos un listado de todas las claves que la firmaron
  • Buscamos y añadimos todas estas claves al keyring
  • Utilizamos esta información para generar un grafo con sig2dot.pl y después utilizamos Graphviz para generar un PNG del grafo.

 

torvard.dot

Este gráfico  muestra que no solamente firmaron la falsa de Linux Torvards, volviendo a buscar las claves “falsas” paver ver si había otras firmas aparece el siguiente grafo.

second.dot

Los nodos sin conexión son debidos seguramente a algunas claves “verdaderas” que se mezclaron en la búsqueda. (la verdad es que tendría que investigar algo más.

Todas las claves además guardan la misma relación de fechas de creación y revocación, ,Buscando en la información del servidor de claves de RedIRIS, por las estadisticas se vé que efectiamente el día 16 se actualizaron muchas claves:

Time New Keys Updated Keys
2016-08-22 845 464
2016-08-21 650 369
2016-08-20 662 365
2016-08-19 924 366
2016-08-18 1067 468
2016-08-17 1029 480
2016-08-16 27501 24242
2016-08-15 878 425
2016-08-14 830 248
2016-08-13 736 12
Por fortuna en la lista de administradores de los servidores de clave PGP aparece la solución, http://lists.nongnu.org/archive/html/sks-devel/2016-08/msg00019.html ,  ya que indican un enlace a la siguiente discusión en ycombinator https://news.ycombinator.com/item?id=12296974
Al Parecer en https://evil32.com/  se han dedicado a recrear todas la información de todas las claves en el “anillo fuerte” de PGP y algún usuario había subido las claves a los servidores de claves PGP , por lo que para evitar problemas los responsables del sitio revocaron todas las claves falsas y las subieron a los servidores de claves PGP, de forma que todas estuvieran “anuladas” por si hubiera dudas.
Aunque PGP / GnuPG sigue siendo un método seguro para cifrar y firmar información,  los problemas comentados anteriormente y que en los ejemplos de evil32.com están bien comentado s,  https://evil32.com/examples.html  indican muchas veces la falsa seguridad del empleo “incorrecto” de PGP:
  • No se emplea/mantiene una Red de confianza (Web of trust), mediante “fiestas de firmado de claves”, https://es.wikipedia.org/wiki/Fiesta_de_firmado_de_claves  es decir reuniones en las que se comprueba la identidad de la persona mediante identificadores oficiales (DNI, pasaportes, etc) y se hace hincapié en  la verificación del fingerprint (huella digital de la clave).
  • Esto hace que mucha gente solamente porque la firma de un mensaje o fichero sea válida, la da por correcta, sin verificar la identidad de las firmas  que pueda tener esta clave, además en muchos sistemas se configura GnuPG para que de forma automática se descargue las claves PGP que no tenga en su keyring,
  • solamente se verifica “visualmente” que el nombre y correo de la clave correspondan  con el emisor del mensaje
  • Mucha gente confia en que la información puesta en la web (muchas veces sin SSL/HTTPs) indicando  una clave PGP es valida.

La solución pasa desde luego por la utilización correcta de la red de confianza de PGP.

 

Categories: Criptografía Tags:

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.