MXPA98000399A - Sistema y metodo para proporcionar control de acceso a nivel de par en una red - Google Patents

Sistema y metodo para proporcionar control de acceso a nivel de par en una red

Info

Publication number
MXPA98000399A
MXPA98000399A MXPA/A/1998/000399A MX9800399A MXPA98000399A MX PA98000399 A MXPA98000399 A MX PA98000399A MX 9800399 A MX9800399 A MX 9800399A MX PA98000399 A MXPA98000399 A MX PA98000399A
Authority
MX
Mexico
Prior art keywords
rule
packet
local
pair
base
Prior art date
Application number
MXPA/A/1998/000399A
Other languages
English (en)
Other versions
MX9800399A (es
Inventor
N Zenchelsky Daniel
P Dutta Partha
B London Thomas
F Vrsalovic Dalibor
A Siil Karl
Original Assignee
At & T Corp
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
Priority claimed from US08/785,501 external-priority patent/US6233686B1/en
Application filed by At & T Corp filed Critical At & T Corp
Publication of MX9800399A publication Critical patent/MX9800399A/es
Publication of MXPA98000399A publication Critical patent/MXPA98000399A/es

Links

Abstract

La presente invención se refiere a un sistema y método para proporcionar control de acceso a nivel de par en redes que transportan paquetes de información, cada paquete tiene una 5-tupla que tiene direcciones de fuente y destino, un puerto de fuente y destino y un identificador de protocolo. La base de reglas local de un par se cargan dinámicamente en un filtro cuando el par se autentica y expulsa cuando el par pierde su autenticación. La base de reglas local se busca eficientemente a través del uso de tablas hash o de clave de elección arbitraria, en donde una dirección de red par con clave de elección arbitraria, sirve como puntero a las reglas locales del par. Cada regla comprende una 5-tupla y una acción. La acción de una regla se lleva a cabo en un paquete cuando la 5-tupla de la regla corresponde a la 5-tupla del paquete.

Description

SISTEMA Y MÉTODO PARA PROPORCIONAR CONTROL DE ACCESO A NIVEL DE PAR EN UNA RED ratrr > e la Invención Esta invención se relaciona a seguridad en sistemas de información, en particular a proporcionar control de acceso entre uno y otro conjuntos de sistemas de información automatizados. Antecedentes dß la Invención Métodos conocidos para implementar control de acceso para una computadora específica en una red, son problemáticos e inflexibles, debido a que las reglas de acceso deben codificarse y proporcionarse a mano por un administrador del sistema. Esto es impráctico para redes cuyos miembros cambian frecuentemente, o cuyas necesidades de seguridad de los miembros cambian frecuentemente . La seguridad del sistema de información efectiva evita descripción, modificación o ejecución no autorizada, de datos y procesos de sistemas de información automatizada (AIS = Automated Information System) . Como se emplea aquí, el término AIS se refiere a una computadora, red de computadoras, inter-red de computadoras, o cualquier eub-conjunto de las mismas. El término "datos" se refiere a cualquier información residente en un AIS, incluyendo archivos y programas. El término "procesos" se refiere a programas en cualquier etapa de ejecución en un AIS. Un "huésped" es una computadora con una dirección de red asignada, por ejemplo una dirección de protocolo de Internet REF: 26413 (IP = Internet Protocol) . Un "usuario" es una computadora que no tiene una dirección de red fija asignada. Para obtener conectividad a Internet, por ejemplo, un usuario debe obtener comúnmente una dirección de IP temporal desde un huésped con un conjunto de estas direcciones. Esta dirección de IP temporal se retiene por el usuario solo por la duración de una sola sesión de conectividad con Internet . La información circula en ciertas redes en paquetes . Un "paquete" es un número cuántico de información que tiene un cabezal que contiene una fuente y una dirección de destino. Un ejemplo de un paquete es un paquete IP. Paquetes tales como paquetes IP tienen un identificador de protocolo de red ("protocolo") como parte del cabezal del paquete. El protocolo identifica el número de versión de protocolo empleado para dirigir el paquete. Un ejemplo de un identificador de protocolo de red es el campo de protocolo IP en un cabezal de paquete IP. Paquetes en una red se dirigen a y de puertos . Un "puerto" es una dirección lógica dentro de una computadora, a través de la cual un proceso que se ejecuta en la computadora comunica con otros procesos de ejecución. Estos otros procesos pueden residir en la misma computadora o en otras computadoras en red. La seguridad del sistema de información se implementa por medio de una política de seguridad, que comprende reglas dirigidas a regular el flujo de información en un AIS. Las reglas de una política de seguridad se incorporan en un "base de reglas", un conjunto de reglas que especifica si un paquete habrá de pasarse al destinatario pretendido o habrá de retirarse con base en el identificador del paquete. Un identificador de paquete son datos que se transportan generalmente en el cabezal de paquete que sirven para identificar el paquete. Un ejemplo de un identificador de paquete es un número de circuito, que ocurre en el cabezal de paquetes que circulan en redes conmutadas de paquetes orientadas por conexión (es decir conmutadas por circuito) . Otro ejemplo de identificador de paquete es una 5-tupla de paquete, que es la fuente de paquete y dirección de destino, puerto de fuente y destino y protocolo. Paquetes con flujo de 5-tupias fluyen en redes conmutadas en paquetes sin conexión. Una base de reglas puede ser global o local . Una base de reglas global es un conjunto uniforme de reglas ("reglas globales") que aplican a un grupo de usuarios huéspedes o a ambos. Una base de reglas local es un conjunto de reglas ("reglas locales") que aplican a un usuario simple con una dirección de red temporal o un huésped. Un usuario simple con una dirección de red temporal o un huésped que tiene su propia base de reglas se denomina un "par" . Otro medio para implementar política de seguridad es restringir acceso a una red a un conjunto predeterminado de usuarios y huéspedes. Cuando un usuario o huésped solicita acceso, su identidad debe establecerse y verificarse antes de que se otorgue acceso. Este proceso implica dos etapas: identificación y autenticación. La Figura 1 muestra un método de identificación y autenticación en la forma de un diagrama de flujo, con cada etapa designada por un número de referencia. Una primer etapa requiere una fuente de información que se identifique por nombre, al suministrar una sarta de datos denominadas una id de usuario 10. Para evitar que un impostor obtenga los privilegios asociados con una id de usuario determinado, el usuario tras la id de usuario se verifica al requerir que proporcione una clave 11 que normalmente se mantiene confidencial . Esta verificación se denomina "autenticación" . El AIS verifica la combinación de id fuente y clave contra una lista de usuarios válidos, 12. Cuando el AIS reconoce la id de usuario válida y clave correspondiente, se dice que un usuario o huésped se ha identificado y autenticado 14. De otra forma, la solicitud para acceso se niega 13. A continuación, una fuente que ha sido identificada y autenticada, se dirá que ha sido "autenticada" para propósitos de brevedad. Una base de reglas para política de seguridad se implementa en una red utilizando un dispositivo denominado un filtro que tiene equipo físico y software. La base de reglas se carga en el filtro, que recibe paquetes en ruta (entre su fuente y destino) y verifica el identificador de cada paquete contra el identificador contenido en cada regla de la base de reglas para una correspondencia, es decir si el paquete corresponde a la regla. Un paquete corresponde a una regla, si la regla aplica al paquete. Por lo tanto, una regla se pretende que aplique a paquetes con un número de circuito de 3254, por ejemplo, "corresponde" a todos los paquetes con un identificador de paquete que indica el número de circuito 3254. Si el identificador de paquete de red corresponde a un identificador de regla, el filtro lleva a cabo la acción PASA (PASS) o RETIRA (DROP) prescrita por la regla en el paquete. Si la acción PASA (PASS) se lleva a cabo, el paquete se deja que pase a través del filtro. Si una acción RETIRA (DROP) se lleva a cabo, el paquete se elimina. A menudo un filtro se combina con otro equipo físico y software que ayudan a administrar el flujo de información a través del filtro. La combinación de equipo físico y software que lleva a cabo y soporta el filtrado de paquete, se denomina una pared de fuego (firewall) . Una pared de fuego a menudo se coloca entre una primer red que "posee" la pared de fuego y una segunda red. El propósito de la pared de fuego consiste en regular el flujo de información dentro y fuera de la primer red desde la segunda red, al implementar la base de reglas que pertenecen a la primer red para toda esta información. Una aplicación típica de una pared de fuego se ilustra en la Figura 2. Una red corporativa 20 puede ser el proporcionar acceso a los huéspedes de Internet 21 a sus subscriptores, pero puede desear limitar el acceso que los huéspedes de Internet 21 tienen a la red corporativa 20, que puede contener secretos comerciales e información de propiedad. La red corporativa 20 desarrollará una política de seguridad implementada por una pared de fuego 22 colocada en la interfase entre la red corporativa 20 y los huéspedes de Internet 21. La pared de fuego 22 comprende un filtro 23 que PASARA (PASS) o RETIRARA (DROP) paquetes de los huéspedes de Internet 21 a los subscriptores de red corporativa 20 y viceversa con base en las direcciones de fuente y destino de los paquetes. Se dice que la pared de fuego pertenece a la red corporativa, y pone en vigor reglas que "protegen" huéspedes dentro de la red corporativa que tienen direcciones IP. Estos huéspedes se dice que están "tras" la pared de fuego o red corporativa. Un ejemplo de una regla base para la red corporativa 20 que tiene los huéspedes A 24, B 25 y C 26 conectados a través de una pared de fuego 22 a Internet que tiene huéspedes G 27, H 28 e I 29 es como sigue: FUENTE DESTINO VERSIÓN ACCIÓN Dirección, Puerto, Dirección, Puerto A, 21 G, 32 4 PASA A, 22 H, 19 3 RETIRA G, 11 A, 64 4 RETIRA C, 9 I, 23 4 PASA Cada base de reglas debe tener una acción predefinida para transacciones que no se especifican explícitamente en la base de reglas, que usualmente es la acción de RETIRA (DROP) . De esta manera, paquetes del sistema A, 21 al sistema G, 33 se retirarán, debido a que la base de reglas anterior no incluye expresamente una regla para dicha transferencia. Una arquitectura típica para proporcionar acceso a usuarios de Internet se ilustra en la Figura 3. Los usuarios 31 y 32 no tienen direcciones de IP fijas. En vez de eso, a un usuario se le asignan direcciones IP temporales por un proveedor de servicios de Internet (ISP = Internet Service Provider) , punto de presencia (POP = Point of Presence) 33, desde un conjunto de estas direcciones que se mantienen por el POP 33 para este propósito. Un POP comprende al menos un huésped (no mostrado) . Cuando un usuario 31 termina su sesión de acceso a Internet 35, la dirección IP se regresa al POP 33. De esta manera, sobre sesiones de acceso sucesivas, es probable que un usuario 31 tenga varias direcciones de IP diferentes. Filtros conocidos no son bien adecuados para proporcionar control de acceso apropiado para redes tales como POP. Esto es debido a que un filtro conocido solo es capaz de cargar y almacenar reglas a través de la intervención de un administrador de sistema, un proceso lento y problemático. Sin duda, el administrador de sistema generalmente debe codificar a mano reglas en un formato específico para la plataforma de filtro. Con filtros conocidos, es impráctico implementar las reglas de acceso de un usuario específico (conocidas como las "reglas locales" del usuario) quien accesa y deja la red con direcciones de red cambiantes . Este problema se ilustra en las Figuras 5a y 5b. La Figura 5a muestra una primer sesión en donde un primer usuario 51 ha solicitado acceso a Internet y se ha autenticado por un POP y se le ha asignado la dirección IP B del conjunto de direcciones POP IP 52. Igualmente, un segundo usuario 53 se ha autenticado y se le ha asignado una dirección IP E del conjunto 52. Una base de reglas 53 se carga en un filtro para regular el flujo de información entre los usuarios 51 y 53 y los huéspedes P, U, V y W en Internet . La base de reglas ilustrada en las Figuras 5a y 5b solo muestra las direcciones fuente y destino por cada regla, y omite los puertos y protocolo fuente y destino por simplicidad. Ambos usuarios dejan de accesar Internet y luego posteriormente solicitan acceso de nuevo y se autentican por una segunda sesión ilustrada en la Figura 5b. Esta vez, al primer usuario 51 se le asigna la dirección IP E del conjunto 52, y al segundo usuario se le asigna la dirección IP A. Con las direcciones de red recientemente asignadas, la base de reglas en el filtro ahora está desactualizada, no conteniendo reglas para el segundo usuario, y las reglas erróneas para el primer usuario, que se le ha asignado la dirección IP asignada al segundo usuario durante la primer sesión. Incluso si a ambos usuarios fortuitamente se les reasignará las mismas direcciones IP para la segunda sesión, si cualesquiera necesidades de la seguridad del usuario han cambiado entre sesiones, una nueva base de reglas tendría que cargarse al filtro. Como se discutió anteriormente, el cargar reglas en filtros conocidos es tedioso. Cargar y retirar estas reglas con la frecuencia que los usuarios accesan y dejan un POP es impráctico para filtros conocidos. La inflexibilidad de filtros conocidos a menudo requiere la implementación de bases de reglas que son demasiado amplias para una aplicación determinada. Sin la posibilidad de fáciles actualizaciones, es más simple el dirigir reglas globales que aplicar a todos los AIS tras un filtro, en vez de cargar reglas que aplican a huéspedes específicos. En dicho caso, todos los AIS tras el filtro deben adaptarse a los requerimientos de seguridad más estrictos de cualquier AIS, resultando en un filtrado excesivamente restrictivo. Las desventajas de filtros conocidos se ilustran por algunas de las arquitecturas actualmente empleadas para proporcionar seguridad en sistemas de información para un POP. La arquitectura ilustrada en la Figura 3 proporciona un nivel mínimo de seguridad a través de un sistema de autenticación 34 que limita acceso a una lista predeterminada de usuarios autenticados. Pero la lista de usuarios en general debe proporcionarse a mano por el administrador de sistema, y de esta manera no puede cambiarse fácilmente. Además, una vez que se otorga acceso, el acceso es ilimitado. La información puede circular a y de los usuarios 31 y 32 desde la Internet 35 sin regulación, no proporcionando seguridad más allá del proceso de autenticación inicial. Esto expone a los usuarios 31 y 32 al riesgo de ataques de intrusos informáticos de usuarios y huéspedes a Internet, posiblemente resultando en el robo o manipulación no autorizada de datos de usuario. La arquitectura ilustrada en la Figura 4, muestra otra solución conocida a proporcionar seguridad de sistemas de información en un POP. El filtro conocido 46 implementa una política de seguridad para paquetes que circulan entre Internet 45 y los huéspedes 41 y 42. Sin embargo, la base de reglas en el filtro 46 aun debe formularse y cargarse por el administrador de sistema. Además, las direcciones de red de los usuarios 31 y 32 probablemente cambiarán en una base de sesión por sesión. Esto significa que solo es práctico el cargar reglas generales "globales" al filtro que son válidas para todos los usuarios. De esta manera, por ejemplo, si el usuario A no desea recibir paquetes de un huésped particular en Internet, la base de reglas de filtro debe retirar todos estos paquetes, de esta manera cortando o impidiendo que el usuario B reciba paquetes de ese huésped de Internet por igual. De esta manera, la base de reglas global requerida por las capacidades limitadas de sistemas de filtrado conocidos casi es siempre demasiado amplia. Otra desventaja es que es difícil cambiar la base de reglas de filtro para ajustar a necesidades de seguridad cambiantes ya sea del usuario 41 o 42. Otra arquitectura que proporciona seguridad para cada par, se ilustra en la Figura 6. Aquí, los filtros 66 y 67 se colocan entre los usuarios 61 y 62 respectivamente y el POP. Requerir que cada usuario tenga su propio filtro es una solución costosa que es impráctica de implementar. Lo que se requiere es un sistema y método de filtrado que implementan en forma precisa y eficiente bases de reglas locales en una red cuya configuración y necesidades de seguridad están cambiando constantemente. Esta invención proporcionará seguridad a nivel de par, flexibilidad y en forma económica con poca intervención requerida desde un administrador de sistema. Compendio de la Invención La presente invención comprende un filtro que almacena, implementa y mantiene eficientemente reglas de acceso específicas a una computadora individual en una red con configuraciones rápidamente cambiantes y necesidades de seguridad. Esto permite ventajosamente que una computadora individual (un par) implemente su política de seguridad en un filtro compartido por muchas de esas computadoras en una red. Cuando una base de reglas local no es más válida debido a que el par ya no está más autenticado al filtro de acuerdo con la presente invención, la base de reglas local del par se "expulsa", es decir una operación lógica se lleva a cabo en el filtro con lo que la base de reglas local se elimina del filtro.
Esta operación lógica de datos almacenados en una computadora, es bien conocida en la técnica. Esto regula efectivamente el flujo de información en una base de sesión-por-sesión, lo cual es especialmente ventajoso en AIS cuando usuarios individuales y huéspedes tienen diferentes necesidades de seguridad que cambian de tiempo en tiempo. Por ejemplo, la presente invención es útil para implementar un sistema de control de padres, en donde un padre es capaz de regular el acceso a ciertos tipos de material licencioso en Internet para cuentas de acceso de Internet domésticas . La presente invención permite que un solo dispositivo regule en forma flexible y eficiente el flujo de información de acuerdo con políticas de seguridad que se ajustan específicamente a la medida al usuario individual o huésped. Ventajosamente, ninguna intervención por parte del administrador del sistema es ordinariamente requerida en el funcionamiento usual de la presente invención. A diferencia de filtros conocidos, la presente invención es capaz de permitir a usuarios con direcciones de red temporales tan fácilmente como huéspedes con direcciones de red fijas. De acuerdo con la presente invención, cada par individual se autentica al solicitar acceso a la red. La base de reglas local del par luego se carga en el filtro de la presente invención, ya sea desde el propio par, o desde otro usuario, huésped o par. Cuando el par ya no está autenticado más al POP (por ejemplo el par pierde conectividad o se sale de registro del POP) , la base de reglas local del par se expulsa (elimina) del filtro. Breve Descripción de los Dibulos La Figura 1 muestra el proceso de identificación y autenticación. La Figura 2 muestra una pared de fuego interpuesta entre una red corporativa y la Internet. La Figura 3 muestra a usuarios conectados a Internet a través de un punto de presencia (POP) que tiene un sistema de autenticación. La Figura 4 muestra un POP con un sistema de autenticación y un filtro. La Figura 5a muestra una primer sesión de acceso de Internet para dos usuarios a través de un POP que tiene un filtro. La Figura 5b muestra una segunda sesión de acceso de Internet para dos usuarios a través de un POP que tiene un filtro. La Figura 6 muestra un método conocido para proporcionar control de acceso a Internet a nivel de usuario. La Figura 7a muestra una arquitectura de base de reglas de acuerdo con una modalidad de la presente invención. La Figura 7b muestra una implementación de la arquitectura de base de reglas ilustrada en la Figura 7a.
La Figura 8a muestra un POP con un filtro y un sistema de autenticación que proporciona acceso a Internet a los tres pares . La Figura 8b muestra una ilustración simplificada de las bases de reglas que pertenecen a los pares ilustrados en la Figura 8a. La Figura 8c muestra una función hash o de clave de elección arbitraria aplicada a las direcciones de red de los tres pares ilustrados en la Figura 8a, y las bases de reglas de entrada local y salida local . La Figura 8d muestra una representación detallada de la casilla "verificar base de reglas local" ilustrada en la Figura 7b. La Figura 9 muestra una implementación de la presente invención. Descripción Detallada De acuerdo con la presente invención, la Figura 7a muestra una modalidad de una arquitectura de reglas, que incorpora la funcionalidad de filtros conocidos al incluir una base de pre-reglas global 701, una base de reglas local 702 y una base de post-reglas global 703. La base de pre-reglas global 701 usualmente comprende reglas generales que aplican a todos los huéspedes tras la pared de fuego, y se aplican más eficientemente antes de cualesquiera reglas locales. Un ejemplo de una pre-regla global es que no se permiten solicitudes telnet (registro remoto) más allá de la >pared de fuego. La base de reglas local 702 comprende el conjunto de bases de reglas de par cargadas en el filtro para pares autenticados . Estas reglas pertenecen a huéspedes específicos . Un ejemplo de una regla local es que el huésped A puede no recibir correo electrónico (e-mail) más allá de la pared de fuego . La base de post-reglas global 703 comprende reglas generales que se aplican más eficientemente después de la base de pre-reglas global y la base de reglas local se busca. Una regla aplicada en la base de post-reglas global, no requiere tener el mismo efecto que si se aplicara en la base de pre-reglas global. Considere el ejemplo anterior que impide la recepción de ciertas solicitudes telnet. Si esta regla se coloca en la base de postreglas global, la base de reglas local se busca primero, y puede contener una regla que permite una solicitud telnet a través de un par particular. Si esta regla se encuentra en la base de reglas local, la base de post-reglas global no se busca subsecuentemente, y la solicitud telnet se deja que pase. Considere el efecto diferente de la misma regla cuando ocurre en la base de pre-reglas global, que va a bloquear todas las solicitudes telnet para todos los huéspedes tras la pared de fuego. La importancia del orden de aplicar reglas es evidente para una consideración más detallada del método de la presente invención. La Figura 7b ilustra un diagrama de flujo de procesamiento de filtrado de paquetes de acuerdo con la presente invención. Como se ilustra ahí, un paquete que entra al filtro primero se verifica contra una base de pre-reglas global 711, que contiene reglas para todos los huéspedes y usuarios que tienen direcciones de red tras la*pared de fuego!1 Si una regla correspondiente se encuentra y la acción predeterminada es RETIRAR (DROP), el paquete se retira a 712. Si en la regla correspondiente se encuentra y la acción es PASAR (PASS), el paquete se pasa 720. Si no se encuentra regla correspondiente, entonces la base de reglas local se verifica 713. La base de reglas local 702 se ajusta para todas las bases de reglas por usuario que se cargan dinámicamente ante autenticación y expulsan ante pérdida de autenticación de acuerdo con la presente invención. Si una regla correspondiente se encuentra en la base de regla es local y la acción es RETIRAR (DROP) , el paquete se retira 714. Si una regla correspondiente se encuentra y la acción es PASAR (PASS), el paquete se pasa 721. Si no se encuentra regla correspondiente, entonces se verifica la base de post-reglas global 715. Si una regla correspondiente se encuentra en la base de post-reglas global y la acción es RETIRA (DROP) , el paquete se retira a 716. Si la acción es PASA (PASS), el paquete se pasa a 722. Si no se encontró regla correspondiente en cualquiera de las bases de reglas, entonces el paquete se verifica contra la regla pre-definida 717, cuya acción generalmente es RETIRA (DROP) el paquete. Si el paquete corresponde a una regla predefinida, entonces la acción pre-definida se lleva a cabo 723. Si el paquete no corresponde a la regla pre-definida, entonces ocurre una condición de error 724. Esta arquitectura de base de reglas retiene ventajosamente la funcionalidad de filtros conocidos. Por ejemplo, si hay reglas en la pre- o post-base de reglas global solamente, el filtro se comporta igual que los filtros conocidos. Si solo hay reglas en la base de reglas local, el filtro tiene todas las características nuevas e innovativas de la presente invención, sin tener reglas globales. Es ventajoso implementar la presente invención con un sistema para buscar eficientemente la base de reglas local para reglas correspondientes para un paquete determinado. Un sistema que proporciona dichas eficiencias utiliza una función hash para generar un índice de las reglas. Una función hash mapea una sarta de caracteres a un entero. Como se conoce en la especialidad, una sarta de caracteres se representa como números binarios dentro de una computadora. Un ejemplo de una función hash sería tomar el tercero, cuarto y quinto octetos o palabras (bytes) de una sarta de caracteres conforme se almacena en una computadora como el primero segundo y tercer dígitos de un entero que se asocia con la sarta. Una sarta en la que una función hash se ha llevado a cabo se dice que está "calculada por elección arbitraria" (hashed) y el entero resultante se refiere como "la clave por elección arbitraria" (hash) de la sarta. Esto se lleva a cabo al dividir lógicamente las reglas lógicas en reglas de acceso local o reglas de salida local. Una regla de acceso local es cualquier regla que aplica a un paquete cuya dirección de destino corresponde a una dirección de red tras la pared de fuego. Por ejemplo, supongamos un huésped con una dirección de red A está tras la pared de fuego, y los huéspedes B, C y D están fuera de la pared de fuego. Lo siguiente son ejemplo de reglas de acceso local para el huésped A, siguiendo el formato DIRECCIÓN FUENTE (SOURCE ADDRESS) , PUERTO DE FUENTE (SOURCE PORT)--> DIRECCIÓN DE DESTINO (DESTINATION ADDRESS), PUERTO DE DESTINO (DESTINATION PORT) : Protocolo; ACCIÓN: B, 31 --> A, 33:4: RETIRA (DROP) C, 64 --> A, 45:4: PASA (PASS) D, 11 --> A, 17:4: PASA (PASS) Una regla de salida local es cualquier regla que aplica a un paquete cuya cuenta corresponde a una dirección de red tras la pared de fuego. Las reglas de salida local para el ejemplo anterior son: A, 44 --> B, 70:4: PASA (PASS) A, 13 --> C, 64:4: RETIRA (DROP) A, 12 --> D, 17:4: RETIRA (DROP) De acuerdo con la presente invención, una función hash h se lleva a cabo en la dirección de red del propietario en una base de reglas local . Una función hash asocia un entero con la sarta. Para el ejemplo anterior en donde un huésped con la dirección de red A ("huésped A") tiene una base de reglas local, una función hash se llevaría a cabo en A: h (A) =N, en donde N es un entero Un ejemplo de esta función hash es tomar el último dígito decimal en cada octeto de una dirección IP y componer un entero para el número hash. De esta manera, por ejemplo la dirección IP 123.4.46.135 tendrá un valor hash de 3465. Después de que la función hash se lleva a cabo, se genera una tabla hash de entrada local y salida local . Estas tablas esencialmente son buscables por índices en los números hash derivados de las direcciones de red de pares, en donde cada dirección de red de par con clave calculada por elección aleatoria, señala a esas reglas de entrada local y salida local del par. De esta manera, si A es la dirección de red del par A y si h(A) = 32, entonces 32 señalará a las reglas de entrada local y salida local de A de par en la base de reglas local . Las ventajas de este sistema de indexado de acuerdo con la presente invención pueden demostrarse con el auxilio de las Figuras 8a, 8b, 8c y 8d. La Figura 8a muestra una arquitectura ejemplar en donde los pares A 801, B 802 y C 803 están tras de una pared de fuego 804 que tiene un filtro 805 conectado a una red 806 que tiene los huéspedes G 807, H 808 e I 809. Estas letras representan direcciones de red. La Figura 8b muestra que la base de reglas local está asociada con cada huésped. Por simplicidad, cada regla en las bases de reglas solo se ilustra como una dirección de destino y fuente de red; los puertos de fuente y destino y los números de protocolo no se ilustran. El asterisco representa un comodín indicando cualquier huésped. Por ejemplo, esta característica puede implementarse ventajosamente de acuerdo con la presente invención, al incluir comodines en uno o más de los cuatro octetos que constituyen una dirección IP. Las siguientes especificaciones de dirección IP son todas válidas para utilizar en bases de reglas de acuerdo con la presente invención: 123.*.233.2 34.*.*.155 *.*.*.32 * * _ * * La característica de comodín también puede emplearse de acuerdo con la presente invención en una forma similar en cualquier otro componente de la 5-tupia, es decir los puertos de destino y fuente y el protocolo. La Figura 8c muestra la tabla hash de acceso par 821 y la tabla hash de salida par 822 derivadas de las redes locales ilustradas en la Figura 8b y la función hash h que se lleva a cabo en las direcciones de red A, B y C 823. Cuando se recibe un paquete por el filtro 805, el filtro lleva a cabo la misma función hash h en la dirección, destino y fuente del paquete 824. La Figura 8d muestra el método por el cual las tablas hash se buscan de acuerdo con la presente invención. La Figura 8d representa una vista detallada de la casilla "verifica base de reglas local" 713 en la Figura 7b. De acuerdo con la presente invención, si no hay regla correspondiente encontrada en la base de pre-reglas global 711 (Figura 7b) , entonces la tabla hash de acceso local se busca eficientemente para una regla que corresponde al paquete 841. Si una regla correspondiente se encuentra y la acción es RETIRAR (DROP) el paquete se retira 842. Si la acción es PASAR (PASS) o no hay regla correspondiente, la tabla hash de salida de par se verifica 843. Si una regla correspondiente en la tabla de salida hash se encuentra y la acción es RETIRAR (DROP) el paquete se retira 844. Si la acción es PASAR (PASS) o no hay regla correspondiente, y si al menos una de las tablas hash contiene una regla correspondiente, el paquete se pasa 845. Si no hay reglas correspondiente en cualquier tabla hash 846, entonces la base de post-reglas 715 se verifica como se ilustra en la Figura 7b. Cuando si no es por tablas hash de acceso de par o salida de par, las reglas tendrían que buscarse bastante menos eficiententemente al buscar toda la base de reglas para identificadores de reglas (por ejemplo 5-tupias) que corresponden al identificador de paquete (por ejemplo 5-tupia) . La parte de la regla que identifica el paquete al cual aplica la regla (el identificador de regla) también se denomina la "clave" de regla. Utilizar las tablas hash elimina la necesidad por buscar las claves de todas las reglas, señalando por el contrario al subconjunto relevante de reglas posiblemente aplicables a través de una búsqueda más rápida. De esta manera, se reduce substancial y ventajosamente el tiempo de computación y alcance requerido para llevar a cabo la búsqueda, disminuyendo el retardo en tiempo de tránsito de paquete provocado por la interposición de un filtro entre la fuente y destino de paquete. Como se ilustra en la Figura 9, primero se autentica un par 91 de acuerdo con la presente invención. Al autenticar, la base de reglas local del par se carga en el filtro 92. Una función hash se lleva a cabo en la dirección de red del par 93, y las tablas hash de entrada de par y salida de par del filtro se actualizan 94 con punteros a las reglas de entrada de par y salida de par de los pares. Cuando el par no se autentica más 95, las reglas locales del par se expulsan de la base de reglas local del filtro 96, y los punteros a las reglas de entrada de par y salida de par de los pares se expulsan de las tablas hash de entrada de par y salida de par de los filtros 97. La presente invención proporciona nueva funcionalidad de seguridad en una base por usuario a filtros y paredes de fuego, mientras que mantiene la funcionalidad de filtros conocidos. La presente invención permite el ajuste dinámico de bases de reglas locales que pueden ajustarse a la medida dinámicamente para cumplir con las necesidades cambiantes del usuario individual . Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención. Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes:

Claims (26)

  1. REIVINDICACIONES 1. - Filtro para proporcionar control de acceso al nivel de par en una red que tiene un par con una base de reglas local, caracterizado porque el filtro comprende: (a) medios para accesar la base de reglas local de un par; y (b) medios para recibir un paquete que tiene un identificador de paquete, identificar una regla local correspondiente y llevar a cabo la acción de la regla local correspondiente en el paquete mientras que el filtro separa paquetes para el par en el paquete.
  2. 2. - El filtro de conformidad con la reivindicación 1, caracterizado porque además comprende: (c) medios para expulsar la base de reglas local del filtro.
  3. 3.- El filtro de conformidad con la reivindicación 1, caracterizado porque el identificador de paquete comprende una dirección de fuente y destino, un puerto de fuente y destino y un identificador de protocolo.
  4. 4.- El filtro de conformidad con la reivindicación 1, caracterizado porque los medios para accesar la base de reglas local comprenden el recibir y almacenar la base de reglas local .
  5. 5.- El filtro de conformidad con la reivindicación l, caracterizado porque además comprende medios para autenticar el par.
  6. 6.- El filtro de conformidad con la reivindicación 1, caracterizado porque además comprende una base de pre-reglas global que tiene una pre-regla global, en donde al recibir el paquete, el filtro primero busca la base de pre-reglas global para una regla que corresponda al paquete y lleva a cabo la acción de la pre-regla global correspondiente en el paquete, y en donde si no se identifica la pre-regla global correspondiente, el filtro busca la base de reglas global para una regla que corresponde al paquete y lleva a cabo la acción de la regla global correspondiente en el paquete.
  7. 7.- El filtro de conformidad con la reivindicación 1, caracterizado porque además comprende una base de post-reglas global, en donde la base de post-reglas global se busca por una regla que corresponde al paquete, y la acción de una post-regla global se lleva a cabo si corresponde al paquete, solo si no se identifica regla correspondiente en la base de pre-reglas global y no se identifica regla correspondiente en la base de reglas local.
  8. 8.- El filtro de conformidad con la reivindicación 1, caracterizado porque además comprende una regla predefinida, en donde si no se identifica pre-regla global correspondiente y no se identifica post-regla global correspondiente, el filtro lleva a cabo la acción de la regla pre-definida, si la regla predefinida corresponde al paquete, y genera una condición de error si la regla predefinida no corresponde al paquete.
  9. 9.- El filtro de conformidad con la reivindicación 1, caracterizado porque el par tiene una dirección de red, y en donde el identificador de paquete comprende una dirección de fuente de paquete y una dirección de destino de paquete, y en donde una regla local comprende una dirección de fuente de regla, una dirección de destino de regla y una acción, además comprende una tabla hash de acceso local, que tiene un puntero de entrada derivado al aplicar una función hash a la dirección de red del par, el puntero de acceso señala a una regla local de par cuya dirección de destino de regla corresponde a la dirección de red del par.
  10. 10.- El filtro de conformidad con la reivindicación 1, caracterizado porque el par tiene una dirección de red, y en donde el identificador de paquete comprende una dirección de fuente de paquete y una dirección de destino de paquete, y en donde una regla local comprende una dirección fuente de regla, una dirección de destino de regla y una acción, además comprende una tabla hash de salida local que tiene un puntero de salida derivado al aplicar una función hash a la dirección de red del par, el puntero de salida señala a una regla local de puntero cuya dirección fuente de regla corresponde a la dirección de red del par.
  11. 11.- Un método para proporcionar control de acceso a nivel de par en una red, el método se caracteriza porque comprende: a) accesar una base de reglas local de un par; (b) recibir un paquete que tiene un identificador de paquete; y (c) buscar la base de reglas local identificar la regla local que corresponde al identificador de paquete, y llevar a cabo la acción de una regla local si la regla local corresponde al paquete .
  12. 12.- El método de conformidad con la reivindicación 11, caracterizado porque además comprende la etapa de: (d) expulsar la base de reglas local .
  13. 13.- El método de conformidad con la reivindicación 11, caracterizado porque el identificador de paquete comprende una dirección de fuente y destino, un puerto de fuente y destino y un identificador de protocolo.
  14. 14.- El método de conformidad con la reivindicación 11, caracterizado porque accesar una base de reglas local comprende las etapas de recibir y almacenar la base de reglas local .
  15. 15.- El método de conformidad con la reivindicación 11, caracterizado porque además comprende la etapa de autenticar un par antes de accesar la base de reglas local del par.
  16. 16. - Un método para proporcionar control de acceso a nivel de par en una red con un par, el método se caracteriza porque comprende: a) recibir un paquete que tiene un identificador de paquete,- b) buscar una base de pre-reglas global e identificar una pre-regla global que corresponde al paquete,- c) llevar a cabo la acción de una pre-regla global si la pre-regla global corresponde al paquete,- d) accesar una base de reglas local de un par; e) si no se encuentra pre-regla global correspondiente en la base de pre-reglas global, buscar la base de reglas local identificando una regla local que corresponde al paquete y llevar a cabo la acción de una regla local si la regla local corresponde al paquete.
  17. 17.- El método de conformidad con la reivindicación 16, caracterizado porque además comprende la etapa de: (f) expulsar la base de reglas local del filtro.
  18. 18.- El método de conformidad con la reivindicación 17, caracterizado porque además comprende las etapas de: g) si no se encuentra pre-regla global correspondiente en la pre-base de reglas global y la regla local correspondiente se encuentra en la base de reglas local, buscar una post-base de reglas global para una post-regla global que corresponde al paquete,- y h) llevar a cabo la acción de una post-regla global si la post-regla global corresponde al paquete.
  19. 19.- El método de conformidad con la reivindicación 18, caracterizado porque además comprende las etapas de: i) si no se encuentra regla correspondiente en la base de pre-reglas global y no se encuentra regla correspondiente en la base de reglas local, y no se encuentra regla correspondiente en la base de post-reglas global, determinar si el paquete corresponde a la regla pre-definida; y j) llevar a cabo la acción de la regla predefinida si la regla pre-definida corresponde al paquete, y generar una condición de error si la regla pre-definida no corresponde al paquete.
  20. 20.- El método de conformidad con la reivindicación 16, caracterizado porque el par tiene una red de dirección, y en donde el identificador de paquete comprende una dirección de fuente de paquete y una dirección de destino de paquete, y en donde una regla local comprende una dirección de fuente de regla, una dirección de destino de regla y una acción, y en donde la base de reglas local tiene una regla local cuya dirección de destino de regla corresponde a la dirección de red del par se busca por una regla local que corresponde al paquete y la acción de la regla local se lleva a cabo si la regla local corresponde al paquete; que comprende las etapas de: a) derivar un puntero de acceso para aplicar una función hash a la dirección de red del par; b) almacenar el puntero de acceso en una tabla hash de acceso de par, de manera tal que el puntero de acceso señala a una regla local cuya dirección de destino de regla corresponde a la dirección de destino de red del par,- c) recibir un paquete,- d) aplicar la función hash a la dirección de destino de red del paquete; e) buscar las reglas locales a las cuales el puntero de acceso correspondiente a la dirección de destino de red de paquete con clave de elección arbitraria señala para una regla que corresponde al paquete,- y f) llevar a cabo la acción de una regla si la regla corresponde al paquete.
  21. 21.- El método de conformidad con la reivindicación 20, caracterizado porque además comprende la etapa de: (g) eliminar los punteros de acceso del par en la tabla hash de acceso local .
  22. 22.- El método de conformidad con la reivindicación 16, caracterizado porque el par tiene una dirección de red, y en donde el identificador de paquete corresponde a una dirección de fuente de paquete y una dirección de destino de paquete, y en donde una regla local comprende una dirección de fuente de regla, una dirección de destino de regla y una acción, y en donde la base de reglas local que tiene una regla local cuya dirección de fuente de regla corresponde a la dirección de red del par, se busca para una regla local que corresponde al paquete, y la acción de una regla local se lleva a cabo si la regla local corresponde al paquete, que comprende las etapas de: a) derivar un puntero de salida al aplicar una función hash a la dirección de red del par; b) almacenar el puntero de salida en una tabla hash de salida de par, de manera tal que el puntero de salida señala a una regla local cuya dirección de fuente de regla corresponde a la dirección de fuente de red del par,- c) recibir un paquete; d) aplicar la función hash a la dirección fuente de red del paquete,- e) buscar las reglas locales a las cuales el puntero de salida correspondiente a la dirección fuente de red del paquete con clave de elección arbitraria señala para una regla que corresponde al paquete,- y f) llevar a cabo la acción de una regla si la regla corresponde al paquete.
  23. 23.- El método de conformidad con la reivindicación 22, caracterizado porque además comprende la etapa de: (g) eliminar los punteros de salida de par en la tabla hash de salida local .
  24. 24.- Un filtro para proporcionar control de acceso al nivel de par en una red con un par, el filtro se caracteriza porque comprende: (a) medios para autenticar un par,- b) medios para accesar reglas desde un par que prescribe una acción de PASO (PASS) o RETIRA (DROP) a llevarse a cabo en un paquete; c) medios para recibir un paquete; d) medios para buscar e identificar reglas que corresponden al paquete,- y e) medios para llevar a cabo la acción de PASA (PASS) o RETIRA (DROP) de una regla que corresponden al paquete.
  25. 25.- El filtro de conformidad con la reivindicación 23, caracterizado porque además comprende: f) medios para expulsar las reglas de un par.
  26. 26.- El filtro de conformidad con la reivindicación 24, caracterizado porque además comprende: g) medios para autenticar un par.
MXPA/A/1998/000399A 1997-01-17 1998-01-13 Sistema y metodo para proporcionar control de acceso a nivel de par en una red MXPA98000399A (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/785,501 US6233686B1 (en) 1997-01-17 1997-01-17 System and method for providing peer level access control on a network
US08785501 1997-01-17

Publications (2)

Publication Number Publication Date
MX9800399A MX9800399A (es) 1998-10-31
MXPA98000399A true MXPA98000399A (es) 1999-01-11

Family

ID=

Similar Documents

Publication Publication Date Title
US6233686B1 (en) System and method for providing peer level access control on a network
US7441265B2 (en) Method and system for session based authorization and access control for networked application objects
US6754832B1 (en) Security rule database searching in a network security environment
US6505192B1 (en) Security rule processing for connectionless protocols
EP0943199B1 (en) Method and apparatus for access control in a distributed multiserver network environment
US8959613B2 (en) System and method for managing access to a plurality of servers in an organization
US6715081B1 (en) Security rule database searching in a network security environment
US7869361B2 (en) Managing hierarchically organized subscriber profiles
US6347376B1 (en) Security rule database searching in a network security environment
EP2239887B1 (en) User managing method and apparatus
US20090077618A1 (en) Segmented Network Identity Management
US20080046989A1 (en) System and method for remote authentication security management
US20020110123A1 (en) Network connection control apparatus and method
WO2004036350A2 (en) Secure file system server architecture and methods
WO2005027464A1 (en) Method and apparatus for providing network security using role­-based access control
CN1822590A (zh) 保护轻量级目录访问协议的通信
Eisler NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
US20080271114A1 (en) System for providing and utilizing a network trusted context
MXPA98000399A (es) Sistema y metodo para proporcionar control de acceso a nivel de par en una red
US8873555B1 (en) Privilege-based access admission table
EP1223721A2 (en) Systems and methods for automatically formulating response to authentication requests from secured servers
Cisco Wireless Support
Cisco Wireless Support
Cisco Configuring Traffic Filters
US20080028440A1 (en) System and a Method for Authorizing Processes Operations on Internet and Intranet Servers