Suscríbete a DeepL Pro para poder traducir archivos de mayor tamaño.

Más información disponible en www.DeepL.com/pro.

"¿Sabes hablar mi dialecto?":

Marco para la autenticación de servidores
mediante dialectos de protocolos de
comunicación
Kailash Gogineni∗ , Yongsheng Mei∗ , Guru Venkataramani∗ , Tian Lan∗
�Universidad George Washington
{kailashg26,ysmei,guruv,tlan}@gwu.edu
arXiv:2202.00500v1 [cs.CR] 1 feb 2022

dorsal de la infraestructura informática distribuida, donde las

Resumen En el mundo actual, las redes informáticas son
vulnerables a numerosos ataques. Tanto en las redes aplicaciones dependen de las transferencias de datos para ejecutar
inalámbricas como en las cableadas, uno de los ataques más sus tareas. Por lo tanto, es fundamental preservar su seguridad para
comunes son los ataques de intermediario (man-in-the-middle), evitar que los adversarios exploten las lagunas, fallos y errores de
dentro de los cuales el secuestro de sesión y los ataques de configuración inherentes a los servicios de software pertinentes.
confusión de contexto han sido los más intentados. Así, un Numerosos ataques en este espacio de amenazas han sido
atacante potencial puede tener tiempo suficiente para lanzar un
ataque dirigido a estas vulnerabilidades (como desviar la petición ampliamente estudiados en el pasado - ejemplos incluyen
objetivo a un servidor malicioso o secuestrar el tráfico). Una oscurecimiento de fuentes de red [1], [2], suplantación de sitios
estrategia viable para resolver este problema es cambiar genuinos [3], [4], ataques Man in the Middle (MITM)
dinámicamente las propiedades y configuraciones del sistema y
crear huellas digitales únicas para identificar la fuente (desde la
que se envió el mensaje). Sin embargo, los trabajos existentes
sobre huellas dactilares se centran principalmente en las
propiedades de nivel inferior (por ejemplo, dirección IP,
protocolo TCP), y sólo este tipo de propiedades están restringidas
a la mutación.
En este artículo, desarrollamos un novedoso sistema,
denominado Verify-Pro, para proporcionar autenticación de
servidores mediante dialectos de protocolos de comunicación,
que utiliza una arquitectura cliente-servidor basada en
protocolos de red para personalizar las transacciones de
comunicación. Para cada sesión, se utilizará una secuencia
particular de apretones de manos como dialectos. Así, dado el
contexto, con el establecimiento de un nombre de usuario y una
contraseña de un solo uso, utilizamos los dialectos como
mecanismo de autenticación para cada solicitud (por ejemplo,
obtener nombre de archivo en FTP) a lo largo de la sesión, lo que
refuerza la autenticación continua. En concreto, aprovechamos
un enfoque de aprendizaje automático (modelo de red neuronal
preentrenado) en los equipos cliente y servidor para activar un
dialecto específico que cambia dinámicamente para cada
solicitud.
Implementamos un prototipo de Verify-Pro y evaluamos su
practicidad en los protocolos de comunicación estándar FTP
(protocolo de transferencia de archivos), HTTP (protocolo de
transferencia de hipertexto) y MQTT (transporte de telemetría
de colas de mensajes). Nuestros resultados experimentales
muestran que mediante el envío de información engañosa a
través de paquetes de mensajes de un atacante en la capa de
aplicación, el destinatario puede identificar si el remitente es
genuino o una suplantación, con una sobrecarga insignificante de
0,536%.

Términos índice-Personalización de programas, Dialectos de

protocolos, Redes neuronales profundas, Seguridad de redes,
Autenticación.

I. INTRODUCCIÓN
Los protocolos de comunicación constituyen la espina
mediante el secuestro de los paquetes de solicitud [5], el uso
de proxies [3],
[6] y cortafuegos y ataques de repetición, en los que los
atacantes pueden lanzarlos fácilmente de forma remota
sin establecer una conexión física con sus víctimas. La
tendencia reciente de los ataques denunciados muestra un
aumento significativo de las amenazas planteadas por vul-
nerabilidades en los protocolos de comunicación [7], [8].
Aparte de esto, los investigadores de Barracuda
informaron en enero de 2020 de que el secuestro de
conversaciones había aumentado un 400% en 4 meses [9].
En muchos protocolos de comunicación (incluida la
implementación de los protocolos más utilizados, como
FTP [10], HTTP [11], [12] y MQTT [11], [13]), la
autenticación suele producirse antes del inicio de la
sesión. Esto los hace vulnerables a los ataques antes
mencionados, como el secuestro de sesión MITM o los
ataques de confusión de contexto, en los que los atacantes
pueden redirigir la petición. Para contrarrestarlos,
buscamos técnicas que garanticen la autenticación
continua para cada búsqueda en una sesión mediante el
aprovechamiento inteligente de las características de la
capa de aplicación.
En este trabajo, presentamos Verify-Pro, un marco que
mejora la autenticación del servidor a través de la
modificación dinámica y continua de las propiedades de
un objetivo (binario de programa), manteniendo al mismo
tiempo la funcionalidad básica del protocolo de
comunicación subyacente. Además, Verify-Pro genera
dinámicamente respuestas de servidor personalizadas
utilizando dialectos de protocolo para cada solicitud, lo
que dificulta al atacante lanzar un ataque efectivo contra
un protocolo de comunicación que se autoadapta
constantemente. En este documento, definimos dialecto
de protocolo como variaciones de la implementación del
protocolo a nivel binario para incorporar medidas de
seguridad adicionales. Las variaciones pueden consistir
en la mutación de paquetes de mensajes, la generación de
diferentes transacciones de solicitud-respuesta basadas
en algunas condiciones ambientales, etcétera.
Proporcionamos una prueba de concepto de la
implementación de nuestra herramienta propuesta Verify-
Pro utilizando los protocolos FTP, HTTP y MQTT.
Nuestra contribución. Verify-Pro consta de tres
módulos principales: (1) Dialectos de protocolo (PD), (2)
Mecanismo de decisión de dialecto (DDM) y (3)
Verificación de respuesta del servidor (SRV). El módulo
PDs comprende varias transacciones personalizadas
utilizadas para la comunicación entre el cliente y el
servidor. Cuando el cliente lanza un comando (por
ejemplo, obtener archivo.txt en el protocolo FTP) para
recuperar un archivo del almacenamiento del servidor, se
activa el módulo DDM en el cliente, y la solicitud se
introduce como entrada en su red neuronal y se determina
un dialecto de respuesta "n".
para futuras verificaciones. Observamos que la selección de neuronal es desplegar un mecanismo personalizado para la
dialectos debe ser impredecible para los fisgones, con el fin selección del dialecto y evitar ataques de ingeniería inversa
de evitar el secuestro de sesiones MITM y los ataques de por parte de adversarios.
repetición. Con este fin, desplegamos un modelo de red • Diseñamos e implementamos el prototipo Verify-Pro en FTP,
neuronal preentrenado en ambos sistemas cliente-servidor HTTP y MQTT, y evaluamos su eficacia utilizando dialectos
equipado con un diseño personalizado (alterando la como huellas dactilares en una configuración del mundo real.
predicción de dialectos en un mecanismo construido a Los resultados de nuestra evaluación muestran que Verify-Pro
medida) para predecir un número de dialecto para iniciar la puede derrotar con éxito los ataques MITM de secuestro de
comunicación. Las estrategias aplicadas a la red neuronal sesión, repetición y confusión de contexto.
son i) Des- uniforme. Motivación. Los protocolos de comunicación se enfrentan a un
tribución de dialectos- ofrecen la ventaja de dificultar la
que el atacante pueda realizar ingeniería inversa en la red
neuronal (adivinar el número de dialecto), ya que todos los
dialectos están distribuidos uniformemente en las solicitudes
de muestra. Por otro lado, ii) la selección de dialecto basada
en la propiedad de coste ofrece un modelo de red neuronal
flexible para activar el dialecto con menor coste y hacer que el
sistema sea más eficiente (el menor coste para un dialecto da
como resultado ese número de dialecto...).
Di predicho con mayor frecuencia en las solicitudes de
muestras), y
iii) Pérdida consolidada- incluye un factor de compensación
a′′ que decide la sensibilidad a las propiedades antes descritas.
Hasta donde sabemos, este trabajo es el primero que utiliza
una red neuronal
como mecanismo de decisión (DDM) para activar los
dialectos que cambian dinámicamente las transacciones para
cada solicitud. El enfoque general y directo para el mecanismo
de decisión en cuestión es utilizar directamente una clave
"real" precompartida que podría utilizarse como índice para
seleccionar el dialecto de la biblioteca de dialectos. En
contraste con este enfoque, verify-pro, 1)
propone un mecanismo de decisión con propiedades a medida
para
diseñar un modelo de red neuronal personalizado para la
predicción del dialecto, 2) menor coste de despliegue y
mínima sobrecarga, 3) el uso de clave precompartida (clave
secreta) es vulnerable a ataques de fuerza bruta [14], mientras
que la ingeniería inversa de una red neuronal es
comparativamente más difícil de invertir y estos ataques
también pueden mitigarse [15], [16]. Dado que el cliente
necesita verificar la
dialecto del servidor en el que se envió la respuesta, el módulo
SRV del lado del cliente comprueba si el servidor responde a
la solicitud utilizando el dialecto "n" correcto.
Contribuciones. En resumen, hacemos las siguientes
aportaciones:
• Proponemos Verify-Pro, un marco automatizado para
aplicar dialectos de protocolos de comunicación como
huellas dactilares para autenticar servidores.
Aprovechamos diferentes implementaciones de dialectos
de protocolos para crear respuestas únicas que ayuden a
autenticar servidores durante la comunicación y mejoren
la seguridad.
• Verify-Pro utiliza un modelo de red neuronal para
seleccionar un dialecto único de respuesta que se utilizará
para cada solicitud. El motivo detrás del modelo de red
2
número de ataques como los proxies y los ataques de VIII se analizan los trabajos relacionados. La última sección
secuestro de sesión-MITM, que se convierten en la presenta el alcance futuro con una conclusión sobre el
principal amenaza para la seguridad de las experimento realizado.
comunicaciones. En este trabajo, creamos, analizamos y II. ANTECEDENTES
evaluamos las estrategias que son diversas y que se
desplazan y cambian repetidamente con el tiempo para El Protocolo de Transferencia de Ficheros (FTP), tal y
aumentar la complejidad, el tiempo y el coste para los como se define en el RFC 959 [10], es un protocolo basado en
atacantes, incrementando así la resiliencia del sistema. texto que se utiliza ampliamente para transferir ficheros entre
Los métodos de huella digital existentes se limitan a ordenadores a través de una red TCP/IP, como Internet. FTP
aumentar la complejidad frente a posibles ataques porque promueve el intercambio de datos entre las personas dentro de
las propiedades del sistema de red existentes (por sus oficinas y a través de Internet. El FTP se basa en una
ejemplo, dirección IP, apretones de manos a tres bandas arquitectura cliente-servidor que utiliza conexiones de control
TCP, números de puerto) están confinadas a la mutación. y datos separadas entre el cliente y el servidor. El FTP tiene
La falta de autenticación adicional para validar la un mecanismo de autenticación por defecto como el nombre
identidad en la sesión permite a los atacantes MITM de usuario y
redirigir las peticiones a entidades maliciosas, lo que da
lugar a mensajes malformados. Esta vulnerabilidad puede
evitarse aplicando una autenticación continua para cada
solicitud.
Para ello, diseñamos una herramienta de recursos
limitados (por ejemplo, de bajo coste), Verify-Pro, que
crea una serie de variaciones utilizando dialectos de
protocolo como huellas digitales que aprovechan más
características de la capa de aplicación. Los dialectos de
protocolo pueden aumentar las variaciones de las
propiedades del sistema para mejorar la seguridad de la
comunicación. Diseñamos un módulo de decisión de
dialectos (DDM) para garantizar la transmutación de los
dialectos utilizados en cada transacción. Verify- Pro
permite que el cliente y el servidor, que conocen los
mismos patrones de variación de dialectos de protocolo,
se comuniquen entre sí con precisión. Además, el uso de
un modelo de árbol de decisión basado en datos (SRV)
impide la superposición de respuestas enviadas desde
dialectos diferentes o de paquetes enviados por un
atacante.
Nuestros resultados experimentales demuestran que las
técnicas que utilizamos identifican con éxito (y también
rechazan- cierran la conexión de toda la sesión) a los
atacantes que tienden a enviar mensajes no deseados o
malformados. Además, demostramos que después de
identificar con éxito que el mensaje procede de un
atacante, cerramos la conexión de toda la sesión, lo que
ayuda al destinatario a no recibir posteriores paquetes de
mensajes (re sponses) de los atacantes. Creemos que
extraer el módulo DDM y adaptarlo a la evolución del
dialecto tiene un coste elevado y hace que el atacante
invierta más tiempo.
Organización. El resto de este documento se organiza
como sigue: Sección I: Introducción y motivación. En la
Sección II se describen los antecedentes de los protocolos
de comunicación. En la Sección III se analizan el modelo
de amenazas y los supuestos. En la sección IV se describe
el sistema. La Sección V trata de la implementación. La
Sección VI analiza la seguridad. Sección
VII se analiza la evaluación de nuestro experimento y su
usabilidad. Sección
3
antes de iniciar la sesión. Los mensajes enviados por el
remitente se denominan solicitudes (por ejemplo, get file.txt),
y ordenan al receptor que transfiera los datos en función de la
solicitud. El RFC de FTP define diez comandos. Cada
comando tiene un uso único y una sintaxis diferente para ser
enviado como petición. Cuando el remitente escribe una
solicitud (get hello.txt), la conexión de control se utiliza para
transferir estos comandos al servidor, y una vez que el
receptor lee la solicitud, los archivos se transfieren sólo a
través de la conexión de datos si el archivo está presente en el
almacenamiento del servidor. Los datos se transmiten
normalmente como un flujo de bytes a través del canal de
datos al cliente. En este documento, nos centramos
únicamente en el comando GET, en el que el formato de
solicitud del cliente es:
problemas de confusión de origen [18]. Intrínsecamente,
asumimos que los adversarios típicos husmean en la Wi-Fi
local y se localizan en la red Wi-Fi abierta sin una fuerte
protección de seguridad. Además, los ataques pueden ser
lanzados por pasarelas o proxies.
Los modelos de amenazas mencionados apoyan una prueba de
concepto para Verify-Pro como una nueva dirección prometedora
para utilizar dialectos como huellas dactilares para proporcionar
autenticación de servidor entre el

Request = {Argumento del comando ∈ obtener

nombre de archivo}
En esta implementación de FTP, un comando y un argumento
están separados por un "espacio". La primera palabra que
aparece antes del espacio es tratada como el comando, y la
siguiente es el nombre del archivo a recuperar. Nos referimos
a varias implementaciones sobre cómo se comunican los
sistemas cliente-servidor FTP. Como veremos más adelante,
aprovechamos estas desviaciones para determinar el dialecto
FTP utilizado en conversaciones FTP específicas. Los detalles
de los protocolos HTTP y MQTT se describen en el apartado
VII.
III. MODELO DE AMENAZA
Desde una perspectiva ofensiva, el objetivo del atacante es
recopilar información relevante utilizada para enviar una
respuesta no deseada o malformada a una máquina objetivo.
Verify-Pro es un mecanismo de autenticación del servidor
diseñado para facilitar su uso, al tiempo que proporciona
autenticación continua para cada solicitud (por ejemplo,
obtener el nombre de un archivo en FTP) en la sesión.
Además, permite al cliente verificar la autenticidad de las
respuestas del servidor (en cada transacción) a través de redes
no fiables. Verify-Pro está pensado para proteger contra los
siguientes tipos de adversarios:
1) Adversario activo. Permitimos al atacante espiar
cualquier tráfico de red de forma pasiva. Un adversario
activo puede desviar activamente las peticiones y
respuestas intercambiadas entre las máquinas cliente y
servidor. Por ejemplo, el adversario activo puede
reproducir, utilizar proxies, interceptar, fabri- car
nuevos mensajes e impedir que los mensajes lleguen a
su destino (enviando la petición a un servidor
malicioso): secuestro de peticiones.
2) Ataques de confusión de contexto. Asumimos que el
atacante se sitúa en la misma LAN que las víctimas,
pudiendo redirigir el tráfico cifrado (petición), donde los
ataques MITM se basan en certificados TLS
compartidos [17]. Usando los certificados TLS
compartidos [5] los adversarios pueden causar
4
 objetivo en una red inalámbrica. Para contrarrestar estos
ataques, el aspecto principal de nuestra propuesta consiste en
utilizar los dialectos de protocolos (PD) (distribuidos a los
sistemas cliente-servidor) como sistema eficaz de
autenticación del servidor. Estos dialectos están incrustados de
forma que el cliente dispone de paquetes de petición y el
servidor incluye los paquetes de respuesta. En contraste con
una clave compartida real criptográfica, utilizamos un módulo
DDM diseñado a medida (con tres propiedades para construir
un modelo de red neuronal personalizado que da

Figura 1: Diagrama del sistema Verify-Pro.

sistemas cliente-servidor en la seguridad de las

comunicaciones. Hacemos las siguientes suposiciones
para apoyar el sistema Verify-Pro:
• Proporcionamos autenticación unidireccional, en la que
dos partes se comunican; sólo una parte se autenticará
ante la otra entidad. En nuestro caso, como suponemos
que lo ideal es que el cliente sea auténtico, el
El servidor necesita autenticarse ante el cliente. Las
respuestas enviadas del servidor al cliente pueden ser
malformadas o reproducidas, y la solicitud enviada por el
cliente genuino puede ser secuestrada a un servidor
defectuoso.
• Suponemos además que el atacante no tiene medios
para acceder al modelo de decisión del dialecto (una red
neuronal profunda que decide
un dialecto), comprometen directamente el software, el
almacenamiento y las estructuras de datos que se ejecutan
en el cliente y el servidor.
Aunque este modelo de amenaza subestima el alcance y
la gravedad de algunos ataques activos y futuros contra el
protocolo de comunicación, apoya la prueba de concepto
de los dialectos de protocolo como una dirección
prometedora para añadir autenticación continua para cada
solicitud en la sesión junto con los mecanismos
predeterminados de nombre de usuario y contraseña. Por
lo tanto, este trabajo funciona como un paso inicial que
dirige una solución integral basada en el uso de dialectos
de protocolo de comunicación como huellas dactilares.

IV. RESUMEN DEL SISTEMA

Verify-Pro consta de tres módulos principales: (1)

Dialectos de protocolo (PD), (2) Mecanismo de decisión
de dialectos (DDM), y
(3) Verificación de la respuesta del servidor (SRV). En la
figura 1 se ilustra el diagrama del sistema Verify-Pro.
El atacante puede intentar activamente interceptar las
redes realizando ataques de secuestro de sesión y de
confusión de contexto mediante la colocación de
atacantes MITM realistas para redirigir el mensaje

5
como resultado de la divergencia en la predicción de correctamente con el cliente. Sin embargo, diferentes sistemas
dialectos) para seleccionar el dialecto para iniciar la cliente-servidor pueden implementar el protocolo de comunicación
comunicación. Durante la comunicación real, varios dialectos de formas ligeramente diferentes, por tres razones principales:
serán seleccionados dinámicamente por el módulo DDM, y 1. Las RFC no siempre ofrecen un único formato posible a la hora
esto, a su vez, da una mejor ventaja sobre las de especificar los paquetes de solicitud-respuesta. Por ejemplo, en
implementaciones por defecto de los protocolos de el protocolo FTP los identificadores de comando no distinguen
comunicación, ya que las peticiones-respuestas siguen entre mayúsculas y minúsculas y también las variaciones normales
cambiando dinámicamente para cada transacción y confunde a del código fuente binario, lo que significa que el
los atacantes intermedios, como resultado de la aplicación de
nuestra autenticación continua. Cuando el cliente lanza un
paquete de solicitud (por ejemplo, obtener archivo.txt en FTP)
para recuperar un archivo del almacenamiento del servidor, se
activa el módulo DDM en el cliente, y la solicitud se introduce
como entrada en su red neuronal para obtener un número de
dialecto específico en el que puede enviar su solicitud al
servidor y se determina un dialecto de respuesta "n" para su
futura verificación. Obsérvese que la solicitud de comando
(por ejemplo, obtener archivo.txt en FTP) en todos los
dialectos tiene el mismo formato y, además, la dialectalización
de nuestro protocolo comienza realmente a partir de la
respuesta del servidor. Obsérvese que el modelo de red
neuronal utilizado en los sistemas cliente-servidor es el
mismo, por lo que, dado el contexto, para la petición "Ri ",
tanto el cliente como el servidor deberían predecir el mismo
número de dialecto "Di ". Tras la predicción del número de
dialecto por parte del servidor, se envía al cliente una
respuesta "Resp" adaptada al dialecto. El módulo SRV del
lado del cliente verifica si el servidor responde a la solicitud
utilizando el dialecto "n" "correcto". Verify-Pro tiene los
protocolos dialectos desplegados de una manera
descentralizada que utiliza el módulo DDM para activar el
dialecto para validar la respuesta del servidor. Para superar la
validación, los sistemas cliente-servidor deben compartir el
mismo modelo de red neuronal y los mismos dialectos de
protocolo de forma automatizada. El servidor responde a la
solicitud enviada por el cliente de forma única para cada
dialecto. Para lanzar un ataque con éxito, el atacante tiene que
falsificar las respuestas enviadas al cliente o reenviar las
peticiones a un servidor defectuoso. Esta es una tarea
imposible para los atacantes MITM, ya que estamos aplicando
la autenticación continua para cada solicitud en la sesión. La
idea central de Verify-pro es que, aunque el atacante observe
pasivamente el tráfico y controle las redes inalámbricas, no
puede predecir el número de dialecto para responder o iniciar
la comunicación, ya que importamos la biblioteca de dialectos
y el módulo DDM en máquinas cliente-servidor con dialectos
y esquemas de predicción personalizados.

A. Dialectos del protocolo

Esta sección describe el proceso de creación de un dialecto
para un protocolo y su integración en un binario existente del
protocolo de comunicación. El módulo PDs resume los
recursos, las reglas utilizadas para garantizar que los dialectos
de protocolo cumplirán los requisitos de los protocolos de
comunicación para imponer una autenticación continua. Las
RFC que definen los protocolos de comunicación delinean el
protocolo que debe hablar un servidor para comunicarse
6
GET o get son ambos comandos válidos. Dado que el la respuesta (patrón de dialecto) que recibirá si ambos se
cliente tiene formato de petición get - "get comunican en idéntico dialecto. Dado que los protocolos de
nombrearchivo", podríamos incluso modificar el comunicación comprenden una arquitectura petición-
binario del programa para cambiar la colocación de los respuesta, también ajustamos la comunicación incluyendo un
argumentos comando y nombrearchivo como mayor número de peticiones-respuestas en la creación de un
"nombrearchivo get". único dialecto. Mostramos la diferencia entre la transacción
2. Identificamos numerosas implementaciones de por defecto y la transacción personalizada para el protocolo
protocolos de comunicación e integramos las variaciones FTP en el Apéndice XI y el mecanismo de handshake de los
en protocolos binarios estándar. En el núcleo de la dialectos modelo para el protocolo FTP en la Figura 2. La
creación de dialectos de protocolos personalizados, el respuesta del servidor a los diferentes dialectos es la misma.
problema crítico es comprender las variaciones en los La respuesta del servidor a los distintos dialectos se resalta en
apretones de manos. Por lo tanto, nos referimos a varias verde. Cada uno tiene una estructura de mensaje única que
implementaciones de los protocolos de comunicación que ayuda al cliente a identificar el número de dialecto que el
nos ayudan a generar transacciones personalizadas que se servidor utilizó para enviar su respuesta.
pueden utilizar como dialectos. 2) Variaciones del formato de los mensajes: Estas
3. Los protocolos de comunicación como FTP no tienen variaciones representan transmutaciones en el formato de las
cabeceras ni campos en la capa de aplicación. Por lo respuestas que envía el servidor
tanto, cualquier sistema cliente-servidor que realice la
funcionalidad básica de compartir el archivo de forma
efectiva se considera la funcionalidad básica de FTP.
Aprovechamos este escenario para crear manualmente
paquetes de respuesta con campos separados por una
coma -",". Aparte de eso, protocolos como MQTT, HTTP
tienen cabeceras, pero aún así mostramos que nuestro
Verify-Pro es eficientemente compatible con esos
protocolos en § VII y Apéndice XII.
En este documento, llamamos a diferentes implementaciones
de la red
protocolos, dialectos de protocolos. Dado el contexto
de un protocolo de comunicación estándar, un dialecto
D se define como la variación creada por el injerto
cruzado de varias implementaciones de reglas de
apretón de manos y la mutación de los paquetes de
mensajes, manteniendo intacta la funcionalidad
central del protocolo. Más concretamente, suponemos
que D1 , D2 , D3 ,. . Dn son los dialectos
creados utilizando diferentes reglas de comunicación y
mutando
los paquetes de solicitud-respuesta. Si un usuario inicia
una petición "Ri ", se utilizará un dialecto "Di " para
la comunicación. Así, cada dialecto de protocolo "Di "
se define de forma única mediante una solicitud "Ri "
utilizando un módulo DDM.
1) Plantillas de mensajes: Como se ha comentado en
la sección anterior, sólo proporcionamos autenticación
unidireccional, lo que significa que la respuesta del
servidor debe demostrar su identidad a un cliente
auténtico. Creamos las plantillas de mensajes para
personalizar la respuesta del servidor. Como los
protocolos de comunicación no tienen ningún formato
para los mensajes, definimos los campos como
delimitadores y los separamos con una coma.
Observamos que la información de (comando, longitud
del comando, longitud del nombre del archivo, nombre
del archivo, tamaño del archivo, etc.) (Por razones de
espacio, los dialectos del protocolo FTP se enumeran en
el Apéndice X) se utiliza para definir un dialecto
específico, de modo que el cliente conozca de antemano
7
 versiones diferentes de un protocolo desplegado en un único
binario de protocolo de comunicación. Además, el despliegue de
dialectos como hilos nos ofrece la ventaja añadida de una
sobrecarga mínima y un coste menor, ya que la activación de cada
dialecto se produce en milisegundos. Aunque para futuros
trabajos, nuestro objetivo es añadir más dialectos para aumentar la
complejidad y hacer que el sistema sea robusto con menos coste y
menos sobrecarga de ejecución.

Figura 2: Petición-Respuesta de Dialecto 1 y Dialecto 6 en

FTP.

al cliente. Por ejemplo, las respuestas del servidor FTP a un

comando de un cliente tienen una estructura poco
convencional, es decir, cada dialecto tiene su estructura de
respuesta del servidor de forma única, y la respuesta se
proporciona como información legible por humanos al
usuario. Siguiendo las especificaciones del protocolo, un
cliente debe leer los datos del servidor hasta que reciba un
terminador de línea, comprobar el mensaje y reenviar el texto
de la respuesta al usuario si es necesario. Teniendo en cuenta
las especificaciones del protocolo, elaboramos las variantes de
respuesta de dos formas distintas para explorar
sistemáticamente cómo las identifica un cliente:
Respuestas no conformes: Estas variaciones de respuesta no
cumplen la especificación del protocolo, pero se observan
con frecuencia en las conversaciones. Por ejemplo, esta
técnica puede variar los mensajes enviados al cliente, variar
las mayúsculas de la respuesta
(mayúsculas/minúsculas/mixtas) incluyendo mensajes no
convencionales como - "Sí, el archivo existe". Técnicas
como los apretones de manos no convencionales, la mutación
de paquetes, el cambio de campos (alteración de campos para
el nombre del comando, la longitud del comando, la longitud
del nombre del archivo, etc.) se integran para aumentar la
diversidad de software en los binarios de programa de los
protocolos de red.
Respuestas con campos: Esta técnica puede variar el número
de mensajes enviados en un paquete concreto con campos
q u e los controlan. En este caso, el servidor envía la
información separada por una coma en el mismo paquete. Por
supuesto, no está garantizado que el cliente requiera
información como el nombre del comando, la longitud del
nombre del archivo, el tamaño del archivo, etc. Utilizamos
esta información para que el servidor auténtico envíe una
respuesta de forma que el cliente auténtico pueda entender su
estructura de respuesta. No utilizamos una técnica de
automatización para desplegar los dialectos porque éstos están
diseñados con una estructura poco convencional (como el uso
de campos de mensajes, mutaciones de secuencias de paquetes
y handshake, extraídas de varias implementaciones de
protocolos). Los dialectos de protocolo se generan como
8
B. Mecanismo de decisión dialectal invertir el modelo, puesto que todos los dialectos tienen la
misma probabilidad de ocurrir.
La selección del dialecto por parte del cliente y el
servidor debe ser impredecible para los fisgones y, al Σ
M

mismo tiempo, garantizar que tanto el sistema del cliente Pérdida de uniformidad(l1) : min (P
i
como el del servidor predicen un dialecto idéntico D′′ para (yi )log2 (P (yi))) (1)
una solicitud determinada. i=1
′R′ . Para ello, desplegamos un modelo de red neuronal
El icoste como criterio de selección de dialecto. Definimos
preentrenado que confiere a la red neuronal ciertas el coste del dialecto como el número de peticiones-
propiedades flexibles y personalizadas. Los detalles del respuestas (el número (coste) se multiplica por 1000 para
conjunto de datos del módulo DDM se describen en el conseguir variaciones significativas) compartidas entre las
Apéndice X-A. máquinas cliente y servidor de un dialecto concreto.
Proceso de entrenamiento. Nuestro modelo es una DNN Suponemos un coste Cx para cada dialecto y P (yi ) es la
sencilla, capaz de asignar los vectores de características distribución de probabilidad de elegir un dialecto, por lo
de entrada x = x1 , ...xn (convirtiendo la "solicitud" del que nuestro objetivo es minimizar la suma de P (yi ) × Cx
protocolo en vectores), que constan de n muestras, a , que es el coste esperado. M se define como el número
una salida yi (que es el número de dialecto para una total de dialectos (clases). Esta propiedad ofrece la
solicitud determinada). La entrada de la red neuronal flexibilidad de hacer predicciones personalizadas
tiene un tamaño de n = 100 (vector para cada
solicitud), alimentada como un vector de características
de alta dimensión. El modelo tiene dos capas ocultas
con 128 neuronas cada una y función de activación
"relu" en cada capa, pero la última capa tiene 15
neuronas (esto representa que tenemos n = 15 como
número total de dialectos para el protocolo FTP) con
función de activación "softmax". El aumento del número
de capas ha dado buenos resultados y hace que el modelo
entrenado sea complejo.
Para el proceso de entrenamiento se utilizó el optimizador
ADAM. Los modelos se implementaron utilizando Python
y Keras con Tensorflow backend. Todo el procedimiento
de cálculo por capas desde las muestras de datos de
entrada hasta la predicción de salida se define como
inferencia. Cuando los datos de verdad terrestre no están
disponibles, consideramos que la función de pérdida L se
impone como un criterio que puede ser útil en la
generación de etiquetas (números de dialecto). La función
de pérdida del modelo consta de tres variantes:
Distribución uniforme de dialectos. Esta propiedad
implica que si tenemos un conjunto de peticiones de
entrada en el conjunto de d a t o s d e prueba, los números
de dialecto predichos deben distribuirse uniformemente.
Si el conjunto de datos de prueba tiene K entradas,
los dialectos previstos deben ser K/N , donde N es el
número de dialectos. Para conseguirlo
utilizamos la maximización de la entropía en la función de
pérdida para el entrenamiento. Aquí, la P (yi )
representa la aparición de un determinado número
dialecto de solicitudes yi . (calculado como el número
de apariciones de solicitudes con una determinada
probabilidad i dividido por el número de todas las
solicitudes de esa familia concreta), log2 es un
logaritmo con base 2, y M es el total de solicitudes con una
determinada probabilidad i dividido por el número de
todas las solicitudes de esa familia concreta).
número de dialectos (clases). Esta propiedad hace que el
modelo de red neuronal sea resistente, ya que el atacante
tendrá que invertir tiempo y esfuerzo para predecir o
9
en función del coste asignado individualmente a cada dialecto. respuesta como entrada al árbol de decisión, que verifica la
Por ejemplo, pretendemos que el dialecto 4 tenga una alta estructura de respuesta enviada por el servidor.
probabilidad de predicción, mientras que el dialecto 8 debe El árbol de decisión es uno de los algoritmos de clasificación más
tener la menor probabilidad. En este caso, asignamos un valor utilizados en el aprendizaje automático. Los árboles de decisión
más alto como coste al dialecto 4, mientras que el menor tienen una buena capacidad explicativa y son modelos
número (coste) para el dialecto 8. Tras el entrenamiento, el interpretables muy utilizados.
modelo predeciría el dialecto 4 con una frecuencia elevada. La
personalización con el coste hace que el sistema sea más
flexible para revisar la predicción con frecuencia y confundir
a los atacantes MITM.
M
Σ
Pérdida dialectal basada en el coste(l2) : min (P
(yi)(Cx)) (2)
i=1

Pérdida consolidada. Utilizamos la fórmula de la ecuación 3

para calcular la pérdida consolidada utilizando un factor de
compensación 'a', en el rango [0,1]. La combinación de estas
pérdidas l1 y l2 demostró ser eficaz, ya que, al variar el valor
de 'a', la predicción de dialectos cambiará gradualmente de
'encontrar el dialecto con bajo coste' a 'distribuir
uniformemente los dialectos' entre las solicitudes de muestra y
permite un diseño personalizado para la predicción de
dialectos.
Pérdida consolidada(l3) : (a × l2) + ((1 - a) × l1) (3)

El algoritmo del mecanismo de Decisión por Dialecto se

muestra en el Algoritmo 1. Comienza cuando el usuario
introduce una solicitud (por ejemplo, obtener archivo.txt) r′′ .
A continuación, la solicitud r′′ se introduce como entrada en el
módulo DDM del sistema cliente y se predice un dialecto de
respuesta n′′ . A continuación, se envía al servidor la solicitud
no dialectalizada de esa instancia dialectal concreta. En la
Figura 4 se muestran los gráficos de convergencia de las
propiedades. Finalmente, el cliente también calcula el número
de dialecto para utilizarlo en futuras verificaciones por el
módulo SRV del Algoritmo 3.

Algoritmo 1 Algoritmo del módulo de decisión dialectal -

DDM Entrada: R: Una petición R (por ejemplo,′ get
filename′ ← R para recuperar un archivo).
Salida: D: Un número de dialecto de un conjunto de dialectos
de 1 a 15.
1: procedimiento DDM(R) d Predicción del dialecto D a
partir de una solicitud R
2: R ← obtener nombre de fichero d Se activa la
solicitud, obtener nombre de archivo.
3: D ← Modelo de red neuronal(R) d La
solicitud se envía como entrada a la NN
4: devolución D d El número de dialecto
es D 5: Clase D ← D d Bloque de código de
un dialecto 6: R ← Clase D d R es una petición no
dialectada 7: R se envía a la máquina Servidor que
escucha en el puerto 21

C. Verificación de la respuesta del servidor

Tras recibir la respuesta del servidor, el cliente envía la
10
De ahí que se utilicen en aplicaciones como la tiene dos aristas salientes. Para entrenar un clasificador de
recomendación de productos, la detección de fraudes y la árbol de decisión CART, dado un conjunto de datos de
detección de intrusiones. Además, un árbol de decisión entrenamiento, el árbol de decisión se obtiene dividiendo el
ofrece una capacidad de percepción única para identificar conjunto en subconjuntos desde el nodo raíz hasta el nodo
actividades maliciosas y puede ayudar en el análisis hijo. La división se basa en las reglas derivadas por el índice
sistemático. Los árboles de decisión se utilizan para de Gini (ecuación 4), y el proceso de división se realiza
identificar y organizar condiciones con reglas en un repetidamente en cada subconjunto derivado de forma
proceso estructurado. recursiva, lo que se conoce como partición recursiva. En
Selección de características. En un esquema típico de nuestro esquema, sólo tenemos en cuenta el modelo de árbol
aprendizaje supervisado, se nos da un algoritmo de de decisión preentrenado en el lado del cliente, confirmando
que la respuesta del remitente es del dialecto n "correcto", que
aprendizaje δ y un conjunto de entrenamiento T ⊂ α ×
el cliente esperaba.
β compuesto por elementos de algún conjunto α, con
su etiqueta de clasificación de un conjunto finito de
clases β. Aplicando δ a T se obtiene un modelo
clasificador: η : α × β. En relación con nuestro
mecanismo, definimos α como estructura de respuesta
(cada dialecto tiene una estructura de respuesta
diferente, por ejemplo, las respuestas del servidor en el
protocolo FTP para numerosos dialectos se muestran
en el Apéndice X (resaltadas en color rojo)), αi son las
características, y β o clase es el número de dialecto.
Suponemos que Árbol de decisión: τ está equipado con
un conjunto finito de características con las que puede
construir un clasificador de árbol de decisión. En la
estructura de respuesta,
consideramos que cada paquete tiene como máximo 4
campos y que no hay más de 6 paquetes en la estructura
de respuesta. Para el conjunto de características se tienen
en cuenta características como el número de paquetes, el
número de campos de cada paquete y el tipo de datos de
cada campo. Idealmente, el algoritmo de aprendizaje δ
tendría en cuenta todas las secuencias posibles de
características para dividir un conjunto de datos y llegar a
un clasificador óptimo. Los detalles del conjunto de datos
se describen en el apéndice X-A.
En un árbol de decisión ∆, cada nodo intermedio incluye
un atributo, cada rama corresponde a una decisión y cada
nodo hoja indica un resultado. Más concretamente, cada
nodo interno
n tiene un índice de atributo correspondiente n.atributo
del conjunto de características de d atributos, y un umbral
n.umbral y dos hijos n.izquierda y n.derecha. Cada nodo
hoja y contiene el resultado de la clasificación y.class, que
es la etiqueta. Cada petición se representa como un vector
de tamaño R relativo a cada atributo. El algoritmo de
predicción del árbol de decisión se muestra en el
Algoritmo 2. El mecanismo parte del nodo raíz de
∆. Para cada nodo de n en ∆, compara R[n.atributo]
con n.umbral, y decide ir a n.izquierda si R[n.atributo]
< n.umbral, y a n.derecha en circunstancias diferentes.
En el
final, el algoritmo alcanza un nodo hoja y y el resultado
de la predicción es y.class (dialecto).
Utilizamos el paquete sklearn en Python, que nos ayuda a
diseñar un árbol de decisión sin necesidad de especificar
manualmente las reglas de clasificación. Sklearn utiliza
CART [19] (Classification and Regression Trees), que
construye árboles binarios; en concreto, cada nodo interno
11
Algoritmo 2 Predicción del árbol de decisión para la solicitud por "," y los paquetes separados por "/". El paquete 1(P1) tiene
de muestra R′′ una cadena como primer campo de la entrada anterior, y el
paquete 2(P2) tiene una cadena como primer campo y un
Entrada: Árbol de decisión ∆, solicitud de muestra R entero como segundo campo. Dado que verificamos el tipo de
Resultado: Resultado de la clasificación: Número de dialecto datos de cada campo del paquete y la estructura del mismo,
D para a
esto nos obliga a crear un conjunto de datos de 150K muestras
solicitar R con cadenas y enteros aleatorios según cada patrón de
1: n = ∆.raíz respuesta de dialecto. Tras la conversión vectorial, la entrada
2: while n is not a leaf node do se recorre a través del modelo preentrenado, y se predice una
3: si R[n.atributo] < n.umbral entonces clase (número de dialecto) con la que habita esa estructura de
4: n = n.izquierda respuesta. Asimismo, el árbol de decisión funciona muy bien a
5: si no la hora de verificar la estructura de la respuesta, ya que todos
6: n = n.derecha los dialectos y sus respuestas son únicos. El algoritmo de
7: return n.número de dialectod número de dialecto validación de la respuesta del servidor se muestra en el
es la clase Algoritmo 3. Comienza con el servidor recibiendo la solicitud
enviada por el cliente; de nuevo, la solicitud
c
Índice de Gini: IG = 1 - (por ejemplo, get file.txt) se introduce como entrada al
(4)
Σ i módulo DDM en el lado del servidor, y se determina un
p2 dialecto de respuesta n′′ . En función del número de
i=1 dialecto, se envía la respuesta dialectada′ resp .′
donde Pi es la proporción de muestras que pertenece a una árbol de decisión preentrenado en el lado del cliente para
clase
(dialecto) c para un nodo en particular. En el algoritmo 2, el comprobar el solapamiento (patrón) de la respuesta enviada por el
umbral se basa en la métrica de impureza, el índice de Gini, servidor. Por ejemplo, en el protocolo FTP, mostramos la
que elige el propio paquete sklearn. respuesta de nuestro servidor: la entrada es:
Entrada: "P1: comando/ P2: nombre de archivo, longitud del
Algoritmo 3 Algoritmo de validación de la respuesta del nombre de archivo"
servidor - SRV
Para el aprendizaje, convertimos la entrada en vectores de tamaño,
Entrada: R: Se recibe una solicitud R (por y consideramos los tipos de datos con campos separados
ejemplo,′ get filename′ ← R) del cliente.
Salida: Validación de la respuesta por parte del cliente.
1: procedimiento LADO SERVIDOR: DDM(R) d Predicción
del dialecto D a partir de una petición R
2: R ← obtener nombre de fichero d Se activa la
solicitud, obtener nombre de archivo.
3: D ← Modelo de red neuronal(R) d La
solicitud se envía como entrada a la NN
4: devolución D d El número de dialecto
es D 5: Clase D ← D d Bloque de código de
un dialecto 6: Resp ← Clase D d Resp es la respuesta
dialectada
7: Resp se envía a la máquina Cliente.
8: procedimiento CLIENTE: SRV(Resp)
9: Cliente ← Resp d La respuesta se envía al
cliente 10: Cliente: DS tree(Resp)
d El cliente verifica la respuesta del servidor
cotejando la estructura de la respuesta mediante un
árbol de decisión y también verificar el contenido
11: Si Resp ∈ Respuesta del dialecto esperada por el
cliente entonces
12: Re¯sp del cliente se envía al servidor
13: Else La conexión se termina.

Verificación de respuestas basada en árboles de decisión.

En nuestro modelo de árbol de decisión, una entrada x se
recorre en el árbol aprendido en δ. Desplegamos un modelo de
12
al cliente. Eventualmente, cuando el cliente recibe una
respuesta dialectal′ resp′ , el módulo SRV se activa, y el
módulo
′resp′ se alimenta como entrada al módulo SRV (Árbol de

decisión), que ayuda al cliente a verificar si la

respuesta era realmente del dialecto n′′ , que el cliente
estaba esperando/ si hay solapamiento de dialectos/
variaciones en las estructuras de los paquetes (ocurren a
causa del atacante intermediario o del servidor
defectuoso). Tras verificar el patrón del mensaje
recibido y confirmar el dialecto, también verificamos
los valores de los campos, ya que el cliente ya
conoce cierta información sobre el mensaje que
recibirá (como el comando, los nombres de archivo, la
los nombres de archivo de ).
longitud del comando y
V. IMPLEMENTACIÓN
Implementamos un prototipo de Verify-Pro sobre
protocolos de comunicación en tres fases, que incluyen
los siguientes módulos principales.
Fase 1: Dialectos de protocolo (PD): Implementamos
nuestras funciones de transacción cus- tomizadas (por
ejemplo, mutando las variaciones de formato de los
mensajes) en el protocolo de comunicación. Los
apretones de manos y los formatos de los mensajes se
cruzan a partir de diferentes fuentes de implementaciones
de protocolos de red, y algunos según las condiciones del
entorno. Aprovechamos estos apretones de manos y los
utilizamos como huellas dactilares para verificar la
identidad del remitente de la respuesta. Diseñamos 15
dialectos (en FTP) como prueba de concepto, y se
despliegan en máquinas cliente y servidor para
comunicarse eficazmente en uno de los dialectos
activados para cada solicitud.
Fase 2: Mecanismo de decisión dialectal (DDM):
Implementamos el módulo DDM como una red neuronal
profunda que tiene como entrada la petición′ ′ (por
ejemplo, get file.txt en el protocolo FTP), y como etiqueta
el número de dialecto (entre 1 y 15). La salida del DDM
se utilizará como número de dialecto para iniciar la
comunicación, y se iniciará el handshake personalizado.
Fase 3: Verificación de la respuesta del servidor (SRV):
Implementamos nuestro módulo SRV para verificar la
estructura (formato en el que se envían los paquetes) de la
respuesta del remitente (es decir, la respuesta del
servidor) para evitar que se solape con la respuesta de
cualquier dialecto o con cualquier respuesta maliciosa. El
módulo SRV dispondrá de un árbol de decisión para
validar la estructura de los paquetes de respuesta
recibidos por

13
el cliente. Siempre y cuando, si el cliente confirma que la
respuesta fue del dialecto del servidor como - correcto, que
en realidad estaba esperando de, entonces la comunicación
será exitosa. Cualquier desviación de este proceso resulta en la
terminación de toda la sesión.
certificado TLS [5]. Por lo tanto, la ruta de reenvío de datos sigue
siendo válida, lo que no crea ninguna incertidumbre para Alice.
Así, Mallory puede comunicarse con Alice y permanecer en el
enlace de comunicación el mayor tiempo posible entregando el
tráfico con normalidad. En

VI. ANÁLISIS DE SEGURIDAD

Esta sección destaca los riesgos de seguridad de los
protocolos de comunicación y muestra cómo pueden evitarse
con Verify-Pro. Resumimos nuestros hallazgos en la Tabla I.
Descripción del ataque. Vectores de ataque como MITM-
session hijacking- rerouting the target request [20], [21],
ataques de confusión de contexto, uso de proxies/firewalls
pueden hacerse pasar intencionadamente por un usuario
legítimo, lo que daña la autenticidad de la comunicación. El
desvío de la solicitud de un cliente auténtico a un servidor
defectuoso por parte de los atacantes intermedios provoca la
intromisión en el canal de datos. En este escenario, el
adversario es capaz de establecer un relé MITM o una
estación base falsa [22] entre las partes de la comunicación
para interrumpir la comunicación, a través de la cual se
renuncia a que el servidor genuino reciba la petición del
objetivo. Ataques de confusión de contexto [5], utilizados por
protocolos estándar como HTTPS, FTPS, se puede utilizar un
mecanismo estándar como SSL/TLS para proteger el canal de
comunicación. Sin embargo, aprovechando la vulnerabilidad
existente en SSL/TLS, los atacantes intermedios pueden
lanzar ataques de degradación de la suite de cifrado
abandonando el paquete Clienthello enviado por el cliente
genuino y sustituyéndolo por un paquete malformado
consistente en una versión inferior de SSL/TLS [17], [23]-
[25]. En el ataque de confusión de contexto, el ataque se
produce a causa de certificados TLS compartidos; de este
modo, el adversario desvía la petición se desvía a un servidor
con certificado compartido defectuoso. El uso de entidades
intermedias como proxies maliciosos [6], [26]-[30] o software
de interceptación [26], [27], una forma de ataque MITM,
causa los problemas de confusión de origen ya que el atacante
puede secuestrar el tráfico seguro entre el cliente y el servidor.

A. Configuración del ataque en el mundo real

Presentamos el escenario de elusión de las políticas de
seguridad y demostramos la confusión de contexto, los
ataques de secuestro de sesión MITM en un entorno complejo.
Para comprender las repercusiones reales, realizamos un
experimento en el mundo real para este tipo de ataque de
reenvío de datos (Figura 3). Verify-Pro requiere un cliente
auténtico (Alice), un servidor auténtico (Bob), un atacante
MITM (Eve) y un servidor atacante (Mallory). Eve se
interpone entre las dos entidades comunicantes, Alice y Bob. A
continuación, Eve captura la petición del objetivo y la reenvía
a Mallory, lo que es posible gracias a los ataques de
suplantación de identidad [31], [32]. Mallory se hace pasar por
Bob y se comunica con Alice después de que Eve reciba la
petición. Esta situación se produce cuando tanto Bob como
Mallory comparten un certificado TLS válido, y la
autenticación también se puede pasar debido al mismo

14
 caso, el adversario - Mallory debe crear un modelo sombra
para el
Módulo DDM y PDs en convencer a Alice para completar el
apretón de manos. Sin embargo, argumentamos que adaptarse
a estos módulos supone una complejidad de tiempo y costes
para el atacante-Mallory. Para cada solicitud Ri , las
respuestas Resp cambian dinámicamente debido al módulo
DDM. En concreto, si Mallory envía un paquete que no
contiene las reglas de comunicación inducidas por los PD,
Alice abortará la transacción sin completar

Figura 3: Configuración del ataque.

al final, Mallory comienza la comunicación en políticas de

seguridad débiles (debido a ataques de downgrade TLS)
con Alice, resultando en el fallo de autenticación. Como
tal, Mallory envía la respuesta malformada (sin conocer
ningún patrón de dialecto), resultando en problemas de
autenticación que pueden ocurrir en cualquier petición de
destino y puede causar potenciales amenazas de
seguridad. Una defensa que evita con éxito esta
vulnerabilidad consiste en aplicar la autenticación
continua mediante dialectos de protocolo (aprovechando
las características de la capa de aplicación) durante la
comunicación. Al hacer nuestra afirmación de seguridad,
enviamos una petición get file.txt
de Alice al módulo DDM para predecir un dialecto,
digamos D8. Recordemos que la petición de cada dialecto
tiene el mismo formato y el dialect-ing comienza
realmente a partir de la respuesta de Bob′ . A partir de los
modelos de amenaza anteriores, suponemos que cuando el
La petición de destino es secuestrada y desviada por un
Eve a Mallory. Dado que Bob y Mallory comparten los
mismos certificados TLS, no existe forma de validar la
identidad de los paquetes de respuesta. Bajo estos
supuestos, afirmamos que la Alice espera una respuesta en
un único paquete que contiene cuatro campos de D8.
Para ello, utilizamos el módulo PDs (que comprende
de dialecto de protocolo único y estructuras de
respuesta únicas para cada dialecto Di ) y el módulo
DDM para seleccionar un dialecto basado en la
solicitud de Alice′ s Ri . A su vez, Alice utiliza el
módulo SRV para verificar si la respuesta tiene un
único paquete con cuatro campos (separados por ,′′ ).
Para ello, Alice dispone de las características de todos
los dialectos, como el número de paquetes, los campos
y el tipo de datos de cada campo. Para que esta
verificación sea aún más sólida, Alice ya conoce el
patrón del mensaje y cierta información (como el
nombre del comando, el nombre del archivo, la
longitud de
) del dialecto D8 por adelantado. De este modo, todos los
dialectos están dotados de características únicas que
ayudan al cliente - Alice a identificar su identidad. En este
15
el handshake debido a un mensaje malformado. Partiendo de de concepto, FTP presenta dos ventajas principales: (a) un
nuestra suposición de que Mallory no puede acceder al protocolo de red ligero con un rendimiento más fino, flexibilidad y
módulo DDM, observamos que propiedades de DDM como la facilidad de prueba, y
uniformidad ofrecen la ventaja de repartir los dialectos (b) Tiene menos complejidad en el diseño, soporta la
uniformemente entre todas las peticiones de muestra, lo que personalización del protocolo a nivel binario para proporcionar
hace más difícil para Mallory o Eve adivinar el dialecto medidas de se- guridad adicionales. Como se muestra en el
sucesivo basándose en la experiencia previa de dialectos. La Apéndice XI, cuando una solicitud
propiedad de selección de dialectos basada en el coste
confiere un diseño de red neuronal personalizado para activar
un dialecto con la frecuencia más alta (lo que crea una
situación inversa para la distribución uniforme) y renovar las
predicciones con frecuencia para confundir a los atacantes
MITM.
Seguridad matriz de lisis
ana
Ataque Implicaciones Vulnerabilidad Requiere Continu-
notables autenticación y uso
tion de funciones de la
capa de aplicación
Secuestro de sesión MITM, rastreo Redirigir la solicitud de
de paquetes destino
Ataques proxy y Software de Origen confusión es-
cortafuegos (una interceptación demanda
forma de MITM)
Contexto Confusión en Cambiar a una Transpira debido a
las chinchetas versión inferior de los certificados TLS
TLS compartidos entre los
servidores

Tabla I: Matriz de análisis de seguridad.

VII. EVALUACIÓN

En esta sección, evaluamos la eficacia de Verify-Pro en tres

implementaciones de protocolos del mundo real: FTP, HTTP
Y MQTT. Analizamos numerosas implementaciones de F T P
para recopilar diversas transacciones de comunicación.
Personalizamos el protocolo FTP en sistemas cliente-servidor
para incluir 15 dialectos de protocolo de transacciones cus-
tomizados para proporcionar autenticación continua para cada
solicitud en la sesión. MQTT (un protocolo de mensajes IOT)
se ejecuta sobre TCP/IP. MQTT es un protocolo de
publicación y suscripción que transporta mensajes entre
entidades. Elegimos personalizar el paquete de publicación
para construir diferentes versiones personalizadas del
protocolo y evaluar nuestra viabilidad Verify- Pro. HTTP es
un protocolo de capa de aplicación que se ejecuta sobre TCP.
Este protocolo es similar al FTP, donde el cliente envía las
peticiones y el servidor envía las respuestas. El protocolo
HTTP se utiliza principalmente para entregar datos (archivos
de imagen, archivos HTML, etc.) El puerto por defecto es el
80, pero también se pueden utilizar otros puertos. HTTP se
utiliza para transferir archivos pequeños, como páginas web,
mientras que FTP es más eficaz para transferir archivos
grandes.
Configuración del experimento: Nuestros experimentos se
llevan a cabo en un equipo con CPU Intel(R) Core(TM) i7-
4790S a 3,20 GHz y 15,5 Gigabytes de memoria principal. El
sistema operativo es Ubuntu
18.04 LTS.

A. Personalización de FTP
Como protocolo objetivo para nuestra evaluación de prueba
16
'GET nombrearchivo' se envía al servidor, el proto- col convergencia de la propiedad de coste y las propiedades de
FTP por defecto tiene un handshake petición-respuesta. distribución uniforme. Se utilizaron 128 × 128 × 15 capas,
Después de aplicar Verify- Pro en FTP, los módulos PDs una tasa de aprendizaje de 0,00001 y 40 épocas para el cálculo.
comprenden varias transacciones de comunicación en pérdida de coste y 100 épocas para la pérdida de entropía, tamaño
ambos lados. El módulo DDM en ambos sistemas cliente- de lote 128 como
servidor se utiliza para elegir un dialecto 'di ' para cada las configuraciones del sistema. A partir de la ecuación 3,
solicitud única 'Ri '. La solicitud 'Ri ' (solicitud sin utilizamos un factor de compensación a para mostrar la
dialecto) se envía al servidor, y el cliente espera la flexibilidad y la capacidad del algoritmo del módulo DDM
para adaptarse a distintos requisitos. Por ejemplo,
respuesta del servidor para verificar la identidad del
consideremos dos dialectos 1 y 7 con marcos de tiempo de
servidor. En el lado del servidor, utilizando la solicitud
muestreo medio de 0,0707 segundos y 8,112 segundos
'Ri ' recibida del cliente, el servidor utiliza el módulo
DDM para determinar el número de dialecto 'di ' para respectivamente (§ XII-B).
enviar una respuesta dialectal 'resp' al cliente. A su vez,
el cliente utiliza el módulo SRV para validar la respuesta
enviada por el servidor, lo que da lugar a la verificación
de la identidad.
Para demostrar la eficacia de nuestra herramienta (véase
el Apéndice XI-A), Verify-Pro, creamos un servidor FTP
atacante (servidor A) que no incluye ningún dialecto de
protocolo ni módulo DDM. Una vez que los sistemas
cliente y servidor A están en el bucle de comunicación, se
envía la petición objetivo desde un cliente auténtico a un
servidor malicioso. El servidor malicioso puede empezar
a fabricar y enviar respuestas maliciosas al cliente
genuino. El servidor malicioso falla en la fase de
evolución del dialecto, ya que se realiza una autenticación
continua para cada solicitud de la sesión. Dado que el
patrón dialectal del protocolo cliente cambia
dinámicamente con cada petición, al servidor malicioso le
resulta difícil entender el patrón de evolución dialectal
generado por el módulo DDM. Creemos que este método
se ajusta incluso a los esquemas de cifrado TLS para
aumentar también la confidencialidad. Demostramos que
nuestro método ayuda a defender los protocolos de
comunicación de vectores de ataque como el desvío de la
petición de destino, el uso de proxies o software de
interceptación maliciosos y los ataques de confusión de
contexto .
Análisis del rendimiento de Verify-Pro en FTP
Índice de rendimiento FTP Verify-Pro (FTP)
Utilización CPU <1% 1%
Tiempo/seg. del sistema 43,871 seg. 44,106 seg.
Modelo DDM tiempo/seg N/A (No DDM) 0,0723 seg.
Modelo SRV tiempo/seg N/A (No SRV) 0,000525 seg
(sólo en cliente)

Tabla II: Métricas de rendimiento de Verify-Pro FTP

y FTP 1Tiempo del sistema: Tiempo registrado desde el inicio de
sesión del usuario hasta la transferencia de un archivo de 20 bytes en
segundos para Dialect 8 (Verify-Pro) & FTP (plantilla dialect-8
desplegada). 2Tiempo DDM: Tiempo registrado desde la activación de
la solicitud del usuario hasta la predicción del número de dialecto.
3 SRV time:Tiempo registrado desde la alimentación de la respuesta como
entrada a la Decisión
árbol hasta emitir el dialecto como confirmación.
1) Trade-offs del módulo DDM.: En esta sección,
variamos el factor de compensación a′′ de nuestra red
neuronal profunda que asegura la propiedad de
flexibilidad y proporciona una compensación entre las
propiedades de pérdida l1 & l2. Como puede verse en la
figura 4, los gráficos 1 y 2 muestran los resultados de la
17
Nuestra red neuronal personalizada ayuda a elegir un dialecto para el modelo de red neuronal y 7 KB para los modelos de
que tenga menos sobrecarga de ejecución. Normalmente, árbol de decisión, el tiempo de ejecución de estos módulos es
asignamos el insignificante. Además de
coste del dialecto x basado en el número de peticiones- la sobrecarga de los módulos DDM, SRV, la sobrecarga restante
C′′ respuestas
pares intercambiados entre dos partes. Pero para fines generados en una secuencia. Esto significa que, dada cualquier
experimentales, digamos que necesitamos elegir un dialecto longitud de números de dialecto precedentes, no se puede
óptimo con menos tiempo de ejecución, entonces podemos predecir el siguiente número para una solicitud dada en la
definir el coste basándonos en nuestras suposiciones. El secuencia observando los números de dialecto dados.
dialecto 1 tiene un coste bajo en este experimento debido a su Análisis de la Tabla II. Al final, evaluamos la sobrecarga de
baja sobrecarga de ejecución en comparación con el dialecto ejecución de Verify-Pro, transfiriendo un fichero de 20 bytes-
7. Nos entrenamos utilizando el optimizador Adam y Dialect(8) y comparamos los resultados con el FTP estándar
encontramos una solución óptima con todas las muestras que (plantilla dialect-8 de- ployed). Para concretar nuestra evaluación,
predicen el dialecto D1 cuando el factor de compensación a se también comprobamos la sobrecarga de los módulos añadidos en
fija en 0 para la pérdida de entropía (la pérdida de coste comparación con la implementación FTP original. Presentamos la
predice el dialecto óptimo como D1-Figura 5a). En relación sobrecarga de los módulos DDM y SRV. Dado que ambos
con este experimento, concluimos dos casos: (1) Hacemos que
nuestro modelo módulos tienen modelos preentrenados con un tamaño de 12 MB
más eficiente eligiendo un dialecto 1 óptimo, que tiene un
11374% menos de sobrecarga que el dialecto 7 (basado en
marcos temporales).
(2) Al variar los pesos de la red neuronal, la arquitectura
puede desencadenar varios dialectos y confunde a los
atacantes intermedios para especular el patrón. A partir de
esto, podemos concluir que no existen patrones en la
secuencia de dialectos y esto, a su vez, proporciona una
ventaja de seguridad añadida. Por otro lado, utilizamos las
configuraciones del sistema mencionadas con 30 épocas para
analizar cómo afectaba el factor de compensación a la
distribución. El hallazgo interesante de la figura 5d es que, a
medida que el valor a disminuye de 1 a 0, observamos que
todos los dialectos son
distribuidos uniformemente de forma que cada dialecto tenga
un
igual probabilidad de que ocurra. Por ejemplo, las figuras 5b y
5c muestran la variación cuando el factor de compensación de
la pérdida de costes
pasa de 0,8 a 0,4. Si se considera la pérdida de costes con
el factor de compensación a = 0,8, aunque se incluya la
pérdida de entropía fija, el dialecto óptimo D1 se predice
para un 50% más de solicitudes de muestra en comparación
con el segundo mejor dialecto óptimo D14. Del mismo
modo, la pérdida de costes con el factor de compensación a
= 0,4 muestra que D1 sigue teniendo la frecuencia más alta,
pero también se observa que los dialectos parecen repartirse
más uniformemente cuando
en comparación con la Figura 5b. Existen problemas
moderados en el aprendizaje de la función de pérdida
consolidada utilizando un factor de compensación debido a
factores como la arquitectura de la red, las características,
los hiperparámetros o los procedimientos de entrenamiento.
Una de las razones destacadas para utilizar una red neuronal
es su propiedad de reproducibilidad en términos de
seguridad. Esto garantiza que, dada la red neuronal con la
misma arquitectura, el número de dialecto predicho 'Di '
será el mismo para una solicitud dada 'Ri '. Los números de
dialecto predichos son independientes entre sí, es decir, no
debe haber ninguna correlación serial entre los números

18
incurre cuando el cliente verifica la información de cada
campo, como el comando, el nombre del archivo, etc.
Llegamos a la conclusión de que los desarrollos
correspondientes no repercuten en la ralentización del
proceso ni facilitan a los atacantes la obtención de un
modelo sombra. Nuestro módulo PDs no incurre en
ninguna sobrecarga. Los dialectos se crean como hilos
de tal forma que sólo se activará una instancia 'Ci ' para
un dialecto dado 'Di ' & para la solicitud única 'Ri '. Para
evitar posibles sesgos estadísticos, ejecutamos el
experimento varias veces y calculamos la sobrecarga
media (véase la Tabla II). Precisamente, concluimos
que la adición de los módulos PD, DDM, SRV incurre
en una sobrecarga del 0,536% (del tiempo del sistema),
lo cual es trivial; a su vez, la adición de estos módulos
refuerza la autenticación continua.
Además, la sobrecarga del tiempo de ejecución para todos
los dialectos excepto el dialecto 7 es < 1% (de media), lo
que es insignificante. El motivo de aumentar el tiempo de
ejecución del dialecto 7 es utilizarlo para la restricción en
la selección de dialectos basada en la propiedad de coste
(para representar cómo se pueden seleccionar dialectos
con menos tiempo de ejecución).
en lugar de los dialectos que tienen una gran sobrecarga
en tiempo de ejecución). Teniendo en cuenta la
sobrecarga de almacenamiento del módulo DDM cuando
un servidor está conectado a varios clientes, el despliegue
de varios modelos de redes neuronales ocupa grandes
cantidades de espacio en disco. Para contrarrestar este
problema, los usuarios avanzados pueden utilizar la poda
de redes neuronales [33], [34] para comprimir la red
neuronal profunda y producir la misma funcionalidad.

Figura 4: pérdida en función del número de épocas.

*El gráfico 1 muestra la convergencia de la propiedad de
coste y el gráfico 2 muestra la convergencia de la
uniformidad.

B. Personalización de MQTT y HTTP

En esta subsección, evaluamos la eficiencia y
usabilidad de protocolos de comunicación como HTTP y
MQTT tras su integración con Verify-Pro.
1) Protocolo MQTT: MQTT es un protocolo de
mensajería IoT ligero estándar que se utiliza para
dispositivos IoT. Es un protocolo basado en binarios,
que tiene formato de comando y acuse de recibo de
comando. La carga útil del protocolo MQTT transporta
datos binarios, ASCII, etc. Utiliza paquetes de pequeño
tamaño, por lo que ofrece ventajas para aplicaciones con
poco ancho de banda. El paquete MQTT (Figura 6.)
contiene una cabecera fija (incluida la cabecera de
control), una cabecera variable y una carga útil en la capa
de aplicación. Programamos un cliente y un broker
(servidor) MQTT estándar y les aplicamos nuestro
Verify-Pro. El cliente enviará un paquete de
publicación al servidor, y el servidor responderá con un
mensaje 'pub - ack'. Protocolo MQTT

19
 (a) a = 1 para (b) a = 0,8 para (c) a = 0,4 para (d) a = 0 para
pérdida l2 a = 0 pérdida l2 a = 0,2 pérdida l2 a = 0,6 pérdida l2 a = 1
para pérdida l1 para pérdida l1 para pérdida l1 para pérdida l1
Figura 5: Variaciones de los gráficos teniendo en cuenta el factor de compensación a. A medida que disminuye el factor de
compensación, la distribución empieza a repartirse entre más dialectos. Este gráfico muestra el número de dialectos en
el eje x y las solicitudes de muestra en el eje y.

específicos. El cliente A no envía múltiples paquetes de

dialectos se presentan en la Tabla III. En este protocolo,
publicación para agotar los recursos del servidor, ya que los
asumimos que el cliente tiene que demostrar su autenticidad
módulos PD y DDM sólo están disponibles con el cliente
al servidor, lo que significa que el dialecto del protocolo
auténtico, sólo un cliente auténtico, basado en su tema, puede
comienza realmente en el cliente. Como puede verse en la
enviar mensajes dialectales y el servidor basado en el mismo tema
Figura 6, consideremos el paquete de publicación con el
puede conocer la técnica de mutación dialectal. El cliente
mensaje "HELLO" al tema "OPENLABPRO". En la cabecera
variable, los 2 primeros bytes especifican la longitud del
tema y a continuación le sigue el tema. Del mismo modo,
la cabecera de carga útil tiene los 2 primeros bytes que
denotan la longitud del mensaje, seguidos por el mensaje en
sí. El módulo PDs contiene dialectos con mutaciones
realizadas en el nombre del tema, las cabeceras de las
variables del mensaje, etc. La entrada de la red neuronal
(DDM) para este protocolo es el tema del paquete de
publicación. Dado que el tema se utiliza como entrada, el
número de dialecto predicho a partir de él se utilizará como
clave para iniciar la comunicación. El módulo SRV, en el
lado del servidor, verifica si el cliente se está comunicando
en el dialecto 'Di ' para un tema 'Ti '.

Nombre dialectal Mutaciones realizadas

Cabecera aleatoria
Transmutación de mensajes
Mutación de la carga útil
Los campos Tema y Mensaje son
conmutado
Un MQTT por defecto tiene 1 tema
y
1 valor en cada paquete de
publicación, pero esta variante
publica el mensaje con 2 temas y 2
valores para ahorrar ancho de
banda.
Esta variante divide un solo paquete
con (1 tema y 1 valor) en dos
paquetes diferentes

Tabla III: Dialectos del protocolo MQTT.

Para ilustrar la capacidad de MQTT-con PDs en la defensa

contra ataques DoS, implementamos un cliente atacante
(cliente A) que se esfuerza por vaciar el servidor enviando
continuamente paquetes 'publish'. El módulo PDs utiliza
diferentes variantes de los dialectos del protocolo, como
transmutar las reglas del handshake, barajar las cabeceras,
mutar los campos topic y value (principalmente muestra cómo
se envía el paquete). El cliente A no entiende la evolución del
dialecto basado en cada tema único y los formatos de mensaje
20
El cliente y el servidor pueden comunicarse eficazmente y
publicar información en el servidor debido al módulo
DDM clonado, y el cliente auténtico siempre sabe cómo
enviar el paquete en un "dialecto particular" - para un
"tema" único. Por ejemplo, consideremos que un tema
OPENLABPRO con un mensaje HELLO es lanzado por
un cliente genuino. En este punto, el cliente ya calcula el
número de dialecto n utilizando el módulo DDM y lo
conserva para futuras verificaciones. El servidor, al
recibir el paquete de publicación, sigue de nuevo el
mismo proceso utilizando un módulo DDM para calcular
un número de dialecto n. La técnica de dialecto,
transmutación de mensajes, muta los paquetes de temas y
mensajes etiquetando temas y mensajes ficticios en un
único paquete de publicación. A continuación, el servidor
prepara la respuesta dialectal y la envía al cliente.
Finalmente, el módulo SRV en el lado del cliente ayuda a
verificar si la respuesta recibida del servidor tiene
campos de tema y mensaje ficticios con los originales en
el mismo paquete de publicación, lo que resulta en la
verificación del formato en el que se envían los mensajes.

Índice de rendimiento HTTP Verificar- MQTT Verificar-

Pro(HTTP) Pro(MQTT)
Utilización de la CPU <1% 1% <1% <1%
Tiempo/seg. del sistema 4,867 seg. 4,902 seg. 4.293 4.325
Modelo DDM N/A (No 0,0538 seg. N/A (No 0,0715 seg.
tiempo/seg DDM) DDM)
Modelo SRV tiempo/seg N/A (No 0.000346 N/A (No 0.000617
SRV) sec SRV) sec
(sólo en (sólo en el
cliente) servidor)

Tabla IV: Análisis del rendimiento de los protocolos

MQTT y HTTP 1Tiempo del sistema: Calculamos el tiempo medio
de todos los dialectos (HTTP y MQTT). Sólo registramos el tiempo del
sistema para un handshake completo. Más concretamente, el tiempo que
tarda el dialecto en activarse hasta que recibe la confirmación del
dialecto de otra máquina.
2) Protocolo HTTP: HTTP es uno de los principales
protocolos utilizados en Internet. HTTP ayuda a los
usuarios a interactuar con recursos web como archivos
HTML mediante la transmisión de mensajes entre
sistemas cliente y servidor. En este protocolo, asumimos
que el servidor tiene que demostrar su autenticidad al
cliente, lo que significa que el dialecto del protocolo
comienza en el lado del servidor. Consideremos el
escenario de un comando GET, el cliente enviará una
petición GET al servidor, y el servidor responderá con un
cuerpo de datos HTML. Como prueba de concepto, para
mostrar la viabilidad de Verify-Pro en HTTP, creamos un
par de dialectos descritos en la Tabla V. Como puede
verse en la figura 7, la solicitud GET se utiliza para
recuperar el cuerpo HTML como respuesta de

21
 Nombre dialectal Mutaciones realizadas
Mutación del mensaje de respuesta El mensaje de respuesta (archivo
HTML
en la Fig.7) se envía en 5 paquetes
desde el servidor
Cambio de campo Para una solicitud dadai′R′ , la re-
sponse se envía en dos paquetes con
paquete 1- dos mensajes (ficheros
HTML) & paquete 2- sin cuerpo de
respuesta
Tabla V: Dialectos del protocolo HTTP.
escalable. Dadas sus ventajas en materia de seguridad, creemos
que Verify-Pro puede funcionar como una sólida capa de
protección adicional junto con los mecanismos de autenticación
existentes.
VIII. TRABAJOS RELACIONADOS
En esta sección, primero discutimos los esfuerzos existentes en
el análisis for- mal del método de huellas dactilares para identificar
bots y otros protocolos y luego comparamos nuestro enfoque con
los anteriores.

el almacenamiento del servidor. El módulo PDs comprende

dialectos con mutaciones realizadas en el cuerpo del mensaje.
La entrada de la red neuronal (DDM) para este protocolo es el
comando y el nombre del archivo HTML ('GET hola.html'). La
Tabla V presenta los dialectos de protocolo aplicados en el
protocolo HTTP. En el protocolo HTTP, nos centramos en la
respuesta (el archivo HTML recibido) para una solicitud
determinada (por ejemplo, GET hola.html HTTP/1.1). Nos
centramos principalmente en prevenir los ataques de secuestro
de sesión MITM (desvío de la solicitud de destino), los
ataques de confusión de contexto y los ataques HTTP DoS.
Como suponemos que el cliente es idealmente auténtico,
tendemos a proporcionar autenticación continua para cada
transacción, de forma que el servidor verifique su identidad
ante el cliente.
Para demostrar la viabilidad práctica de Verify-Pro,
implementamos un servidor HTTP atacante (A-server-sin
PDs y módulo DDM). Una vez establecida la conexión, la
petición de destino se redirige desde el cliente HTTP a un
servidor malicioso que utiliza capacidades MITM. El servidor
malicioso falla, ya que se realiza una autenticación continua
para cada petición en la sesión. Dado que el patrón de dialecto
del protocolo cliente cambia dinámicamente para cada
petición, al servidor malicioso le resulta difícil comprender el
patrón de evolución del dialecto generado por el módulo
DDM. El módulo SRV está programado de tal manera que,
para el dialecto, 'Di ' consiste en el patrón 'Pi '. Cualquier
desviación en este patrón resulta en la terminación de toda
la sesión del protocolo de comunicación. Por ejemplo,
consideremos una petición GET, con un hello.html a recibir
del servidor. Mutamos el mensaje de respuesta, como el envío
del cuerpo HTML en cinco paquetes diferentes. Sólo un
cliente auténtico sabe que para un dialecto n dado, el
cuerpo HTML se enviará en cinco paquetes. El módulo
SRV en el lado del cliente tiene las características
necesarias para identificar el formato del mensaje y
confirmar si el formato del mensaje es legítimo o
falsificado. Como puede verse en la Tabla IV, concluimos
que la adición de PD,
DDM, los módulos SRV incurren en una sobrecarga mínima
(< 0,8%) (del tiempo del sistema) de media para los
protocolos MQTT y HTTP en todos los dialectos
implementados. Nuestra solución, Verify-Pro, demuestra que
la autenticación continua se puede implementar con un
mínimo de
de los protocolos de comunicación y puede desplegarse de
forma incremental, lo que la convierte en una solución
22
 empíricos indican que Verify-Pro puede utilizarse para
trabajos. Muchos trabajos anteriores tratan sobre la toma detectar adversarios, ayudar a una comunicación eficaz
de huellas dactilares. Sin embargo, la mayoría de ellos se utilizando dialectos de protocolo y mejorar la seguridad,
centran en áreas diferentes. Numerosos estudios se incurriendo al mismo tiempo en una sobrecarga de ejecución
centran en la identificación de la presencia de tráfico insignificante del 0,536% (para FTP). Aunque los atacantes
HTTPS [35]. Hfinger [36] es una herramienta de podrían adaptarse al entorno Verify-Pro observando
fingerprinting de malware que extrae la información de pasivamente el tráfico, utilizando métodos de ingeniería
las partes de la petición, como URI, información de inversa, sostenemos que esto deteriora su rendimiento,
protocolo, cabeceras, etc., y genera huellas digitales. La flexibilidad e incurre en complejidades de coste y tiempo.
huella digital del protocolo DNS puede utilizarse como Esperamos que nuestra investigación permita a la comunidad
proceso para detectar ataques DDoS de amplificación y a los desarrolladores de programas prestar más atención al
DNS [37], identificar servidores DNS [38]. Cuando se refuerzo de la autenticación continua para los protocolos de
utilizan para obtener huellas dactilares del tráfico de red comunicación.
de malware, los enfoques conferidos pueden detectar
mensajes de spam, ataques DDoS e identificar unidades
familiares de malware. Los artículos [39], [40] se centran
en el origen del correo electrónico explorando las
características del remitente de un mensaje (por ejemplo,
la dirección IP) o evaluando si se trata de spam
aproximando la distancia geográfica entre el remitente y
el destinatario. Los notables trabajos de Stringhini et al.
[41], [42], presentan una conceptualización diferente. Los
investigadores se centraron en el análisis de la
comunicación de red observada durante el envío de un
mensaje por spam-bot al construir dialectos SMTP. Sus
resultados ejemplifican los errores en la implementación
del protocolo SMTP cometidos por los adversarios y, por
tanto, una perspectiva de clasificación. Ampliación del
trabajo Botnet Fingerprint- ing [43], los autores se centran
en el desarrollo de la detección y clasificación de
mensajes enviados por spam-bots. Utilizaron dialectos
SMTP e introdujeron mejoras en la noción de botnet
fingerprinting. Ouyang et al. [44] presentan un análisis
exhaustivo de la detección de spam a través de
características de red, como la IPTTL extraída del
paquete TCP SYN o el tiempo de terminación del apretón
de manos a tres bandas TCP. Los métodos existentes se
limitan a configuraciones del sistema de bajo nivel (por
ejemplo, dirección IP, handshakes a tres bandas TCP). En
contraste con estos trabajos, nuestro esquema se centra
principalmente en aprovechar las características de la
capa de aplicación en el diseño de dialectos de protocolo
y aplica la autenticación continua para cada solicitud en la
sesión. Verify-Pro genera dinámicamente respuestas de
servidor personalizadas utilizando dialectos de protocolo
para cada solicitud, lo que dificulta al atacante lanzar un
ataque potencial contra un protocolo de comunicación
que se autoadapta constantemente. Además, utilizamos un
Mecanismo de Decisión de Dialecto (DDM- red neuronal
personalizada) para activar un dialecto específico bajo la
premisa de dialectos de protocolo.
IX. CONCLUSIÓN
Presentamos un nuevo marco, Verify-Pro, cuyo
objetivo es utilizar las transacciones personalizadas,
dialectos como huellas dactilares durante la
comunicación, y seleccionar dinámicamente diferentes
dialectos basados en una solicitud única en la sesión para
obligar a la autenticación continua. Los resultados
23
 Como trabajo futuro, seguiremos incluyendo una variedad [18] A. Delignat-Lavaud y K. Bhargavan, "Network-based origin confusion
de dialectos de protocolo (número de dialectos) y entrenando attacks against https virtual hosting", en Proceedings of the 24th
International Conference on World Wide Web, ser. WWW '15.
el modelo para hacerlo más robusto. También exploraremos República y Cantón de Ginebra, CHE: International World Wide Web
estrategias de automatización que nos ayuden con el Conferences Steering Committee, 2015, p. 227-237. [En línea].
despliegue de dialectos de forma escalable. Available: https://doi.org/10.1145/2736277.2741089
[19] L. Breiman, J. Friedman, C. Stone y R. Olshen, "Classification and
regression trees chapman & hall", Nueva York, 1984.
REFERENCIA [20] A. R. Chordiya, S. Majumder, and A. Y. Javaid, "Man-in-the-middle
S (mitm) attack based hijacking of http traffic using open source tools," in
2018 IEEE International Conference on Electro/Information
Technology (EIT). IEEE, 2018, pp. 0438-0443.
[1] A. Acar, H. Fereidooni, T. Abera, A. K. Sikder, M. Miettinen, H. Aksu, [21] M. Antikainen, T. Aura, y M. Sa¨rela¨, "Spook in your network:
M. Conti, A.-R. Sadeghi, and S. Uluagac, "Peek-a-boo: I see your smart Attacking an sdn with a compromised openflow switch", en Nordic
home activities, even encrypted!" in Proceedings of the 13th ACM conference on secure IT systems. Springer, 2014, pp. 229-244.
Conference on Security and Privacy in Wireless and Mobile Networks, [22] H. Wong y T. Luo, "Man-in-the-middle attacks on mqtt-based iot using
2020, pp. 207-218. bert based adversarial message generation", KDD'20.
[2] D. Rupprecht, K. Kohls, T. Holz y C. Po¨pper, "Imp4gt: Impersonation [23] (2019) Man-in-the-middle tls protocol downgrade at- tack. [En línea].
attacks in 4g networks", en Symposium on Network and Distributed Disponible: https://www.praetorian.com/blog/ man-in-the-middle-tls-ssl-
System Security (NDSS). ISOC, 2020. protocol-downgrade-attack
[3] A. Delignat-Lavaud and K. Bhargavan, "Network-based origin confu- [24] S. Lee, Y. Shin, and J. Hur, "Return of version downgrade attack in the
sion attacks against https virtual hosting," in Proceedings of the 24th era of tls 1.3," in Proceedings of the 16th International Conference on
International Conference on World Wide Web, 2015, pp. 227-237. emerging Networking EXperiments and Technologies, 2020, pp. 157-
[4] R. Roberts, Y. Goldschlag, R . Walter, T. Chung, A. Mislove, y 168.
D. Levin, "You are who you appear to be: a longitudinal study of [25] M. Sjoholmsierchio, B. Hale, D. Lukaszewski y G. G. Xie, "Strength-
domain impersonation in tls certificates", en Proceedings of the 2019 ening sdn security: Protocol dialecting and downgrade attacks", arXiv
ACM SIGSAC Conference on Computer and Communications Security, preprint arXiv:2010.11870 , 2020.
2019, pp. 2489-2504. [26] X. d. C. de Carnavalet y M. Mannan, "Killed by proxy: Analyzing
[5] M. Zhang, X. Zheng, K. Shen, Z. Kong, C. Lu, Y. Wang, H. Duan, client-end tls interception software", en Network and Distributed System
S. Hao, B. Liu y M. Yang, "Talking with familiar strangers: An Security Symposium , 2016.
empirical study on https context confusion attacks", en Proceedings of [27] Z. Durumeric, Z. Ma, D. Springall, R. Barnes, N. Sullivan, E. Bursztein,
the 2020 ACM SIGSAC Conference on Computer and Communications M. Bailey, J. A. Halderman y V. Paxson, "The security impact of https
Security, ser. CCS '20. New York, NY, USA: Association for interception", en NDSS, 2017.
Computing Machinery, 2020, p. 1939-1952. [En línea]. Available: [28] T. Chung, D. Choffnes y A. Mislove, "Tunneling for transparency: A
https://doi.org/10.1145/3372297.3417252 large-scale analysis of end-to-end violations in the internet", en
[6] S. Frolov y E. Wustrow, "{HTTPT}: A probe-resistant proxy", en 10th Proceedings of the 2016 Internet Measurement Conference, 2016, pp.
{USENIX} Workshop on Free and Open Communications on the 199-213.
Internet ({FOCI} 20), 2020. [29] C. Soghoian y S. Stamm, "Certified lies: Detecting and defeating gov-
[7] C. Crane. (2020) La guía definitiva de estadísticas de ciberseguridad e r n m e n t interception attacks against ssl (short paper)", en
para 2020. [En línea]. Disponible: International Conference on Financial Cryptography and Data
https://www.thesslstore.com/blog/cyber-security-statistics/ Security. Springer,
#cyber-security-statistics-top-cyber-attack-and-data-breach-statistics-and-trends 2011, pp. 250-259.
[8] --. (2019) 80 estadísticas de ciberseguridad reveladoras para 2019. [En [30] B. Kondracki, A. Aliyeva, M. Egele, J. Polakis y N. Nikiforakis,
línea]. Disponible: https://www.thesslstore. com/blog/80-eye-opening- "Meddling middlemen: Empirical analysis of the risks of data-saving
cyber-security-statistics-for-2019/ mobile browsers", en 2020 IEEE Symposium on Security and Privacy
#estadísticas de ciberseguridad: tipos más comunes de ciberataques (SP). IEEE, 2020, pp. 810-824.
[9] D. MacLennan. (2020) La amenaza en el punto de mira: Conversation [31] (2019) Danami: Redirección de puertos/ ip. [En línea]. Disponible: https:
hi- jacking. [En línea]. Disponible: //docs.danami.com/juggernaut/user-guide/port-ip-redirection
https://blog.barracuda.com/2020/01/16/ threat-spotlight-conversation- [32] A. R. Chordiya, S. Majumder, and A. Y. Javaid, "Man-in-the-middle
hijacking/ (mitm) attack based hijacking of http traffic using open source tools," in
[10] J. Postel y J. Reynolds, "Protocolo de transferencia de archivos", 1985. 2018 IEEE International Conference on Electro/Information
[11] J. Dizdarevic', F. Carpio, A. Jukan, y X. Masip-Bruin, "A survey of Technology (EIT), 2018, pp. 0438-0443.
communication protocols for internet of things and related challenges of [33] F. Manessi, A. Rozza, S. Bianco, P. Napoletano y R. Schettini,
fog and cloud computing integration", ACM Computing Surveys "Automated pruning for deep neural network compression", en 2018
(CSUR), vol. 51, n.º 6, pp. 1-29, 2019. 24th International conference on pattern recognition (ICPR). IEEE,
[12] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and 2018,
T. Berners-Lee, "Hypertext transfer protocol-http/1.1", 1999. pp. 657-664.
[13] M. Calabretta, R. Pecori, M. Vecchio y L. Veltri, "Mqtt-auth: A token- [34] S. Han, H. Mao y W. J. Dally, "Deep compression: Compressing deep
based solution to endow mqtt with authentication and authorization neural networks with pruning, trained quantization and huffman
capabilities", Journal of Communications Software and Systems, vol. coding", arXiv preprint arXiv:1510.00149, 2015.
14, no. 4, pp. 320-331, 2018. [35] W. M. Shbair, T. Cholez, J. Francois e I. Chrisment, "A survey of https
[14] P. Grubbs. (2021) Los riesgos de seguridad de las claves precompartidas. traffic and services identification approaches", arXiv preprint
[En línea]. arXiv:2008.08339, 2020.
Disponible: https://www.securew2.com/blog/risks-pre-shared-keys-psks [36] P. Białczak y W. Mazurczyk, "Hfinger: Malware http request finger-
[15] Y. Liu, D. Dachman-Soled, and A. Srivastava, "Mitigating reverse printing", Entropy, vol. 23, no. 5, p. 507, 2021.
engineering attacks on deep neural networks," in 2019 IEEE Computer [37] C. Fachkha, E. Bou-Harb y M. Debbabi, "Fingerprinting internet dns
Society Annual Symposium on VLSI (ISVLSI). IEEE, 2019, pp. 657- 662. amplification ddos activities", en 2014 6th International Conference on
[16] X. Wang, R. Hou, Y. Zhu, J. Zhang y D. Meng, "Npufort: A secure New Technologies, Mobility and Security (NTMS). IEEE, 2014, pp. 1-5.
architecture of dnn accelerator against model inversion attack", en [38] T. Kim y H. Ju, "Effective dns server fingerprinting method", en 2011
Proceedings of the 16th ACM International Conference on Computing 13th Asia-Pacific Network Operations and Management Symposium.
Frontiers, 2019, pp. 190-196. IEEE, 2011, pp. 1-4.
[17] E. S. Alashwali y K. Rasmussen, "What's in a downgrade? a taxon- omy [39] S. Hao, N. A. Syed, N. Feamster, A. G. Gray y S. Krasser, "De- tecting
of downgrade attacks in the tls protocol and application protocols using spammers with snare: Spatio-temporal network-level automatic
tls", en International Conference on Security and Privacy in reputation engine", en USENIX security symposium, vol. 9, 2009.
Communication Systems. Springer, 2018, pp. 468-487.
24
[40] S. Venkataraman, S. Sen, O. Spatscheck, P. Haffner y D. Song,
"Exploiting network structure for proactive spam mitigation", 2007.
[41] G. Stringhini, M. Egele, A. Zarras, T. Holz, C. Kruegel y G. Vigna,
"B@ bel: Leveraging email delivery for spam mitigation", en 21st
{USENIX} Security Symposium ({USENIX} Security 12), 2012, pp. 16-
32.
[42] G. Stringhini, O. Hohlfeld, C. Kruegel y G. Vigna, "The harvester, the
botmaster, and the spammer: On the relations between the different
actors in the spam landscape", en Proceedings of the 9th ACM
symposium on Information, computer and communications security,
2014, pp. 353- 364.
[43] P. Bazydlo, K. Lasota y A. Kozakiewicz, "Botnet fingerprinting:
Anomaly detection in smtp conversations", IEEE Security & Privacy,
vol. 15, n.º 6, p. 25-32, nov. 2017. [En línea]. Disponible: http:
//dx.doi.org/10.1109/MSP.2017.4251116
[44] T. Ouyang, S. Ray, M. Allman y M. Rabinovich, "A large-scale em-
pirical analysis of email spam detection through network characteristics
in a stand-alone enterprise", Computer Networks, vol. 59, pp. 101-121,
2014.
[45] R. Beverly y K. Sollins, "Exploiting transport-level characteristics of
spam", 2008.
[46] G. Kakavelakis y J. Young, "Auto-learning of smtp tcp transport-layer
features for spam and abusive message detection", en LISA, 2011, pp.
18-18.
[47] S. V. Radhakrishnan, A. S. Uluagac y R. Beyah, "Gtid: A technique for
physical device and device type fingerprinting", IEEE Transactions on
Dependable and Secure Computing, vol. 12, no. 5, pp. 519-532, 2014.
[48] J. P. John, A. Moshchuk, S. D. Gribble, A. Krishnamurthy et al.,
"Studying spamming botnets using botlab", en NSDI, vol. 9, nº 2009,
2009.
ANEXO
Dialectos FTP. Creamos una variedad de dialectos Appx. X
utilizando técnicas cambiando las reglas de comunicación
como la mutación de paquetes, generando diferentes
peticiones-respuestas, comunicando sólo con números. Por
ejemplo, en el dialecto 5, la comunicación ocurre con números
- 1 (el archivo existe), comunicación inversa (explicada en el
dialecto 14, donde el archivo es transferido, pero el protocolo
handshake es asumido como inverso al proceso). El dialecto 7
incluye estadísticas como el tiempo de transferencia y divide
el fichero y lo envía en subpaquetes para aumentar
intencionadamente el tiempo del handshake. Nuestro principal
objetivo es detectar al adversario en la fase inicial de un
handshake para que el cliente pueda terminar la conexión sin
ni siquiera entrar en el proceso de transferencia de archivos.
Como este trabajo es una prueba de concepto, sólo
desplegamos 15 dialectos, pero cuando el número de dialectos
aumenta, al adversario le resulta aún más difícil adivinar el
dialecto correcto. La Tabla VII representa el tiempo que tarda
cada dialecto en completar el handshake en las máquinas
cliente y servidor. Existen variaciones modestas debido a las
diversas variaciones en la transferencia de datos. Aparte de la
respuesta del servidor, también se producen variaciones en la
respuesta del cliente tras la verificación. Además, el servidor
envía el archivo de diferentes maneras (dividir el archivo en
múltiples bloques de datos, compresión, etc.) se explorará en
futuros trabajos para probar la autenticación bidireccional.
11 Petición: obtener
nombre de archivo
Petición: Número de
puerto Respuesta: El

X. DIALECTOS FTP CON PARES SOLICITUD-RESPUESTA

fichero existe
Respuesta: tamaño
Número de Pares solicitud-respuesta del fichero
dialecto Respuesta: Nombre del archivo, longitud del nombre del archivo
Respuesta: comando, longitud del comando
1 Petición: obtener nombre de
12 Petición: obtener
archivo Petición: Número de
nombre de fichero
puerto Respuesta: El fichero
existe, tamaño del fichero Petición: Número de
Compartir archivos - Sólo después de que el cliente verifique la puerto Respuesta:
respuesta del servidor tamaño del archivo
2 Petición: obtener 13 Petición: obtener
nombre de archivo nombre de archivo
Petición: Número de Petición: Número de
puerto puerto
Respuesta: tamaño del archivo, tamaño del archivo d Respuesta: El archivo existe, nombre de archivo,comando
tamaño del archivo enviado dos veces Respuesta: longitud del nombre del archivo
Respuesta: Conexión cerrada 14 Petición: obtener nombre de
3 Petición: obtener archivo Petición: Número de
nombre de archivo puerto Respuesta: El fichero
Petición: Número de no existe Respuesta: -(tamaño
puerto del fichero)
Respuesta: Archivo existente, tamaño del archivo, nombre del
archivo 15 Petición: obtener
4 Petición: obtener nombre de nombre de archivo
archivo Petición: Número de Petición: Número de
puerto Respuesta: File size/2 puerto Respuesta: El
Respuesta: Tamaño restante archivo existe
del fichero Respuesta: tamaño
5 Petición: obtener del archivo
nombre de archivo Respuesta: Nombre
Petición: Número de del fichero Respuesta:
puerto comando
Respuesta: Longitud del comando
Respuesta: 1 (el fichero existe), longitud del nombre del fichero,
longitud del comando
Respuesta: Tamaño del fichero
6 Petición: obtener
nombre de archivo
Petición: Número de
puerto Respuesta: El
fichero existe
Respuesta: longitud del nombre de archivo, longitud del comando
Respuesta: Tamaño del archivo
7 Petición: obtener nombre de
archivo Petición: Número de
puerto Respuesta: El fichero
existe Respuesta: Longitud
del fichero
Respuesta: Longitud del comando
8 Petición: obtener
nombre de archivo
Petición: Número de
puerto
Respuesta: El archivo existe, tamaño del archivo, nombre del
archivo,comando
9 Petición: obtener
nombre de archivo
Petición: Número de
puerto
Respuesta: El fichero existe, tamaño del fichero
Respuesta: filename, command
10 Petición: obtener
nombre de archivo
Petición: Número de
puerto Respuesta: El
fichero existe
Respuesta: tamaño del archivo,nombre del archivo,comando

25
A. Descripción del conjunto de datos para los módulos
DDM y SRV
1) Descripción del conjunto de datos para DDM:
Utilizamos el corpus de palabras en lenguaje
natural (https://norvig.com/ngrams/) para crear un
conjunto de datos personalizado. Nuestra red
neuronal requiere que la entrada sea la "petición"
del protocolo de comunicación. Construimos un
nuevo conjunto de entrenamiento candidato
utilizando una lista de palabras del mundo real del
corpus NLP. Por ejemplo
un protocolo FTP. Nuestro conjunto de datos debe
tener un formato "get filename", añadimos un
comando - get y la extensión del archivo a las
palabras. Utilizamos este conjunto de datos
personalizado como principal conjunto de datos de
entrenamiento y evaluación. Esto nos permite
examinar las propiedades de generalización del
modelo para nuevos ejemplos no vistos. El
conjunto de datos sólo incluye la lista de peticiones
(p. ej., "obtener nombre de archivo"), ya que el
modelo se construye de forma no supervisada y
contiene un gran conjunto de 150.000 peticiones
de muestra sin etiquetar. En este trabajo, tendemos
a diseñar una red neuronal personalizada sin
ground truth. Basándonos en las propiedades que
utilizamos en las funciones de pérdida
(uniformidad, coste como criterio para la selección
de dialecto y pérdida consolidada), el modelo
tendrá que predecir los números de dialecto para
cada solicitud.
2) Descripción del conjunto de datos para SRV:
Nuestro objetivo es entrenar un clasificador
utilizando este tipo de datos y construir
eficazmente un árbol de decisión que clasifique las
muestras. Sólo necesitamos el patrón y el tipo de
datos de cada campo de la respuesta, y utilizamos
un script de python para generar el conjunto de
datos con 150.000 muestras. Creamos un conjunto
de datos estándar utilizando un script de python
(de 150 líneas de código) para generar cadenas y
enteros aleatorios en paquetes y campos concretos.
Cada dato tiene 31 características, y el número
total de etiquetas es de 15. En el mecanismo de
verificación SRV, el cliente sólo comprueba el
patrón (estructura de la respuesta) enviado por el
servidor (creamos respuestas diferentes para cada
dialecto del protocolo FTP para evitar el
solapamiento de dialectos).

26
 XI. CONVERSACIONES FTP ORIGINAL Y FTP MODIFICADO XII. DETALLES COMPLETOS

Por defecto:
Cliente: get hello. txtd Descargar hello.txt del
almacenamiento en disco del servidor
Servidor: 226 Transferencia completada d Archivo
transferido

Modificado: Ejemplo de dialecto 10

Cliente: get hello. txtd Descargar hello.txt del
almacenamiento en disco del servidor Figura 6: Formato del paquete de publicación MQTT.
Servidor: El archivo existe
Servidor: 20,hola.txt,get d 20 es el tamaño del archivo en
bytes, hola.txt es el nombre del archivo, get es el comando
Cliente: Listo para recibir el archivo.
Cliente: Conexión cerrada, archivo recibido.

A. Cliente FTP legítimo y servidor legítimo vs. Cliente FTP

legítimo y servidor malicioso (Servidor A)
comunicación plantillas
Cliente: ftp> obtener hola.txt
usando dialecto 9
(Control) Conexión obtenida desde ('127.0.0.1',
60068) 200 PORT command successful
Tiempo empleado:
1.056454 seg Archivo
recibido con éxito
Servidor:
request: ['rget','hola.txt'], dialect:9
using dialect D9
(Control) El puerto de datos es 33345
Enviando fichero hola.txt al cliente
127.0.0.1 Tiempo empleado: 1.00464363 Figura 7: Formato del paquete de solicitud-respuesta HTTP-
seg GET.

Cliente: ftp> obtener hola.txt

usando dialecto 12 A. Análisis de Verify-Pro con las técnicas existentes
(Control) Conexión obtenida desde ('127.0.0.1', En esta sección, la Tabla VI describe las contramedidas
56768) 200 PORT command successful existentes contra el secuestro de sesiones MITM,
Error de dialecto, el servidor no se comunicó en el dialecto proxies/software de interceptación, spammers, etc., en
correcto. relación con las consideraciones de despliegue. La dificultad
Tiempo empleado: 0.00056454 seg se refiere a la evaluación global de la integración de los
Servidor A: módulos PD, DDM y SRV correspondientes, y a los costes
request:['rget','hola.txt'] monetarios, de mano de obra y de tiempo. La característica de
Envío de un mensaje malformado → El archivo no compatibilidad indica el número de protocolos de
e comunicación compatibles con las tecnologías propuestas.
xisted No hay dialectos ni módulo DDM. Así que el servidor
malicioso no sabe cuál es el formato de mensaje para el B. Plazos concretos de los dialectos en el FTP
dialecto 9 & no hay módulo DDM a qué dialecto se debe
*Estas
utilizarconversaciones
para cada muestran las plantillas de transacciones Plazos de las plantillas de dialectos
de comunicación
solicitar cliente-servidor genuinas y servidor Número de dialecto Tiempo de apretón de manos completo (seg)
malformado. Por ejemplo, la conversación de la parte superior Dialecto 1 Cliente:0.0623 seg & Servidor:0.00841 seg
d Transacción fallida Dialecto 4 Cliente:0.0931 seg & Servidor:0.0083 seg
indica una transacción 'exitosaƒul' con el tiempo (tomado por Dialecto 7 Cliente:4.085 seg & Servidor:4.0556 seg
cliente y servidor) dis- puesto, uso de dialecto, nombre de host Dialecto 8 Cliente:0,0075 seg & Servidor:0,0017 seg
y números de puerto. Por el contrario, la parte inferior indica Dialecto 9 Cliente:0.0815 seg & Servidor:0.00868 seg
Dialecto 10 Cliente:0,017 seg & Servidor:0,049 seg
la transacción fallida cuando se comunica con un servidor Dialecto 12 Cliente:0.052 seg & Servidor:0.00856 seg
atacante.
27
Cuadro VII: Diversos dialectos con sus respectivas
cronologías.

28
 Comparación de las contramedidas existentes con Verify-
Pro
Contramedidas Dificultad Coste Au- continuo Características Compatibilidad con mul- Automatizaci
thentication protocolos individuales ón
Detección de spam [45], [46] Medio Medio × Características del nivel de No (sólo para SMTP) Sí
transporte
SNARE[39] Alta Alta × Funciones de red No Sí
GTID[47] Alta Alta × Flujos a nivel IP Sí Sí
Botlab[48] Medio Medio × Nivel de red No Sí
Verificar-Pro[este documento] Medio Bajo Funciones de la capa de Sí Sí
aplicación

Tabla VI: Comparación de las contramedidas existentes con Verify-Pro.

Enumeramos los marcos temporales, para dialectos
particulares-desde la llamada a la función do get (comando
get) en el cliente, la llamada a la función send file en el
servidor, hasta la transferencia de archivos de
20 bytes al cliente, para cada dialecto-tiempo de biblioteca del
paquete python se importa para anotar el tiempo exacto para
mostrar la diferencia entre algunos dialectos de Verify-Pro en
la Tabla VII. De la tabla, se deduce que los dialectos
(Verificar-Pro) con sus mutaciones varían en el tiempo de
ejecución (insignificante diferencia de sobrecarga de
ejecución en la ruta de ejecución para cada plantilla de
dialecto). Desde el punto de vista de Verify-Pro, sólo se puede
ejecutar un dialecto Di para una única solicitud Ri . Por lo
tanto, no habrá ninguna sobrecarga de ejecución en segundo
plano que pueda afectar al dialecto que ya se está procesando.
Nos referimos al protocolo FTP:
https://github.com/ShripadMhetre/FTP- Python como el FTP
estándar. Ejecutamos los comandos con el mismo tamaño de
archivo 20 veces y calculamos la media para evitar posibles
sesgos. Llegamos a la conclusión de que nuestros desarrollos
adicionales (con módulo SRV, diferentes peticiones-
respuestas) no de- terioran el FTP estándar incurriendo en
sobrecarga de ejecución, ya que todos los PD adicionales se
generan como instancias separadas.

29