Coders4Africa in action in Senegal a lancé le programme de formation 2012

Coders4Africa (ci-après C4A) a annoncé le lancement de son projet de formation basée sur  la pratique(PPBT) 2012. Le programme vise à offrir aux stagiaires les compétences et les connaissances nécessaires pour prendre des positions appropriées professionnelles en technologies de l'information et de la communication (TIC) diplômés du secteur tout en développant des postes de direction ou de poursuivre des possibilités d'entrepreneuriat. Les stagiaires seront sélectionnés à partir d'un pool de développeurs professionnels, étudiants en informatique et IT amateurs. Le processus de sélection comprend un examen en ligne, une analyse de curriculum vitae et d'une entrevue. En tant que membre de la communauté en ligne C4A est également nécessaire.

La première session de formation se déroulera dans un cadre 13 semaine temps, du 1er Octobre 2012 au 15 Janvier 2013 à Dakar, au Sénégal. Il y aura une pause de deux semaines forcé à cause des vacances de décembre. Après avoir obtenu ses 15 premiers stagiaires de Dakar, la PPBT finira par faire ses tournées à travers le Ghana, le Kenya et le reste des pays africains en 2013-2014.

Compte tenu des développements récents en matière de TIC, programme de formation C4As est basé sur un modèle d'enseignement dans lequel le développement des compétences et l'apprentissage autodirigé sont essentiels. Le programme de formation s'articule autour de quatre domaines de connaissances principaux:

Logiciel d'analyse, de modélisation et de conception

Projet et gestion du changement

Projets de cadre intégré

programme de certification

Nouveau algorithme de hachage SHA-3 dit Keccak a vu le jour.

Le National Institute of Standards and Technology (NIST) a annoncé aujourd'hui le vainqueur de ses cinq années d'concours pour choisir un nouvel algorithme de hachage cryptographique, l'un des outils fondamentaux de la sécurité de l'information moderne. L'algorithme gagnante, Keccak (prononcez «catch-ack»), a été créé par Guido Bertoni, Joan Daemen et Gilles Van Assche de STMicroelectronics et Michaël Peeters de NXP Semiconductors. L'entrée de l'équipe a battu 63 mémoires d'autres que le NIST reçues après son appel ouvert pour les algorithmes de candidats en 2007, quand il a pensé que SHA-2, la norme Secure Hash Algorithm, pourrait être menacée. Keccak sera désormais algorithme de hachage SHA-3 du NIST. Les algorithmes de hachage sont largement utilisés pour des applications cryptographiques qui assurent l'authenticité des documents numériques, tels que les signatures numériques et les codes d'authentification de messages. Ces algorithmes prennent un fichier électronique et de générer un court-circuit "digest", une sorte d'empreinte numérique du contenu. Un bon algorithme de hachage a quelques caractéristiques essentielles. Tout changement dans le message original, même minime, doit provoquer un changement dans le recueil, et pour un fichier donné et à digérer, il doit être impossible pour un faussaire de créer un fichier différent avec la même empreinte. L'équipe du NIST a salué l'algorithme Keccak pour ses nombreuses qualités admirables, y compris son design élégant et sa capacité à bien fonctionner sur de nombreux appareils informatiques différents. La clarté de la construction Keccak se prête à une analyse simple (lors de la compétition tous les algorithmes présentés ont été mis à la disposition du public pour consultation et la critique), et Keccak a de meilleures performances dans les implémentations matérielles que SHA-2 ou l'un des autres finalistes. "Keccak a l'avantage de ne pas être vulnérable de la même manière SHA-2 pourraient être», explique l'expert en sécurité informatique du NIST Tim Polk. "Une attaque qui pourrait travailler sur SHA-2 n'aurait probablement pas travailler sur Keccak parce que les deux algorithmes sont conçus de manière différente." Polk dit que les deux algorithmes de sécurité offrent aux concepteurs une plus grande flexibilité. Malgré les attaques qui ont éclaté autres à peu près semblables, mais plus simple des algorithmes de hachage en 2005 et 2006, SHA-2 a bien résisté et le NIST estime que SHA-2 pour être sûr et approprié pour une utilisation générale. Que sera donc SHA-3 est bon? Alors que Polk dit qu'il peut prendre des années pour identifier toutes les possibilités de Keccak, il fournit immédiatement une police d'assurance indispensable en cas de SHA-2 est jamais rompu. Il spécule également que le caractère relativement compacte de Keccak, il peut être utile pour soi-disant "intégré" ou des dispositifs intelligents qui se connectent à des réseaux électroniques, mais ne sont pas eux-mêmes à part entière ordinateurs. Les exemples incluent des capteurs dans un système de sécurité l'ensemble du bâtiment et les appareils ménagers qui peuvent être contrôlés à distance. "L'Internet tel qu'on le connaît est en pleine expansion pour relier les dispositifs que beaucoup de gens ne pensent habituellement de comme faisant partie d'un réseau," Polk dit. "SHA-3 fournit un nouvel outil de sécurité pour le système et les concepteurs de protocole, ce qui peut créer des opportunités pour la sécurité des réseaux qui n'existaient pas auparavant." Pour en savoir plus sur le concours SHA3, voir http://csrc.nist.gov/groups/ST/hash/sha-3/index.html .

Les huits commandes de base pour la configuration de ASA

IPv6 protocol

Concepts de base sur les listes de contrôle d’accès (ACL)

Les listes de contrôle d’accès sont un mécanisme de sécurité fondamental qui est utilisé pour se prémunir contre les cyber-attaques dans les réseaux modernes. Cet article examine les différents types de listes de   contrôle d'accès que vous pouvez utiliser immédiatement afin d'aider à «durcir» votre réseau.

  Dans les réseaux d’aujourd'hui l'un des problèmes les plus importants que nous devons faire face est la sécurité. Plus précisément, nous avons besoin pour s'assurer que nos équipements  sont "durcis" contre la menace d'une cyber-attaque. Les cyber-attaques peuvent prendre plusieurs formes, mais la majorité des méthodes utilisées pour réduire notre exposition à ces menaces s'appuient sur un outil de réseau très basique. Nous parlons des listes de contrôle d'accès (ACL). Qu'elles sont appliquées directement sur une interface d’un routeur ou d’un switch, ou utilisés dans le cadre d'une configuration de pare-feu, elles sont rapidement devenues l'une de nos premières lignes de défense contre les menaces externes et même internes. En tant que ingénieur en Sécurité réseau, nous avons besoin de comprendre que la sécurité de nos réseaux dépend fortement des listes de contrôle d’accès bien écrites, organisées, et concises  pour restreindre l'accès aux services  réseau. Nous allons jeter un regard critique sur les différents types d'ACL, et plus précisément la façon dont ils peuvent être identifiées et  appliquées.

Dans l’IOS, les ACL sont divisés en deux types: IP access-lists Standards et Etendues. Ici, nous allons couvrir les bases mêmes associés à chacun de ces types qui se rapportent à IPv4 et au protocole TCP.

• ·        ACL Standard sont utilisées pour filtrer les paquets IP en fonction de la seule adresse source.

• ·         ACL Etendues sont utilisées pour filtrer les paquets en fonction de plusieurs critères, y compris mais pas exhaustif  ce qui suit:

o   Adresse IP source

o   Adresse IP de destination

o   Ports source TCP / UDP

o   Ports de destination TCP / UDP

  Sous peu nous allons regarder de plus près chaque type d’ACL, mais ce que nous devons comprendre maintenant, c'est que les ACLs  étendues comme leur nom l’indique nous offrent beaucoup plus de souplesse que les  ACLs standard. Nous verrons, cependant, que l’IOS utilise le  meilleur d’entre les deux pour le travail et les différences entre ces types d'ACL seront dans la façon dont elles  sont utilisées et appliquées.

Comment pouvons-nous identifier les différents types de listes de contrôle d'accès? 

Soit un numéro ou un nom permet d'identifier une ACL et les protocoles qu'elle filtre. Nous allons discuter du nom des listes d'accès plus tard. En ce qui concerne l’ACL numérotée, le numéro de l'ACL détermine quel protocole est filtré. Nous avons déjà mentionné que nous nous concentrons uniquement sur les ACL utilisées avec les protocoles TCP/IP, ce qui signifie que nous allons examiner la plage de numéros utilisés par ces protocoles. Il est important d'observer cependant que ces ACL permet de filtrer des protocoles autres que ceux TCP/IP.

 Lorsque nous créons une ACL numérotée nous lui attribuons une valeur numérique qui a  un double objectif. D'abord, elle spécifie le protocole qui fera l’objet de filtrage et ensuite elle identifie  localement l'ACL de façon unique. Nous pouvons avoir jusqu'à 99 listes d'accès standard allant de 1 à 99; la plage de numéros des ACL étendues est de 100 à 199.

Après une courte période de temps, il a été décidé que de nombreux environnements nécessitaient des plages plus étendues aussi bien pour les ACL standard que étendues LCA étendues, de sorte que Cisco élargisse la plage pour  chaque type. Maintenant, nous pouvons utiliser des numéros allant de 1300 à 1999 pour les autres ACL standard et 2000 à 2699 pour ajouter des ACL étendues.
 

Maintenant que nous savons comment identifier les ACL, nous avons besoin de voir  un peu plus près à chaque type:

A quoi ressemblent  les ACL standard  sur ​​un routeur?

Une liste de contrôle d'accès standard ne vous permet d'autoriser ou de refuser le trafic provenant d'adresses IP spécifiques. La destination du paquet et les ports impliqués n'ont pas d'importance.

Voici un exemple:

          access-list 10 permit 192.168.1.0 0.0.0.255

Cette liste autorise tout trafic provenant  des adresses dans la plage 192.168.1.0 à 192.168.1.255

Vous pouvez voir comment la dernière entrée ressemble à un masque de sous réseau, mais les ACL Cisco utilisent un masque générique. Une autre règle très importante à propos des listes de contrôle d'accès, c'est qu'il y’a toujours un «DENY implicite » à la fin de chaque ACL. Ce que cela signifie, c'est que chaque ACL standard a une instruction invisible à la fin de celle-ci. Dans notre exemple, ce serait

         access-list 99 deny any

Donc, si votre trafic n’est  pas expressément autorisé par une déclaration dans l’ACL Standard, alors il est REJETE. Si vous tapez manuellement la déclaration « deny any » elle apparaîtra, mais rappelez-vous, même si vous ne l'inscrivez pas, elle est toujours là.

A quoi  ressemblent les ACL étendues sur le routeur?

Les ACL étendues nous permettent d'autoriser ou refuser le trafic d'une adresse IP source  et d’un port spécifiques à une adresse IP de destination et un port spécifiques. Elles  peuvent également être utilisées  pour spécifier différents types de trafic tels que ICMP, TCP, UDP, etc. Cela rend les ACL  étendues très granulaire et nous permet d'être très précis sur ce que nous voulons filtrer. A titre d'exemple:

           

       access-list 103 permit tcp any 192.168.0.0 0.0.255.255 eq 80

          access-list 103 permit tcp any host 192.168.1.3 eq 23

 Dans cet exemple, l’ACL étendue 103 autorise le trafic de n'importe quelle source et destiné  vers n'importe quelle adresse allant de 192.168.0.0 à 192.168.255.255 qui correspond au port 80.

Le deuxième numéro de séquence autorise tout le trafic telnet destiné à  192.168.1.3. Qu’en est-il si un trafic  telnet (port 23) est destiné à l'adresse IP 192.168.1.1?

Rappelez-vous du deny implicite. Ce trafic serait bloqué par l'ACL. Cela nous amène à une chose supplémentaire que nous devrions examiner ce qui concerne comment les ACL fonctionnent.

Processus Top Down
 
Les lignes d'une ACL sont traitées dans une séquence de haut en bas dans l'ordre où ils sont configurés. Quand un paquet en cours de traitement par le biais d’une ACL correspond à une déclaration faite dans la liste, tout le traitement pour ce paquet est arrêté. A titre d'exemple:

           access-list 1 deny 10.10.10.10

             access-list 1 deny 11.11.11.11

             access-list 1 permit 10.10.10.10

Dans le cas où cette ACL est utilisé pour filtrer le trafic entrant sur une interface et un paquet IP arrive avec une adresse source de 10.10.10.10, le trafic sera-t-il autorisé ou refusé? Afin de donner la réponse  nous avons besoin de regarder l’ACL  elle-même. C’est parce que les listes de contrôle d'accès seront traitées à partir du haut vers le bas que le trafic sera refusée. Cela se produit même si il est permis plus tard en bas de la liste. L’important chose que nous de garder à l'esprit est que l'ordre du permit et du deny est essentielle.

Les trois règles d'ACL et filtrage du trafic

La règle d'or quand il s'agit d’ACL est que vous pouvez avoir qu'une seule ACL par protocole, par direction, par interface. Cela signifie que vous pouvez utiliser une liste d'accès pour chaque protocole (IP, TCP, Telnet, etc.) Vous ne pouvez avoir une seul ACL pour chaque direction IN ou OUT. Vous pouvez appliquer une ACL sur chaque interface de type FastEthernet ou de Serial. En termes simples, vous n'êtes pas autorisé à avoir deux  ACL  sur la même Interface. Dans les situations où cela peut être une exigence, il sera nécessaire de les combiner en une seule ACL. Encore une fois, gardez à l'esprit que l'ordre utilisé pour construire ce combiné ACL est essentiel.

Où allons-nous appliquer les ACL?

Comme l’ACL standard filtre en fonction de l'adresse IP source d'un paquet, il est plus efficace de l’appliquer  le plus près possible de la destination du paquet. Si vous ne l'appliquez pas à proximité de la destination et choisissez  de l'appliquer près de la source, l'ACL peut accidentellement filtrer  un trafic qui nous ne voulons pas filtrer.
En règle générale, les ACL étendues peuvent être placés n'importe où, car elles filtrent  à la fois en fonction la source et la destination du paquet. Cependant, il  est recommandé de les appliquer le plus près possible  de la source. L'application de ces ACL près de la source permettra d'économiser des ressources telles que les cycles de CPU et la bande passante. Si un paquet doit être refusée, alors il n'y a pas de sens de le laisser être transmis à la destination en gaspillant des ressources, elle doit être refusée à proximité de la source afin d'éviter le gaspillage de bande passante.

Comment les ACL sont-elles appliquées ?

Les ACL doivent être appliqués sur une interface d’un routeur pour qu’elles aient un effet. Il est important de noter que les ACL sont appliqués sur une interface en fonction de la direction du flux de données qu’on souhaiterait filtrer :

• Inbound (in) signifie que l’ACL filtre les paquets entrant par l’interface du routeur

• Outbound (out) signifie que l’ACL est appliquée aux paquets qui quittent l’interface du routeur

Avant d’appliquer l’ACL sur une interface, il est nécessaire de savoir dans quelle direction elle va filtrer. Une fois la direction connue, on utilise la commande  « ip  access-group » en mode de configuration interface. Sur le routeur cela ressemblera à quelque chose du genre :

              R1(config)# interface Fa0/0

                  R1(config-if)# ip access-group 2 in

                  R1(config)# interface Fa0/1

                  R1(config-if)# ip access-group 3 out

                  R1(config-if)# exit

Dans cet  exemple, nous voyons que nous avons appliqué ACL 2 et ACL 3 sur deux interfaces différentes.

Une pratique très courante de la sécurité dans le monde réel est de créer une ACL qui filtre tout ce qui provient  de nos réseaux internes, et ensuite appliquer cette ACL entrant sur ​​toutes les interfaces externes qui font face à nos réseaux internes. Ce processus permettra d'éviter un cyber attaquant d'utiliser la célèbre attaque "usurpation d'adresse IP"  contre le réseau. Dans une attaque par usurpation d’adresse IP, l'accès non autorisé à des hôtes du réseau et des services est acquis par un intrus qui envoie messages à un hôte interne avec une adresse IP faisant semblant d'être un message à partir d'un hôte interne de confiance. L’application d'une ACL qui refuse tout le trafic provenant de tout sous-réseau que nous utilisons sur notre réseau pourra  immédiatement prévenir ce type d'attaque.

Conclusion
Comprendre l'utilisation correcte des ACL de Cisco IOS est une exigence essentielle pour n'importe quel ingénieur réseau en herbe. Dans ce blog, nous avons examiné les éléments essentiels de la liste de contrôle d'accès que chacun devrait connaître y compris la façon de créer et de les appliquer. Nous avons analysé comment des listes d'accès peut être utilisé pour filtrer le trafic qui circule à travers le réseau, mais il ya tellement d'options et d’utilisations que nous n’avons pu explorer ici. Pour en savoir plus, rendez-vous à votre routeur et le type access-list?, Ou consultez la documentation Cisco sur des listes d'accès

Configuring a Cisco Router for Remote Administration Using the Router Console

Un canal sécurisé est nécessaire pour l'administration à distance des routeurs Cisco. Cisco fournit un support pour SSH et IPSec comme moyen pour un tel canal. Toutefois, au moment d'écrire ces lignes, la mise en œuvre de Cisco de SSH ne peut pas être recommandé comme leur IOS routeur prend en charge uniquement comme groupe d'authentification le groupe 1 Diffie-Hellman . L' utilisation d'un tunnel VPN IPSec avec le groupe 5 Diffie-Hellman  comme groupe d'authentification est recommandé pour les réseaux à forte valeur ajoutée avec une stratégie de migration vers Diffie-Hellman groupe 14 dès qu'elle sera disponible.
Ce document détaille la configuration du routeur pour établir un tunnel VPN IPSec à partir d'un PC fonctionnant sous Windows 2000/XP doté d'un Client VPN .



Pour cette configuration, il y aura un routeur Cisco à administrer et un PC de gestion. Le PC de gestion aura l'adresse IP 192.168.45.67 et le routeur Cisco sera administré grâce à son interface avec l'adresse IP 192.168.45.100. Voir Figure

Configuration du réseau

  

Paramètres des politiques de sécurité

La politique  de sécurité IKE phase 1 ou une SA ISAKMP avec les paramètres suivants:

• Triple-DES comme algorithme de chiffrement
• SHA-1 comme algorithme de hachage
• groupe 5 Diffie-Hellman comme groupe d'authentification
• clé partagée comme méthode d'authentification 

La politique de sécurité IKE phase 2 avec les paramètres suivants:

• Triple-DES comme algorithme de chiffrement
• SHA-1 comme algorithme de hachage
• Transport comme mode du tunnel

Configuration des paramètres de IPsec sur le routeur Cisco

Les commandes suivantes permettent de définir la politique de sécurité IKE phase 1  de priorité 20 ou une SA ISAKMP avec comme 3-DES comme algorithme de chiffrement, SHA-1 comme algorithme de hachage, clé partagée comme méthode d'authentification et le group 5 comme groupe d'authentification Diffie-Hellman.

router#config t

router(config)# crypto isakmp policy 20

router(config-isakmp)# encr 3des

router(config-isakmp)# hash sha

router(config-isakmp)# authentication pre-share

router(config-isakmp)# group 5

router(config-isakmp)# exit

router(config)#

 On donne la clé partagée "thepassphrase" et l'addresse IP du peer avec qui le routeur partage la clé c'est à dire le PC de gestion par la commande suivante:

router(config)#crypto isakmp key 0 thepassphrase address 192.168.45.67

 Les commandes suivantes définissent  IKE phase 2 en donnant la transform-set nommé admin_3des destiné à la crypto map ultérieure avec esp-3des comme algorithme de chiffrement et esp-sha-hmac comme algorithme d'authenfication et transport comme mode du tunnel

router(config)# crypto ipsec transform-set admin_3des esp-3des esp-sha-hmac

router(cfg-config-trans)# mode transport

router(cfg-config-trans)# exit

router(config)#

Enfin, une crypto map doit être créé et ensuite appliquée à l'interface appropriée du routeur. La crypto map utilise une ACL pour indiquer que le trafic sortant doit être crypté. Ce sera le trafic du routeur vers le PC  de gestion.L' ACL est crée par la commande:

router(config)# access-list 192 permit ip host 192.168.45.100 host 192.168.45.67

 On lance la procédure de création d'une crypto map de priorité 10 nommée ADMIN_MAP avec une politique de gestion automatique des clés en trois phases:

• set peer donne le correspondant
• set transform-set admin_3des donne le transform-set associé à la crypto map
• match address 192 donne le trafic à chiffrer déterminé par l'ACL 192

router(config)# crypto map ADMIN_MAP 10 ipsec-isakmp

router(config-crypto-map)# set peer 192.168.45.67

router(config-crypto-map)# set transform-set admin_3des

router(config-crypto-map)# match address 192

router(config-crypto-map)# exit

router(config)#

La crypto map est appliquée sur l'interface appropriée du routeur grâce aux commandes suivantes:


                  router(config)# interface fastethernet 0/1 

 router(config-if)# crypto map ADMIN_MAP  

 router(config-if)# exit 

 router(config)# exit

 router#

Cela fournira une connexion sécurisée pour l'administration du routeur en utilisant, par exemple, une connexion telnet.

Source:SNAC/NSA

CONFIGURATION D'UN VPN-IPSEC POUR ROUTEUR CISCO

Une entreprise peut avoir besoin d’une connexion WAN entre deux sites.

Dans certains cas (liaison de secours ou liaison WAN pas cher) nous pouvons utiliser un tunnel IPSEC. IPSEC est une technologie VPN qui fonctionne sur la couche3 du model OSI. C’est aussi un standard IETF, ce qui signifie que nous pouvons l’utiliser entre des équipements de différents fabricants.

Les VPN IPSEC permettent :

•   Une authentification de chaque paquet IP.

•  Une vérification de l’intégrité des données de chaque paquet.

•  De rendre confidentiels les données de chaque paquets IP.

IPSEC est un “Framework” qui spécifie plusieurs protocoles à utiliser afin de fournir un standard de sécurité.Les protocoles spécifiés par IPSEC sont :
  
InternetKey Exchange : IKE

IKE va nous permettre de négocier des paramètres de sécurités et créer les clés d’authentification utilisée par le VPN. IKE va permettre d’établir un échange de clé de manière sécurisé sur un réseau « non sécurisé ».

Encapsulating Security Payload: ESP

Le plus utilisé par IPSEC, ESP va encrypté les données. ESP protège également contre des attaques basées sur du trafic « replayed ».

Authentication Header : AH

AH fournit de l’authentification de la donnée. Il est peu utilisé, ESP étant plus efficace et cryptant le tout.

Plus tard dans notre configuration nous utiliserons ESP puisqu’il permet de crypter les données en utilisant DES, 3DES ou AES. AH ne permet pas cela.

Les VPN IPSEC utilisent le protocole IKE afin d’établir une communication sécurisé entre deux « peers» à travers un réseau non sécurisé. IKE utilise l’algorithme de DIFFIE-HELLMAN afin d’échange des clés symétriques entre deux « peers » et de configurer les paramètres de sécurité associés au VPN. IKE

utilise le port UDP 500 et envoie des « keepalive » toutes les 10 secondes.

IKE:

•  Elimine le besoin de spécifier manuellement tous les paramètres de sécurité sur chaque «peer». 
• Permet de configurer une durée de vie pour le SA (Security association) de IPSEC. Une SA est un «ensemble de contrat de sécurité ». 
• Permet de changer les clés de chiffrement pendant la session IPSEC 
• Permet de fournir des services « anti-replay » 
• Supporte l’architecture PKI. 
•  Permet une authentification dynamique de chaque peer.

Apres ces quelques explications nous allons voir comment configurer un VPN IPSEC.

Nous avons deux sites (Paris et Chine). Nous avons déjà une connexion WAN qui fonctionne entre les deux sites. Nous souhaitons configurer une connexion VPN entre PARIS et CHINE qui servira de connexion de secours. Nous décidons d’utiliser notre connexion Internet qui coûte moins cher qu’une connexion ISDN. Mais pour cela nous devons crypter notre traffic.

Voici les différentes étapes de configuration :

1. Définir les règles de sécurité ISAKMP

2. Configurer les « transform set »

3. Configurer une ACL qui spécifiera quel trafic peut/doit emprunter le VPN.

4. Configurer une « crypto-map »

5. Appliquer la « crypto-map » sur l’interface

6. Configurer une ACL si besoin sur l’interface « outside » (en option)

Nous devrons exécuter ces étapes de configurations sur les routeurs de PARIS et CHINE. 

Définir une règle de sécurité ISAKMP

Nous devons d’abord activer le moteur « isakmp »en utilisant la commande :

CHINA(config)# crypto isakmp enable

PARIS(config)# crypto isakmp enable

Nous utiliserons la commande suivante afin d’activer le moteur « software » au cas où notre routeur ne disposerait pas de moteur « hardware ».

CHINA (config)# crypto engine software ipsec

PARIS (config)# crypto engine software ipsec

Dans cet article nous utiliserons une « clé partagé » (Pre Shared Key) pour l’authentification. Elle doit être associée à un « peer » distant qui utilise la même « clé partagé ». (Ici la PSK est labo-cisco).

CHINA (config)#crypto isakmp key labo-cisco address 192.168.0.6

PARIS(config)# crypto isakmp key labo-cisco address 192.168.0.1

 Nous allons maintenant utiliser les paramètres suivant pour notre VPN sur les deux routeurs:

• Authentication mode : Pre shared key (Nous pouvons aussi utiliser des « Username & Password »,   OTP, ou des certificats).

• Hash Method: SHA (md5 or sha)

•   Encryption type : AES 192 (DES est par défaut, l’encryption AES peut utiliser de 128 à 256 bits)

•   Diffie-Hellman group à utiliser : 1 or 2 (group 1 est basé sur 768-bit et group 2 est basé sur 1024 bits).

• Lifetime of the exchanged key : Nous utiliserons 3600 pour 1 heure.(Par défaut 86400 secondes)

  Donc au final nous configurerons nos routeurs comme cela :

CHINA(config)#crypto isakmp policy 1

CHINA (config-isakmp)# encr aes 192

CHINA (config-isakmp)# authentication pre-share

CHINA (config-isakmp)# group 2

PARIS(config)#crypto isakmp policy 1

PARIS (config-isakmp)# encr aes 192

PARIS (config-isakmp)# authentication pre-share

PARIS (config-isakmp)# group 2

Configuration des « transform-set »

Une « transform-set » est une combinaison d’algorithmes et protocoles de sécurité «acceptable». Les « peers » essaieront de trouver la meilleure combinaison possible selon les configurations et

capacités de chaque point de chute du VPN en se basant sur les « transform-set » disponibles

Configuration: 

CHINA(config)#crypto ipsec transform-set TSET esp-aes192  esp-sha1-hmac

PARIS(config)#crypto ipsec transform-set TSET esp-aes192 esp-sha1-hmac

* TSET est le nom du « transform-set » situé sur le routeur (portée locale)

* “esp-aes” précise que nous allons encrypter en utilisant ESP et AES.

* “192” est le nombre de bits utiliser pour le cryptage.

* esp-sha1-hmac comme transform d’authentification

Apres avoir entré cette commande nous avons un nouveau mode de configuration ou nous pouvons configurer notre VPN en mode « Transport » ou « Tunnel »

Le mode « Tunnel » encryptera tout le « datagram » (y compris les IP sources et destination, gênant ainsi la QOS) alors que le mode « Transport » encryptera seulement la donnée présente dans le

paquet IP (peut poser un problème de sécurité car une personne malveillante peut ainsi voir les vrai IP

source et destination de chaque paquet IP).

Ici nous allons utiliser le mode « Tunnel » :

CHINA(config)#mode  tunnel

PARIS(config)#mode  tunnel

Configurer une ACL qui spécifiera quel trafic peut/doit emprunter le VPN

Ici nous allons autoriser le traffic depuis le lan de PARIS vers le lan de CHINE. Il faut utiliser une ACL étendue.

Sur Chine :

CHINE (config)#access-list 101 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255

Et sur Paris :

PARIS(config)#access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255

Configurer la « crypto-map »

Une « crypto-map » est comme un profil, qui va associer les ACL (crypto-ACL) , « transform-set »

configuré précédemment avec l’adresse IP du « peer » distant.

Sur CHINA nous entrerons les commandes suivante :

CHINA(config-crypto-map)#crypto map VPN-2-MAIN 10 ipsec-isakmp match address 101

CHINA(config-crypto-map)#set peer 192.168.0.6

CHINA(config-crypto-map)#set transform-set TSET

Et sur Paris :

PARIS(config-crypto-map)#crypto map VPN-2-Remote 10 ipsec-isakmp match address 101

PARIS(config-crypto-map)#set peer 192.168.0.1

PARIS(config-crypto-map)#set transform-set TSET

Appliquer la « Crypto-map » sur l’interface

PARIS(config-if)#crypto map VPN-2-Remote

CHINE(config-if)#crypto map VPN-2-MAIN

Voici la maquette utilisée pour tester cette configuration : La version d' IOS utilisé est la 12.4(1).

Comme nous pouvons le voir dans la table de routage tout trafic provenant du LAN 10.0.1.0/24 vers 10.0.2.0/24 utilisera la liaison WAN principale.

Si celle-ci est inutilisable, rien ne se passera même si nous avons configuré le VPN IPSEC sur les deux routeurs.

Nous pouvons ajouter une route statique flottante (AD plus grande que l’AD de RIP) qui peut ainsi relayer la liaison principale arrête de fonctionner.

Il suffit de taper:

PARIS(config)#ip route 10.0.1.0 255.255.255.0 192.168.0.1 140

CHINE(config)#ip route 10.0.2.0 255.255.255.0 192.168.0.6 140

Nous pouvons tester cela:

Sur l’ordinateur A nous faisons un « traceroute » vers l’ordinateur B :

 

Maintenant nous allons tester la route statique flottante quand la liaison principale est non utilisable.

Faisons un autre « traceroute » afin de confirmer que nous utilisons bien notre VPN.