En el video se muestra como configurar una sesión BGP entre dos enrutadores Cisco IOS. Se realiza con ebgp multihop y se muestra captura de paquetes con Wireshark
jueves, 10 de octubre de 2019
jueves, 4 de julio de 2019
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.
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
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
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)
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
#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
martes, 30 de abril de 2019
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
.- Utilizando nslookup
¿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
La idea es en lineas generales ver si podemos alcanzar el destino desde nuestra computadora:
Utilizando traceroute:
¿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):
!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
!).
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)
Ejemplo 1: (conectándose al puerto https)
Cuando el destino se encuentra bloqueado a nivel de 4 veríamos algo así:
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)
¿Qué hay que revisar de la salida?
El bloqueo de sitios Web en Internet no trae beneficios.
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?
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
!
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.
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.
jueves, 4 de abril de 2019
Video: Ejemplo: Utilizando BGP Local Preference y Weight con prefijos IPv6
Η δυσκοιλιότητα είναι αποτέλεσμα διάφορων παραγόντων, η οποία φαίνεται, να έχει ενταθεί λόγω του σύγχρονου τρόπου ζωής. Αντιμετωπίστε άμεσα τη δυσκοιλιότητα με το Izicol. Ωστόσο, πολύ σημαντικός παράγοντας φαίνεται να είναι η διατροφή και η ενυδάτωση του οργανισμού.
martes, 19 de marzo de 2019
miércoles, 13 de marzo de 2019
Video: Ejemplo de BGP Route Reflector en una red IPv6
Hola,
Les comento que el otro día estuve dando un curso de IPv6 que incluía una parte de BGP; entre las consultas que recibí hubo una pregunta de enrutadores Route Reflector, por ello decidí realizar el siguiente video:
Espero sea útil para alguien.
Saludos,
Alejandro,
Les comento que el otro día estuve dando un curso de IPv6 que incluía una parte de BGP; entre las consultas que recibí hubo una pregunta de enrutadores Route Reflector, por ello decidí realizar el siguiente video:
Espero sea útil para alguien.
Saludos,
Alejandro,
miércoles, 6 de febrero de 2019
DNS: Bloquear o no bloquear las direcciones IPv6 6to4
Introducción
El
servicio de DNS es sin duda alguna uno de los pilares de Internet, sin DNS el
Internet no sería ni remotamente como lo conocemos hoy en día.
DNS es
el servicio que permite -entre otras funciones- convertir nombres de dominios a
direcciones IP y viceversa.
Sobre
el proyecto IPv6 Open Resolvers:
Dentro
de Lacnic, desde comienzos del año 2018 [1] estamos en la búsqueda de
servidores DNS sobre IPv6 que son consideraciones “Open Resolvers” [2]
¿Que
tiene que ver 6to4 con Open Resolvers y seguridad?
Durante el tiempo que tiene este proyecto en funcionamiento hemos tenido
la oportunidad de exponer el estudio y sus resultados [3] en sitios como
DNS-OARC 28 , LACNIC 29 y NANOG 74. En esta última, recibimos muy buenos
comentarios y quizás el más significativo fue el de George Wes donde él
indicaba la existencia de muchos servidores DNS con direcciones IP 6to4 [4] las
cuales utilizan direcciones IP de túneles automáticos dentro del prefijo
2002::/16.
En
base a lo anterior, decidimos profundizar en este concepto y estudiar con más
detalle los resolvers con direcciones IPv6 6to4 y obtuvimos información muy
interesante.
Por
ejemplo, el día 2 de Diciembre del 2018 estudiamos: 6248 servidores, de los
cuales 61 estaban contenidos en el prefijo 2002::/16, y de aquí tuvimos 20
servidores abiertos, es decir, casi un 33%. Todos ellos potenciales para realizar diferentes ataques de DNS como de amplificación, cache poisoning, DDoS, DNS hijacking, entre otros.
Aquí
tenemos dos gráficos de lo arriba expuesto:
Conclusión
Primero, el problema per sé no es el 6to4, son los Open Resolvers. Segundo, como administrador de servidores DNS ustedes deben querer responder a la mayor cantidad de queries posibles de clientes válidos, nuestra recomendación no se ajusta solo a redes 6to4, sino básicamente la implementación de RLL (Response Rate Limit) a los queries según el origen, claro prestarle mayor atención a las provenientes del prefijo 2002::/16 no es mala idea.
Referencias
vivo v15 pro
beautiful Rohini escorts for you
Suscribirse a:
Entradas (Atom)
Una mejora práctica en el Transporte DNS sobre UDP en IPv6
Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...
