ESNOG

Grupo de Operadores de Red Españoles

GORE 21

TAGS: None

Ya sabemos donde y cuando tendrá lugar la próxima reunión, la 21ª.

Será en Barcelona, en las instalaciones del CSUC que ya nos han acogido con anterioridad, los días 9 y 10 de Abril de 2018.

¡Apuntadlo en la agenda! Nos vemos allí

 

GORE 20

TAGS: None

Hola a todos,

ya podemos confirmar que la próxima reunión de ESNOG, la vigésima!, tendrá lugar en Madrid, en el MediaLab Prado, los días 30 y 31 de Octubre de 2017.

Podeis inscribiros en la página del evento.

Nos vemos!

Monitorizar ataques en Cisco

TAGS: None

Recientemente la red de un conocido empezó a tener un tráfico totalmente atípico y sospechando un ataque de DOS (Denegación de servicio) me pidieron mi ayuda.

El método que use para determinar que máquina estaba comprometida es muy sencillo y la mayoría de los administradores de sistemas lo conocen, no obstante lo cuento aquí por si puede ser de utilidad para alguien.

En este caso son routers cisco, pero con adaptaciones puede funcionar con la mayoría de los demás fabricantes.

Nada mas conectarme hice un “show interfaces | i protocol|rate”, es una forma rapida de ver de forma resumida el trafico por cada interfaz:

GigabitEthernet0/0 is up, line protocol is up 
  Queueing strategy: fifo
  30 second input rate 1691000 bits/sec, 3405 packets/sec
  30 second output rate 57859000 bits/sec, 5920 packets/sec
     0 unknown protocol drops
GigabitEthernet0/1 is up, line protocol is up 
  Queueing strategy: fifo
  30 second input rate 55911000 bits/sec, 5723 packets/sec
  30 second output rate 1365000 bits/sec, 3382 packets/sec
     118 unknown protocol drops

Aquí está el pimer detalle interesante, Gi0/0 es la interfaz HACIA Internet y Gi0/1 HACIA la red interna de mi conocido.

Es decir la red interna estaba ENVIANDO tráfico a Internet.

Por tanto no era un ataque de DOS, sino un equipo aparentemente hackeado enviando tráfico a Internet.

El segundo problema, averiguar cual. lo primero que hice es ver cuantas maquinas habia activas en la red interna (a partir de aquí las IP se han modificado para proteger identidades):

router(config)#do sh arp                                      
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
...
Internet  192.0.2.33            -   c471.fe88.8888  ARPA   GigabitEthernet0/1
Internet  192.0.2.34            0   0044.8856.0022  ARPA   GigabitEthernet0/1
Internet  192.0.2.35            0   0044.8856.0063  ARPA   GigabitEthernet0/1
Internet  192.0.2.36            8   0044.8856.0063  ARPA   GigabitEthernet0/1
Internet  192.0.2.37            0   0044.8856.0020  ARPA   GigabitEthernet0/1
Internet  192.0.2.38            0   0044.8856.0069  ARPA   GigabitEthernet0/1
Internet  192.0.2.39            8   0044.8856.0063  ARPA   GigabitEthernet0/1
Internet  192.0.2.40            8   0044.8856.0063  ARPA   GigabitEthernet0/1
Internet  192.0.2.41            2   0044.8856.0026  ARPA   GigabitEthernet0/1
Internet  192.0.2.42            0   0044.8856.001d  ARPA   GigabitEthernet0/1
Internet  192.0.2.43            0   0044.8856.0013  ARPA   GigabitEthernet0/1
Internet  192.0.2.44            3   0044.8856.0027  ARPA   GigabitEthernet0/1
Internet  192.0.2.45            0   Incomplete      ARPA  
Internet  192.0.2.46            0   Incomplete      ARPA

A continuación construí un access-list con todas esas direcciones:

access-list 169 permit ip host 192.0.2.34 any
access-list 169 permit ip host 192.0.2.35 any
access-list 169 permit ip host 192.0.2.36 any
access-list 169 permit ip host 192.0.2.37 any
access-list 169 permit ip host 192.0.2.38 any
access-list 169 permit ip host 192.0.2.39 any
access-list 169 permit ip host 192.0.2.40 any
access-list 169 permit ip host 192.0.2.41 any
access-list 169 permit ip host 192.0.2.42 any
access-list 169 permit ip host 192.0.2.43 any
access-list 169 permit ip host 192.0.2.44 any
access-list 169 permit ip host 192.0.2.45 any
access-list 169 permit ip host 192.0.2.46 any
access-list 169 permit ip any any

Varios detalles sobre este access-list:

  • Es extendido (entre 100 y 199) para poder poner como condición la IP de origen del paquete (nos interesa saber que máquina interna está enviando los paquetes)
  • Cada IP que hemos identificado está en una línea y no nos importa el destino, por eso hemos puesto any.
  • Deja pasar  todo el trafico, pero vamos a aprovechar una particularidad de cisco. Cuando un paquete es aceptado (matcheado que dicen alguno) por la condición de una línea, se incrementa un contador. Mirando ese contador sabremos que maquina es la que envía más paquetes y por tanto es la culpable.

Ahora aplicamos el access-lis en entrada en la red interna:

inter gi0/1
ip access-group 169 in

Dejamos reposar unos minutos (como los quitamanchas) y…

router#sh ip access-lists 169
Extended IP access list 169
    10 permit ip host 192.0.2.34 any (307926 matches)
    20 permit ip host 192.0.2.35 any (50 matches)
    30 permit ip host 192.0.2.36 any (487 matches)
    40 permit ip host 192.0.2.37 any (189 matches)
    50 permit ip host 192.0.2.38 any (3539 matches)
    60 permit ip host 192.0.2.39 any (46 matches)
    70 permit ip host 192.0.2.40 any (290 matches)
    80 permit ip host 192.0.2.41 any (398 matches)
    90 permit ip host 192.0.2.42 any (5 matches)
    100 permit ip host 192.0.2.43 any (68 matches)
    110 permit ip host 192.0.2.44 any (5 matches)
    120 permit ip host 192.0.2.45 any
    130 permit ip host 192.0.2.46 any

Ya tenemos un ganador. La IP 192.0.2.34 es el culpable.

Resulta que era un servidor de correo que había sido hackeado y se estaba usando para envia spam.

Si resulta que en nuestra red interna hay demasiadas maquinas, no resulta práctico poner un access-list tan largo. Usemos la dicotomía, por ejemplo si tenemos una red /24, podemos hacer:

access-list 169 permit ip 192.0.2.0 0.0.0.63 any
access-list 169 permit ip 192.0.2.64  0.0.0.63 any
access-list 169 permit ip 192.0.2.128 0.0.0.63 any
access-list 169 permit ip 192.0.2.192 0.0.0.63 any

Descubrimos cual de las cuatro subredes es la que tiene el trafíco (supongamos que la segunda) y la subdividimos a su vez:

no access-list 169
access-list 169 permit ip 192.0.2.64 0.0.0.15 any
access-list 169 permit ip 192.0.2.80  0.0.0.15 any
access-list 169 permit ip 192.0.2.96 0.0.0.15 any
access-list 169 permit ip 192.0.2.112 0.0.0.15 any

Con este resultado ya sabremo en que grupo de 16 direcciones esta la culpable y podemos hacer una lista de 16 hosts para descubrir cual es.

Por otra parte, si fuera al reves, es decir un ataque desde Internet a tu máquina, bastaría con cambiar el orden en el access-list, poner el any delante, y el access-list configurarlo como out en lugar de in en la interfaz.

Espero que este sencillo hack le sea de utilidad a alguine.

GORE/ESNOG Reunion 19 – CSUC/CATNIX, Barcelona

Tags: , ,

Los días 6 y 7 de Abril volveremos a reunirnos en Barcelona, en las instalaciones del CSUC/CATNIX, al que de nuevo agradecemos su acogida.

En breve publicaremos el formulario de inscripción (a través de este mismo canal), información de logística y también la agenda provisional.

Actualización (6 de Marzo): Ya está abierta la inscripción para GORE 19. Si quieres asistir inscríbete. (Aforo completo)

Actualización (3 de Abril): Acabamos de publicar la agenda para la reunión de finales de esta semana. ¡Nos vemos pronto!

GORE 18 – Volvemos al Medialab Prado

TAGS: None

EL 20 y 21 de Octubre estamos de vuelta en el Mediaba Prado, un escenario estupendo para una nueva edición de ESNOG.

La página con más información sobre la logística, incluida la inscripción, ya está disponible aquí. Iremos completando detalles en los próximos días.

Recordaros que la semana siguiente al GORE 18 se desarrollará en Madrid la reunión de RIPE, RIPE 73, de la que ESNOG es co-anfitrión.

 

Abierta la inscripción para el GORE 17

TAGS: None

¡Ya está abierta la inscripción para el GORE 17!

Repetimos en Barcelona, en las instalaciones del CSUC/CATNIX, que siempre nos brinda una fantástica acogida.

La página de inscripción con la agenda, que seguirá evolucionando los próximos días, está ya accesible.

Nos vemos los días 12 y 13 de Mayo de 2016.

Actualización a 28 de Abril: Ya hemos publicado la agenda. ¡Esta reunión va a estar muy, muy bien!

Resultados encuesta ESNOG16

Tags: ,

Os presentamos los resultados de la encuesta que hicimos sobre el propio evento, y que 26 de vosotros contestasteis.

En general, ¿qué tan satisfecho está con el contenido?
Extremadamente satisfecho 68.45%
Muy satisfecho 23.21%
Moderadamente satisfecho 8.34%
Poco satisfecho 0.00%
Nada satisfecho 0.00%
En general, ¿qué tan adecuada le parece la duración de las presentaciones realizadas en la reunión?
Extremadamente satisfecho 44.50%
Muy satisfecho 51.34%
Moderadamente satisfecho 4.16%
Poco satisfecho 0.00%
Nada satisfecho 0.00%
La presentación y el contenido de la documentación entregada han sido adecuados.
Extremadamente satisfecho 46.15%
Muy satisfecho 50.00%
Moderadamente satisfecho 3.85%
Poco satisfecho 0.00%
Nada satisfecho 0.00%
En general, la combinación de aspectos teóricos y prácticos ha sido adecuada.
Extremadamente satisfecho 44.00%
Muy satisfecho 48.00%
Moderadamente satisfecho 4.00%
Poco satisfecho 4.00%
Nada satisfecho 0.00%
El entorno donde se ha llevado a cabo la presentación reunía las condiciones necesarias.
Extremadamente satisfecho 61.54%
Muy satisfecho 30.77%
Moderadamente satisfecho 7.69%
Poco satisfecho 0.00%
Nada satisfecho 0.00%
La exposición de los ponentes (habilidad de mantener la atención, capacidad de responder a las cuestiones, amabilidad…) me ha parecido adecuada.
Extremadamente satisfecho 53.85%
Muy satisfecho 42.31%
Moderadamente satisfecho 3.85%
Poco satisfecho 0.00%
Nada satisfecho 0.00%
Por favor, haz una valoración global de la reunión.
Extremadamente satisfecho 61.54%
Muy satisfecho 30.77%
Moderadamente satisfecho 7.69%
Poco satisfecho 0.00%
Nada satisfecho 0.00%
Por favor, haz una valoración global de la retransmisión del evento online.
Extremadamente satisfecho 0.00%
Muy satisfecho 42.86%
Moderadamente satisfecho 0.00%
Poco satisfecho 0.00%
Nada satisfecho 14.29%

 

GORE 17

TAGS: None

Tenemos ya fecha y lugar para el GORE 17. Será en Barcelona, en las instalaciones del CSUC, los días 12 y 13 de Mayo de 2016, este último hasta la hora de comer. Durante las semanas iremos proporcionando más detalles. Esperamos veros a todos allí.

Resumen de las charlas del GORE-16

TAGS: None

Resumen de las charlas que se dieron en el GORE-16 (en la página del GORE-16 tenéis acceso a la mayoría de las presentaciones correspondientes)

·         Visibilidad del tráfico de red (Talaia Networks)
Se trataba de enseñar una herramienta desarrollada por Talaia Networks, antiguos miembros de la UPC, llamada Polygraph.io. Un sistema de analisis y supervisión de red basado en Netflow.
Es bastante interesante y entre otras cosas da información de las aplicaciones usadas, AS de entrada y salida de tráfico, tráfico por interfaz, detección de anomalias de tráfico, etc.
El modelo de negocio estándar es SaaS (Software as a Service). Es decir la información de Netflow se envía a los servidores de Talaia para su análisis y el cliente examina esta información a través de los servidores de Talaia. No obstante también tienen la opción de desplegar toda la estructura en casa del cliente.
Puede ser interesante para las necesidades de análisis de la red que tiene BEN.

·         Novedades en K-root, RIS y RIPE Atlas (RIPE)
Se mostraron varios de los servicios que proporciona RIPE. El primero fue RIPE Atlas una red distribuida de cerca de 10.000 sondas por todo el mundo que permite hacer pruebas de latencia, pérdida de paquetes, cortes en la red, etc. Los usuarios de las sondas (empresas o particulares) las instalan y mantienen de forma gratuita en sus redes (son muy pequeñas y con un consumo de red muy reducido) y a cambio pueden hacer una cierta cantidad de medidas cada mes.
RIPE mantiene uno de los 13 servidores raiz que hay en el mundo que en realidad son múltiples servidores físicos distribuidos por todo el mundo con funcionamiento anycast para dar mayor fiabilidad. Explicaron la distribución, tipos de servidores (con alcance global o local) y si alguna compañía quería instalar una instancia del servidor en su red, los requisitos que pide.
Por ultimo hablaron de RIS (Route Information Service), una red de servidores distribuida, principalmente en puntos neutros, que hablan BGP con las otras redes -no anuncian redes, sólo reciben los anuncios del resto-, procesan la información y generan información sobre estabilidad de prefijos, distancia en AS, etc. Comentaron también planes futuros (están cambiando el hardware usado para las mediciones) y los requisitos para albergar una de las sondas del proyecto.
DSC05219
·         El estado optimo de las lentes en los transceptores ópticos: como reducir el coste de operación y mantenimiento y el número de dolores de cabeza (Alturna Networks)
Mini curso (con un pequeño taller práctico) sobre fibras ópticas, incluyendo tipos, conectores, etc. Y los problemas típicos como suciedad, rayaduras y como corregirlos con limpiadores y otros elementos.
También presentaron el Multi Fiber Tool, una herramienta para medir transceptores SFP y SFP+, detección de problemas en fibras a través del mismo SFP e incluso con los SFP de SolidOptics (la empresa que hace el aparato) que son “marca blanca”, reprogramarlos para que valgan para varios fabricantes. De esta forma se puede tener un solo recambio y reprogramarlo para Cisco, Juniper, Alcatel, etc. Según haga falta.
DSC05236
·         Un balanceador para mil millones de usuarios (Facebook)
Explicaron la estructura de los servidores de Facebook, que actualmente funcionan SOLO en IPv6. Delante de los servidores de datos (distribuidos por varios CPD en el mundo) hay un balanceador llamado Proxygen que mantiene estados de sesiones y delante de este otro balanceador llamado shiv que es stateless. Detallaron el funcionamiento, los problemas que se encuentran, incluyendo retardos, y como los resuelven. También habló de Cartographer, una herramienta que emplean para distribuir el tráfico entre servidores cuando se saturan.
Por ultimo habló del Wedge y del Spine, dos switches que han desarrollado para sus CPD y que utilizan FBOSS (FaceBook Operating System).

·         Trabajando con Flowspec para parar ataques de DDOS (Arbor Networks)
Flowspec es un sistema parecido a SDN en el area de que permite inyectar rutas y controlar flujos en routers. El inconvenientes es que las implementaciones que hay (Cisco, Juniper, Alcatel, Huawei) so nmuy recientes e incompatibles de un fabricante a otro. Arbor Networks está usando Flowspec para detección y prevención de ataques, analizando patrones de tráfico y redirigiendo el tráfico maligno a agujeros negros.
DSC05240
·         Inteligencia Operacional: Splunk, ELK, Logtrust (Open3S)
Hicieron una presentación de las diversas herramientas de  gestión de logs que hay en el mercado, tanto open source como comerciales y se centraron en Splunk (comercial) y como la usaban como base para desarrollar un entorno de analísis de la red que permite de forma sencilla conocer el estado de red y detectar rápidamente cualquier problema.

·         Colaboracion con los ISPs en las operaciones internacionales de Cibercrimen (Europol)
Explicaron como actua la unidad de crimen digital de la Europol, como colaboran con los ISP, herramientas que usan, etc. A petición del presentador no se pudo grabar ni distribuir la presentación.

·         Lista blanca de reputación SMTP (RedIRIS)
Se presentaron dos listas que lleva el foro Abuses (patrocinado por RedIRIS) para validar la reputación de los servidores de correo. La primera formada sólo por la información proporcionada por los miembros de abuses de sus propios servidores y otra más amplia que añade información de otras fuentes. Estas listas pueden usarse para validar la fiabilidad de los servidores de correo y evitar, en cierta medida, la llegada de spam.

·         Código de buenas prácticas en Ciberseguridad (INCIBE, Telefonica)
Cuando se desmantela una red de bots, normalmente la policia no detiene el servidor, sino que lo deja levantado pero sin sus funciones “malignas” esto permite recolectar las IPs de todos los PCs que se conectan (que están infectados). La lista de estas IPs se transfiere al ISP específico para que avise al usuario. En el caso de Telefonica explicaron que se enviaba un correo al usuario, indico como intentaban detectar al usuario real en caso de IP dinámicas, avisándole de que tenía un virus y le daban un enlace a una página con todos los antivirus y desinfectadores gratuitos necesarios.  También explicó que hacían seguimiento para verificar si la máquina se había desinfectado.

·         CDN metrics (google)
Explicó como hacían las medidas de respuesta de sus servidores en Internet y dio algunos hints sobre lo que los usuarios debían y no debían hacer para medir si su conexión a Internet funcionaba (hint: ping a 8.8.8.8 no es la mejor forma).
También indicó como debían hacer los anuncios los ISPs que hacían peering con Google para evitar que el tráfico fuera por los enlaces de tránsito, mas caros.
DSC05256
·         Dr NMS or: How Facebook Learned to Stop Worrying and Love the Network (Facebook)
Interesante charla sobre como Facebook monitoriza toda su red con una sola persona. Todos los servidores de logs que tienen montados, como filtran la información y como tienen autómatas que intentan corregir los problemas de forma que que una minima parte, menos de un 1 por ciento, neceistan intervención humana.
La parte final de la conferencia fueron las ocho lecciones aprendidas durante el desarrollo de todas las herramientas que usan.

·         Hacking BGP (BICS)
Conjunto de ideas, trucos y herramientas para gestionar los enlaces eBGP en una empresa o ISP pequeño, ajustar, en la medida de lo posible, el uso de ancho de banda y herramientas para monitorizar el AS.

·         Anti phishing WG (APWG)
Explicó el funcionamiento del anti phishing working group y las herramientas que utilizan para evitar el phishing, incluyendo la desactivación de dominios de phishing, clausura de registradores dedicados a este tipo de dominios, etc. Fue una charla de presentación del grupo con poco contenido técnico y más generalista.

IPv6 un poco más cerca

TAGS: None

Esta semama se está desarrollando la WWDC de Apple en San Francisco.
Una presentación que ya es tradición es la del “Estado de la Plataforma”. En esta ocasión ha habido un anuncio con especial relevancia para el despliegue de IPv6.
Como podeis ver en el video de la presentación, con iOS 9 Apple hará que el correcto soporte de IPv6 en las Apps sea un criterio de aceptación para que la App sea aceptada en el App Store.
El video es largo, si quereis ir al grano, dadle al Fast Forward hasta los 35:05 minutos.

© 2009, 2010, 2011 ESNOG. All Rights Reserved.

Tu dirección IP:
54.227.51.103

This blog is powered by Wordpress and Magatheme by Bryan Helmig.