ES2932499T3 - Procedimiento de asignación de un identificador a un nodo de cliente, procedimiento de registro de un identificador, dispositivo, nodo de cliente, servidor y programas de ordenador correspondientes - Google Patents

Procedimiento de asignación de un identificador a un nodo de cliente, procedimiento de registro de un identificador, dispositivo, nodo de cliente, servidor y programas de ordenador correspondientes Download PDF

Info

Publication number
ES2932499T3
ES2932499T3 ES19802235T ES19802235T ES2932499T3 ES 2932499 T3 ES2932499 T3 ES 2932499T3 ES 19802235 T ES19802235 T ES 19802235T ES 19802235 T ES19802235 T ES 19802235T ES 2932499 T3 ES2932499 T3 ES 2932499T3
Authority
ES
Spain
Prior art keywords
client
client node
identifier
domain
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES19802235T
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Application granted granted Critical
Publication of ES2932499T3 publication Critical patent/ES2932499T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

La invención se refiere a un método para asignar un identificador a un primer nodo cliente de un dominio cliente, siendo dicho primer nodo cliente adecuado para gestionar el tráfico asociado al dominio cliente con el fin de protegerlo contra un ataque informático, comprendiendo dicho método: - recibir una solicitud del primer nodo de cliente para la asignación de un identificador de nodo de cliente, comprendiendo dicha solicitud al menos una pieza de información de identificación del nodo de cliente; - obtener una lista de identificadores de nodos de clientes ya asignados a los nodos de clientes activos, al menos en el dominio de clientes; - asignar, al primer nodo de cliente, un identificador de nodo de cliente que no pertenece a la lista obtenida; - registrar, en una memoria local, una asociación entre el identificador asignado y la información de identificación del primer nodo cliente; (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento de asignación de un identificador a un nodo de cliente, procedimiento de registro de un identificador, dispositivo, nodo de cliente, servidor y programas de ordenador correspondientes
1. Campo de la invención
El campo de la invención es el de las comunicaciones dentro de una red de comunicación, por ejemplo, una red IP, y especialmente el de los servicios IP de valor agregado. Más precisamente, la invención ofrece una solución para proteger la red de comunicación y los terminales conectados a esta red contra los ataques informáticos.
En particular, la invención ofrece una solución que permita asignar un identificador único a un nodo de cliente conectado al dominio de cliente y registrar este identificador en asociación con un identificador del dominio de cliente.
La invención encuentra, especialmente, aplicaciones en el campo de la mitigación de ataques por denegación de servicios distribuidos (en inglés DDoS, para «Distributed Denial of Service»), implementando, por ejemplo, pero no exclusivamente, una arquitectura de tipo DOTS (en inglés «DDoS Open Threat Signaling»), tal como lo estandarizado por el IETF.
2. T écnica anterior y sus inconvenientes
Como recordatorio, un ataque DDoS es un intento de hacer que los recursos, por ejemplo, los recursos de red o de cálculo, no estén disponibles para sus usuarios. Tales ataques se pueden desplegar masivamente comprometiendo un gran número de hosts, y utilizando estos hosts para amplificar los ataques.
Con el fin de remediar estos ataques DDoS, se proponen servicios de detección y de mitigación de los ataques DDoS para determinados proveedores de acceso o de servicios a sus clientes. Tales servicios de mitigación (en inglés DPS para «DDoS Protection Services») pueden ser alojados dentro de las infraestructuras operadas por los proveedores de acceso o en la «nube» (en francés «nuage»). Especialmente, permiten distinguir el tráfico «legítimo», es decir, los datos consentidos por el usuario, del tráfico «sospechoso».
Cuando un servicio de tipo DPS está alojado en la «nube», es difícil identificar un ataque DDoS de manera anticipada, ya que un tal servicio no está presente en las rutas de enrutamiento (por defecto) que permiten unirse a la red víctima de un ataque DDoS.
Para resolver este problema, se ha propuesto, especialmente, establecer túneles para forzar el tráfico (entrante o saliente) en un sitio o una red destinada a ser inspeccionada por el servicio DPS. Sin embargo, este enfoque aumenta de manera considerable la latencia observada por los usuarios e impone restricciones de dimensionamiento del servicio DPS para estar en condiciones de procesar todo el tráfico entrante o saliente de todos los usuarios de la red. Además, los túneles constituyen vectores de ataque potenciales y comprobados.
Cuando un servicio de tipo DPS está alojado dentro de una infraestructura operada por un proveedor de acceso, incluso si el servicio DPS está presente en la ruta de enrutamiento del tráfico entrante o saliente de una red, pueden surgir dificultades para la identificación del tráfico sospechoso. Especialmente, con el aumento del tráfico cifrado, transportado en particular sobre UDP (por ejemplo, el tráfico QUIC, para «Quick UDP Internet Connection» en inglés), es difícil distinguir el tráfico legítimo del tráfico sospechoso. La dificultad de acceder a los mensajes de control en texto claro, tales como los mensajes «SYN/SYN-ACK/ACK» previstos en el protocolo TCP, puede además hacer compleja la verificación del consentimiento de un nodo de la red para recibir el tráfico.
Con el fin de ayudar a la identificación del tráfico sospechoso, el IETF ha estandarizado una arquitectura específica. Una tal arquitectura, denominada DOTS, permite que un nodo de cliente, denominado cliente DOTS, informe a un servidor, denominado servidor DOTS, que ha detectado un ataque DDoS y que se requieren las acciones adecuadas para contrarrestar este ataque.
Por tanto, si un dominio de cliente es el objetivo de un ataque DDoS, un cliente DOTS que hace parte de este dominio de cliente puede enviar un mensaje a un servidor DOTS para solicitar ayuda. Este último coordina, con una entidad de mitigación (en inglés «mitigator»), las acciones por efectuar para que el tráfico sospechoso, asociado al ataque de denegación de servicio, no sea enrutado más hacia el dominio de cliente, mientras que el tráfico legítimo continúa para ser enrutado normalmente hacia el dominio de cliente. La entidad de mitigación puede ser coubicada con el servidor DOTS.
Esta solución utiliza dos canales de comunicación entre un cliente DOTS y un servidor DOTS:
- un canal de señalización DOTS (en inglés «DOTS Signal Channel»), y
- un canal de datos DOTS (en inglés DOTS «Data Channel»).
El canal de señalización DOTS se utiliza cuando está en curso un ataque DDoS. Por tanto, un cliente DOTS puede utilizar este canal para solicitar la ayuda de un servidor DOTS. Por ejemplo, un cliente DOTS utiliza este canal de señalización para enviar una solicitud al servidor informándole que el prefijo «1.2.3.0/24» es objeto de un ataque DDoS, con el fin de que el servidor pueda iniciar acciones para poner fin al ataque. Una tal solicitud está asociada con un cliente DOTS identificado por un identificador único, indicado por ejemplo CUID («Client Unique IDentifier»).
Por tanto, un servidor DOTS puede tomar las medidas apropiadas para poner fin a un ataque DDoS, por un lado, si la solicitud procedente del cliente DOTS no está en conflicto con otras solicitudes procedentes de otros clientes DOTS del mismo dominio de cliente, o con una regla de filtrado instalada de manera previa en el servidor por otro cliente DOTS del dominio de cliente, y por otro lado si el servidor está habilitado a/configurado para cumplir la última solicitud recibida. En caso de conflicto, el servidor puede enviar un mensaje de error, por ejemplo, de tipo 4.09 («Conflict»), para informar al cliente DOTS.
Un tal canal de señalización es especialmente descrito en el documento «Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification», draft-ietf-dots-signal-channel, Reddy, T. y al., enero de 2018.
El canal de datos DOTS se utiliza cuando no hay ningún ataque DDoS en curso. Por ejemplo, un cliente DOTS puede utilizar este canal para instalar las reglas de filtrado, tales como el filtrado del tráfico recibido de determinadas direcciones o el destinado a un nodo determinado. Por ejemplo, un cliente DOTS puede utilizar este canal de datos DOTS para solicitarle al servidor que bloquee todo el tráfico destinado al prefijo «1.2.3.0/24», o todo el tráfico UDP destinado al número de puerto 443.
El servidor DOTS puede proceder con la instalación de reglas de filtrado en respuesta a una solicitud enviada por un cliente DOTS, si esta solicitud no está en conflicto con otras solicitudes que provienen de otros clientes DOTs del mismo dominio de cliente o con una regla de filtrado existente. En caso de conflicto con otras reglas mantenidas por el servidor DOTS, el servidor puede enviar un mensaje de error, por ejemplo, de tipo 409 («Conflict»), para informar al cliente DOTS.
Un tal canal de datos es especialmente descrito en el documento «Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel», draft-ietf-dots-data-channel, Boucadair M. y al., diciembre de 2017.
Según el procedimiento descrito en los dos documentos antes mencionados, existe un riesgo de que un servidor DOTS rechace procesar una solicitud de mitigación de ataque emitida por un cliente DOTS cuando el ataque es real, o rechace solicitudes de filtrado emitidas por un cliente DOTS. (siendo un objetivo de las solicitudes de filtrado anticipar los ataques DDoS). Un tal rechazo puede ocurrir especialmente cuando estas solicitudes de filtrado están en conflicto con las reglas de filtrado instaladas por otros clientes DOTS de un mismo dominio de cliente.
Sin embargo, la eliminación de estas reglas por otro nodo de cliente del mismo dominio es imposible y el nodo de cliente en el origen de la solicitud de mitigación de ataque no dispone de ninguna información referente a la identidad del nodo de cliente que ha instalado estas reglas.
También puede ser que estas reglas ya no estén justificadas, porque están desactualizadas (en inglés «stale») y que el cliente DOTS en el origen de estas reglas no esté preocupado por desinstalarlas.
Además, pueden producirse complicaciones en caso de colisión entre los identificadores utilizados por los clientes DOTS de un mismo dominio. Por ejemplo, la mitigación de un ataque DDoS puede tomar más tiempo si el servidor DOTS detecta que el identificador utilizado por el cliente DOTS que origina la solicitud de mitigación está en conflicto con el de otro cliente DOTS del mismo dominio de cliente.
Por lo tanto, existe una necesidad de una nueva técnica, que permita mejorar la fiabilidad y la seguridad de los intercambios entre los clientes y el servidor DOTS y, por tanto, establecer una protección eficaz contra los ataques informáticos, especialmente los ataques por denegación de servicio.
3. Exposición de la invención
Según al menos un modo de realización, la invención se refiere a un procedimiento se asignación de un identificador a un primer nodo de cliente de un dominio de cliente, siendo el dicho primer nodo de cliente capaz de gestionar el tráfico asociado al dominio de cliente con el fin de protegerlo contra un ataque informático, comprendiendo el dicho procedimiento:
- la recepción de una solicitud de asignación de un identificador de nodo de cliente procedente del primer nodo de cliente, comprendiendo la dicha solicitud al menos una información de identificación del nodo de cliente;
- la obtención de una lista de identificadores de nodos de cliente ya asignados a los nodos de cliente activos al menos en el dominio de cliente;
- la asignación al dicho primer nodo de cliente de un identificador de nodo de cliente que no pertenece a la lista obtenida;
- el registro en una memoria local de una asociación entre el identificador asignado y la información de identificación del primer nodo de cliente;
- la emisión de una respuesta destinada al primer nodo de cliente, comprendiendo el identificador asignado; y - la emisión de una solicitud de registro del identificador asignado al primer nodo de cliente en el dominio a al menos un servidor de gestión del tráfico asociado al dominio.
Por tanto, la invención propone una gestión controlada de los identificadores utilizados por los nodos de cliente de un dominio de cliente para comunicarse entre sí y con un servidor de gestión del tráfico asociado al dominio de cliente. Según este modo de realización, garantiza la unicidad del identificador asignado al primer nodo cuando pasa a estar activo en el dominio y, por tanto, permite evitar los conflictos de identificación entre nodos activos.
Cabe señalar que el procedimiento puede ser implementado por otro nodo de cliente, beneficiándose de privilegios en el dominio de cliente, denominado cliente maestro, o por una instancia de software dedicada, denominada CMI (CUID Management Instance) la cual interactúa con el nodo de cliente maestro. También puede haber uno o más servidores involucrados en la mitigación de ataques informáticos, por ejemplo, de denegación de servicio, soportados por un mismo dominio de cliente.
Según un modo de realización particular, sobre la detección de un evento relativo a una actividad del dominio de cliente, el procedimiento comprende una modificación de la asociación registrada en la memoria local.
Por tanto, según este modo de realización, la gestión del identificador asignado al primer nodo de cliente se controla durante todo el periodo de conexión del nodo al dominio de cliente.
En particular, el evento detectado pertenece a un grupo que comprende:
- la inactividad del primer nodo de cliente;
- un comportamiento sospechoso del primer nodo de cliente;
- la recepción de una solicitud de eliminación recibida del primer nodo de cliente; y
- un número de nodos de clientes activados en el dominio demasiado elevado con respecto a un número máximo autorizado.
Cabe señalar que el evento puede referirse tanto a un cambio en la actividad del primer nodo de cliente, o en la política de seguridad o administración del dominio de cliente.
Según un primer ejemplo de realización, la modificación comprende la eliminación del registro, y el procedimiento comprende la emisión de una solicitud de cancelación del registro del identificador asignado al servidor.
Por tanto, este primer ejemplo de realización permite la repercusión al nivel del servidor de la eliminación de la asociación (cliente, cuid). Por tanto, el identificador asignado al primer cliente se libera y puede asignarse a otro nodo de cliente activo.
Según un segundo ejemplo de realización, la modificación comprende una sustitución, en el registro de la memoria local, de la información de identificación del primer cliente por una información de identificación de un segundo cliente del dominio.
Por tanto, este segundo modo de realización permite facilitar la sustitución del primer nodo de cliente por un segundo, sin modificar las acciones de mitigación instaladas por el primer nodo de cliente y, en consecuencia, sin perturbar la ejecución en curso de estas acciones de mitigación. El segundo nodo de cliente reanudará el procesamiento de las acciones de mitigación implementadas de manera previa por el primer nodo de cliente. No es necesario, según este ejemplo, hacer repercutir esta modificación al servidor, ya que este ya almacena la asociación correcta entre el identificador único de nodo de cliente y el identificador de dominio.
Según un modo de realización particular, la solicitud recibida comprende además una solicitud de asignación de un atributo de delegación de gestión, estando el dicho atributo destinado para ser especificado por otro nodo de cliente en una solicitud de procesamiento de una regla de gestión de tráfico transmitida al servidor para delegar al primer nodo de cliente la gestión de la dicha regla de gestión de tráfico, el procedimiento comprende:
- la asignación de un atributo de delegación al primer nodo de cliente,
- el almacenamiento del atributo asignado con la asociación en el registro, y
- la respuesta emitida al primer nodo de cliente comprende el atributo de delegación asignado.
Según este modo de realización, el atributo de delegación puede ser especificado por el primer nodo de cliente durante la instalación de una regla (filtrado, ACL, etc.) después de la ejecución de una acción de mitigación con el servidor, de modo que indique que otorga una delegación sobre la acción de mitigación. A continuación, el servidor almacena el atributo de delegación en asociación con la regla instalada. El conocimiento de este atributo de delegación asignado al primer nodo de cliente puede transmitirse a otro nodo de cliente con el fin de permitirle modificar la regla instalada por el primer nodo de cliente. Para realizar esto, el segundo nodo de cliente deberá insertar el valor de este atributo de delegación en su solicitud de modificación de la regla en cuestión y dirigida al servidor.
Por ejemplo, la respuesta comprende además el atributo de delegación asignado a al menos otro nodo de cliente. De esta manera, varios nodos de clientes del dominio comparten el mismo atributo de delegación, lo cual les permite intervenir sobre una regla instalada por otro nodo de cliente cuando sea necesario. Una ventaja de esta solución es ser simple y optimizar el servicio de protección.
Por el contrario, cuando la respuesta recibida del nodo de cliente maestro o de la entidad CMI no comprende un atributo de delegación, esto significa que el nodo de cliente maestro o la entidad CMI desea desactivar el procedimiento de delegación, por ejemplo, porque induce una carga excesiva en determinados nodos clientes del dominio.
En otro modo de realización, la invención se refiere a un procedimiento de registro de un identificador asignado a un nodo de cliente capaz de gestionar el tráfico asociado a un dominio de cliente con el fin de protegerlo contra un ataque informático, implementado en un servidor, comprendiendo el procedimiento:
- la recepción de una solicitud de registro de un primer nodo de cliente, comprendiendo la dicha solicitud un identificador del primer nodo de cliente, habiendo sido el dicho identificador asignado al primer nodo de cliente de acuerdo con el procedimiento de asignación, tal como se ha descrito anteriormente;
- la obtención de un identificador del dominio de cliente al cual pertenece el nodo de cliente; y
- el registro en una memoria del identificador del primer nodo de cliente asociado al identificador del dominio de cliente obtenido.
Según este modo de realización, la invención propone registrar al nivel del servidor una asociación entre el identificador único asignado al nodo de cliente y el identificador del dominio de cliente, lo cual permite asegurar los intercambios entre los nodos de clientes y el servidor para gestionar el tráfico asociado al dominio de cliente y garantizar la unicidad global del identificador constituido por el par {CUID, CDID}.
En particular, en la recepción de una solicitud de procesamiento de una regla de gestión de tráfico emitida por el nodo de cliente, comprendiendo la dicha solicitud el identificador del primer nodo de cliente, el procedimiento comprende la búsqueda del dicho registro en una memoria y el rechazo de la solicitud si no se ha encontrado el dicho registro. Por tanto, se facilita la detección de un nodo de cliente malicioso perteneciente por ejemplo a otro dominio de cliente, y es posible rechazar la solicitud si el nodo es malicioso.
Según un modo de realización particular, cuando la solicitud de procesamiento comprende una solicitud de modificación de una regla de gestión de tráfico instalada por un segundo nodo de cliente, el procedimiento comprende: - la verificación de una delegación de gestión mediante comparación de un primer atributo de delegación de gestión especificado en la solicitud de modificación de la regla de gestión de tráfico y de un segundo atributo de delegación de gestión asociado con la regla de gestión de tráfico instalado por el segundo nodo de cliente en un registro almacenado en la memoria;
- cuando el primer y el segundo atributos de delegación tengan el mismo valor, modificación de la regla de gestión de tráfico de acuerdo con la solicitud.
Por tanto, este procedimiento de delegación permite hacer migrar la gestión de una acción de mitigación en caso de indisponibilidad del nodo de cliente que origino su instalación. Es particularmente interesante, en caso de un ataque, cuando un nodo de cliente ha emitido de manera previa una solicitud de mitigación al servidor que había respondido que existía un conflicto entre su solicitud y al menos una regla ya instalada por otro nodo de cliente después de la ejecución de una acción de mitigación. Con la invención, el nodo de cliente el cual detecta el ataque puede aprovechar el procedimiento de delegación para solicitar al servidor que modifique la regla de modo que ya no sea más un obstáculo para la mitigación del ataque en curso. Por lo tanto, se incrementa la fiabilidad del servicio de mitigación de ataques.
En particular, en la recepción de una solicitud de eliminación de registro del identificador del primer nodo de cliente, el procedimiento comprende la eliminación del dicho registro y la eliminación de las reglas de gestión de tráfico instaladas por el primer nodo de cliente.
Según un modo de realización particular, el procedimiento de registro de un identificador comprende la notificación de otros nodos de clientes activos en el dominio de cliente, de manera previa a la dicha eliminación de las reglas de gestión de tráfico instaladas por el primer nodo de cliente.
Por tanto, es posible informar a los otros nodos de clientes de la eliminación inminente de reglas instaladas por un cliente para la mitigación de un ataque, y darles la posibilidad de solicitar al servidor que las migre para su beneficio.
Según otro modo de realización, la invención se refiere a un dispositivo de asignación de un identificador a un primer nodo de cliente capaz de gestionar el tráfico asociado a un dominio de cliente con el fin de protegerlo contra un ataque informático, comprendiendo el dicho dispositivo al menos una máquina de cálculo programable o una máquina de cálculo dedicada y configurada para implementar:
- la recepción de una solicitud de asignación de un identificador de nodo de cliente procedente del primer nodo de cliente, comprendiendo la dicha solicitud al menos una información de identificación del nodo de cliente;
- la obtención de una lista de identificadores de nodos de clientes ya asignados a los nodos de clientes activos al menos en el dominio de cliente;
- la asignación al primer nodo de cliente de un identificador de nodo de cliente que no pertenece a la lista obtenida; - el registro en una memoria local de una asociación entre el identificador asignado y la información de identificación del primer nodo de cliente;
- la emisión de una respuesta destinada al primer nodo de cliente, que comprende el identificador asignado; y - la emisión de una solicitud de registro del identificador asignado al primer nodo de cliente en el dominio a al menos un servidor de gestión del tráfico asociado al dominio.
Otros modos de realización se refieren a un nodo de cliente y un servidor correspondientes.
En otro modo de realización, la invención se refiere a uno o más programas de ordenador que incluyen instrucciones para la implementación de un procedimiento según al menos un modo de realización de la invención, cuando este o estos programas es/son ejecutado(s) por un procesador.
En aún otro modo de realización, la invención se refiere a uno o más soportes de informaciones, inamovibles, o de manera parcial o totalmente amovibles, legibles por un ordenador, y que incluyen instrucciones de uno o más programas de ordenador para la ejecución de un procedimiento según al menos un modo de realización de la invención.
Por lo tanto, los procedimientos según la invención se pueden implementar de varias maneras, especialmente en forma de cable y/o en forma de software.
4. Lista de las figuras
Otros objetivos, características y ventajas de la invención aparecerán más claramente con la lectura de la siguiente descripción, dada a título de simple ejemplo ilustrativo, y no limitativo, con relación a las figuras, entre las cuales: - la Figura 1 ilustra un ejemplo de una red de comunicación que implementa un procedimiento de asignación de un identificador de un nodo de cliente y un procedimiento de registro de un identificador según un modo de realización de la invención;
- la Figura 2 presenta las principales etapas del procedimiento de asignación de un identificador según un modo de realización de la invención;
- la Figura 3 presenta las principales etapas del procedimiento de registro de un identificador según un modo de realización de la invención;
- las Figuras 4A y 4B ilustran ejemplos de mensajes intercambiados entre un primer nodo de cliente, un cliente maestro y un servidor para la asignación de un identificador al primer cliente de un dominio de cliente y su registro según un modo de realización de la invención;
- las Figuras 5A y 5B ilustran ejemplos de aplicación de la invención para fiabilizar los intercambios entre los nodos de clientes y el servidor;
- las Figuras 6A a 6D ilustran ejemplos de mensajes intercambiados entre el primer nodo de cliente, el cliente maestro y el servidor para eliminar el identificador asignado al primer nodo de cliente según un modo de realización de la invención;
- la Figura 7 detalla las etapas implementadas por el servidor para procesar una solicitud de modificación a través de un primer nodo de cliente de una acción de gestión instalada por un segundo nodo de cliente, según un modo de realización de la invención;
- las Figuras 8A a 8B ilustran la resolución de un conflicto entre acciones de gestión de tráfico según un modo de realización de la invención;
- las Figuras 9A a 9C ilustran ejemplos de mensajes intercambiados para el establecimiento de un procedimiento de delegación entre nodos de clientes según un modo de realización de la invención; y
- la Figura 10 ilustra de manera esquemática la estructura de hardware de un nodo de cliente y de un servidor según un modo de realización de la invención.
5. Descripción detallada de modos de realización de la invención
El principio general de la invención se basa en la asignación de un identificador único a un nodo de cliente que hace parte de un dominio de cliente, pero también en el registro de este identificador en asociación con un identificador del dominio de cliente, y en la utilización de este identificador único para hacer más eficaz y fiable la protección contra los ataques de denegación de servicio dentro del dominio.
Se presenta, con relación a la figura 1, diferentes equipos de una red encargados de la protección de la red y de los terminales los cuales están conectados a ella contra ataques informáticos, e implementar un procedimiento para la asignación de un identificador según un modo de realización de la invención.
Por ejemplo, el dominio 11 de cliente comprende una o más máquinas, también denominadas nodos. En este caso, se entiende por «dominio» un conjunto de máquinas o nodos colocados bajo la responsabilidad de una misma entidad. Se considera, por ejemplo, varios nodos de clientes C1, C2, Cm pertenecientes al dominio 11 de cliente, que comunican con un servidor S 12.
Según el ejemplo ilustrado, el servidor 12 no pertenece al dominio 11 de cliente. Según otro ejemplo no ilustrado, el servidor 12 puede pertenecer al dominio 11 de cliente.
En la continuación de la descripción, se considera el caso de una arquitectura de tipo DOTS, según la cual los nodos 114 de clientes C1, C2 y Cm son clientes DOTS y el servidor S es un servidor DOTS. Por tanto, los nodos de clientes C1, C2 y Cm y el servidor S pueden comunicarse a través de los canales de señalización y de datos DOTS definidos con relación a la técnica anterior, para informar al servidor que se ha detectado un ataque DDoS y que se requieren las acciones apropiadas.
5.1. Recordatorios sobre la arquitectura DOTS
Una solicitud DOTS puede ser, por ejemplo:
- un mensaje de gestión de alias, por ejemplo, destinado para asociar un identificador con uno o más recursos de red ubicado(s) en el dominio de cliente,
- un mensaje de señalización para solicitar la mitigación de un ataque de denegación de servicio con un servidor DOTS, pudiendo el servidor, en la recepción de un tal mensaje, desencadenar las acciones necesarias para poner fin al ataque, o
- un mensaje de gestión de reglas de gestión de tráfico, por ejemplo, filtrado, que comprende una solicitud a un servidor DOTS para que instale (o hacer instalar), modifique o incluso elimine una lista de control de acceso (ACL para «Acces Control List») para la mitigación de un ataque. En la continuación, se designará por «solicitud de procesamiento» una solicitud de instalación de una o más reglas de filtrado explícitas, una lista de control de acceso y, más en general, de cualquier acción que un nodo de cliente DOTS pueda solicitar al servidor para la mitigación de un ataque y más en general, la aplicación de una política de seguridad dirigida al dominio el cual aloja el cliente DOTS.
Una solicitud DOTS puede ser enviada desde un cliente DOTS, perteneciente a un dominio de cliente DOTS, a un servidor DOTS o a una pluralidad de servidores DOTS. Un dominio DOTS puede recibir uno o más clientes DOTS. En otras palabras, varios nodos de cliente en un dominio de cliente pueden disponer de funciones DOTS.
Las comunicaciones DOTS entre un dominio de cliente y un dominio de servidor pueden ser directas, o establecidas a través de puertas de enlace DOTS (en inglés «DOTS gateways»), no se representan. Estas puertas de enlace se pueden alojar dentro del dominio de cliente, del dominio de servidor, o de los dos. En otras palabras, un nodo de cliente del dominio de cliente puede comunicarse directamente con el servidor, o transmitir una solicitud a una puerta de enlace del dominio de cliente el cual se comunica directamente con el servidor o con una puerta de enlace del dominio de servidor, o transmitir una solicitud a un puerta de enlace del dominio de servidor el cual se comunica con el servidor.
Un servidor DOTS considera una puerta de enlace DOTS ubicada en un dominio de cliente como un cliente DOTS.
Una puerta de enlace DOTS ubicada en un dominio de servidor es considerada por un cliente DOTS como un servidor DOTS. En caso de presencia de una puerta de enlace DOTS en un dominio de servidor, la autenticación de los clientes DOTS se puede confiar a la puerta de enlace DOTS del dominio de servidor. Un servidor DOTS se puede configurar con la lista de puertas de enlace DOTS activas dentro de su dominio y el servidor puede delegar algunas de sus funciones a estas puertas de enlace de confianza. En particular, el servidor puede utilizar de manera segura las informaciones proporcionadas por una puerta de enlace que figura en una lista declarada con el servidor y mantenida por este último, por medio de un procedimiento de autenticación ad hoc (por ejemplo, configuración explícita de la lista a través del administrador autorizado del servidor, la recuperación de la lista de un servidor de autenticación, tal como un servidor AAA (para «Authentication, Authorization and Accounting»), etc.).
Los modos de realización presentados más adelante pueden ser implementados independientemente de la configuración de la arquitectura DOTS (uno o más clientes DOTS en un dominio de cliente, ninguna puerta de enlace DOTS, una o más puertas de enlace DOTS en el dominio de cliente o en el dominio de servidor, dominio de cliente distinto del dominio de servidor, etc.).
El establecimiento de una sesión DOTS segura se puede desarrollar de acuerdo con el procedimiento descrito en el documento «Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification» antes mencionado.
En la continuación, se supone que los agentes DOTS (cliente(s), servidor(es)) se autentican de manera mutua. Por lo tanto, existe un canal de comunicación seguro, por ejemplo, de tipo DTLS/TLS (para «(Datagram) Transport Layer Security»), entre un cliente DOTS y un servidor DOTS.
Por tanto, los mensajes recibidos de otro servidor que usurpan la dirección IP del servidor legítimo pueden ser rechazados por un cliente DOTS. De manera similar, el servidor DOTS ignora las solicitudes de clientes DOTS no autorizados para acceder al servicio de mitigación. En la continuación, se supone que este procedimiento es establecido por los agentes DOTS.
Los detalles de los intercambios DTLS/TLS y los que se refieren a la gestión de las claves de seguridad para la autenticación mutua de los agentes DOTS, no son objeto de la presente invención y no se detallan aquí.
5.2 Ejemplos de aplicación en el campo de los servicios de mitigación (DPS)
La figura 2 ilustra las etapas principales del procedimiento de asignación de un identificador a un primer nodo de cliente C1 según un modo de realización de la invención. Este procedimiento puede ser implementado por otro nodo de cliente del dominio de cliente, beneficiándose de privilegios con el servidor S, denominado cliente Cm maestro, o por una nueva instancia de software dedicada, denominada CMI (para «CUID Management Instance», en inglés) la cual interactúa con un nodo CI de cliente maestro. En la continuación, se supone que el procedimiento de asignación de un identificador es implementado por el cliente Cm maestro del dominio 11 de cliente. Sin embargo, el mismo procedimiento se aplica cuando esta función es realizada por la dicha entidad CMI dedicada.
Cuando el cliente DOTS C1 se inicia, este último contacta su cliente Cm maestro o la instancia CMI para solicitar en 21 la asignación de un identificador de cliente DOTS o cuid. Para realizar esto, el cliente DOTS C1 emite un mensaje de solicitud de asignación MREQID o GET() destinado al cliente Cm maestro, como se ilustra en la figura 4A. Tan pronto como el cliente Cm DOTS maestro (o la instancia CMI) recibe el mensaje MREQID o GET(), este último verifica que este cliente C1 está autorizado para invocar el servicio DOTS. En caso necesario, el cliente Cm maestro obtiene en 22 una lista de los identificadores utilizados actualmente en el dominio, por ejemplo, consultando una tabla almacenada en memoria, y elige en 23 un identificadorcuid_c1 el cual no hace parte de esta lista. De esta manera, el cliente DOTS Cm (o la instancia CMI) asegura por defecto que dos clientes del dominio de cliente no utilicen el mismo identificador 'cuid'. Cabe señalar que esta restricción se puede liberar durante las fases de aseguramiento o sustitución de un cliente DOTS por otro. Una vez elegido el identificador cuid_c1, el cliente Cm maestro registra en 24 el par formado por el identificador único asignado y el identificador del cliente C1 en la memoria, por ejemplo, una memoria local. A continuación, y con el fin de mejorar la robustez del servicio DOTS, el cliente DOTS Cm maestro contacta en 25 el servidor S en 27Cm para registrar el nuevo identificador activado dentro del dominio de cliente DOTS para el cliente C1. Como se ilustra en la figura 4B, lo hace, por ejemplo, con la ayuda de un mensaje de solicitud de registro MREQREG() o REGISTER_REQ(). Este mensaje puede incluir el(los) identificador(es) DOTS cuid del cliente C1 solo o de varios clientes). En la recepción de un mensaje de confirmación MREPREG() o REGISTER_ACK() del servidor S, envía en 26 al cliente C1 un mensaje de reconocimiento MREPID o SET(cuid_c1) que comprende el identificador cuid_c1 el cual le ha asignado, como se ilustra en la figura 4A. En la recepción de una respuesta de rechazo por parte del servidor S, el cliente Cm puede reiterar el proceso con el fin de reasignar un nuevo identificador al cliente C1 y solicitar nuevamente el registro del nuevo identificador cuid_c1 del servidor S.
De manera opcional, en la detección de un evento ocurrido en el dominio de cliente, como la inactividad del nodo de cliente C1, o su desconexión o incluso un cambio en la política de seguridad del dominio de cliente en 27, modifica en 28 al menos de manera local el registro del identificador cuid_c1.
Con relación a la figura 3, ahora se describen las etapas de un procedimiento de registro de un identificador asignado a un nodo de cliente, implementado por el servidor S según un modo de realización de la invención. En la recepción en 31 de una solicitud de registro m Re QREG() o REGISTER_REQ de un identificador cuid_c1 para el cliente C1 del dominio 11 de cliente procedente del cliente Cm maestro, como se ilustra en la figura 4B, el servidor S procede a las verificaciones de seguridad (no se representan) ya mencionadas. En caso de éxito, obtiene en 32 un identificador 'cdid' (para «Client Domain IDentifier», en inglés) del dominio 11 de cliente al cual está conectado el cliente C1. A título de ejemplo, un servidor DOTS identifica los clientes DOTS que pertenecen a un mismo dominio a través del atributo cdid. El servidor puede admitir otros mecanismos para la identificación del dominio de cliente. El identificador de dominio puede ser calculado de manera local por el servidor o comunicado por otra entidad de confianza (típicamente, un relevo DOTS de su dominio de servidor), o los dos. No se hace ninguna hipótesis sobre la estructura del cdid. A continuación, verifica en 33 si ya está almacenada en la memoria una asociación entre este identificador de cliente cuid_c1 y este identificador de dominio 'cdid'. Si encuentra uno, rechaza la solicitud de registro en 35 volviendo a enviar al cliente maestro una respuesta de rechazo MREPREQ(rej). Si no encuentra ninguno, procesa la solicitud de registro en 34 almacenando el par (cuid, cdid) del cliente C1 en la memoria M2. A continuación, confirma la solicitud de registro con un mensaje MREPREG(ack) o REGISTER-ACK(), como se ilustra en la figura 4B.
De manera opcional, en la recepción en 36 de una solicitud de procesamiento MREQT para la implementación de una solución de mitigación, tal como la instalación de una regla de gestión de tráfico del tipo filtrado del tráfico Rk, procediendo esta solicitud de un cliente identificado por el identificador cuid_c1, el servidor verifica en 37 que el identificador cuid_c1 está válidamente registrado en su memoria en asociación con el identificador del dominio de cliente del que procede la solicitud. En caso de éxito, procesa la solicitud en 38; de lo contrario, la rechaza. Se señala que el procedimiento de verificación según la invención implementado por el servidor DOTS para procesar una solicitud DOTS que procede de un cliente DOTS hace que el servicio sea más fiable incluso en caso de robo de las identidades de seguridad por una entidad malintencionada. Se presenta con relación a la Tabla 1 un ejemplo de extracto de una lista de clientes DOTS, tal como la mantenida por un cliente DOTS maestro Cm. La tabla indica tres clientes DOTS activos para este dominio. La invención no asume ninguna estructura particular para las tablas mantenidas por la instancia CMI/cliente maestro DOTS.
Tabla 1
Figure imgf000009_0003
Cabe señalar que en el caso de que el procedimiento según la invención sea implementado por una entidad software CMI, las informaciones que se refieren a la asignación del identificador del cliente DOTS son comunicadas por la instancia CMI al cliente maestro DOTS Cm.
A continuación, se presenta un ejemplo de extracto de una solicitud de registro MREPREG transmitida por el cliente Cm maestro al servidor S. En este ejemplo, la solicitud PUT es retransmitida por un relevo DOTS del dominio de servidor. El nodo de cliente de relevo inserta la información “cdid=here.example” para comunicar al servidor la identidad del dominio del cliente DOTS. Esta información es especialmente utilizada por el servidor para la aplicación de políticas, tales como la aplicación de cuota o la limitación del número de solicitudes por dominio.
Figure imgf000009_0001
También se presenta, con relación a la Tabla 2, un ejemplo de extracto de una lista de clientes, tales como los mantenidos por el servidor S. La tabla indica 5 clientes DOTS activos, 3 de los cuales pertenecen al dominio «here.example» del cliente Cm maestro.
Tabla 2
Figure imgf000009_0002
Para ilustrar las ventajas del procedimiento de asignación de identificador único según la invención, se consideran los ejemplos de la situación de las figuras 5A y 5B.
En estos dos ejemplos, el cliente C1 maestro primero procede al registro en el servidor S del identificador cuid_c3 el cual ha asignado al cliente C3. Como se describió anteriormente, el servidor S, en la recepción de la solicitud REGISTER_REQ(cuid_c3), verifica que este identificador sea efectivamente único en el dominio 11 de cliente identificado por su identificador único cdid = «here.example» y, si es el caso, almacena en la memoria la asociación (cuid_c3, cdid).
Con relación a la figura 5A, si un cliente C4 DOTS malicioso perteneciente a otro dominio 12 contacta el servidor S, solicitando la implementación de una acción de gestión a nombre del cliente C3, es decir, utilizando su identificador cuid_c3, el servidor detecta que la asociación (cuid_c3, cdid) es errónea y rechaza la solicitud.
Con relación a la figura 5B, si un cliente C2 DOTS malicioso que hace parte de un mismo dominio 11 que el cliente C3 y que el cliente Cm maestro, contacta el servidor S para una solicitud de mitigación de un ataque, su solicitud será rechazada por el servidor S, ya que este cliente C2 no está registrado válidamente con él.
Con relación a las figuras 6A a 6C, ahora se detallan las etapas 27 de detección de un evento de gestión del tráfico asociado al dominio de cliente y 28 de modificación de la asociación de identificadores registrados en la memoria local del cliente maestro o de la entidad CMI, según un primer modo de realización de la invención.
Se supone que el evento detectado en 27 es un evento relativo a un cambio en la actividad de los nodos de clientes registrados en el dominio o en la política de seguridad aplicada dentro del dominio. Según la invención, un nodo de cliente Cm maestro utiliza los identificadores únicos para reaccionar a este evento. Se trata por ejemplo de:
- la inactividad de un nodo de cliente durante un período predeterminado;
- la decisión del administrador del dominio de cliente de reducir el número de clientes DOTS activados dentro del dominio;
- el comportamiento sospechoso de un nodo de cliente DOTS;
- la solicitud explícita de eliminación de registro procedente de un nodo de cliente DOTS del dominio 11 de cliente.
Después de esta detección, el cliente Cm maestro puede decidir eliminar el registro de uno o más nodos de cliente con el servidor S.
Para realizar esto, como se ilustra en la figura 6A, envía un mensaje de solicitud de eliminación de registro MREQUNREG o UNREGISTER_REQ(). El mensaje de eliminación del registro puede incluir uno o más identificadores de clientes DOTS de un dominio de cliente. Tras la recepción de este mensaje, el servidor DOTS S procede a la eliminación de los clientes listados en sus tablas (después de las verificaciones de seguridad de uso).
Con relación a la figura 6B, el evento detectado por el cliente Cm maestro es la recepción de una solicitud explícita de eliminación de un registro por parte de un nodo de cliente C1 del dominio de cliente. En la recepción de la solicitud MREQSUP() o DELETE(cuid_c1), el cliente Cm maestro procede a la modificación del registro del identificador del cliente C1.
Se consideran dos opciones:
- Según una primera opción, ilustrada por la figura 6B, el cliente C1 maestro reconoce la solicitud del cliente C1 a través de un mensaje de respuesta MREPSUP (ack) y transmite una solicitud de eliminación de registro MREQUNREG () del cliente C1 al servidor S. Este último elimina la asociación (cuid_c1, cdid) de su tabla y responde al cliente Cm maestro a través de un mensaje de reconocimiento. Por tanto, el identificador cuid_c1 se libera al nivel del servidor S, el cual luego eliminará las acciones instaladas con este identificador.
Según una variante ilustrada en la figura 6C, antes de eliminar las reglas de gestión de tráfico instaladas con el identificador que viene de ser liberado, el servidor DOTS S informa a los otros clientes del dominio de la existencia de estas reglas, de modo que puedan reinstalarlas.
En un ejemplo de realización, se supone que los agentes DOTS (clientes y servidores) admiten el mecanismo «RESTCONF and HTTP Transport for Event Notifications», tal como se especifica en el documento «RESTCONF Transport for Event Notifications, draft-ietf-netconf-restconf notif, E. Voit y al., septiembre de 2018».
Cuando el cliente C2 se desconecta o cuando el servidor detecta una inactividad del cliente C2 durante un período determinado, este último identifica los filtros asociados con este cliente C2, y a continuación, notifica a los otros nodos de clientes del mismo dominio de cliente, tales como el C1 de su intención de eliminar las reglas de gestión de tráfico asociadas con el cliente C2.
En la recepción de esta notificación, el cliente C1 puede decidir asumir la responsabilidad de determinadas reglas inicialmente asociadas con el cliente C2. Para realizar esto, transmite una solicitud de tipo POST al servidor S para solicitarle que migre a su nombre determinadas reglas del cliente C2. El servidor S procede a la migración de estas reglas, y envía un mensaje de reconocimiento de tipo «204 created» al cliente C1 (es decir, el servidor mantendrá el identificador del nodo de cliente C1 como responsable de la gestión de estas reglas).
Si no se recibe respuesta de los otros clientes del dominio de cliente, el servidor S confirma la eliminación de los filtros.
- Según una segunda opción, ilustrada por la figura 6D, el cliente Cm maestro reconoce la solicitud del cliente C1 a través de un mensaje de respuesta MREPSUP (ack). Para evitar perturbar el funcionamiento del dominio DOTS 11, no solicita al servidor S que elimine el registro del identificador cuid_c1 del cliente C1, sino que reasigna este identificador a otro cliente C2 del dominio 11. De esta manera, reemplaza el cliente C1 por otro cliente del dominio sin afectar el estado mantenido por el servidor S.
Cuando el cliente C2 emite una solicitud de procesamiento, como, por ejemplo, la instalación de una regla de filtrado al servidor S, identificándose con el identificador cuid_c1, el servidor puede aceptar su solicitud ya que el cliente C2 está válidamente identificado.
Por tanto, la asignación de un identificador único a cada cliente de un dominio de cliente realizada por el procedimiento según la invención hace más fiables los intercambios entre los agentes DOTS y hace más robusta la protección, por el cliente Cm maestro situado en el dominio 11 de cliente, del dominio de cliente contra los ataques, incluso en caso de desconexión de determinados nodos de clientes de un mismo dominio de cliente.
Con relación a la figura 7, ahora se detallan las etapas 36 a 38 de recepción y de procesamiento de una solicitud de modificación de una regla de gestión de tráfico implementada por el servidor S según un segundo modo de realización de la invención.
El servidor S recibe en 36 una solicitud de procesamiento de una regla Rk procedente del cliente C1. Verifica en 37 que el identificador cuid_c1 está efectivamente registrado en asociación con el identificador del dominio de cliente cdid. En caso necesario, busca en 371 un registro que asocie el identificador cuid_c1 a la regla Rk identificada por el atributo rk. Si es el caso, el cliente C1 es el originador de la instalación de la regla Rk que desea modificar.
El servidor S procede a la modificación solicitada en 38.
En caso contrario, realiza en 372 una verificación adicional, la cual consiste en buscar un registro que asocie a la regla Rk el atributo de delegación «THIRD_PARTY_NONCE» del cliente C1. Si lo encuentra, el servidor S considera que el cliente C1 se beneficia de una delegación por parte del cliente C2 para modificar la regla Rk y procede a la modificación solicitada en 38.
De manera concreta, este nuevo atributo «THIRD_PARTY_NONCE» es informado por el cliente DOTS C2 durante la creación de la regla Rk con el servidor S. Este atributo incluye un identificador único, tal como el identificador cuid_c1 del cliente C1.
Este procedimiento de delegación permite que un nodo de cliente del dominio de cliente modifique las acciones instaladas por otro cliente de este dominio de cliente, tales como por ejemplo las reglas de filtrado de tráfico que estén desactualizadas o entren en conflicto con la instalación de otras reglas de filtrado, por ejemplo, para el establecimiento de una solución de mitigación contra un ataque DDoS.
Ahora se detalla la implementación de un procedimiento de delegación según la invención considerando el ejemplo de los nodos de clientes C1 y C2 del dominio 11 de cliente. Se supone que C1 y C2 activan el procedimiento de delegación de las operaciones DOTS para fiabilizar el servicio en caso de indisponibilidad de uno de ellos, en caso de conflicto, etc. El procedimiento de delegación se puede activar de varias maneras:
- Según una primera opción, la delegación es activada únicamente por el cliente C1 en beneficio del cliente C2. El cliente C2 no designa al cliente C1 como beneficiario de una delegación;
- según una segunda opción, la delegación es activada por los dos clientes: C1 delega a C2 y viceversa. Se consideran dos variantes:
o el mismo valor del atributo THIRD_PARTY_NONCE es utilizado por los dos clientes.
o los valores distintos son utilizados por cada uno de los clientes.
Con fines de ilustración, a continuación, se presenta un ejemplo de solicitud de instalación de una acción de gestión «my_acl», para la cual el nodo de cliente C2, identificado por el identificador cuid_c2, especifica al servidor que admite la delegación indicando el valor «263afd79-835c-4ee7-9535-df245cf28d9a» para el atributo THIRD_PARTY_NONCE en su solicitud.
Figure imgf000012_0001
Ahora se supone que el nodo de cliente C1 detecta que la máquina cuya dirección IP es «1.2.3.1/32» es objeto de ataque, como se ilustra en la figura 8A.
Con relación a la figura 8B, el nodo de cliente C1 solicita al servidor S que establezca una solución de mitigación de este ataque enviando en 81C1 el siguiente mensaje:
Figure imgf000012_0002
En la recepción en 82S de esta solicitud, el servidor S procede en 83S a las verificaciones de seguridad y de registro del nodo de cliente C1 ya descritas, luego decide en 84S sobre una acción por establecer. Se trata, por ejemplo, de instalar una nueva regla de filtrado Rk2. Cuando intenta instalar esta regla, detecta en 85S un conflicto con la regla de filtrado Rk = «my_acl» ya instalada por el nodo de cliente C2.
En 86S envía un mensaje de error 4.09 (Conflict) al nodo de cliente C1 para informarle de la existencia de este conflicto con la regla de filtrado Rk = “my-acl”.
El nodo de cliente C1 recibe este mensaje de error en 87C1. De manera contraria al estado de la técnica, el nodo de cliente C1 vuelve a enviar en 88C1 una solicitud de modificación de la regla de filtrado Rk al servidor S1 para resolver el conflicto. En este ejemplo, se supone que el nodo de cliente C1 agrega una nueva entrada a la regla existente «myacl» para bloquear solo el tráfico destinado a la dirección «1.2.3.1/32». Por ejemplo, la solicitud de modificación de Rk que envía al servidor S1 toma la siguiente forma:
Figure imgf000013_0001
(continuación)
Figure imgf000013_0002
Cabe señalar que especifica el valor del atributo THIRD_PARTY_NONCE. Tras la recepción de este mensaje a través del servidor d Ot S S en 89S, este último verifica que el valor del atributo «THIRD_PARTY_NONCE» (263afd79-835c-4ee7-9535-df245cf28d9a) es idéntico al indicado por el cliente C2 durante la creación de la regla de filtrado Rk= “myacl” y que los dos clientes C1 y C2 pertenecen al mismo dominio 11 de cliente DOTS. Después de esta verificación, el servidor DOTS S decide modificar el filtro como lo solicitado por el nodo de cliente C1. El tráfico DDoS es entonces bloqueado como se ilustra en la figura 8C. Por tanto, la invención permite resolver el conflicto sin solicitar el nodo de cliente C2.
Según un tercer modo de realización de la invención, el valor del atributo «THIRD_PARTY_NONCE» es asignado por la instancia CMI/cliente Cm maestro, al mismo tiempo que el identificador 'cuid'. El valor del atributo de delegación se puede obtener mediante configuración estática o dinámica, por ejemplo, a través del protocolo DHCP.
Con relación a la figura 9A, el nodo de cliente C1 transmite una solicitud de asignación MREQID() o GET(cuid, THIRD_PARTY_NONCE) de un identificador 'cuid_c1' y de un atributo de delegación.
Ventajosamente, la instancia CMI o el nodo de cliente Cm maestro pueden desactivar este procedimiento de delegación no devolviendo ningún valor de atributo de delegación al cliente C1 como se ilustra en la figura 9B. De manera concreta, la ausencia del atributo THIRD_PARTY_NONCE en la respuesta recibida de la CMI es una indicación explícita para informar al nodo de cliente C1 que el procedimiento de delegación DOTS está desactivado.
En efecto, el procedimiento de delegación puede inducir una sobrecarga de cálculo para el nodo de cliente que toma el relevo de otro nodo de cliente para la gestión de sus acciones en curso. Si la carga del dicho nodo de relevo alcanza un determinado umbral, por ejemplo, el 80 % de la unidad central de procesamiento o CPU (para «Central Processing Unit», en inglés), entonces se podría desactivar el procedimiento de delegación. La entidad encargada de la activación del procedimiento de delegación puede, especialmente, ser informada de una superación del umbral a través de medios de notificación convencionales, tales como una «trap SNMP».
Según una variante de realización, ilustrada por la figura 9C, el nodo de cliente maestro indica en su respuesta al nodo de cliente C1, no sólo el valor del atributo de delegación que le ha asignado, sino también el que ha asignado a otros nodos de clientes del mismo dominio de cliente. Se entiende que, en este caso, todos los nodos de clientes del dominio de cliente comparten el mismo valor de atributo de delegación.
Por tanto, como se ilustra a través de los diferentes modos de realización de la invención que se acaban de describir, el registro a través del servidor S de una asociación entre el identificador único asignado al nodo de cliente por el nodo de cliente maestro o la entidad CMI, y el identificador del dominio 11 de cliente, no solo hace más fiables los intercambios entre los agentes DOTS, sino que facilita y hace más robusta la protección implementada por el servidor S contra los ataques DDoS.
5.3 Estructuras
Finalmente se presenta, con relación a la figura 10, las estructuras simplificadas de un nodo de cliente y de un servidor según uno de los modos de realización descritos más arriba.
Según un modo de realización particular, un nodo de cliente Cm comprende una memoria 101em que comprende una memoria intermedia, una unidad de procesamiento 102om, equipada por ejemplo con una máquina de cálculo programable o una máquina de cálculo dedicada, por ejemplo un procesador P, y controlada por el programa de ordenador 103om, implementando etapas del procedimiento de asignación de un identificador a un primer nodo de cliente encargado de la gestión del tráfico asociado a un dominio de cliente según un modo de realización de la invención.
En la inicialización, las instrucciones de código del programa de ordenador 103om se cargan, por ejemplo, en una memoria RAM antes de ser ejecutadas por el procesador de la unidad de procesamiento 102om.
El procesador de la unidad de procesamiento 102om implementa las etapas del procedimiento de asignación del identificador descrito anteriormente, según las instrucciones del programa de ordenador 103om, para:
- recibir una solicitud de asignación de un identificador de nodo de cliente procedente del primer nodo de cliente, comprendiendo la dicha solicitud al menos una información de identificación del nodo de cliente;
- obtener una lista de identificadores de nodos de clientes ya asignados a los nodos de clientes activos al menos en el dominio de cliente;
- asignar al dicho primer nodo de cliente un identificador de nodo de cliente que no pertenece a la lista obtenida;
- registrar en una memoria local una asociación entre el identificador asignado y la información de identificación del primer nodo de cliente;
- emitir una respuesta destinada al primer nodo de cliente, que comprende el identificador asignado; y
- emitir una solicitud de registro del identificador asignado al primer nodo de cliente en el dominio a al menos un servidor de gestión del tráfico asociado al dominio.
Según un modo de realización particular, un servidor S comprende una memoria 101s que comprende una memoria intermedia, una unidad de procesamiento 102s , equipada por ejemplo con una máquina de cálculo programable o una máquina de cálculo dedicada, por ejemplo, un procesador P, y controlada por el programa de ordenador 103s , implementando etapas del procedimiento de registro de un identificador según un modo de realización de la invención.
En la inicialización, las instrucciones de código del programa de ordenador 103s se cargan, por ejemplo, en una memoria RAM antes de ser ejecutadas por el procesador de la unidad de procesamiento 102s .
El procesador de la unidad de procesamiento 102s implementa etapas del procedimiento de registro de un identificador descrito anteriormente, según las instrucciones del programa de ordenador 103s , para:
- recibir una solicitud de registro de un primer nodo de cliente, comprendiendo la dicha solicitud un identificador del primer nodo de cliente, habiendo sido el dicho identificador asignado al primer nodo de cliente por el nodo de cliente Cm según la invención;
- obtener un identificador del dominio de cliente al cual pertenece el nodo de cliente;
- registrar en una memoria el identificador del primer nodo de cliente asociado al identificador del dominio de cliente obtenido.

Claims (15)

REIVINDICACIONES
1. Procedimiento de asignación de un identificador a un primer nodo de cliente de un dominio de cliente, siendo el dicho primer nodo de cliente capaz de gestionar el tráfico asociado al dicho dominio de cliente con el fin de protegerlo contra un ataque informático, caracterizado porque el dicho procedimiento es implementado por un dispositivo de asignación de un identificador y porque comprende:
- la recepción (21) de una solicitud de asignación de un identificador de nodo de cliente procedente del primer nodo de cliente, comprendiendo la dicha solicitud al menos una información de identificación del primer nodo de cliente; - la obtención (22) de una lista de identificadores de nodos de clientes ya asignados a los nodos de clientes activos al menos en el dominio de cliente;
- la asignación (23) al dicho primer nodo de cliente de un identificador de nodo de cliente que no pertenece a la lista obtenida;
- el registro (24) en una memoria local de una asociación entre el identificador asignado y la información de identificación del primer nodo de cliente;
- la emisión (26) de una respuesta destinada al primer nodo de cliente, que comprende el identificador asignado; y - la emisión (25) de una solicitud de registro del identificador asignado al primer nodo de cliente en el dominio a al menos un servidor de gestión del tráfico asociado al dominio.
2. Procedimiento de asignación de un identificador según la reivindicación 1, caracterizado porque, en la detección de un evento relativo a una actividad del dominio de cliente, el procedimiento comprende una modificación (28) de la asociación registrada en la memoria local.
3. Procedimiento de asignación de un identificador según la reivindicación 2, caracterizado porque el evento detectado pertenece a un grupo que comprende:
- la inactividad del primer nodo de cliente;
- un comportamiento sospechoso del primer nodo de cliente;
- la recepción de una solicitud de eliminación recibida desde el primer nodo de cliente; y
- un número de nodos de clientes activados en el dominio demasiado elevado con respecto a un número máximo autorizado.
4. Procedimiento de asignación de un identificador según una de las reivindicaciones 2 o 3, caracterizado porque la modificación comprende la eliminación del registro, y porque el procedimiento comprende la emisión de una solicitud de cancelación del registro del identificador asignado destinado al servidor.
5. Procedimiento de asignación de un identificador según la reivindicación 2, caracterizado porque la modificación comprende una sustitución, en el registro de la memoria local, de la información de identificación del primer nodo de cliente por una información de identificación de un segundo nodo de cliente del dominio.
6. Procedimiento de asignación de un identificador según una de las reivindicaciones anteriores, caracterizado porque, la solicitud recibida que comprende además una solicitud de asignación de un atributo de delegación de gestión, estando el dicho atributo destinado para ser especificado por otro nodo de cliente en una solicitud de procesamiento de una regla de gestión de tráfico transmitida al servidor para delegar al primer nodo de cliente la gestión de la dicha regla de gestión de tráfico, el procedimiento comprende:
- La asignación de un atributo de delegación al primer nodo de cliente,
- El almacenamiento del atributo asignado con la asociación en el registro, y porque
- La respuesta emitida destinada al primer nodo de cliente comprende el atributo de delegación asignado.
7. Procedimiento de registro de un identificador asignado a un nodo de cliente capaz de gestionar el tráfico asociado a un dominio de cliente con el fin de protegerlo contra un ataque informático, implementado en un servidor, caracterizado porque el dicho procedimiento comprende:
- la recepción de una solicitud de registro de un primer nodo de cliente, comprendiendo la dicha solicitud un identificador del primer nodo de cliente, habiendo sido el dicho identificador asignado al primer nodo de cliente de acuerdo con el procedimiento de asignación según una de las reivindicaciones 1 a 6;
- la obtención de un identificador del dominio de cliente al cual pertenece el primer nodo de cliente; y
- el registro en una memoria del identificador del primer nodo de cliente asociado al identificador del dominio de cliente obtenido.
8. Procedimiento de registro de un identificador según la reivindicación 7, caracterizado porque, en la recepción de una solicitud de procesamiento de una regla de gestión de tráfico emitida por el primer nodo de cliente, comprendiendo la dicha solicitud el identificador del primer nodo de cliente, el procedimiento comprende la búsqueda del dicho registro en una memoria y rechazar la solicitud si no se encuentra el dicho registro.
9. Procedimiento de registro de un identificador según la reivindicación 8, caracterizado porque, cuando la solicitud de procesamiento comprende una solicitud de modificación de una regla de gestión de tráfico instalada por un segundo nodo de cliente, el procedimiento comprende:
- la verificación de una delegación de gestión mediante la comparación de un primer atributo de delegación de gestión especificado en la solicitud de modificación de la regla de gestión de tráfico y un segundo atributo de delegación de gestión asociado a la regla de gestión de tráfico instalada por el segundo nodo de cliente en un registro almacenado en la memoria;
- cuando el primer y el segundo atributos de delegación tengan el mismo valor, modificación de la regla de gestión de tráfico de acuerdo con la solicitud.
10. Procedimiento de registro de un identificador según una de las reivindicaciones 7 a 9, caracterizado porque, en la recepción de una solicitud de eliminación de registro del identificador del primer nodo de cliente, comprende la eliminación del dicho registro y la eliminación de las reglas de gestión de tráfico instaladas por el primer nodo de cliente.
11. Procedimiento de registro de un identificador según la reivindicación 10, caracterizado porque comprende la notificación de otros nodos de clientes activos en el dominio de cliente, previo a la dicha eliminación de las reglas de gestión de tráfico instaladas por el primer nodo de cliente.
12. Dispositivo de asignación de un identificador a un primer nodo de cliente capaz de gestionar el tráfico asociado a un dominio de cliente con el fin de protegerlo contra un ataque informático, caracterizado porque el dicho dispositivo comprende al menos una máquina de cálculo programable o una máquina de cálculo dedicada y configurada para implementar:
- la recepción de una solicitud de asignación de un identificador de nodo de cliente procedente del primer nodo de cliente, comprendiendo la dicha solicitud al menos una información de identificación del primer nodo de cliente; - la obtención de una lista de identificadores de nodos de clientes ya asignados a nodos de clientes activos al menos en el dominio de cliente;
- la asignación al primer nodo de cliente de un identificador de nodo de cliente que no pertenece a la lista obtenida; - el registro en una memoria local de una asociación entre el identificador asignado y la información de identificación del primer nodo de cliente;
- la emisión de una respuesta destinada al primer nodo de cliente, que comprende el identificador asignado; y - la emisión de una solicitud de registro del identificador asignado al primer nodo de cliente en el dominio a al menos un servidor de gestión del tráfico asociado al dominio.
13. Nodo de cliente que comprende al menos una máquina de cálculo programable o una máquina de cálculo dedicada configurada para la gestión del tráfico asociado a un dominio de cliente, caracterizado porque comprende un dispositivo de asignación de un identificador a un primer nodo de cliente según la reivindicación 12.
14. Sistema que comprende un nodo de cliente según la reivindicación 13, el cual comprende un dispositivo de asignación de un identificador a un primer nodo de cliente según la reivindicación 12, y un servidor que comprende al menos una máquina de cálculo programable o una máquina de cálculo dedicada configurada para la gestión del tráfico asociado a un dominio de cliente con el fin de protegerlo contra un ataque informático, caracterizado porque el dicho servidor implementa:
- la recepción de una solicitud de registro del primer nodo de cliente, comprendiendo la dicha solicitud un identificador del primer nodo de cliente;
- la obtención de un identificador del dominio de cliente al cual pertenece el primer nodo de cliente;
- el registro en una memoria del identificador del primer nodo de cliente asociado al identificador del dominio de cliente obtenido.
15. Producto de programa de ordenador que comprende instrucciones de código de programa para la implementación de un procedimiento según una cualquiera de las reivindicaciones 1 a 10, cuando es ejecutado por un procesador.
ES19802235T 2018-09-28 2019-09-26 Procedimiento de asignación de un identificador a un nodo de cliente, procedimiento de registro de un identificador, dispositivo, nodo de cliente, servidor y programas de ordenador correspondientes Active ES2932499T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1859044A FR3086776A1 (fr) 2018-09-28 2018-09-28 Procede d'allocation d'un identifiant a un nœud client, procede d'enregistrement d'un identifiant, dispositif, nœud client, serveur et programmes d'ordinateurs correspondants.
PCT/FR2019/052279 WO2020065232A1 (fr) 2018-09-28 2019-09-26 Procédé d'allocation d'un identifiant à un nœud client, procédé d'enregistrement d'un identifiant, dispositif, nœud client, serveur et programmes d'ordinateurs correspondants

Publications (1)

Publication Number Publication Date
ES2932499T3 true ES2932499T3 (es) 2023-01-20

Family

ID=65685535

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19802235T Active ES2932499T3 (es) 2018-09-28 2019-09-26 Procedimiento de asignación de un identificador a un nodo de cliente, procedimiento de registro de un identificador, dispositivo, nodo de cliente, servidor y programas de ordenador correspondientes

Country Status (6)

Country Link
US (1) US20220038473A1 (es)
EP (1) EP3857848B1 (es)
CN (1) CN112771833B (es)
ES (1) ES2932499T3 (es)
FR (1) FR3086776A1 (es)
WO (1) WO2020065232A1 (es)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3086821A1 (fr) * 2018-09-28 2020-04-03 Orange Procedes de collaboration et de demande de collaboration entre services de protection associes a au moins un domaine, agents et programme d’ordinateur correspondants.
US11637710B2 (en) * 2019-12-10 2023-04-25 Jpmorgan Chase Bank, N.A. Systems and methods for federated privacy management
WO2022152377A1 (en) * 2021-01-14 2022-07-21 Telefonaktiebolaget Lm Ericsson (Publ) MITIGATING DDoS ATTACKS

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1655928A1 (en) * 2004-11-05 2006-05-10 Hitachi, Ltd. Method and apparatus for allocating a unique identifier to a network node
US7653352B2 (en) * 2005-12-22 2010-01-26 Motorola, Inc. Method and apparatus for self-assigning addresses
US20080161008A1 (en) * 2006-12-27 2008-07-03 Enoch Porat Method and system for identification of a communication device in a wireless communication network
US9137135B2 (en) * 2011-11-14 2015-09-15 Jds Uniphase Corporation Selective IP address allocation for probes that do not have assigned IP addresses
US8935430B2 (en) * 2012-06-29 2015-01-13 Verisign, Inc. Secondary service updates into DNS system
CN103067385B (zh) * 2012-12-27 2015-09-09 深圳市深信服电子科技有限公司 防御会话劫持攻击的方法和防火墙
CN104618351A (zh) * 2015-01-15 2015-05-13 中国科学院信息工程研究所 一种识别dns欺骗攻击包及检测dns欺骗攻击的方法
CN105262722B (zh) * 2015-09-07 2018-09-21 深信服网络科技（深圳）有限公司 终端恶意流量规则更新方法、云端服务器和安全网关
CN105610852A (zh) * 2016-01-15 2016-05-25 腾讯科技（深圳）有限公司 处理ack洪泛攻击的方法和装置
US20170345009A1 (en) * 2016-05-25 2017-11-30 Mastercard International Incorporated Systems and Methods for Use in Facilitating Network Transactions
US10728280B2 (en) * 2016-06-29 2020-07-28 Cisco Technology, Inc. Automatic retraining of machine learning models to detect DDoS attacks
US10382480B2 (en) * 2016-10-13 2019-08-13 Cisco Technology, Inc. Distributed denial of service attack protection for internet of things devices
US10305931B2 (en) * 2016-10-19 2019-05-28 Cisco Technology, Inc. Inter-domain distributed denial of service threat signaling
US9756075B1 (en) * 2016-11-22 2017-09-05 Acalvio Technologies, Inc. Dynamic hiding of deception mechanism

Also Published As

Publication number Publication date
US20220038473A1 (en) 2022-02-03
EP3857848A1 (fr) 2021-08-04
EP3857848B1 (fr) 2022-08-31
CN112771833B (zh) 2023-06-06
WO2020065232A1 (fr) 2020-04-02
FR3086776A1 (fr) 2020-04-03
CN112771833A (zh) 2021-05-07

Similar Documents

Publication Publication Date Title
ES2932499T3 (es) Procedimiento de asignación de un identificador a un nodo de cliente, procedimiento de registro de un identificador, dispositivo, nodo de cliente, servidor y programas de ordenador correspondientes
JP7133010B2 (ja) Ｄｉａｍｅｔｅｒエッジエージェント（ＤＥＡ：ＤＩＡＭＥＴＥＲ ＥＤＧＥ ＡＧＥＮＴ）を用いる、アウトバウンドローミング加入者に対するモビリティ管理エンティティ（ＭＭＥ：ＭＯＢＩＬＩＴＹ ＭＡＮＡＧＥＭＥＮＴ ＥＮＴＩＴＹ）認証のための、方法、システム、およびコンピュータ読み取り可能な媒体
US10630725B2 (en) Identity-based internet protocol networking
US20200053165A1 (en) Session processing method and device
US20070192858A1 (en) Peer based network access control
CN103875226A (zh) 用于网络环境中主机发起的防火墙发现的系统和方法
US20230036806A1 (en) Crypto tunnelling between two-way trusted network devices in a secure peer-to-peer data network
EP2373075A1 (en) System and method for WLAN traffic monitoring
ES2895052T3 (es) Control dinámico e interactivo de una pasarela residencial conectada a una red de comunicaciones
US20240056428A1 (en) Crypto-signed switching between two-way trusted network devices in a secure peer-to-peer data network
JP4750750B2 (ja) パケット転送システムおよびパケット転送方法
KR101628534B1 (ko) 가상 802.1x 기반 네트워크 접근 제어 장치 및 네트워크 접근 제어 방법
EP1836559B1 (en) Apparatus and method for traversing gateway device using a plurality of batons
US11659394B1 (en) Agile node isolation using packet level non-repudiation for mobile networks
US11563816B2 (en) Methods for managing the traffic associated with a client domain and associated server, client node and computer program
CN112514350B (zh) 用于核实ip资源的有效性的方法以及相关联的访问控制服务器、验证服务器、客户端节点、中继节点和计算机程序
US20220414211A1 (en) Method for coordinating the mitigation of a cyber attack, associated device and system
CN113853776B (zh) 用于网络架构的方法、系统和计算机可读介质
US12034701B2 (en) Methods for protecting a client domain, corresponding client node, server and computer programs
CN113056896B (zh) 在与至少一个域相关联的保护服务之间进行协作和请求协作的方法、相应的代理和计算机程序
US20220038429A1 (en) Methods for Protecting a Client Domain, Corresponding Client Node, Server and Computer Programs
US20230147555A1 (en) Secure assistance for asynchronous task completion by unavailable endpoint device upon restored availability in a secure peer-to-peer data network
CN117914505A (zh) 控制终端安全访问互联网和内网的方法及设备