BGP Stream: un año de análisis sobre incidentes BGP

04/03/2024

Por Alejandro Acosta, Coordinador de I+D en LACNIC

LACNIC presenta la primera página on line que muestra los incidentes y el análisis de datos de medición del Border Gateway Protocol (BGP) en América Latina y el Caribe.

PRINCIPALES SUCESOS. Además de sumarizar la información se aprecian los tres principales sucesos, los cuales son: posibles secuestros de red, interrupciones BGP y fugas de rutas.

Posibles secuestros de red es la adquisición ilegítima de grupos de direcciones IP al corromper las tablas de enrutamiento de Internet. Tradicionalmente ocurre cuando el Sistema Autónomo anuncia un prefijo que no le pertenece.

Interrupciones (outages) se refiere a la pérdida de visibilidad de prefijos de red por un grupo mayoritario de sensores[1] .

Fugas de rutas como su nombre lo indica, se refiere al anuncio -posiblemente- no intencional de algún prefijo de red vía BGP. Por ejemplo, un peering privado de intercambio de tráfico, alguno de los participantes anuncia el prefijo del peer a Internet. Este caso es el más difícil de detectar por los algoritmos y no consigue identificar algunas de éstas incidencias.

¿Cómo se obtienen los datos?

Esta iniciativa utiliza BGP Stream de Cisco, un proceso automatizado que selecciona los incidentes más grandes e importantes, qué tipo de situación es y cuáles ASNs están involucrados.

Leer también:

Un necesario RFC sobre BGP: AS Path Prepending

La información se publica de forma abierta ya que LACNIC considera que se trata de información importante para que ingenieros, responsables de redes y organizaciones puedan conocer los incidentes más comunes de la región y crear conciencia sobre la situación.

Ello permite la investigación eficiente de eventos, creación rápida de prototipos y de herramientas complejas y aplicaciones de monitoreo a gran escala (por ejemplo, detección de interrupciones de conectividad, ataques o secuestros de BGP).

En base a un sistema desarrollado por el área de I+D de LACNIC, se obtienen los datos de forma cruda, los parcela, identifica, limpia y almacena en una base de datos para posteriormente generar estadísticas y gráficas. Lo anterior ocurre cada 24 horas de forma automatizada.

RESULTADOS. Durante el período de tiempo estudiado -febrero 2023 a febrero 2024- nos encontramos con los siguientes resultados que se muestran en la siguiente gráfica comparando eventos BGP mundiales vs eventos BGP de nuestra región.

Comparando la gráfica mundial versus la gráfica de la región vemos que el orden de incidentes es similar (el mayor es outages, seguido por posibles secuestros de red y finalizando en fugas de prefijos).  Adicionalmente hay que destacar que en nuestra región las interrupciones (outages) son más frecuentes en comparación con el total mundial de eventos BGP. 

Al analizar la tabla resultados mostrando eventos BGP Mundiales vs eventos BGP de nuestra región, nos encontramos con los siguientes fatos.

TOP 5 países de nuestra región con Interrupciones BGP (Outages)

Outages
CC	Events
BR	781
AR	99
HT	24
MX	22
CL	17

TOP 5 países de nuestra región con secuestros de prefijos (Possible Hijacks)

Expected CC	Detected CC	Events
BR	BR	67
BR	none	35
PY	BR	24
BR	US	22
BR	CN	9

TOP 3 países de nuestra región con fugas de rutas (Route Leaks)

Origin CC	Leaker CC	Events
VE	VE	7
MX	MX	5
CL	PA	2

El impacto

En este primer año de funcionamiento desde LACNIC hemos observado una disminución de los incidentes BGP, entre los motivos de estos resultados podemos identificar: a) el despliegue y la adopción de Sistema de Certificación de Recursos (RPKI), b) el Registro de Enrutamiento de Internet de LACNIC (IRR) y la adopción del RFC 9234 (Roles en BGP).

La adopción de dichas herramientas se está dando por mejores prácticas de los operadores y el impulso de MANRS por ISOC.

Conclusiones

Los posibles secuestros de red (BGP Hijacks), interrupciones BGP (Outages) y fugas de rutas son los incidentes BGP más comunes. Durante el primer año de recopilación de datos, se observa una disminución de estos casos; sin embargo, en el futuro cercano no desaparecerán por completo. Es crucial implementar medidas robustas de redundancia y resiliencia en las redes, así como detectar y prevenir tempranamente posibles secuestros para garantizar la integridad y confiabilidad de las rutas de Internet.

En LACNIC, buscamos crear conciencia y motivar a los ISPs y organizaciones a estar preparados para abordar estos incidentes de manera eficiente cuando ocurran.

Referencias

https://stats.labs.lacnic.net/BGP/bgpstream-lac-region.html

https://stats.labs.lacnic.net/BGP/bgpstream.html

https://bgpstream.crosswork.cisco.com/ 

Solución: libnsock mksock_bind_addr(): Bind to 2001:db8:1::1:0 failed (IOD #1): Cannot assign requested address (99)

Problema:

  Al usar nping (que viene con nmap) recibimos un error similar a:

libnsock mksock_bind_addr(): Bind to 2001:db8:1::1:0 failed (IOD #1): Cannot assign requested address (99)

Situación:

  La situación es que nping no consigue como utilizar la dirección IPv6 fuente 2001:db8:1::1

Solución:

  Pueden haber muchas soluciones. La que yo utilicé fue crear una interfaz tipo tunnel -una interfaz lógica- con la dirección IPv6 deseada. Te dejo los comandos:

ip tuntap add mode tun dev tun1

ip -6 addr add 2001:db8:1::1 dev tun1

ifconfig tun1 up

Finalmente podrías ejecutar algo similar a esto:

nping -6 -S 2001:db8:1::1 --tcp-connect -c 2 -p 53 <ipv6_dest> --source-mac 00:50:XX:XX:XX:35  --dest-mac 2c:XX:XX:XX:44:20

Espero haya sido útil.

Por fin, RRL en BIND por defecto - con ejemplo

Historia

Al parecer este es un post que tuve que haber hecho hace mucho, sin embargo hoy recién es que lo veo funcionando correctamente


Introducción

Si el lector se parece un poco a mí, quizás sea de esas personas que tiene MUCHOS años esperando el soporte de Response Rate Limiting en Bind9. Buenas noticias!, ya existe !.


¿Qué es RRL en DNS?

RRL se refiere a Response Rate Limit. De una manera resumida es una técnica para minimizar ataques de amplificación que son muy comunes en el mundo de DNS. Hoy en día es muy recomendado en servidores autoritativos pero puede servir en recursivos.


Situación


Deseo instalar Bind9 vía apt (apt-get) y tener soporte de RRL (Response Rate Limiting). Algo que me extraña es que en teoría debería tener soporte por defecto luego del 9.10, sin embargo verán que este ejemplo está en 9.9.5)


Pasos:


El día de hoy, con Ubuntu 14.04 (si, bastante viejo) hice un upgrade de Bind9, probé RRL y todo anduvo perfecto. 

1) Actualizar bind9
   apt-get –only-upgrade install bind9

2) Chequeo la versión:
   root@my:~/SCRIPTS# apt-cache policy bind9
      bind9:
      Installed: 1:9.9.5.dfsg-3ubuntu0.19

3) Configurar RRL en bind9. Un sencillo ejemplo:


   rate-limit {
      responses-per-second 1;
   };


(favor notar que puse "1".., solo para probar que el feature realmente sirva)

4) Reiniciar bind vía rndc o el servicio (service bin9 restart)


   #service bind9 restart

Comprobar

Debido a que dejamos una sola consulta por segundo, es tan sencillo como ir a otro equipo, tener varios terminales abiertos y hacer muchos dig simultáneamente de algún dominio/zona autorizada. Si todo sale bien, en el log verás algo como:


Jul 4 11:47:55 my named[8317]: limit responses to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)


Jul 4 11:47:55 my named[8317]: client 10.112.225.51#11257 (exp.example.com): rate limit slip response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)


Jul 4 11:47:56 my named[8317]: client 10.112.225.51#7921 (exp.example.com): rate limit drop response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)

Mas info:
https://kb.isc.org/docs/aa-00994
https://whatis.techtarget.com/definition/DNS-amplification-attack

Aportando un grano de arena en la seguridad de la red, un caso de éxito

Introducción

Seguramente algunos de ustedes conocen el proyecto IPv6 DNS Open Resolvers [1] que lleva adelante LACNIC, un trabajo conjunto de WARP [2] y de I+D donde identificamos servidores abiertos DNS con direccionamiento IPv6.
Tradicionalmente no ofrecemos soporte de ningún tipo para la infraestructura de nuestros asociados, esto quiere decir que LACNIC “no toca” los equipos (servidores, dispositivos de red). Sin embargo siempre hemos extendido una mano de apoyo para colaborar en todo lo que podamos.

Contexto

Luego de haber identificado una dirección IPv6 donde se encuentra una servidor DNS recursivo abierto, envíamos un correo automatizado a la organización dueña de la dirección IP alertando la situación. En él explicamos las posibles consecuencias y recomendamos una serie de configuraciones para los servidores más usados. Dicho correo tiene un formato similar a:

===
DATE DD-MM-AAAA


Dear ORG-ID NAME. (OR-ID-LACNIC):

You appear to be running a DNS - open recursive resolver at IP address 280X:XXXX:X:XXXX:XXXX:XXXX:XXXX:XXXX.

It may have undesirable consequences on the Internet because it may participate in an attack against a selected target, causing a Denial of Service (DOS) attack. It generates large UDP responses to spoofed queries, with those responses becoming fragmented because of their size.

We strongly recommend to reconfiguring your resolver. Here are some ways that may help you:


- To only serve your customers and not respond to outside IP addresses (in BIND, this is done by defining a limited set of hosts in "allow-query";)

options {

 allow-query {
  192.168.196.0/24;
  2001:db8::/32;
  localhost;
 } // end of allow-query
} // end of options


- To only serve domains that it is authoritative for (in BIND, this is done by defining a limited set of hosts in "allow-query" for the server overall but setting "allow-query" to "any" for each zone)

zone "example.com"{
 type master;
 file "example.com.db";
 allow-query {
  192.168.196.0/24;
  2001:db8::/32;
  localhost;
 } // end of allow-query
} // end of zone example.com


In unbound you can achieve the same behavior with the access-control statement in the unbound.conf file. Would be something like:

server:
 access-control: 2001:db8::/32 allow


If you are an ISP, please also look at your network configuration and make sure that you do not allow spoofed traffic (that pretends to be from external IP addresses) to leave the network. Hosts that allow spoofed traffic make possible this type of attack.

References:
More information on this type of attack and what each party can do to mitigate it can be found here: http://www.us-cert.gov/ncas/alerts/TA13-088A


Best regards,

LACNIC's WARP Team

=======

Caso de éxito

Queremos presentarles este caso de éxito que comenzó cuando una organización recibió el correo indicado anteriormente y se contactó con WARP buscando recibir apoyo para aplicar las recomendaciones de seguridad en sus equipos. Por ser un proyecto nuevo no nos había ocurrido esta situación anteriormente pero analizamos el caso decidimos proseguir por dos razones:
⋅⋅1. La persona que nos contactó se mostró realmente interesada
⋅⋅2. El OS y el servidor DNS se encontraba en el grupo de los cuales tenemos experiencia

Comenzamos por identificar dónde estaban los archivos de configuración del servidor y los ACLs que él mismo utilizaba. Luego le guiamos para implementar en la configuración existente, las recomendaciones de seguridad genéricas que enviamos en el correo inicial.

La buena noticia fue que el miembro de LACNIC, siempre se mostró muy dado a recibir nuestra ayuda y la comunicación fue muy fluida en todo momento. Al cabo de menos de dos semanas, con aproximadamente 8 correos intercambiados, el servidor que era una potencial amenaza se encontraba configurado de tal manera que solo permitía consultas DNS desde sus propios prefijos.
Pero esto no fue todo, la alerta que enviamos y por la cual fuimos contactados, refería solo a uno de los servidores administrados por esta organización. Para completar nuestra tarea, nuestro miembro identificó que otro servidor de su red se encontraba en las mismas condiciones que el anterior, por lo que también colaboramos en la aplicación de las correcciones necesarias.

El caso lo consideramos muy exitoso por ser servidores que tienen direcciones IPv6 estáticas las cuales eventualmente podrían ser descubiertas por algunos atacantes y traer consigo eventuales tareas maliciosas sobre la red.

Lo anterior no quiere decir que sea el único caso de éxito ocurrido, muy posiblemente otros operadores han tomado acciones sobre sus servidores sin conocimiento alguno de LACNIC. Prontamente estaremos trabajando en identificar estos casos y publicaremos algunos resultados.

Referencias

[1] (https://labs.lacnic.net/Identificando-servidores-DNS-IPv6-Open-Resolvers/)
[2] (https://warp.lacnic.net/)

Por:

Darío Gómez

Security Analyst at LACNIC WARP

@daro_ua

y

Alejandro Acosta

@ITandNetworking

Demostración: Antispoofing IPv6 en un router Cisco IOS

El siguiente video muestra como simular un ataque spoof en Internet y como prevenir el mismo en Cisco IOS

 

Script in Python3 que chequea fecha de vencimiento de certificados SSL y envia correos

Intro:
  Abajo les dejo un script realizado en Python3 que chequea fecha de vencimiento de certificados SSL (https) y realiza el envio de correos.

Importante:
  Que corra en OS modernos (Ubuntu 16.04 o mayor por ejemplo).., la razón es el soporte de librerías actualizadas SSL

El Script:
$ more check_ssl_certificates.py 

#!/usr/bin/python3

#El objetivo de este script es revisar los hostnames en la lista hostnames

#revisar cuantos dias faltan para que expire el certificado SSL

#y se expira pronto (definido por la variable umbral) enviar un correo

#con dicha notificacion




import OpenSSL

import ssl, socket

import argparse

from OpenSSL import SSL

from datetime import datetime




# Please add every FQDN you wish to be checked

hostnames = ["www.sitio1.com","www.sitio2.com","www.sitio3.com"]

umbral = 10 #threshold - number of days left in order to send the notification

notify_to= "you@yourserver.com, youyou@yourserver.com" #list of email addresses to send email separated by ,




def cert_expiration_date(hostname):

# get SSL Cert info

try:

cert = ssl.get_server_certificate((hostname, 443))

x509 = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, cert)

x509info = x509.get_notAfter()




exp_day = x509info[6:8].decode('utf-8')

exp_month = x509info[4:6].decode('utf-8')

exp_year = x509info[:4].decode('utf-8')




exp_date = str(exp_day) + ' ' + str(exp_month) + ' ' + str(exp_year)

expire_date = datetime.strptime(exp_date, "%d %m %Y")







except Exception:

MSG='el host ' + str(hostname) + ' no pudo ser chequeado '

sendnotification(hostname, 0, MSG)

return #will enter here if could not connect to the website port 443




#print('SSL Certificate for hostname', hostname, 'will be expired on (DD-MM-YYYY)', exp_date)

#print('SSL Certificate for hostname', hostname, 'will be expired on (DD-MM-YYYY)', expire_date)



expire_in = expire_date - datetime.now()

expire_in = str(expire_in).split(' ')[0]




if int(expire_in) < umbral :

MSG='el cert ssl de ' + str(hostname) + ' expira en ' + str(expire_in) + ' dias'

sendnotification(hostname, str(expire_in), MSG)




#print ('Expira en: ', expire_in)




def sendnotification(hostname, expire_in, MSG):

from smtplib import SMTP_SSL as SMTP

import logging

import logging.handlers

import sys

from email.mime.text import MIMEText




#MSG = 'el cert ssl de ' + str(hostname) + ' expira en ' + str(expire_in) + ' dias'

#text = MSG

msg = MIMEText(MSG, 'plain')

msg['Subject'] = MSG

me = 'your@email.com'




recipients = notify_to

msg['To'] = notify_to

try:

conn = SMTP('yourmailserver.com')

conn.set_debuglevel(True)

conn.login('authusr', 'yourpassword')

try:

conn.sendmail(me,recipients.split(',') , msg.as_string())

finally:

conn.close()

except Exception as exc:

logger.error("ERROR!!!")

logger.critical(exc)

sys.exit("Mail failed: {}".format(exc))






if __name__ == "__main__":

for hostname in hostnames:

cert_expiration_date(hostname)

Propuesta de una fuente confiable de enrutamiento para la región de LAC

Introducción

Recientemente fue publicado un artículo por Job Snijders llamado: “A New Source For Authoritative Routing Data”, su traducción viene a ser algo como: “Una nueva fuente de información de enrutamiento autoritativa”. (Snijders 2017)

El documento trata sobre un trabajo donde explica como varios expertos y en contribución con varias instituciones construyeron una manera de proveer a la comunidad información confiable sobre enrutamiento. Para ir entrando en detalles técnicos podemos verlo como algo entre un IRR (“Internet Routing Registry - Wikipedia” n.d.) y RPKI (“Resource Public Key Infrastructure - Wikipedia” n.d.)

En este documento se describe una propuesta de LACNIC a la comunidad, con el fin de proveer una fuente de información autoritativa confiable sobre enrutamiento que pueda utilizarse por parte de los operadores de Internet de la región.

Un poco de historia

En el post de Job Snijder se explica cómo se tomó como fuente de información confiable la base de datos de Whois de ARIN y especificamente un campo llamado Origin el cual especifica cual AS (Sistema Autónomo) es quien anunciará determinado prefijo.

Posteriormente lo que se hace con esa información es construir un archivo JSON (“JSON - Wikipedia, La Enciclopedia Libre” n.d.) el cual puede ser utilizado fácilmente por programadores y diferente software de forma muy similar a lo que hace un IRR actualmente.

¿Qué hicimos en Lacnic?

Luego de analizar el post anterior y nuestras opciones, concluimos que el campo OriginAS prácticamente no es utilizado en el WHOIS de LACNIC, por lo que no estaríamos en condiciones de extraer esa información a partir de esa fuente. Sin embargo, dado el gran porcentaje de ROAs creados en varios países de la región (“Statistics — RIPE Network Coordination Centre” n.d.), creemos conveniente utilizar RPKI como fuente de información.

¿Cómo se tomó la información de RPKI?

Para utilizar la informacion de RPKI de LACNIC trabajamos con el validador RPKI de RIPE (“Tools and Resources” n.d.), con la diferencia que removimos todos los TAL (Trust Anchor Locator) exceptuando el de LACNIC. De esta manera el validador unicamente estaría procesando los ROAs correspondientes a nuestra región. Finalmente lo que hicimos fue exportar los ROAs en formato JSON, una funcionalidad que ofrece el propio validador.

Proceso de la información de RPKI

Finalmente, utilizando un script en python3 y en base al JSON exportado del Validador de RIPE construimos un nuevo archivo de JSON, (“Tools and Resources” n.d., “Website” n.d.) con una similitud sintáctica de 95% al del proyecto previo (“Website” n.d.)(Job Snijders y compañía). En este sentido, la manera como se crea la fecha, las posiciones relativas en el archivo, los nombres de las llaves son identicos, de esta manera facilitamos la interoperatividad con scripts y software ya existente.

Adicionalmente, esta misma información se publica en format RPSL(“Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre” n.d.), un formato que es más habitual para los operadores. De esta forma, se puede elegir entre ambos formatos para procesar o utilizar la información autoritativa.

Avances actuales

En base a todo lo mencionado anteriormente actualmente:

• Se publica diariamente un dump de todos los ROAs en formato JSON
• Se publica en RPSL la información correspondiente al AS de Origen y el prefijo (tanto v4 como v6) Lo anterior viene acompañado de un un hash de comprobación bajo SHA384 URL http://stats.labs.lacnic.net/RPKI/RPKItoJSON/

Espacio para mejoras

Sabemos que existen muchas cosas para mejorar, por el momento debemos mencionar:

1. Publicar los archivos en un server con soporte de https

Conclusiones

Dentro de Lacnic este proyecto aun se encuentra en una etapa Alfa, a lo sumo Beta. Dependeremos 100% de los comentarios recibidos de la comunidad si deseamos llevar esta idea a un ambiente con carácter de producción. Por ello no dude en comunicarse con nosotros, somos muy buenos recibiendo quejas, comentarios y felicitaciones.

Consideraciones adicionales

En los ROAs es posible especificar una longitud máxima y mínima de prefijos a publicar, sin embargo esto no tendría una forma similar de replicarlo en el archivo de salida. Una posibilidad en IPv4 sería generar los prefijos intermedios con el mismo sistema autónomo de origen, pero en IPv6 esto no sería posible por la cantidad de direcciones involucradas. Otra posibilidad es no utilizar las longitudes mínima y máxima en los ROAs, ya que esa es la situación análoga a los IRRs. El formato JSON de salida es fácilmente convertible a RPSL, con lo cual se pueden utilizar las mismas herramientas que se utilizan para procesar la información de un IRR. Un punto a analizar es si resulta necesario poder contar con otros objetos que no están incluidos en esta base de datos auto-generada.

Por:

• Alejandro Acosta alejandro \at lacnic dot net
• Guillermo Cicileo guillermo \at lacnic dot net

https://twitter.com/lacniclabs

Referencias

1. “Internet Routing Registry - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Internet_Routing_Registry.
2. “JSON - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/JSON.
3. “Resource Public Key Infrastructure - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure.
4. “Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/Routing_Policy_Specification_Language.
5. Snijders, Job. 2017. “A New Source For Authoritative Routing Data: ARIN WHOIS.” Medium. Medium. December 19, 2017. https://medium.com/@jobsnijders/a-new-source-for-authoritative-routing-data-arin-whois-5ea6e1f774ed.
6. “Statistics — RIPE Network Coordination Centre.” n.d. Accessed January 19, 2018. https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html.
7. “Tools and Resources.” n.d. RIPE Network Coordination Centre. Accessed January 19, 2018. https://www.ripe.net/manage-ips-and-asns/resource-management/certification/tools-and-resources.
8. “Website.” n.d. Accessed January 19, 2018a. http://stats.labs.lacnic.net/RPKI/RPKItoJSON/.