EP1894350B1 - Securisation de la telephonie sur ip - Google Patents

Securisation de la telephonie sur ip Download PDF

Info

Publication number
EP1894350B1
EP1894350B1 EP06778655A EP06778655A EP1894350B1 EP 1894350 B1 EP1894350 B1 EP 1894350B1 EP 06778655 A EP06778655 A EP 06778655A EP 06778655 A EP06778655 A EP 06778655A EP 1894350 B1 EP1894350 B1 EP 1894350B1
Authority
EP
European Patent Office
Prior art keywords
network
proxy
data
security
sip
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.)
Not-in-force
Application number
EP06778655A
Other languages
German (de)
English (en)
Other versions
EP1894350A1 (fr
Inventor
Gérard KAAS
Benjamin Calais
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.)
CheckPhone Technologies
Original Assignee
CheckPhone Technologies
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 CheckPhone Technologies filed Critical CheckPhone Technologies
Publication of EP1894350A1 publication Critical patent/EP1894350A1/fr
Application granted granted Critical
Publication of EP1894350B1 publication Critical patent/EP1894350B1/fr
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes

Definitions

  • the present invention relates to the field of voice over IP ( Internet Protocol ) .
  • the present invention more particularly relates to a system and a method for securing IP telephony.
  • the invention relates as well to the security of calls during their establishment and their lives as the security of the network infrastructure hosting telephony over IP.
  • the pure IP telephony (ToIP) context is based on the existence of a single link between the packet network type A and B companies, for example the Internet. All calls between these two companies go through this network.
  • IP IP telephony
  • Telephony in general implements two streams of data: one relates to signaling for the establishment and management of calls, the other relates to the data media stream itself, for example the voice.
  • ToIP Session Initiation Protocol
  • H.323, Media Gateway Control Protocol (MGCP), SS7 ( Signaling System No. 7 ), etc. are also known.
  • the A1 post is in company A, it uses a SIP phone and is behind a SIP proxy that handles the connections. All connections from Company A's phones go out via the Internet connection dedicated to telephony; the B1 post is in the B company, uses a SIP phone and is behind a SIP proxy that handles the connections. All connections from company B phones go out via the Internet connection dedicated to telephony.
  • the figure 2 illustrates the establishment of a call between A1 and B1 for a standard SIP protocol.
  • Proxy A1 picks up his phone and makes a call to B1. This has the effect of issuing an INVITE type message from the A1 to the Proxy company A. Proxy A takes into account the request of A1. As the request is for an area that is not managed by Proxy A, Proxy A consults a location server to obtain more information about the target area, namely the Proxy concerned (Proxy B). It then transmits to Proxy B, the INVITE request.
  • Proxy A sends a TRYING message to A1 to warn him that his request has been taken into account.
  • Proxy B which has received the request from Proxy A, transmits it to B1. During this time, Proxy B sends a TRYING message to Proxy A to warn him that the request is well taken into account.
  • the B1 station has received the call request, and responds with a RINGING message to the B Proxy, which propagates this information to the Proxy A which in turn transmits it to the A1 station.
  • the session of the call is then fully established.
  • the station A1 sends an acknowledgment message ACK directed to the station B1.
  • IP packet network
  • the document US 2004/255156 describes a system for securing telephony over an internal packet network connected to an external network. This system dynamically creates at least one pinhole in a firewall.
  • the communications system includes a protected node capable of initiating a communications session with an outside node. In this regard, the protected node may receive rate parameters relating to the communications session when it is installed.
  • the system also includes a firewall placed along the communications path between the protected node and the outer node.
  • the present invention intends to overcome the drawbacks of the prior art by proposing a system and a method for securing IP telephony.
  • the invention is based on the use of a security supervisor inside a demilitarized zone, which supervisor uses network data provided by equipment dedicated to either IP telephony (SIP Proxy) or to detection. suspicious data packets or data on the network (detection probe) and comparing them to safety rules in order to adapt adequately the behavior of protective equipment.
  • SIP Proxy IP telephony
  • detection probe comparing them to safety rules in order to adapt adequately the behavior of protective equipment.
  • the use of a central and independent supervisor in the management of data transfer and in particular IP telephony offers an easier management of security, in particular by allowing it to be dynamic through the use of expert systems self-learners.
  • the invention does not consist in a simple control in the opening / closing of firewall ports, but in a more complex management of voice over IP security.
  • the method according to the present invention responds particularly well to the needs of companies for which the security of calls but also IP network infrastructures are first-rate.
  • the invention relates in its most general sense to a system for securing telephony on an internal network in packet mode connected to an external network, the system comprising a firewall and a proxy processing call signaling, both connected to said internal network, characterized in that it further comprises a security supervisor connected to said proxy and able to control said firewall in response to data transmitted by the proxy.
  • said supervisor comprises a database providing security rules to be applied to said network and software means for comparing said received data with said security rules.
  • said supervisor controls the opening and closing of the ports of said firewall.
  • system further comprises an IDS probe connected to the network and providing data to said supervisor.
  • said IDS probe is dedicated for the ToIP and remounts to said supervisor the data contained in the signaling packets.
  • said IDS probe is dedicated for the analysis of the media flow and returns to said supervisor only information on the detected media stream.
  • said packet network is an IP network and the telephony protocols are SIP for signaling and RTP for the media stream.
  • said proxy comprises software means able to trace information on the call signaling to the supervisor.
  • the system may include a second firewall connected to said packet network, all two firewalls constituting a demilitarized zone between the internal network and the external network, said supervisor also controlling said second firewall.
  • said external network is a switched mode telephony network comprising a switch, which exchange transmits to the supervisor data on calls passing through the switch.
  • the system comprises two IDS probes within the demilitarized zone, the two probes being connected to said supervisor and each associated with a firewall.
  • the invention also relates to an architecture comprising an internal packet network connected to an external network by a security system according to any one of the preceding claims, and a set of telephones on said internal network, wherein said set of telephones is consisting of at least two subsets and, during a call to or from one of said phones, said supervisor takes into account the subset of membership of the phone in determining the response to bring.
  • the invention also relates to an architecture comprising a plurality of internal networks in packet mode interconnected by an external network, each internal network comprising a security system described above.
  • the architecture further comprises a certificate server connected to said external network, and in that the signaling transmitted between two proxy is a negotiated secure channel.
  • the invention also relates to a method for securing telephony on a packet network comprising a security system described above, said method comprising a transmission step of proxy data to said supervisor, a confrontation step, by the supervisor, of said data with security rules contained in the supervisor and determination of an adapted response, a control step by the supervisor of the firewall to apply said reply.
  • the signaling protocol used for voice over IP is the SIP while the media flow protocol is the RTP.
  • Company A is connected to both the digital Internet network and the public switched telephone network (PSTN) and has an internal switched network 40 and an IP network 50, the two networks being connected to each other.
  • PSTN public switched telephone network
  • the company's switched network 40 comprises a gateway 42 ( media gateway ) to the IP network 50, this gateway converting the format data of one of the networks into the format of the other: from the media to the switched mode on ISDN in the RTP format for the IP network.
  • the switched network 40 also comprises a plurality of "conventional" telephones 44 connected to the network 40.
  • a communication originating from the PSTN switched network intended for a "conventional" station 44 transits via the gateway 42.
  • a solution for securing such a device switched network has been proposed in the patent application FR04 / 52361 .
  • the security of the PBX a security server retrieves switching data from the switch, confronts them with security rules and controls, according to the latter, a firewall for neutralize possible attacks.
  • the gateway 42 is understood as including the switching means (automatic switch) and means for implementing a security policy in accordance with the patent application. FR04 / 52361 .
  • TDM time division multiplexing
  • the call passes via the gateway 42, is converted into the correct format and is then transmitted to the IP 50 network.
  • the IP network 50 comprises a SIP proxy 52 and a set of SIP telephone sets 54 on the company's internal IP network 56.
  • the signaling part is processed by the SIP proxy 52, then the media stream is established on the IP network to the SIP station 54 concerned.
  • the SIP Proxy 52 can directly integrate the functions of Registrar 52 '(stores the addresses of the SIP extensions to allow localization thereof, used in case of post portability for the same person) and 52 "authentication server .
  • the IP network 50 comprises a demilitarized zone 60 in front (directly connected) of the external Internet network.
  • This demilitarized zone is connected to the three networks: external Internet, internal switched 40 via the gateway and internal IP 56.
  • Firewalls are implemented in software on computer workstations and control the exchange of IP packets by opening or closing communication ports.
  • a security supervisor 68 is also provided in the demilitarized zone 60. This supervisor 68 is connected to the network 50 and can control / control the firewalls 62, 64 and 66. Intrusion detection probes 70 and 72 and a guard The voice 74 is also integrated into the IP 50 network in the demilitarized zone and provides information to the supervisor 68.
  • the intrusion detection probes 70 and 72 analyze the SIP header and the body of the SIP messages. From this data, they define a call context that defines whether the packet is allowed in the current context of the call.
  • This call context is correlated on the various probes through the supervisor so that each border element knows the contexts of the various calls in progress.
  • the transmitted SIP signaling packets are received by the SIP Proxy 52.
  • the Proxy 52 is the main element of an IP telephony architecture. As such, he is involved in the establishment of all communications. In order to be able to guard against various attacks, a certain amount of information is retrieved from it in order to transmit it to the supervisor 68.
  • the Proxy 52 thus integrates an additional software layer with that usual in these infrastructures, the new software layer making it possible to make this information available to the security supervisor 68. In some cases of attack, for example attacks directed to the proxy, it is interesting that it is the proxy that reacts in addition to the firewalls.
  • Proxy 68 must therefore be able to go into "security" mode in the event of a massive attack in order to safeguard the integrity of already established communications: the software layer then comprises static security rules (for example in the form of configuration parameters) which can be applied directly without the intervention of the supervisor 68.
  • the SIP signaling data is also retrieved by the IDS probes 70 and 72 or the voice firewall 74 which transmit the contents of the SIP packets to the supervisor 68.
  • the voice firewall 74 deals with the security of the switched network portion . For this purpose it uses the data collected by the TDM sensor and cuts the communications on the Media Gateway 42 if necessary. In the event that a call passes through both networks (switched to IP and IP to switched) the security action will be conducted at the level of the firewall 66 from the supervision server 68.
  • the firewall 74 synchronizes with the security supervisor before each action in order to allow a single cut-off request to be made either at the firewall level 66/64/62 either at the level of the Media Gateway 42 if the communication passes through these two equipments.
  • the supervisor 68 receives information from the SIP proxy 52, the gateway 42 (or the switched network security supervisor as mentioned above) and possibly the intrusion detection probes 70 and 72, and the voice firewall 74.
  • Supervisor 68 includes security rules in a database as well as a processing module that confronts received data with the rules.
  • a more precise description of such a supervisor is provided in the patent application FR04 / 52361 , in which the person skilled in the art can easily convert the information concerning switched telephony to IP telephony.
  • the supervisor 68 optionally includes a system for learning security rules based on possible scenarios of calls. This system can be an expert system.
  • an audit supervisor makes it possible to analyze the functionalities of the Proxy 52 and the terminals 54 as well as the architecture of the system for the implementation of the IP telephony. This analysis allows the audit supervisor to establish call scenarios that will be taken into account by the supervisor 68 for establishing the security rules.
  • the supervisor 68 supervises the progress of the communications and pilot, for security purposes, the openings and closings of port on the firewalls 62, 64 and 66.
  • the supervisor 68 informs the Proxy 52 of this intervention so that it updates its data for example the list of communications in progress in the case of a proxy " statefull »(Which memorizes a context related to a user).
  • the supervisor also informs the switched party (gateway 42) to inform the exchange of the end of a call if the latter passes through the gateway to recover the resources that have been allocated to this call.
  • IP telephony uses dynamically selected ports to pass RTP media streams. For security reasons, these ports should not be open permanently but dynamically when a communication occurs.
  • the information concerning the ports to open is contained in the body of the SIP message.
  • the security supervisor 68 will therefore seek the information of the port to open in the SIP Proxy 52 before controlling the firewalls for the opening of said communication port.
  • the calling contact comes from the example.com domain , and the proxy that forwarded the request comes from the pirate.com domain . It is therefore reasonable to consider that the request is dangerous.
  • the verification procedure of the incoming call Upon receipt of the INVITE request, the verification procedure of the incoming call must verify that the call has followed a consistent path to reach the SIP Proxy 52 of the company. It is then necessary to verify that a call is in progress on the other Proxy. Since this functionality is not directly implemented in SIP, it is necessary to go through a proprietary dialogue phase between the two Proxies (companies A and B).
  • This check validates the supervisor 68 opening the communication ports on the firewalls for this call.
  • a first step is to retrieve the remote proxy certificate (1). Then, the certificate of the another.com remote domain is checked : Proxy 52 issues (2) another.com certificate request to a certificate server.
  • a SIP call is in progress between two people, one from company A and the other from company B.
  • a "BYE" message arrives at Proxy A with the source poste-b1@societe-b.com.
  • the A 52 Proxy looks at first that the path taken by the message is consistent. If this is the case, Proxy 52 asks its DNS server which is the Proxy that manages the domain societe-b.com. Then he asks this Proxy if he has issued a BYE request for the offending call. Finally, a check of the criteria allowing the entry in the zone in question is carried out.
  • the company's security policy therefore corresponds to defining the level of security required to enter a given zone. To qualify this, matrices such as the one below are used:
  • These matrices are to be defined by the user and form the basis of the company's security policy. These matrices thus defined, it will be possible to define the actions to be generated according to the various cases that may arise, for example calls not having a high enough level to reach the requested area.
  • the security policy makes it possible to define whether the requests "REINVITE" are authorized or not and if yes in which security zone they are.
  • the security policy implemented by the supervisor 68 will define whether the messages "3x" x are allowed or not and if so in which security zone it is. We also define if it is possible to divert calls to the outside (case of a different domain, a different location ). This information is contained in the supervisor's security rules 68.
  • a harassment attack is very easy to achieve in an IP telephony architecture. It can almost be likened to the problem of spam (spam) in the case of emails.
  • This data allows the supervisor 68 to refuse harassing-type calls that come from a single and same source. If the source is diversified, we must wait to know the different sources of attacks before we can block them all.
  • a response alternative is to divert to an operator or to the messenger during a given period, all calls arriving to a target, as soon as a harassing call is detected on a set.
  • a denial of service attack directed to Proxy 52 will try to generate too much traffic to be handled by the SIP architecture. For this, a number of attacks are possible each attacking a particular feature of the proxy.
  • a dedicated IDS 70 probe ToIP Telephony over IP
  • ToIP Telephony over IP
  • a statistical calculation makes it possible to define whether the increase in the number of connections remains in normal use or not.
  • the Registrar 52 maintains the list of users currently connected and the location where they can be found in order to know at every moment a particular person is.
  • Hackers are trying to attack this particular service. Indeed, like any element of a computer installation, it has a limit in terms of processing capacity.
  • processing capacity if a large number of registration requests are generated, it is possible to saturate the memory that manages these connections; queries from real phones are no longer processed.
  • Proxy 52 limits the number of recordings from the same source address for a given time. For example, there are five "REGISTER” messages (a message used to modify Registrar 52 'data) for a period of one minute.
  • the media stream that carries the voice is an RTP stream.
  • This flow evolves continuously and does not cross the Proxy.
  • the RTP flood attack consists of inserting additional streams to those logically contained in the RTP packets in order to disrupt the reception of the stream.

Landscapes

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

Description

  • La présente invention se rapporte au domaine de la voix sur IP (Internet Protocol).
  • La présente invention concerne plus particulièrement un système et un procédé pour sécuriser la téléphonie sur IP. L'invention concerne aussi bien la sécurisation des appels lors de leur établissement et leur vie que la sécurisation des infrastructures du réseau accueillant la téléphonie sur IP.
  • En référence à la figure 1, le contexte de téléphonie sur IP (ToIP) pure se base sur l'existence d'un seul lien entre les sociétés A et B de type réseau en mode paquets, par exemple Internet. Tous les appels entre ces deux sociétés passent donc par ce réseau.
  • La téléphonie en général met en oeuvre deux flux de données : l'un concerne la signalisation pour l'établissement et la gestion des appels, l'autre concerne le flux média de données à proprement parler, par exemple la voix. À l'heure actuelle, le standard émergeant pour la signalisation de la ToIP est SIP (Session Initiation Protocol), protocole de bas niveau servant à initialiser les sessions de communication entre les utilisateurs. On connaît également d'autres protocoles de signalisation comme H.323, MGCP (Media Gateway Control Protocol), SS7 (Signalling System N°7), ...
  • Le poste A1 est dans la société A, il utilise un téléphone SIP et est derrière un Proxy SIP qui gère les connexions. Toutes les connexions depuis les téléphones de la société A sortent par la connexion Internet dédiée à la téléphonie ; le poste B1 est dans la société B, utilise un téléphone SIP et est derrière un Proxy SIP qui gère les connexions. Toutes les connexions depuis les téléphones de la société B sortent par la connexion Internet dédiée à la téléphonie.
  • La figure 2 illustre l'établissement d'un appel entre A1 et B1 pour un protocole SIP standard.
  • A1 décroche son téléphone et émets un appel en direction de B1. Cela a pour effet d'émettre un message de type INVITE depuis le poste A1 en direction du Proxy de la société A. Le Proxy A prend en compte la requête de A1. Comme la demande concerne une zone qui n'est pas gérée par le Proxy A, le Proxy A consulte un serveur de localisation pour obtenir plus d'information sur la zone cible, à savoir le Proxy concerné (Proxy B). Il transmet alors au Proxy B, la requête INVITE.
  • Pendant ce temps, le Proxy A envoie un message TRYING à A1 pour le prévenir que sa demande a bien été prise en compte.
  • Le Proxy B ayant reçu la requête du Proxy A la transmet à B1. Pendant ce temps-là, le Proxy B envoie un message TRYING au Proxy A pour le prévenir que la requête est bien prise en compte.
  • Le poste de B1 a reçu la demande d'appel, et réponds par un message RINGING vers le Proxy de B, lequel propage cette information au Proxy A qui le transmet à son tour au poste A1.
  • Lorsque l'abonné B1 décroche l'appel, son poste envoie un message OK au Proxy B, lequel le transmet au Proxy A, qui à son tour le transmet au poste A1.
  • La session de l'appel est alors pleinement établie. Le poste A1 émet un message d'acquittement ACK dirigé vers le poste B1.
  • Une fois que cet échange SIP a établi l'appel, la main est donnée à un protocole tiers pour le transport du média (voix, vidéo, ...). L'art antérieur connaît plusieurs protocoles tiers dont le plus connu est RTP (Real-time Transport Protocol).
  • La coexistence d'une téléphonie traditionnelle (réseau commuté) avec une téléphonie sur IP conduit à une convergence des deux types de réseau. En référence à la figure 3, durant la période de migration de la téléphonie vers la téléphonie sur IP, les deux réseaux vont cohabiter. Les entreprises disposent alors d'un double accès, l'un au réseau commuté (PSTN - Public Switched Telephone Network) et l'autre au réseau en mode paquets (IP).
  • Les risques qui résultent d'une telle installation sont donc la combinaison des :
    • risques liés à la téléphonie classique ;
    • risques liés à la téléphonie sur IP ;
    • risques liés à la convergence des deux technologies.
  • Durant cette période de cohabitation téléphonie classique-téléphonie en mode paquets, il sera donc très important d'apporter une solution répondant aux différentes problématiques.
  • Un certain nombre de risques sur les appels en téléphonie sur IP a pu être identifié, par exemple :
    • garantir l'appel en cours ;
    • le déni de service (DoS - Deny of service) : coupure de communication, modification des caractéristiques de l'appel, harcèlement, attaque sur le proxy, ... ;
    • la déviation d'appel ;
    • le dépassement de débit (overflow) des données média ;
  • L'art antérieur propose déjà quelques solutions.
  • Entre autres, on connaît, par la demande de brevet US 6 865 681 (Nokia), un terminal de voix sur IP comprenant un module de gestion de sécurité qui reçoit des paramètres d'authentification des appels, et transmet à la pile de gestion du protocole de signalisation l'autorisation d'établir ces appels. Cette architecture est orientée poste client (téléphones) et à ce titre n'implémente que des mécanismes de sécurité à leur niveau. Cette solution ne répond pas à une optique de contrôle de sécurité sur la globalité d'une infrastructure, postes clients et serveurs compris.
  • L'art antérieur connaît également, par la demande de brevet WO 01 / 08 377 , une solution de sécurisation des connexions d'appels pour voix sur IP dans laquelle les échanges entre les passerelles des différents réseaux internes s'effectuent de façon cryptée après un échange initial de certificat numérique et de clés. Cette solution est figée en ce qu'elle ne vise qu'à sécuriser les données échangées afin d'éviter toute utilisation de celles-ci par une personne malveillante. Cette solution est limitée en ce qu'elle est statique et ne peut tenir compte de nouvelles attaques. On note que cette solution n'est pas dotée d'une approche comportementale pour laquelle des données analysées conduisent à prendre une décision sécuritaire. Une telle approche comportementale apparaît avantageuse car elle permet une évolution et une mise à jour aisées de la sécurité de l'architecture.
  • L'art antérieur connaît également, par la demande de brevet US 2005 / 27 985 , un système et un procédé sécurisant les connexions par des méthodes cryptologiques entre les différents acteurs. La solution est basée sur l'utilisation de clés d'encryptage pour toutes les communications passées entre différents équipements du système. Bien que cette solution sécurise les données pour qu'elles ne puissent pas être exploitées par un intercepteur, elle ne permet pas de faire face à de nombreuses attaques, par exemple celles de type déni de service pour lesquelles un apprentissage et une approche comportementale semblent plus adaptés.
  • Le document US 2004/255156 décrit un système pour la sécurisation de la téléphonie sur un réseau interne en mode paquets connecté à un réseau externe. Ce système permet de créer de manière dynamique au moins un trou d'épingle dans un pare-feu. Le système de communications comporte un noeud protégé capable de lancer une session de communications avec un noeud extérieur. A cet égard, le noeud protégé peut recevoir des paramètres de débit concernant la session de communications lorsque celle-ci est installée. Le système comporte également un pare-feu placé le long du chemin de communications entre le noeud protégé et le noeud extérieur.
  • La présente invention entend remédier aux inconvénients de l'art antérieur en proposant un système et un procédé pour sécuriser la téléphonie sur IP. L'invention repose sur l'utilisation d'un superviseur de sécurité à l'intérieur d'une zone démilitarisée, lequel superviseur utilise les données du réseau fournies par des équipements dédiés soit à la téléphonie sur IP (Proxy SIP) soit à la détection de paquets ou données suspects sur le réseau (sonde de détection) et en les comparant à des règles de sécurité afin d'adapter de façon adéquate le comportement des équipements de protection. L'utilisation d'un superviseur central et indépendant dans la gestion du transfert de données et notamment de la téléphonie sur IP, offre une gestion plus aisée de la sécurité, notamment en permettant que celle-ci soit dynamique par l'utilisation de systèmes experts auto-apprenants.
  • L'invention ne consiste pas en un simple pilotage dans l'ouverture/fermeture de ports de pare-feux, mais dans une gestion plus complexe de la sécurité des appels par voix sur IP.
  • Le procédé selon la présente invention répond particulièrement bien aux besoins des entreprises pour lesquels la sécurisation des appels mais aussi des infrastructures du réseau IP sont de premier ordre.
  • À cet effet, l'invention concerne dans son acception la plus générale un système pour la sécurisation de la téléphonie sur un réseau interne en mode paquets connecté à un réseau externe, le système comprenant un pare-feu et un Proxy traitant la signalisation d'appels, tous deux connectés audit réseau interne, caractérisé en ce qu'il comprend, en outre, un superviseur de sécurité connecté audit Proxy et apte à commander ledit pare-feu en réponse à des données transmises par le Proxy.
  • Dans un mode de réalisation, ledit superviseur comprend une base de données renseignant des règles de sécurité à appliquer audit réseau et des moyens logiciels pour confronter lesdites données reçues aux dites règles de sécurité.
  • Dans un autre mode de réalisation, ledit superviseur commande l'ouverture et la fermeture des ports dudit pare-feu.
  • Dans un mode de réalisation particulier, le système comprend, en outre, une sonde IDS connectée au réseau et fournissant des données audit superviseur.
  • Particulièrement, ladite sonde IDS est dédiée pour la ToIP et remonte audit superviseur les données contenues dans les paquets de signalisation.
  • Eventuellement, ladite sonde IDS est dédiée pour l'analyse du flux de média et remonte audit superviseur uniquement des informations sur le flux média détecté.
  • Dans un mode de réalisation, ledit réseau en mode paquets est un réseau IP et les protocoles de téléphonie sont le SIP pour la signalisation et le RTP pour le flux média.
  • Particulièrement, ledit Proxy comprend des moyens logiciels aptes à remonter des informations sur la signalisation d'appel au superviseur.
  • Précisément, le système peut comprendre un deuxième pare-feu connecté audit réseau en mode paquets, l'ensemble des deux pare-feux constituant une zone démilitarisée entre le réseau interne et le réseau externe, ledit superviseur commandant également ledit deuxième pare-feu.
  • Dans un mode de réalisation particulier, ledit réseau externe est un réseau de téléphonie en mode commuté comprenant un autocommutateur, lequel autocommutateur transmet au superviseur des données sur les appels transitant par l'autocommutateur.
  • Dans un autre mode de réalisation, le système comprend deux sondes IDS à l'intérieur de la zone démilitarisée, les deux sondes étant connectées audit superviseur et associées chacune à un pare-feu.
  • L'invention concerne également une architecture comprenant un réseau interne en mode paquet relié à un réseau externe par un système de sécurisation selon l'une quelconque des revendications précédentes, et un ensemble de téléphones sur ledit réseau interne, dans laquelle ledit ensemble de téléphones est constitué d'au moins deux sous-ensemble et, lors d'un appel vers ou depuis un desdits téléphones, ledit superviseur tient compte du sous-ensemble d'appartenance du téléphone dans la détermination de la réponse à apporter.
  • L'invention concerne également une architecture comprenant une pluralité de réseaux internes en mode paquets reliés entre eux par un réseau externe, chaque réseau interne comprenant un système de sécurisation décrit précédemment.
  • Dans un mode de réalisation, l'architecture comprend, en outre, un serveur de certificats relié audit réseau externe, et en ce que la signalisation transmise entre deux Proxy est un canal sécurisé négocié.
  • L'invention concerne également un procédé de sécurisation de la téléphonie sur un réseau en mode paquets comprenant un système de sécurisation décrit précédemment, ledit procédé comprenant une étape de transmission des données du Proxy vers ledit superviseur, une étape de confrontation, par le superviseur, desdites données avec des règles de sécurité contenues dans le superviseur et de détermination d'une réponse adaptée, une étape de commande par le superviseur du pare-feu pour appliquer ladite réponse.
  • On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées :
    • la figure 1 illustre le contexte de la téléphonie sur IP de l'art antérieur ;
    • la figure 2 représente les échanges lors de l'établissement d'un appel dans le contexte de téléphonie de la figure 1 ;
    • la figure 3 illustre le contexte de réseau convergé de l'art antérieur ;
    • la figure 4 représente un mode de réalisation de l'architecture de la présente invention ; et
    • les figures 5 et 6 illustrent deux exemples de politique sécuritaire mises en oeuvre dans le mode de réalisation de la figure 4.
  • Dans le mode de réalisation non limitatif de la description, le protocole de signalisation utilisé pour la voix sur IP est le SIP tandis que le protocole de flux media est le RTP.
  • En référence à la figure 4, la société A est reliée à la fois au réseau numérique Internet et au réseau téléphonique public commuté (PSTN) et possède un réseau interne commuté 40 et un réseau IP 50, les deux réseaux étant connectés entre eux.
  • Le réseau commuté 40 de l'entreprise comprend une passerelle 42 (media gateway) vers le réseau IP 50, cette passerelle réalisant la conversion des données du format de l'un des réseaux dans le format de l'autre : du media en mode commuté sur RNIS dans le format RTP pour le réseau IP. Le réseau commuté 40 comprend également une pluralité de téléphones 44 « classiques » connectés au réseau 40. Une communication provenant du réseau commuté PSTN à destination d'un poste « classique » 44 transite via la passerelle 42. Une solution de sécurisation d'un tel réseau commuté a été proposée dans la demande de brevet FR04/52361 . Dans cette solution, est proposée la sécurisation de l'autocommutateur d'entreprise : un serveur de sécurisation récupère des données de commutation depuis l'autocommutateur, les confronte à des règles sécuritaires et commande, en fonction de ces dernières, un pare-feu pour neutraliser d'éventuelles attaques. Dans le cadre de la présente invention, la passerelle 42 est entendue comme incluant les moyens de commutation (autocommutateur) et des moyens de mise en oeuvre d'une politique sécuritaire conformément à la demande de brevet FR04/52361 .
  • L'intégration des sondes TDM (time division multiplexing - réseau commuté) permet la convergence des données et informations depuis le réseau téléphonique classique. On pourra ainsi détecter les tentatives d'attaques croisées TDM / IP visant à saturer les lignes disponibles. Le système de pare-feu temps réel comme décrit dans la demande de brevet FR04/52361 sera réutilisé pour permettre de gérer les risques spécifiques à l'utilisation d'un réseau commuté.
  • Les systèmes d'audit des applicatifs PABX décrits dans la demande de brevet FR04/52361 seront réutilisés pour permettre de gérer les risques liés à la fois à la téléphonie classique mais également à la téléphonie sur IP. Les applicatifs seront audités afin de permettre de déterminer les dangers potentiels liés à ces configurations.
  • Dans le cas d'un appel en provenance (à destination) du réseau PSTN et à destination (provenance) d'un poste téléphonique IP du réseau IP 50, l'appel transite via la passerelle 42, est converti dans le bon format puis est transmis au réseau IP 50.
  • Pour la mise en oeuvre de la téléphonie sur IP, le réseau IP 50 comporte un Proxy SIP 52 et un ensemble de postes téléphones SIP 54 sur le réseau interne IP 56 de l'entreprise. Lorsqu'un appel s'établit, la partie signalisation est traitée par le Proxy SIP 52, puis le flux media est établi sur le réseau IP jusqu'au poste SIP 54 concerné. Le Proxy SIP 52 peut intégrer directement les fonctions de Registrar 52' (enregistre les adresses des postes SIP afin de permettre la localisation de ceux-ci ; utilisé en cas de portabilité de poste pour une même personne) et de serveur d'authentification 52".
  • Pour la présente invention, le réseau IP 50 comprend une zone démilitarisée 60 en frontal (directement reliée) du réseau externe Internet. Cette zone démilitarisée est reliée aux trois réseaux : externe Internet, interne commuté 40 via la passerelle et interne IP 56.
  • Cette zone démilitarisée 60 comprend un pare-feu pour chaque liaison avec un réseau externe à la zone :
    • Pare-feu 62 vers le réseau externe Internet ;
    • Pare-feu 64 vers le réseau interne IP 56 ;
    • Pare-feu 66 vers le réseau commuté 40.
  • Les pare-feux sont implémentés de façon logicielle sur des postes informatiques et permettent de contrôler les échanges de paquets IP en ouvrant ou fermant des ports de communication.
  • Un superviseur de sécurité 68 est également fourni dans la zone démilitarisée 60. Ce superviseur 68 est relié au réseau 50 et peut commander/piloter les pare-feux 62, 64 et 66. Des sondes de détection d'intrusion 70 et 72 et un pare-feu voix 74 sont également intégrées au réseau IP 50 dans la zone démilitarisée et fournissent des informations au superviseur 68.
  • Les sondes de détection d'intrusion 70 et 72 analysent l'entête SIP et le corps des messages SIP. À partir de ces données, elles définissent un contexte d'appel qui permet de définir si le paquet est autorisé dans le contexte courant de l'appel.
  • Ce contexte d'appel est corrélé sur les différentes sondes à travers le superviseur afin que chaque élément de bordure connaisse les contextes des différents appels en cours.
  • Lors de l'établissement d'un appel, les paquets de signalisation SIP transmis sont reçus par le Proxy SIP 52. Le Proxy 52 est l'élément principal d'une architecture de téléphonie sur IP. A ce titre, il intervient dans l'établissement de toutes les communications. Afin de pouvoir se prémunir contre diverses attaques, on récupère un certain nombre d'informations dans celui-ci pour les transmettre au superviseur 68. Le Proxy 52 intègre donc une couche logicielle supplémentaire à celle habituelle dans ces infrastructures, la nouvelle couche logicielle permettant de mettre à disposition ces informations au superviseur de sécurité 68. Dans certains cas d'attaque, par exemple les attaques dirigées vers le Proxy, il est intéressant que ce soit le Proxy qui réagisse en plus des pare-feux. Le Proxy 68 doit donc pouvoir passer en mode « sécurité » en cas d'attaque massive afin de sauvegarder l'intégrité des communications déjà établies : la couche logicielle comprend alors des règles sécuritaires statiques (par exemple sous forme de paramètres de configuration) qui pourront être appliquées directement sans intervention du superviseur 68.
  • Les données de signalisation SIP sont également récupérées par les sondes IDS 70 et 72 ou le pare-feu voix 74 qui transmettent le contenu des paquets SIP au superviseur 68. Le pare-feu voix 74 s'occupe de la sécurité de la partie réseau commuté. Pour cela il utilise les données recueillies par la sonde TDM et coupe au besoin les communications sur la Media Gateway 42. Dans le cas où un appel passe à travers les deux réseaux (commuté vers IP et IP vers commuté) l'action de sécurité sera menée au niveau du firewall 66 depuis le serveur de supervision 68. Le pare-feu 74 se synchronise avec le superviseur de sécurité avant chaque action afin de permettre qu'une seule demande de coupure soit effectuée soit au niveau des firewall 66/64/62 soit au niveau de la Media Gateway 42 si la communication passe à travers ces deux équipements.
  • Le superviseur 68 reçoit des informations du Proxy SIP 52, de la passerelle 42 (ou du superviseur de sécurité du réseau commuté comme mentionné précédemment) et éventuellement de sondes de détection d'intrusion 70 et 72, et du pare-feu voix 74. Le superviseur 68 comporte des règles de sécurité dans une base de données ainsi qu'un module de traitement qui confronte les données reçues aux règles. Une description plus précise d'un tel superviseur est fournie dans la demande de brevet FR04/52361 , dans laquelle l'homme du métier pourra convertir aisément les informations concernant la téléphonie en mode commuté à la téléphonie sur IP. Comme décrit dans la demande FR04/52361 , le superviseur 68 comprend éventuellement un système permettant l'apprentissage de règles de sécurité en fonction de scenarii possibles d'appels. Ce système peut être un système expert.
  • La réception d'un message INVITE par la sonde du Proxy du domaine protégé se fait par exemple comme suit : 
     INVITE sip:bob@biloxi.example.com SIP/2.0
  Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
  Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   ;received=192.0.2.101
  Max-Forwards: 69
  Record-Route: <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
  CSeq: 1 INVITE
   Contact: <sip:alice@client.atlanta.example.com>
   Content-Type: application/sdp
   Content-Length: 151
   v=0
   o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
   s=-
   c=IN IP4 192.0.2.101
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
  • L' extraction des données utiles se fait par exemple comme suit: 
    •  MSG TYPE : INVITE
 VIA LIST : ss1.atlanta.example.com;client.atlanta.example.com
 FROM : sip:alice@atlanta.example.com
 TO : sip:bob@biloxi.example.com
 CID : 2xTb9vxSit55XU7p8@atlanta.example.com
 IP : 192.0.2.101
 PORT : 49172
 TYPE : AUDIO
 AUDIO_TYPE : PCMU
  • La règle suivante peut par exemple être appliquée : 
    •      SI : Sur une communication arrivant (INVITE)
    le CODEC est interdit sur le lien
    ALORS : Refuser le paquet
      Mettre a jour les données de session sur le proxy
      Demander au firewall de fermer les ports dynamiques de cette
      communication
  • Une autre règle possible après établissement de la communication est décrite ci-dessous : 
    •  SI : Sur une communication (CID, FROM, TO) en cours
         un paquet type BYE arrive avec VIA LIST <> de celle du
         paquet INVITE
         ALORS : Refuser le paquet
          Demander au pare feu de bannir l'IP du proxy attaquant.
  • Également, intégré ou non au superviseur 68, un superviseur d'audit permet d'analyser les fonctionnalités du Proxy 52 et des terminaux 54 ainsi que l'architecture du système pour la mise en service de la téléphonie sur IP. Cette analyse permet au superviseur d'audit d'établir des scenarii d'appels qui seront pris en compte par le superviseur 68 pour l'établissement des règles de sécurité.
  • Par ce traitement sur les données reçues, le superviseur 68 supervise le déroulement des communications et pilote, à des fins sécuritaires, les ouvertures et fermetures de port sur les pare-feux 62, 64 et 66. En cas d'intervention sur l'un des pare-feux, par exemple fermeture d'une communication, le superviseur 68 informe le Proxy 52 de cette intervention afin que celui-ci mette à jour ses données par exemple la liste des communications en cours dans le cas d'un Proxy « statefull » (qui mémorise un contexte lié à un utilisateur). Eventuellement, le superviseur informe également la partie commuté (passerelle 42) afin d'informer l'autocommutateur de la fin d'un appel si ce dernier transite par la passerelle pour récupérer les ressources qui ont été attribuées à cet appel.
  • Voici maintenant quelques mécanismes de sécurisation mis en oeuvre par le superviseur 68 et le Proxy 52.
    • Ouverture dynamique des ports media
  • En fonctionnement, la téléphonie sur IP utilise des ports choisis dynamiquement pour faire passer les flux de média RTP. Pour des raisons de sécurité, ces ports ne doivent pas être ouverts en permanence mais dynamiquement lorsqu'une communication se présente. L'information concernant les ports à ouvrir est contenue dans le corps du message SIP. Le superviseur de sécurité 68 ira donc chercher l'information du port à ouvrir dans le Proxy SIP 52 avant de piloter les pare-feux pour l'ouverture dudit port de communication.
    • Garantir la provenance de l'appelant
  • Le message SIP arrivant au Proxy à la forme : 
    •      INVITE sip:callee@domain.com SIP/2.0
     Contact: sip:caller@u1.example.com
     Record-Route: <sip:p1.example.com;1r>
  • On peut déduire de cette présentation que l'appel a été routé à travers un Proxy : le Proxy p1 de example.com. Le contact appelant provient également du domaine example.com. On peut considérer comme invariant dans le système SIP qu'un appel provenant d'un domaine A provienne d'un Proxy SIP de la même société A.
  • Par exemple un appel SIP comme suit arrivant au Proxy de domain.com : 
    •      INVITE sip:callee@domain.com SIP/2.0
     Contact: sip:caller@u1.example.com
     Record-Route: <sip:p1.pirate.com;lr>
  • Le contact appelant provient du domaine example.com, et le Proxy qui a transmis la requête provient du domaine pirate.com. On peut donc raisonnablement considérer que la requête est dangereuse.
  • Le superviseur 68 veillera alors à :
    • la vérification de la cohérence des Record-Route par rapport au domaine de l'appelant,
    • la vérification de l'existence d'un Proxy SIP sur la dernière adresse Record-Route.
  • En cas d'incohérence ou d'inexistence, le superviseur interdira l'appel et fermera les ports associés au niveau des pare-feux.
    • Garantir l'appel en cours
  • A réception de la requête INVITE, la démarche de vérification de l'appel entrant doit permet de vérifier que l'appel a bien suivi un chemin cohérent pour atteindre le Proxy SIP 52 de l'entreprise. Il convient alors de vérifier qu'un appel est bien en cours sur l'autre Proxy. Cette fonctionnalité n'étant pas directement implémentée dans SIP, il faut passer par une phase de dialogue propriétaire entre les deux Proxy (des entreprises A et B).
  • En référence à la figure 5, lorsqu'un appel arrive (1) sur le Proxy 52 du domaine domain.com, la requête provenant du domaine another.com, le Proxy SIP 52 lance (2) une requête DNS afin de découvrir le Proxy SIP qui gère le domaine de l'appelant (another.com).
  • Après avoir découvert l'adresse du Proxy another.com qui gère le domaine de l'appelant, par retour du serveur DNS, une requête est envoyée (3) par le Proxy SIP 52 vers le Proxy découvert en dialogue propriétaire afin de récupérer le CALL-ID correspondant à la personne ayant appelé. Les informations transmises dans cette requête sont :
    • Chemin pour envoyer la réponse ;
    • Identifiant de la personne appelante.
  • À réception de la requête, le Proxy another.com qui gère le domaine another. com envoie (4) la réponse à cette requête et clos le dialogue propriétaire. La réponse contient les informations suivantes :
    • Présence ou non d'un(des) appel(s) pour la personne indiquée ;
    • Liste des CALL-ID des communications en cours.
  • Cette vérification permet de valider au superviseur 68 l'ouverture des ports de communication sur les pare-feux pour cet appel.
    • Sécuriser le dialogue
  • Afin de fournir un haut niveau de sécurité, les dialogues propriétaires effectués précédemment doivent être faits à travers un média sécurisé. Pour cela, il est prévu d'utiliser les fonctionnalités SSL pour crypter le canal de communication. Chaque Proxy 52 sécurisé devra faire l'acquisition d'un certificat SSL afin de permettre le bon fonctionnement de cette fonctionnalité.
  • Une première étape consiste en la récupération du certificat du Proxy distant (1). Ensuite, on procède à la vérification du certificat dont fait état le domaine distant another.com : le Proxy 52 émet (2) une requête de demande de certificat another.com vers un serveur de certificats.
  • Ensuite, on négocie un canal sécurisé grâce aux clés de sessions générées précédemment (par les certificats). L'ensemble du dialogue propriétaire peut alors s'effectuer au travers de ce média en toute sécurité.
  • Éventuellement, on pourra réutiliser les certificats SSL déjà utilisés par certains Proxy SIP.
    • Sécuriser contre le déni de service DoS « BYE » de coupure de communication
  • L'un des principaux problèmes de l'utilisation de SIP est qu'une personne mal intentionnée (reliée au réseau Externe / Interne) peut envoyer des ordres de coupures sur les communications. Les attaques les plus simples consistent à envoyer un ordre de fin de communication (« BYE » ...) afin de demander la fermeture de la communication.
  • Pour se prémunir de ce genre d'attaque, un certain nombre de vérifications doivent être faites sur le message arrivant pour garantir qui en est l'émetteur :
    • Vérifier la cohérence du chemin emprunté ;
    • Vérification de l'émetteur du message ;
    • Critères cohérents pour entrer dans la zone de sécurité demandée.
  • Par exemple, une communication SIP est en cours entre deux personnes, une depuis la société A et l'autre depuis la société B. Un message « BYE » arrive au Proxy A avec comme provenance poste-b1@societe-b.com.
  • Le Proxy A 52 regarde dans un premier temps que le chemin emprunté par le message est cohérent. Si c'est le cas, le Proxy 52 demande à son serveur DNS quel est le Proxy qui gère le domaine societe-b.com. Ensuite il demande à ce Proxy s'il a bien émis une requête de type BYE pour l'appel incriminé. Pour finir, une vérification des critères permettant l'entrée dans la zone en question est effectuée.
    • Notion de zones
  • Dans une entreprise, tous les postes n'ont pas forcément les mêmes besoins en terme de sécurité. Par exemple, le poste d'un directeur est plus problématique que celui d'un chef de projet, qui est lui-même plus problématique que celui d'une secrétaire.
  • Pour répondre à ce problème, il est prévu, dans la présente invention, de créer des niveaux de sécurité pour qualifier le niveau de sûreté des appels entrants et sortants. Ainsi sont créées des zones de sécurité qui classent les postes suivant la criticité qu'ils représentent. Les niveaux de sécurité proposés par défaut seront :
    • Faible ;
    • Normale ;
    • Maximum.
  • Les zones de sécurité proposées par défaut sont :
    • Normale ;
    • Critique ;
    • Hautement critique.
  • La politique de sécurité de l'entreprise correspond donc à définir le niveau de sécurité requis pour entrer dans une zone donnée. Pour qualifier cela, des matrices telles que celle ci-dessous sont utilisées :
    Figure imgb0001
    Figure imgb0002
  • Ces matrices sont à définir par l'utilisateur et constituent la base de la politique de sécurité de l'entreprise. Ces matrices ainsi définies, on pourra définir les actions à engendrer suivant les différents cas de figure qui pourront se présenter, par exemple les appels n'ayant pas un assez haut niveau afin d'atteindre la zone demandée.
  • Appels n'ayant pas un niveau suffisant pour atteindre leur destinataire :
    • Dévier vers l'opératrice de la zone concernée ;
    • Envoyer sur la messagerie vocale de la personne ;
    • Faire des déviations spécifiques (Patron /Secrétaire) ;
    • Refuser l'appel ;
    • Lecture d'un message explicatif.
    Sécuriser contre le déni de service DoS « REINVITE »
  • De la même façon qu'un pirate peut envoyer des messages pour couper les communications en cours, il peut envoyer un message « REINVITE » afin de modifier les caractéristiques de la communication en cours de route. Il peut par exemple passer le type de communication d'audio à vidéo ou autre ...
  • On appliquera les mêmes critères que précédemment pour vérifier que le message émane bien de la personne qui est en cours de communication :
    • Cohérence du chemin emprunté ;
    • Vérification de l'émetteur du message ;
    • Critères cohérents pour entrer dans la zone de sécurité demandée.
  • La politique de sécurité permet de définir si les requêtes « REINVITE » sont autorisées ou non et si oui dans quelle zone de sécurité elles le sont.
    • Éviter la déviation d'appel
  • Lors de la réception d'un message « INVITE » pour démarrer un appel, il est possible d'envoyer un message dit « 3xx » pour signaler que l'appelé est joignable à un autre endroit. Cette fonction peut-être détournée par des pirates afin d'intercepter des appels et de les rediriger vers d'autres postes.
  • La politique de sécurité mise en oeuvre par le superviseur 68 permettra de définir si les messages « 3x »x sont autorisés ou non et si oui dans quelle zone de sécurité il le sont. On définit également s'il est possible de dérouter des appels vers l'extérieur (cas d'un domaine différent, d'une localisation différente ...). Ces informations sont contenues dans les règles de sécurité du superviseur 68.
    • Sécuriser contre le déni de service DoS de harcèlement
  • Une attaque de harcèlement est très facile à réaliser dans une architecture de téléphonie sur IP. On peut presque l'assimiler au problème du spam (pourriel) dans le cas des mails.
  • Pour résoudre ce problème on effectue un calcul statistique sur :
    • le nombre d'appel arrivant sur une période ;
    • le temps de repos entre deux appels ;
    • la provenance des appels.
  • Ces données permettent au superviseur 68 de refuser les appels de type harcèlement qui proviennent d'une seule et même source. Si la source est diversifiée, il faut attendre de connaître les différentes sources d'attaques avant de pouvoir toutes les bloquer.
  • Une alternative de réaction consiste à dévier vers une opératrice ou vers la messagerie pendant une période donnée, tous les appels arrivant vers une cible, dès qu'un appel de harcèlement est détecté sur un poste.
    • Sécuriser contre le déni de service DoS sur le Proxy
  • Une attaque de déni de service dirigée vers le Proxy 52 va essayer de générer un trafic trop important pour être géré par l'architecture SIP. Pour cela, un certain nombre d'attaques sont possibles s'attaquant chacune à une fonctionnalité particulière du Proxy.
  • Les schémas de détection de l'attaque peuvent être :
    • Grand nombre d'ouverture de connexion ;
    • Appels générés vers des utilisateurs n'existant pas ;
  • Pour se prémunir de ce genre d'attaque, une sonde IDS 70 dédiée ToIP (Telephony over IP) est placée en amont du Proxy 52. L'IDS 70 associé au superviseur 68 permet de détecter un accroissement anormal des communications dirigées vers des utilisateurs n'existant pas ou selon d'autres critères.
  • Eventuellement, un calcul statistique permet de définir si l'accroissement du nombre de connexions reste dans l'utilisation normale ou non.
    • Sécuriser contre le déni de service DoS sur le Registrar
  • Comme précisé précédemment, le Registrar 52' maintient la liste des utilisateurs actuellement connectés et l'emplacement où l'on peut les trouver afin de savoir à chaque instant où se trouve une personne donnée. Les pirates tentent d'attaquer ce service en particulier. En effet, comme n'importe quel élément d'une installation informatique, celui-ci à une limite en terme de capacité de traitement. Ainsi si l'on génère un grand nombre de demandes d'enregistrement, on peut arriver à saturer la mémoire qui gère ces connexions ; les requêtes provenant de téléphones réels ne sont alors plus traitées.
  • La sécurisation consiste à ce que le Proxy 52 limite le nombre d'enregistrement provenant d'une même adresse source pendant un temps donné. Par exemple, on limite à cinq messages « REGISTER » (message utilisé pour modifier les données du Registrar 52') pour une période d'une minute.
    • Sécuriser contre l'overflow du flux media (Flood RTP)
  • Dans le cas où une communication est établie, le flux de média qui transporte la voix est un flux RTP. Ce flux évolue en continue et ne traverse pas le Proxy. L'attaque par flood RTP consiste à insérer des flux supplémentaires à ceux qui sont logiquement contenus dans les paquets RTP afin de perturber la réception du flux.
  • Pour se prémunir contre une telle attaque, on placera une sonde IDS 72 sur le trajet du flux média. Cette sonde IDS remonte au superviseur 68 des données sur la taille des paquets RTP qui transitent et l'ordre d'arrivée des paquets. L'analyse temporelle de ces paquets et donc du flux média permet de définir si la taille du flux et l'enchaînement des paquets sont bien corrélés avec le codec (algorithme de codage) utilisé pour encoder la voix. En cas d'incohérence, le superviseur 68 commande la fermeture de l'appel. En effet, pour chaque codec on peut définir une taille normale de données échangées sur une période donnée, par exemple 64 kbit/s pour G711 ainsi qu'un ordre logique d'arrivée des paquets. En laissant une marge de sécurité autour de ces valeurs, on peut donc détecter l'insertion de flux malicieux à l'intérieur du flux RTP.

    • Claims (11)

    1. Système de sécurisation de la téléphonie sur un réseau interne (56) en mode paquets connecté à un réseau externe, le système comprenant un pare-feu (62 ;66) et un proxy (52) traitant des données de signalisation d'appels,
      tous deux connectés audit réseau interne (56), caractérisé en ce que le pare-feu (62 ; 66) et le proxy (52) font partie d'une zone démilitarisée (60) entre le réseau interne (56)en mode paquet et le réseau externe en ce que le système comprend, en outre, au moins une sonde IDS (70, 72), système de détection d'intrusion, disposée sur le flux de données du réseau et apte à traiter des données transitant sur ledit réseau interne, et un superviseur de sécurité (68) connecté audit réseau interne (56), ledit superviseur de sécurité (68) comprenant une pluralité de règles de sécurité, et en ce que ledit superviseur de sécurité (68) est apte à recevoir des données de signalisation d'appels traitées par ledit proxy (52) et des données de flux traitées par ladite sonde IDS (70,72), à appliquer lesdites règles aux données traitées reçues et à commander ledit pare-feu (62 ; 66) pour l'ouverture et la fermeture de ports en fonction de l'application desdites règles aux données traitées reçues.
    2. Système selon la revendication précédente, caractérisé en ce que ladite sonde IDS (70) est dédiée pour la ToIP et transmet audit superviseur (68) des données contenues dans les paquets de signalisation.
    3. Système selon la revendication 1, caractérisé en ce que ladite sonde IDS (70) est dédiée pour l'analyse du flux de média et transmet audit superviseur (68) des données relatives aux paquets du flux média détecté.
    4. Système selon la revendication 1, caractérisé en ce que ledit réseau interne (56) en mode paquets est un réseau IP et les protocoles de téléphonie sont le SIP pour la signalisation et le RTP pour le flux média.
    5. Système selon la revendication 1, caractérisé en ce que ledit proxy (52) comprend des moyens logiciels aptes à transmettre lesdites données traitées de signalisation d'appel au superviseur (68).
    6. Système selon la revendication 1, caractérisé en ce la zone démilitarisée (60) comporte un deuxième pare-feu (64) connecté audit réseau interne en mode paquets (56), ledit superviseur de sécurité (68) commandant également ledit deuxième pare-feu (64).
    7. Système selon la revendication précédente, caractérisé en ce que ledit réseau externe est un réseau de téléphonie en mode commuté comprenant un autocommutateur, lequel autocommutateur transmet au superviseur (68) des données sur les appels transitant par l'autocommutateur.
    8. Système selon la revendication 6, caractérisé en ce qu'il comprend deux sondes IDS (70, 72) à l'intérieur de la zone démilitarisée (60), les deux sondes étant connectées audit superviseur (68) et associées chacune à un pare-feu (62, 64).
    9. Architecture comprenant un réseau interne (56) en mode paquet relié à un réseau externe par un système de sécurisation selon l'une quelconque des revendications précédentes, et un ensemble de téléphones (54) sur ledit réseau interne (56), caractérisé en ce que ledit ensemble de téléphones (54) est constitué d'au moins deux sous-ensembles et en ce que, lors d'un appel vers ou depuis un desdits téléphones (54), ledit superviseur (68) tient compte du sous-ensemble d'appartenance du téléphone dans la détermination de la réponse à apporter.
    10. Architecture comprenant une pluralité de réseaux internes en mode paquets reliés entre eux par un réseau externe, chaque réseau interne comprenant un système de sécurisation selon l'une quelconque des revendications 1 à 8.
    11. Architecture selon la revendication 10, caractérisée en ce qu'elle comprend, en outre, un serveur de certificats relié audit réseau externe, et en ce que la signalisation transmise entre deux proxy est un canal sécurisé négocié.
    EP06778655A 2005-06-23 2006-06-23 Securisation de la telephonie sur ip Not-in-force EP1894350B1 (fr)

    Applications Claiming Priority (2)

    Application Number Priority Date Filing Date Title
    FR0506401A FR2887722A1 (fr) 2005-06-23 2005-06-23 Securisation de la telephonie sur ip
    PCT/FR2006/001456 WO2006136733A1 (fr) 2005-06-23 2006-06-23 Securisation de la telephonie sur ip

    Publications (2)

    Publication Number Publication Date
    EP1894350A1 EP1894350A1 (fr) 2008-03-05
    EP1894350B1 true EP1894350B1 (fr) 2013-03-20

    Family

    ID=36011148

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP06778655A Not-in-force EP1894350B1 (fr) 2005-06-23 2006-06-23 Securisation de la telephonie sur ip

    Country Status (5)

    Country Link
    US (1) US20080089494A1 (fr)
    EP (1) EP1894350B1 (fr)
    CA (1) CA2613217A1 (fr)
    FR (1) FR2887722A1 (fr)
    WO (1) WO2006136733A1 (fr)

    Families Citing this family (11)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    CN101227289A (zh) * 2008-02-02 2008-07-23 华为技术有限公司 统一威胁管理设备及威胁防御模块的加载方法
    US8325893B2 (en) * 2008-11-24 2012-12-04 Ringcentral, Inc. Click-to-call attack prevention
    KR101107742B1 (ko) * 2008-12-16 2012-01-20 한국인터넷진흥원 에스아이피(ｓｉｐ) 기반 서비스의 보호를 위한 ｓｉｐ 침입 탐지 및 대응 시스템
    US8955090B2 (en) * 2011-01-10 2015-02-10 Alcatel Lucent Session initiation protocol (SIP) firewall for IP multimedia subsystem (IMS) core
    US9332119B1 (en) * 2013-03-07 2016-05-03 Serdar Artun Danis Systems and methods for call destination authenticaiton and call forwarding detection
    US10110560B2 (en) * 2015-08-07 2018-10-23 Avaya Inc. Management for communication ports
    KR102588498B1 (ko) 2016-11-07 2023-10-12 삼성전자주식회사 통신 시스템에서 발신자를 인증하기 위한 장치 및 방법
    US10708306B2 (en) * 2017-06-15 2020-07-07 Palo Alto Networks, Inc. Mobile user identity and/or SIM-based IoT identity and application identity based security enforcement in service provider networks
    US11063990B2 (en) 2018-08-13 2021-07-13 T-Mobile Usa, Inc. Originating caller verification via insertion of an attestation parameter
    US10999443B1 (en) * 2018-11-06 2021-05-04 Dialpad, Inc. On premises gateways interconnecting VoIP systems the public switched telephone network and private branch exchanges and other telephony infrastructure
    US11277521B1 (en) 2018-11-06 2022-03-15 Dialpad, Inc. On premises gateways interconnecting VoIP systems, the public switched telephone network and private branch exchanges and other telephony infrastructure

    Family Cites Families (3)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US7100202B2 (en) * 2001-03-02 2006-08-29 Tekelec Voice firewall
    US8126722B2 (en) * 2001-12-20 2012-02-28 Verizon Business Global Llc Application infrastructure platform (AIP)
    US7340771B2 (en) * 2003-06-13 2008-03-04 Nokia Corporation System and method for dynamically creating at least one pinhole in a firewall

    Also Published As

    Publication number Publication date
    FR2887722A1 (fr) 2006-12-29
    EP1894350A1 (fr) 2008-03-05
    CA2613217A1 (fr) 2006-12-28
    WO2006136733A1 (fr) 2006-12-28
    US20080089494A1 (en) 2008-04-17

    Similar Documents

    Publication Publication Date Title
    US20120144051A1 (en) System and method for detection of data traffic on a network
    EP3545670A1 (fr) Utilisation de messages sip pour déterminer l&#39;état d&#39;un terminal distant dans des systèmes de communication voip
    EP2215755A1 (fr) Interception de contenu d&#39;appel basé sur ip au moyen de répéteurs
    US20080089494A1 (en) System and Method for Securing a Telephone System Comprising Circuit Switched and IP Data Networks
    EP1111892B1 (fr) Procédés et systèmes de surveillance d&#39;un réseau à protocole Internet
    Park Voice over IP security
    Kumar et al. Security and challenges in voice over internet protocols: A survey
    Nassar et al. VoIP honeypot architecture
    Wang et al. Voice pharming attack and the trust of VoIP
    Shan et al. Research on security mechanisms of SIP-based VoIP system
    EP1869858A2 (fr) Procede de lutte contre l&#39;envoi d&#39;information vocale non sollicitee
    Voznak et al. Threats to voice over IP communications systems
    Řezáč et al. Security risks in IP telephony
    EP3808060B1 (fr) Traitement de messages dans un réseau de voix sur ip
    Ylli et al. EXPLOITING VOIP SECURITY ISSUES IN A CLASSIC SCENARIO
    KR101379779B1 (ko) 발신 정보가 변조된 보이스 피싱 및 문자 피싱 공격을 탐지 및 차단하는 방법
    Simon et al. Voice over IP: Forensic computing implications
    Zhang et al. On the billing vulnerabilities of SIP-based VoIP systems
    WO2007019802A1 (fr) Portier securise pour reseau a communication vocale en paquets
    Arafat et al. SIP security in IP telephony
    Wei et al. Security implementation for a VoIP server
    Lamba et al. Security traits of VoIP
    Wang et al. Voip security: vulnerabilities, exploits, and defenses
    Arya Chandrapal Singh et al. VoIP Security Threat Taxonomy and Privacy
    Sengar Don’t Let the VoIP Service to Become a Nuisance for Its Subscribers

    Legal Events

    Date Code Title Description
    PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

    Free format text: ORIGINAL CODE: 0009012

    17P Request for examination filed

    Effective date: 20071224

    AK Designated contracting states

    Kind code of ref document: A1

    Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

    DAX Request for extension of the european patent (deleted)
    111Z Information provided on other rights and legal means of execution

    Free format text: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR

    Effective date: 20080206

    DAX Request for extension of the european patent (deleted)
    RAP1 Party data changed (applicant data changed or rights of an application transferred)

    Owner name: CHECKPHONE TECHNOLOGIES

    17Q First examination report despatched

    Effective date: 20111027

    GRAP Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOSNIGR1

    GRAS Grant fee paid

    Free format text: ORIGINAL CODE: EPIDOSNIGR3

    GRAA (expected) grant

    Free format text: ORIGINAL CODE: 0009210

    AK Designated contracting states

    Kind code of ref document: B1

    Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

    REG Reference to a national code

    Ref country code: GB

    Ref legal event code: FG4D

    Free format text: NOT ENGLISH

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: EP

    REG Reference to a national code

    Ref country code: IE

    Ref legal event code: FG4D

    Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

    REG Reference to a national code

    Ref country code: AT

    Ref legal event code: REF

    Ref document number: 602625

    Country of ref document: AT

    Kind code of ref document: T

    Effective date: 20130415

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R096

    Ref document number: 602006035202

    Country of ref document: DE

    Effective date: 20130516

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: ES

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130701

    Ref country code: BG

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130620

    Ref country code: LT

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: SE

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: LU

    Payment date: 20130621

    Year of fee payment: 8

    Ref country code: GB

    Payment date: 20130619

    Year of fee payment: 8

    Ref country code: CH

    Payment date: 20130621

    Year of fee payment: 8

    Ref country code: DE

    Payment date: 20130620

    Year of fee payment: 8

    REG Reference to a national code

    Ref country code: AT

    Ref legal event code: MK05

    Ref document number: 602625

    Country of ref document: AT

    Kind code of ref document: T

    Effective date: 20130320

    REG Reference to a national code

    Ref country code: LT

    Ref legal event code: MG4D

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: LV

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: GR

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130621

    Ref country code: SI

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: FI

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: FR

    Payment date: 20130703

    Year of fee payment: 8

    REG Reference to a national code

    Ref country code: NL

    Ref legal event code: VDEP

    Effective date: 20130320

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: AT

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: RO

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: NL

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: CZ

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: SK

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: PT

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130722

    Ref country code: IS

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130720

    Ref country code: EE

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: CY

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: PL

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    BERE Be: lapsed

    Owner name: CHECKPHONE TECHNOLOGIES

    Effective date: 20130630

    PLBE No opposition filed within time limit

    Free format text: ORIGINAL CODE: 0009261

    STAA Information on the status of an ep patent application or granted ep patent

    Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: DK

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    Ref country code: MC

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    26N No opposition filed

    Effective date: 20140102

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: IT

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    REG Reference to a national code

    Ref country code: IE

    Ref legal event code: MM4A

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: BE

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20130630

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R097

    Ref document number: 602006035202

    Country of ref document: DE

    Effective date: 20140102

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: IE

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20130623

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R119

    Ref document number: 602006035202

    Country of ref document: DE

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: LU

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20140623

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: PL

    GBPC Gb: european patent ceased through non-payment of renewal fee

    Effective date: 20140623

    REG Reference to a national code

    Ref country code: FR

    Ref legal event code: ST

    Effective date: 20150227

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R119

    Ref document number: 602006035202

    Country of ref document: DE

    Effective date: 20150101

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: LI

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20140630

    Ref country code: CH

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20140630

    Ref country code: DE

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20150101

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: GB

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20140623

    Ref country code: FR

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20140630

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: TR

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20130320

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: HU

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

    Effective date: 20060623