MX2010009441A - Deteccion y notificacion de intrusion mejoradas. - Google Patents

Abstract

Un dispositivo (200, 300, 400) para su uso en un sistema (100) de comunicación celular, el dispositivo (200, 300, 400) se proporciona con medios (205) para inspeccionar paquetes de tráfico hasta y desde usuarios en el sistema y para una primera clasificación (SI) de paquetes de acuerdo con reglas predeterminadas. El dispositivo (200, 300, 400) también comprende medios (210, 220) para iniciar un proceso para un usuario el cual es el destino u origen de un paquete el cual se clasifica en la primera clasificación (SI) como perteneciendo a un tipo específico de tráfico el cual tiene como una de sus características que el dispositivo (200) no puede redirigir el paquete desde su destino pretendido a otro destino. El proceso es tal que en un punto posterior en el tiempo, cuando el usuario intenta acceder a una página web, el usuario se redirige a una página web predefinida.

Description

DETECCIÓN Y NOTIFICACIÓN DE INTRUSIÓN MEJORADAS CAMPO TÉCNICO La presente invención describe un dispositivo y un método para detección y notificación de intrusión mejoradas en un sistema celular inalámbrico.

ANTECEDENTES Software malicioso, también conocido como "malware" es el nombre común para todos los tipos de software o código de programación que se diseñan para infiltrar y dañar potencialmente un sistema de cómputo sin consentimiento informado de su propietario. El software malicioso abarca virus de computadora, Troyanos, gusanos, spyware y además adware a cierto grado.

Ejemplos de formas comúnmente conocidas en malware son virus de computadora y gusanos, los cuales difieren entre sí principalmente de la forma en que se propagan. Un virus es en principio un programa ejecutable o un archivo infectado que requiere que el usuario lo active, por ejemplo, al ejecutar un programa de virus descargado o al abrir un documento infectado anexado a un correo electrónico. Un gusano, por otro lado, se propaga automáticamente sobre una red sin ninguna intervención activa del usuario.

Los problemas relacionados con diferentes formas de malware se incrementan en la Internet de hoy en día, y es altamente probable que virus y gusanos que plagan actualmente computadoras estacionarias y computadoras tipo laptop pronto también "migrarán" a teléfonos celulares. Éste particularmente es el caso puesto que teléfonos celulares con una facilidad cada vez mayor pueden utilizarse para navegar la Internet, lo cual incrementa el riesgo de infecciones de malware .

Una forma de tratar con el problema de malware en teléfonos celulares puede ser desde luego proporcionar a los usuarios finales (es decir, los teléfonos) con soluciones de antivirus, tales como programas antivirus. Sin embargo, los teléfonos celulares presentan desafíos significativos para el software antivirus, tal como por ejemplo: · Restricciones de memoria, • Restricciones de procesador, • Proporcionar definiciones y nuevas actualizaciones de firmas a los microteléfonos móviles En vista de estos desafíos, un sistema de detección de intrusión (IDS) así denominado o sistema de detección de intrusión de red (NIDS) puede parecer una solución atractiva para el problema de malware en teléfonos celulares. Estos sistemas, es decir, IDS/NIDS pueden explicarse brevemente como sigue: Un sistema de detección de intrusión (IDS) monitorea el tráfico de red en un sistema o un dispositivo y es capaz de detectar formas no deseadas de tráfico tal como tráfico malicioso de gusanos y virus que tratan de propagarse sobre la red.

Detectar tráfico sospechoso tradicionalmente se logra por la inspección de paquetes, identificando heurísticas y patrones (conocidos como firmas) de ataques de red común .

Cuando un "sensor" de IDS detecta una brecha de seguridad potencial, señala al propietario del sistema y registra la información.

Algunos sistemas de IDS son reactivos, estos sistemas, conocidos como Sistemas de Prevención de Intrusión (IPS), responden a actividad sospechosa al terminar la conexión .

Un sistema de detección de intrusión de red (NIDS) es un IDS que se implementa como una plataforma autónoma que identifica las intrusiones a través de inspección de paquetes de tráfico hasta y desde múltiples ordenadores.

Aunque parecen soluciones atractivas a primera vista, introducir NIDS/NIPS autónomos en redes móviles puede tener varias desventajas: • Los NIDS/NIPS autónomos pueden introducir latencia de plano de usuario adicional en el sistema , • Inspección de paquetes se realizará de manera ineficiente en varios casos de la red si la red utiliza PCC (Control de Política y Cobro) de 3GPP: o Una vez para propósitos de detección de intrusión en lado de Gn (enlace ascendente) o Una vez más para el control de política y cobro o Probablemente también una tercera vez en el lado de Gi (enlace descendente) para prevención de intrusión.

• Componentes adicionales en la red que requerirán mantenimiento y que de este modo llevarán a una complejidad incrementada para el operador, es decir: o CAPEX incrementado o Riesgo de OPEX incrementado Un problema particular es provocado por malware que infecta su "ordenador" por medio de tráfico, el cual no es hasta o desde una página web, debido al hecho de que si un dispositivo, con o sin el consentimiento del usuario direcciona una página web la cual se conoce como fuente de malware o que lleva con el mismo un alto riesgo conocido de infección de malware, el tráfico puede interrumpirse por un programa de supervisión y redirigirse a un sitio predeterminado "seguro", el cual puede tener un letrero de advertencia, para que el usuario por ejemplo pueda verse obligado a ejecutar una exploración de virus o a descargar un programa de antivirus/antimalware .

Sin embargo, si el malware infecta su ordenador por otro medio, no existe forma de que el usuario del dispositivo ordenador pueda alertarse en cuanto al hecho de que tráfico sospechoso se está enviando desde/hasta el dispositivo.

COMPENDIO De este modo, como se explica en lo anterior, existe la necesidad de una solución por medio de la cual los problemas establecidos en lo anterior con respecto a la prevención/remoción de malware puedan reducirse o eliminarse. La solución en particular debe ser capaz de solucionar el problema de malware el cual se transporta en tráfico que no puede redirigirse.

Tal solución se presenta por la presente invención ya que describe un dispositivo para su uso en un sistema de comunicación celular, el cual comprende medios para inspeccionar paquetes de tráfico hasta y desde usuarios en el sistema .

El dispositivo además se proporciona con medios para una primera clasificación de los paquetes de tráfico de acuerdo con reglas predeterminadas, asi como con medios para iniciar un proceso para un usuario el cual es el destino u origen de un paquete el cual se clasifica en la primera clasificación como perteneciendo a un tipo específico de tráfico .

El "tipo especifico de tráfico" mencionado en lo anterior tiene como una de sus características que el dispositivo no puede redirigir el paquete desde su destino pretendido a otro destino, y el proceso el cual se inicia por el dispositivo es tal que en un punto posterior en el tiempo, cuando el usuario intenta acceder a una página web, el usuario se redirige a una página web predefinida.

De este modo, la invención puede manejar el caso de tráfico sospechoso "sin relación de explorador" ya que, cuando es posible, el usuario se redirige a una página web la cual contiene de manera adecuada una advertencia con respecto a infecciones de malware . De manera adecuada, esta "redirección" se lleva a cabo en la primera oportunidad, es decir, el "punto posterior en el tiempo" mencionado en lo anterior se presenta antes de la siguiente vez que el usuario intente acceder a cualquier página web.

En una modalidad, el dispositivo también se proporciona con medios para llevaran a cabo una clasificación secundaria de los paquetes, y en esta modalidad el dispositivo comprende adicionalmente un primer nodo adicional el cual se suministra con los resultados de la clasificación secundaria. El primer nodo adicional a su vez suministra el dispositivo con una decisión sobre si el proceso debe iniciarse o no.

En otra modalidad, el dispositivo recibe las reglas para la primera clasificación desde un segundo nodo adicional en el sistema, incluyendo reglas para el inicio del proceso.

La invención también describe un método para detección y prevención de malware en un sistema de comunicación celular.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La invención se describirá en mayor detalle en lo siguiente, con referencia a los dibujos anexos, en los cuales : La Figura 1 muestra un principio de la invención, y las Figuras 2-4 muestran diagramas de bloque de modalidades de un dispositivo de la invención, y la Figura 5 muestra un diagrama de flujo de un método de la invención.

DESCRIPCIÓN DETALLADA La Figura 1 ilustra esquemáticamente un principio detrás de la invención. Sin embargo, antes de que se describa este principio, debe señalarse que en la descripción siguiente, el uso se hará de la terminología tomada de los sistemas celulares tales como sistemas 2G/3G. Sin embargo esto sólo es para facilitar el entendimiento del lector de la invención y no debe verse como restricción del alcance de la protección buscada por la presente invención, la cual puede aplicarse igualmente en otros sistemas celulares, tales como por ejemplo, sistemas de WLAN o LTE, Evolución a Largo Plazo.

Con referencia ahora a la figura 1, una terminal de usuario, un "UE" 110 recibe y envía tráfico en un sistema 100 celular, el tráfico se enruta a través de un puerto de enlace, tal como por ejemplo, un denominado GGSN, Nodo de Soporte de GPRS de Puerto de Enlace. Parte del sistema 100 se ilustra esquemáticamente como una nube, para indicar que pueden existir múltiples componentes entre el UE y el GGSN.

El tráfico hasta y desde el UE se muestra esquemáticamente con flechas en la figura 1, y un principio de la invención es que el tráfico en una o ambas direcciones se inspecciona por un nodo o función en un dispositivo en el sistema tal como por ejemplo, el GGSN. Puesto que una meta de la invención es detectar principalmente el comportamiento de malware en tráfico, el cual no es hasta o desde una aplicación basada en explorador en el UE, la inspección se lleva a cabo de preferencia sólo en tal tráfico. Otra forma de expresar esto es que la inspección de preferencia se lleva a cabo en el tráfico el cual no se basa en protocolos de explorador tal como HTTP, Protocolo de Transferencia de Hipertexto, o WSP, Protocolo de Sesión Inalámbrica.

Los paquetes hasta o desde el UE se inspeccionan y clasifican de acuerdo con ciertas reglas, la clasificación es tal que cada paquete se le asigna con lo que se denominará en la presente como un Identificador de Servicio, un SI. Diferentes tipos de inspección pueden utilizarse para llegar al SI adecuado para un paquete, con algunos ejemplos de métodos de inspección siendo Inspección de Encabezado, inspección de paquetes a Profundidad e inspección Heurística.

Estos métodos se describirán en mayor detalle en lo siguiente : Inspección de Encabezado Durante la inspección de encabezado, el Protocolo de Internet (IP) y los encabezados de protocolo de transporte del paquete inspeccionado se analizan y correlacionan con las reglas de encabezado configuradas para el usuario. Si el paquete puede clasificarse basándose en la información en el IP y los encabezados de protocolo de transporte, se le asigna un SI .

Inspección de paquetes a profundidad La inspección de paquetes a profundidad es una extensión opcional de la inspección de encabezado. En lugar de asignar un SI, una regla de encabezado puede resultar en el reenvío de un paquete a las reglas del filtro de inspección a profundidad que se configuran para el usuario.

A través de las reglas del filtro de inspección a profundidad, el GGSN inspecciona el tráfico en el nivel de protocolo de aplicación, significando que, por ejemplo, el tráfico de http o WSP puede clasificarse basándose en la información de Identificador de Recursos Uniforme, URI, o en la operación específica utilizada.

Si la inspección a profundidad es exitosa, el paquete se le asigna un SI. La inspección a profundidad de varios protocolos de capa de aplicación ya se soporta en GGSN disponibles, en los cuales, por ejemplo, HTTP, WSP, FTP, TFTP SMTP, POP3, RTSP y SIP pueden soportarse.

Inspección heurística La inspección heurística es opcional, y se basa en un conjunto de patrones empíricos que caracterizan un protocolo o aplicación particular. Es una alternativa para la inspección de propiedad (por ejemplo, Skype) o protocolos encriptados que no pueden identificarse a través de inspección de encabezado o inspección a profundidad.

El SI el cual se le asigna a un paquete hasta o desde el UE se basará en uno o más de los parámetros de inspección listados en lo anterior. Un criterio principal para proporcionar a un paquete un SI el cual indica malware es que el paquete es tráfico no relacionado con "explorador" , por ejemplo, tráfico que no utiliza los protocolos de HHTP o WSP.

Si el SI el cual se le asigna un paquete hasta o desde el usuario indica malware, entonces el nodo de la invención inicia un proceso para el usuario, por medio del cual, la siguiente vez que el usuario intente acceder a una página web (es decir, la siguiente vez que el usuario utilice, por ejemplo, tráfico basado en HTTP o WSP) , se redirigirá al usuario a una página web la cual se ha configurado para tales casos, normalmente una página web de información que, por ejemplo, informa al usuario que el UE se le ha enviado y/o recibido tráfico sospechoso, y recomienda que el usuario tome la medida necesaria, tal como contactar al operador del sistema o descargar software que eliminará el malware .

El mecanismo para asignar un SI a un paquete puede observarse como un filtro, el cual puede detectar el comportamiento de tráfico sospechoso. Naturalmente, los filtros necesitarán actualizarse, lo cual puede hacerse adecuadamente por el operador del sistema.

Como ejemplo, una configuración para la detección de nivel de encabezado de malware la cual se conoce y es frecuente al momento de escritura, se proporciona en la tabla 1 siguiente, la cual muestra el tráfico que se presenta comúnmente que se origina a partir de malware . Los paquetes que muestran estas características, a todos se les puede dar uno y el mismo SI, el cual es un SI que indica malware, por ejemplo SI=666.

El proceso descrito previamente entonces se iniciará para el UE el cual es el origen o destino de los paquetes cuyo SI=666. Los paquetes con SI que indican una "factura limpia de rendimiento" se procesarán como normales.

Tabla 1, Ejemplos de Comportamiento de Malware Dirección de Protocolo IP L-4 Puertos Comentarios de cualquiera TCP 5554, 9995- Sasser a cualquiera 9996 de cualquiera TCP 2556 Bagle.m, n, o a cualquiera t, etc. Troyano furtivo de cualquiera TCP 2745 Bagle.k Troyano a cualquiera Furtivo de cualquiera TCP 8866 Bagle.b Troyano a cualquiera Furtivo de cualquiera TCP 3127 Mydoom* troyano a cualquiera furtivo de cualquiera TCP 3333, 4444 Blaster a cualquiera de cualquiera TCP 6531, 6551 Hale Troyano a cualquiera furtivo de cualquiera TCP 48522, 5555 Hale Troyano a cualquiera furtivo de cualquiera TCP 135, 593 Explota a cualquiera RPC/DCOM de cualquiera UDP 996 a 999 Sobig a cualquiera de cualquiera TCP 1080 Bugbear a cualquiera de cualquiera TCP 6129 Dameware RAT a cualquiera de cualquiera UDP 1434 Slammer/W32. SQLE a cualquiera x . Gusano de cualquiera UDP 135 Spam de Windows a cualquiera Messenger de cualquiera TCP 135 Explota a cualquiera Portmapper de cualquiera TCP 139 SMB sobre a cualquiera Netbios explota de cualquiera UDP 137-138 SMB sobre a cualquiera Netbios explota de cualquiera TCP 445 SMB sobre TCP/IP a cualquiera explota de cualquiera UDP 69 Cirebot IRC a cualquiera Troyano furtivo de cualquiera TCP 69, 57005 Cirebot IRC a cualquiera Troyano furtivo de cualquiera TCP 8719 Winshell .50 a cualquiera Troyano furtivo Algunos ejemplos específicos de modalidades de un dispositivo de la invención ahora se proporcionarán. Un GGSN normalmente comprenderá una función conocida como PCEF, Función de Mejora de Política y Cobro, en la cual particularmente es ventajoso integrar el nodo de la invención, puesto que la PCEF ya se configura para inspeccionar paquetes por razones de cobro y autorización. De este modo, en los ejemplos dados en lo siguiente, la invención se mostrará como siendo integrada en la PCEF.

Primer ejemplo de una modalidad, solución "autónoma" La figura 2 muestra un diagrama de bloque básico de un nodo 200 de PCEF de la invención, la cual puede comprenderse en un puerto de enlace de sistema tal como un GGSN en el caso 2G/3G. Esos bloques funcionales del nodo 200 de PCEF que se rediseñarán en un sistema de la invención se indican por medio de líneas discontinuas. Los bloques funcionales también se describirán en lo siguiente.

Una PCEF de la técnica anterior comprende un Motor 205 de Clasificación, CE , el cual clasifica paquetes y les asigna SI, Identif icadores de Servicio, basándose en definiciones de filtro que el CE recibe de un conjunto o base de datos de definiciones de filtro, FD 215. Las definiciones 215 de filtro se modificarán por medio de la invención, para incluir el comportamiento de malware conocido, por ejemplo aquellos de la tabla 1 anterior.

De este modo, por medio de las definiciones en FD 215, el CE 205 llega a un SI para un paquete, y el paquete junto con su SI se envían al PCE 210, Motor de Política y Cobro.

Asumir ahora, para ilustrar el ejemplo de la figura 2 adicionalmente , que existen cuatro filtros en la base de datos 215 de definición de filtro. De este modo, existen cuatro salidas de SI posibles del CE, las cuales pueden ejemplificarse como sigue: Número de Filtro Salida SI 1 1 2 2 3 100 4 666 Un PCE 210 de la técnica anterior utiliza una Base 220 de Política e Información, PIB, para encontrar la política correcta para un paquete con un cierto SI. La PIB 220 se modificará en una PCEF de la invención, para incorporar las políticas adecuadas para paquetes de malware.

En el presente ejemplo, los SI 1, 2 y 100 son indicativos de tráfico inofensivo, mientras un paquete que se encuentra a la altura de las definiciones del filtro número 4 es un paquete que se ajusta a la descripción de malware y de éste recibe un SI indicativo de esto, por ejemplo SI 666.

Un ejemplo de una PIB 220 para su uso en la PCEF 200 se proporciona en lo siguiente, con la característica agregada de que el tráfico en el sistema 100 en el cual la PCEF 200 puede aplicarse, puede existir en el tráfico 2G-GPRS ó 3G-GPRS, también denominado como tipos diferentes de Tipo de Acceso de Radio, RAT. En el siguiente ejemplo, se asumirá que SI 1, 2 y 100 son indicativos de tráfico que puede redirigirse, es decir, por ejemplo, tráfico basado en protocolos de HTTP o WSP.

En la PIB del ejemplo siguiente, el tráfico se trata como usual siempre y cuando no se detecte ningún tráfico relacionado con malware a través de clasificación de un paquete con SI 666. Si uno o más paquetes se clasifican con SI 666, entonces todo el tráfico subsiguiente (relevante) se redirigirá a una página web donde por ejemplo, el usuario del UE se le informa que su terminal ha enviado o recibido tráfico sospechoso que potencialmente se origina de malware, y el usuario se le aconseja tomar una medida apropiada. Esto significa que la siguiente vez que el usuario inicie una sesión de explorador, inmediatamente se le informará, aunque en otras modalidades, el tiempo de redirección puede establecerse para algún otro punto en el tiempo.

En una modalidad, cuando se lleva a cabo una redirección, un cronómetro restablecido se iniciará. Cuando el cronómetro expire, el portador de paquetes para SI 666 (o algún otro SI de malware) se restablecerá. Durante el tiempo en que se encuentra activo el cronómetro, es decir, en cuenta regresiva, el usuario no se redirigirá nuevamente. La razón de esto puede no bloquear al usuario para que continúe con su sesión en la web. Si el tráfico de software malicioso se detecta nuevamente cuando haya expirado el cronómetro, el usuario se redirigirá nuevamente.

Ejemplo de una PIB: Base de Información de Política, PIB Sin paquetes previos con SI 666 0 cronómetro restablecido no expirado : SI Acción 1 permitir 2 permitir 100 permitir 666 permitir, iniciar proceso para usuario Paquetes previos con SI 666 Y cronómetro restablecido expirado/no iniciado: SI Acción 1 redirigir, iniciar cronómetro, establecer "paquete previo con 666" =0 2 redirigir, iniciar cronómetro, establecer "paquete previo con 666" =0 100 redirigir, iniciar cronómetro, establecer "paquete previo con 666" =0 666 permitir, iniciar proceso para el usuario, establecer "paquete previo con 666"=0 Segundo ejemplo de una modalidad En esta modalidad, la PCEF de la invención también se integra en un puerto de enlace del sistema tal como un GGSN si el sistema es un sistema 2G/3G. De este modo, la figura 3 la cual forma un diagrama de bloque de una PCEF 300 con el nodo inventivo tiene muchos bloques en común con la modalidad mostrada en la figura 2. Los bloques que la PCEF 300 de la figura 3, tienen en común con la PCEF de la figura 2 que han retenido sus números de referencia de la figura 2. Como en la figura 2, los bloques que se modifican en una PCEF inventiva se muestran con líneas discontinuas en la figura 3.

Una diferencia en la PCEF 300 en comparación con la PCEF 200 de la figura 2 es que la PCEF 300 comprende o hace uso de un nodo 305 adicional, denominado OCS, Sistema de Cobro en Línea. Tales nodos existen previamente, pero el OCS 305 se modifica para desempeñarse de acuerdo con la invención, como se explicará en lo siguiente.

La interconexión (técnica anterior) entre la PCEF 300 y el OCS 305 se conoce como la interconexión Gy. La información sobre un paquete que se envía desde la PCEF viene desde el PCE 210, y se conoce como el Grupo de Clasificación, el RG, de paquetes.

En la modalidad de la figura 3, un paquete que lleva a la PCEF 300 aún se le asigna un SI por el FD 215, como se explica junto con la modalidad de la figura 2. El paquete y su SI entonces se envían a la PIB 220, la cual sin embargo tiene una función ligeramente diferente en esta modalidad: el objetivo de la PIB 220 aquí es correlacionar el SI de un paquete con un RG correspondiente. De este modo, la modificación de la PIB 220 en comparación con la técnica anterior comprenderá aquí permitir a la PIB 220 asignar el RG a SI los cuales indican malware, tal como por ejemplo, SI 666.

Actualmente, (técnica anterior) , una OCS puede responder de las siguientes formas a un RG desde el PCE: • Conceder solicitudes del RG, • Negarse a conceder solicitudes del RG, • Ordenar una redirección para el RG La invención podría implementarse utilizando el OCS 305 de la siguiente forma: asumir que las definiciones de filtro FD 215 incluyen filtros para software malicioso como se muestra en la figura 3, y que SI 666 se mapea en (por ejemplo) RG 666 por la PIB 220.

Cuando un SI de un paquete se clasifica como 666 (o algún otro SI el cual es indicativo de malware) , el PCE 210 solicitará créditos de RG 666 sobre la interconexión Gy. El crédito entonces puede concederse por el OCS 305 para este RG durante un periodo de tiempo el cual por ejemplo, es igual al cronómetro restablecido o discutido junto con el ejemplo 1 anterior, es decir, la solución "autónoma" .

La siguiente vez que el usuario inicie una sección de exploración (HTTP o WSP) y el PCE 210 solicite créditos del OCS 305 para esta sesión, el OCS 305 no concederá ningún crédito pero iniciará de hecho una redirección de una sola vez a por ejemplo, una página web donde al usuario del UE se le informa que su terminal está enviando o recibiendo tráfico sospechoso que potencialmente se ha originado de malware, y le aconseja al usuario tomar medidas apropiadas. Después de la redirección, el usuario puede continuar la sesión (le concederán créditos) .

Si el usuario trato con el problema inmediatamente, el tráfico del malware se detendrá, lo cual eventualmente provocará que los créditos para RG 666 "se venzan", y el PCE 210 informará consecuentemente al OCS 305 de esto. Sin embargo, si el usuario no arregla el problema de malware, el crédito para RG 666 se agotará y de este modo resultará en una solicitud de actualización donde PCE 210 solicita más créditos para RG 666. Esto informará al OCS 305 que el problema no se ha resuelto, y el usuario puede redirigirse nuevamente a la página web de información.

De este, modo, el comportamiento básico de la PCEF 300 es el mismo que en el caso autónomo, es decir, la PCEF 200, aunque en este ejemplo las enmiendas a la PCEF de la técnica anterior ahora también incluyen modificación de un OCS y dejan que la PCEF 300 utilice el OCS 305 modificado para lograr las metas de la invención.

Tercer ejemplo de una modalidad Un tercer ejemplo de una modalidad de la invención ahora se describirá con referencia a la figura 4.

La figura 4 muestra una modalidad en la cual el nodo de PCEF de la invención también se integra en un puerto de enlace del sistema tal como un GGSN. De este modo, en la figura 4, la cual muestra un diagrama de bloque de una PCEF 400 como el nodo inventivo, la PCEF 400 tiene muchos bloques en común con las modalidades mostradas en las figuras 2 y 3. Los bloques que la PCEF 400 de la figura 4 tienen en común con la PCEF de la figura 2, han retenido sus números de referencia de la figura 2. Como en la figura 2, los bloques que se modifican en una PCEF inventiva se muestran con líneas discontinuas en la figura 3.

En la modalidad 400, la PCEF también comprende o hace uso de un nodo 405 denominado PCRF, es decir, un nodo para Función de Reglas de Política y Cobro, el cual en la técnica anterior se accedió por el PCE 210 mediante una interconexión conocida como la interconexión Gx para suministrar el PCE con información de política con respecto a cobro y autorización de tráfico. De este modo, en la técnica anterior, cuando un UE inicia una sesión, el PCE solicita esta información de política de la PCRF mediante la interconexión Gx .

El PCE puede solicitar actualizaciones de la información de política de la PCRF, por ejemplo en actualizaciones de sesión, pero la PCRF también puede actualizar la actualización de política a voluntad, por ejemplo, como resultado de activadores externos, tal como por ejemplo, actualizaciones de suscripción.

De acuerdo con la invención, el PCE 210 y la PCRF 405 se alteran en su manejo de la interconexión de Gx, de modo que (PCE y PCRF) pueden utilizar la interconexión Gx para intercambiar mensajes con respecto a SI que son indicativos de malware .

Asumir ahora que las definiciones de filtro en FD 215, como en lo anterior, incluyen filtros para malware, y que el malware se asignará uno o más "SI de malware" especiales, tal como por ejemplo 666. Lo siguiente entonces es un ejemplo de un escenario posible en la PCEF 400: 1. En la sesión de inicio para un UE, una sesión de Gx se inicia por el PCE 210 hacia la PCRF 405. La siguiente información de política se recibe por el PCE sobre la interconexión de Gx: Regla de Política SI Regla de autorización 1 1 Autorizado 2 2 Autorizado 100 100 Autorizado 666 666 Autorizado + reportar después de 1 paquete En este ejemplo, cuando un paquete se clasifica con SI 666, el Motor de Política y Cobro lo autorizará, pero el evento también activará un reporte sobre la interconexión de Gx. Tanto el mecanismo de activación como el mecanismo para el reporte son partes de la invención. 2. La PCRF 405 responderá al reporte con nueva información de política para el PCE 210, como sigue: de Política SI Regla de autorización 1 1 Redirigir + reportar después de un paquete 2 2 Redirigir + reportar después de un paquete 100 100 Redirigir + reportar después de un paquete 666 666 Autorizado De acuerdo con estas nuevas reglas que se activan por SI de malware, el tráfico el cual puede redirigirse (por ejemplo, "tráfico basado en explorador" , tal como tráfico basado en HTTP y WSP) se redirigirá ahora a una página web donde el usuario por ejemplo se le informa que su terminal está enviando o recibiendo tráfico sospechoso que potencialmente se origina de malware, y que debe tomarse una medida apropiada. En efecto, esto significa que la siguiente vez que el usuario inicie una sesión de explorador, se le puede informar inmediatamente o de manera alternativa, en un punto posterior en el tiempo.

Cuando una redirección de acuerdo con las reglas anteriores tiene lugar, el PCE solicitará otra actualización sobre la interconexión de Gx. La PCRF responderá con nueva información de política como sigue: Regla de PCC SI Regla de autorización 1 1 Autorizado 2 2 Autorizado 100 100 Autorizado 666 666 Autorizado Nuevamente, todo el tráfico se autorizará, y un cronómetro se iniciará en la PCRF. Con la finalización del cronómetro, la siguiente información de política se "insertará" en el PCE: Regla de PCC SI Regla de autorización 1 1 Autorizado 2 2 Autorizado 100 100 Autorizado 666 666 Autorizado + reportar uso después de 1 paquete Como puede observarse, ésta es la misma información de política que se proporcionó en el establecimiento de sesión. Por consiguiente, si un paquete se clasifica como SI 666, el mismo procedimiento tendrá lugar, y el usuario se redirigirá nuevamente.

La figura 5 muestra un diagrama de flujo esquemático de un método 500 generalizado de la invención. El método 500 se pretende para su uso en un sistema de comunicación celular, y, como se indica en la etapa 505, comprende inspección de paquetes de tráfico hasta y desde usuarios en el sistema, así como, etapa 510 una primera clasificación de paquetes de acuerdo con las reglas predeterminadas .

El método 500 también inicia, etapa 515, un proceso para un usuario el cual es el destino u origen de un paquete el cual se clasifica en la primera clasificación de la etapa 510 como perteneciendo a un tipo específico de tráfico el cual tiene como una de sus características que el sistema no puede redirigir el paquete desde su destino pretendido a otro destino. El proceso es tal, que en un punto posterior en el tiempo, cuando el usuario 110 intenta acceder a una página web, el usuario se redirige, etapa 520, a una página web predefinida .

En una modalidad, como se indica en la etapa 525, el punto posterior del tiempo cuando un usuario se redirige se presenta la siguiente vez que el usuario intenta acceder a cualquier página web.

Como se muestra en la etapa 533, el método 500 también puede comprender una clasificación secundaria de los paquetes, utilizando la clasificación secundaria para tomar una decisión sobre si debe iniciarse o no el proceso.

En una modalidad alternativa, como se indica en la etapa 530, las reglas para la primera clasificación se reciben, como se muestra en la etapa 530, desde un nodo adicional en el sistema, incluyendo reglas para el inicio del proceso .

Como se indica en la etapa 535, el método 500 puede aplicarse en un dispositivo para PCEF, Función de Ejecución de Política y Cobro, la cual como se indica en la etapa 545, puede representarse en un sistema celular, tal como uno de los siguientes: 2G/3G, WLAN o LTE . Como se muestra en la etapa 540, la clasificación secundaria mencionada en lo anterior puede hacerse adecuadamente en un nodo para OCS, Sistema de Cobro en Línea.

La invención no se limita a los ejemplos de modalidades descritas en lo anterior y se muestra en los dibujos, pero puede variarse libremente dentro del alcance de las reivindicaciones anexas. Por ejemplo, la invención puede aplicarse no sólo en un sistema de 2G/3G, sino también puede aplicarse en sistemas tales como WLAN o LTE. Ejemplos de puertos de enlace en estos sistemas en los cuales la PCEF podría emplearse son el PDG, Puerto de Enlace de Datos por Paquetes, en sistemas de WLAN, y en sistemas de LTE, un puerto de enlace adecuado para la PCEF de la invención es el PDN-GW, el Puerto de Enlace de Red de Datos por Paquetes.

Claims (23)

REIVINDICACIONES

1. Un dispositivo (200, 300, 400) para su uso en un sistema (100) de comunicación celular, el dispositivo (200, 300, 400) se proporciona con medios (205) para inspeccionar paquetes de tráfico hasta y desde usuarios en el sistema y para una primera clasificación (SI) de paquetes de acuerdo con reglas predeterminadas, el dispositivo (200, 300, 400) se caracteriza porque también comprende medios (210, 220) para iniciar un proceso para un usuario el cual es el destino u origen de un paquete el cual se clasifica en la primera clasificación (SI) como perteneciendo a un tipo específico de tráfico el cual tiene como una de sus características que el dispositivo (200) no puede redirigir el paquete desde su destino pretendido a otro destino, el proceso es tal que en un punto posterior en el tiempo, cuando el usuario intenta acceder a una página web, el usuario se redirige a una página web predefinida.

2. El dispositivo (200, 300, 400) de la reivindicación 1, en el cual el punto posterior en el tiempo cuando un usuario se redirige se presenta la siguiente vez que el usuario intenta acceder a cualquier página web.

3. El dispositivo (200, 300, 400) de la reivindicación 1 ó 2, es un dispositivo para PCEF, Función de ejecución de Política y Cobro.

4. El dispositivo de la reivindicación 3, que es una PCEF en un puerto de enlace de sistema (100) en uno de los siguientes sistemas de comunicación celular: 2G/3G, WLAN o LTE.

5. El dispositivo (300) de cualquiera de las reivindicaciones 1-4, también se proporciona con medios (210, 220) para llevar a cabo una clasificación secundaria de paquetes, el dispositivo (200, 300) comprende adicionalmente un primer nodo (305) adicional, el cual se suministra con los resultados de la clasificación secundaria, y cuyo primer nodo (305) adicional en cambio suministra al dispositivo con una decisión sobre si debe iniciarse o no el proceso.

6. El dispositivo de la reivindicación 5, con el primer nodo (305) adicional siendo un nodo para OCS, Sistema de Cobro en Línea.

7. El dispositivo (400) de cualquiera de las reivindicaciones 1-4, que recibe reglas para la primera clasificación desde un segundo nodo (405) adicional en el sistema, incluyendo reglas para el inicio del proceso.

8. El dispositivo (400) de la reivindicación 7, con el segundo nodo (405) adicional siendo un nodo para PCRF, Función de Reglas de Política y Cobro.

9. Un nodo (305) para OCS, Sistema de Cobro en Línea, en un sistema (100) de comunicación celular, el nodo (305) de OCS se adapta para recibir, desde un dispositivo (300) en el sistema, solicitudes de crédito para paquetes de un usuario, las solicitudes se basan en una clasificación de un paquete por el dispositivo (300) , el nodo (305) de OCS se adapta para conceder créditos para paquetes con una cierta clasificación durante un cierto periodo predeterminado de tiempo.

10. El nodo (305) de OCS de la reivindicación 9, se adapta para iniciar una redirección del tráfico de usuario a una cierta página web predeterminada si el crédito se solicita varias veces para uno y el mismo usuario con paquetes con una clasificación que indica malware .

11. El nodo (305) de OCS de las reivindicaciones 9 ó 10, en el cual la clasificación es la clasificación RG, Grupo de Clasificación, la cual se intercambia con el dispositivo (300) sobre la interconexión Gy del nodo de OCS.

12. Un nodo (405) para PCRF, Función de Reglas de Política y Cobro en un sistema (100) de comunicación celular, el nodo (405) de PCRF se adapta para suministrar a un dispositivo (400) en el sistema con un primer conjunto de reglas para cobro y autorización de tráfico en forma de paquetes, el nodo (405) de PCRF también se adapta para recibir reportes del dispositivo (400) sobre paquetes que el dispositivo ha asignado una cierta clasificación, el nodo (405) también se adapta para suministrar al dispositivo (400) con un segundo conjunto de reglas para paquetes al recibir los reportes.

13. El nodo (405) de PCRF de la reivindicación 12, en el cual el segundo conjunto de reglas que comprende instrucciones para redirigir el tráfico redireccionable a una cierta página web predefinida.

14. El nodo (405) de PCRF de la reivindicación 13, se adapta para recibir un reporte del dispositivo (400) que ha tenido lugar una redirección, sobre la cual el nodo (405) de PCRF emite un nuevo conjunto de reglas al dispositivo (400) , que instruyen al dispositivo a cesar el redireccionamiento .

15. El nodo (405) de PCRF de la reivindicación 14, el cual comprende un cronómetro el cual se inicia cuando el dispositivo (400) se instruye para cesar el redireccionamiento, de modo que el nodo (405) de PCRF, con la finalización del cronómetro, emitirá el segundo conjunto de reglas al dispositivo (400) .

16. Un método (500) para su uso en un sistema (100) de comunicación celular, que comprende inspección (505) de paquetes de tráfico hasta y desde usuarios (110) en el sistema (100) , en una primera clasificación (510) de los paquetes de acuerdo con las reglas (SI) predeterminadas, el método (500) se caracteriza porque también inicia (515) un proceso para un usuario (110) el cual es el destino u origen de un paquete el cual se clasifica en la primera clasificación (510) como perteneciendo a un tipo específico de tráfico, el cual tiene como una de sus características que el sistema (100) no puede redirigir el paquete desde su destino pretendido a otro destino, con el proceso siendo tal que en un punto posterior en el tiempo, cuando el usuario (110) intenta acceder a una página web, el usuario se redirige (520) a una página web predefinida.

17. El método (500) de la reivindicación 16, de acuerdo con el cual el punto posterior en el tiempo cuando un usuario (100) se redirige, se presenta (525) la siguiente vez que el usuario intenta acceder a cualquier página web.

18. El método (500) de cualquiera de las reivindicaciones 16 ó 17, aplicado (535) en un dispositivo para PCEF, Función de Ejecución de Política y Cobro.

19. El método (500) de la reivindicación 18, con la PCEF siendo utilizada (545) en un puerto de enlace de sistema en uno de los siguientes sistemas de comunicación celular: 2G/3G, LAN o LTE .

20. El método (500) de cualquiera de las reivindicaciones 16-19, también comprende una clasificación (533) secundaria de los paquetes y utiliza la clasificación secundaria para tomar una decisión sobre si debe iniciarse o no el proceso.

21. El método (500) de la reivindicación 20, de acuerdo con el cual la clasificación secundaria se hace en un nodo (305) para OCS, Sistema de Cobro en Línea.

22. El método (500) de las reivindicaciones 16-19, de acuerdo con el cual las reglas para la primera clasificación se reciben (530) desde un nodo (405) adicional en el sistema (100) , que incluye reglas para el inicio del proceso.

23. El método (500) de la reivindicación 22, con el nodo (405) adicional siendo un nodo para PCRF, Función de Reglas de Política y Cobro.