ANCI ICANN | Charla buenas prácticas DNSSCEC

Muy buenos días a todos y a todas. Eh,
mi nombre es Rodrigo Saucedo. Soy
director de relacionamiento de partes
interesadas para la región andina y de
iniciativas estratégicas para América
Latina y el Caribe en la ICÁ. Eh, esta
es la segunda sesión que tenemos. El día
de hoy vamos a hablar sobre eh un
protocolo de seguridad del DNS, más
conocido como DNC. Y para eso lo tenemos
a Nicolás Antonielo, que es mi colega en
ICAN, él es de Uruguay, él es eh gerente
de relacionamiento técnico para la
región de América Latina y el Caribe y
los dejo en muy buenas manos. Lo único
que les eh les pido por favor es eh
apagar sus dispositivos, mantenerlos en
silencio y si tienen alguna pregunta eh
levanten la mano y les vamos a ceder la
palabra. Intentemos hacerlo eh que sea
lo más interactivo posible y con eso no
les quito más tiempo. Le cedo la palabra
a Nicolás. Adelante, Nico.
Hola, buenas, buenos, buenos días a
todos, a todas. ¿Se se escucha bien el
audio, Rodrigo? Perfecto. Eh, bueno,
como dice Rodrigo, hoy el objetivo de
hoy es revisar el
protocolo
de NSC.
lo que vamos a lo que vamos a hacer es
eh bueno, basándonos un poco lo que en
lo que vimos en la en la sesión anterior
sobre DNS
y vamos a vamos a hablar este de esta de
esta extensión de seguridad eh que se
llama que recibe el nombre de de DNCSC.
Vamos a hablar de un poco de de cómo
funciona y cómo funciona en general el
el mecanismo que que utiliza DNS y
bueno, cómo se aplica eso en en en el
DNS y y al final vamos a ver algunas
algunas consideraciones y algunas
estadísticas eh de DNCSC que que que
puse ahí en la presentación para para el
caso de Chile, sobre todo para la parte
de los de los de los resolver, de los de
los servidores recursivos de DNS a modo
de repaso.
El la vez anterior cuando vimos cuando
repasamos el tema de DNS, eh simplemente
recordar el DNS es tiene esa estructura
de árbol invertido donde la raíz está
arriba del todo, en la parte más alta de
la jerarquía y a partir de ahí se va
armando todo el todo lo que llamamos el
árbol del sistema de nombres de dominio
del DNS.
Recuerdan que en el caso del primer
nivel por debajo de la raíz, ¿sí? Lo que
se llaman justamente dominios de primer
nivel o dominios este de nivel superior,
habíamos eh hacemos énfasis en dos en en
dos de de dos tipos de de dominios de de
primer nivel, los que llamamos dominios
genéricos de primer nivel y los dominios
asociados a códigos de país. ¿Sí? Y
bueno, por debajo de cada uno de esos a
su vez pueden haber sus dominios y así
sucesivamente se va armando todo el el
árbol de DS.
Recordar también la forma en la que se
almacena la información, ¿sí? La forma
en la que almacenamos información en ese
en ese en ese en ese sistema en el
sistema de nombres de dominio es a
través de la utilización de lo que
llamamos registros. ¿Sí? Entonces,
recuerden que teníamos un registro
diferente para cada tipo distinto de
información que se puede almacenar en
DNS. Es así que teníamos un registro
para almacenar la dirección IP versión 4
asociado a un nombre de dominio, un
registro para almacenar la dirección IP
versión 6 asociado a un nombre de
dominio, un registro para almacenar el
el nombre del servidor de correo
electrónico, etcétera, etcétera. ¿Sí?
Entonces, cada registro es un tipo de
información que yo almaceno en el DNS. Y
quien administra una parte del DNS,
quien administra una zona del DNS, sí,
va a administrar todas las la los
registros asociados a un determinado
nombre de dominio, ¿sí? O o a un
conjunto de nombres de dominio.
Entonces, esa esa información se va a
colocar en en lo que se llama archivo de
zona, digamos, ¿sí? que básicamente es
toda la la
especificación de toda la información
almacenada referente a ese a ese a ese
nombre de dominio. ¿Sí?
Bien, hasta ahí había había un repaso
muy muy rápido de de de lo que habíamos
visto la vez pasada. ¿Por qué hago este
repaso? Porque bueno, DNC vamos a ver
que agrega algunos algunos registros,
agrega algunos tipos de datos que
también hay que almacenar en el sistema
de nombres de dominio para poder este
cumplir con con la especificación y con
lo y con lo que con con las
funcionalidad del del protocolo.
Entonces, voy a compartir la
presentación.
Bien, se ve correctamente la
presentación, Rodrigo.
Perfecto. Bien, entonces eh antes de
comenzar y para hacer el comentario
general, recuerden que en cualquier
momento pueden enviar un una consulta,
un comentario, lo pueden hacer en el en
el en el chat y ahí, Rodrigo, en ese
caso, te voy a pedir si si tú podés este
monitorear el chat porque yo no no lo
voy a no lo veo tan fácilmente cuando
estoy presentando. Y y bueno, si no
también pueden este
activar el micrófono y hacer uso de la
de la palabra para para justamente para
hacer las consultas o comentarios. Si no
no esperen al final de la presentación,
como siempre, la idea es hacerlo es
hacerlo dinámico, así que en cualquier
momento pueden pueden este eh
intervenir. Bien, perfecto. Entonces,
empecemos.
Vamos a
a empezar con el con el repaso este de
de de y explicación de cómo funciona el
protocolo de NC. Entonces, a veces
cuando se habla de del protocolo de NS y
de los protocolos de internet en
general, si se dice que
la seguridad no era algo que se que se
consideraba al principio. Eh, estamos
hablando de la década de 1980, cuando
surge todo este tema de internet y
cuando surge el sistema de hombres
dominio, etcétera. Eso no es no es del
todo correcto, digamos. No, no, no, no
es que no se considerara la seguridad en
en las versiones originales de los
protocolos.
Eh, la seguridad se considera siempre,
solamente que eh los requerimientos de
seguridad han ido cambiando a lo largo
del del del tiempo, ¿no?, de la historia
de vida de internet, ¿sí? En estos, no
sé, 40, 50 años que que que existe
internet. Al principio las
consideraciones de seguridad eran eran
bastante laxas, no había mucha
preocupación
por la seguridad porque internet eran
unos pocos dispositivos. Eh eh al
principio era exclusivamente o casi
exclusivamente a nivel académico,
después eso fue creciendo y bueno, los
requerimientos de seguridad fueron
cambiando, fueron incrementándose los
requerimientos de seguridad, fueron
surgiendo otros otros otros
requerimientos y y otras este
vulnerabilidades en materia de
confidencialidad, por ejemplo.
Eso se vio, el tema de confidencialidad,
por ejemplo, se vio bastante acrecentado
con con el surgimiento de la normativa a
nivel de la de la Unión Europea de GDPR.
Eh, entonces ahí hubo que que revisar un
montón de de funcionalidades eh en
materia de de almacenamiento y y y
disponibilidad pública de de información
que fue considerada o es considerada
datos personales y no debe ser accesible
públicamente, etcétera, etcétera. ¿Sí?
Entonces, en materia de de seguridad, en
materia de de
privacidad,
fueron cambiando los requerimientos. Eh,
también en materia de lo que llamamos
disponibilidad, ¿sí? En en la la
disponibilidad es, digamos, la la la el
la capacidad de acceder a un determinado
servicio, ¿sí? Eh, a medida que que se
va volviendo más importante o más este
estratégico que determinado servicio
permanezca siempre disponible, ¿sí? Se
van agregando o se van diseñando
mecanismos y protocolos para aumentar
esa esa disponibilidad. Sí. En el caso
del sistema de de nombres de dominio, es
un sistema que tiene altísima
disponibilidad, digamos, y bueno, tiene
un montón de de de mecanismos y de
protocolos, como decía, este, que están
diseñados específicamente para eso.
Entonces, mirando un poco esta esta
estas tres áreas de de vulnerabilidades
que que pusimos acá, lo que sería
confidencialidad, lo que sería
disponibilidad y lo que sería
integridad, vamos a explicar brevemente
cada cada una de ellas y y y ver en cuál
es que que que vamos a estar
posicionados hoy en día. O sea, sobre
cuál de estas actúa DNSC. Cuando
hablamos de confidencialidad en general,
como como recién estamos mencionando,
hablamos de bueno de del del se visto
desde el lado de la vulnerabilidad,
digamos, vulnerar la confidencialidad
sería acceder en forma no deseada a
determinada información de tercero, ¿sí?
Por ejemplo, un sistema de información
que está destinado para uso interno de
una organización, si se vulnera ese
sistema y y y una un una tercer persona,
un atacante logra acceder a esa
información, ahí se estaría vulnerando
la confidencialidad. Esto tiene que ver
también con la privacidad. Hay
muchísimas formas de de de
asegurar la confidencialidad de los de
los de los sistemas. En general, cuando
estamos hablando de envío de información
a través de de internet, uno de los
mecanismos por excelencia utilizado para
preservar la la confidencialidad o la
privacidad es la encriptación. Sí,
generar un canal encriptado en el cual
la información entre origen y destino
viaja encriptada. Entonces, si alguien
captura los datos,
no tiene posibilidad de decodificar o de
desencriptar esa información, de
visualizar la la la información a menos
que conozca el mecanismo para
desencriptarla, o sea, tenga las
credenciales para desencriptarla o el
algoritmo que yo utilice, el mecanismo
que yo utilice para encriptar, eh se se
vulnere. Y bueno, ahí este
eso en general se se se
refiere a que se rompe el el mecanismo
de de encriptación y bueno, ahí se puede
acceder a la información, digamos, ¿no?
Este,
después el tema de la disponibilidad es
eso, la disponibilidad, si visto de
nuevo desde el lado de la vulnerabilidad
sería perder la capacidad de acceso o la
o la la la capacidad de utilizar o de
acceder a un determinado servicio o un
determinado sistema o mecanismo. ¿Sí? Y
por último, la integridad sería
evitar, si se quiere, la modificación o
destrucción no deseada de información.
Sí. De estas tres áreas, DNCSC no actúa
sobre la confidencialidad. Esto es algo
que a veces eh
genera confusión, digamos. DNCSC no
encripta la información. La información
de DNS sigue viajando en texto, lo que
llama texto claro, digamos, cualquiera
que capture tanto la consulta de NS como
las respuestas de NS a cualquier nivel
entre entre el cliente y el servidor
recursivo, entre el servidor recursivo y
los servidores autoritativos, en
cualquier momento las todo el tráfico de
de información de DNS es visible por
cualquiera que logre capturar ese
tráfico. ¿Sí? Entonces, DNSC, esta
extensión de seguridad, la que vamos a a
ver hoy, no agrega en materia de
confidencialidad. Sí, tampoco agrega en
materia de disponibilidad. No hace el
desplegar de NSC, no hace que el sistema
de nombres de dominio sea más tolerante
a a a fallos de disponibilidad. Sí, lo
hace, por supuesto, más tolerante a a a
ataques, pero eso lo lo vamos a ver
enseguida. Pero no aumenta la
disponibilidad del sistema de nombre de
dominio par. ¿Sí? ¿Dónde actúa DNCSC?
Entonces, actúa en materia de
integridad. Sí, DNSC justamente está
diseñado para evitar la modificación o
destrucción de información de DNS
sin que sea sin que sea evidente, o sea,
digamos evitar la modificación o
destrucción de información de DNS, sobre
todo la modificación de información de
DNS y que eso pase desapercibido. ¿Sí?
Entonces, de nuevo, DNSC actúa en
materia de de eh integridad. Acá hay un
hay un un este este slide, digamos, lo
que trata de mostrar es un un el caso de
cómo funcionaría el cómo funciona el
sistema DNS, como vimos este la sesión
anterior sin DNSC. Sí, recuerden que
tenemos un un cliente, un dispositivo
que que realiza una consulta de que
tiene que resolver, por ejemplo, cuál es
la dirección IP asociada a un
determinado nombre de dominio. Envía la
consulta a un servidor recursivo. Sí. a
los estos buscadores. Sí. Luego el
servidor recursivo va a empezar a buscar
la respuesta consultando sucesivamente
servidores autoeditativos. Si no tienen
ninguna información acerca de la
consulta que le hicieron, va a comenzar
preguntándole a la raíz y después va a
ir como navegando el árbol hacia abajo,
empezando por la raíz, hasta encontrar
el servidor autoritativo que tiene la
respuesta que está buscando. Una vez que
ese servidor autoritativo le envía la
respuesta al servidor recursivo, el
servidor recursivo le envía la respuesta
al cliente y ahí termina la parte de de
resolución de DNS o consulta y y y
respuesta de DNS. Recuerden también que
habíamos mencionado en la sesión
anterior que los servidores recursivos,
sí, a su vez cada vez que reciben
información de cualquier servidor
autoritativo, ya sea durante la búsqueda
de de la de la respuesta o o o la
información correspondiente a la
respuesta final, en cualquier caso, el
servidor recursivo siempre guarda esa
información que recibe en memoria. O
sea, todo lo que aprende el servidor
recursivo de los servidores
autoritativos lo guarda en esa que
llamamos memoria calé del servidor
recursivo. ¿Para qué? Para acelerar las
búsquedas, para no tener que salir a
buscar cada vez que le preguntan lo
mismo. Sí, si alguien le pregunta lo
mismo, como lo tiene almacenado en
memoria, va a poder responder más rápido
sin necesidad de volver a salir a buscar
la información. Y recordemos también que
esa información que se almacena en la
memoria del servidor recursivo, no no se
almacena para siempre, sino que se
almacena por un tiempo y pasado ese
tiempo se elimina. Si alguien quiere de
nuevo vuelve a a hacer la misma
consulta, bueno, ahí como la información
ya se se no está en la memoria, va a
tener que volver a recursivo, va a tener
que volver a realizar este toda la
búsqueda de información en el en el
árbol de de DNS. ¿Sí? Bien.
¿Dónde actúa principalmente DNCSC?
Primero dijimos que DNCS entonces actúa
en materia de integridad. Sí. En qué
parte de de todo el de todo el de todo
el el intercambio de información de NS
actúa, bueno, principalmente actúa en el
intercambio de información entre los
recursivos y los autoritativos. O sea,
actúa cuando el servidor recursivo
intercambia información con los
servidores autoritativos. Sí, acá hay
una especie de resumen entonces de qué
es lo que lo que hace DNSC y qué no hace
DNSC. ¿Qué hace DNSC? DSC mediante la
utilización de criptografía que que se
llama de clave pública y clave privada.
Ahora vamos a ver qué es eso de clave
pública, criptografía de clave pública y
firmas digitales. Utiliza criptografía
de clave pública y firmas digitales para
proporcionar básicamente dos cosas. Lo
que se llama lo que llamamos
autenticación de origen, ¿sí? Y lo que
llamamos integridad de los datos.
Autenticación de origen es poder
asegurarse de que la de que quien está
enviando, quien origina la información
sí sea la autoridad para esa información
y no sea alguien que se está haciendo
pasar por la autoridad para la
información. O sea, que la información
provenga de una fuente verdadera y no
sea información falsificada. Eso es
autenticar el origen de la información.
Y la integridad de los datos es que
significa que cuando la información se
está enviando, cuando está este
transitando entre el origen y el
destino, ¿sí?
evitar que esa información sea
modificada y eso pase desapercibido. Es
decir, dense proporciona un mecanismo
para autenticar el origen de los datos y
además proporciona un mecanismo para que
si alguien intercepta la información y
la modifica,
cuando el servidor recursivo recibe la
información, esto es información que el
servidor autoritativo está enviando al
servidor recursivo. ¿Sí? Si alguien
intercepta esa información y la
modifica, el servidor recursivo tiene un
mecanismo provisto por DNSCS, que ahora
vamos a ver enseguida, que le permite
eh darse cuenta o o o verificar si la
información fue alterada o no. Y en caso
de que la información haya sido
alterada, obviamente la va a descartar y
no la va a utilizar porque se trata de
información incorrecta o falsificada.
¿Sí?
Entonces, autenticación de origen,
integridad de los datos.
Básicamente, DNS entonces ofrece
protección contra la falsificación de
datos de DNS, ya sea en el origen o
interceptando la información mientras
viaja de autoritativo a recursivo. ¿Qué
no hace DNS? Bueno, lo que dijimos, no
provee confidencialidad en el
intercambio de datos DNS, o sea, no
encripta los datos de DNS. Sí, los datos
siguen siendo visibles y tampoco evita
todos los ataques posibles de DNS. O
sea, el el el espectro de de ataques de
NS es muy grande. Lo vamos a ver en en
en
futuras sesiones. Eh,
DNS SEC sí evita algunos tipos de ataque
y permite mitigar otros tipos de ataque,
pero no es la solución a todos. Por
ejemplo, este que se menciona acá de lo
que se llama ataque de de neegación de
servicio, ya sea este concentrado o
distribuido. Eh, DNCS, por ejemplo, no
es no proporciona ningún tipo de
protección ni solución ante un ataque
distribuido o concentrado de denegación
de servicio. Sí, pero si proporciona,
por ejemplo, eh una protección 100%
eficiente o eficaz, digamos, 100% eficaz
para el un tipo de ataque que se conoce
como envenenamiento de cé. El
envenenamiento de calé es a nivel de
servidor recursivo inyectar en la
memoria del servidor recursivo una
entrada falsa. Por ejemplo, asociar un
nombre de dominio a una dirección IP de
un atacante en lugar de la dirección IP
original eh que está en el sistema de
nombres de dominio. Entonces, si yo
logro que un servidor recursivo memorice
esa información falsa, cuando alguien le
haga una consulta de NS al servidor
recursivo, el servidor recursivo no va a
salir a buscar la respuesta porque ya la
tiene en memoria, pero lo que tiene en
memoria es incorrecto porque alguien
logró inyectar una entrada falsa en la
memoria del servidor DNS. Entonces,
contaminar la memoria del servidor
recursivo es lo que se llama envenenar
la memoria del servidor recursivo. Y ahí
de ahí viene el nombre de ataque de
envenenamiento de calle del servidor
recursivo. DNSC
evita ese tipo de ataque. O sea, si los
registros de DNS en cuestión están eh
tienen implementado DNSC, no es posible
realizar para esos registros de DNS, no
es posible realizar un ataque de
envenenamiento de calle. Sí, ahora vamos
a ver por qué y cómo funciona y por qué
porque esto es así. De hecho, el este
tipo de ataque fue el la principal
motivación para para el por la cual se
diseñó y se inventó el protocolo de
NSSC. es para DNS surge como un
protocolo este estandarizado por la ITF
como consecuencia como respuesta a este
a a a este tipo de de ataque que se
descubrió y no se descubrió hace hace
mucho tiempo. Digamos DNC eh está
operativo desde el año 2010. Sí,
previo a esa previo a esa a esa fecha,
eh los ataques de de de envenenamiento
de calle y algunos otros ataques eran
eran este mucho más mucho más fáciles de
de de realizar, digamos. Sí.
Bien,
¿cómo funciona DNSC?
Entonces, para explicar cómo funciona
DCS, antes vamos a explicar cómo
funciona, en qué consiste una firma
digital. Sí, vamos a explicar cómo
funcionan el dos dos mecanismos eh
matemáticos, dos algoritmos de de
encriptación, uno que se llama función
de hash y el otro que es el justamente
la encriptación esté basada en clave
pública y clave privada. ¿Sí?
Eh, entonces
veamos primero el mecanismo de de hash.
¿Qué es una función de hash? Sí, una
función de hash es un algoritmo
criptográfico, una una función
matemática, digamos, una operación, una
serie de operaciones matemáticas, un
procedimiento matemático que
en en nuestro caso va a tomar un texto,
¿sí?, una secuencia de caracteres, un
texto
origen, ¿sí? que al aplicarle la función
de hash a ese texto, el resultado sí es
una cadena de caracteres que representa
ese texto encriptado. Sí, lo que hace es
encriptar
un determinado texto con algunas
características muy particulares. Y
vamos a a mencionar tres de esas de esas
características particulares. La primera
característica es que sin importar el
tamaño del volumen de texto original que
yo tenga, una vez que yo defino la
función de hash que voy a utilizar, ¿sí?
Eh, en el ejemplo que está en la
pantalla, la función de hash que yo
utilicé para encriptar todos estos estos
tres textos que están acá, ¿sí? Es una
que se conoce como MD5, que es la
probablemente la función de hash más
utilizada, ¿sí? Que es la que utiliza
además el protocolo de NSCS. y es la que
utilizan otro montón de protocolos.
Prácticamente todos los generadores de
de de firmas electrónicas utilizan esta
función eh de hash MD5, ¿sí? Entonces,
esta función de hash de nuevo toma un
texto y lo encripta, ¿sí? Una vez que yo
fijo la función de hash digo, "Bueno,
voy a usar MD5." El resultado de esa
encriptación, ¿sí? La longitud del
resultado siempre es la misma. No
importa si yo tengo dos caracteres o
tengo un millón de páginas de texto y
las estoy les estoy aplicando la función
de hash. Si le aplico una función de
hash a dos caracteres o le aplico la
misma función de hash a un millón de
páginas de texto, el la longitud del
resultado es siempre la misma. Está eso
es una de las características que tiene
el hash. La longitud del resultado, la
cadena de caracteres o la secuencia de
caracteres encriptada siempre tiene la
misma longitud. Sí. La segunda
característica importante es que no es
reversible. ¿Qué quiere decir que no es
reversible? Quiere decir que una vez que
yo tengo el texto, le aplico la función
de hash y obtengo la cadena encriptada,
si yo les digo, usé el la función de
hash md5 para obtener esta cadena de
caracteres, no existe mecanismo por el
cual ustedes puedan volver partiendo de
la cadena de caracteres, conociendo la
función de hash. No se puede volver
atrás, no se puede volver a obtener el
texto original, no es es lo que se llama
irreversible. Es un proceso
irreversible. Una vez que yo encripté,
no se puede desencriptar más, no hay
forma de desencriptarlo, no hay no hay
mecanismo
matemático estadístico que permita
desencriptar una función de hash. ¿Sí? O
sea, que es en un solo sentido. Solo
puedo encriptar y alguien dirá, "Bueno,
pero para qué sirve si yo encripto algo
y nunca más lo puedo desencriptar.
Está difícil o a veces es un poco
difícil ver la utilidad. La vamos a ver
enseguida." Está, recuerden eso. La
longitud es constante para un para un
algoritmo de gas definido y no es
reversible. ¿Sí? Y la otra
característica que tiene es que
cualquier cosa que yo modifique en el
texto, agregar caracteres, agregar
palabras, agregar espacios, borrar
caracteres, o sea, cualquier
modificación en el texto original
produce un resultado encriptado. Sí.
Totalmente distinto. Sí. Y acá, por
ejemplo, yo puse tres ejemplos. Ustedes
pueden buscar después ahí en en
internet, este, hay muchos eh eh sitios
que uno pone
algoritmo de hash MD5 y te permiten
escribir un una secuencia de caracteres
y y y generar el hash. Si ustedes eh
escriben este esta secuencia one ring to
rule de mold y está escrito en inglés,
pero bueno, este escriben estas tres
secuencias van a tener estos tres
resultados diferentes. Si se fijan,
este, entre la primera y la segunda hay
solo una letra de diferencia. Una dice
ring y otra dice ping. Sí, una R y una
P. Es la única diferencia entre las dos
primeras. Sí, a las dos se le aplicó el
mismo mecanismo de hash MD5. Y fíjense
el resultado. Las dos tienen la misma
longitud, ¿sí? Pero son totalmente
distintos los los cadena de caracteres
encriptada. ¿Sí? Entonces, cualquier
cosa que cambie en la secuencia original
me modifica totalmente este el
resultado. ¿Sí? Y el último ejemplo es
una secuencia mucho más corta, son
solamente dos palabras y también es
totalmente distinto a los a los
anteriores, pero de nuevo la longitud es
siempre la misma.
Perfecto.
Te interrumpo. Hay un comentario, tal
vez vale la pena leerlo.
Adelante.
MD5 es muy vulnerable. No está
contemplado usar una función de hash
como AS256.
¿Es una modificación del protocolo?
Pregunta.
Sí. A ver, el el el
mecanismo de de
en el caso de MD5 lo codifica en una en
una en una secuencia de, o sea, utiliza
una una encriptación de 128 bits,
digamos. Eh, el
MD5
es vulnerable,
pero no tan no tan rápidamente, digamos.
lo lo que lo que lo que importa acá este
en en en este caso es cuál es en
promedio el tiempo que se insume para
romper este eh en general utilizando un
mecanismo que se llama fuerza bruta para
romper el el el la codificación,
digamos, o sea, para que alguien este
lo logre revertir, digamos, ¿no? Esto es
irreversible, entonces si alguien lo
logra revertir, quiere decir que rompió
el el algoritmo de codificación. La
forma de de de romperlo en el caso de de
hash no es revirtiéndolo porque de nuevo
no es reversible, no es matemáticamente
reversible, digamos. Lo que se hace es
se empieza a generar secuencias de
caracteres y y a encriptar secuencias de
caracteres hasta que se obtiene la misma
cadena. Si yo encripto dos secuencias de
caracteres y obtengo la misma cadena,
quiere decir que las dos secuencias de
caracteres son iguales. ¿Sí? Entonces
empieza a probar encriptar este, pero
hay que tener una idea de qué es lo que
estoy encriptando para de la longitud
original del de la secuencia para para
poder este romperlo. Sí, es
relativamente vulnerable, pero en en
ahora vamos a ver cómo se utiliza y lo
importante acá es que en en los tiempos
en que se insume
eh eh para vulnerar esto, en realidad ya
como que el la información no es no es
importante, no es relevante. Entonces,
toda lación se basa en general en eso,
¿no? en que no en que sea infalible,
sino en que se demore muchísimo tiempo
en vulnerarla.
Normalmente la idea es que sea muchísimo
más tiempo que la utilidad de la
información. Sí, que yo quiero el tiempo
durante el cual yo quiero ocultar
información. No sé, para un para un como
mencionaron por ahí, para un mecanismo
de encriptación basado en SHA 256, el
promedio con las computadoras que hay
hoy en día, con la capacidad de cómputo
de hoy en día para para romper un una
encriptación de SHA 256
probablemente miles o millones de años,
digamos. Entonces, probablemente en
miles de años esa información ya no sea
útil, digamos. Y en eso se basa la la
encriptación. SHA1, por ejemplo, ya está
más que este roto el el el algoritmo,
entonces se demoran unos pocos minutos o
menos en romper una una codificación
SH1, pero por eso es que no se utiliza
más, digamos, ¿no? Por eso se recomienda
utilizar ese HA256 o algo todavía más
difícil de de vulnerar. Sí, de nuevo se
pueden utilizar otros mecanismos de hash
que no sean de 128 bits, que sean de más
de más resistentes, digamos, este, y sí,
cuanto más resistente es mejor. En
general, NCS utiliza eh MD5, pero no es
el único que utiliza. También utiliza
ención de clave pública y clave privada,
que es así. Este es muchísimo más
complicada de resolver. Utilizo una
combinación de las dos. Ahora vamos a
ver.
Sí.
Bien, muchas gracias por la pregunta.
Pues es es superinesante. Tampoco este
nos vamos a poner a ver en detalle cómo
funciona todo el tema de de encriptación
porque sería un poco un poco complicado.
No sé si responde la pregunta o si
alguien tiene alguna otra otra pregunta
o comentario adicional.
No, creo que se le habilitó el
micrófono.
Ahí está. Ya le pusimos.
Nico, sin querer queriendo te puse mute
a ti. Perdón.
Estás on te tienes que
habilitar tu micrófono. Yo lo puse sin
querer por
Ahí está. Ahora me escuchan.
Perdón, perdón. Ahora sí.
No pasa nada. Me está saboteando la la
prestación, Rodrigo, pero no pasa nada,
no hay problema. Cosas que pasan.
Así le damos un poco más de tono jocoso
a esto. Está perfecto. Bueno, entonces
así funciona el mecanismo de hash.
Guardemos eso en la memoria por un
momento y vamos a hablar un poco de esto
de encriptación este de clave pública.
Sí.
¿Cómo funciona la encriptación de clave
pública? ¿Qué es y cómo funciona?
cuando cuando hablamos de de
encriptación en general, eh podríamos
hacer esta esta distinción en dos
grandes grupos, ¿no? Lo que lo que
llamamos encriptación simétrica y lo que
llamamos encriptación asimétrica. Cuando
hablamos de encriptación simétrica, ¿sí?
Sin importar el mecanismo de
encriptación que utilicemos,
cuando es simétrica, las mismas
credenciales que se usan para encriptar
se usan para desencriptar. O sea, yo
encripto utilizando una clave, por
ejemplo, sí envío la información
encriptada a a alguien que quiero que la
pueda leer, que pueda visualizar o tener
la información de nuevo. O sea, lo que
lo que tiene que hacer esa esa persona
ese e el que recibe la información que
está encriptada es desencriptarla. Como
esa encriptación, como estamos hablando
encriptación simétrica, ¿sí? Lo que
necesita es la misma clave que yo usé
para encriptar. La misma clave con la
que encripto, desencripto. Por eso es
simétrico. Entonces, yo tengo que
comunicar la clave que usé para
encriptar. Sí, cualquiera que tenga la
clave puede encriptar y desencriptar
indistintamente. ¿Sí? Por otro lado, hay
otro tipo deción sería la inclinación
asimétrica. En lación asimétrica, en vez
de generar una única clave, se generan
dos claves. Sí, se pueden generar más.
No vamos a entrar en detalles, pero el
caso más simple de incripitación
asimétrica es con dos claves. ¿Sí?
Entonces, ¿qué sucede? Esas dos claves
que se generan, ¿sí? Una se utiliza para
encriptar y la otra se utiliza para
desencriptar. ¿Cuál uso para hacer qué?
No importa, cualquiera de las dos la
puedo utilizar para encriptar. Lo que lo
que lo que hay que siempre recordar es
que si estamos hablando de encriptación
asimétrica con un par de claves, si yo
elijo cualquiera de ellas y la utilizo
para encriptar, la única forma de
desencriptar es utilizando la otra.
Es decir, si utilizo la misma clave que
usé para encriptar, no puedo
desencriptar. Solo la puede desencriptar
la otra. No importa cuál de las dos
utilice. Lo que una encripta, solo la
otra lo desencripta. Así no más. Lo que
una encripta, solo la otra lo
desencripta. Okay. Bien. Por eso se
llama asimétrica.
¿Por qué se le llama a veces a esto en
critación de clave pública y clave
privada? Bueno, de esas dos claves que
se generan enitación asimétrica, a una
de ellas se le asigna el nombre de clave
privada. De nuevo, ¿a cuál? No importa,
cualquiera de las dos. Cualquiera de las
dos voy a decir, "Bueno, esta es la
clave privada. ¿Por qué se le llama
privada?" Porque la clave privada solo
la voy a conocer yo, quien quiero que
pueda encriptar. Y la clave privada solo
se va a utilizar para encriptar. En este
caso,
¿cómo hago para desencriptar las cosas
que encripto con la clave privada?
Necesito la otra clave. A la otra clave
se le llama clave pública. ¿Por qué se
le llama clave pública? Porque se le se
le da, sí, la tengo que suministrar a
todo aquel que quiero que pueda
desencriptar la información. Es decir,
encripto con la clave privada,
desencripto con la clave pública. La
clave privada la conozco solo yo, o sea,
que solo yo puedo encriptar. Y la clave
pública se la doy a todo el mundo, por
eso llama público. Así todos pueden
desencriptar lo que yo encripto. Y de
nuevo alguien acá se puede preguntar,
"Bueno, pero ¿por qué le darías la clave
pública a todo el mundo si lo que querés
es encriptar?" Si vos encriptas algo y
después le das la clave a todo el mundo,
cualquiera lo puedes encriptar.
Entonces, ¿qué sentido tiene encriptar?
Bueno, de nuevo, recordemos que la
utilización acá de de estos mecanismos
de encriptación no es para proveer
privacidad, no es para que no se pueda
acceder al contenido encriptado, sino
que es para generar lo que llamamos una
firma digital. Entonces, ahora vamos a
ver cómo utilizando este mecanismo,
combinando el hash con el mecanismo de
clave pública y clave privada utilizado
de esa manera, se obtiene una firma
digital. Sí. Y esto aplica a cualquier
firma digital, no solo a DNCS, digamos.
Sí. Entonces,
tengo un texto, ¿sí? Lo encripto con la
clave pública, obtengo el texto
encriptado. Sí, si yo desencripto ese
texto con la clave privada, ¿qué
obtengo? Obtengo el texto original. O
sea, que texto original, encripto con la
clave pública. Ahora está encriptado,
desencripto con la clave privada y
vuelvo a obtener el texto original. Acá
sí es reversible, solamente que es
reversible utilizando la otra clave que
no es la que se usó para encriptar. Una
enrita la otra es encrpita. Okay. Bien.
Vamos a ver entonces cómo se cómo se
construye una firma una firma una firma
digital y por qué es una firma digital
combinando hash con encriptación de
clave pública y clave privada.
El objetivo acá es firmar un texto,
igual que como firmamos un contrato,
igual que como firmamos un cheque.
Cuando yo firmo un cheque, ¿sí?, ¿qué es
lo que hace el el receptor, el banco que
recibe el cheque? Es verificar la firma,
¿verdad? Antes de de de pagar el cheque
o de hacer algo con ese cheque, tiene
que verificarse la firma. Sí, lo mismo
para un contrato. Yo firmo un contrato.
Antes de de revisar el contrato o ver la
valiz del contrato, hay que verificar la
firma. Entonces, ¿cómo se verifica una
firma caligráfica, digamos, una firma
escrita a mano? Bueno, una firma escrita
a mano, hay hay unas técnicas y hay eh
en Uruguay se le llaman peritos
calígrafos eh a las personas que
verifican eh firmas este caligráficas de
de de
manera de manera visual, digamos, este y
comparándola con con la firma con un
registro de firmas. Si. Entonces yo para
verificar una firma de una firma manual
de un cheque, bueno, tengo un registro
de firmas donde dice firmar a la
persona, no sé, cinco veces, ¿sí?
Entonces, cuando firma el cheque,
comparo la firma que está en el cheque
con ese registro. Sí. Y si hay
determinado tipo de coincidencias, este,
que yo desconozco porque no soy experto
en eso, este, bueno, la firma se da por
válida. Sí. Este, claro, una firma
caligráfica es bastante fácil, bastante
fácil o relativamente fácil de
falsificar.
Sí, porque, bueno, solo toca hacerla lo
más parecido posible y a a la a la a las
al registro de firmas como para que pase
la prueba y listo. Una firma digital ya
es si no se rompieron los algoritmos es
prácticamente imposible de falsificar,
digamos, ¿no? Entonces, ¿cómo funciona?
Tengo tengo el texto que quiero firmar.
Sí, lo primero que se le hace al texto,
como está acá, lo primero que se le hace
al texto es aplicarle el hash. Sí,
recuerden que cuando al texto le
aplicamos el hash utilizando, por
ejemplo, MD5, obtenemos esa cadena de
caracteres de longitud fija, pero que
cualquier cosa que cambie en el texto
original produce un hash totalmente
distinto. ¿Sí? ¿Por qué se aplica el
hash? Sí. y no directamente
generar la firma eh con el texto
original. Bueno, acá lo que lo que entra
en juego es
la longitud fija del resultado de hash.
Imagínense que ustedes tienen tres
palabras, le aplican un hash obtienen un
una secuencia de caracteres, no sé, de
de de 30 caracteres y después tienen un
texto de
10,000 páginas de texto, le aplican el
mismo hash. Obtienen una secuencia
totalmente distinta, pero también de 30
caracteres. Sí. Entonces, sin importar
el tamaño del texto original, el
resultado siempre es el mismo en
longitud.
Eso lo que me hace es que yo tenga
certeza del volumen de información que
voy a manejar. Porque si yo manejara
este texto original, ¿sí? No es lo mismo
tener que transferir dos o tres palabras
que tener que transferir un millón de
páginas. Transferir un millón de páginas
ocuparía muchísimo ancho de banda.
transferir dos o tres palabras ocuparía
muy poco. Entonces, el ancho de banda
dependería de la cantidad de información
que yo quiero transferir. Si yo le hago
el hash y lo que transfiero es el hash,
ya me separo, me olvido de la cantidad
de información que yo tengo
originalmente, porque lo que voy a
transferir es más o menos siempre lo
mismo, porque la longitud es siempre la
misma del resultado, ¿se entiende? Igual
va a ser una especie de huella digital
de lo original. ¿Por qué? Porque el hash
si cambia algo en el texto original
cambia totalmente la secuencia. Sí.
Entonces, con eso lo que se hace es se
acota el ancho de banda que se utiliza
para enviar la información de la firma,
¿está? Entonces, texto original que yo
quiero firmar, le aplico el hash y luego
encripto el hash con mi llave privada.
Sí. El resultado de encriptar el hash de
un texto con la llave privada es lo que
se llama firma digital de ese texto. Eso
es una firma digital. ¿Por qué es una
firma digital? Si yo encripté algo con
mi llave privada, ¿quién es el único que
lo puede desencriptar?
El que tenga la llave pública, ¿verdad?
Dijimos que la llave pública se la damos
a todo el mundo, entonces todo el mundo
lo puede desencriptar.
Entonces, el punto de vista de
encriptación no tiene mucho sentido
porque cualquiera puede abrir la
información. Pero des el punto de vista
de firma, fíjense lo siguiente. Si yo
tengo
algo que pude desencriptar
con la llave pública,
¿qué quiere decir respecto a
el el el texto original que yo encripté?
Bueno, quiere decir que si yo puedo
desencriptar algo con la llave pública,
¿sí? ¿Quién es el único que lo pudo
haber encriptado?
el que tiene la llave privada, porque la
llave pública solo desencripta lo que la
llave privada encriptó. Entonces, si yo
logro desencriptar algo, sí, el único
que pudo haberlo encriptado es el que
tiene la llave privada. Y eso es una
firma. ¿Por qué? Porque solamente yo
tengo la llave privada. Entonces, si
ustedes logran desencriptar algo que yo
envié, pueden estar seguros de que no es
falso, de que lo envié yo. Y yo tampoco
voy a poder decir, "No, yo no lo envié."
Sí lo enviaste vos, porque el único que
tiene la llave privada sos vos. y yo
acabo de desencriptar algo que vos
encriptaste, ¿se entiende? Entonces, por
eso es que el mecanismo de llave pública
y llave privada utilizado de esta manera
es un mecanismo para firmar digitalmente
algo, digamos. Sí, ¿qué es lo que
estamos firmando digitalmente acá? Lo
que estamos firmando digitalmente acá es
un hash porque estamos encriptando el
hash. ¿Okay? Entonces, ¿cómo se verifica
la firma digital del texto original? Si
yo encripté el hash Bueno, se hace de la
siguiente manera.
Yo lo que tengo que hacerle llegar al al
al al a la otra parte, digamos, es el
texto original. Lo que estoy
transfiriendo es un es información
firmada. Entonces, además de enviarle la
información, yo le voy a enviar la
firma. Y además de enviarle la firma,
¿qué necesito enviar? La clave pública
también. O sea, que el que recibe
necesita la información, obviamente, que
es lo que le interesa, la firma de esa
información y la clave pública, ¿no? Y
además conocer los algoritmos que se
utilizaron para para hacer el hash y
para encriptar. Si yo si yo tengo toda
esa información, si recibo toda esa
información, tengo por un lado el texto
original, que es lo que quiero, por otro
lado, la firma con la clave pública y
los algoritmos. Yo antes de mirar que
hay en el texto, lo que voy a hacer es
validar la firma, tratar de validar la
firma. Si la firma valida, perfecto. Si
la firma no valida, descarto todo,
porque quiere decir que algo falso. O la
firma es falsa, o el texto está
modificado o el texto es falso, hay algo
mal. Está. ¿Cómo verifico la firma?
Bueno, tengo la firma y la clave
pública.
Con la clave pública puedo desencriptar
la firma. ¿Qué obtengo? El hash.
Correcto. Tengo el hash. Ahora, el hash
que obtuve de desencriptar la firma. Por
otro lado, tengo el texto original. Le
aplico el hash al texto original porque
yo ese hash no es reversible, no puedo
deshacer el hash y comparar los textos
originales. Entonces, desencripto la
firma, tengo el hash. Agarro el texto
original, le aplico el hash y comparo
los dos hash. Si los dos hash coinciden,
son exactamente iguales, quiere decir
que esa firma corresponde a ese texto.
Si hay alguna diferencia entre los hash,
quiere decir que la firma es falsa, el
texto fue modificado o algo pasó, pero
definitivamente esa firma no corresponde
a ese texto. Si ese no fue el texto
firmado que corresponde a esta firma,
por lo cual descarto la información.
¿Sí? Entonces, de nuevo, ¿cómo se
verifica la firma digital? Se
desencripta la firma con la llave
pública, se obtiene un hash y se compara
con el hash del texto
y ahí si coinciden bien y si no descarto
la información. ¿Okay?
De de esta manera se se puede fácilmente
verificar una una firma una firma
digital y es el mecanismo de
verificación que utilizan casi todos los
mecanismos de firma de firma digital.
Sí. Por eso le decía hoy en día que
tampoco es tan crítico el tema de la
reversibilidad del hash. Si acá lo que
es crítico es que lo que lo que tiene
que ser bien sólido es el el el
mecanismo de encriptación de clave
pública y clave privada. Sí, el hash es
más que nada para no depender del tamaño
del texto original y enviar siempre
información con una longitud fija para
acotar el ancho de banda. Sí, pero
perfectamente podría olvidarme del
algoritmo de hash y encriptar
directamente el texto. Ahí desencripto
la firma y tengo el texto y comparo los
textos. Lo que pasa que también una cosa
es comparar 30 caracteres, un hash con
otro hash y otra cosa es comparar 10,000
páginas de texto con 10,000 páginas de
texto buscando a ver si hay alguna
diferencia. Demoro, en un caso demoro
unos pocos milisegundos o menos y en el
otro puedo demorar días comparando
página de texto, digamos, aunque sea en
forma computacional, digamos. Entonces,
esa es la razón por la que se se
comparan y se se utilizan los hash y no
directamente eh los textos tal cual
están, digamos. Pero no es el la
finalidad no es solo no es meramente la
de encriptar, eso es lo de menos,
digamos. O sea, que el hecho de que se
vulnere, incluso si se vulnerara, si se
rompiera totalmente y fuera bien fácil
revertir un el MD5 en este caso, la
firma sería totalmente seguiría siendo
totalmente válida porque de nuevo es un
mecanismo para acotar el ancho de banda
y no para para proteger información.
Está. Lo que protege la información es
el algoritmo que que genera la firma,
que es la encriptación con la con la
clave pública y clave privada. ¿Sí?
Bien.
¿Qué tiene que ver todo esto con el DNS
y cómo se aplica a DNSC? Sí. Bien.
Entonces, ¿cómo cómo se aplica ADNCSC?
Bueno, dijimos que eh esto opera en el
diálogo entre servidor recursivo y los
servidores autoritativos. Cuando el
servidor recursivo empieza a consultar
los servidores autoritativos para
obtener la respuesta. Entonces cada vez
que un servidor autoritativo le envía
una respuesta al servidor recursivo,
cuando yo no tengo DNCs, va, viene la
respuesta. El servidor recursivo no
tiene otra opción que confiar en lo que
le llegó. Si lo que le llegó está mal,
chao, perdimos. Si alguien lo modificó,
si alguien logró acceder al servidor
autoritativo y modificar la información
el servidor autoritativo, si hizo un
ataque de lo que se llama persona en el
medio, digamos, de de interceptar la
información, modificarla, cosa de que lo
que sale del servidor autoritativo es
diferente a lo que llega al servidor
recursivo, cualquier tipo de de ataque.
Si yo no tengo un mecanismo de
verificación de la información, no tengo
DNCS implementado, el el servidor
recursivo va a confiar en la
información. Si la información es falsa,
va a dar información falsa. Si tengo
DNCS implementado, cuando el servidor
autoritativo envía la información al
servidor recursivo, además, ¿qué le va a
hacer? Le va a enviar la firma de esa
información. O sea, DNCSC no es otra
cosa que firmar la información
a nivel de servidor autoritativo para
enviar la información firmada al
servidor recursivo. Entonces, ahora el
servidor recursivo, ¿sí? Si el servidor
autoditativo tiene DNCS implementado,
envía la información al servidor
recursivo, le envía la firma al servidor
recursivo, le envía la clave pública al
servidor recursivo y le dice cuáles son
los algoritmos que utilizó para el hash
y para encryptar. Ya. Entonces ahora
tengo la información igual que como
tenía sin DNSC sumado a
la firma, la clave pública y los datos
de los algoritmos utilizados. Sí, el
servidor recursivo recibe todo eso. ¿Qué
hace? Tiene la información y tiene la
firma y tiene la clave pública. Agarra
la clave pública, desencrita la firma,
tiene el hash. Agarra la información, le
aplica el hash y compara los dos hash.
Si los dos hash coinciden, perfecto, la
información viene de quien dice, de
quien tiene la autoridad para esa
información. Y además no hay forma de
que haya sido modificada en el medio,
porque si alguien cambia la información
la firma no va a verificar. Sí.
Entonces, el servidor recursivo tiene un
mecanismo para verificar esa firma eh
digital que generó y envió el servidor
autoritativo. Esa esa acción de
verificar una firma digital por parte
del servidor recursivo se llama
validación. Validación de DNSC. La
validación de DNSC ocurre a nivel de
servidor recursivo.
La firma de la información ocurre en los
servidores autoritativos. Entonces, para
que DS funciona es una tarea de dos. A
nivel de servidor autoritativo, cada
registro que yo tenía en mi archivo de
zona, cuando yo despiego de NSSC, lo voy
a firmar y va a quedar firmado, o sea,
va a haber una firma para cada uno de
los registros que yo tenía en el archivo
de Sony
del lado del servidor recursivo, hay que
habilitar validación de NCSC de forma
que el servidor recursivo cuando recibe
la información, la firma, la clave
pública y los datos pueda verificar esa
firma. Sí, tiene que ser una cosa de de
los dos lados. Sí, de nuevo, servidor
autoritativo, firmar los registros.
Servidores recursivos, habilitar
validación. Por supuesto que la
habilitación de la validación y la
acción de validación es muchísimo más
simple que mantener un esquema de firmas
y administrar un servidor autoritativo
con DNCS. No es superclicado administrar
un servidor autoritativo con TSC, pero
sí es más complejo, bastante más
complejo que solamente habilitar
validación a nivel de servidor
recursivo. Sí. Eh, bien,
preguntas hasta acá, comentarios.
Nos está faltando un pedacito que es el
más complicado de todos. Entonces, ahora
ajústense los cinturones porque va a ser
un poquito movido esto. Eh, hay una
pregunta, Yuri. Sí, adelante.
Hola, buen día. Eh, Nicolás,
en este caso, eh, para la región, los
servidores autoritativos ya lo tienen
implementado o están en un proceso en
esto?
Muy buena pregunta. Eh, los eso depende,
obviamente depende de los
administradores de los autoritativos que
tengan o no firmados sus registros. Sí,
a veces se dice firmar la zona. En
realidad lo que se firma no es la zona,
lo que se firma es cada registro que
está dentro de la zona. O sea, hay una
firma para cada uno de los registros que
están dentro de la zona. No es una única
firma para todo. Eso depende del
administrador de de de la zona. Hay DSSC
todavía todavía hay un largo camino por
recorrer para que esté ampliamente este
desplegado, digamos. Sí. Si bien uno
dice, "Ah, pero me dijiste que desde el
2010 está funcionando, hace 15 años que
está operando y todavía falta mucho para
que todo esté todo tenga todos los
servidores de NS tengan desplegado en
SE." Sí, falta bastante, digamos. Por
eso hacemos estos estos esfuerzos. Eh,
si lo comparamos con el despliegue IP
versión 6, por ejemplo, no tiene nada
que ver con el DNS, pero pero también
este IP versión 6 tiene no tiene 15,
tiene 30 años eh operando y y y todavía
falta muchísimo para que todas las redes
soporten IP versión 6, ¿no? Este porque
todo en internet, todos los cambios este
son lentos, digamos, ¿no? En general,
este, por desgracia, mucha gente
reacciona, digamos, implementa estas
cosas después de que le pasa algo malo,
digamos, en el caso de NCSC, después de
que reciben y son objetos de algún tipo
de ataque que DNCS resuelve, dicen, "Uy,
está, sí, deberíamos este implementar
DNCs, sí deberías haberlo implementado
antes para prevenir el ataque, pero
bueno, nada, si sirve este si sirve de
incentivo el el el justamente ser objeto
de de alguna vulnerabilidad y por eso
reaccionar, implementarlo, fantástico,
digamos. Sí, lo que sucede en la
realidad es que muchas organizaciones no
visualizan eh correctamente las ventajas
de implementar estas cosas, digamos,
porque tienen costos operativos, porque
hay que formar a la gente, capacitar a
la gente. Si estoy firmando este un
servidor autoritativo,
tengo que administrar clave pública y
clave privada, tengo que tener un
mecanismo para mantener secreta y segura
la clave privada, tengo que mantener un
mecanismo para para utilizarla y firmar
cada cada vez que hay un cambio en la en
la zona. Todo eso es automatizable. Hoy
en día existe montones de software que
lo hacen totalmente automatizado,
digamos. Sí. Este, pero bueno, de nuevo,
muchas organizaciones no visualizan las
ventajas de de de tenerlo. Es como el
seguro médico, ¿no? Dice, "Bueno, ¿para
qué voy a pagar miles de pesos todos los
meses para toda mi familia por un seguro
médico que utilizo una vez por año, no?"
Y bueno, pero el seguro médico en
realidad no es la forma de evaluar un
seguro médico, a mi criterio, no es cada
cuánto lo utilizo, es lo mejor que te
puede pasar es pagar miles de pesos por
un seguro médico y no utilizarlo nunca
en tu vida, digamos, ¿no? Pero el día
que lo tengas que utilizar, si no lo
tenés,
ahí estamos en problema. Esto es igual.
La seguridad en general es igual. Es
decir, uno hace una inversión y lo mejor
que le puede pasar es que nunca pase
nada. Sí, pero no es un no es tirar
dinero, no es un gasto, es una
inversión. porque uno está invirtiendo
en justamente en si alguna vez me pasa
algo, bueno, tengo este mecanismo que lo
va a mitigar o me lo va a evitar,
digamos. Entonces, y además es muy
difícil medir lo los ataques que uno
dejó de de tener porque tenía las
medidas de seguridad, ¿no? Es decir,
¿cuántos ataques evitó el firewall que
tenés instalado en tu organización? No
lo sé. Yo puedo medir más o menos los
ataques que son grandes y puedo decir,
"Bueno, este firewall eh retuvo mitigó
este, no sé, 10 ataques en el último
mes. En realidad no mitigó 10. Si te
detectó 10, mitigó 5,000 ataques.
Entonces, si vos no lo tenés, justamente
lo que estás dejando de es mitigar, está
dejando de mitigar 5,000 ataques y si lo
tenés, de repente solamente reconocés 10
de esos 5,000. No, esto es igual.
Entonces, de nuevo, el esfuerzo que
hacemos es justamente tratar de generar
esta esta conciencia de, bueno, esto en
realidad el es preventivo, es justamente
es el el el
digamos si vos sos objeto de un ataque y
tu servicio de DNS deja de funcionar, es
muy probable que todos tus servicios
digitales o todos tus servicios en
internet dejen de funcionar. Entonces,
el lucro cesante que tenés, el impacto
sobre la imagen que tenés, ¿no? Si sos
un banco y te atacan y te ganan acceso a
todas las cuentas porque alguien te
secuestró un servidor de NS o te logró
meter información falsa y la gente fue a
un servidor de un atacante pensando que
era el servidor del banco y le reveló
las credenciales para acceder a la
cuenta bancaria y después el atacante le
vació la cuenta bancaria a dos personas
de 1 millón de personas de un banco. el
banco pierde
un montón de de de dinero que no es
fácil de medir, digamos, porque la
pérdida de imagen no es fácil de medir.
Sí. Entonces, de nuevo, a veces es
difícil de visualizar, pero bueno, está
en nosotros el en los técnicos, digamos,
el transmitir a las jerarquías, este,
¿por qué es necesario desplegar esto?
¿Por qué es necesario capacitarse? Y por
qué es necesario invertir en estas
medidas de seguridad, digamos. Sí.
Entonces,
eh un poco un poco viene viene por por
por por ese lado. Sí, todavía hay un
largo camino por recor para que tengan
una idea, el el dominio
comom, el GTLD, el dominio de primer
nivel com es el el dominio por lejos que
tiene más subdominios en todo en todo el
sistema de nombre de dominio. El COM es
el que tiene más su dominio, o sea, la
mayoría, dicho de otra manera, la
mayoría de los nombres de dominio
terminan en punto comom. Sí,
solamente un cco menos de un 5%
de los servidores de NS eh de segundo
nivel por debajo del del COM este tienen
su registro firmado, o sea, tienen
desplegado DNSC. dicho de otra manera, o
sea, el COM sí soporta DSC, pero por
abajo del punto comom, los dominios, no
sé, nicolas.com o lo que sea, comom,
solamente un 5% de todos esos, menos un
5% realmente más cerca del 4,5%
hoy en día está con DNS SEC desplegado y
ese es el que tiene más subdominio.
Imagínense que falta todavía un un un
largo camino por recorrer, pero
desde otro de lado positivo, por
ejemplo, en el caso de Latinoamérica y
el Caribe, sí hay un montón de eh de de
CCTDs, de nombres de dominios de de
primer nivel asociados a código de país
que ya soportan DNS, digamos. Sí. Este,
eso quiere decir que cualquiera que
registre un dominio por abajo del
dominio de código de país ya puede
implementar en ese seco. Sí, porque
ahora vamos a ver justamente esto que
está faltando ver ahora es lo que no lo
que nos va a decir que para que un
administrador, un servidor de nombres de
dominio autoritativo pueda desplegar de
NCSC, toda la cadena que está por encima
hasta la raíz tiene que tener desplegado
de NCS. O sea, si si si mi padre o madre
no tiene el DNS no tiene desplegado DSC,
yo no puedo desplegar DNSC. Sí, la raíz
tiene implementado DNSC desde el año
2010, que fue cuando empezó el
protocolo, cuando se implementó por
primera vez el protocolo en el año 2010.
los este
los eh
nombres de dominios genéricos de primer
nivel, el COM, el ORG, el EDU, todos los
de primer nivel genéricos, eh tienen
obligación contractual por el contrato
que tienen con ICAN de desplegar DNC, o
sea, que todos tienen DNCSC
implementado, todos soportan DNSC, los
de código de país no tienen obligaciones
contractuales. Entonces, bueno, hay
muchos de ellos que lo tienen
implementado, otros que todavía no
tienen implementado DCSC deberían
implementarlo. Eso es algo que que
ustedes como
parte de de las organizaciones del
Estado, digamos, pueden incentivar
decir, bueno, el el el
en el caso de Chile eh ya está
desplegado a nivel del punto cl, pero no
es el caso de todos los países de
Latinoamérica y del Caribe. Entonces,
bueno, ahí este la la las los usuarios y
también los gobiernos pueden invitar a
justamente a tener desplegado DNC en el
en el en el dominio de de código de
país, porque si no, por ejemplo, un
dominio, no sé, ehgob.cl
no puede eh desplegar DNSC hasta que CL
no tenga desplegado DC. De nuevo, Chile
es un caso particular porque el los
administradores del punto CL te lo hacen
muy bien y es uno de los pioneros en
muchas cosas en nuestra región. O sea,
que no es un ejemplo bueno para poner
ejemplos malos, digamos, sino que todo
lo contrario. Pero sí hay muchos países
que no son este buen ejemplo y que ni
siquiera tienen desplegado todavía de
NCS en su en su en su dominio de nivel
superior asociado al código país. Está
un poco por ahí va la respuesta. resumen
de nuevo, todavía hay un largo camino
por recorrer, pero bueno, justamente es
importante visualizar la necesidad de
que de que todos desplieguen este de
NSC, porque además este hay como un
temor ahí, sobre todo la parte de
administrar este de NCS a nivel de un
servidor autoativo
y y
el 99% de los errores como consecuencia
de desplegar de sex son humanos. son por
procedimientos mal hechos, mal escritos
o no o carente procedimiento. Por
ejemplo, despliego de NCSC, pero no
escribo bien los procedimientos para
hacer la operación de eso. Entonces,
cuando uno no escribe los procedimientos
y tiene un grupo de operaciones que
tiene muchas personas, bueno, ahí es
fácil que uno conozca todo bien, pero
que el otro no tenga ni idea de lo que
estoy hablando. Entonces, con una mala
operación o con una mala este respuesta
o procedimiento
se puede cometer un error. La mayoría de
los problemas con DC son consecuencia de
errores humanos y no de fallas de
protocolo, ni siquiera fallas de
hardware ni de software. Es la mayoría
son problemas humanos, errores de
operación. Sí. Eh, porque es fácil
cometer error de operación cuando uno no
tiene las cosas bien procedimentadas.
Sí, aunque parezca mentira. y ocurren a
todos los niveles. No importa si estamos
hablando de una organización pequeña o
de una organización monstruosamente
grande. Hay ejemplos, muchísimos
ejemplos de todos los casos, digamos.
Sí. Bien, ¿qué es lo que está faltando
todo esto? Cuando el servidor
autoritativo envía al servidor recursivo
la respuesta de de DNS firmada, le envía
la clave pública, dijimos, envía todo y
el servidor recursivo puede agarrar y
verificar esa firma. Lo que no estamos
diciendo acá es, bueno, si el servidor
autoritativo le envía la clave pública
con la información y la firma, hay un
problema, ¿no? Porque alguien podría
preguntarse,
¿qué pasa si un atacante captura la
información, la modifica,
modifica también la firma, genera una
firma nueva con una clave privada de él
y pone su clave pública ahí? Al servidor
recursivo le va a llegar la información
modificada, le va a llegar la firma
modificada que valida con esa
información porque la clave pública que
puso el atacante es la de él, o sea, que
le llega todo y va a validar todo y el
servidor va a decir, "Ah, esto valida,
perfecto." Y era todo falso. Entonces,
no sirve para nada todo lo que dijimos,
¿no? ¿Por qué? Porque
acá el problema se reduce a que el
servidor recursivo antes de realizar la
validación de la firma tiene que estar
seguro que la clave pública es la
correcta, que la clave pública no fue
modificada, que la clave pública es la
clave pública que envió
en la autoridad para esa información.
¿Cómo se hace la verificación de la
clave pública? La verificación de la
clave pública la tiene que hacer de
nuevo el servidor recursivo antes de
validar la firma. Entonces, el video
recursivo recibe todo. Recibe la
información, la firma, la clave pública.
Antes de validar, antes de hacer el
procedimiento que que dijimos para
verificar la firma, va a agarrar la
clave pública y le va a preguntar al
padre del dominio que del cual recibió
la respuesta. O sea, si el servidor
autoritativo que me está enviando la
información firmada es el servidor
autoritativo de nicolas.com,
¿sí? El servidor recursivo le va a ir a
preguntar al padre nicolas.com. ¿Quién
es el padre deenicolas.com? El puncom,
¿verdad? El servidor recursivo a
preguntar al padre nicolas.com,
¿esta clave pública que me mandó tu hijo
es la correcta o o está modificada?
¿Qué hace el padre? El padre le va a
contestar, básicamente le va a contestar
sí o no y va a firmar la respuesta con
su clave privada.
Entonces, ahora tengo el padre me envía
la respuesta diciéndome, "Sí, esa firma
es válida, es la de es la de es la de
nicolas.com, la de mi hijo, pero y no y
además te la firmo con mi con mi firma
electrónica, te mando la respuesta
firmada."
Está. Entonces, ahora el servidor
recursivo recibe una respuesta del
padre, ¿sí? Que está firmada por el
padre que dice que la firma de del la
clave pública del hijo es correcta.
Pero, ¿cuál es el problema ahora? El
problema es que tengo que confiar en la
firma del padre. ¿Cómo sé que no
falsificaron también la firma del padre?
Sí. Y empieza como una especie de de de
cascada o reacción en cadena, digamos,
en la cual ahora el servidor recursivo
tiene que ir al padre del padre y
preguntarle lo mismo. La clave pública
del de tu hijo es la correcta. Sí. Y acá
va firmada. Entonces sube un nivel más.
Y así sube hasta dónde? Hasta que
lleggaue a la raíz. Cuando el servidor
recursivo llega a la raíz, le va a
preguntar la raíz, ¿la firma de del del
punto comom es válida? La raíz le va a
decir sí es válida y la firma
con la clave privada de la raíz. Y ahora
recibo una respuesta de la raíz con la
clave pública de la raíz y tengo un
problema porque cómo verifico la clave
pública de la raíz si la raíz no tiene
padre.
Sí. Entonces voy recorriendo eso, esa
cadena hasta llegar a la raíz. Sí,
recibiendo respuestas firmadas y
validando con los padres las claves
públicas hasta que llego a la raíz.
Eso se llama cadena de confianza, ¿sí?
de de DNCS. Entonces, ahora todo el
problema se reduce a estar seguro que la
clave pública de la raíz es la correcta,
porque la raíz no tiene padre, no tengo
a quien preguntarle. Sí, para eso no lo
vamos a ver hoy. Para eso se diseñó un
protocolo que se llama protocolo de
firma de la raíz TDNS, ¿sí? En el cual
la clave pública asociada a la firma de
la raíz de DNS, ¿sí?, que se generó por
primera vez en el año 2010. La clave
pública
se disponibiliza a toda la comunidad de
internet a través de unos de unos
servicios, unos servidores especificados
para eso. Sí, las todas las ceremonias
de firma de la raíz eh se se filman y se
hace streaming de eso en tiempo real. O
sea, que cualquiera puede este atender
remotamente esas ceremonias. También hay
lo que se llaman testigos de la
comunidad que asisten a esa ceremonia de
firma de la raíz, ¿sí?, que se realizan
este cuatro veces al año. Este cuatro
veces al año se se realizan esas esas
ceremonias para para firmar la la
raíz de del DNS. Y
la clave pública en realidad no se
modifica en esa ceremonia. La clave
pública es siempre la misma. Se publica
y lo que uno debería hacer cuando
instala un servidor este recursivo por
primera vez, ¿sí? el servidor recursivo,
eh, cuando cuando uno lo lo pone en
funcionamiento, digamos, sí, va a
acceder a estos servidores y se va a
descargar la clave pública de la raíz de
DNS, ya esa clave pública de la raíz D
que se que se descarga el servidor
recursivo, hay que verificarla una sola
vez. En realidad, lo mínimo es una sola
vez cuando se instala el servidor. ¿Por
qué hay que verificarla? Porque si justo
alguien logró hacer un ataque en ese
momento y logró inyectarme una firma
falsa de la raíz de DNS, todo el
protocolo de NSC para mí está vulnerado.
¿Sí? Entonces es crítico que la firma,
la clave pública de la raíz de DNS que
tiene almacenada el servidor recursivo
en su memoria sea la correcta. ¿Cómo se
hace eso? El administrador cuando
instala un servidor recursivo y lo pone
en operación agarra la clave pública que
que obtuvo de de de la raíz del DNS. y
la compara con la clave pública que está
publicada en en varios lugares, digamos.
Sí, comparas la clave. Si la clave
coincide, está puedes estar tranquilo de
que es la correcta y de ahí en más el
sistema va a funcionar en forma
automatizada y no hay que realizar
ningún ningún ningún chequeo adicional.
O sea, que por lo menos una vez cuando
se pone en funcionamiento por primera
vez el servidor recursivo, hay que
verificar que la clave pública sea la
correcta, ¿sí? Para la raíz de DNS.
Luego de ahí, como la clave pública para
RNC ya está verificada manualmente,
todo el resto de la cadena de confianza
este está asegurada, digamos. Sí.
Entonces, la cadena de confianza de DNS
es justamente lo que garantiza
la este la la
veracidad de la clave pública que recibo
de cada uno de los servidores
autoritativos.
Bien.
Entonces, básicamente, ¿cómo se
implementa todo esto? Bueno, eh lo que
se hace, lo que se hizo cuando se diseñó
el protocolo de NSC es se le agregaron a
el protocolo de NSSC se agregaron
registros de NS, se crearon básicamente
tres nuevos registros de DNS, ¿sí? Para
poder implementar DNS. Lo que dijimos es
que los servidores autoritativos tienen
que enviar al servidor recursivo la
información como enviaban siempre.
Tienen que poder enviar la firma, tienen
que poder enviar la clave pública, ¿sí?
Y tienen que poder realizar esta este
chequeo de cadena de confianza. está.
Entonces, la firma está asociada a cada
registro. O sea, que para cada registro
tiene que haber una firma. ¿Sí? ¿Cómo se
coloca la firma en el archivo de zona
asociada a cada registro? Bueno, se
coloca en un registro nuevo que se crea
cuando se crea DNSC que se llama
registro RR SIG. El registro RR SIG es
el registro que se utiliza para
almacenar la firma digital de cualquier
otro registro de DNS. Entonces, cuando
se firma, cuando se implementa DNSC, que
es un servidor autoritativo, a cada uno
de los registros DNS que yo tengo en la
zona, se le asocia un registro RRSI
y en ese registro RSI se coloca la firma
de cada uno de esos registros. Esa es la
forma de colocar la firma para cada
registro en el DNS. ¿Okay? Entonces,
registro de RSI es un registro nuevo que
agrega DNSC para poder almacenar las
firmas.
Otro registro, el registro DNS Qy. El
registro DNS Q es el registro que se
crea para almacenar en el archivo de
zona la clave pública.
Dijimos que cada vez que se envíe una
respuesta hay que enviar también la
clave pública. La clave pública se
almacena en el archivo de zona en el
registro de NSX y por lo menos tiene que
haber un registro de NSX por todo para
cada archivo de zona. Este no es un
registro para cada registro DNS que
tenga mi archivo de zona, es uno solo
para todo el archivo de zona. Mínimo un
registro DNSX aquí con un la clave
pública para todo el archivo de zona.
Ya. Y por último está el registro DS. El
registro DS es el que se llama registro
de delegación y es justamente un
registro que no se almacena en el
archivo de zona que estoy implementando
de NSC, sino que es un registro que se
crea en el padre. Este registro DS es el
registro que se crea en el padre con la
clave pública del hijo firmada por el
padre y es el registro que consulta el
servidor recursivo y que va consultando
cada registro de S en secuencia hasta
llegar a la raíz. ¿Sí? Entonces, el
registro DS se utiliza para eso, para
asegurar la cadena de confianza de la
clave pública. El registro DNSQ se
utiliza para almacenar la clave pública
y el registro RRSI para almacenar la
firma. Y hay un registro RRS para cada
registro DNS que yo tenga en mi archivo
de SU. Con esos tres nuevos registros es
que se implementa DNSC en un servidor
recursivo, en un servidor autoativo,
perdón. Sí. Y en el servidor recursivo
simplemente hay que habilitar validación
de NCS. Y bueno, así es como funciona y
implementa este DNSC. preguntas hasta
acá,
¿no?
Bien, todavía nos quedan unos minutos y
les quería mostrar si no hay preguntas o
comentarios. Rodrigo, no sé si hay
alguna pregunta o comentario en el en el
chat.
Bien, supongo que no. Quería mostrarles
algunas estadísticas que tengo que que
les puse acá para Chile. Este este sitio
eh que está aquí abajo está
stats.labs.net.
E épnica es el registro de de
direcciones para para la región de de
Asia del Pacífico. Es el par de LNIC.
LCNIC es el registro de direcciones este
para Latinoamérica del Caribe, o sea,
cualquier organización que requiera
direcciones IP o número de sistema
autónomo se los va a solicitar a este
registro regional. eh estos registros
regionales que son cinco en el mundo,
este, básicamente también hacen otras
actividades de de de investigación y
desarrollo y generan herramientas para
la para la comunidad de operadores de de
internet, etcétera, etcétera. Sí, en
particular esto es una herramienta que
que generó que diseñó la gente de de
ApNIC para visualizar y llevar una
estadística sobre el nivel de despliegue
global de validación de NCS a nivel de
servidores recursivos. Sí. No a nivel de
servidores autoritativos. No es cuántos
servidores autoritativos tienen sus
zonas firmadas y con DNC desplegado,
sino cuántos servidores recursivos
tienen habilitado validación. O sea,
¿cuántos servidores recursivos de todos
los que hay son capaces de validar una
firma de NSC? ¿Sí?
Y uno puede navegar este mapa. Si se
fijan, si yo acá me paré arriba de Chile
y básica este esta foto la tomé hoy, o
sea, que hoy en día según esta
estadística solamente el 8% de las
consultas DNS que resuelven los
servidores recursivos que están ubicados
en las distintas organizaciones que
administran servidores recursivos en
Chile, solamente el 8% de esas consultas
que que resuelven los servidores
recursivos están validadas con DNSC.
¿Sí? O sea, prácticamente no hay
validación de NCSC en Chile. Sí,
un 8% es casi nada, prácticamente cero.
Sí. Y acá acá hay una lista que también
se se puede se puede ir navegando a
través de este sitio. Si uno pincha
arriba del país, obtiene más información
más detallada. Esto es un un una gráfica
estadística del 2014 al 2025, digamos,
de cómo se fue cómo fue variando el
despliegue de validación de NCSC en el
país. Si se fijan, básicamente se
mantuvo casi casi que plano este desde
el 2014. Incluso en algunos casos se ve
que había alguien que estaba haciendo
validación y dejó de hacerla, digamos.
Eh, este y y y se puede también navegar
más abajo y tienen una lista. Yo acá
saqué una foto parcial de toda la lista
de unas una una estadística que se hace
haciendo unas pruebas con los diferentes
operadores en el país. Si se fijan acá
la última columna que dice número de
muestras, samples, ¿sí? Yo lo ordené de
mayor a menor. Cuanto más muestras
tiene, quiere decir eso está
directamente vinculado con la cuota de
mercado. Es decir, cuanto más grande es
el operador, cuanto más clientes tiene
un operador en un país, más muestras se
obtienen. ¿Sí? Entonces, en este caso,
aparentemente, Telefónica Chile es el
operador más grande de Chile en cantidad
de clientes, digamos. Sí. Después le
sigue Chile, después le sigue BTR, banda
ancha y otros. Sí. Y si se fijan acá en
la primer columna que dice DNCS
validates, ¿sí? ¿Cuántas de esas
consultas que se utilizaron a modo de
testing, ¿sí? de 23,225
muestras, ¿sí?
Solamente el 1%
está validado con NCC. Cuando dice 1%,
cuando dice 2%, cuando dice 10%, es lo
mismo que no tener validación activado,
está es como si fuera cero. Esto, ¿qué
quiere decir? que
los prácticamente los 1 2 3 4
5 6 los seis primeros los seis este
operadores más grandes que que nuclean a
más del 99% de todos los clientes eh de
con acceso a internet en Chile no tiene
no utiliza un servidor recursivo que
tenga DNSCS validación de NCS que
habilitado. Entonces acá aunque todos
los servidores autoritativos tuvieran
DNSC implementado, aunque ustedes a
nivel de gobierno implementen DNSC en
todos los servidores, como los
servidores recursivos no hacen
validación, nadie está validando DSC.
¿Sí? Entonces es importante justamente
trabajar con estos operadores para que
implementen validación de NSC, para que
activen validación de NSC en sus
servidores recursivos. La razón por la
que a veces se ven números diferentes a
cero, este 4% 1% puede ser porque
algunos clientes de esos operadores en
vez de utilizar el servidor recursivo
del operador utilizan algún servidor
recursivo público que tiene habilitado
validación. Entonces, hay unos
porcentajes pequeños de validación, pero
ya les digo, con valores menores al yo
diría al 15 o 20%
este eh eso quiere decir que no están
que no tienen validación encendida en
ninguno de sus servidores este eh
recursivos. Algunos operadores, en
algunos casos sucede que son operadores
de móvil y de y de fija, internet fija
internet móvil y para para uno de los
utilizan por algún motivo diferentes eh
servidores recursivos de DNS para
resolver consultas de DNS y algunos ha
pas se ven casos, por ejemplo, de
operadores que tienen para los servicios
eh móviles habilitado de NSC y para los
servicios fijos no habilitado de NSC,
validación de NSC, ¿no? Este es curioso
eso y y tiene muchas puede tener muchas
explicaciones. Si ustedes instalan hoy
cualquier servidor de todos los sabores
de servidores de todos los servidores
recursivos BNS que ustedes pueden
utilizar, cualquiera que ustedes
instalen hoy, por defecto tiene
encendido validación de NC, o sea, usted
no tienen que hacer nada, instalan el
servidor y ya empieza a validar con DCS.
Es más, si no quieren validar NC, tienen
que a propósito deshabilitarlo. O sea,
cualquiera que hoy en día sin conocer de
NSC instale un servidor recursivo o bien
instalado un servidor recursivo en los
últimos 7 8 años, tiene validación de
NSC automática por defecto. ¿Sí?
¿Por qué todavía hay muchos servidores
recursivos que no tienen validación de
SEC? Y bueno, porque originalmente
cuando empezaron con esto de los
servidores recursivos no tenían DNC
habilitado, han ido, muchos de ellos han
ido actualizando, tienen sus servidores
actualizados, pero si uno lo tenía
deshabilitado, cuando uno actualiza la
versión del servidor, eso no se activa
solo, hay que activarlo manualmente,
digamos. Entonces, y otros eligen
tenerlo por algún motivo que desconozco,
eligen tenerlo este desactivado,
digamos, sí que pueden ser motivos
fundados, digamos, este, pero en
realidad hoy a nivel de servidor
recursivo,
eh la la la
potencialidad de problemas que pueden
aparecer por tener habilitado este
validación de NC es casi cero, digamos,
y el costo operativo de implementar
validación de NSC es muy muy bajo,
digamos. Sí. Y el la prevención de de de
ataques es bastante alta porque, por
ejemplo, todos esos ataques de eh
envenenamiento de calé, todos los
ataques
de, por ejemplo, todos los fishing esos
que que pretenden que uno cambie su su
contraseña del banco y y termina uno
accediendo a un servidor que no es el
original del banco, sino que es el
servidor de de un atacante, etcétera,
etcétera. Todo eso se puede prevenir si
está correctamente desplegado de NS SEC.
Entonces, la la la seguridad adicional
que provee DSC es supera enorme
enormemente los los costos operativos. Y
ya les digo, a nivel de validación el
costo operativo es muy bajo. A nivel de
despliegue de NCC, que en un servidor
autoritativo ya tiene un costo operativo
un poquito más alto, pero tampoco es
algo imposible, digamos, ni mucho menos.
es bueno capacitar al personal que lo
opera como como en todos los casos como
para cualquier operación de cualquier
sistema y y luego de este planificar el
despliegue, desplegarlo y después
mantenerlo operativo. Por supuesto que
no es poner las cosas al funcionario
olvidarse, hay que hacer monitoreo, pero
tampoco es exclusivo de DNS. monitoreo
hay que hacer de cualquier sistema que
uno esté operando. Hay que hay que hay
que hacer análisis de seguridad cada
tanto, pero eso también nada nuevo ni
nada que sea exclusivo de DNS ni de
DNSC. Es algo que hay que hacer con
todos los con todos los sistemas. Sí. Y
bueno, hasta acá un poco ahí les dejo un
una unas direcciones que pueden pueden
probar. Este, ustedes escriben, abren un
navegador, escriben cualquiera de estas
dos y lo que hace es hace una prueba a
ver si el servidor recursivo que ustedes
están utilizando tiene habilitado o no
validación de NSC. Y si lo prueban ahora
se van a sorprender, o sea, apuesta que
el 90% de de de de ustedes va a obtener
una respuesta negativa, que les va a
decir, "No, no tienen habilitado
validación. El servidor recursivo que
están utilizando no tiene habilitados
validación de NSC, a menos que justo
todos estén en la oficina y toda la red
de de la oficina este tenga justo el
servidor recursivo que que tiene que
tiene validación.
Este, es probable que desde sus casas,
es casi seguro, según estas estadísticas
que están acá, si tienen alguno de estos
proveedores, es casi seguro que no que
no estén validando validando DNS
con el servidor recursivo que están
utilizando. Sí. Bueno, un poco hasta acá
la presentación. Espero que que les haya
servido por lo menos para para entender
de qué se trata y cómo funciona de NCSC,
digamos. Este es una presentación un
poco de alto nivel, pero tampoco tampoco
está pensada solamente para para
exclusiva para técnicos. Entonces, la
idea es un poco que que todos, sin
importar técnicos o no técnicos, este
comprendan cómo funciona el protocolo y
bueno, y sean eh eventualmente más
conscientes de por qué la necesidad de
desplegar estas estas estas extensiones
de seguridad de NSC adicionales a a la
operación de cualquier servidor de NES,
ya sea recursivo activando validación o
en el caso de un autoritativo este
firmando los registros de de la zona que
que administra.
preguntas, comentarios.
Hay algunos comentarios en el chat.
Si los que A ver
si sí si los quieres leer, Rodrigo. O
a
leo uno acá de Jorge dice, "Si tengo un
dominio que tiene DNS internos y DNS
público también posee. También cont
interno sale por una plataforma y
público sale por otra.
entiendo que a ver,
o, o sea, el lo que estás escribiendo,
Jorge, es es está es un caso muy
particular y y de relativa complejidad,
digamos, eh cómo se pueden prevenir
impactos operativos y y qué riesgos
puedo prever, o sea, la implementación
de DNC SEC
a nivel de recursivo, que es básicamente
el servicio que que vos vas a vas a
utilizar más cuando estás resolviendo
nombres de dominio. Sí. Este
eh sobre todo cuando utilizas servidores
de NS público, servidores de NS interno,
etcétera, etcétera, el el impacto es
mínimo, digamos. O sea, uno ahí decide
este dónde si uno administra el servidor
DNS recursivo, por ejemplo, hay muchas
organizaciones que internamente
para todos los dispositivos internos de
la organización le le asignan un
servidor recursivo administrado por la
misma organización. Sí, muchos sistemas
de controladores de seguridad, etcétera,
etcétera, ya levantan automáticamente un
servidor recursivo para todos los para
todos los servicios internos. Por
ejemplo, Active Directory de Microsoft
es un típico caso de que de que tiene un
servidor este bueno, autoritativo para
los dominios internos y además este un
servidor recursivo este cuando uno
utiliza un proxy de de de DNS, por
ejemplo, también en general este trata
de resolver todos los dominios con un
servidor recursivo, un servidor
recursivo propio. quiere protegerse este
y tener cierto control sobre sobre el
tráfico de de DNS, activar validación
DNSC ahí es bastante importante y no
tiene un impacto operativo, digamos. No
hay mayores problemas operativos. Por
supuesto, si yo estoy validando DSC y el
que firmó, ¿sí? Es un típico típico
error operativo de de de DNS. Sí.
Alguien agarra a nivel de un servidor
autoativo, ¿sí? errores operativos en a
nivel de validación de recursivos son
muy muy pocos y y no vale la pena ni ni
ni ni mencionarlos porque no no tiene un
impacto operativo grande a nivel de de
seguridad autoritativo. Sí, hay
personas, por ejemplo, cuando cuando
establecen sus políticas de de de de
DNCS y y generan la clave pública y la
clave privada, cuando no generan la
clave, ¿sí? Muchos de ellos eh le ponen
un tiempo de expiración de la clave. O
sea, esta clave es válida hasta tal
fecha. Sí.
No, ese es eh típica reacción de de
alguien que administra sistemas de de de
seguridad de cualquier tipo, ¿no? El
tema de que las contraseñas no son
válidas para siempre, sino que expiran,
entonces hay que cambiarlas. Está eso
que es bueno, relativamente bueno para
una contraseña, aunque lo podíamos dejar
para otra charla. Este, en el caso de
NSC no es bueno. En el caso de NCSC,
originalmente se recomendaba este rotar
las claves cada tanto, etcétera,
etcétera, ponerles fecha de expiración a
la a las a la a las claves eh privada y
pública. Hoy en día la recomendación es
totalmente lo contrario. Es la
recomendación y la buena práctica es
nunca le pongan fecha de expiración a un
par de clave pública y privada. ¿Por
qué?
Eso quiere decir que nunca la voy a
rotar, ¿no? La política de rotación de
claves ustedes la pueden definir como
ustedes más le satisfaga, ¿sí? Y las
claves las pueden rotar, pero ¿por qué
no ponerle expiración a una clave? O
sea, si yo no la quiero rotar, la clave
va a seguir siendo válida para siempre.
Eso es importante. ¿Por qué? Porque uno
de los errores más comunes,
¿sí? Irónicamente, uno de los errores
más comunes es olvidarse de renovar la
clave. Los que le ponen fecha de
expiración se olvidan de renovar la
clave. La clave expira, DNSC deja de
funcionar. Los servidores recursivos
van a validar, van a tratar seguir
validando la lo que reciben, pero lo que
reciben, la firma ya no es más válida.
Una firma no válida es lo mismo que una
firma falsa. Entonces, el servidor
recursivo la la identifica como no
válida y descarta la información y no
resuelve el DNS.
No resuelve porque hay un error en el
servidor recursivo, no. El servidor
recursivo está haciendo bien su trabajo,
está validando y no valida. No resuelve
porque hay un error en el servidor
autoritativo. No, no resuelve porque
alguien se olvidó, le puso esta clave a
partir de hoy no es más válida y no la
renovó, no creó, no generó una nueva.
Entonces, el hecho de no ponerle fecha
de expiración, si ustedes por algún
motivo tienen que posponer el el el la
renovación, no pasa nada porque la clave
va a seguir siendo válida. Sí, ustedes
la renuevan cuando quieran. Si la
política de ustedes es renovarla cada 6
meses, perfecto, pero no le pongan fecha
de aspiración porque si un día no pueden
renovarla, bueno, tienen más tiempo. Sí,
eso, por ejemplo, durante la pandemia
pasó bastante porque la pandemia hizo
difícil o imposible que mucha gente se
trasladara y muchos protocolos de
rotación de de claves implicaban que la
gente fuera físicamente a un data
center, a un lugar y generara la nueva
clave y y todo eso. Entonces, como las
claves tenían vencimiento y no podían ir
a a a rotarlas, expiraron y cuando
expiraron dejan de funcionar, deja
resolver el DNS porque dejan de ser
válidos. Entonces, esa es la razón por
la cual, por ejemplo, no se recomienda
ponerle fecha de expiración a las a las
claves. Igual ustedes las pueden rotar
cuando quieran, digamos, está esas cosas
que parecen este triviales no lo son,
digamos, a nivel operativo. Entonces,
bueno, este de nuevo, los errores se
pueden evitar primero documentando los
procedimientos, procedimientos bien
establecidos y bien documentados, que
todos los conozcan, capacitando a a las
personas que van a operar las redes y
monitoreando, ¿no? es los servicios no
se ponen a operar y se dejan ahí y se
sorprenderían de la cantidad de
servidores en ese que tienen más de 15
años sin ni siquiera un parche de
seguridad. Sí. Bueno, la cantidad de
vulnerabilidades que tiene son todas las
vulnerabilidades de hace 15 años hasta
ahora. Imagínense, son casi todas las
que hay. Este, se sorprendería la
cantidad de servidores que no son
actualizados porque el servicio de DNS,
como es algo que uno lo pone a
funcionar, funciona y queda ahí, se
olvidan. Entonces, monitorear,
monitorizar, perdón, este, procedimentar
bien y escribir los procedimientos y que
todos los conozcan y capacitar capacitar
a la al al personal. Con esas tres cosas
básicas, este, ya se resuelven el 99% de
los problemas, digamos, no solo los de
DNS, de todos los problemas operativos,
pero porque ahí somos es donde las
personas fallamos más, digamos. Sí.
Este y bueno, y después sí, después hay
problemas que pueden surgir porque las
cosas fallan, los hardware, el hardware
se rompe o o soy objeto de un ataque que
no pude mitigar y bueno y tengo que
tengo que actuar en consecuencia y
resolverlo, pero bueno, eso la idea es
que sean los menos esos casos y cuanto
más mecanismo de seguridad como de NSSC
tenga yo implementado, más protegido voy
a estar contra más cantidad de de tipos
de ataque y de vectores de ataque y de
vulnerabilidades.
Entonces, la la recomendación es siempre
desplegar estas estas cosas de nuevo, no
es implementarlo y nada más, sino que
hay que tener en cuenta todas estas
consideraciones. ¿Sí?
Y creo que no hay este no hay más este
no hay más no hay más preguntas ahí en
el en el en el chat. No sé, en el chat
creo que no hay más preguntas. Este,
bueno, si no hay más preguntas un poco
hasta acá era la la presentación.
Estamos apenas 2 minutos pasados de la
de la de la de la hora estipulada.
Espero que les que les haya servido, que
les haya parecido interesante, por lo
menos. Y y nada, nos vemos en la en la
en la próxima en la próxima sesión. Sí,
Rodrigo, te devuelvo el la palabra para
ser.
Eh, no, solamente que muchísimas gracias
a todos. Acá les voy a compartir en el
chat eh mi correo y cualquier pregunta
eh lo que necesitan, estamos a la orden.
Muchas gracias a todos y obviamente no
no quiero eh terminar sin agradecer eh a
ans por hacer posible este tipo de
capacitaciones. Gracias y que tengan un
buen día.
Que tengan un excelente día a todos.
Chao. Chao.
Gracias. Adiós.