Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64

Parece loco, pero no lo es: Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64 

Como deshabilitar IPv4 temporalmente en una interfaz dentro de Linux

Caso:

  Deseamos deshabilitar IPv4 en una interfaz

Solución:

  sudo ip -4 addr flush dev enp0s1

Explicación:

  El comando anterior elimina todas las direcciones IPv4 para la interfaz enp0s1. Importante, recuerda que esta deshabilitación es solo temporal.

NGINX Reverse Proxy y Granja de Servidores IPv6 Only

 Introducción

En el presente trabajo presentaremos una manera muy sencilla de ofrecer acceso Web Dual Stack a una granja de servidores IPv6 Only utilizando NGINX. Con el crecimiento continuo de la red y la adopción gradual del protocolo IPv6, es esencial garantizar la conectividad y accesibilidad para aquellos clientes que utilizan tanto IPv4 como IPv6.

Explicaremos cómo configurar NGINX para admitir acceso web Dual Stack; veremos cómo configurar NGINX como un proxy inverso que escucha tanto en direcciones IPv4 como IPv6, y cómo direccionar correctamente las solicitudes entrantes a los servidores backend que solo tienen direcciones IPv6.  Por cierto, lo que estudiaremos en el siguiente artículo es un importante paso para lograr el ansiado ahorro de direcciones IPv4, entre muchos otros beneficios.

¿Qué es un reverse proxy?

Cloudflare define en [1] un Servidor Proxy Inverso o Reverso como:

“Un proxy inverso es un servidor que se sitúa delante de los servidores web y reenvía las solicitudes del cliente (por ejemplo, el navegador web) a esos servidores web. Los proxies inversos suelen implementarse para ayudar a aumentar la seguridad, el rendimiento y la fiabilidad. Para entender mejor cómo funciona un proxy inverso y las ventajas que puede aportar, definamos primero qué es un servidor proxy.”

¿Qué es un servidor proxy?

Nuevamente Cloudflare define en [1] un Servidor Proxy como:

“Un proxy de reenvío, con frecuencia conocido como proxy, servidor proxy o proxy web, es un servidor que se sitúa delante de un grupo de máquinas cliente. Cuando esos ordenadores realizan solicitudes a sitios y servicios en Internet, el servidor proxy intercepta esas peticiones y luego se comunica con los servidores web en nombre de esos clientes, como un intermediario.”

¿Cuáles son los beneficios de un Reverse Proxy?

•     Ofrecer IPv4 o IPv6 transparente a clientes provenientes desde Internet servidos desde una granja de servidores IPv6 Only (en esto nos enfocaremos)

•     Escalabilidad: Al utilizar un proxy inverso, es posible agregar o eliminar servidores backend según sea necesario sin afectar a los usuarios finales. Esto facilita la escalabilidad horizontal de las aplicaciones, lo que permite manejar un mayor número de solicitudes y usuarios simultáneos.

•     Cacheo de contenido estático: NGINX puede almacenar en caché contenido estático como imágenes, archivos CSS y JavaScript, lo que reduce la carga en los servidores backend y acelera la entrega de contenido a los usuarios. Esto mejora el tiempo de carga de las páginas y reduce el ancho de banda necesario.

•     Seguridad: NGINX actúa como un punto de entrada a la aplicación, lo que proporciona una capa adicional de seguridad. Puede realizar funciones como filtrado de solicitudes, prevención de ataques DDoS, protección contra inyecciones SQL y autenticación de clientes. Además, NGINX puede habilitar el uso de SSL/TLS para cifrar la comunicación entre los clientes y el servidor backend.

•     Enrutamiento avanzado: Un proxy inverso permite realizar enrutamiento avanzado según diferentes criterios, como el nombre de dominio, la URL o las cabeceras HTTP. Esto es útil en casos donde se necesite dirigir el tráfico a diferentes servidores backend según las características de la solicitud.

•     Consolidación de servicios: NGINX puede actuar como un punto de entrada único para varios servicios backend. Esto simplifica la infraestructura al consolidar múltiples servicios en un solo servidor, lo que facilita la administración y el mantenimiento.

•     Mejora del rendimiento: NGINX está diseñado para ser liviano y eficiente en el uso de recursos. Su arquitectura optimizada y su capacidad para manejar grandes cantidades de conexiones simultáneas lo convierten en una opción popular para mejorar el rendimiento de las aplicaciones web.

•  Balanceo de carga: Un proxy reverso como NGINX puede distribuir el tráfico entrante a través de varios servidores backend. Esto ayuda a equilibrar la carga de trabajo y garantiza que ningún servidor esté sobrecargado, lo que mejora el rendimiento y la capacidad de respuesta de la aplicación. 

Topología que vamos a usar

¿Qué vamos a lograr el día de hoy?

El servidor en el borde (Servidor Proxy Reverso) va a ser capaz de recibir peticiones HTTP en IPv4 e IPv6, y dependiendo del sitio Web que se desea visitar (dominio) re-enviará la consulta al servidor correcto. En el ejemplo actual ocurrirá lo siguiente:

El Cliente visita      Petición enviada a:

server-a.com   →   2001:db8:123::101

server-b.com   →   2001:db8:123::102

server-c.com   →   2001:db8:123::103

Prerrequisitos

• Linux con Nginx en el Servidor Proxy Reverso 

• Acceso super usuario

• Servidor Web en cada uno de los servidores de la granja

• Conectividad a Internet IPv4 e IPv6

• Conectividad interna en IPv6

Manos a la obra

1) Instalar nginx en todos los servidores 

   #apt update

   #apt install nginx

2) Crear los sitios Web en el Proxy Reverso NGINX 

Archivo  /etc/nginx/sites-available/server-a.com

server {

listen 80;

listen [::]:80;

    server_name server-a.com;

    location / {

        proxy_pass http://[2001:db8:123::101];

    }

}

Archivo  /etc/nginx/sites-available/server-b.com

server {

listen 80;

listen [::]:80;

    server_name server-b.com;

    location / {

        proxy_pass http://[2001:db8:123::102];

    }

}

Archivo  /etc/nginx/sites-available/server-c.com

server {

listen 80;

listen [::]:80;

    server_name server-c.com;

    location / {

        proxy_pass http://[2001:db8:123::103];

    }

}

3) Crear links simbólicos para habilitar los sitios configurados:

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-a.com /etc/nginx/sites-enabled/server-a.com

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-b.com /etc/nginx/sites-enabled/server-b.com

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-c.com /etc/nginx/sites-enabled/server-c.com

4) Recordemos reiniciar nginx:

$sudo systemctl restart nginx

Sobre los logs

Los registros de conexión (logs) son de suma importancia para cualquier empresa e ISP que desea realizar alguna revisión de las conexiones entrantes.

  Lo que ocurre es que NGINX por defecto utilizará su propia dirección IP cuando realice las conexiones salientes, lo que trae como consecuencia que se pierde la dirección del cliente que originó la solicitud HTTP.  Pero no se preocupen, NGINX tiene la solución, se llama proxy_set_header y la configuración se divide en el servidor final y en el servidor Proxy Reverso.

1. En el Servidor Proxy Reverso, archivo del sitio web.

# Ejemplo de  nginx reverse proxy que permite conservar la dirección

# y puerto de original del cliente

location /examples {

  proxy_pass http://[2001:db8:123::103];

  proxy_buffering off;

  proxy_set_header X-Real-IP $remote_addr;

  proxy_set_header X-Forwarded-Host $host;

  proxy_set_header X-Forwarded-Port $server_port;

  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

2. En el servidor final en el archivo: /etc/nginx/nginx.conf agregar en la sección http lo siguiente:

   set_real_ip_from 2001:db8:123::100; #sustituir la dirección IP por la del Proxy

   real_ip_header X-Forwarded-For;

   real_ip_recursive on;

Ejemplo:

http {

    …

    set_real_ip_from 2001:db8:123::100;

    real_ip_header X-Forwarded-For;

    real_ip_recursive on;

   …

}

  Luego de estas configuraciones el servidor final confiará en la cabecera llamada X-Forwarded-For que provenga del IP 2001:db8:123::100 y en sus registros (/var/log/nginx/access.log) se podrá apreciar la dirección origen del cliente.

Conclusiones

Se puede percibir que con el diseño propuesto podemos administrar una granja de servidores web 100% IPv6 Only con acceso al mundo tanto IPv4 e IPv6 de una manera muy sencilla, escalable y eficiente. Lo anterior trae consigo diferentes beneficios tales como: administrar solo un stack TCP/IP, simplicidad, seguridad e incluso ahorro de direcciones IPv4.

Referencias

• [1] https://www.cloudflare.com/es-es/learning/cdn/glossary/reverse-proxy/

• https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-reverse-proxy-on-ubuntu-22-04

• Archivos de configuración de todo el proyecto en el Github de LACNIC:  https://github.com/LACNIC/BlogPostHelpFiles/tree/main/2023_Ofreciendo_conectividad_Dual_Stack_a_servidores_Web_en_una_granja_de_servidores_100_IPv6_Only

ortodoncia invisible madrid

Comportamiento extraño de ssh en MAC - Problemas de copiar / Pegar

 Situación:

  Comportamiento extraño de SSH en MAC, problemas para copiar / pegar en el terminal durante el ssh. Funciona el portapapeles en otras aplicaciones

Solución:

  Al menos en "vi" la solución es muy sencilla. Edita el archivo: ~/.vimrc y pega el siguiente contenido:

if !has("gui_running")

  set mouse=

endif

Suerte!

4 posibles soluciones en Python3 a: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 503: ordinal not in range(128)

Problema: 

 Al ejecutar un script en python se recibe un mensaje similar a: 

return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 503: ordinal not in range(128) 

Causa:

  Por defecto python intenta utilizar ASCII como encoding, en caso de que el archivo a leer, la variable a declarar tenga otro codec debe ser especificado, sin embargo, en líneas generales UTF-8 es capaz de solucionar la mayoría de las situaciones

Soluciones

1) Especifar el encoding al momento de leer un archivo:

 with open(os.path.expanduser(path), encoding='utf-8') as f:

2) Asignar una variable e indicar la forma de decodificarla:

s = s.decode('utf-8')

3) Declarar variables de entorno (Linux). Por ejemplo

 export LANG=en_US.UTF-8 

export LC_ALL=en_US.UTF-8 export 

export PYTHONIOENCODING=utf8

4) Indicar al comienzo del script el coding. Por ejemplo

#!/usr/bin/python

# coding: utf-8

Suerte, espero haya sido de tu ayuda.

Solución "Unable to parse package file " luego de apt

 Problema:

    Obtenemos un error después de ejecutar cualquier comando apt en Linux

Solución:

    La solución es muy fácil, les comento que pasé muchas horas arreglándolo.

    Solo tiene que eliminar el archivo mencionado en el error, en mi caso obtuve: "E: Unable to parse package file /var/lib/apt/extended_states (1)"

    Acabo de borrar el archivo /var/lib/apt/extended_states

  Ejemplo:

    #sudo rm /var/lib/apt/extended_states

  Eso es todo, suerte!

Instalando el validador FORT RPKI en Ubuntu 20.04

 

Solución: VBoxGuestAdditions.iso (VERR_PDM_MEDIA_LOCKED)

Situación: 

   Cuando intentando insertar los Guest Addition en una VM Debian recibes: VERR_PDM_MEDIA_LOCKED 

Solución: 

   Hay varias soluciones, por ejemplo: 

1) Ejecutar: 

   sudo apt-get upgrade 

   sudo apt-get install virtualbox-guest-additions-iso

2) Remover e insertal el CD dentro de la configuración de la máquina virtual

3) Dejando una unidad óptica en blanco

y una cuarta solución que justo la acabo de hacer y quise publicar este post:

a) Arranca la VM

b) Abre un terminal

c) Ejecuta:

  sudo su

  cd /media

  mkdir cdrom

  mount /dev/cdrom /media/cdrom

  cd cdrom

  sh VBoxLinuxAdditions.run

Espero sea de utilidad.

Alejandro,

Global spending on public cloud services is expected to grow 18.4% in 2021 to total $304.9 billion (Gartner).

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.

RFC 7911- BGP Add-path en acción

En el video se realiza un demo de la capacidad de BGP llamada Add-Path definida en el RFC 7911 utilizando FRR sobre Ubuntu. Para la realización del video se utilizó únicamente prefijos IPv6 a pesar de que la capacidad es agnóstica al prefijo transportado

Roles en BGP - Reduciendo fugas de redes/prefijos en BGP con mensajes OPEN y UPDATE

El video muestra una característica muy novedosa aún discutida dentro de IETF de como prevenir routing leaks utilizando un nuevo concepto llamado: "Roles BGP"

Solucion: Closing connection because of an I/O error en FRR

 Hola,

  Si recibes el siguiente error en FRR:

Closing connection because of an I/O error

  la solución que yo tuve fue compilar de nuevo agregando el flag:

--enable-systemd

  Sería algo como:

./configure \

    --prefix=/usr \

    --includedir=\${prefix}/include \

    --enable-exampledir=\${prefix}/share/doc/frr/examples \

    --bindir=\${prefix}/bin \

    --sbindir=\${prefix}/lib/frr \

    --libdir=\${prefix}/lib/frr \

    --libexecdir=\${prefix}/lib/frr \

    --localstatedir=/var/run/frr \

    --sysconfdir=/etc/frr \

    --with-moduledir=\${prefix}/lib/frr/modules \

    --with-libyang-pluginsdir=\${prefix}/lib/frr/libyang_plugins \

    --enable-configfile-mask=0640 \

    --enable-logfile-mask=0640 \

    --enable-snmp=agentx \

    --enable-multipath=64 \

    --enable-user=frr \

    --enable-group=frr \

    --enable-vty-group=frrvty \

    --enable-systemd \

    --with-pkg-git-version \

    --with-pkg-extra-version=-MyOwnFRRVersion

  Puedes seguir las las instrucciones en: http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-ubuntu2004.html  y agregar mi propuesta.

Suerte.

Tunel GRE entre Linux y Cisco IOS

Lado del linux:

[root@server]# ip tunnel add tun0 mode gre remote $public_ip_cisco local $public_ip_linux ttl 255

[root@server]# ip link set tun0 up

[root@server]# ip addr add 172.20.0.2/30 dev tun0

Del lado del Cisco

interface Tunnel0

 description Tunel hacia sitio remoto

 ip address 172.20.0.1 255.255.255.252

 tunnel source $public_ip_cisco

 tunnel destination $public_ip_linux

end

  Para enrutar cierta red desde el Cisco hacia el linux via el tunel: 

ip route $prefix $mask 172.20.0.2 

Espero sea útil.

Saludos

Python3: Una solucion a UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position 26: ordinal not in range(128)

Situación:

  Al ejecutar un script en python3 se recibe un error similar a:

UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position 26: ordinal not in range(128)

Solución:

  El problema viene dado (tal como lo explica el mensaje) por manejo de strings y unicode, muy seguramente el código contiene algún tipo de carácteres en  

español, portugués, árabe u otro idioma no cubierto por ASCII

  Si lees en Internet hay DECENAS de maneras de solucionar esto, yo solo voy a mencionar una que funciona y es MUY sencilla.

  Si te encuentras en Linux o MAC es tan sencillo como colocar esto antes de ejecutar tu script (dentro de bash):

export PYTHONIOENCODING=utf8

  Lo que se esta haciendo es declarar la variable de entorno PYTHONIOENCODING a utf8, python3 al ser ejecutado utilizará esta variable como encoding y tu problema será resuelto.

  Claro, pudieses colocar dicha variable al entrar a tu sesión, o dentro de un script en bash que posteriormente llame a tu .py, etc, etc.

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

Como verificar si un sitio Web se encuentra bloqueado

Hola,
  Si en google por ejemplo buscamos "como revisar si un sitio web esta bloqueado" será difícil  conseguir información de como revisar nosotros mismos, los resultados serán principalmente sitios Web que pueden abrir la página Web por tí, mostrarte desde otros sitio si puede conectarse, algún plugin que puedas instalar. En estás páginas se puede revisar si un sitio está arriba o no: https://www.blocked.org.uk/check y https://downforeveryoneorjustme.com/

   NOTA: Este post es básicamente como podemos revisar nosotros mismos un bloqueo. Estamos hablando de bloqueos por parte de un ISP/país, no de bloqueos en el firewall en una empresa o compañía. Se aceptan sugerencias y quejas.., comentarios están abiertos al final del documento

Introducción:
  Como algunos de ustedes saben, existen muchas manera de bloquear sitios Web, principalmente los bloqueos ocurren de 4 maneras:
1) DNS
2) Routing
3) Capa 4 (bloqueo de puertos TCP/UDP a ciertos destinos)
4) Capa 7 (bloqueo de por ejemplo la URL/dominio)

  Ahora bien, antes de continuar quiero dejar claro mi posición en cuanto a los bloqueos en Internet: ME PARECEN MUY MALA IDEA y no trae nada bueno al país/ISP..., y en el supuesto que traíga una cosa buena, trae 10 cosas malas. Tengo algunas cosas plasmadas en este post: https://blog.acostasite.com/2014/10/la-mala-idea-de-bloquear-internet.html

Pasos para revisar un bloqueo de un sitio Web:
  Ahora bien, en el supuesto que queramos saber si algún sitio se encuentra bloqueado, podemos seguir estos pasos (preferiblemente Linux y/o MAC):

1) Revisar si el bloqueo es por DNS. ¿Cómo lo hacemos?
   Podemos usar dos herramientas de resolución DNS. Para este ejemplo utilizaremos dig y/o nslookup.


.- Utilizando dig

MacBook-Pro-2:tmp$ dig +short www.example.com

172.XX.YY.39

.- Utilizando nslookup

MacBook-Pro-2:tmp$ nslookup www.example.com

Server: 8.8.8.8

Address: 8.8.8.8#53

Non-authoritative answer:

Name: www.example.com

Address: 172.XX.YY.39

¿Qué hay que revisar de la salida?
Básicamente con el comando, le pedimos a dig que muestre de manera resumida, que direcciones IP resuelve www.example.com. En este sentido 172.XX.YY.39 será el IP al cual nuestra computadora se va a conectar. Lo importante aquí es identificar si 172.XX.YY.39 corresponde al IP destino que nos queremos conectar (si, ciertamente pueden resolver direcciones diferentes y eso, pero si sabes eso no necesitas leer este documento :) !! )  Muchas veces algunos ISPs cambian la resolución de un dominio y no verías el IP correcto sino otra al cual es imposible conectarse (por ejemplo, 127.0.0.1)


2) Routing

  Para revisar routing principalmente utilizaremos traceroute (tracert en Windows)

  La idea es en lineas generales ver si podemos alcanzar el destino desde nuestra computadora:


Utilizando traceroute:

MacBook-Pro-2:tmp$ traceroute -n 8.8.8.8  (sustituye 8.8.8.8 por el dominio o el IP obtenido en el paso previo)

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets

 1  192.168.1.1  1.724 ms  1.030 ms  1.376 ms

 2  190.XX.XX.1  28.969 ms *  35.939 ms

 3  172.YY.13.33  27.988 ms  27.379 ms  29.267 ms

 4  * * *

 5  10.XX.1.105  29.229 ms 28.628 ms 28.303 ms

 6  10.XX.1.1  38.332 ms  26.855 ms 28.605 ms

 7  200.XX.XX.177  61.560 ms  62.466 ms  68.661 ms

 8  72.NN.NN.84  62.411 ms  62.523 ms 62.188 ms

 9  108.170.253.17  62.537 ms  63.011 ms 63.182 ms

10  108.170.226.13  63.588 ms 65.335 ms 62.301 ms

11  8.8.8.8  62.329 ms  63.023 ms  62.176 ms

¿Qué hay que revisar de la salida?

  Como se puede ver en el traceroute de arriba, se llegó satisfactoriamente al destino.
  En el caso de ver algún "!" seguido por una letra, es mala noticia. Por ejemplo ver esto en el traceroute significa que hay algo mal, quizás el ISP bloqueó las direcciones IP destino de alguna manera.

  Errores comunes (tomados de la página del manual de traceroute):

 !H, !N, or !P (host, network or protocol unreachable)

  !S (source route failed)
  !U or !W (destination network/host unknown) 
 !I (source host is isolated)
 !A (communication with destination network administratively prohibited)
 !Z (communication with destination host administratively prohibited)
 !Q (for this ToS the destination network is unreachable), 
 !T (for this ToS the destination host is unreachable), 
 !X (communication administratively prohibited), 
 !V (host precedence violation), 
 !C (precedence cutoff in effect), or 
 ! (ICMP unreachable code ). 

Extra:
  Otra herramienta que recomiendo para revisar este punto es MTR  (My traceroute) ; https://es.wikipedia.org/wiki/MTR_(software).., es una combinación de ping y trace. MUY buena.


3) Capa 4 (bloqueo de puertos a ciertos destinos)
  Para revisar bloqueos de capa 4, principalmente la idea es revisar conectividad a nivel de puertos (TCP) desde tu computadora al destino.
  La herramienta más sencilla para revisar esto es telnet, la intención al ejecutarlo es chequear que efectivamente "se conectó" nuestra computadora al destino.

Utilizando telnet:
Ejemplo 1: (conecta¡ándose al puerto http)

MacBook-Pro-2:tmp$ telnet www.example.com 80  -- 80 quiere decir el puerto destino

Trying 199.NN.NN.100...

Connected to www.example.com. --- esto es lo que hay que revisar

Escape character is '^]'.

Ejemplo 1: (conectándose al puerto https)

MacBook-Pro-2:tmp$ telnet www.example.com 443  -- 443 quiere decir el puerto destino

Trying 199.NN.NN.100...

Connected to www.example.com.   --- esto es lo que hay que revisar

Escape character is '^]'.

Cuando el destino se encuentra bloqueado a nivel de 4 veríamos algo así:

MacBook-Pro-2:tmp$ telnet www.example.com 80

Trying 199.XX.XX.100...

telnet: connect to address 199.XX.NN.100: Operation timed out

telnet: Unable to connect to remote host

Depende el tipo de bloqueo, el telnet puede ser rechazado muy rápido (reject *), quizás el telnet solo dure mucho hasta que haga timeout.

* tu computadora recibe un icmp error desde el dispositivo que se encuentra bloqueando

4) Capa 7 (bloqueo de por ejemplo la URL/dominio)

  Revisar capa 7 viene a ser cuando el ISP es capaz de identificar el contenido de paquetes HTTP y chequear por el texto del dominio bloqueado dentro de él, es decir: el ISP quiere bloquear www.example.com, algunos dispositivos dentro del ISP son capaces de revisar a nivel de capa de aplicación (capa 7) el fqdn www.example.com, y allí tomar la decisión: bloquear o no.

  Para lo anterior, recomiendo utilizar curl o wget. Dejaré solo el ejemplo con curl:

Utilizando curl (en hacia un destino bloqueado)

MacBook-Pro-2:tmp$ curl -v https://www.example.com

* Rebuilt URL to: https://www. example.com/

*   Trying 172.NN.NN.39...

* TCP_NODELAY set

* Connected to www.example.com (172.NN.NN.39) port 443 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

* successfully set certificate verify locations:

*   CAfile: /etc/ssl/cert.pem

  CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443 

* stopped the pause stream!

* Closing connection 0

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443 

¿Qué hay que revisar de la salida?

   No hay que asustarse con la salida, aquí hay revisar que la negociación SSL/TLS no pudo completarse, esto lo podemos apreciar al conseguir que el texto *ERROR* se ve en la salida.

   Nota: Cuando la salida es satisfactoria, veremos código html

Conclusión:
  Existen MUCHAS manera de bloquear acceso a sitios en Internet, incluso en algunas oportunidades puede usarse una combinación de varias maneras para lograr un bloqueo.

  Se que el post puede ser mucho más amplio y faltaron cosas por cubrir, sin embargo a su vez espero que él mismo sea visto como una introducción.

  El bloqueo de sitios Web en Internet no trae beneficios.

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