Archivo

Archivo del autor

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

miércoles, 19 de julio de 2017 Sin comentarios

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.

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

miércoles, 24 de agosto de 2016 Sin comentarios

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 Sin comentarios

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.

Categories: Sin categoría Tags: , ,

Asimetrías de tráfico en Cortafuegos

miércoles, 22 de julio de 2015 Sin comentarios

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 Sin comentarios

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: ,

Atacantes en IPv6

martes, 19 de mayo de 2015 Sin comentarios

Revisando los logs del cortafuegos esta mañana aparece el siguiente paquete que ha sido marcado como un Ataque de inyección de código en bash “Bash Remote Code Execution Vulnerability”, el famoso ShellSock CVE-2014-6271 .

El paquete ethernet capturado es el siguiente:

19:37:20.000000 AA:BB:CC:DD:EE:FF > ZZ:XX:YY:SS:TT:RR, ethertype 802.1Q 
(0x8100), length 305: vlan XX, p 0, ethertype IPv6, (hlim 54, next-header: 
TCP (6), length: 247) 2001:41d0:2:c59e::1.53537 > 2001:720:418:cafd::20.80:
 P, cksum 0xca79 (correct), 1838219336:1838219551(215) ack 3534929269 win
 113 <nop,nop,timestamp 1314898790 2658160117>

	0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................
	0x0010:  0000 0000 0000 0000 0636 2001 41d0 0002  ................
	0x0020:  c59e 0000 0000 0000 0001 2001 0720 0418  ................
	0x0030:  cafd 0000 0000 0000 0020 d121 0050 6d91  ................
	0x0040:  0048 d2b2 bd75 8018 0071 ca79 0000 0101  ...............
	0x0050:  080a 4e5f c366 9e70 4df5 4745 5420 2f6c  ..N_.f.pM.GET./l
	0x0060:  6973 742f 7075 626c 2f68 6572 7261 6d69  ist/publ/herrami
	0x0070:  656e 7461 2e70 6466 2048 5454 502f 312e  enta.pdf.HTTP/1.
	0x0080:  310d 0a41 6363 6570 742d 456e 636f 6469  1..Accept-Encodi
	0x0090:  6e67 3a20 6964 656e 7469 7479 0d0a 486f  ng:.identity..Ho
	0x00a0:  7374 3a20 7777 772e 7265 6469 7269 732e  st:.www.rediris.
	0x00b0:  6573 0d0a 436f 6e6e 6563 7469 6f6e 3a20  es..Connection:.
	0x00c0:  636c 6f73 650d 0a55 7365 722d 4167 656e  close..User-Agen
	0x00d0:  743a 2028 2920 7b20 666f 6f3b 7d3b 6563  t:.().{.foo;};ec
	0x00e0:  686f 3b20 2f62 696e 2f62 6173 6820 2d63  ho;./bin/bash.-c
	0x00f0:  2022 6578 7072 2032 3939 3636 3332 3939  ."expr.299663299
	0x0100:  3636 3520 2f20 333b 2065 6368 6f20 3333  665./.3;.echo.33
	0x0110:  333a 3b20 756e 616d 6520 2d61 3b20 6563  3:;.uname.-a;.ec
	0x0120:  686f 2033 3333 3a3b 2069 643b 220d 0a0d  ho.333:;.id;"...
	0x0130:  0a                                       .

Hasta aquí todo normal, hasta que viendo la dirección IP origen del ataque aparece como tipo de protocolo IPv6 y dirección 2001:41d0:2:c59e::1 , parece que IPv6 empieza a verse en algunos ataques además del Spam.

 

Webber: Páginas estáticas en el siglo XXI

viernes, 8 de mayo de 2015 Sin comentarios

En el articulo  de la publicación de Web Security de la ACM Paul Vixie hace una defensa del uso de páginas estáticas a la hora de proteger los servidores WWW ante las distintas amenazas existentes tanto ataques de denegación de servicio como intrusiones , modificación de páginas WWW , etc lo que nos lleva a comentar el funcionamiento de Webber.

Desde hace mucho tiempo  (aproximadamente 1996 ) en RedIRIS se emplea un sistema para la generación de los contenidos en las páginas WWW llamado webber,  (sin referencia ninguna al corredor de formula ;-), que aunque odiado por muchos sigue todavía se mantiene, webber hace las funciones de gestor de contenidos (CMS como lo suelen llamar en ingles) generando las páginas HTML de forma uniforme en base a una plantilla y de forma estática.

Webber ha pasado por varios cambios inicialmente era un simple programa en Perl que en base a una plantilla fija y un texto HTML sin cabeceras (el contenido de la página), generaba una página HTML con una apariencia definida, cabecera, pie de páginas, etc. la tipica página de “Hola Mundo” en webber era más o menos:

#title= Hola mundo
#athor= anonimo
#wbbIn= 
Hola mundo<p>
¿Como estas ?

Donde los valores con corchete “#” indicaban el nombre de una variable  (que podía tener varias lineas) que después se rellenaba en la plantilla. Había varias variables definidas, title para el titulo, wbbIn para el contenido la página,  description para la descripción, keyword para las palabras clave , etc.   Además y para facilitar se tenían ficheros de plantilla para incluir valores que iban a ser comunes dentro de un subdirectorio , como “author” y se tenía “herencia”, ya que las plantillas se procesaban por todo el arbor de directorios desde la raíz del código.

En una primera evolución se paso a separar las funciones en diversos procesadores, de forma que se pudieran tener varias plantillas (el nombre de la plantilla a utilizar era al final otra variable “webber” ), se pudieran incluir tablas de forma rápida, colocar menus,  separar el código fuente de las páginas finales, etc. Al final muchas funciones que la mayoría de las veces utilizamos pocas veces.

Siguiendo con la evolución y como al final la utilización del “vi” en sus diversas versiones era cada vez más compleja (entre otras cosas por la aparición de las distintas codificaciones, ISO-8859, UTF-8, etc) y porque las páginas WWW no solas las editaban usuarios “expertos” al final se creo una entorno de edición “web” para al menos poder editar las páginas WWW desde el servidor y después utilizar webber para generar el contenido en base a los ficheros estáticos.

Así el webber ha ido evolucionando dentro de RedIRIS tiene hasta página web en el servidor, pero su uso fuera de RedIRIS ha sido muy escaso , seguramente por la complejidad de montar unas páginas “desde cero” y el abuso de la terminología exotérica que tiene la documentación y es que como siempre lo documentar y actualizar las cosas nos da algo de pereza.

Aunque Webber ha sido código libre desde el principio, la gestión del código siempre ha sido algo complicada y por eso   a finales del 2014 decidimos migrar el repositorio de código de Webber a github de forma que el código de webber este disponible en esta herramienta.

Coincidiendo con la publicación de esta entrada en el GitHub esta la versión 3.0 preliminar del webber, que permite una mayor flexibilidad a la hora de definir la entrada y salida y elimina algunos procesadores antiguos no utilizados, al ser una versión preliminar algunas cosas no están pulidas del todo , aunque es bastante funcional.

 

Un pequeño ejemplo de funcionamiento:

Descargar el fichero de github en un directorio y descomprimirlo ,

Editar el fichero webber.wbb  y cambiar la entrada “wbbRoot”  , por ejemplo,

#wbbRoot=/home/usuario/webber-master

Grabar el fichero.

El fichero de configuración será ahora mismo mas o menos.

##where the webber standard root start
 #wbbRoot=/XXXX/XXXX/XXXX/webber-master/
 ## Where "standard" processors are located
 #wbbProcLib= $var(wbbRoot)/proc
 ## Version
 ## Template dir name
 #wbbTemplateName= wbbdir.cfg
 #wbbFileNameRegExp = ^(.+)\.wbb$
 #wbbFileLangRegExp = ^.+(es|en|ca|gl)\.wbb$
 # Default extension
 #wbbExtension = .html
 #wbbDebugFile= $var(wbbRoot)debug.txt
 ##wbbDebugFile = ./debug.txt
 #wbbDebug = 10
 #wbbRun=File::SetTarget File::ReadVars wbbPre wbbProc wbbPost File::WriteVar
 #File.WriteVar= wbbOut
 #wbbPre=
 #wbbProc= Webbo::webbo
 #wbbPost=
 #webbo.src=file:$var(wbbRoot)src/test.webbo
 #webbo.dst=wbbOut
 #wbbSourceRoot= $var(wbbRoot)src
 #wbbTargetRoot= $var(wbbRoot)html
 #wbbMakedir=1

Las variables tienen el siguiente significado:

  1. wbbRoot : Base donde se encuentra el código de webber
  2. wbbProc: Donde se encuentran los procesadores webber
  3. wbbDebugFile : Path al fichero de debug
  4. wbbDebug : Nivel de depuración
  5. wbbTemplateName Fichero de “plantilla” utilizado para definir variables que afecten a todos los ficheros que haya en un directorio (y subdirectorios de el)
    wbbFileNameRegExp = Expresión regular para idenfitifcar los ficheros de fuentes webber
    wbbFileLangRegExp = Expresion regular para idenficar los ficheros de lenguaje
    wbbExtension = Extensión que tendran los ficheros destino
  6. wbbSourceRoot= Base donde se encuentran los fuentes webber
    wbbTargetRoot= Base a partir de donde se escriben los ficheros webber
    wbbMakedir Fuerza la creacion de directorios si no existen
  7. wbbRun: Listado de procesadores a ejecutar ya tiene  definido una serie de procesadores para tener el funcionamiento de webber 1.X por defecto,  los procesadores que se ejecutan son:
    • File::SetTarget : Define en base una serie de variables cual es el fichero que se va a escribir
    • File::ReadVars: Lee un fichero en formato webber y define las variables de forma apropiada
    • wbbPre , wbbProc , wbbPost : listas de procesadores a ejecutar, con compatibilidad con webber 1.X
    • File::WriteVar : Escribe en el fichero definido en la variable wbbTargetFile el contenido de una variable webber
    • De todos las tres colas de procesadores solo wbbProc contiene un procesador y es el Webbo
      • wbbProc = Webbo , Webbo es un procesador que reemplaza nombres de variables webber por su valor en un fichero / variable (apuntado en #webbo.src ) dejando el contenido final en webbo.dst , es utilizado a la hora tener una plantilla (ver el fichero src/(test.webbo) que después es rellenada, ahí se definen dos variables wbbIn y title
      • webbo.dst= wbbOut
      • webbo.src= file:$var(wbbRoot)src/test.webbo

Una vez modificada la variable wbbRoot para que apunte se puede hacer:

 

perl ./webber --config ./webber.wbb --help para ver el fichero de ayuda

con

perl ./webber --config ./webber.wbb --list-proc se puede obtener un listado de los procesadores instalados

y finalmente con:

perl ./webber --config ./webber.wbb src/* se procesan los dos ficheros ".wbb" que hay en el directorio src/ y se generan en el directorio html/ los ficheros "destinos.

En próximas entradas seguiremos detallando el uso de webber para la creación de páginas más complejas.

 

Categories: Sin categoría, sistemas Tags:

Ataques de amplificación de tráfico: NTP

viernes, 21 de febrero de 2014 Sin comentarios

 

 

Durante el año 2013 se ha generalizado el uso de protocolos distintos al tradicional DNS a la hora de realizar ataques de denegación de tráfico, el ultimo protocolo que se esta usando es Network Time Protocol (NTP), empleado para que los equipos estén sincronizados a nivel horario.

Ya se comentó anteriormente est tipo de ataques, que se basan en dos situaciones bastante frecuentes,  una normal y otra debida sobre todo a malas configuraciones.

Es habitual y normal que haya muchas peticiones de tráfico que no sean balanceadas (se reciba más información que la que se solicita),esto ocurre en la mayoria de las situaciones (ver un video por internet, acceder a una página WWW, etc), por lo general somos “consumidores” de información y recibimos más información de internet que la que enviamos hacia fuera.

Para la mayoría de los protocolos esta situación no genera problemas de amplificación de tráfico ya que emplean un protocolo orientado a conexión como es TCP, en el cual se establece una negociación entre los equipos antes de enviar información, pero hay otros protocolos como ICMP o UDP que no son orientados a conexión .

Aquí interviene después la segunda situación que es la posibilidad de que un equipo genere tráfico con una dirección IP que no le corresponde (falsificación de direcciones, Spoofing, etc), y que este tráfico llegue hasta Internet.

Como comentábamos el documento de buenas prácticas BCP 38 , http://tools.ietf.org/html/bcp38  comentaba hace casí 15 años la necesidad de que las organizaciones filtraran el tráfico en origen , de forma que este  trafico no deseado no llegue a internet. Este  filtrado fue evolucionando de las tradicionales listas de acceso en los routers a técnicas como el “Reverse Path Forwarding”, (RPF),  implementado en los routers de la mayoria de los fabricantes, como Cisco,  o Juniper  , así en la mayoría de los sistemas operativos   (Linux, *BSD*,etC) , cortafuegos (Fortinet, Paloalto, …).

Por lo general las instituciones conectadas a RedIRIS ya tienen aplicados estos filtros y además en el backbone se realizan comprobaciones adicionales pero se puede colaborar con proyectos como spoofer  para comprobar si una red es susceptible de ser utilizada en ataques DDOS.

Estos ataques de denegación de servicio seguirán existiendo mientras haya redes que permitan la falsificación de tráfico ,aunque en el caso de NTP es algo más complicado y peligroso por diversos factores :

  • NTP es usado por muchos sistemas a la hora de mantener una sincronización horaria, necesaria para diversos protocolos  de enrutamiento , verificación de tiempos de espera y de vida de una conexión, etc. Por eso es crítico en muchos entornos.
  • Muchos servidores de NTP, sobre todo los empleados en enrutadores y commutadores no tienen la posibilidad de filtrar las peticiones de consulta “privilegiadas” en la versión del sistema operativo que están corriendo, por lo que hay que aplicar filtros para impedir su uso desde el exterior.
  • En muchas organizaciones como hardware para correr el servicio de NTP se utilizan enrutadores que disponen de varias direcciones IP (por los distintos interfaces) por lo que es necesario aplicar los filtros en todos los interfaces del equipo .

En el caso de NTP el problema es debido a que los servidores que permiten los paquetes en modo 7  (administrativo) desde otros hosts pueden recibir consultas para obtener una lista de los ultimos 600 servidores/clientes que han obtenido tiempo del servidor en cuestión. Esto puede realizarse mediante el comando monlist de la ultilidad ntpdc.

De esta forma un paquete comando de unos pocos bytes obtiene una respuesta de varios miles de bytes que pueden llegar a saturar el servidor y la red.

Existen 3 soluciones recomendadas a nivel de equipo que es servidor de NTP:

  1.   Actualizar el servicio ntp a versiones posteriores a la 4.2.7p26.
  2.   Deshabilitar el monitor. En el fichero de configuración añadir una linea “disable monitor”
  3.  Añadir “noquery” en la lista de restricciones por defecto y despues permitirla a las maquinas que interese             que reciban esa informacion.
      restrict -4 default noquery
      restrict -6 default noquery

Estas dos lineas anteriores evitaran que se ignoren los paquetes en modo 6 y 7 tanto para IPv4 como IPv6.

Referencias:

Por otro lado es aconsejable que aplique a nivel de red los filtros apropiados para evitar que se acceda desde el exterior de la organización a los servidores NTP que no sean públicos para evitar su uso en los ataques de denegación de servicio

 

Categories: Sin categoría Tags: , ,

Spam académico

martes, 20 de agosto de 2013 Sin comentarios

 

Algunos piensan que con esto de la crisis económica todo vale y que ya que recibimos spam todos los días el buscar de forma masiva direcciones de correo y emplear los servidor de listas de las organizaciones para la difusión de convocatorias de congresos, revistas, cursos y demás formas de conseguir financiación adicional o prestigio, yo personalmente creo que hay que hace hincapié en los responsables de las listas de correo internas de cada organización para evitar este tipo de comportamientos.

 

No se ve todos  los días , pero como mínimo una vez al mes se recibe  información desde listas de correo sobre masters, cursos, congresos y demás organizados por departamentos o centros de instituciones afiliadas, donde sin haberlo pedido en ningún momento me han incorporado a una lista de distribución.

Mención aparte merecen algunas organizaciones afiliadas a RedIRIS con difusión internacional que añaden de forma masiva a los usuarios extranjeros que acceden a una de sus cursos/conferencias y charlas y de los que recibimos diariamente quejas de algunos ISP estadounidenses.

 

Aparte de la mala imagen para la organización, generación de spam a los destinatarios, etc,  están los problemas de listas negras.  por lo que un uso irresponsable de los recursos que proporciona la organización pueden provocar perjuicios a otros usuarios  en un momento determinado.

Por favor. recordarle a los administradores de las listas de correo las normas de buen uso , gran parte de vosotros las tiene ya publicadas y aprobadas , por ejemplo en :https://www.google.es/search?q=rediris.es+listas+de+correo+normas&rlz=1C5CHFA_enUS503ES505&oq=rediris.es+listas+de+correo+normas&aqs=chrome.0.69i57j69i62l2.6272j0&sourceid=chrome&ie=UTF-8

 

Y explicitamente en RedIRIS en http://www.rediris.es/mail/abuso/ace.es.html  (perdonar por los tipos mime sin actualizar 😉  se indica claramente que este tipo de contenido viola varios de los puntos que desde RedIRIS se consideran contenido abusivo.

 

un saludo a todos

Categories: Incidentes Tags:

Rendimiento de equipamiento de seguridad en IPv6

martes, 6 de agosto de 2013 Sin comentarios

 

 

En  una reunión paralela al IETF 87 en Berlin , de un grupo de “hackers” interesados en la seguridad informática hubo una comparativa entre el rendimiento de algunos dispositivos de seguridad en IPv4 e IPv6, bastante completa y con varios sistemas de pruebas que se están haciendo ya.

En http://www.insinuator.net/2013/08/ipv6-hackers-meeting-ietf-87-in-berlin-slides/ están las presentaciones que se hicieron con varias pruebas.

Hay que indicar que se trata por lo general de equipamiento para redes pequeñas y no de equipamiento de backbone pero es interesante a la hora de saber como se comportan estos fabricantes a nivel de IPv6.

 

 

Categories: Sin categoría Tags: ,