ES2313959T3 - Camara de seguridad para una red. - Google Patents

Camara de seguridad para una red. Download PDF

Info

Publication number
ES2313959T3
ES2313959T3 ES01937384T ES01937384T ES2313959T3 ES 2313959 T3 ES2313959 T3 ES 2313959T3 ES 01937384 T ES01937384 T ES 01937384T ES 01937384 T ES01937384 T ES 01937384T ES 2313959 T3 ES2313959 T3 ES 2313959T3
Authority
ES
Spain
Prior art keywords
network
packages
data
package
monitor
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.)
Expired - Lifetime
Application number
ES01937384T
Other languages
English (en)
Inventor
Parag Pruthi
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.)
Niksun Inc
Original Assignee
Niksun Inc
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 Niksun Inc filed Critical Niksun Inc
Application granted granted Critical
Publication of ES2313959T3 publication Critical patent/ES2313959T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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/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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/026—Capturing of monitoring data using flow identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/18—Protocol analysers
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • 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
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0681—Configuration of triggering conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5029—Service quality level-based billing, e.g. dependent on measured service level customer is charged more or less
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/028—Capturing of monitoring data by filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/06—Generation of reports
    • H04L43/062—Generation of reports related to network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0858—One way delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894—Packet rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Algebra (AREA)
  • Probability & Statistics with Applications (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Closed-Circuit Television Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)
  • Polymerisation Methods In General (AREA)

Abstract

Método para detectar intrusiones que comprende las etapas de: (a) recibir datos desde una línea (2904) de comunicación; (b) segregar los datos en paquetes; (c) identificar una característica respectiva de cada paquete respecto a patrones indicativos de un aspecto de intrusión o tipo de intrusión, y (d) proporcionar selectivamente los paquetes a uno de una pluralidad de dispositivos (2908, 2910, 2912) de detección de intrusión paralelos según la característica identificada de cada paquete.

Description

Cámara de seguridad para una red.
Campo técnico
La presente invención se refiere en general a comunicaciones de datos, y, en particular, a un sistema y método relacionado para recoger, analizar, y monitorizar comunicaciones de datos.
Antecedentes de la invención
Actualmente es rutinario comunicar datos y otra información a diferentes puntos a través de una red de datos o de comunicaciones. Un ejemplo de tales redes de datos incluye múltiples ordenadores de usuario final que se comunican entre sí a lo largo de los diversos trayectos que comprenden tales redes. La complejidad de tales redes informáticas puede variar desde conexión entre pares sencilla entre un número relativamente pequeño de máquinas, hasta LANS, WANS y, por supuesto, la red informática mundial conocida como internet. La arquitectura de tales redes varía ampliamente, dependiendo de la aplicación particular, pero las redes más sofisticadas utilizan de redes troncales, nodos, y servidores informáticos que soporta la transmisión de datos e información a través de tales
redes.
Las empresas y los individuos cada vez dependen más de tales redes de datos no sólo para enviar y recibir información, sino para transacciones de negocios, y para cualquier otra actividad concebible que implique el envío, recepción o visualización de información. La llegada de Internet y su desarrollo continuado sólo ha aumentado la demanda de comunicación efectiva entre empresas, individuos, y otros usuarios de tales redes.
Esta demanda de enviar y recibir datos a través de tales redes genera lo que se denomina "tráfico", es decir, un volumen o "carga útil" de información codificada digitalmente, que atraviesa los trayectos apropiados en la red. Desgraciadamente, el tráfico a través de la red a menudo lleva a la congestión o "puntos problemáticos" en algunos puntos o a lo largo de algunos trayectos de la red. Tal congestión puede adoptar la forma de transmisión de datos lenta hasta la exasperación, o, en el peor de los casos, una incapacidad total para enviar o recibir la información necesaria a través de tal red. Este problema se agrava por el hecho de que, en algunas arquitecturas de red, el tráfico en general avanza sólo tan rápidamente como lo permitan su enlace o ruta más lentos.
Obviamente, tal congestión de tráfico no es deseable por diversos motivos. Los usuarios "atascados" en tal tráfico pueden culpar de la congestión a sus proveedores de servicio de red, haciendo que tales proveedores puedan perder negocio. Tales retardos de red también tendrán un efecto negativo, tanto directa como indirectamente, en la productividad de los usuarios de redes.
Un enfoque para aliviar tal congestión de red u otros "puntos problemáticos" de red es obtener información oportuna y precisa acerca de la congestión o punto de conflicto. Desgraciadamente, los intentos de la técnica actual para resolver lo intricado de las redes informáticas y aliviar la congestión sufre de diversos inconvenientes y desventajas. Por ejemplo, las herramientas de monitorización de red de la técnica actual pueden ser difíciles de personalizar, y por tanto pueden carecer de las herramientas necesarias para analizar la congestión de red o los puntos problemáticos. Tales "husmeadores" de red a menudo se limitan a realizar vaciados de tráfico de ciertos protocolos específicos que, de nuevo, pueden no ser capaces de describir de manera precisa o localizar el origen de la congestión de red. En otras palabras, la mayoría de los monitores de red y "husmeadores" de la técnica actual tienen capacidades limitadas para tabular datos en tiempo real, o para registrar datos en largos periodos de tiempo.
Los monitores de red de la técnica actual en general se inmiscuyen en la red para evaluar o estimar el rendimiento de red. La referencia "TCP/IP Illustrated, Volume I - The Protocols", Capítulos 7 y 8, disponible de Addison- Wesley Publishing Co., 1994, describe una técnica de este tipo. Para estimar los tiempos de propagación de ida y retorno para "paquetes" de información en internet, el monitor de red inyecta paquetes adicionales en la red y sigue el desplazamiento de tales paquetes adicionales. Por tanto, el verdadero proceso de determinación del propio rendimiento de red degrada adicionalmente el rendimiento añadiendo paquetes adicionales de información al tráfico.
No sólo es intrusivo el método descrito anteriormente, sino que en general es también impreciso. En particular, los tiempos de propagación en un sentido se evalúan dividiendo en general el retardo de propagación de ida y retorno del paquete de prueba entre dos; sin embargo, la mitad de un tiempo de propagación de ida y retorno en general no es equivalente a un retardo de propagación en un sentido, en parte basándose en asimetrías (que se analizan posteriormente) en la red. Para compensar esta imprecisión, algunas enseñanzas de la técnica actual inyectan paquetes de prueba con mayor frecuencia en la red, una solución que puede degradar adicionalmente el rendimiento de red que está probándose o monitorizándose.
El rendimiento de red puede mejorarse adicionalmente si el flujo de tráfico de red o el dimensionamiento de ancho de banda de red pudieran modelizarse de manera más precisa. En particular, el tráfico no fluye necesariamente de manera simétrica a través de un trayecto de red dado. Esto es especialmente cierto cuando el trayecto termina en un usuario final en una conexión de internet. Tal trayecto es asimétrico porque el usuario final normalmente descarga más carga útil o tráfico del que sube. Los monitores de la técnica actual en general no detectan o modelizan tales asimetrías, con el resultado de que se destinan mayores recursos de red a rutas particulares de los que pueden requerirse de otro modo. Esto cuesta más dinero y malgasta recursos informáticos.
Hay por tanto una necesidad de mejorar el rendimiento de red y aliviar la congestión de tráfico de red. Hay una necesidad adicional de herramientas que no se inmiscuyan en el flujo de tráfico, que puedan adaptarse para analizar diferentes parámetros de tráfico o tipos de "paquetes", y que recojan y tabulen estadísticas requeridas de manera rápida y precisa.
Con el uso cada vez mayor de redes informáticas de datos, empresas e individuos cada vez están más interesados en recoger, filtrar, o "perfilar" datos acerca de los usuarios o su tráfico en tales redes. Las empresas de marketing u otras organizaciones comerciales pueden estar particularmente fascinadas por datos demográficos o de otro tipo que pueden recogerse registrando y analizando de manera precisa el tráfico de red. Desgraciadamente, muchos anunciantes de internet obtienen perfiles de cliente pidiendo a los usuarios que rellenen formularios y cuestionarios. Los anunciantes pierden la mayoría de esta información de cliente debido a que los clientes a menudo no quieren que nadie les moleste teniendo que contestar tales preguntas. Hay por tanto una necesidad de obtener "perfiles" de cliente de una manera menos intrusiva.
El uso creciente de las redes ha aumentado asimismo las posibilidades de que los "piratas informáticos" u otros intrusos perjudiciales que realizan actividades maliciosas o incluso delictivas en redes de propiedad o protegidas. Como tal, un sistema que puede determinar el origen de violaciones de seguridad sería valioso para los departamentos de seguridad del estado, tales como el FBI, para contener la marea de delitos y faltas relacionados con la informática. La técnica actual, de nuevo, en general no consigue analizar, tabular, monitorizar o registrar el flujo de datos a través de una red de un modo óptimo para facilitar las actividades de seguridad.
Las empresas o individuos encargadas de monitorizar redes no sólo necesitan obtener enormes cantidades de información y estadísticas de manera oportuna, sino también necesitan visualizar tales datos rápidamente, fácilmente, y en un formato comprensible. De nuevo, las soluciones de la técnica actual a menudo se limitan a proporcionar "vaciados", a menudo de manera cronológica, con compilaciones estadísticas o representaciones gráficas inadecuadas de tales datos. Por tanto es deseable no sólo compilar información de tráfico de red, sino realizar algunos cálculos normalmente necesarios, y representar gráficamente tales cálculos en un formato fácil de usar y flexible.
La patente US-A-5787253 da a conocer un analizador de actividad de internet que incluye un controlador de interfaz de red que está dispuesto para recibir una corriente de paquetes de datos que pasa a lo largo de un medio de transmisión para un segmento de red. La corriente de paquetes se filtra y almacena en una memoria intermedia de paquetes de datos en bruto. Los datos por paquetes se descodifican en la capa de protocolo de internet para proporcionar información tal como datos de secuenciación y de temporización. Los datos en bruto se traducen al nivel de protocolo de aplicación para proporcionar información de alto nivel respecto a las transacciones entre nodos.
La patente US-A-5991881 da a conocer un sistema de vigilancia de red para la detección de intrusiones en la red. Tras la detección de cualquier intento de intrusión, el sistema iniciará un diario de toda la actividad entre los elementos informáticos implicados y enviar una alerta a una consola de monitorización. Cuando se inicia un diario, la red continúa monitorizándose mediante un sistema de vigilancia principal. Se empieza un proceso de monitorización secundario que interrogue al diario de actividad en tiempo real y envía alertas adicionales informando de la evolución del posible intruso.
La patente US-A-6044400 da a conocer un sistema de monitorización de conmutación que incluye al menos un bus que tiene una pluralidad de puertos de conmutación, en el que una multiplicidad de partes de datos se desplaza por el bus, teniendo cada una de las partes de datos al menos un destino. El sistema incluye también una pluralidad de estaciones de trabajo conectadas a la pluralidad de puertos de conmutación, y un dispositivo de recogida de datos operativo para recoger al menos una de los partes de datos procedentes del al menos un bus cuya parte de datos está transmitiéndose a lo largo del al menos un bus a al menos un destino que incluye al menos un destino distinto del dispositivo de recogida de datos.
La patente US-A-5764912 da a conocer un método y un aparato para medir los tiempos de respuesta de transacción. El método y el aparato pueden identificar secuencias de solicitud de servicio correspondientes a una transacción y los tiempos de comienzo y detención de la transacción. La invención puede aplicarse de manera no intrusiva/no invasiva a los paquetes de servicio comunicados entre un nodo de origen y uno de destino.
Para superar las deficiencias de los métodos y sistemas convencionales de monitorización de comunicación de datos, se proporciona un nuevo método de monitorización de una línea de comunicación. Un objeto de la presente invención es proporcionar un monitor de red para recoger y analizar datos de comunicación. Otro objeto es proporcionar un método para recoger y analizar datos de comunicación.
Sumario de la invención
Para conseguir estos y otros objetos, y en vista de sus fines, la presente invención proporciona un método para procesar datos en una línea de comunicación según se define por la reivindicación 1. En las reivindicaciones dependientes se definen características preferidas aunque no esenciales de la invención.
Debe entenderse que tanto la descripción general precedente como la siguiente descripción detallada son a modo de ejemplo, pero no son restrictivas, de la invención.
\vskip1.000000\baselineskip
Breve descripción del dibujo
La invención se entiende mejor a partir de la siguiente descripción detallada cuando se lea en conexión con el dibujo adjunto. Se recalca que, según la práctica común, las diversas características del dibujo no están a escala. Por el contrario, las dimensiones de las diversas características están ampliadas o reducidas de manera arbitraria para mayor claridad. En el dibujo se incluyen las siguientes figuras:
la figura 1 muestra un monitor de red según la presente invención acoplado a una línea de comunicación;
la figura 2 ilustra una jerarquía de protocolo a modo de ejemplo;
la figura 3 es un diagrama de bloques de un monitor de red a modo de ejemplo según la presente invención;
la figura 4 es un diagrama de flujo que ilustra un método de monitorizar a línea de comunicación a modo de ejemplo según la presente invención;
la figura 5 es un diagrama de flujo de datos que ilustra la gran cantidad de permutaciones de recogida de datos y métodos de análisis de un monitor de red según la presente invención;
la figura 6 es un diagrama de flujo que ilustra un método para identificar servidores con problemas;
la figura 7 muestra una red que usa monitores de red según la presente invención acoplados a dos líneas de comunicación separadas en una red;
la figura 8 es un diagrama de flujo que ilustra un método para determinar un retardo de transmisión;
la figura 9A es un diagrama de flujo que ilustra el funcionamiento de un ordenador central para sincronizarse con un ordenador de interfaz;
la figura 9B es un diagrama de flujo que ilustra el funcionamiento de un ordenador de interfaz para sincronizarse con un ordenador central;
las figuras 10-28 son visualizaciones de pantalla que ilustran una interfaz de usuario para recibir parámetros de monitorización y que ilustran métodos de visualización y que proporcionan información de análisis de comunicación;
la figura 29 ilustra un sistema de monitorización de red a modo de ejemplo según una realización a modo de ejemplo de la presente invención;
la figura 30 es un diagrama de reloj que ilustra un sistema de monitorización de red distribuido;
la figura 31 es una visualización de pantalla que ilustra una interfaz de usuario para la gestión centralizada de un sistema de monitorización de red jerárquico; y
la figura 32 es un diagrama de bloques de un monitor de red según una realización a modo de ejemplo de la presente invención.
\vskip1.000000\baselineskip
Descripción detallada de la invención
Con referencia ahora al dibujo, en el que números de referencia similares se refieren a elementos similares a lo largo del mismo, la figura 1 ilustra un monitor 102 de red a modo de ejemplo según la presente invención que está acoplado a una red N1 106 a modo de ejemplo a través de una primera línea 104 de comunicación. El monitor 102 de red recibe (monitoriza) comunicaciones de datos (tráfico) en la línea 104 de comunicación y proporciona métricas o estadísticas en tiempo real del tráfico de datos en la línea 104 de comunicación.
La línea 104 de comunicación puede usar un único protocolo de capa de enlace de datos para transportar tráfico de una multitud de diferentes protocolos de capa de protocolo de jerarquía más alta. Una estructura 200 de protocolo jerárquica de este tipo se ilustra en la figura 2. El protocolo 202 de capa de enlace de datos, Ethernet en este caso a modo de ejemplo, de tráfico entre la red N1 106 y el encaminador 108 puede incluir IPX, IP, ARP, encapsulados u otro tráfico 204 de capa de red. El tráfico IP puede incluir UDP, TCP, ICMP encapsulados u otro tráfico 206 de capa de transporte. El Tráfico TCP puede incluir Web, FTP, Servicio de nombre de dominio, encapsulados u otro tráfico 208 de capa de aplicación.
\newpage
El monitor 102 de red según la presente invención incluye hardware y software (que se analizan posteriormente) que recoge y analiza tráfico de red de modo que puede generar una variedad de estadísticas en tiempo real sobre tal tráfico en uno o en múltiples capas de protocolo. Las estadísticas en tiempo real generadas por el monitor 102 de red permiten el análisis de la calidad y cantidad de servicio, estando basada la facturación en la calidad de servicio y la cantidad de servicio, asignación de recursos de red dinámica y planificación, perfilado de clientes basándose en el contenido de los datos, análisis de seguridad de red, y reproducción de sesión. Estadísticas a modo de ejemplo incluyen cuentas de bytes, cuentas de bits, retardos de propagación en un sentido o de ida y retorno, tiempos de respuesta, bytes retransmitidos, bytes de origen por cada ordenador central, bytes de terminación por cada ordenador central, cuentas de par de ordenadores centrales de origen-determinación, tasas de aborto de web, rendimiento global, rendimiento global de nivel de aplicación, y porcentaje de bytes retransmitidos debido a retardos o pérdidas. Estas estadísticas pueden proporcionarse selectivamente basándose en tráfico en la primera línea 104 de comunicación en una o múltiples capas de protocolo entre la capa de enlace de datos y la capa de aplicación.
El funcionamiento de un monitor 302 de red a modo de ejemplo mostrado en la figura 3 se describe con referencia al diagrama de flujo en la figura 4. El monitor 302 de red incluye una primera interfaz 304 de red acoplada a una primera línea 308 de comunicación por una primera conexión 312 y una segunda interfaz 306 de red acoplada a una segunda línea 310 de comunicación por una segunda conexión 314. La primera interfaz 304 recibe primeros datos (una corriente de bits) desde la primera línea 308 de comunicación (etapa 402) y la corriente de bits se segrega a continuación en paquetes (etapa 404). El término segregar se usa en el presente documento con el significado de que paquetes definidos previamente están extrayéndose de la corriente de bits. La corriente de bits puede segregarse en paquetes por o bien la interfaz 304 o por el ordenador 316 central. Los paquetes se almacenan en la memoria 318 que es jerárquica en esta realización e incluye una memoria 320 a corto plazo y al menos una memoria 322 a más largo plazo. Un procesador y motor 316 de consulta, opcionalmente controlados por una interfaz 324 de usuario, a continuación procesa los paquetes tal como se describe posteriormente con referencia a la figura 4.
En una realización a modo de ejemplo, el monitor 302 de red está acoplado a la primera línea 308 de comunicación de manera no intrusiva. Es decir, no dificulta directamente el flujo de tráfico en la línea de comunicación. El monitor 302 de red puede acoplarse a la línea 308 de comunicación, por ejemplo, enchufando la primera conexión 312 en un puerto o enchufe hembra en un conmutador o encaminador, rompiendo la línea 308 de comunicación e instalar un conector en Y al que la primera conexión 312 está acoplada, conectando la primera conexión a un concentrador, que usa un separador óptico, o conectando el monitor 302 de red a un enchufe hembra de monitorización en una oficina central.
El procesador y motor 316 de consulta convierte los paquetes en registros y almacena los registros en la memoria (etapas 414-422). El procesador y motor 316 de consulta incluye programación adecuada para generar estadísticas correspondientes a los paquetes (etapas 406-412). Aunque la generación de estadísticas para los paquetes puede lograrse de varios modos, un enfoque preferido procesa un conjunto de paquetes recibidos en un intervalo de tiempo o "tiempo de muestreo" predeterminado (etapa 406) para generar correspondientes estadísticas (etapa 408). El procesamiento se repite entonces de manera recurrente para conjuntos de paquetes sucesivos recibidos durante periodos de tiempo sucesivos (etapa 410). Durante tal procesamiento, una programación adecuada almacena las estadísticas generadas en la memoria a intervalos de tiempo apropiados, tales intervalos preferiblemente en el mismo orden que los intervalos de tiempo correspondientes a los conjuntos de paquetes.
La conversión de los paquetes en registros permite generar una amplia variedad de estadísticas adicionales tal como se describe a continuación. Los registros se generan determinando en primer lugar el tipo de cada paquete (etapa 414) y a continuación filtrando los paquetes (etapa 416) basándose en sus tipos determinados. Se genera un índice (etapa 418) para cada paquete y el paquete se convierte a continuación en un registro indexado (etapa 420) y almacenado en la memoria (etapa 422). A continuación se generan estadísticas adicionales (etapa 426) usando las estadísticas previamente generadas para los paquetes y entonces los registros se proporcionan a continuación a una o más aplicaciones tales como un dispositivo de visualización (etapa 428), un encaminador para ajustar dinámicamente encaminamiento de red basándose en las estadísticas adicionales (etapa 430), y un servicio de facturación para facturar a clientes basándose en la calidad o cantidad de servicio determinada basándose en las estadísticas generadas (etapa 432).
A continuación se describe la aplicación del proceso de la figura 4 para una línea de comunicación Ethernet que incluye paquetes IP encapsulados que encapsulan paquetes TCP que encapsulan tráfico web (véase la figura 2). La corriente de bits Ethernet se recibe desde la línea de comunicación (etapa 402) y se segrega en paquetes (etapa 404). Los paquetes se dividen en conjuntos, incluyendo cada conjunto paquetes recibidos durante uno de los periodos de tiempo de un segundo sucesivos (periodo de tiempo a modo de ejemplo) (etapa 406). Se calcula (etapa 408) el número de bits recibidos durante cada periodo de tiempo de un segundo (estadística a modo de ejemplo). Se generan las sucesivas estadísticas para los periodos de tiempo sucesivos recibiendo el siguiente conjunto de paquetes correspondiente al siguiente periodo de tiempo de un segundo (etapa 410) y a continuación se calcula el número de bits en esos paquetes (etapa 408). Las cuentas de bits para cada intervalo de tiempo de un segundo se almacenan en la memoria (etapa 412) a medida que se generan.
Se determina (etapa 414) un tipo (por ejemplo IP, ARP,...) de cada paquete. Si un usuario sólo desea analizar tráfico de paquetes IP, los paquetes se filtran para pasar sólo los paquetes IP (etapa 416). El momento en que el monitor de red recibió cada paquete IP se usa como un índice para cada paquete IP respectivo (418). A continuación se genera un registro indexado (etapa 420) para cada paquete IP y se almacena en la memoria (etapa 422). A continuación se ilustra un registro a modo de ejemplo que tiene el índice como primer campo F1 y el paquete como segundo campo F2.
1
Además de que el filtrado (etapa 416) sólo deja pasar paquetes IP, el filtro puede usarse también para dejar pasar sólo una parte del paquete, tal como sólo la parte IP, truncando la parte de cabecera de Ethernet de modo que el registro anterior contenga sólo la parte IP en el segundo campo F2. Como alternativa, el registro puede incluir una pluralidad de campos, cada uno correspondiente a una parte del paquete IP tal como una dirección de origen o dirección de destino, y el filtrado puede realizarse basándose en uno cualquiera o más de la pluralidad de campos.
Puede generarse cualquier número de estadísticas a partir sólo de los registros almacenados, o en combinación con estadísticas para los paquetes generados en las etapas 406-412. En este ejemplo, una estadística adicional conocida en la técnica de interés incluye la razón del número de bits en paquetes IP recibidos respecto al número de bits en todos los paquetes recibidos por cada minuto sucesivo (etapa 426). El cálculo de esta estadística se facilita según la presente invención, porque los paquetes almacenados son ya todos paquetes IP y se indexan por hora de recepción. Como tal, el cálculo se realiza clasificando los registros por índice, leyendo el conjunto de registros para cada minuto sucesivo, y añadiendo el número de bits en cada conjunto de registros. El número de bits en todos los paquetes por cada minuto puede calcularse sumando las cuentas de bits previamente calculadas generadas segundo a segundo en grupos de sesenta (de ese modo igual a un minuto). Por tanto, la estadística adicional se genera usando tanto los registros almacenados como las estadísticas almacenadas, lo que reduce el número de cálculos adicionales necesarios y el tiempo para generar tal estadística adicional.
Un ejemplo específico de los métodos de filtrado y almacenamiento realizados por un monitor de red según la presente invención se describió anteriormente con respecto a la figura 4. La flexibilidad de recogida de datos y métodos de análisis de un monitor 500 de red según la presente invención se describen posteriormente con respecto a los diagramas de flujo de datos de la figura 5.
Una corriente de bits entrante se segmenta en paquetes mediante un segmentador 502 de paquetes. La decodificación de la corriente de bits puede realizarse automáticamente para protocolos conocidos o puede realizarse según parámetros especificados por el usuario para protocolos personalizados o de propiedad. Por ejemplo, si se introduce un nuevo protocolo de capa de enlace de datos, el monitor 500 de red incluye programación adecuada para responder a protocolos definidos por el usuario, introducidos usando la interfaz 520 de usuario. El monitor 500 de red de la invención por tanto reconoce estructuras de paquete del nuevo protocolo para segmentar en paquetes una corriente de bits entrante. El monitor de red podría realizar a continuación su recogida de datos y métodos de análisis a través de las capas de protocolo más altas. Esta flexibilidad no se limita a la capa de enlace de datos. En otras palabras, el monitor 500 de red según la presente invención puede recoger y analizar comunicaciones de datos para protocolos personalizados en otras capas de protocolo.
Los paquetes pueden almacenarse directamente en la memoria 508 a corto plazo usando el trayecto A. Esto es útil para almacenar todos los datos recibidos desde la línea de comunicación. La memoria 508 a corto plazo puede transferir periódicamente datos a una memoria 510 a largo plazo para evitar desbordamiento. Aunque se ilustra teniendo sólo una única memoria 508 a corto plazo y una única memoria 510 a largo plazo, las enseñanzas de la presente invención son aplicables a otras estructuras de memoria jerárquicas que incluyen una pluralidad de dispositivos de memoria. Por ejemplo, la memoria puede incluir una memoria de acceso aleatorio (RAM), una memoria de disco, y una memoria de cinta. A medida que se llena la RAM, los datos se transfieren a la memoria de disco. A medida que la memoria de disco se llena, los datos se transfieren a la memoria de cinta. A medida que la memoria de cinta se llena, las cintas se sustituyen para almacenamiento de datos continuo o a largo plazo para fines de archivo, por ejemplo. Tal como se indica mediante la flecha doble a la memoria 508 a corto plazo y entre las memorias 508, 510, los datos almacenados en las memorias pueden recuperarse posteriormente para su análisis o para una de las aplicaciones 522-530 que se analizan posteriormente.
Puede desearse almacenar todos los paquetes directamente en la memoria para aplicaciones 528 de seguridad. Por ejemplo, el monitor de red puede programarse para almacenar todas las comunicaciones durante un periodo de 1 semana y a continuación sobreescribir los datos almacenados más antiguos. Si se detecta una violación de la seguridad en una semana desde que se produjo, los datos almacenados pueden analizarse por el monitor de red para determinar el origen y el alcance de la violación.
Los datos segmentados en paquetes pueden proporcionarse como alternativa por el segmentador 502 de paquetes al generador 504 de índice. El generador 504 de índice genera un índice correspondiente a uno o más de los paquetes recibidos. Ejemplos de un índice correspondiente a un paquete incluyen un sello de tiempo para indicar la hora a la que fue recibido por el monitor de red, el tipo de paquete (protocolo y/o capa), el tamaño de paquete, un número de paquete (1, 2, 3, ...), un número de interfaz, una aplicación, y una sesión asociada. El generador 506 de registros recibe los paquetes y el índice generado y genera un registro que incluye el índice generado. Como alternativa, el generador 506 de registros puede combinar el paquete y el índice recibidos con un registro existente previamente almacenado en la memoria 508, 510. El generador de registros puede recibir también un paquete directamente a través del trayecto C y generar un registro no indexado que incluye el paquete o puede combinar el paquete en un registro existente previamente almacenado en la memoria 508, 510.
Por ejemplo, puede generarse un único registro correspondiente a una sesión ATM. Cuando se recibe una primera celda (un paquete de tamaño fijo) correspondiente a la sesión ATM, puede indexarse y puede generarse un registro indexado y almacenarse en la memoria 508, 510. El índice puede ser un identificador de la sesión ATM, por ejemplo. Cuando se reciben celdas adicionales correspondientes a la sesión ATM, no necesariamente en orden, el generador 506 de registros puede recibir directamente estas celdas a través del trayecto C, leer el registro previamente almacenado indexado desde la memoria 508, 510, y a continuación combinar la celda recién recibida con el registro indexado. Además de simplemente combinar paquetes que pertenecen a una sesión ATM común en un registro común, el generador 506 de registros puede también orientar las celdas ATM recibidas dentro del registro en su orden correcto.
El identificador 512 de registro/tipo de paquete recibe paquetes o registros desde o bien el generador 506 de registros o desde la memoria 508 y a continuación caracteriza los paquetes o registros recibidos identificando su correspondiente "tipo" o "propiedad". El tipo o propiedad de un paquete o registro es un identificador versátil y puede programarse a través de la interfaz 520 de usuario. Ejemplos de propiedades o tipos de paquete o registro incluyen el número de bits o bytes correspondientes, su capa de protocolo, su tipo de protocolo en una capa de protocolo particular, una dirección de origen, una dirección de destino, un ID de usuario final, y un ID de aplicación. Los registros o paquetes a continuación se filtran en el filtro 516 de tipo de paquete basándose en la propiedad o tipo identificado por el identificador 512 de registro/tipo de paquete. Los registros o paquetes filtrados a continuación se indexan, indexan y se convierten en registros, o directamente se almacenan en la memoria 508, 510.
El filtro 514 de periodo de tiempo recibe registros o paquetes desde el generador de registros o la memoria 508, 510, y los filtra basándose en la hora a la que se recibieron desde la línea de comunicación por el monitor de red. Los registros o paquetes a continuación se segregan en grupos correspondientes a paquetes recibidos por el monitor de red durante periodos de tiempo sucesivos respectivos. El generador 518 de estadísticas a continuación genera estadísticas para cada uno de los periodos de tiempo sucesivos correspondientes a los paquetes recibidos durante cada periodo de tiempo sucesivo respectivo.
Los paquetes filtrados y las estadísticas generadas pueden almacenarse en la memoria. Los trayectos entre los bloques funcionales en la figura 5 ilustran que los contenidos de memoria pueden usarse a continuación de nuevo para realizar filtrado adicional o generación de estadísticas. Por tanto, un monitor de red según la presente invención puede recoger y analizar datos de manera recurrente generando estadísticas basándose en estadísticas generadas o paquetes almacenados previamente.
Además de programar el monitor de red para un protocolo personalizado tal como se describió anteriormente, la interfaz 520 de usuario puede definir también los parámetros de funcionamiento de los bloques funcionales dentro del monitor de red. Por ejemplo, un usuario puede especificar el índice que va a usar el generador 504 de índice, el periodo de tiempo que va a usar el filtro 514 de periodo de tiempo, y las estadísticas que va a generar el generador 518 de estadísticas para cada uno de los sucesivos periodos de tiempo.
Los datos recogidos y el correspondiente análisis generado por el monitor 500 de red pueden proporcionarse a una o más aplicaciones 522-530. Por ejemplo, un dispositivo 522 de visualización puede visualizar estadísticas, registros o paquetes sensibles a la selección del usuario tal como se describe adicionalmente a continuación con respecto a las pantallas de visualización en las figuras 10-28.
Las estadísticas generadas por el monitor 500 de red pueden proporcionarse a un administrador o encaminador 524 de red para permitir encaminamiento dinámico de comunicaciones y gestión de ancho de banda de red, también conocido como "gestión de rendimiento", en una red sensible a las estadísticas correspondientes al rendimiento de red. Se observa fácilmente que, midiendo los retardos de propagación en un sentido y proporcionando estadísticas de tráfico protocolo a protocolo en diferentes capas de protocolo, un monitor de red según la presente invención puede identificar estas asimetrías cuantificando los flujos de tráfico para permitir a un administrador de red para dimensionar apropiadamente los recursos de red según los flujos medidos.
Las redes de comunicación pueden optimizarse en la capa de servicio debido a que el monitor de red según la presente invención incluye programación adecuada para analizar flujos de tráfico en cualquier capa de protocolo. Aunque diferentes servicios pueden tener diferentes requisitos de servicio, estos servicios a menudo se integran en una única red de comunicación. Sin embargo, servicios tal como multimedia, voz sobre IP, datos, en tiempo real e Intranet pueden tener cada uno requisitos de servicio de red únicos. Por ejemplo, para voz sobre IP, debido a las bajas tolerancias en degradación de transmisiones de voz, puede no tolerarse una calidad de servicio inferior que incluye retardo o pérdida de datos. En contraste, la transmisión de datos puede continuar en un entorno de pérdidas debido a la recuperación de errores mediante retransmisión. Un encaminador 524 a modo de ejemplo está configurado para encaminar el tráfico correspondiente a diferentes servicios de manera diferente dependiendo de sus requisitos de servicio.
El monitor de red según la presente invención incluye características programadas que identifican flujos correspondientes a cada servicio y/o usuario individual y proporcionan análisis de interacciones con diferentes servicios. Esta información puede usarse por un encaminador, por ejemplo, para tomar decisiones en tiempo real o no en tiempo real para optimizar topologías de red, rutas, o segregación de servicio, etc., para conseguir una configuración óptima adecuada para dotar a cada uno de los servicios de su propio requisito de calidad de servicio único.
Un sistema 526 de facturación puede configurarse para recibir estadísticas de calidad y/o cantidad de servicio correspondientes a diferentes servicios y diferentes clientes de ordenadores centrales y de facturación en consecuencia. Esto permite facturar a los clientes basándose en estas estadísticas en lugar de proporcionar facturación de tarifa plana para servicio no medido previamente. Por ejemplo, un cliente puede usar su servicio de Internet ilimitado para comunicación de voz sobre IP. Según la presente invención, el monitor 500 de red puede generar estadísticas para un cliente particular sobre el número, duración, y destino de las llamadas de voz sobre IP. Las estadísticas a continuación se convierten en información de facturación por el sistema 526 de facturación y se factura al cliente en consecuencia. Por tanto, puede facturarse a un abonado a Internet que usa Internet para llamadas de voz sobre IP, ahora según la cantidad, duración, y destino de las llamadas tal como se hace para un servicio telefónico no de Internet. Puede facturarse a los clientes de manera similar basándose en un número de transacciones de comercio electrónico, un número de compraventa de acciones, un número de solicitudes de cotizaciones de acciones en tiempo real, y otras transacciones. Como alternativa, los clientes pueden tener contratos de servicio que incluyen diferentes tarifas de facturación dependiendo de una calidad de servicio proporcionada que puede facturarse en consecuencia. Un monitor de red puede también usarse para garantizar el cumplimiento de los contratos de servicio que garanticen unas condiciones de servicio o acuerdos de nivel de servicio mínimos.
Tal como se describió anteriormente, los datos recogidos pueden usarse para que la seguridad 528 identifique violaciones de seguridad, identifique usos de red inapropiados o actividades ilegales. Por ejemplo, pueden filtrarse paquetes para identificar archivos particulares que se han transferido mediante un FTP a un servidor, para identificar quién hizo un telnet (inició sesión) a una máquina o servidor particular, y para ver qué teclearon una vez iniciada la sesión.
Las estadísticas desde un monitor de red pueden corresponder a un usuario o a un grupo de usuarios para perfilar el usuario o grupo. Mucha de la publicidad en Internet va dirigida a clientes basándose en un perfil de cliente generado pidiendo a un usuario que responda a unas preguntas. Un monitor de red según la presente invención puede filtrar cada paquete recibido basándose en sus contenidos para construir perfiles individuales de cliente. Por ejemplo, un nodo que monitoriza la base de un cliente de Philadelphia puede mirar cada paquete de cada usuario antes de entrar en Internet. También, puede analizar el tráfico devuelto a estos usuarios buscando (filtrando) un texto específico dentro de los paquetes o los sitios web visitados por el usuario. Puede generarse un perfil por cada usuario o grupo de usuarios a continuación basándose en los datos filtrados para dirigir contenido al usuario que será de interés para el usuario tal como correo electrónico dirigido. El método descrito anteriormente para filtrar puede usarse de manera similar por funcionarios encargados del cumplimiento de la ley o de seguridad para monitorizar comunicaciones para detectar actividades ilícitas o monitorizar las actividades de usuarios seleccionados.
El monitor de red puede usarse también para proporcionar datos a un dispositivo 530 de reproducción para reproducir sesiones de cliente que se monitorizaron desde la línea de comunicaciones. Todos los paquetes recibidos pueden registrarse y filtrarse a continuación basándose en una sesión particular. La sesión puede identificarse basándose en información incluida en los propios paquetes o basándose en información de sesión recibida en paquetes especiales o canales tal como SDR (session directory protocol, protocolo de directorio de sesión). Los paquetes correspondientes a la sesión pueden reproducirse a continuación de la manera en la que se presentaron originalmente al usuario. Este método puede usarse para reproducir toda la actividad web de un usuario o de conversaciones de voz sobre IP.
El monitor de red puede configurarse por un usuario para monitorizar líneas de comunicación que transportan tráfico usando un protocolo personalizado o de propiedad. Junto con una interfaz de capa física adecuada entre el monitor de red y la línea de comunicación, un usuario puede introducir parámetros de protocolo de propiedad usando la interfaz de usuario. Los parámetros definen la estructura de paquetes dentro de la corriente de bits transportada en la línea de comunicación para que el monitor de red segregue los paquetes de la corriente de bits. Parámetros adicionales pueden definir también campos dentro de un paquete de modo que el monitor de red pueda configurarse con consultas personalizadas para proporcionar estadísticas basándose en el contenido de estos campos de paquete. El monitor de red puede de manera similar programarse para recibir y analizar datos correspondientes a protocolos personalizados en capas más altas que la capa de enlace.
En una red a modo de ejemplo, el protocolo de transmisión de datos proporciona para cada paquete incluir un campo de sello de tiempo. Los paquetes transmitidos desde un origen a un destino incluyen un valor de sello de tiempo en el campo de sello de tiempo indicando un tiempo de transmisión por el origen. Cuando el paquete se recibe en el destino, el destino puede calcular la duración o retardo de transmisión en un sentido desde el origen al destino sustrayendo el valor de sello de tiempo de un valor de tiempo actual. Este protocolo permite mediciones de retardo de transmisión en un sentido y de calidad de servicio más sencillas eliminando la necesidad de comunicación entre monitores de red para hacer coincidir pares de paquetes en monitores de red separados.
Para una red que incluye muchos trayectos de transmisión intermedios separados entre el origen y el destino, la información de duración de transmisión en un sentido de extremo a extremo no proporciona información respecto a un cuello de botella particular en algún lugar entre el origen y el destino. Para un diagnóstico mejorado de cuello de botella, en lugar de sólo calcular retardos de extremo a extremo, puede acoplarse un monitor de red según la presente invención a uno de los trayectos de transmisión intermedios separados entre el origen y el destino. El monitor de red puede recibir el valor de sello de tiempo desde un paquete que atraviesa la red desde el origen al destino. El valor de sello de tiempo puede sustraerse a la hora actual en la hora de recepción del paquete por el monitor de red para determinar un valor de duración intermedio. Uno o más monitores espaciados entre sí pueden usarse tal como se describió anteriormente para localizar el cuello de botella en una red. En una realización a modo de ejemplo cada uno del origen, destino, y monitor de red incluye una interfaz de GPS (satélite de posicionamiento global) para recibir la hora actual usada para calcular la duración de transmisión.
Una de las métricas que un monitor de red según la presente invención puede proporcionar es una indicación del número de conexiones abortadas para un par origen-destino particular, para un origen o destino particular, e información sobre la razón de conexiones abortadas respecto a las conexiones totales para un origen o destino particular. Un método de identificar servidores TCP (protocolo de control de transmisión) con problemas a modo de ejemplo se describe con respecto al diagrama 600 de flujo en la figura 6.
Tal como se conoce por los expertos en la técnica, el cliente normalmente abre una sesión TCP y después se cierra por el servidor cuando ya no tiene más datos que enviar al cliente. Si el cliente cierra una sesión TCP, esto indica que la sesión se termina de manera prematura. Usando la web como ejemplo, un cliente (usuario que usa un navegador) puede cerrar la sesión por motivos que incluyen simplemente que ha cambiado de opinión respecto a la necesidad de los datos deseados o debido a una impaciencia debido a un retardo en la recepción de los datos deseados.
El monitor de red recibe un paquete desde una línea de comunicación (etapa 602) e identifica si el paquete pertenece a una sesión TCP (etapa 604). El monitor de red puede identificar si el paquete es un paquete TCP identificando y descodificando un campo de protocolo en el paquete que identifica a cuál de los diversos protocolos de capa de transporte pertenece el paquete. Una vez que un paquete se ha identificado como TCP, se identifican el cliente TCP y servidor TCP (etapa 606). El paquete a continuación se examina para determinar si abre o está iniciando la conexión TCP (etapa 608). Si el paquete es el paquete de apertura o inicio de una sesión TCP, se incrementa (etapa 610) una cuenta del número total de sesiones TCP para el (en etapa 606) servidor TCP previamente identificado.
Si el paquete no es un paquete de apertura, el monitor de red determina a continuación si el paquete está cerrando la conexión TCP (etapa 612). Si no, el monitor de red obtiene el siguiente paquete (etapa 602). Por otra parte, el monitor de red determina (etapa 614) si la conexión está cerrándose por el servidor, examinando el bit FIN por ejemplo, o si la conexión está cerrándose por el cliente. El cierre por el servidor indica terminación normal de la sesión y el monitor de red obtiene el siguiente paquete (etapa 602). El cierre por otro distinto del servidor indicó terminación prematura de la sesión y se incrementa una cuenta de cierre prematuro correspondiente al servidor particular (etapa 616). La razón de cierres prematuros respecto al total de sesiones TCP de servidor particular se calcula (etapa 620) y se compara con un valor umbral predeterminado (etapa 622). Si la razón de cierres prematuros supera el umbral, el servidor particular se identifica como un "servidor con problemas" (etapa 624).
Tal como los expertos en la técnica conocen, en algunas redes todos los paquetes correspondientes a una sesión TCP particular no pueden desplazarse a través de la misma línea de comunicación y por tanto no pueden detectarse por un único monitor de interfaz de red. Un monitor de red puede colocarse próximo a o en un servidor o cliente para "coger" todos los paquetes. Como alternativa, pueden usarse múltiples interfaces de monitor de red tal como se describió anteriormente para almacenar registros correspondientes a paquetes. Los registros almacenados pueden a continuación analizarse para determinar qué servidores pueden "tener problemas". En una realización a modo de ejemplo, los monitores de red remotos cada uno busca paquetes FIN, usando un filtro, por ejemplo, y tras detectar un paquete FIN envían un mensaje que incluye los contenidos del paquete FIN a un monitor central que realiza la determinación de "servidor con problemas".
Aunque las enseñanzas respecto a medir conexiones abortadas e identificar servidores con problemas se describieron anteriormente con respecto a sesiones TCP, estas enseñanzas en general son aplicables a otros protocolos y a otras capas de protocolo y no se limitan a identificar servidores TCP con problemas. Por ejemplo, en otro protocolo, una sesión puede tanto abrirse como cerrarse por el mismo nodo, ya sea el cliente o el servidor. Además, las cargas útiles de sesión pueden transmitirse en paquetes separados de o en enlaces de comunicación separados de los mensajes de control de sesión.
En una realización alternativa adicional mostrada en la figura 7, un sistema 701 para monitorizar comunicaciones según la presente invención puede incluir uno o más monitores de red acoplado cada uno a líneas de comunicación respectivas en una red según se muestra en la figura 7. Los monitores 700, 710, 720 de red primero, segundo, y tercero están acoplados a las líneas 702, 712, 722 de comunicación primera, segunda, y tercera, respectivamente. Cada monitor 700, 710, 720 de red recoge y analiza datos recibidos desde su línea de comunicaciones respectiva tal como se describió anteriormente con respecto al diagrama de flujo de datos en la figura 5.
Además de proporcionar recogida y análisis de datos independientes, un sistema que incluye una pluralidad de monitores 700, 710, 730 de red puede correlacionar datos recibidos en los diferentes monitores de red para proporcionar análisis de rendimiento de red mejorado. Por ejemplo, puede calcularse retardo de propagación en un sentido para datos que se desplazan desde la primera línea 702 de comunicación a la segunda línea 712 de comunicación.
\newpage
Un método de cálculo del retardo de propagación en un sentido a modo de ejemplo se ilustra mediante el diagrama de flujo en la figura 8. En general, el "mismo" paquete se identifica en dos monitores de red separados y la diferencia de tiempo entre el momento en que fue recibido por cada monitor se usa para calcular el retardo de propagación en un sentido. El "mismo" paquete se identifica poniendo a cero partes del paquete que cambian entre los monitores de red separados.
Cada uno de los monitores 700, 710 de red primero y segundo recibe datos (etapa 802, 806) desde su línea 702, 712 de comunicación respectiva. El segmentador 502 de paquetes segrega los datos recibidos en paquetes (etapas 803, 807) y cada uno de los generadores (504) de índice asocia la hora de recepción (sello de tiempo) de cada paquete con cada paquete. El generador 506 de registros genera un registro que incluye el sello de tiempo correspondiente a cada paquete y una parte única del paquete de datos (UDPD) y almacena el registro en la memoria 508, 510 (etapas 804, 808).
El UPDP es una parte del paquete recibido que hace la unidad de datos identificable de manera única. Por ejemplo, para una línea de comunicaciones Ethernet y una carga útil IP, se elimina la cabecera de Ethernet del paquete, se rellenan con ceros los campos de ttl y suma de verificación de IP, y la cabecera de IP y los 20 bytes subsiguientes se salvan e incorporan por el generador 506 de registros a un registro UPDP. El UPDP puede ser diferente para diferentes protocolos y puede programarse usando la interfaz de usuario.
Los registros UPDP del primer monitor 700 de red se comparan con los registros UPDP del segundo monitor 710 de red para hacer coincidir pares de UPDP (etapa 810). Los monitores de red primero y segundo pueden comunicarse a través de un enlace 730 de comunicación. El enlace 730 de comunicación puede implementarse por comunicación de los monitores de red a través de la red que están monitorizando (dentro de la banda). Como alternativa, el enlace 730 de comunicación puede implementarse por comunicación externa a la red a través de una línea telefónica, una conexión radioeléctrica, o una conexión por satélite, por ejemplo (fuera de la banda).
Para cada par de UPDP que se han hecho coincidir, el correspondiente sello ts2 de tiempo del segundo monitor de red se sustrae del correspondiente sello ts1 de tiempo del primer monitor de red (etapa 812). Esta diferencia de tiempo ts1-ts2 representa la duración para que los datos correspondientes al UPDP se desplacen desde el segundo monitor 710 de red hasta el primer monitor 700 de red. Calculando el UPDP, la duración de transmisión de una cierta carga útil entre las líneas de comunicación 702, 712 primer y segunda usando el mismo o diferentes protocolos de comunicación puede determinarse según el método descrito anteriormente.
En una realización a modo de ejemplo, la diferencia de tiempo ts1-ts2 se normaliza (etapas 814, 816) para representar el retardo de la primera línea 702 de comunicación. El retardo se normaliza sustrayendo el retardo transmisión-retardo para el paquete correspondiente al UPDP para atravesar la primera línea de comunicación de la diferencia de tiempo según se ilustra por la ecuación a continuación.
Retardo de red normalizado = (ts1-ts2) - (velocidad_enlace/longitud_paquete)
donde velocidad_enlace es la tasa de transmisión en la primera línea 712 de comunicación, y longitud_paquete es la longitud del paquete en la primera línea de comunicación que contenía el UPDP. El retardo de red calculado puede incluir componentes debido a retardo de cola y a retardo de transmisión. Según se ilustra por el diagrama de flujo de datos en la figura 5, el generador 518 de estadísticas puede recibir el paquete para el que va a generarse el registro UPDP, el generador 518 de estadísticas calcula el número de bits en el paquete y proporciona esta estadística al generador de registros para su incorporación en el registro UPDP para su uso en un cálculo de normalización. Los tiempos de propagación de ida y retorno pueden estimarse calculando de manera similar el retardo desde el primer al segundo monitor de red y añadiendo este retardo al retardo entre desde el segundo al primer monitor de red.
La precisión del retardo de transmisión calculado depende de la sincronización de los relojes de tiempo de los monitores 700, 710 de red primero y segundo. Los monitores de red pueden comunicarse a través de la línea 730 de comunicación para sincronizar sus relojes respectivos. En una realización a modo de ejemplo, los monitores de red se sincronizan recibiendo una señal de tiempo desde un origen 740 de tiempo común. En una realización a modo de ejemplo, el retardo de transmisión se genera en un nivel de precisión menor de 10 microsegundos, es decir, la diferencia entre el retardo calculado y el retardo actual es menor de 10 microsegundos. En una realización preferida, el origen 740 de tiempo común es un sistema de satélites globales tal como los satélites de posicionamiento global (GPS) y cada monitor 700, 710 de red incluye un receptor para recibir una señal de tiempo desde uno o más satélites globales. Cuando las dos líneas de comunicación que van a monitorizarse están próximas entre sí, uno de los monitores 700, 710 de red primero y segundo puede incluir un receptor GPS maestro y el otro puede incluir un receptor GPS esclavo acoplado al maestro.
Un monitor de red a modo de ejemplo se implementa con un ordenador central que tiene un ordenador de interfaz en una tarjeta de interfaz de red (NIC) acoplada a la línea de comunicación que está monitorizando. Tal como se describió anteriormente, los datos recibidos por la NIC pueden procesarse antes de enviarse al ordenador central. También tal como se describió anteriormente, el monitor de red puede usar la hora de recepción de datos desde la línea de comunicación para generar estadísticas o métricas de comunicación de red. Para registrar de manera precisa la hora a la que se reciben los datos desde la línea de comunicación, el ordenador de interfaz asocia una hora de recepción con los datos (aplica un sello de tiempo a los datos). Aplicando un sello de tiempo a los datos del ordenador de interfaz en lugar de al ordenador central, se reducen o eliminan las imprecisiones en la hora de recepción debido a un retardo al transferir datos desde el ordenador de interfaz al ordenador central.
En una realización a modo de ejemplo, el ordenador de interfaz incluye un reloj de interfaz y el ordenador central tiene un reloj de ordenador central. El reloj de ordenador central y el reloj de interfaz están sincronizados de modo que el ordenador central puede usar el sello de tiempo para de manera precisa generar estadísticas correspondientes a los datos recibidos. En una realización a modo de ejemplo, el reloj de interfaz se implementa como un contador. Como cada paquete se recibe desde la línea de comunicaciones, el valor del contador actual se asocia con ese paquete. El paquete se transfiere posteriormente al ordenador central con el valor de contador. El ordenador central incluye un reloj de ordenador central sincronizado con una referencia de tiempo absoluto. Tal como se describió anteriormente, la referencia de tiempo absoluto puede proporcionarse mediante un satélite de posicionamiento global.
El reloj de ordenador central y el reloj de interfaz están sincronizados correlacionando los valores de contador asociados con cada paquete por el ordenador de interfaz con la referencia de tiempo absoluto. El método de sincronizar el reloj de interfaz con el reloj de ordenador central se describe con referencia a los trazados de flujo en las figuras 9A y 9B con respecto al ordenador central y el ordenador de interfaz, respectivamente. En general, el ordenador central periódicamente solicita el valor del contador de reloj de interfaz del ordenador de interfaz y usa este valor para correlacionar el contador con el reloj de ordenador central.
Con referencia a las figuras 9A y 9B, si el ordenador central ha recibido un conjunto de paquetes desde el ordenador de interfaz (etapa 902), el ordenador central avanza para solicitar el valor de contador (etapa 906) del ordenador de interfaz enviando un mensaje "obtener contador" al ordenador de interfaz. En una realización a modo de ejemplo, el ordenador de interfaz almacena un conjunto de paquetes en una memoria del ordenador central mediante una operación de acceso directo a memoria (direct memory access, DMA) y a continuación interrumpe al ordenador central para indicar la transferencia de paquetes. Si el ordenador central no ha recibido un conjunto de paquetes, el ordenador central espera los paquetes durante un periodo de tiempo de espera (etapa 904), después del que solicita el valor de contador (etapa 906). El ordenador central registra la hora del reloj de ordenador central (etapa 906) cuando solicita el valor de contador de interfaz.
Cuando el ordenador de interfaz recibe un mensaje "obtener contador" (etapa 920) desde el ordenador central, el ordenador de interfaz a continuación determina (etapa 922) si actualmente está inactivo o si está recibiendo datos desde la línea de comunicación. Si no está inactivo, el ordenador de interfaz envía (etapa 924) un mensaje "inténtelo de nuevo" al ordenador central. Si está inactivo, el ordenador de interfaz a continuación lee el valor de contador y sustrae un tiempo de servicio de interrupción precalculado (etapa 926) para generar un valor de contador ajustado. El ordenador de interfaz a continuación envía (etapa 928) el valor de contador ajustado al ordenador central.
El tiempo de servicio de interrupción precalculado corresponde a la duración de tiempo entre el momento en que el ordenador de interfaz recibe la solicitud de contador desde el ordenador central al momento en que el ordenador de interfaz proporciona al ordenador central el valor de contador ajustado. El tiempo de servicio de interrupción precalculado puede determinarse experimentalmente usando un analizador lógico, por ejemplo para medir la duración de tiempo entre el momento en que la interfaz recibe la solicitud del contador hasta que la interfaz proporciona el valor de contador. Para hacer coincidir las mediciones de retardo experimentales con el retardo durante el funcionamiento normal, se proporciona la solicitud experimental a la interfaz cuando se sabe que la interfaz está inactiva y la interfaz sólo sirve una solicitud durante el funcionamiento normal cuando está inactiva. Tal como conocen los expertos en la técnica, el tiempo de respuesta del ordenador de interfaz puede tomarse repetidamente para generar un tiempo de servicio promedio para su uso durante el funcionamiento.
Tras la recepción del valor de contador, el ordenador central calcula (etapa 912) una estimación de la frecuencia relativa del contador de reloj de interfaz respecto al reloj de ordenador central. La frecuencia relativa puede usarse para correlacionar valores de contador asociados con paquetes recibidos desde el ordenador de interfaz hasta la siguiente ejecución de la rutina de sincronización. En una realización a modo de ejemplo, el ordenador central sustrae un tiempo de servicio de interrupción de ordenador central a partir de la hora registrada en la etapa 906 antes de calcular la frecuencia relativa para representar el retardo entre la hora en que el ordenador central recibe la cuenta desde la interfaz respecto a la hora cuando el ordenador central calcula la frecuencia relativa.
En una realización a modo de ejemplo, interfaces múltiples de red acopladas cada una a una línea de comunicación respectiva se implementan como una única unidad y comparten un reloj común. Por tanto, la sincronización sólo con el reloj común sincroniza el reloj de ordenador central con los sellos de tiempo asociados con los datos recibidos desde cualquiera de las líneas de comunicación respectivas.
Las figuras 10-28 son visualizaciones de pantalla a modo de ejemplo que ilustran una interfaz de usuario gráfica (GUI) para visualizar datos recogidos y analizados por un monitor de red y para controlar los análisis de datos mediante un monitor de red según la presente invención. La visualización en la figura 10 incluye un recuadro 1010 de tablas, un segundo recuadro 1030, y un recuadro 1050 de botones. El recuadro 1010 de tablas incluye una primera parte 1011 con casillas seleccionables para la selección del usuario y casillas de entrada de texto y una segunda parte 1012 con tablas de estadísticas correspondientes a datos recibidos. Las tablas 1023 que aparecen debajo de los botones seleccionables, casillas y campos incluyen entradas correspondientes a los datos particulares que están analizándose. El recuadro 1030 de trazados incluye los trazados 1032, 1034 que ilustran estadísticas correspondientes a los datos recibidos. El recuadro 1050 de botones incluye un conjunto de botones configurables por el usuario.
\vskip1.000000\baselineskip
Las casillas de entrada de texto y las casillas seleccionables en la primera parte 1011 del recuadro 1010 de tablas pueden opcionalmente fijarse para impedir la selección de opciones por parte del usuario e impedir la entrada por parte del usuario en las casillas de texto. Las funciones asociadas con las opciones y casillas visualizadas en la figura 10 se describen a continuación:
1. Inicio: El campo 1013 de inicio especifica la hora de comienzo desde que se analiza el tráfico y se visualizan sus resultados en la GUI.
2. Parada: El campo 1014 de parada especifica la hora de finalización a la que el tráfico se analiza y sus resultados se visualizan en la GUI. Por tanto los campos 1013, 1014 de inicio/parada especifican el tiempo entre el cual el tráfico se ha analizado y presentado al usuario a través de la GUI. Los contenidos de los campos 1013, 1014 de inicio y parada pueden visualizarse en múltiples formatos. Por ejemplo, los contenidos se muestran en un formato de fecha en la figura 10. Como alternativa, los contenidos pueden visualizarse como horas +/- para indicar que una hora relativa a la hora actual, el término "ahora" puede usarse para representar la hora actual, o el término "nunca" puede usarse para representar que los datos deben actualizarse continuamente.
3. Ventana: El campo 1015 de ventana indica los intervalos de tiempo a los que calcular valores que van a trazarse en el segundo recuadro 1030. Por ejemplo, si un usuario introduce "1" como campo de ventana, a continuación los valores en el campo de trazado se trazan cada segundo. El usuario puede introducir los valores en el campo de ventana usando unidades apropiadas para indicar la resolución de los trazados (por ejemplo 1s, 1ms, 100us, ... para indicar una resolución de tiempo si la unidad de la escala horizontal es el tiempo). Un campo 1015 vacío de ventana indica que la resolución en la escala horizontal debe ajustarse automáticamente.
4. Top N: El campo 1016 top N especifica el número máximo de entradas para las tablas 1023 que aparece en la segunda parte 1012 del recuadro 1010 de tablas. Si top N es 10, a continuación la tabla 1023 incluirá 10 filas clasificadas por un valor de columna particular en orden descendente. Si top N es -10, entonces la tabla 1023 incluirá 10 filas clasificadas por un valor de columna particular en orden ascendente (es decir esto se convierte en la noción de BottomN).
5. Filtro: la ventana 1017 de filtro describe un filtro que ha de aplicarse a los datos que van a visualizarse. Por ejemplo el filtro podría ser "protocolo IEEE802.3" para visualizar resultados para paquetes con protocolo IEEE802.3 de capa de enlace. Para datos previamente filtrados para mostrar sólo tráfico IP, un filtro de "ordenador central 10.0.0.1" visualizaría resultados para tráfico IP en los que o bien el ordenador central de origen o de destino era 10.0.0.1. Son también posibles diversos filtros complejos.
6. Hacer DNS: la casilla 1018 de verificación hacer DNS convierte las entradas en las tablas 1023 de una representación numérica a una representación textual. Por ejemplo, en IP una representación numérica (la dirección IP) se usa para identificar un ordenador central. Un DNS (Servidor de nombre de dominio) puede contener un mapeo a partir de esta representación numérica de la dirección IP a una representación textual. Por ejemplo, la dirección IP 10.0.0.1 puede convertirse en la representación textual foo.niksun.com cuando se marca la casilla de verificación hacer DNS. Para protocolos distintos de DNS la etiqueta dada a la casilla de verificación variará de acuerdo con una funcionalidad equivalente.
7. Ayuda: los botones 1019 de ayuda próximos a cada campo cuando se seleccionan hacen que se visualice la ayuda sensible al contexto. Por ejemplo, si se selecciona el botón de ayuda próximo al filtro 1017, se mostraría una ventana de ayuda para filtros.
8. Refrescar: el botón 1020 refrescar refresca los contenidos de todos los recuadros.
9. Botones de avance y retroceso: los botones 1021 de avance y 1022 de retroceso en la parte superior de la parte 1011 primera del recuadro 1010 de tablas funcionan de manera similar a los botones "hacia delante" y "hacia atrás" de un navegador con la característica añadida de mantener los contenidos de todos los recuadros alineados. Por contraste, haciendo clic en los botones "hacia delante" y "hacia atrás" de un navegador provoca movimientos hacia delante de movimientos hacia atrás recuadro a recuadro perdiendo por tanto correspondencia entre los diversos recuadros.
\vskip1.000000\baselineskip
El recuadro 1030 de trazados incluye trazados 1032, 1034, casillas de entrada de texto y casillas y botones seleccionables. Las casillas de entrada de texto y las casillas seleccionables pueden opcionalmente fijarse para impedir la selección de opciones por parte del usuario e impedir la entrada por parte del usuario en las casillas de texto. Las funciones asociadas con las opciones y casillas visualizadas en el recuadro 1030 de trazados de la figura 10 se describen a continuación:
1. Actualizar Tablas y Trazados: Este botón 1036 actualiza las tablas y recuadros de una manera coordinada. Por ejemplo, si un usuario hace zoom para acercar seleccionando una parte del trazado con un ratón, a continuación haciendo clic en este botón 1036 actualizaría los trazados y tablas para el intervalo de tiempo seleccionado del que se hizo zoom para acercar.
2. Cuentas de Byte/Paquete (y Tasas de transmisión de Bit/de paquetes) (y Utilización): Este botón 1037 cambia entre una de tres opciones tras la selección: "Cuentas de Byte/Paquete", "Tasas de transmisión de Bit/ de paquetes", y "Utilización". Los trazados también cambian desde cuentas de Byte/Paquete a través de una determinada ventana, a Tasas de transmisión de Bit/ de paquetes (es decir número de bits o paquetes por segundo), a Utilización en consecuencia. En una realización a modo de ejemplo, el trazado de byte visualiza valores normalizados relativos a la velocidad de enlace (es decir la tasa de transmisión de bits dividida por la capacidad de circuito de enlace o canal o virtual en bits por segundo).
3. Trazado padre de conmutación: Este botón 1038 conmuta la línea sobre los trazados tal como se describe posteriormente.
4. Trazado de conmutación de promedio: Selección del trazado de conmutación de promedio del botón 1039 de promedio conmuta si se visualiza el valor promedio (no mostrado) del eje y de los trazados.
5. Botones reproducir/Hacia delante/parada/Avance rápido/Rebobinar/rebobinado rápido/Pausa: Estos botones 1040 controlan la reproducción de los trazados en la pantalla para permitir actualizar los trazados a lo largo del tiempo y para desplazarse con el tiempo. Las tablas 1023 en el recuadro 1010 de tabla deben actualizarse para coincidir con los trazados 1032, 1034.
6. Diagrama superior: el diagrama 1032 superior mostrado en la figura 10 es un diagrama de tasa de transmisión de bit de nivel de enlace en bytes/segundo.
7. Diagrama inferior: el diagrama 1034 inferior en la figura 10 es un trazado de tasa de transmisión de bit de nivel de enlace en paquetes/segundo.
\vskip1.000000\baselineskip
La tabla 1023 en el recuadro 1010 de tablas se genera automáticamente basándose en protocolos que se sabe que están activos en el intervalo especificado por los campos 1013 de inicio y 1014 de parada. En la figura 10, la tabla 1023 muestra que entre los tiempos de inicio y de parada, se recibieron paquetes IP de 264K (K=1000's) y 919 paquetes ARP por el monitor de red. Los paquetes IP y los paquetes ARP que contienen 99M y 55K bytes, respectivamente (M=1.000.000).
Las entradas en la tabla 1023 pueden seleccionarse para clasificar datos por el campo seleccionado. Por ejemplo, si se hace clic en el encabezamiento de paquetes en la tabla a continuación la tabla se clasificaría por la columna de paquetes en orden descendente de actividad y si se hace clic de nuevo en esta cabecera, a continuación se clasificaría en el orden opuesto. La selección de los otros encabezados de tabla clasifica las entradas de manera similar.
La figura 11 ilustra la capacidad de hacer zoom de la presente invención. El intervalo de tiempo inicio/parada de 7:18/12:02 en la figura 10 se estrecha al intervalo de tiempo de 9:00/10:00 en la figura 11. La tabla 1023 y los trazados 1032, 1034 se han actualizado en consecuencia. Los valores de campo de inicio 1013 y de parada 1014 pueden ajustarse o bien mediante entrada manual en los propios campos 1013, 1014, o por selección gráfica, mediante un ratón por ejemplo, de un intervalo de tiempo en los trazados 1032, 1034. Tras la selección, la visualización hará zoom para acercar el intervalo seleccionado. Haciendo zoom para acercar sobre los trazados hace que los trazados se regeneren para el intervalo seleccionado por el usuario. La selección del botón 1036 "Actualizar Tablas y Trazados" a continuación sincronizará datos en el recuadro 1010 de tablas con los trazados 1032, 1034. Los trazados podrían también actualizarse automáticamente, si el usuario seleccionara la característica de "auto-sincr" (no mostrada). El botón 1036 "Actualizar Tablas y Trazados" permite a un usuario hacer zoom para acercar varias veces hasta un intervalo de tiempo deseado sin actualizar los datos. Esto proporciona la ventaja de reducir procesamiento innecesario por parte del monitor de red hasta que se elija el intervalo final.
Los protocolos enumerados como entradas en la tabla 1023 en la figura 10 pueden seleccionarse por un usuario, como hiperenlaces, por ejemplo, para enumerar protocolos encapsulados dentro del protocolo seleccionado. Haciendo clic o seleccionando la entrada IP en la tabla 1023 en la figura 10 da como resultado la visualización de la figura 12. La selección provoca que los trazados 1032, 1034 en el recuadro 1030 de trazados de la figura 10 se actualicen automáticamente para mostrar sólo tráfico IP en los trazados 1232, 1243 en la figura 12.
Los trazados ilustran todos los tráficos desde la capa de enlace como un gráfico 1235 lineal y todos los tráficos IP como un gráfico de barras. Este formato de visualización dual proporciona una representación gráfica de la perspectiva entre todos los tráficos de un nivel (IP en este caso) comparado con todos los tráficos de un nivel previo (Ethernet en este caso).
Los contenidos de las tablas en el recuadro 1210 de tablas se actualizan también para que se correspondan con el tráfico IP. La tabla 1223 enumera todos los protocolos IP que estaban usándose sobre el enlace que está monotorizándose entre los tiempos de "inicio" y "parada". En este caso particular, sólo se encontraron los protocolos IP TCP, UDP e ICMP. Puede visualizarse también la actividad por parte de ordenadores centrales IP. Desplazándose hacia abajo por el recuadro 1210 de tabla, la tabla de cuentas IP por parte del ordenador central de origen se ve según se ilustra en la figura 13 para el caso en el que TopN=2.
En la figura 13, se visualiza el tráfico en una tabla 1302 de ordenador central de origen para tráfico generado por ordenadores centrales, en una tabla 1304 de ordenador central de destino para tráfico recibido por un ordenador central, y en una tabla 1306 de ordenador central para tráfico generado y recibido por un ordenador central. Haciendo clic sobre un enlace 1308 en el recuadro 1310 de tablas se generará una visualización de una tabla 1402 de "pares de ordenadores centrales" mostrada en la figura 14.
La tabla 1402 de pares de ordenadores centrales enumera el número total de paquetes y bytes enviado entre pares de ordenadores centrales para cada par identificado.
La selección de un "ordenador central de destino" tal como 10.0.0.47 (1404 en la figura 14) filtrará adicionalmente el tráfico por parte del "ordenador central de destino" seleccionado para mostrar sólo tráfico destinado al ordenador central 10.0.0.47. Esto se ilustra en la figura 15 en la que la tabla 1502 muestra tráfico destinado a 10.0.0.47, todos desde el ordenador central 128.32.130.10 en este caso para tráfico monitorizado entre el intervalo de inicio y parada.
Por tanto, se ve que sólo el ordenador central 128.32.130.10 estaba enviando tráfico a 10.0.0.47 entre los tiempos de "inicio" y "parada". Debe observarse que los trazados 1532,1534 en el recuadro 1530 de trazados muestra ahora esta actividad entre estos dos ordenadores centrales como un gráfico 1535 de barras y todos los tráficos IP como un gráfico 1536 lineal. Pueden usarse también colores para distinguir los datos en los trazados o tablas.
Si se selecciona la entrada TCP en la tabla 1223 en la figura 12, nos movemos hacia arriba en la pila de protocolo y el recuadro 1610 de tablas se actualiza según se muestra en la figura 16 para incluir cuentas de nivel TCP para cada aplicación 1612 subyacente. Por ejemplo, había 27K paquetes HTTP (web) que contenían 21 MegaBytes que se recibieron durante el intervalo de tiempo designado.
En la figura 16, si se selecciona el botón 1604 "de flujos TCP", se visualizan todos los flujos TCP con sus métricas de duraciones de tiempo y de rendimiento según se muestra en la figura 17. Un flujo TCP contiene un conjunto de paquetes que pertenecen a una sesión TCP entre dos ordenadores centrales. Cada flujo puede trazarse o sus correspondientes paquetes verse seleccionando el botón 1702 "diagrama" o el botón 1704 "paquetes", respectivamente, correspondientes al flujo TCP deseado. Debe observarse que si se hubiera seleccionado la opción hacer DNS, todas las direcciones IP de ordenador central TCP se sustituirían por sus nombres respectivos (por ejemplo foo.niksun.com). Un usuario puede agregar flujos haciendo clic en otros enlaces tales como los que identifican un ordenador central particular tal como 10.0.0.47. Si un usuario hace clic en 10.0.0.47 (1706), se visualizarán flujos agregados para el ordenador central 10.0.0.47 según se muestra en la figura 18.
La figura 18 muestra todos los flujos TCP que se originan desde el ordenador central 10.0.0.47. La visualización en la figura 18 se genera aplicando un filtro selectivo al ordenador central 10.0.0.47 respecto a los datos visualizados en la figura 17. Pueden aplicarse de manera similar filtros adicionales haciendo clic en otros ordenadores centrales (hiperenlaces) en la figura 18. Por ejemplo, en la columna "ordenador central de término", si un usuario selecciona el ordenador central 10.0.0.5 (1802), a continuación se visualizan todos los flujos TCP entre el ordenador central 10.0.0.47 (como origen) y el ordenador central 10.0.0.5 (como destino).
Puede proporcionarse una selección "rendimiento TCP", en la visualización de pantalla de la figura 16, por ejemplo, para generar tablas de rendimiento TCP. Haciendo clic en el hiperenlace "rendimiento TCP", se visualizan tablas 1902 de rendimiento para TCP según se muestra en la figura 19. La totalidad del recuadro de tablas se visualiza en la figura 19 para mayor claridad. La visualización incluye una tabla de "Clientes TCP con problemas" y una tabla de "Servidores TCP con problemas" para los dos clientes y servidores TCP con el peor rendimiento (valor de campo TopN de 2). A lo largo del intervalo de tiempo especificado por los campos de inicio y parada, las tablas muestran las siguientes mediciones para cada cliente o servidor TCP:
1. N.º de conexiones: Esto es el número total de conexiones TCP al cliente o servidor.
2. Bytes de datos TCP: Esto muestra el número total de bytes de datos llevados por todas las conexiones TCP.
3. Rendimiento global de nivel de aplicación TCP (Bytes/seg): Esto muestra el rendimiento global de carga útil TCP (rendimiento global de aplicación) o rendimiento global de nivel de aplicación TCP. Es decir, el número total de bytes de aplicación dividido por el tiempo que tarda en enviar estos bytes promediados respecto al número de conexiones.
4. Rendimiento global TCP (Bytes/seg): Esto muestra el número total de bytes llevados en las conexiones TCP dividido por el tiempo (tasa de flujo TCP).
5. RTT promedio: Esto muestra el tiempo de propagación de ida y retorno promedio entre el cliente y el servidor respecto al número de conexiones.
6. Respuesta promedio: Esto muestra el tiempo de respuesta promedio desde el servidor hasta el cliente.
7. % retransmitido: Esto muestra el porcentaje de bytes TCP que se retransmitieron (debido a congestión, pérdida, o retardo, o cualquier otro motivo).
\vskip1.000000\baselineskip
Las tablas de rendimiento TCP pueden personalizarse para añadir otras métricas o borrar métricas existentes a través de la interfaz de usuario.
Seleccionar el hiperenlace http en la figura 16 da como resultado la visualización de estadísticas para tráfico web (http) según se muestra en la figura 20.
Puede proporcionarse una selección "rendimiento http", en la visualización de pantalla de la figura 20, por ejemplo, para generar tablas de rendimiento http. Haciendo clic en el hiperenlace "http rendimiento", se visualizan tablas 2102 de rendimiento para http según se muestra en la figura 21. La totalidad del recuadro de tablas se visualiza en la figura 21 para mayor claridad. La visualización incluye una tabla de "clientes WWW con problemas" y una tabla de "servidores WWW con problemas" para los dos clientes y servidores WWW con el peor rendimiento (valor de campo TopN de 2).
Las métricas en las tablas 2102 de rendimiento http pueden generarse en línea y visualizarse al usuario como clientes www y servidores www con problemas o pueden alimentarse directamente a un sistema de gestión de red para la acción inmediata. Estas métricas pueden ayudar a un administrador de red a identificar servidores y conexiones malos. Esta información puede usarse también como base para notificar al operador de servidor web para que compre más ancho de banda o para que fije su servidor. Adicionalmente, puede usarse para notificar a clientes que pueden necesitar más ancho de banda o que pueden necesitar elegir otro proveedor de servicio. Por consiguiente, estas métricas pueden usarse para mejorar la calidad de servicio dada a los usuarios y por último puede proporcionar ingresos adicionales al administrador de red. Por ejemplo, en la tabla "servidores WWW con problemas", el segundo servidor enumerado (204.162.96.10) tenía aproximadamente el 33% abortos web. Esto puede indicar una pérdida potencial del 33% de los clientes de este sitio web.
El recuadro 1610 de tablas se actualiza tal como se muestra en la figura 16 para incluir cuentas de nivel TCP para cada aplicación 1612 subyacente. Por ejemplo, había 27K paquetes HTTP (web) que contenían 21 megabytes que se recibieron en el intervalo de tiempo designado.
Tras la selección del hiperenlace 1240 UDP en la figura 12, nos movemos hacia arriba en la pila de protocolo y se proporciona la visualización de la figura 22 para ilustrar niveles de tráfico UDP. En el recuadro 2210 de tablas, se visualiza una tabla de "cuentas de nivel UDP" que muestra actividad para cada aplicación UDP o puerto UDP. Por ejemplo, la visualización indicó que había 453 paquetes de dominio que contenían 69 kilobytes.
Debe observarse que el uso de ancho de banda UDP sólo era de aproximadamente el 0,32 % del IP total (véase la tabla 1223 en la figura 12). Por tanto, el recuadro de trazados sólo muestra tráfico IP (gráfico ROJO) que minimiza el tráfico UDP (en AZUL). Haciendo clic sobre la "Visualización Padre de Conmutación" el usuario puede ahora hacer zoom para acercar el eje Y sólo en el tráfico UDP (esto no se ilustra) puesto que el trazado para IP (trazado padre) se eliminará.
La selección del botón 2202 "MBONE" en la figura 22 da como resultado la visualización de un análisis de capa de aplicación de sesiones MBONE (Multimedia backbone, red troncal multimedia) tal como se muestra en la figura 23.
La selección del botón 2204 "Ver Paquetes" en el recuadro 2250 de botones en la figura 22 proporciona un volcado de todos los paquetes tal como se muestra en la figura 24. Puesto que el monitor de red puede registrar todos los paquetes, pueden verse todos los paquetes y sus contenidos. Los enlaces en la visualización de la figura 24 permiten a un usuario filtrar de manera flexible las corrientes de datos. Si el usuario hace clic sobre 10.0.0.12 (2402), entonces la siguiente pantalla de volcados sólo contendrá paquetes hasta y desde 10.0.0.12. En esa siguiente pantalla, si un usuario seleccionó 10.0.0.5, entonces la visualización actualizada sólo mostraría paquetes entre 10.0.0.12 y 10.0.0.5. Un usuario podría calificar también adicionalmente el volcado seleccionando puertos. Pueden aplicarse diversas opciones para volcar paquetes seleccionando un tipo de volcado a partir de las selecciones 2404 en la parte superior de la visualización de pantalla.
La selección del botón 2206 "Recomendado" en el recuadro 2250 de botones de la figura 22 tiene como consecuencia la visualización de recomendaciones de capacidad o ancho de banda en tiempo real para la red. Tras la detección de selección del botón 2206 "Recomendado", el monitor de red usa un modelo matemático para interpretar los datos que el usuario está viendo para proporcionar recomendaciones acerca del uso de ancho de banda mediante una aplicación (u otros tipos de tráfico) o al establecer capacidad de enlace/conmutación para obtener una calidad de servicio específica. Varias de tales estadísticas 2502 se muestran en la figura 25. Un usuario puede introducir valores de calidad de servicio deseados tales como tasas de pérdida y retardos máximos para obtener recomendaciones acerca de la capacidad requerida para soportar la calidad de servicio deseada para el tipo de tráfico analizado. Las figuras 25 y 26 ilustran las recomendaciones que pueden proporcionarse.
\newpage
En una realización a modo de ejemplo el usuario puede seleccionar una aplicación particular y un "periodo ocupado" para el que quiere "dimensionar" los recursos de red para un nivel de calidad de servicio particular. Subrutinas apropiadas en el monitor de red analizan entonces el tráfico de aplicación particular y extraen o estiman "parámetros de modelo". Usando el modelo matemático y estimaciones de los parámetros, así como parámetros de calidad de servicio (tales como tasas de pérdida de paquetes, retardos de red, tasas de trama, etc.) el modelo calcula estadísticas tales como ganancias de multiplexación estadística, requisitos de capacidad, y asignaciones de memoria intermedia y proporciona al usuario recomendaciones óptimas de configuraciones de conmutador/encaminador, recursos de red, o parámetros de servidor para maximizar la utilización de red cumpliendo los requisitos de calidad de servicio. Tales recomendaciones pueden calcularse en tiempo real donde la estadística se actualiza para cada paquete o un conjunto de paquetes que pertenecen a diferentes servicios y puede proporcionarse realimentación a elementos de red a lo largo del trayecto para cada flujo en configuraciones óptimas para hacer posible la asignación de recursos dinámicos para cumplir requisitos de calidad de servicio.
El eje x 2602 del gráfico representa el número de usuarios y el eje y 2604 representa la capacidad en bits/segundo. Para un número deseado de usuarios, la capacidad puede leerse a partir de la tabla o a partir de una visualización de resultados tabulares correspondientes. La figura 27 ilustra una visualización similar a la de la figura 22 para el caso en el que el botón Hacer DNS se seleccionó de modo que las direcciones IP se transforman en sus nombres registrados.
La figura 28 es una visualización que muestra estadísticas que se visualizan tras la selección del botón 2208 "Estadísticas" en el recuadro 2250 de botones en la figura 22. Tras la selección del botón 2208 "Estadísticas", el monitor de red calcula diversas estadísticas basándose en datos que el usuario está viendo actualmente. Estadísticas a modo de ejemplo incluyen distribuciones de tamaño de paquete, distribuciones de protocolo, uso de ancho de banda por cada cliente, uso de ancho de banda por dominio, tiempo de respuesta promedio por cada servidor, tiempo de propagación de ida y retorno entre par servidor- cliente, y métricas de rendimiento.
La presente invención no está limitada a una división particular de funciones entre el ordenador central y el ordenador de interfaz. Las funciones del ordenador central y del ordenador de interfaz pueden realizarse por un único ordenador. La interfaz con un monitor de red según la presente invención no está limitada a la interfaz de usuario y puede ser a través de la red que está monitorizándose u otra línea de comunicación.
La figura 29 ilustra un sistema de monitorización a modo de ejemplo que incluye un monitor 2902 de red (Detector_de_red) que está acoplado a una primera línea 2904 de comunicación a través de un derivador 2906. El monitor 2902 de red recibe (monitoriza) comunicaciones de datos (tráfico) en la línea 2904 de comunicación y selecciona determinados paquetes a partir de los datos basándose en las características de esos paquetes. El monitor 2902 de red proporciona entonces los paquetes seleccionados a una de una pluralidad de unidades 2908, 2910, 2912 de procesamiento de datos. El monitor de red puede proporcionar inmediatamente paquetes recibidos a las unidades de procesamiento de datos o puede almacenar y recuperar posteriormente los paquetes según criterios de filtrado. Los paquetes recibidos pueden seleccionarse basándose en uno o más de una dirección de origen, una dirección de destino, un tipo de paquete, un sistema autónomo, un puerto de origen, tiempo, un puerto de destino, un identificador de red y un par de ordenadores centrales, por ejemplo.
Esta arquitectura permite a un monitor 2902 de red que tiene un rendimiento global elevado y una capacidad de almacenamiento de gran volumen realizar una función de procesamiento de datos en paralelo para cada uno de varios grupos seleccionados de paquetes usando unidades 2908-2912 de procesamiento de datos que tienen una capacidad de rendimiento global inferior a la del monitor 2902 de red.
En una realización a modo de ejemplo las unidades 2908, 2910, 2912 de procesamiento de datos son sistemas de detección de intrusión (IDS). El monitor 2902 de red proporciona grupos de paquetes seleccionados a cada IDS para permitir al sistema que explore intrusiones con un rendimiento global mayor que un único sistema de detección de intrusión.
El sistema puede optimizar el sistema de detección de intrusión basándose en los criterios para seleccionar paquetes que se reciben desde la línea de comunicación. En una realización a modo de ejemplo el monitor de red realiza esto o bien registrando sesiones en medios de almacenamiento y reproduciendo sesiones (o flujos, por ejemplo, flujos TCP/IP - SYN-FIN) de nuevo en diferentes dispositivos IDS; o enviando sesiones directamente desde dispositivos de captura de red a interfaz (interfaces) de salida o unidades de procesamiento de datos que pueden estar bajo el mismo o diferente protocolo que en la línea de comunicación o pueden estar en un formato cifrado.
Una sesión puede identificarse como todos los paquetes desde IP DE ORIGEN \ding{212} IP DE DESTINO o todo desde un IP DE ORIGEN o red o flujo TCP entre un par de ordenadores centrales o flujo HTTP entre un par de ordenadores centrales o paquetes UDP desde un ordenador central o red, por ejemplo.
El sistema proporciona detección mejorada de exploraciones de puerto a través de un sistema que selecciona de manera aleatoria paquetes para la distribución a las diferentes unidades de procesamiento de datos o IDS seleccionando todos los paquetes correspondientes a exploraciones de puerto para un único puerto para la distribución a un IDS particular. Esto mejora también la capacidad del sistema para identificar exploraciones de puerto o exploraciones de dirección que pueden producirse a tasas lentas o rápidas; redes, ordenadores centrales desde los que tuvieron lugar ataques de denegación de servicio o de denegación de Servicio distribuidos; tráfico o "comportamiento" anómalo desde ordenadores centrales o usuarios en comparación con actividad histórica (hora del día, día de la semana, para establecer norma o umbrales); transacciones falsas o no habituales en comercio electrónico, por ejemplo actividad repentina para negociar intercambios en la bolsa para diferentes usuarios desde una dirección IP.
La figura 30 ilustra una jerarquía de monitores de red para monitorizar una red. La jerarquía permite la gestión centralizada del sistema de monitorización de red a partir de una única interfaz. Un usuario puede ver una red de monitores de red y su relación jerárquica entre sí. Cualquier unidad en la red puede configurarse y pueden verse estadísticas de tráfico desde una interfaz de usuario unificada.
La gestión centralizada permite la configuración unificada y acceso de múltiples nodos de monitor de red (NetVCR) desde una única interfaz. Los monitores de red están dispuestos en una jerarquía de antepasado/descendiente; los antepasados mantienen información sobre sus descendientes, y los descendientes informan de su estado (y el estado de cualquiera de sus descendientes) a su antepasado inmediato. La interfaz de gestión centralizada permite una vista fácil de todos los nodos descendientes, y proporciona acceso a interfaces de análisis de tráfico y configuración de monitor de red.
Cuando se añade un monitor de red nuevo a la red debe configurarse con la dirección IP de su antepasado inmediato para iniciar el proceso de registro. El nuevo monitor de red descendiente se registra con el nodo de antepasado, suministrando información sobre sí mismo y sus descendientes. El antepasado creará un registro del descendiente (o descendientes) en su base de datos. Tras el registro el descendiente envía periódicamente un mensaje de mantenerse activo a su antepasado inmediato. Si un descendiente se elimina del sistema el antepasado ya no estará recibiendo señales desde ese descendiente y el antepasado establecerá el estado de ese descendiente a inactivo (fuera de línea).
La figura 31 ilustra una interfaz de gestión centralizada de un sistema de monitorización de red jerárquica. La gestión centralizada proporciona una vista de "árbol genealógico" de la red NetVCR. La interfaz muestra gráficamente la relación jerárquica de las diversas unidades NetVCR. La vista de árbol puede expandirse un nivel cada vez, permitiendo al usuario analizar a fondo la jerarquía de red NetVCR.
La subventana izquierda de la interfaz contiene la vista de árbol NetVCR. Su formato es similar a una representación de gestor de archivos de directorios, subdirectorios y archivos. La vista de árbol tiene tres lengüetas a lo largo de la parte superior, Análisis, SLA, y Alarmas. En la figura 31 sólo se implementa la lengüeta Análisis. Al principio la vista de árbol está completamente plegada, significando que sólo el nodo raíz es visible en el árbol. Haciendo doble clic sobre un nodo lo expandirá un nivel, revelando los descendientes inmediatos del nodo. Haciendo doble clic sobre el nodo se plegará de nuevo la rama.
El icono hacia la izquierda de cada nombre de nodo indica su papel en la red NetVCR. Un icono de un globo indica un nodo de antepasado, y un icono de un ordenador indica un nodo sólo de descendiente. Si el icono se pone rojo, entonces el nodo está actualmente fuera de línea o el enlace de comunicación entre el descendiente y el antepasado se ha perdido.
Un único clic sobre un nodo proporciona a la Tabla de Datos de Tráfico de Red, a la derecha de la vista de árbol, información sobre los conjuntos de datos en ese nodo. La tabla proporciona la siguiente información:
Registrado: el nombre de ordenador central de la NetVCR que registró el conjunto de datos.
Interfaz: el tipo de interfaz del conjunto de datos.
Estado: El estado de registro del conjunto de datos. Puede tener uno de los cuatro valores siguientes: registrar, parado, registro archivado y archivo parado.
Comentario: el nombre de conjunto de datos del conjunto de datos tal como se define en la página de configuración de conjunto de datos.
Inicio de datos y Parada de datos: los tiempos de inicio y parada del conjunto de datos.
Dispositivo: la interfaz física usada para registrar datos de tráfico.
\vskip1.000000\baselineskip
En la parte inferior de la Tabla de Datos de Tráfico de Red hay dos botones que hacen posible líneas de cuadrícula horizontales y verticales en la tabla. Una vez que se ha seleccionado un conjunto de datos a partir de la Tabla de Datos de Tráfico de Red, el Menú de Operación de Conjunto de Datos a la derecha de la Tabla de Datos se usa para especificar los parámetros de los datos que van a visualizarse. Estos campos y botones corresponden a los controles para análisis de conjunto de datos.
Inicio y Parada: el intervalo de tiempo que se desea para análisis.
Capa de Protocolo: una lista de menú desplegable de las capas de protocolo disponibles para análisis (incluyendo Trama, Enlace, IP, TCP y UDP).
Analizar: haciendo clic sobre este botón conecta a la página de análisis NetVCR para el conjunto de datos seleccionado, usando los parámetros establecidos por los campos de Inicio, Parada y Capa de protocolo.
Configurar: este botón conecta a la Página de Configuración de Conjunto de datos de NetVCR para el conjunto de datos seleccionado.
Informes: haciendo clic sobre este botón conectará a la Página de Informes de NetVCR y permitirá al usuario ver informes Estándar y Personalizados.
Informes periódicos: Este botón conecta a la Página de Configuración de Informe de NetVCR para el conjunto de datos seleccionado y la capa de protocolo elegida.
\vskip1.000000\baselineskip
Un sistema autónomo (AS) es un grupo de redes IP operadas por uno o más operador/es de red que tiene una política de encaminamiento externa única y claramente definida. Un filtro especificado por el usuario puede usarse para definir el sistema autónomo. Por ejemplo una calificación válida podría ser (net 121.097.0.0 máscara 255.255.0.0) o (121.099 máscara 255.255.0.0) o (net 121.100/16).
Un monitor de red distribuido permite la correlación y agregación de datos a través de la red. Esto permite el seguimiento de eventos (por ejemplo, actividad de piratas informáticos o saboteadores) a través de la red (al origen). Esto es efectivo debido a sellos de tiempo precisos a través de interfaces.
Un monitor de red puede explorar patrones indicativos de un intruso: exploraciones de puerto en todos los puntos de entrada; intentos de telnet en todos los puntos de entrada; patrones que indican la denegación de ataque de servicio; patrones que indican la denegación coordenada de ataques de servicio; modificaciones a archivos clave que pueden indicar la inserción de una puerta trasera (back door) en un sistema.
Un monitor de red puede usarse para:
\bullet
proporcionar una notificación de "solicitud de acción" para cerrar el(los) punto(s) de entrada. Esta acción podría conseguirse a través de un agente inteligente, modificaciones al ACL, o a través de un operador.
\bullet
determinación de si se han creado "puertas traseras".
\bullet
proporcionar una notificación de "solicitud de acción" para cerrar cualquier trayecto de entrada adicional que haya sido creado por el pirata informático. Esta acción podría conseguirse a través de un agente inteligente o un operador.
\bullet
visualizar el historial de las acciones del pirata informático.
\bullet
proporcionar registros de cualquier archivo descargado al sistema violado.
\bullet
identificación de lo que se ha puesto en peligro y proporcionar una notificación de "solicitud de acción", permitiendo por tanto a los administradores llevar a cabo acciones para "deshacer" el daño producido.
\bullet
proporcionar información detallada sobre el culpable para su procesamiento judicial, es decir, una "trayectoria de prueba". Las aplicaciones específicas que pueden soportarse a través de NetDetector incluyen:
-
explorar patrones indicativos de un intruso externo y alertar a los administradores de la posibilidad de un ataque en curso.
-
explorar patrones de mal uso de recursos cooperativos por personal interno
-
trabajar de manera cooperativa con un primer sistema de primera línea de defensa ya desarrollado dentro de la red para identificar si la intrusión sigue en curso; si se han creado puertas traseras; lo que se ha puesto en peligro y detalles sobre el culpable.
-
trabajar de manera cooperativa con un motor inteligente que puede aprender de manera autónoma a expandir de manera continua y mejorar los patrones de alarma.
Un monitor de red según la presente invención puede establecer los siguientes umbrales para detectar actividad anómala:
-
para un conjunto particular de aplicaciones, el número de conexiones de par de ordenadores centrales IP que implican una dirección IP común (o bien el origen o el destino) supera x en una ventana de tiempo de y. x e y debería ser configurable por el usuario. El conjunto de aplicaciones debería incluir un conjunto de reglas positivas, por ejemplo, telnets y ping, así como reglas negativas tales como "no http".
Esto puede usarse para hacer seguimiento de la denegación de ataques de servicio y exploraciones de ordenador central IP.
-
para un par de ordenadores centrales IP particular, la tasa de transmisión de bytes supera x en un periodo continuo de y. x e y debería ser configurable por el usuario. El conjunto de aplicaciones debería incluir un conjunto de reglas positivas, por ejemplo telnets y ping, así como reglas negativas tales como "no http".
Esto puede usarse para hacer seguimiento de uso sospechoso "excesivo" a un destino desde un origen particular. Por ejemplo, irrupciones en un ordenador central particular.
-
para un ordenador central IP particular, el número de sesiones individuales supera x o en un periodo continuo de y. x e y debería ser configurable por el usuario. El conjunto de aplicaciones debería incluir un conjunto de reglas positivas, por ejemplo telnet y ping, así como reglas negativas tales como "no http".
Esto puede usarse para hacer seguimiento de actividades de sesión sospechosas "excesivas" a un destino desde un origen particular. Por ejemplo, irrupciones en un ordenador central particular.
-
la utilización del enlace monitorizado supera una tasa x y continúa en un periodo de tiempo y. x e y debería ser configurable por el usuario.
Esto puede usarse para hacer seguimiento de la denegación de ataques de servicio.
-
un paquete con una dirección de origen no válido o IP de destino atraviesa el enlace monitorizado. (Esto puede realizarse si puede especificarse estadísticamente un conjunto de direcciones de origen IP "válidas" que comprenden la nube de red final). Para enlaces, origen y destino unidireccionales puede comprobarse por separado. Para medios compartidos tales como Ethernet, sólo podría dispararse una alarma si tanto las direcciones de origen como de destino son inválidas.
Esto podría comprobar direcciones suplantadas.
-
Comprobar un patrón de byte genérico en la carga útil. Esta característica exploraría paquetes seleccionados (tráfico filtrado) para una coincidencia de un patrón de byte definido por usuario.
Características de alarma
Una trampa SNMP puede enviarse a un sistema de gestión conectado cuando se supera un umbral. Además podría proporcionarse también alarma a Janus para mostrar alarmas en la interfaz basada en web (tal como cuando se recibe un correo electrónico).
Características de GUI/configuración
Un usuario puede configurar los parámetros necesarios para la comprobación de umbral. Esto significa que las "x" e "y" tal como se especificó anteriormente pueden especificarse por el usuario así como otra información necesaria para definir el umbral, por ejemplo lista de direcciones de origen y/o destino "válidas".
-
capacidad para identificar un único ordenador central IP que ha iniciado cantidades "excesivas" de conexiones con otros ordenadores centrales IP
-
capacidad para especificar el intervalo de tiempo, el número de intentos de conexión que califica como excesivo y la frecuencia de intentos que debería considerarse excesiva
-
capacidad para identificar conexiones IP a IP únicas que usan una cantidad excesiva de puertos en la conexión
-
capacidad para determinar cuando una actividad de red está superando "umbrales normales" (picos de ancho de banda durante largos periodos)
-
capacidad para especificar el intervalo de tiempo y la altura del pico que se consideraría excesivo
-
capacidad del usuario de especificar una lista de "puertos válidos" y alarma sobre cualquier intento de conexión a puertos no especificados
-
capacidad para alertar al administrador de red en caso de una actividad sospechosa
-
capacidad para proporcionar alarmas de audio y visuales en la pantalla del administrador de red
-
capacidad para proporcionar al administrador flexibilidad máxima acerca de alarmas (por ejemplo, buscapersonas; teléfono celular; correo electrónico)
Vista general de la arquitectura
La figura 32 muestra la arquitectura básica del sistema NetDetector:
el módulo de control comunica y dirige las acciones de todos los demás componentes de NetDetector. Éstas son:
-
detector de actividad: módulo de actividad de red y de reconocimiento de patrones
-
gestor de datos: módulo de archivo de datos y de exportación
-
alertador: módulo de alerta
El módulo de configuración configura el módulo de control. El módulo de configuración es responsable de la base de datos (DB) de reconocimiento de patrones, desde la que los patrones que van a detectarse, y las acciones que van a llevarse a cabo se leen por el detector de actividad.
El módulo de alerta es responsable de generar alertas según parámetros de acción configurados. Las alertas pueden producirse de diversas formas, seleccionadas por el usuario, tales como: trampas SNMP, correo electrónico, buscapersonas, o consola.
El gestor de datos tiene dos componentes: el módulo de archivo y el módulo de exportación. El módulo de archivo es responsable de guardar datos de paquete relevantes para el evento de alerta de modo que el proceso de envejecimiento no lo borre. El módulo de exportación gestiona la transmisión de datos relevantes a sistemas externos para análisis adicional.
Detectando picos repentinos en el tráfico de red que duran más de una duración especificada, NetDetector puede señalar cuándo están en curso posibles ataques de DoS (denegación de servicio). Además, mantener el seguimiento de solicitudes SYN no resueltas y paquetes de solicitudes de eco ICMP es otro modo de detectar posibles ataques de DoS.
Un monitor de red según la presente invención puede aprender de manera autónoma a hacer posible realizar cuando la actividad de red aumentada se ha convertido en la norma sin que el administrador de red especifique el cambio.
-
búsqueda de expresión regular en correo electrónico (análisis SMTP/POP), páginas web (análisis HTTP), y otros mensajes de nivel de aplicación (por ejemplo, FTP, TELNET).
-
Capacidad de interoperación con sistemas de detección de intrusión.
Aunque se ha ilustrado y descrito anteriormente con referencia a determinadas realizaciones específicas, la presente invención no pretende sin embargo limitarse a los detalles mostrados. Más bien pueden realizarse diversas modificaciones en los detalles dentro del alcance de las reivindicaciones.

Claims (20)

1. Método para detectar intrusiones que comprende las etapas de:
(a)
recibir datos desde una línea (2904) de comunicación;
(b)
segregar los datos en paquetes;
(c)
identificar una característica respectiva de cada paquete respecto a patrones indicativos de un aspecto de intrusión o tipo de intrusión, y
(d)
proporcionar selectivamente los paquetes a uno de una pluralidad de dispositivos (2908, 2910, 2912) de detección de intrusión paralelos según la característica identificada de cada paquete.
2. Método según la reivindicación 1 en el que la característica comprende además una sesión.
3. Método según la reivindicación 1 en el que la característica está basada además en al menos uno de una dirección de origen, una dirección de destino, un sistema autónomo, un puerto de origen, un puerto de destino, un identificador de red y un par de ordenadores centrales.
4. Método según cualquiera de las reivindicaciones 1 a 3 que comprende además la etapa de cifrar los paquetes antes de proporcionarlos en la etapa (d).
5. Método según la reivindicación 1 en el que la característica comprende además un tipo de paquete.
6. Método según la reivindicación 1 que comprende además la etapa de almacenar los paquetes segregados y la etapa (c) incluye identificar una característica respectiva de los paquetes almacenados.
7. Método según cualquiera de las reivindicaciones 1 a 6 en el que la etapa (a) incluye recibir datos formateados según un primer protocolo y la etapa (d) incluye proporcionar selectivamente los paquetes formateados según un segundo protocolo diferente del primer protocolo.
8. Método según cualquiera de las reivindicaciones 1 a 7 en el que al menos uno de la pluralidad de dispositivos (2908, 2910, 2912) de detección de intrusión paralelos genera una estadística correspondiente a sus paquetes proporcionados; compara la estadística generada con un valor umbral; y genera una señal de alarma si la estadística supera el umbral.
9. Método según la reivindicación 8 en el que la estadística corresponde a un número de paquetes de diferentes usuarios recibidos desde una dirección de origen.
10. Método según la reivindicación 8 en el que la estadística corresponde a un número de paquetes recibidos para modificar un archivo clave.
11. Método según la reivindicación 8 en el que la estadística corresponde a un número de conexiones de par de ordenadores centrales que implican una dirección de origen o destino común.
12. Método según la reivindicación 8 en el que la estadística corresponde a una tasa de transmisión de paquetes correspondiente a un par de ordenadores centrales.
13. Método según la reivindicación 8 en el que la estadística corresponde a sesiones individuales correspondientes a un ordenador central.
14. Método según la reivindicación 8 en el que la estadística corresponde a la utilización de la línea (2904) de comunicación en un periodo dado de tiempo.
15. Método según la reivindicación 8 en el que la estadística corresponde a un número de direcciones de origen o destino inválidas.
16. Método según la reivindicación 8 en el que el al menos uno de la pluralidad de dispositivos (2908, 2910, 2912) de detección de intrusión paralelos genera el valor umbral basándose en valores históricos de su estadística generada correspondiente.
17. Aparato para detectar intrusiones que comprende:
un monitor (2902) de red acoplado a una línea (2904) de comunicación y configurado para recibir datos desde la línea (2904) de comunicación, para segregar los datos en paquetes, y para identificar una característica respectiva de cada paquete recibido respecto a patrones indicativos de un aspecto de intrusión o tipo de intrusión; y
una pluralidad de dispositivos (2908, 2910, 2912) de detección de intrusión paralelos acoplados al monitor (2902) de red;
en el que el monitor (2902) de red proporciona selectivamente paquetes a uno de la pluralidad de dispositivos (2908, 2910, 2912) de detección de intrusión paralelos según la característica identificada de cada paquete.
18. Aparato según la reivindicación 17 en el que al menos uno de la pluralidad de dispositivos (2908, 2910, 2912) de detección de intrusión está configurado para generar una estadística correspondiente a los paquetes recibidos desde el monitor (2902) de red, comparar la estadística con un valor umbral correspondiente, y emitir una señal de alarma si la estadística supera el valor umbral.
19. Aparato según la reivindicación 18 en el que el al menos uno de la pluralidad de dispositivos (2908, 2910, 2912) de detección de intrusión está configurado para generar el valor umbral correspondiente basándose en valores históricos de la estadística.
20. Aparato según la reivindicación 17 que comprende un dispositivo (318) de almacenamiento en el que el monitor (2902) de red está configurado para almacenar paquetes en el dispositivo (318) de almacenamiento y a continuación selectivamente recuperar los paquetes desde el dispositivo (318) de almacenamiento basándose en sus características respectivas.
ES01937384T 2000-05-12 2001-05-12 Camara de seguridad para una red. Expired - Lifetime ES2313959T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US20365200P 2000-05-12 2000-05-12
US203652P 2000-05-12

Publications (1)

Publication Number Publication Date
ES2313959T3 true ES2313959T3 (es) 2009-03-16

Family

ID=22754787

Family Applications (1)

Application Number Title Priority Date Filing Date
ES01937384T Expired - Lifetime ES2313959T3 (es) 2000-05-12 2001-05-12 Camara de seguridad para una red.

Country Status (10)

Country Link
US (1) US8275875B2 (es)
EP (2) EP2018018B1 (es)
JP (1) JP2003533925A (es)
AT (2) ATE498270T1 (es)
AU (1) AU2001263127A1 (es)
DE (2) DE60135550D1 (es)
DK (1) DK1297440T3 (es)
ES (1) ES2313959T3 (es)
SG (1) SG143052A1 (es)
WO (1) WO2001088731A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2580304R1 (es) * 2015-02-19 2016-09-27 Endesa Generación, S.A. Sistema de inspección y diagnóstico de infraestructuras y procedimiento asociado

Families Citing this family (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7080160B2 (en) * 2000-04-27 2006-07-18 Qosmetrics, Inc. Method for creating accurate time-stamped frames sent between computers via a network
US7325029B1 (en) * 2000-08-08 2008-01-29 Chang Ifay F Methods for enabling e-commerce voice communication
GB2386531B (en) * 2000-11-29 2005-07-06 Unilogic Inc Method of facilitating operations on data
US8255791B2 (en) 2000-11-29 2012-08-28 Dov Koren Collaborative, flexible, interactive real-time displays
US7058843B2 (en) * 2001-01-16 2006-06-06 Infonet Services Corporation Method and apparatus for computer network analysis
US7124299B2 (en) * 2001-05-18 2006-10-17 Claymore Systems, Inc. System, method and computer program product for auditing XML messages in a network-based message stream
US7451110B2 (en) * 2001-05-18 2008-11-11 Network Resonance, Inc. System, method and computer program product for providing an efficient trading market
US7464154B2 (en) * 2001-05-18 2008-12-09 Network Resonance, Inc. System, method and computer program product for analyzing data from network-based structured message stream
US7936693B2 (en) * 2001-05-18 2011-05-03 Network Resonance, Inc. System, method and computer program product for providing an IP datalink multiplexer
US6874089B2 (en) * 2002-02-25 2005-03-29 Network Resonance, Inc. System, method and computer program product for guaranteeing electronic transactions
US7769997B2 (en) * 2002-02-25 2010-08-03 Network Resonance, Inc. System, method and computer program product for guaranteeing electronic transactions
TWI244297B (en) * 2002-06-12 2005-11-21 Thomson Licensing Sa Apparatus and method adapted to communicate via a network
US7716737B2 (en) * 2002-11-04 2010-05-11 Riverbed Technology, Inc. Connection based detection of scanning attacks
AU2003280873A1 (en) 2002-11-13 2004-06-03 Ktfreetel Co., Ltd. Apparatus for analyzing the packet data on mobile communication network and method thereof
US7263553B2 (en) * 2003-04-11 2007-08-28 Alcatel Network manager SNMP trap suppression
US7602725B2 (en) 2003-07-11 2009-10-13 Computer Associates Think, Inc. System and method for aggregating real-time and historical data
US7817567B2 (en) * 2003-07-28 2010-10-19 Jds Uniphase Corporation Troubleshooting a specific voice over internet protocol (VOIP) telephone call transmitted over a communications network
US8127356B2 (en) * 2003-08-27 2012-02-28 International Business Machines Corporation System, method and program product for detecting unknown computer attacks
JP4484663B2 (ja) 2004-02-02 2010-06-16 株式会社サイバー・ソリューションズ 不正情報検知システム及び不正攻撃元探索システム
US7698730B2 (en) * 2004-03-16 2010-04-13 Riverbed Technology, Inc. Service detection
EP1736016B1 (en) 2004-04-14 2015-06-24 MBalance Research B.V. Method for preventing the delivery of short message service message spam
EP1752002A1 (en) * 2004-05-19 2007-02-14 Wurld Media, Inc. Dynamic connection structure topologies and methods for facilitating the peer-to-peer transfer of digital files
US7672003B2 (en) * 2004-09-01 2010-03-02 Eric Morgan Dowling Network scanner for global document creation, transmission and management
US7603460B2 (en) * 2004-09-24 2009-10-13 Microsoft Corporation Detecting and diagnosing performance problems in a wireless network through neighbor collaboration
EP1667360A1 (en) * 2004-12-06 2006-06-07 BMC Software, Inc. Generic discovery for computer networks
CN100442702C (zh) * 2005-01-05 2008-12-10 华为技术有限公司 实现调制解调器信号故障分析的方法及装置
US20060230450A1 (en) * 2005-03-31 2006-10-12 Tian Bu Methods and devices for defending a 3G wireless network against a signaling attack
US7774849B2 (en) * 2005-04-15 2010-08-10 Tekelec Methods, systems, and computer program products for detecting and mitigating denial of service attacks in a telecommunications signaling network
US7814647B2 (en) 2005-05-27 2010-10-19 Prairie Packaging, Inc. Reinforced plastic foam cup, method of and apparatus for manufacturing same
US7704347B2 (en) * 2005-05-27 2010-04-27 Prairie Packaging, Inc. Reinforced plastic foam cup, method of and apparatus for manufacturing same
US7694843B2 (en) * 2005-05-27 2010-04-13 Prairie Packaging, Inc. Reinforced plastic foam cup, method of and apparatus for manufacturing same
US7552841B2 (en) * 2005-05-27 2009-06-30 Prairie Packaging, Inc. Reinforced plastic foam cup, method of and apparatus for manufacturing same
US7818866B2 (en) 2005-05-27 2010-10-26 Prairie Packaging, Inc. Method of reinforcing a plastic foam cup
US7536767B2 (en) * 2005-05-27 2009-05-26 Prairie Packaging, Inc. Method of manufacturing a reinforced plastic foam cup
US20070033641A1 (en) * 2005-07-07 2007-02-08 Acenet Technology Inc. Distributed Network Security System
US8965334B2 (en) * 2005-12-19 2015-02-24 Alcatel Lucent Methods and devices for defending a 3G wireless network against malicious attacks
DE602006014667D1 (de) * 2006-06-23 2010-07-15 Nippon Office Automation Co Lt Protokoll- und Sitzunganalysator
DE102006035834A1 (de) * 2006-08-01 2008-02-07 Nokia Siemens Networks Gmbh & Co.Kg Analyseeinheit für ein paketvermittelndes Kommunikationsnetz
US20100278068A1 (en) * 2007-04-16 2010-11-04 Neuralitic Systems Method and System for Filtering IP Traffic in Mobile IP Networks
US20090006252A1 (en) * 2007-06-29 2009-01-01 Ebay Inc. Billing data report system
US7839268B2 (en) * 2007-08-22 2010-11-23 International Business Machines Corporation Method, system and program product for tonal audio-based monitoring of network alarms
KR101397012B1 (ko) * 2007-11-20 2014-06-27 엘지전자 주식회사 단말기 및 단말기의 데이터 통신을 위한 서비스 설정 방법
US8949257B2 (en) * 2008-02-01 2015-02-03 Mandiant, Llc Method and system for collecting and organizing data corresponding to an event
GB2466425B (en) * 2008-10-09 2014-01-08 Sonicwall Inc Computer networks
US8553582B1 (en) * 2009-01-08 2013-10-08 Marvell Israel (M.I.S.L) Ltd. Traffic spraying in a chassis-based network switch
US8828170B2 (en) 2010-03-04 2014-09-09 Pactiv LLC Apparatus and method for manufacturing reinforced containers
US9350616B1 (en) * 2010-05-11 2016-05-24 Trend Micro Inc. Bandwidth prediction using a past available bandwidth value and a slope calculated from past available bandwidth values
US8789176B1 (en) * 2011-03-07 2014-07-22 Amazon Technologies, Inc. Detecting scans using a bloom counter
US9172659B1 (en) 2011-07-12 2015-10-27 Marvell Israel (M.I.S.L.) Ltd. Network traffic routing in a modular switching device
GB2499237A (en) * 2012-02-10 2013-08-14 Ibm Managing a network connection for use by a plurality of application program processes
EP2696322B1 (en) * 2012-08-10 2018-12-05 Zhilabs S.L. Action triggering based on Subscriber Profile
US20150016269A1 (en) * 2013-07-09 2015-01-15 Tektronix, Inc. Frame analysis - a new way to analyze serial and other packetized data
CN105474608A (zh) * 2013-08-08 2016-04-06 株式会社理光 程序、通信质量估计方法、信息处理装置、通信质量估计系统以及存储介质
US10148669B2 (en) * 2014-05-07 2018-12-04 Dell Products, L.P. Out-of-band encryption key management system
US9608879B2 (en) 2014-12-02 2017-03-28 At&T Intellectual Property I, L.P. Methods and apparatus to collect call packets in a communications network
US10693724B1 (en) * 2015-02-25 2020-06-23 Amazon Technologies, Inc. Context-sensitive techniques for optimizing network connectivity
US10440035B2 (en) * 2015-12-01 2019-10-08 Cisco Technology, Inc. Identifying malicious communication channels in network traffic by generating data based on adaptive sampling
US10904150B1 (en) 2016-02-02 2021-01-26 Marvell Israel (M.I.S.L) Ltd. Distributed dynamic load balancing in network systems
US10218986B2 (en) * 2016-09-26 2019-02-26 Google Llc Frame accurate splicing
CN107087006B (zh) * 2017-05-24 2019-08-16 全讯汇聚网络科技（北京）有限公司 一种协议分流方法、系统及服务器
WO2019211650A1 (en) * 2018-05-02 2019-11-07 Pratik Sharma Cloud data segregator
JP7294442B2 (ja) * 2019-11-01 2023-06-20 日本電気株式会社 データ集計装置、データ集計方法、及びプログラム
WO2022059328A1 (ja) 2020-09-17 2022-03-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 検知システム、検知方法、および、プログラム
US12363015B2 (en) * 2021-04-23 2025-07-15 Clockwork Systems, Inc. Clock-synchronized edge-based network functions
US20250203369A1 (en) * 2022-02-22 2025-06-19 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for determining security attacks in software-defined networks
US12592946B1 (en) * 2022-12-16 2026-03-31 Amazon Technologies, Inc. Dynamic detection of abnormal network activity

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2830270B2 (ja) 1990-01-17 1998-12-02 日本電気株式会社 Ｌａｎモニタ回路
EP0477448B1 (en) 1990-09-28 1995-07-12 Hewlett-Packard Company Network monitoring device and system
JP3315404B2 (ja) 1990-09-28 2002-08-19 ヒューレット・パッカード・カンパニー ネットワークのトポロジ的特徴を探知する方法
GB2261799B (en) 1991-11-23 1995-04-19 Dowty Communications Ltd Packet transmission system
JPH05227218A (ja) 1992-02-10 1993-09-03 Nec Corp パケット交換網の伝播遅延測定システム
JP3212040B2 (ja) 1992-03-23 2001-09-25 株式会社荏原製作所 遠心送風機
US5483468A (en) 1992-10-23 1996-01-09 International Business Machines Corporation System and method for concurrent recording and displaying of system performance data
JPH07321783A (ja) 1994-05-25 1995-12-08 Fuji Xerox Co Ltd ネットワーク監視装置
US5615323A (en) * 1994-11-04 1997-03-25 Concord Communications, Inc. Displaying resource performance and utilization information
US5570346A (en) 1994-12-08 1996-10-29 Lucent Technologies Inc. Packet network transit delay measurement system
US6044400A (en) 1995-03-25 2000-03-28 Lucent Technologies Inc. Switch monitoring system having a data collection device using filters in parallel orientation and filter counter for counting combination of filtered events
US5521907A (en) 1995-04-25 1996-05-28 Visual Networks, Inc. Method and apparatus for non-intrusive measurement of round trip delay in communications networks
GB2300789B (en) 1995-05-12 2000-04-05 Gen Datacomm Adv Res Data network
US5790605A (en) 1995-07-28 1998-08-04 Motorola, Inc. Method for determining voting windows in a diversity repeater
JPH0946391A (ja) 1995-08-01 1997-02-14 Nippon Telegr & Teleph Corp <Ntt> データパケットへのタイムスタンプ付加方法
US5781449A (en) 1995-08-10 1998-07-14 Advanced System Technologies, Inc. Response time measurement apparatus and method
US5878420A (en) 1995-08-31 1999-03-02 Compuware Corporation Network monitoring and management system
US5812528A (en) 1995-11-17 1998-09-22 Telecommunications Techniques Corporation Measuring round trip time in ATM network virtual connections
US5761191A (en) 1995-11-28 1998-06-02 Telecommunications Techniques Corporation Statistics collection for ATM networks
US5905736A (en) 1996-04-22 1999-05-18 At&T Corp Method for the billing of transactions over the internet
US5787253A (en) * 1996-05-28 1998-07-28 The Ag Group Apparatus and method of analyzing internet activity
US5734962A (en) 1996-07-17 1998-03-31 General Electric Company Satellite communications system utilizing parallel concatenated coding
US5850386A (en) * 1996-11-01 1998-12-15 Wandel & Goltermann Technologies, Inc. Protocol analyzer for monitoring digital transmission networks
US5991881A (en) * 1996-11-08 1999-11-23 Harris Corporation Network surveillance system
US5867483A (en) 1996-11-12 1999-02-02 Visual Networks, Inc. Method and apparatus for measurement of peak throughput in packetized data networks
US5796942A (en) * 1996-11-21 1998-08-18 Computer Associates International, Inc. Method and apparatus for automated network-wide surveillance and security breach intervention
US6085243A (en) * 1996-12-13 2000-07-04 3Com Corporation Distributed remote management (dRMON) for networks
US6006264A (en) 1997-08-01 1999-12-21 Arrowpoint Communications, Inc. Method and system for directing a flow between a client and a server
US6073089A (en) * 1997-10-22 2000-06-06 Baker; Michelle Systems and methods for adaptive profiling, fault detection, and alert generation in a changing environment which is measurable by at least two different measures of state
ATE314777T1 (de) * 1998-07-21 2006-01-15 Computer Ass Think Inc System zur analyse der informationssicherheit
US6954775B1 (en) * 1999-01-15 2005-10-11 Cisco Technology, Inc. Parallel intrusion detection sensors with load balancing for high speed networks
DE60045552D1 (de) 1999-06-30 2011-03-03 Apptitude Inc Verfahren und gerät um den netzwerkverkehr zu überwachen
US6775657B1 (en) * 1999-12-22 2004-08-10 Cisco Technology, Inc. Multilayered intrusion detection system and method
US7429319B2 (en) 2005-07-26 2008-09-30 Rufus Davis Sewage slurry separation system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2580304R1 (es) * 2015-02-19 2016-09-27 Endesa Generación, S.A. Sistema de inspección y diagnóstico de infraestructuras y procedimiento asociado

Also Published As

Publication number Publication date
WO2001088731A1 (en) 2001-11-22
DK1297440T3 (da) 2008-12-15
US8275875B2 (en) 2012-09-25
EP2018018B1 (en) 2011-02-09
EP1297440A4 (en) 2006-10-18
AU2001263127A1 (en) 2001-11-26
SG143052A1 (en) 2008-06-27
US20040015582A1 (en) 2004-01-22
EP2018018A3 (en) 2009-04-08
EP1297440A1 (en) 2003-04-02
ATE406615T1 (de) 2008-09-15
DE60135550D1 (de) 2008-10-09
EP1297440B1 (en) 2008-08-27
EP2018018A2 (en) 2009-01-21
JP2003533925A (ja) 2003-11-11
DE60144035D1 (de) 2011-03-24
ATE498270T1 (de) 2011-02-15

Similar Documents

Publication Publication Date Title
EP1297440B1 (en) Security camera for a network
KR100814546B1 (ko) 통신 데이터를 수집하여 분석하는 장치 및 방법
US20110128974A1 (en) System, apparatus, and methods for inserting information into captured data packets
Munz et al. Real-time analysis of flow data for network attack detection
Handelman et al. RTFM: New attributes for traffic flow measurement
US7266088B1 (en) Method of monitoring and formatting computer network data
TW201038009A (en) Real-time traffic measurement system of IP network centralized network management and distributed nodes
KR20120010535A (ko) 패킷 분석 장치 및 방법
Pezaros Network traffic measurement for the next generation Internet
Nguyen et al. Network anomaly detection: Flow-based or packet-based approach?
Becker et al. Large scale outage visibility on the control plane
Krejčí Network Traffic Collection with IPFIX Protocol
CN121750307A (zh) 云原生加密流量的威胁检测方法、装置、设备和存储介质
Brekne et al. State of the Art in Performance Monitoring and
Mc Grath et al. Monitoring & Forensic Analysis forWireless Networks
Gebregiorgis URI's NetFlow Traffic Logs' Behavioral Analysis and Monitoring Visualization Tool
Wang Countering distributed denial of service attacks
Danyliw The State of Standardization Efforts to support Data Exchange in the Security Domain