FR2844941A1 - Demande d'acces securise aux ressources d'un reseau intranet - Google Patents

Demande d'acces securise aux ressources d'un reseau intranet Download PDF

Info

Publication number
FR2844941A1
FR2844941A1 FR0211755A FR0211755A FR2844941A1 FR 2844941 A1 FR2844941 A1 FR 2844941A1 FR 0211755 A FR0211755 A FR 0211755A FR 0211755 A FR0211755 A FR 0211755A FR 2844941 A1 FR2844941 A1 FR 2844941A1
Authority
FR
France
Prior art keywords
message
gateway
host computer
host
end devices
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.)
Granted
Application number
FR0211755A
Other languages
English (en)
Other versions
FR2844941B1 (fr
Inventor
Jean Francois Le Pennec
Aurelien Bruno
Jean Marie Sommerlatt
Nicolas Grisi
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.)
AT&T Corp
Original Assignee
AT&T Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by AT&T Corp filed Critical AT&T Corp
Priority to FR0211755A priority Critical patent/FR2844941B1/fr
Priority to US10/638,860 priority patent/US7320143B2/en
Publication of FR2844941A1 publication Critical patent/FR2844941A1/fr
Application granted granted Critical
Publication of FR2844941B1 publication Critical patent/FR2844941B1/fr
Priority to US11/986,534 priority patent/US7716331B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1466Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Landscapes

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

Abstract

Méthode d'accès sécurisé par un ordinateur hôte (13) à des ressources Intranet fournies par au moins un serveur de ressources (18) dans un système de transmission de données dans lequel l'ordinateur hôte est connecté au serveur de ressources à travers une passerelle (17). Cette méthode étant consiste à générer et transmettre à des instants de transmission prédéterminés à partir de l'ordinateur hôte ou de la passerelle des messages de vérification. Chaque message de vérification contient une signature qui dépend des données échangées entre l'ordinateur hôte et la passerelle depuis le message de vérification précédent, l'ordinateur hôte et la passerelle appelés aussi dispositifs d'extrémité ayant à leur disposition un même algorithme définissant lequel d'entre eux transmet un message de vérification à chacun des instants prédéterminés.

Description

2002-0150
Domaine technique L'invention concerne l'accès sécurisé à des ressources d'un
réseau Intranet sans mettre en oeuvre un tunnel direct d'un bout à l'autre mais en utilisant une technique anti-usurpation d'identité entre l'ordinateur hôte et la passerelle reliée aux serveurs de ressources et a trait en particulier à une méthode 10 d'accès sécurisé à des ressources Intranet.
Etat de la technique Le protocole Internet (IP) fonctionne de façon basique avec des petites portions de données appelées paquets contenant une 15 en-tête qui contient l'adresse de destination et l'adresse source. Le protocole IP fonctionnant sans l'établissement d'une connexion, les routeurs du réseau exécutent les actions de routage en se basant sur l'adresse de destination sans que la
source adresse ait une influence.
Cependant, l'utilisation de l'adresse source par des personnes non autorisées peut créer un problème qui est connu en tant qu''usurpation d'identité" qui est le problème numéro un avec Internet. En effet, pour accéder à des ressources, des intrus créent des paquets avec des adresses source IP usurpées. 25 De tels paquets peuvent être routés à travers des pare-feu de
filtrage s'ils ne sont pas configurés pour filtrer des paquets entrants dont l'adresse source se trouve dans le domaine local.
Il est important de noter que cette attaque est possible même si aucun paquet de réponse ne peut atteindre l'intrus. Des 30 configurations qui sont potentiellement vulnérables comprennent les routeurs vers des réseaux externes qui admettent de multiples interfaces internes, les routeurs ayant deux interfaces qui admettent des sous-réseaux sur le réseau interne, les pare-feu
2 2002-0150
proxy dans lesquels les applications proxy utilisent l'adresse source IP pour l'authentification, et les routeurs ou passerelles
d'accès à Internet avec un tunnel vers un réseau interne.
Les administrateurs de réseau ont le choix de faire du 5 filtrage d'adresse source sur leurs routeurs avec des filtres anti-usurpation d'identité mais ils présentent des limitations
dépendant du type d'usurpation et du fonctionnement du réseau.
Un des dangers les plus connus d'usurpation d'identité est l'utilisation de l'usurpation en combinaison avec l'écoute 10 clandestine dans le but d'effectuer une attaque dans laquelle les données écoutées sont utilisées pour générer une réponse qui est basée sur la traduction de l'adresse usurpée. Ceci a pour but de faire croire au destinataire, par l'usurpateur, que c'est
l'entité qui essaie de le contacter.
Un exemple d'usurpation d'identité combinée avec l'écoute clandestine est l'usurpation d'identité dans un serveur de noms de domaine (DNS) dans laquelle un serveur DNS accepte et utilise des informations incorrectes venant d'un ordinateur hôte qui n'a aucune autorité à donner ces informations. Une telle attaque peut 20 amener les utilisateurs à être dirigés vers des sites Internet erronés ou des e-mails à être routés vers des serveurs non autorisés. Un autre type d'usurpation d'identité significatif est celle qui est utilisée avec le protocole de reconnaissance d'adresse 25 (ARP). Dans l'usurpation d'identité ARP, les pirates peuvent trouver des dispositifs actifs sur la partie de réseau local en envoyant une simple série de "broadcasts" (diffusions globales) et en incrémentant la valeur du champ d'adresse IP de destination dans chaque paquet de façon à trouver l'adresse matérielle de 30 destination avec l'adresse IP connue. Cette méthode d'usurpation est similaire à l'usurpation d'identité DNS, mais s'applique seulement à une couche inférieure dans la pile TCP/IP et en
3 2002-0150
outre, fonctionne également sur les réseaux commutés. Avec cette méthode, l'attaquant pourrait convaincre un ordinateur hôte ou un routeur qu'il est l'ordinateur hôte ou le routeur du réseau local auquel il faudrait transmettre les paquets IP. Cette méthode est 5 maintenant régulièrement utilisée pour écouter clandestinement des réseaux commutés. Avant de communiquer avec un ordinateur hôte, un dispositif IP doit obtenir l'adresse matérielle de l'hôte destinataire ou le prochain routeur sur le chemin de l'hôte. L'attaque du cache ARP est une des attaques les plus 10 efficaces consistant à utiliser directement le cache d'un
dispositif destinataire de façon à soit ajouter une nouvelle entrée dans la table, soit mettre à jour une entrée existante.
Ceci permet d'effectuer différentes attaques telles que l'interception des données allant d'un dispositif vers un autre 15 dispositif aussi appelée attaque "quelqu'un dans le milieu".
Il existe plusieurs solutions permettant de protéger un réseau contre des attaques d'usurpation d'identité. Une de ces solutions est illustrée sur la figure 1 qui décrit l'environnement entre un ordinateur hôte et un serveur 18 à 20 travers un tunnel sécurisé. Le tunnel sécurisé utilise le
standard IPsec pour réaliser la fonction tunnel et l'encryptage dans un réseau non sécurisé NET 10 entre deux routeurs d'extrémité R1 14 et R2 15. L'ordinateur hôte 13 peut atteindre le routeur 14 via un LAN 11 et les serveurs de données tels que 25 le serveur 18 sont accédés à travers un LAN 12.
L'authentification de l'hôte est effectuée grâce à une passerelle ou portail GW 17. Lorsque l'authentification a été réalisée, la passerelle fournit l'accès au serveur S 18. On doit noter que le réseau 10 peut être, soit le réseau Internet, soit un réseau 30 Intranet.
Dans l'environnement illustré sur la figure 1 partageant le même tunnel IPsec, il existe un besoin d'authentification de
4 2002-0150
l'utilisateur. Beaucoup de solutions existent pour cette authentification, mais aucune qui puisse simplement vérifier qu'aucune usurpation d'adresse IP de l'hôte a été réalisée durant la connexion. La technique basée sur "Secure Socket Layer" (SSL) 5 fournit cette authentification ainsi que des mécanismes antiusurpation au moyen des clés utilisées.
SSL est une méthode standard de partage de secret utilisant des clés publiques et privées. Puisque l'ordinateur hôte et la passerelle utilisent la même clé secrète pour encrypter et 10 décrypter leurs informations, ils peuvent avoir une certaine satisfaction en sachant que ces informations ne peuvent pas être interceptées et décodées par un tiers. Mais ceci dépend de l'encryptage qui est fort ou faible et donc la protection fournie
par SSL n'est pas suffisante pour empêcher des attaques.
De plus, une solution telle que SSL présente des inconvénients pour la performance et des limitations de sécurité en plus d'avoir été conçu principalement pour l'accès à un serveur Web. La méthode SSL comporte un encryptage alors que l'accès à distance fournit aussi généralement l'encryptage grâce 20 à IPsec. L'encryptage SSL ne peut pas être retiré. En outre, SSL
inclut également l'encapsulation qui est par conséquent effectuée deux fois s'il y a un tunnel IPsec. Aussi, l'utilisation de ce mécanisme existant ne participe pas à la réduction de la charge opérationnelle du système et de la charge imposée par 25 l'encryptage.
La figure 2 décrit une solution alternative appliquée au même système de réseau que celui qui est illustré sur la figure 1. Une telle solution utilisant des protocoles standard tels que IPsec AH ou 802.1X comme méthode de contrôle d'accès (ACTL) entre 30 l'hôte 13 et le routeur 14 permet l'authentification de l'hôte mais pas l'authentification de l'utilisateur. Comme il est très facile de pirater un mot de passe de PC, cette solution n'est pas
2002-0150
très sécurisée puisque aucune authentification d'utilisateur n'est effectuée. Les deux mécanismes ont besoin de capacités du routeur pour la réaliser, ce qui signifie que la même entité administrative devrait posséder le routeur et les ordinateurs 5 hôtes et activer cette fonction. Par conséquent, elle est
complexe à réaliser et pas suffisamment sécurisée.
Exposé de l'invention En conséquence, le but de l'invention est de réaliser une 10 méthode d'accès sécurisé à des ressources Intranet qui permette d'empêcher qu'une connexion entre un ordinateur hôte et au moins un serveur de données au moyen d'une passerelle soit usurpée et qui ne nécessite pas de mettre en oeuvre des mécanismes complexes
impactant la performance du système.
L'invention a donc pour objet une méthode d'accès sécurisé par un ordinateur hôte à des ressources Intranet fournies par au moins un serveur de ressources dans un système de transmission de données dans lequel l'ordinateur hôte est connecté au serveur de ressources à travers une passerelle. Cette méthode consiste à générer et transmettre à des instants de transmission prédéterminés à partir de l'ordinateur hôte ou de la passerelle des messages de vérification. Chaque message de vérification contient une signature qui dépend des données échangées entre l'ordinateur hôte et la passerelle depuis le message de 25 vérification précédent, l'ordinateur hôte et la passerelle appelés aussi dispositifs d'extrémité ayant à leur disposition un même algorithme définissant lequel d'entre eux transmet un
message de vérification à chacun des instants prédéterminés.
Description brève des dessins
6 2002-0150
Les buts, objets et caractéristiques de l'invention
apparaîtront plus clairement à la lecture de la description qui
suit faite en référence aux dessins dans lesquels: * la figure 1 est un bloc-diagramme représentant un système de 5 transmission de données de la technique antérieure dans lequel une première solution sécurisée est utilisée, * la figure 2 est un bloc-diagramme représentant le même système de transmission de données de la technique antérieure dans lequel une deuxième solution sécurisée est 10 utilisée, * la figure 3 est un bloc-diagramme représentant le même système de transmission de données que dans la figure 1 dans lequel la méthode selon l'invention est mise en oeuvre, * la figure 4A est un organigramme représentant les actions 15 qui sont mises en oeuvre dans l'ordinateur hôte ou la passerelle à l'occurrence de différents événements, * la figure 4B est un organigramme représentant les actions entreprises dans l'ordinateur hôte ou dans la passerelle lors des interruptions dues aux minuteries, * la figure 4C est un organigramme représentant les actions qui sont initialisées à la réception des messages par l'ordinateur hôte ou par la passerelle, * la figure 5 est un bloc-diagramme des différents blocs fonctionnels dans l'ordinateur hôte ou la passerelle, et * la figure 6 est un blocdiagramme représentant un système de transmission de données général dans lequel la méthode selon
l'invention peut être mise en oeuvre.
Description détaillée de l'invention
Comme il a été mentionné dans la description des figures 1
et 2 représentant un système de transmission comprenant un tunnel
7 2002-0150
sécurisé, les méthodes antérieures telles que SSL ou IPsec H ne sont pas adaptées dans la mesure o, soit elles exigent que les données soient encryptées et encapsulées ce qui entraîne un surcroît de charge, soit elles ne fournissent pas une 5 authentification de l'utilisateur mais seulement une
authentification de l'hôte.
Dans la méthode selon l'invention, les problèmes ci-dessus sont résolus en mettant en oeuvre deux mécanismes. Le premier mécanisme est une vérification permanente de la présence du 10 dispositif d'extrémité valide (hôte ou passerelle) comme étant la source de données et le second est la vérification locale qu'aucune usurpation d'identité n'a été effectuée. Chaque fois qu'une nouvelle connexion débute à partir de l'hôte, la vérification que c'est le bon utilisateur de l'hôte qui utilise 15 la source est effectuée. Puis, la passerelle et l'hôte effectuent
de façon indépendante cette vérification durant la session.
Ainsi, ni un tunnel complexe ni une encapsulation ne sont
nécessaires comme dans les systèmes antérieurs.
En référence à la figure 3 dans laquelle le système de 20 transmission de données est le même que celui illustré sur les figures 1 et 2, la passerelle 17 transmet d'abord la procédure de connexion dans une première étape 30 ou la configure si elle est déjà installée dans l'ordinateur hôte. Cette procédure comporte une clé publique et une clé secrète partagée. La clé secrète 25 partagée, encryptée par la clé publique, est transmise à l'ordinateur hôte. Puis, une étape d'authentification 32 est effectuée. L'utilisateur de l'hôte 13 s'authentifie en fournissant son identification ID et son mot de passe encrypté par la clé publique. Puis, à l'autre extrémité, la passerelle 30 authentifie l'utilisateur de l'hôte 13. A noter que l'hôte peut utiliser la procédure de connexion et une application locale pour vérifier que son adresse IP et l'adresse MAC associée sur le LAN
8 2002-0150
est unique, ce qui signifie que personne n'usurpe une de ces adresses. De façon à protéger les données contre l'usurpation d'identité, un nouveau type de numérotation de séquence basée sur 5 les paramètres ID/mot de passe et/ou la clé partagée est débutée des deux côtés. Cette numérotation est calculée indépendamment par les deux dispositifs d'extrémité hôte et passerelle, parce que chacun connaît tous les paramètres pour la construire. La séquence évolue en se basant sur un algorithme défini de sorte 10 que personne d'autre puisse générer le numéro de séquence
suivant. Ce numéro de séquence pseudo-aléatoire est utilisé pour transporter tout le trafic IP qui utilise un numéro de séquence.
Autrement, d'autres champs IP ou des champs de couches supérieures peuvent être utilisés dans ce but. Pour les 15 protocoles utilisant une numérotation de séquence non incrémentée, un brouilleur peut être utilisé pour changer le champ à la transmission en utilisant la clé secrète partagée entre H et GW et remettre à la valeur initiale à l'autre extrémité. C'est la façon utilisée pour l'échange de données 34 20 ou 34'. Cette nouvelle numérotation de la séquence est optionnelle sur les paquets de données. L'option peut inclure une caractéristique plus protectrice qui calcule la nouvelle numérotation de séquence en se basant non seulement sur des valeurs d'origine et sur la clé secrète, mais en se basant 25 également sur le CRC ou le hachage du paquet. Cette dernière option limite le risque pour une modification du paquet sans
impact sur la charge opérationnelle.
La méthode pour établir la connexion est gérée en permanence par une vérification de l'intégrité du flot de données qui est 30 effectuée grâce aux messages Verif H 36 et Verif GW 38. Ce message pour vérifier l'identité du dispositif d'extrémité (hôte ou passerelle) est transmis à des instants prédéterminés fournis
9 2002-0150
par des minuteries et définis par plusieurs paramètres comprenant un temps moyen et la clé secrète partagée de manière à empêcher un autre dispositif de générer de tels messages. Ces messages peuvent inclure des informations sur les données échangées entre 5 l'hôte et la passerelle en tant que signature du trafic: nombre
de paquets, nombre de bytes, ou bien une signature plus complexe.
Lorsque l'hôte 13 reçoit un message de vérification 36 de la passerelle 17, il renvoie un message Accusé réception GW 37 à la passerelle. De la même façon, lorsque la passerelle 17 reçoit un 10 message de vérification 38 de l'hôte 13, elle renvoie un message
Accusé réception H 39 à l'hôte.
Le message de vérification transmis à partir de l'hôte ou de la passerelle est basé sur les minuteries et l'autre dispositif doit répondre dans un court délai avec une réponse correcte. S'il 15 n'y a pas de réponse ou une mauvaise réponse la connexion est stoppée. Si aucunes données ne sont reçues ou des mauvaises données sont reçues, alors la session est stoppée. En outre, ces messages sont encryptés et signés. Entre deux messages de vérification, les données sont transmises de façon transparente 20 avec l'option de changement de numéro de séquence. A noter que, si aucun message d'accusé réception n'est reçu par soit l'hôte soit la passerelle en réponse à un message de vérification, la
connexion est également stoppée.
Une option plus sécurisée consiste à mettre comme argument 25 dans un message la valeur de hachage cumulative de tous les paquets entre deux messages pour éviter l'attaque "quelqu'un dans le milieu". La liste des numéros de séquence utilisée depuis le dernier message de vérification peut aussi être transmise dans la zone de données du message pour améliorer la vérification des 30 paquets reçus. Ceci est valable si les paquets sont protégés par le mécanisme de numérotation proposé ou même quand on utilise des valeurs de numérotation d'origine. Cette façon de faire permet
2002-0150
également d'identifier quels paquets doivent être considérés entre deux messages de vérification de façon à résoudre le
problème de synchronisation des paquets.
En référence à la figure 4A qui décrit les étapes du procédé 5 réalisé dans chacun des deux dispositifs d'extrémité, hôte ou passerelle, le procédé commence à l'étape CONNEXION 40 et signifie qu'un message de connexion est transmis à l'autre dispositif pour commencer le même procédé en parallèle. C'est l'étape o la procédure de connexion est chargée si nécessaire et 10 correspond à l'étape 30 de la figure 3. Un drapeau F est mis à la valeur zéro à l'étape suivante 52 de façon à identifier qu'une connexion a débuté. En outre, un événement est mémorisé avec un horodateur pour conserver l'événement de début de session grâce à
l'étape ENREGISTREMENT EVENEMENT 49.
Puis, à l'étape suivante 55, comme la valeur de F est zéro, le procédé continue à l'étape 45. L'authentification effectuée à l'étape 45 est AUTHENTIFICATION comme décrit sur la figure 3 précédente. La prochaine étape PROTECTION 46 débute le mode de protection local pour l'antiusurpation d'identité. Les fonctions 20 impliquées seront décrites plus loin mais, de façon basique, la détection d'une usurpation potentielle aura pour résultat d'activer le procédé débutant à l'étape EVENEMENT CRITIQUE 41
pour analyser cet événement critique.
A ce point, basés sur la clé secrète partagée comme 25 mentionné précédemment, des minuteries pseudo-aléatoires utilisant des brouilleurs sont activées. C'est l'étape DEMARRER MINUTERIES 47 qui permet d'entrer dans le mode TRANSFERT DE
DONNEES 48.
Une autre entrée dans le procédé qui débute à l'étape 30 EVENEMENT CRITIQUE 41, assure que la connexion sera rompue en cas d'usurpation locale. L'étape RESTAURATION 42 suit immédiatement cette détection et transmet un message de restauration à l'autre il 2002-0150 dispositif d'extrémité (hôte ou passerelle) de façon à interrompre la transmission. Ceci se produit lorsque l'événement sécurité ne peut pas être certifié automatiquement comme étant un
changement normal.
On détermine alors si l'événement est validé à l'étape EVENEMENT VALIDE 43 permettant soit de redémarrer la connexion sécurisée à l'étape 45, soit de logger une alerte DECLENCHEMENT ALERTE 44. Cette validation pour le procédé d'événement critique peut, soit être une validation locale avec une fenêtre POP UP sur 10 l'écran de l'hôte de l'utilisateur et des explications, soit être une requête de validation transmise à un administrateur du réseau. Cette validation manuelle de l'événement peut être préanalysée par un système expert qui, soit prendra la décision, soit fera une recommandation. Une telle validation est induite 15 par un changement d'adresse (MAC ou IP) dans le dispositif, passerelle 17 ou routeur R1 14 ou R2 16. Un changement d'adresse (MAC ou IP) de l'hôte ne sera jamais accordé et shuntera l'étape de validation pour logger une alerte directement avec un message POP UP. Un nouvel ordinateur hôte connecté au LAN 11 sera aussi 20 détecté, mais si l'adresse MAC est une adresse qui a déjà été utilisée dans le passé et qui peut être vérifiée, soit par l'hôte local qui mémorise les tables ARP approuvées antérieures, soit par l'administrateur qui peut faire une recherche dans une base de données d'adresses MAC, alors le système expert peut délivrer 25 cette nouvelle entrée de table ARP et la mise à jour du cache correspondante. Dans un tels cas, une vérification que l'adresse IP associée pour ce nouvel hôte est, soit l'adresse IP précédente ou une adresse maintenue dans une étendue DHCP valide pour ce LAN, soit une adresse statique qui a été affectée par 30 l'administrateur à cet hôte, est effectuée. Si cette validation est effectuée de façon satisfaisante, alors l'événement est
considéré comme valide.
12 2002-0150
Lorsque l'événement n'est pas validé quelle que soit la méthode de validation utilisée, le procédé passe à l'étape DECLENCHEMENT ALERTE 44 o une alerte est mémorisée localement dans l'hôte et transmise à l'administrateur. En plus, un message 5 peut être envoyé au nouvel ordinateur hôte qui est à l'origine de cet événement de manière à lui conseiller de contacter
l'administrateur pour obtenir l'approbation de l'accès LAN.
Lorsque l'événement est validé, une vérification de la valeur de F est faite à l'étape 55 pour savoir si une re10 connexion doit être effectuée de façon à continuer à échanger des
données par la passerelle GW. Ceci correspond à la valeur 0 du drapeau F. Une valeur 1 du drapeau F signifie qu'une déconnexion a été faite et aucune re-connexion n'est demandée. Dans ce cas, le procédé mémorise un événement avec un horodateur à l'étape 15 ENREGISTREMENT EVENEMENT 49.
L'entrée restante du procédé est la fonction de déconnexion qui débute à l'étape DECONNEXION 50, soit sur requête de l'utilisateur, soit par "Logoff" de cet utilisateur, soit par panne de l'hôte. Le drapeau F est mis à la valeur 1 pour refléter 20 ce changement à l'étape 51 et le procédé envoie un signal de restauration à l'autre dispositif à l'étape 42. Normalement, la session est arrêtée par l'hôte H mais une panne ou une reinitialisation de la passerelle GW dans un but de maintenance
peut aussi arrêter les sessions.
La figure 4B montre le processus d'interruption des minuteries. Deux minuteries sont débutées à l'étape 47. Une première minuterie appelée minuterie de transmission T est utilisée pour générer et transmettre les messages de vérification. Une seconde minuterie R est utilisée pour vérifier 30 que l'autre dispositif a transmis un message de vérification et que ce message a été reçu. T et R pour un des dispositifs, hôte ou passerelle, correspondant respectivement à R et T pour l'autre
13 2002-0150
dispositif avec un retard égal au temps de transmission si nécessaire. En cas d'interruption T à l'étape 60, un message de vérification détaillé sur la figure 3 est transmis à l'étape 5 TRANSMISSION VERIFICATION 64 chaque fois que T initie une interruption selon la séquence pseudo- aléatoire pour les valeurs de T. Pour la minuterie R, une interruption est générée à un instant R+ correspondant au temps auquel le message de 10 vérification de l'autre dispositif doit avoir été reçu. R+
correspond a R plus un retard qui peut être ajusté pour construire une fenêtre de réception des messages de vérification.
Si aucun message n'est reçu lorsque R+ expire et initie l'interruption, l'étape 66 envoie un message ECHEC à l'autre 15 dispositif (H ou GW), interrompt la connexion et place une alerte à l'étape 68. Le message ECHEC indique qu'aucun message de
vérification n'a été reçu dans l'intervalle de temps défini.
La figure 4C décrit le procédé lorsqu'un message de contrôle est reçu par un des dispositifs, hôte ou passerelle, durant une 20 session ouverte. Quatre types de messages peuvent être reçus et
identifiés à l'étape MESSAGE IDENTIFIE 70.
En cas de message de requête RESTAURATION 74 issu après une usurpation d'identité locale décrit à la figure 4A, la session est arrêtée et l'information d'alerte fournie par le message est 25 mémorisée pour analyse ultérieure à l'étape 86. Un tel message RESTAURATION est aussi envoyé lorsque le séquencement des paquets de données est activé et qu'une erreur est détectée par le dispositif d'extrémité qui reçoit. En conséquence, le message
RESTAURATION contient un champ identifiant le type d'événement 30 qui a déclenché l'envoi du message.
En cas de message VERIFICATION 73, une vérification que ce message est reçu à un temps t à l'intérieur de la tranche de
14 2002-0150
temps définie par R et R+ est effectuée à l'étape 75. Seulement un message de vérification reçu entre R et R+ sera considéré comme valide. La valeur de temps réelle peut aussi être mémorisée pour être comparée à la valeur prédéfinie R+. Ceci peut être 5 utilisé pour ajuster cette valeur si nécessaire selon l'étape 80.
Lorsqu'il y a validation pour les temps, une vérification additionnelle du contenu du message comparé aux paquets de données reçus entre ce message de vérification et le message de vérification précédent est effectuée à l'étape MSG OK 78. Elle 10 peut inclure la vérification de plusieurs éléments tels que le nombre de paquets reçus, la taille des paquets, la signature des paquets. Si la vérification est complétée de façon satisfaisante, ce procédé renvoie à l'autre dispositif un message d'accusé 15 réception ACCUSE RECEPTION 83. Un message tel que le message de vérification peut utiliser la méthode de la fenêtre de temps avec les minuteries. Sinon, le procédé interrompt la connexion et
place une alerte à l'étape 86.
Si le message est un message ECHEC 72 transmis à l'étape 66 20 par le dispositif opposé, le procédé ajuste d'abord les valeurs
des minuteries si possible et en parallèle (non montré sur la figure) interrompt la connexion et place une alerte à l'étape 86.
Le dernier cas est lorsque le message est un message ACCUSE RECEPTION 71. Si le dispositif qui a envoyé le message de 25 vérification ne reçoit pas l'accusé réception à un temps t à l'intérieur d'un intervalle défini par une fenêtre de temps entre R+ et R++ vérifié à l'étape 76, le procédé essaie d'ajuster à l'étape 80 la valeur de R++ et en parallèle interrompt la connexion et place une alerte à l'étape 86. Si le message ACCUSE 30 RECEPTION est reçu dans l'intervalle de temps, le procédé continue à l'étape 84 qui peut logger si nécessaire la valeur réelle du temps de réception pour ce message. Ceci peut être
2002-0150
activé en mode d'apprentissage pour identifier les valeurs
appropriées pour les minuteries.
En référence à la figure 5, la réalisation fonctionnelle d'un dispositif d'extrémité, hôte ou passerelle, comprend 5 l'interface INTF 92 étant généralement Ethernet, la pile IP 94
qui contient les commandes pour l'interface LAN 92 et supporte les couches inférieures de TCP/IP permettant à des applications d'être exécutées en tête du système d'exploitation OS 95 qui connecte le réseau et avec lequel s'exécutent les applications de 10 l'utilisateur, et le cache ARP 95 qui contient la table ARP.
Comme nouveau bloc fonctionnel, le bloc 98 a un accès dédié à la pile IP pour générer des messages de contrôle dans une session et obtenir desdétails sur les paquets de données tels que la longueur, le CRC et voir chaque byte pour reconstruire à 15 la volée la signature de paquet. Comme décrit avec la figure 4A, certaines actions nécessitent une action manuelle de
l'utilisateur qui est effectuée sur l'interface 96.
L'interface utilisateur 96 est connectée également au bloc antiusurpation 99 de manière à travailler avec les tables ARP 20 mémorisées dans le cache ARP 97 via le bloc de contrôle 99 comme
décrit ci-dessous. Des changements concernant les éléments ARP peuvent être faits directement à partir de l'interface utilisateur avec l'assistance d'un système expert situé dans le bloc anti-usurpation 99 qui analyse le cache ARP et les tables 25 ARP mémorisées actuelles ou précédentes.
Le bloc anti-usurpation contient les mesures anti-usurpation
implémentées dans les dispositifs qui analysent le réseau local et vérifient s'il y a usurpation des adresses IP ou MAC. Ce mécanisme fonctionne en étroite association avec le cache ARP de 30 façon à détecter des changements qui peuvent être des attaques.
En fait, tout changement dans le cache ARP relatif à un
16 2002-0150
dispositif débute le procédé de vérification pour un événement
critique EVENEMENT CRITIQUE 41 de la figure 4A.
Les vulnérabilités MAC et IP seront mieux comprises avec la
description de la façon de gérer les tables ARP et les adresses 5 IP/MAC et qui explique que tout réseau qui utilise une
technologie à segments partagés est vulnérable à l'usurpation
d'identité spécifique à ces types de réseaux.
Le protocole ARP est un protocole qui est utilisé avec les segments partagés de façon à faire correspondre les adresses IP 10 aux adresses MAC. Ce protocole est particulièrement vulnérable du fait qu'il utilise des diffusions globales (broadcasts) et n'a pas une forme unique d'authentification. Basiquement, lorsqu'un système désire envoyer un datagramme IP, il regarde si l'adresse IP est dans sa table ARP courante. Si ce n'est pas le cas, il 15 diffuse une requête ARP sur le segment partagé, et lie l'adresse
IP à l'adresse MAC mentionnée dans la réponse ARP qu'il reçoit.
L'utilisation de la réponse ARP faisant l'objet d'une usurpation d'identité donne la possibilité à un attaquant de perturber le réseau, mais surtout donne la possibilité à un 20 attaquant de prendre la place d'un autre dispositif dans le LAN pour transmettre et recevoir des paquets ou d'implémenter une simple attaque du type "quelqu'un dans le milieu", ce qui permet d'intercepter tous les paquets et de les retransmettre (en
général modifiés).
L'utilisation des tables ARP statiques évite beaucoup l'impact de l'usurpation des segments partagés, mais est moins flexible pour les utilisateurs. Toutefois, un point important demeure. La plupart des systèmes d'exploitation ne vérifient pas si un datagramme IP reçu a pour origine une adresse MAC qui a un 30 sens. Par conséquent, la connexion comble cette lacune et fournit un cache ARP permanent et un contrôle de table même si la table ARP n'est pas statique. Le bloc anti-usurpation 99 considère
17 2002-0150
qu'une partie du cache ARP comprenant des dispositifs toujours présents dans le LAN tels que des routeurs ou des passerelles, ne doit pas être statique et tout événement sur cette partie est considéré comme une attaque potentielle et génère le message 5 EVENEMENT CRITIQUE 41. Deux règles de base sont continuellement
vérifiées: les adresses source d'un datagramme IP local doivent correspondre aux adresses MAC de la table ARP, et les adresses IP des datagrammes non locaux ne doivent pas correspondre à l'adresse MAC de l'un des routeurs connus ayant une entrée de 10 routage valide dans la table de routage tel que R1.
En outre, toute adresse IP locale nouvelle qui n'a pas ou n'avait pas une entrée dans la table ARP ne doit pas être acceptée lorsque la session est en cours. Ceci est aussi un événement critique qui débute le procédé à partir de l'étape 41. 15 La mémorisation dans l'hôte de l'association d'adresses IP/MAC
valides précédentes permettra de supporter de nouveaux dispositifs connus dans le passé, ce qui signifie qu'il y a une entrée dans une des tables ARP mémorisées même s'ils utilisent une adresse IP différente si celle-ci appartient encore à une 20 gamme d'adresse DHCP permises.
Chaque ordinateur fonctionnant en TCP/IP utilise un cache qui contient des correspondances entre des adresses IP et du contrôle d'accès media (MAC) ou des adresses d'adaptateur sur le réseau. Le cache est maintenu par le protocole ARP et est 25 dynamique. Ceci explique que le bloc antiusurpation 99 est directement lié à ce cache pour identifier tout changement dynamique. Un changement du cache ARP peut être d, soit à une requête venant de l'hôte local par exemple si l'hôte H établit une autre session avec un autre dispositif du réseau, soit 30 lorsque l'adresse IP du dispositif destination n'est pas dans le cache et que l'hôte diffuse une trame sur le réseau. Le cache doit contenir des correspondances correctes pour les
18 2002-0150
communications. Une telle mise à jour du cache peut être faite à
la suite d'une requête de l'hôte local.
Au démarrage du système, lorsque le protocole IP s'initialise, la fonction anti-usurpation compare sa table ARP 5 précédente à l'environnement du réseau. L'hôte H envoie une
requête ARP contenant sa propre adresse MAC et IP de sorte que d'autres ordinateurs peuvent mettre à jour leurs caches ARP. S'il y a déjà un ordinateur utilisant l'adresse IP, l'ordinateur "ancien" répond par une réponse ARP contenant son adresse MAC et 10 IP, indiquant qu'il y a conflit.
Il peut trouver des changements importants ou une adresse dupliquée. La détection d'une adresse dupliquée est une caractéristique importante. Lorsque la pile est initialisée ou lorsqu'une nouvelle adresse IP est ajoutée, des requêtes ARP 15 gratuites sont diffusées pour les adresses IP de l'hôte local
dans ce but.
Une adresse dupliquée trouvée avant que la connexion soit
établie démarrera une alerte qui est localement loggée et transmise à l'administrateur pour vérification. La session ne 20 sera pas autorisée tant que la vérification n'est pas terminée.
Une adresse dupliquée détectée durant la connexion sécurisée
interrompt la connexion.
Une fois qu'une table ARP est validée, elle est copiée dans un fichier qui est comparé lorsque l'hôte est reconnecté sur le 25 réseau. Ce fichier est mémorisé dans le système des fichiers de l'OS 95 et repris par l'interface utilisateur 96. En fait, un historique des tables ARP est conservé et utilisé pour comparaison puisque la table à utiliser est reconstruite régulièrement. Ceci réduit le risque d'intrusion due aux 30 dispositifs inconnus sur le réseau lorsque l'hôte n'est plus alimenté ou est déconnecté du réseau mais présente plus de
flexibilité pour accepter de nouveaux dispositifs sur le LAN.
19 2002-0150
La figure 6 montre un système dans lequel une connexion LAN directe existe entre les dispositifs d'extrémité, hôte 13 et passerelle 17. Dans ce cas, l'ordinateur hôte et la passerelle sont connectés au même LAN 11. Comparée à la figure 1, la 5 connexion entre l'hôte et la passerelle est une connexion LAN
plutôt qu'une connexion multiple de réseaux LAN et WAN.
Dans ce système simplifié, le mécanisme anti-usurpation LAN
local IP/MAC peut être réduit à un seul dispositif, soit l'hôte, soit la passerelle. Dans ce cas, la fonction de connexion (plug10 in) peut ne contenir que le contrôle de session.
Pour conclure, le mécanisme proposé fournit un accès sécurisé, éloigné ou local, permettant des transferts de données sécurisés entre une passerelle et un ordinateur hôte, avec optionnellement un mécanisme anti- usurpation d'identité. Ce peut 15 être une amélioration pour les connexions éloignées multiples, utilisant une technologie à base de la fonction "tunnel". Il peut
former une partie des serveurs/portails d'authentification.
Un domaine d'application majeur est une application domestique o le tunnel est entre un routeur et un réseau 20 Intranet. Quiconque sur le réseau local peut atteindre l'Intranet
s'il a accès à ce LAN local, soit parce qu'aucune authentification locale n'est effectuée sur le portail, soit même si l'authentification est effectuée auquel cas l'anti-usurpation d'identité est très facile. Elle est même plus dangereuse avec 25 des LAN sans fils.
2002-0150

Claims (15)

REVENDICATIONS
1. Méthode d'accès sécurisé par un ordinateur hôte (13) à des ressources Intranet fournies par au moins un serveur de 5 ressources (18) dans un système de transmission de données dans lequel ledit ordinateur hôte est connecté audit serveur de ressources à travers une passerelle (17); ladite méthode étant caractérisée en ce qu'elle consiste à générer et transmettre à des instants de 10 transmission prédéterminés à partir dudit ordinateur hôte ou de ladite passerelle des messages de vérification dans laquelle chaque message de vérification contient une signature qui dépend des données échangées entre ledit ordinateur hôte et ladite passerelle depuis le message de 15 vérification précédent, ledit ordinateur hôte et ladite passerelle appelés aussi dispositifs d'extrémité ayant à leur disposition un même algorithme définissant lequel d'entre eux transmet un message de vérification à chacun desdits instants prédéterminés. 20
2. Méthode selon la revendication 1, dans laquelle lesdits
instants de transmission sont fournis par une minuterie T dans chacun des dispositifs d'extrémité (13, 17) et sont basés sur au moins une clé secrète partagée par lesdits 25 dispositifs d'extrémité.
3. Méthode selon la revendication 2, dans laquelle une minuterie R dans chacun desdits dispositifs d'extrémité (13, 17) définit les instants de réception auxquels ledit message 30 de vérification transmis par un desdits dispositifs d'extrémité est reçu par l'autre dispositif, lesdits instants de réception pour chacun desdits dispositifs d'extrémité correspondant auxdits instants de transmission
21 2002-0150
prédéterminés pour l'autre dispositif avec un retard
additionnel égal au temps de transmission.
4. Méthode selon la revendication 3, dans lequel ledit message 5 de vérification transmis à un instant de transmission prédéterminé par un premier desdits dispositifs d'extrémité (13 ou 17) doit être reçu par l'autre dispositif dans un premier intervalle de temps prédéterminé après ledit instant de réception correspondant audit instant de réception 10 prédéterminé pour être considéré comme valide, un message d'accusé réception étant transmis en retour audit premier dispositif d'extrémité par l'autre dispositif d'extrémité lorsque ledit message de vérification est reçu dans ledit
premier intervalle de temps.
5. Méthode selon la revendication 4, dans laquelle un message d'échec est retransmis par ledit autre dispositif d'extrémité (13, 17) audit premier dispositif d'extrémité lorsque ledit message de vérification n'est pas reçu dans 20 ledit premier intervalle de temps, et une procédure d'interruption et d'alerte est activée dans ledit autre
dispositif d'extrémité dans un tel cas.
6. Méthode selon la revendication 4, dans laquelle ledit 25 message d'accusé réception doit être reçu par ledit premier
dispositif d'extrémité dans un second intervalle de temps prédéterminé après la fin dudit premier intervalle de temps pour être considéré comme valide, une procédure d'interruption et d'alerte étant activée dans ledit premier 30 dispositif d'extrémité si ce n'est pas le cas.
7. Méthode selon l'une des revendications 1 à 6, dans laquelle
un message de restauration est transmis par un premier desdits dispositifs d'extrémité (13 ou 17) à l'autre
22 2002-0150
dispositif d'extrémité lors de la détection d'un événement critique tel qu'une usurpation d'identité locale, ledit message de restauration initialisant une procédure d'interruption de la connexion et le déclenchement d'une 5 alerte lorsqu'il est reçu par ledit autre dispositif d'extrémité.
8. Méthode selon la revendication 7, dans laquelle, soit la connexion entre lesdits dispositifs d'extrémité (13, 17) est 10 redémarrée si ledit événement de sécurité est validé, soit une alerte est déclenchée si ledit événement n'est pas validé.
9. Méthode selon la revendication 8, dans laquelle la 15 validation dudit événement critique est soit une validation locale après affichage d'une fenêtre POP IN sur l'écran d'utilisateur dudit ordinateur hôte (13), soit une validation administrative après envoi d'une requête à
l'administrateur du réseau.
10. Méthode selon la revendication 8, dans laquelle la validation dudit événement critique comprend le changement
de l'adresse IP ou MAC de ladite passerelle (17).
11. Méthode selon la revendication 9 ou 10, dans laquelle ledit événement critique correspond à une usurpation d'identité locale et est activé lorsque l'adresse source IP du paquet de données ne correspond pas à l'adresse MAC dans une table
de correspondance.
12. Méthode selon l'une des revendications 1 à 11, dans laquelle
chacun desdits dispositifs d'extrémité (13, 17) génère une même séquence de numérotation pseudo-aléatoire dans laquelle la valeur du numéro de séquence est déterminée par un
23 2002-0150
algorithme prédéterminé, ladite séquence étant utilisée pour échanger des paquets de données IP entre lesdits dispositifs d'extrémité.
13. Méthode selon la revendication 12, dans laquelle la valeur du numéro de ladite séquence numérotation pseudo-aléatoire est déterminée en utilisant le numéro de la séquence d'origine et au moins ladite signature ou une clé secrète partagée par les deux dispositifs d'extrémité (13, 17) 10 permettant au dispositif d'extrémité qui reçoit de retrouver
le numéro de séquence d'origine.
14. Système de transmission de données comprenant des moyens
adaptés pour effectuer les étapes de la méthode selon l'une 15 quelconque des revendications 1 à 13.
15. Système de transmission de données selon la revendication 14, dans lequel la connexion entre ledit ordinateur hôte (13) et ladite passerelle (17) s'effectue à travers un 20 tunnel sécurisé entre deux routeurs d'extrémité (14, 15) tel
qu'un tunnel IPsec.
FR0211755A 2002-09-24 2002-09-24 Demande d'acces securise aux ressources d'un reseau intranet Expired - Fee Related FR2844941B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR0211755A FR2844941B1 (fr) 2002-09-24 2002-09-24 Demande d'acces securise aux ressources d'un reseau intranet
US10/638,860 US7320143B2 (en) 2002-09-24 2003-08-11 Method of gaining secure access to intranet resources
US11/986,534 US7716331B2 (en) 2002-09-24 2007-11-21 Method of gaining secure access to intranet resources

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0211755A FR2844941B1 (fr) 2002-09-24 2002-09-24 Demande d'acces securise aux ressources d'un reseau intranet

Publications (2)

Publication Number Publication Date
FR2844941A1 true FR2844941A1 (fr) 2004-03-26
FR2844941B1 FR2844941B1 (fr) 2005-02-18

Family

ID=31970912

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0211755A Expired - Fee Related FR2844941B1 (fr) 2002-09-24 2002-09-24 Demande d'acces securise aux ressources d'un reseau intranet

Country Status (2)

Country Link
US (2) US7320143B2 (fr)
FR (1) FR2844941B1 (fr)

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7647647B2 (en) * 2004-08-05 2010-01-12 International Business Machines Corporation System, method and program product for temporally authorizing program execution
US7567573B2 (en) * 2004-09-07 2009-07-28 F5 Networks, Inc. Method for automatic traffic interception
US20060114863A1 (en) * 2004-12-01 2006-06-01 Cisco Technology, Inc. Method to secure 802.11 traffic against MAC address spoofing
JP2006253900A (ja) * 2005-03-09 2006-09-21 Hitachi Ltd Ipアドレス引き継ぎ方法、ipアドレスアドレス引き継ぎプログラム、サーバおよびネットワークシステム
US7743254B2 (en) 2005-03-23 2010-06-22 Microsoft Corporation Visualization of trust in an address bar
US7725930B2 (en) * 2005-03-30 2010-05-25 Microsoft Corporation Validating the origin of web content
US7707417B2 (en) * 2005-06-23 2010-04-27 Masami Yoshioka Secure transmission of data between clients over communications network
US9590964B1 (en) * 2006-03-02 2017-03-07 Rockwell Collins, Inc. GPS-enabled cross-domain guard
US7809354B2 (en) * 2006-03-16 2010-10-05 Cisco Technology, Inc. Detecting address spoofing in wireless network environments
US20070266236A1 (en) * 2006-05-09 2007-11-15 Colditz Nathan Von Secure network and method of operation
JP2008003438A (ja) * 2006-06-26 2008-01-10 Sony Corp 乱数生成装置、乱数生成制御方法、メモリアクセス制御装置、および、通信装置
US7769842B2 (en) * 2006-08-08 2010-08-03 Endl Texas, Llc Storage management unit to configure zoning, LUN masking, access controls, or other storage area network parameters
US8201217B1 (en) 2006-10-03 2012-06-12 Stamps.Com Inc. Systems and methods for single sign-in for multiple accounts
US8046823B1 (en) * 2006-10-03 2011-10-25 Stamps.Com Inc. Secure application bridge server
US8190755B1 (en) * 2006-12-27 2012-05-29 Symantec Corporation Method and apparatus for host authentication in a network implementing network access control
KR101399359B1 (ko) * 2007-04-06 2014-05-26 삼성전자주식회사 컨텐츠 전송 제어 방법 및 장치
CN101094236B (zh) * 2007-07-20 2011-08-10 华为技术有限公司 地址解析协议报文处理方法及通讯系统及转发平面处理器
US8950001B2 (en) * 2007-08-01 2015-02-03 Avaya Inc. Continual peer authentication
US8646039B2 (en) * 2007-08-01 2014-02-04 Avaya Inc. Automated peer authentication
US20090210935A1 (en) * 2008-02-20 2009-08-20 Jamie Alan Miley Scanning Apparatus and System for Tracking Computer Hardware
US8505074B2 (en) * 2008-11-21 2013-08-06 Sharp Laboratories Of America, Inc. Selective web content controls for MFP web pages across firewalls
US8874693B2 (en) * 2009-02-20 2014-10-28 Microsoft Corporation Service access using a service address
US20100215052A1 (en) * 2009-02-20 2010-08-26 Inventec Corporation Iscsi network interface card with arp/icmp resolution function
US8856525B2 (en) * 2009-08-13 2014-10-07 Michael Gregor Kaplan Authentication of email servers and personal computers
US20120136944A1 (en) * 2010-04-05 2012-05-31 Futurewei Technologies, Inc. Method For Dynamic Discovery of Control Plane Resources and Services
US8346672B1 (en) * 2012-04-10 2013-01-01 Accells Technologies (2009), Ltd. System and method for secure transaction process via mobile device
US8875254B2 (en) * 2012-08-07 2014-10-28 International Business Machines Corporation Cache sharing of enterprise data among peers via an enterprise server
US9973515B1 (en) * 2014-02-05 2018-05-15 Rockwell Collins, Inc. Network security for avionics with ethernet connections system and related method
WO2015150854A1 (fr) * 2014-04-01 2015-10-08 Anas Basalamah Procédé et traitement de transport de type « mule » de données humain autonome à l'aide de dispositifs électroniques de communication
US10592108B2 (en) * 2014-09-30 2020-03-17 Anthony Tan Secured storage system with temporary external assignable memory
US9634917B2 (en) * 2014-10-17 2017-04-25 Aruba Networks, Inc. Method and system for detecting use of wrong internet protocol address
CN104394243B (zh) * 2014-12-15 2018-10-19 北京搜狐新媒体信息技术有限公司 一种重复地址检测方法和装置
US9800547B2 (en) * 2015-04-16 2017-10-24 International Business Machines Corporation Preventing network attacks on baseboard management controllers
US9781105B2 (en) 2015-05-04 2017-10-03 Ping Identity Corporation Fallback identity authentication techniques
US10051000B2 (en) * 2015-07-28 2018-08-14 Citrix Systems, Inc. Efficient use of IPsec tunnels in multi-path environment
US9853993B1 (en) 2016-11-15 2017-12-26 Visa International Service Association Systems and methods for generation and selection of access rules
US10320846B2 (en) 2016-11-30 2019-06-11 Visa International Service Association Systems and methods for generation and selection of access rules
US10218712B2 (en) * 2017-01-25 2019-02-26 International Business Machines Corporation Access control using information on devices and access locations
US11201853B2 (en) 2019-01-10 2021-12-14 Vmware, Inc. DNS cache protection
US10855644B1 (en) * 2019-09-09 2020-12-01 Vmware, Inc. Address resolution protocol entry verification
US11575646B2 (en) * 2020-03-12 2023-02-07 Vmware, Inc. Domain name service (DNS) server cache table validation

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001063853A1 (fr) * 2000-02-22 2001-08-30 Nokia Networks Oy Procede de verification de la quantite de donnees transmises
WO2002021415A1 (fr) * 2000-09-06 2002-03-14 Xanboo, Inc. Methode d'amortissement d'une redondance d'authentification

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6304969B1 (en) * 1999-03-16 2001-10-16 Webiv Networks, Inc. Verification of server authorization to provide network resources

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001063853A1 (fr) * 2000-02-22 2001-08-30 Nokia Networks Oy Procede de verification de la quantite de donnees transmises
WO2002021415A1 (fr) * 2000-09-06 2002-03-14 Xanboo, Inc. Methode d'amortissement d'une redondance d'authentification

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WHALENS: "An Introduction to ARP spoofing", PACKETSTORM, June 2001 (2001-06-01), XP002240206, Retrieved from the Internet <URL:http://packetstormsecurity.nl/papers/protocols/intro_to_arp_spoofing.pdf> [retrieved on 20030506] *

Also Published As

Publication number Publication date
US7716331B2 (en) 2010-05-11
US7320143B2 (en) 2008-01-15
FR2844941B1 (fr) 2005-02-18
US20080147871A1 (en) 2008-06-19
US20040059909A1 (en) 2004-03-25

Similar Documents

Publication Publication Date Title
FR2844941A1 (fr) Demande d&#39;acces securise aux ressources d&#39;un reseau intranet
US10250618B2 (en) Active validation for DDoS and SSL DDoS attacks
US8413248B2 (en) Method for secure single-packet remote authorization
EP1605660B1 (fr) Contrôle d&#39;accès à un réseau d&#39;un terminal source utilisant un tunnel en mode bloquant
US20130312054A1 (en) Transport Layer Security Traffic Control Using Service Name Identification
EP3100405A2 (fr) Systèmes et procédés de protection de communications
WO2009068603A2 (fr) Procede de securisation d&#39;un canal bidirectionnel de communication et dispositif de mise en oeuvre du procede
Al-Bahadili et al. Network security using hybrid port knocking
EP3459224B1 (fr) Sécurité de serveur web
WO2004086719A2 (fr) Systeme de transmission de donnees client/serveur securise
EP3087719B1 (fr) Procédé de ralentissement d&#39;une communication dans un réseau
FR2881592A1 (fr) Procede et dispositif de detection d&#39;usurpations d&#39;adresse dans un reseau informatique
WO2006134072A1 (fr) Procede de protection contre le piratage d&#39;un terminal client utilisant une connexion securisee avec un serveur sur un reseau public
EP2109284A1 (fr) Mécanisme de protection contre les attaques de refus de service par réacheminement de trafic.
Efe et al. A Hidden Hazard: Man-In-The-Middle Attack in Networks
Smyth Security+ Essentials
Belbachir et al. Involved Security Solution in Voice over IP Networks
WO2006035137A1 (fr) Procede et dispositif de filtrage pour detecter une usurpation d’adresse dans un reseau informatique
Forte The state of the art in digital forensics
PRICE et al. Network security mechanisms utilizing dynamic network address translation ldrd project
Izadinia Fingerprinting encrypted tunnel endpoints
Cowley et al. Network Security
Wu Control E-commerce security
Nalavade et al. Denial of Service on TCP/IP Security Protocols: Vulnerabilities, Tools and Countermeasures
Krishnamurthy James Joshi University of Pittsburgh, USA

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20110531