vendredi 25 avril 2014

Implementation de GETVPN dans les CEs au niveau d'une architecture MPLS/VPN

Topologie




Introduction


Le GET VPN ça sert à quoi déjà ? Vous avez peut être un super VPN MPLS au bureau qui marche super mais ça vous embête un petit peu d’avoir votre trafic qui se balade en clair. On peut donc mettre du DMVPN, mais on parleras de VPN Overlay dans la mesure ou on réencapsule les paquets et donc on rajoute une surcouche IP, donc on perd l’intérêt du VPN MPLS. Avec le GET VPN, on laisse le backbone MPLS s’occuper du VPN, et nous (le client) on s’occupe du chiffrement du traffic entre les équipement client (le provider n’a pas a gérer la configuration).
Pour fonctionner, le GETVPN utilise une variante de isakmp qui s’appelle GDOI qui permets la synchronisation des clés de sessions IPSec entre les différents clients, le principe du GET VPN étant d’être multicast, tous les clients auront la même clé de chiffrement à l’instant T (TEK – Traffic encryption key) et un rekeying global de cette TEK s’éffectura de temps en temps via la KEK (Key Encryption Key)

Pour fonctionner, le GETVPN utilise une variante de isakmp qui s’appelle GDOI qui permets la synchronisation des clés de sessions IPSec entre les différents clients, le principe du GET VPN étant d’être multicast, tous les clients auront la même clé de chiffrement à l’instant T (TEK – Traffic encryption key) et un rekeying global de cette TEK s’éffectura de temps en temps via la KEK (Key Encryption Key)

Config initiale

Bon je penses que ceux qui suivent un peu mon blog doivent être familier avec les VPNMPLS donc on va passer les détails de la config 
On va commencer par faire une petite capture de ping entre C1 et C2 et faire un capture au niveau de F2/0 de core 1 pour voir ce qu’il ressort:
C1#ping 10.1.2.2 data DEAD repeat 20

Type escape sequence to abort.
Sending 20, 100-byte ICMP Echos to 10.1.2.2, timeout is 2 seconds:
Packet has data pattern 0xDEAD
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 52/106/192 ms
ce qui nous donne:

Mise en place du serveur de certificats IOS

Alors vu que j’ai pas envie de démarrer une VM en CA, et qu’on a pas vu comment faire un CA sous IOS, et bien on va le faire ici.
Le procédure est dispo ici:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080210cdc.shtml
En gros on génère des clés exportables, on les exportes sous forme de certificats, on active le serveur sur un des routeurs (ici core 1) et on va enroller les autres sur ce serveur CA.
c1(config)#crypto key generate rsa general-keys label carsa exportable modulus 512
% They will be replaced.

% The key modulus size is 512 bits
% Generating 512 bit RSA keys, keys will be exportable...[OK]

c1(config)#
*Oct  4 17:24:40.303: %SSH-5-DISABLED: SSH 1.5 has been disabled
*Oct  4 17:24:41.227:  RSA key size needs to be atleast 768 bits for ssh version 2
c1(config)#
*Oct  4 17:24:41.243: %SSH-5-ENABLED: SSH 1.5 has been enabled
!export format PEM, encryption clé privée DES, pass cisco 123
!Je suis pas sur que ça soit obligatoire, je penses que c'est plutot
!pour archiver les clés si on les perds mais j'ai pas testé sans
c1(config)#crypto key export rsa carsa pem url nvram: 3des cisco123
% Key name: carsa
 Usage: General Purpose Key
Exporting public key...
Destination filename [carsa.pub]?
Writing file to nvram:carsa.pub
Exporting private key...
Destination filename [carsa.prv]?
Writing file to nvram:carsa.prv
c1(config)#ip http server !activation HTTP pour SCEP
c1(config)#crypto pki server carsa
c1(cs-server)#database url nvram:
c1(cs-server)#database level names !on stock en plus le nom de chaque certificat
! par défaut minimum = juste le contenu crypto
core1(cs-server)#issuer-name CN=c1 L=MYDESK C=BE
! L = location, C = country
c1(cs-server)#no shut
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password: cisco123 
Re-enter password: cisco123
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
% Exporting Certificate Server signing certificate and keys...

% Certificate Server enabled.
c1(cs-server)#
*Oct  4 17:36:57.087: %PKI-6-CS_ENABLED: Certificate server now enabled.
c1(cs-server)#do write
Building configuration...
[OK]
c1(cs-server)#exi
c1(config)#
Voilà normalement on est bon ici.
On va maintenant « enroller » nous routeurs afin qu’ils puissent s’authentifier les uns et les autres.
Je rappelle la procédure, on fait un trustpoint afin d’obtenir le certificat du CA (via la commande crypto ca authenticate), et ensuite on s’enroll (on demande notre certificat).
c2(config)#crypto ca trustpoint carsa
! vu que j'ai pas mis de CRL dans mon CA ça pourrait déconner
c2(ca-trustpoint)#revocation-check none
c2(ca-trustpoint)#enrollment url http://10.1.1.2:80
c2(ca-trustpoint)#exi
c2(config)#crypto ca authenticate carsa
Certificate has the following attributes:
 Fingerprint MD5: F9060FED EFDD437B 0971B86E 2CC79D65
 Fingerprint SHA1: 9261C779 35420504 12F77C07 B0EF5938 66F3DC48 

% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
c2(config)#crypto ca enroll carsa
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
 password to the CA Administrator in order to revoke your certificate.
 For security reasons your password will not be saved in the configuration.
 Please make a note of it.
!password défini lors du no sh du CA
Password: cisco123
Re-enter password: cisco123 

% The subject name in the certificate will include: c2
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose carsa' commandwill show the fingerprint.

c2(config)# ! voilà la requête de certificat, il faut maintenant l'approuver
*Oct  4 17:46:27.135: CRYPTO_PKI:  Certificate Request Fingerprint MD5: 4D9971C8 F02B5822 B4062ABE E4FD370A
*Oct  4 17:46:27.147: CRYPTO_PKI:  Certificate Request Fingerprint SHA1: 1CD7E7FA B4A4016E 5A7D4F9E FEDD64BD D3234946
c2(config)#
on va donc sur C1:
C1#sh crypto pki server carsa requests
Enrollment Request Database:

Subordinate CA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

RA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

Router certificates requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------
1      pending    B50C87B6E5AD25927EFDB485EF0003ED hostname=C2

C1#crypto pki server carsa grant 1
C1#sh crypto pki server carsa requests
Enrollment Request Database:

Subordinate CA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

RA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

Router certificates requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------
1      granted    B50C87B6E5AD25927EFDB485EF0003ED hostname=C2
on doit voir sur C2:
*Oct  4 18:17:32.151: %PKI-6-CERTRET: Certificate received from Certificate Authority
Maintenant on fait pareil sur C3 ET C1 (les certificats sur C1 servent pour le serveur, pas pour que notre routeur s’authentifie !).

Configuration du GET VPN

Donc le chiffrement va se faire au niveau des clients (C#). Au niveau du process, on a une isakmp (1ère phase uniquement) qui va permettre d’établir une connexion sécurisée entre les différents routeurs, puis GDOI (port UDP 848, ISAKMP=500) va gérer les clés IPSec (au lieu de la phase 2 isakmp).
On a un routeur qui fera office de keyserver (KS) et qui distribuera les TEK ainsi que les message de rekeying, et aura aussi la fonction d’indiquer aux autres routeurs (Group member) le traffic à sécuriser (via une ACL).
Note: on peut redonder les KS.
Note2 (edit): Le KS ne peut, à ma connaissance forwarder du trafic, il est uniquement la pour synchroniser les différents routeurs afin qu’ils puissent communiquer de manière sécurisée, mais ne communique pas. Si quelqu’un toutefois à réussi à faire en sorte que le KS puisse forwarder du trafic, je suis preneur !
Il faut donc que tous nos routeurs aient une policy isakmp identique:
C1(config)#crypto isakmp policy 666
C1(config-isakmp)#auth rsa-sig
C1(config-isakmp)#hash sha
C1(config-isakmp)#group 5
C1(config-isakmp)#exi
Ensuite, coté KS, on créé un transform set et un profile ipsec qui utilise ce transform set, puis une ACL pour le traffic à chiffrer, et enfin la config GDOI.
C1(config)#crypto ipsec transform-set TSET1 esp-aes
C1(cfg-crypto-trans)#mode transport
C1(cfg-crypto-trans)#exi
C1(config)#crypto ipsec profile P1
C1(ipsec-profile)#set transform-set TSET1
C1(ipsec-profile)#exi
C1(config)#ip access-list extended private-traffic
C1(config-ext-nacl)#deny udp any eq 848 any eq 848 ! on chiffre pas GDOI
C1(config-ext-nacl)#permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255
C1(config-ext-nacl)#exi
C1(config)#crypto gdoi group GETVPN1
C1(config-gdoi-group)#identity number 1234 ! doit matcher sur les GM
C1(config-gdoi-group)#server local
C1(gdoi-local-server)#rekey ? ! ici je laisse tout par défaut
 address         Define the rekey packet format
 algorithm       Set the rekey encryption algorithm
 authentication  Identify the rekey authentication keypair
 lifetime        Define the rekey lifetime
 retransmit      Define the rekey retransmission parameters
 transport       Specify the rekey distribution method

C1(gdoi-local-server)#sa ipsec 1
C1(gdoi-sa-ipsec)#profile P1
C1(gdoi-sa-ipsec)#match address ipv4 private-traffic
C1(gdoi-sa-ipsec)#exi
C1(gdoi-local-server)#address ipv4 10.1.1.2 !interface d'écoute
C1(gdoi-local-server)#exi
C1(config-gdoi-group)#exi
Coté client on va voir que c’est beaucoup plus simple, tout est géré par le KS quasiment:
C2(config)#crypto gdoi group GETVPN1
C2(config-gdoi-group)#identity number 1234
C2(config-gdoi-group)#server address ipv4 10.1.1.2
C2(config-gdoi-group)#exi
C2(config)#crypto map GETMAP 10 gdoi
% NOTE: This new crypto map will remain disabled until a valid
 group has been configured.
C2(config-crypto-map)#set group GETVPN1
C2(config-crypto-map)#exi
C2(config)#int F1/0
C2(config-if)#crypto map GETMAP
Et la normalement, tout est bon.
J’ai eu quelques messages sur C2 et C3:
*Oct  4 18:47:43.275: %CRYPTO-5-GM_REGSTER: Start registration to KS 10.1.1.2 for group GETVPN1 using address 10.1.3.2
C3(config-if)#dow
*Oct  4 18:47:43.307: %CRYPTO-6-IKMP_NO_PRESHARED_KEY: Pre-shared key for remote peer at 10.1.1.2 is missing
*Oct  4 18:47:43.319: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
C3(config-if)#do
*Oct  4 18:47:45.743: %GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.1.2 complete for group GETVPN1 using address 10.1.3.2
Ce qui je penses est du au fait que les policy isakmp par défaut sous IOS 15.0 utilise les PSK, et vu que j’ai fait une policy démoniaque (#666) ce n’était peut être pas la première testée, en conséquence de quoi les routeurs veulent s’auth via PSK, ils trouvent pas de PSK, ils passent en rsa-sig
quelques vérifs:
C1#sh crypto gdoi
GROUP INFORMATION

 Group Name               : GETVPN1 (Multicast)
 Group Identity           : 1234
 Group Members            : 2
 IPSec SA Direction       : Both
 Group Rekey Lifetime     : 86400 secs
 Rekey Retransmit Period  : 10 secs
 Rekey Retransmit Attempts: 2

 IPSec SA Number        : 1
 IPSec SA Rekey Lifetime: 3600 secs
 Profile Name           : P1
 Replay method          : Count Based
 Replay Window Size     : 64
 SA Rekey
 Remaining Lifetime  : 3300 secs
 ACL Configured         : access-list private-traffic

 Group Server list       : Local

C1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.1.1.2        10.1.2.2        GDOI_IDLE         1005 ACTIVE
10.1.1.2        10.1.3.2        GDOI_IDLE         1006 ACTIVE

IPv6 Crypto ISAKMP SA
!!!!!!!!!!!!
C2#sh crypto gdoi ipsec sa

SA created for group GETVPN1:
 FastEthernet1/0:
 protocol = ip
 local ident  = 10.1.0.0/16, port = 0
 remote ident = 10.1.0.0/16, port = 0
 direction: Both, replay: Disabled

C2#sh crypto gdoi gm      
Group Member Information For Group GETVPN1:
 IPSec SA Direction       : Both
 ACL Received From KS     : gdoi_group_GETVPN1_temp_acl

 Group member             : 10.1.2.2         vrf: None
 Registration status   : Registered
 Registered with       : 10.1.1.2
 Re-registers in       : 3001 sec
 Succeeded registration: 1
 Attempted registration: 5
 Last rekey from       : 0.0.0.0
 Last rekey seq num    : 0
 Multicast rekey rcvd  : 0
Notez que le KS ne peut faire partie du VPN, ce que je n’avais prévu, sinon j’aurai rajouté un routeur. Pour le KS, il doit soit avoir une connexion dédiée accessible depuis tous les GM, soit être connecté derrière un GM (le GM ne doit pas passer par le KS pour avoir accès au VPN).
Bon pour que vous soyez pas trop déçu, je vous redonne quelques commandes show coté KS:
C1#sh crypto gdoi ks members 

Group Member Information : 

Number of rekeys sent for group GETVPN1 : 0

Group Member ID    : 10.1.2.2
 Group ID          : 1234
 Group Name        : GETVPN1
 Key Server ID     : 10.1.1.2

Group Member ID    : 10.1.3.2
 Group ID          : 1234
 Group Name        : GETVPN1
 Key Server ID     : 10.1.1.2

C1#sh crypto gdoi ks po      
C1#sh crypto gdoi ks policy
Key Server Policy:
For group GETVPN1 (handle: 2147483650) server 10.1.1.2 (handle: 2147483650):

 # of teks : 1  Seq num : 0
 kek policy : FALSE 

 TEK POLICY (encaps : ENCAPS_TRANSPORT)
 spi                : 0xFA94E73B
 access-list        : private-traffic
 transform          : esp-aes
 alg key size       : 16            sig key size          : 0         
 orig life(sec)     : 3600          remaining life(sec)   : 411       
 tek life(sec)      : 3600          elapsed time(sec)     : 3189      
 override life (sec): 0             antireplay window size: 64        

C1#sh cry
C1#sh crypto se
C1#sh crypto session
Crypto session current status

Interface: FastEthernet1/0
Session status: UP-IDLE
Peer: 10.1.2.2 port 848
 IKE SA: local 10.1.1.2/848 remote 10.1.2.2/848 Active 

Interface: FastEthernet1/0
Session status: UP-IDLE
Peer: 10.1.3.2 port 848 
 IKE SA: local 10.1.1.2/848 remote 10.1.3.2/848 Active 

C1#
et coté GM
C2#sh crypto ipse sa

interface: FastEthernet1/0
 Crypto map tag: GETMAP, local addr 10.1.2.2

 protected vrf: (none)
 local  ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
 remote ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
 current_peer 0.0.0.0 port 848
 PERMIT, flags={origin_is_acl,}
 #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
 #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
 #pkts compressed: 0, #pkts decompressed: 0
 #pkts not compressed: 0, #pkts compr. failed: 0
 #pkts not decompressed: 0, #pkts decompress failed: 0
 #send errors 0, #recv errors 0

 local crypto endpt.: 10.1.2.2, remote crypto endpt.: 0.0.0.0
 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
 current outbound spi: 0xFA94E73B(4204062523)
 PFS (Y/N): N, DH group: none

 inbound esp sas:
 spi: 0xFA94E73B(4204062523)
 transform: esp-aes ,
 in use settings ={Transport, }
 conn id: 1, flow_id: SW:1, sibling_flags 80000000, crypto map: GETMAP
 sa timing: remaining key lifetime (sec): (303)
 Kilobyte Volume Rekey has been disabled
 IV size: 16 bytes
 replay detection support: N
 Status: ACTIVE
!!!!...!!!!!
C2#sh crypto session
Crypto session current status

Interface: FastEthernet1/0
Session status: UP-ACTIVE     
Peer: 0.0.0.0 port 848 
 IKE SA: local 10.1.2.2/848 remote 10.1.1.2/848 Active
 IPSEC FLOW: permit ip 10.1.0.0/255.255.0.0 10.1.0.0/255.255.0.0
 Active SAs: 2, origin: crypto map
C2#sh crypto gdoi gm acl
Group Name: GETVPN1
 ACL Downloaded From KS 10.1.1.2:
 access-list  permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255
 ACL Configured Locally:
bon il y en a d’autres, mais maintenant on va conclure par un petit ping voir la différence ! Ce coup ci je vais pinger entre C2 et C3 et sniffer sur Core3 F2/0.
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.3.2, timeout is 2 seconds:
Packet has data pattern 0xDEAD
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 248/274/304 ms
et la pas de suprise, on voit plus de traffic en clair, mais bien du traffic sécurisé via ESP.

VRF GETVPN, DMVPN, et FLEXVPN

Dans cet article, je vais vous présenter l’utilisation de 3 VPNs multipoints (GETVPN, FLEXVPN Spoke To Spoke, et DMVPN) avec des VRFs (Virtual Routing and Forwarding).
Pour rappel, une VRF permets de virtualiser la table de routage d’un routeur afin de segmenter le routage de manière logique.





J’ai par contre pas le courage de détailler chaque point de la configuration, je vous mets donc le but du lab, ainsi que les configurations Initiale et Finales. Si vous avez des questions laissez un commentaire :).

Adressage

DeviceInterfaceIPVRF
ASA3G0/0.172 (Outside – MGMT Context)172.17.0.30+1/24
ASA3G0/0.254 (Outside – DATA Context)10.254.0.30+1/24
ASA3G0/1 (inside – MGMT Context)10.1.1.30+1/24
ASA3G0/1 (inside – DATA Context)10.1.1.40+1/24
ASA3G0/2 (FAIL)99.99.99.30+1/24
R10G0/1.172172.17.0.10/24DataVRF
R11G0/1.172172.17.0.11/24DataVRF
R10G0/1.25410.253.0.10/24MgmtVRF
R11G0/1.25410.253.0.11/24MgmtVRF
R10G0/0100.0.0.10/24InternetVRF
R11G0/0100.0.0.11/24InternetVRF
R7G0/0100.0.0.7/24InternetVRF
R8G0/0100.0.0.8/24InternetVRF
R1L01.1.1.1/24
R7L07.7.7.7/24DataVRF
R8L08.8.8.8/24DataVRF
R10Tun100172.16.0.10/24MgmtVRF
R11Tun100172.16.0.11/24MgmtVRF
R7Tun100172.16.0.7/24MgmtVRF
R8Tun100172.16.0.8/24MgmtVRF
R10Tun20010.254.0.10/24MgmtVRF
R11Tun20010.254.0.11/24MgmtVRF
R7Tun20010.254.0.7/24MgmtVRF
R8Tun20010.254.0.8/24MgmtVRF
R1G0/010.1.1.1/24
En gros le but est d’avoir du GETVPN over DMVPN. Les données transiteront dans la VRF DataVRF (partie DMVPN/GRE), mais les terminaisons des tunnels seront dans la VRF InternetVRF. Les données dans la VRF InternetVRF seront sécurisées via GETVPN.
Pour rappel, avec IPSEC, nous avons la notions de I-VRF ou Inside VRF qui identifie la VRF des données qui seront chiffrées, et la F-VRF ou Frontdoor VRF qui identifie la VRF de transport IPSEC. Ces deux VRFs peuvent ou non être identique.
R1 sera le KeyServer, et les autres routeurs seront les GroupMembers.
Parce que c’est fun, j’ai aussi mis un deuxième reseau DMVPN lui sécurisé par IPSEC classic qui vas servir au rekeying multicast du réseau GETVPN.
Enfin, puisque l’ASA en mode multi contexte ne gère pas le routage multicast, j’ai mis un 3e cloud VPN utilisant IKEv2 et FLEXVPN spoke to spoke pour le multicast vers le KeyServer R1.
Ce qui est fun avec le FlexVPN Spoke to Spoke, c’est que l’on instancie une VirtualTemplate lors de la redirection NHRP, et on a donc non plus un seul tunnel multi-point, mais plusieurs tunnels point-to-point créé a la volée. IKEv2 Mode config permets aussi en théorie de s’affranchir d’un protocole de routage.

On termine par quelques vérifications:

R8#ping vrf DataVRF 10.1.1.1 source Lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 8.8.8.8 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R8#ping vrf MgmtVRF 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R10#sh crypto session detail 
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection     
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation     
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: GigabitEthernet0/0
Session status: UP-ACTIVE     
Peer: 0.0.0.0 port 848 fvrf: InternetVRF ivrf: InternetVRF
      Desc: (none)
      Phase1_id: (none)
  IKEv1 SA: local 239.1.2.3/848 remote 1.1.1.1/848 Active 
          Capabilities:(none) connid:1061 lifetime:0
  IPSEC FLOW: permit 47 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 2651 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2088
        Outbound: #pkts enc'ed 2641 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2088

Interface: Tunnel100
Uptime: 01:49:01
Session status: UP-ACTIVE     
Peer: 100.0.0.11 port 500 fvrf: InternetVRF ivrf: MgmtVRF
      Phase1_id: 100.0.0.11
      Desc: (none)
  IKEv1 SA: local 100.0.0.10/500 remote 100.0.0.11/500 Active 
          Capabilities:(none) connid:1048 lifetime:22:10:57
  IPSEC FLOW: permit 47 host 100.0.0.10 host 100.0.0.11 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 1492 drop 0 life (KB/Sec) 4171263/504
        Outbound: #pkts enc'ed 1513 drop 0 life (KB/Sec) 4171262/504

Interface: Tunnel100
Uptime: 01:49:03
Session status: UP-ACTIVE     
Peer: 100.0.0.8 port 500 fvrf: InternetVRF ivrf: MgmtVRF
      Phase1_id: 100.0.0.8
      Desc: (none)
  IKEv1 SA: local 100.0.0.10/500 remote 100.0.0.8/500 Active 
          Capabilities:(none) connid:1046 lifetime:22:10:56
  IPSEC FLOW: permit 47 host 100.0.0.10 host 100.0.0.8 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 1784 drop 0 life (KB/Sec) 4184809/466
        Outbound: #pkts enc'ed 1525 drop 0 life (KB/Sec) 4184832/466

Interface: Tunnel100
Uptime: 01:49:01
Session status: UP-ACTIVE     
Peer: 100.0.0.7 port 500 fvrf: InternetVRF ivrf: MgmtVRF
      Phase1_id: 100.0.0.7
      Desc: (none)
  IKEv1 SA: local 100.0.0.10/500 remote 100.0.0.7/500 Active 
          Capabilities:(none) connid:1047 lifetime:22:10:57
  IPSEC FLOW: permit 47 host 100.0.0.10 host 100.0.0.7 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 1778 drop 0 life (KB/Sec) 4312433/481
        Outbound: #pkts enc'ed 1514 drop 0 life (KB/Sec) 4312456/481

Interface: Tunnel0
Uptime: 00:59:01
Session status: UP-ACTIVE     
Peer: 10.1.1.1 port 500 fvrf: MgmtVRF ivrf: MgmtVRF
      Phase1_id: R1.cciesec.local
      Desc: (none)
  IKEv2 SA: local 172.17.0.10/500 remote 10.1.1.1/500 Active 
          Capabilities:(none) connid:1 lifetime:23:00:59
  IPSEC FLOW: permit 47 host 172.17.0.10 host 10.1.1.1 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 137 drop 0 life (KB/Sec) 4182850/3544
        Outbound: #pkts enc'ed 140 drop 0 life (KB/Sec) 4182850/3544

Interface: Tunnel100
Profile: GET
Session status: UP-IDLE
Peer: 1.1.1.1 port 848 fvrf: MgmtVRF ivrf: DataVRF
      Phase1_id: 1.1.1.1
      Desc: (none)
  IKEv1 SA: local 172.16.0.10/848 remote 1.1.1.1/848 Active 
          Capabilities:(none) connid:1060 lifetime:23:39:29

R1#crypto gdoi ks rekey 

% There has not been a GDOI policy change for group GETVPN, a rekey is not needed

Are you sure you want to proceed ? [yes/no]: yes
R1#
*Mar 30 16:21:28.833: %GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey with policy-replace for group GETVPN from address 1.1.1.1 to 239.1.2.3 with seq # 1

R7#
*Mar 30 16:11:41.650: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated
*Mar 30 16:11:41.650: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Mar 30 16:11:41.650: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GET from 1.1.1.1 to 239.1.2.3 with seq # 1
*Mar 30 16:11:41.650: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 1.1.1.1 for group GET & gm identity  239.1.2.3
R7#sh ip mroute vrf MgmtVRF
 (*, 239.1.2.3), 01:17:16/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel100, Forward/Dense, 01:17:16/stopped

(1.1.1.1, 239.1.2.3), 00:00:46/00:02:13, flags: PLT
  Incoming interface: Tunnel100, RPF nbr 172.16.0.11
  Outgoing interface list: Null


SECURIDAY-ACCESS CONTROL (BYOD, CLOUD, HARDWARE)

Le club SecuriNets a l'immense plaisir de vous convier le Samedi 26 Avril 2014 à l’INSAT à la 8ème édition de Securiday, 4ème édition de la Journée Nationale de la Sécurité Informatique qui aura pour thème Access Control : les contrôles d’accès au sein du milieu professionnel. Ce thème sera traité dans 3 différents axes : BYOD (Bring Your Own Device), Hardware et Cloud.
Sous le joug d’un monde informatique en constante évolution, toute entreprise digne de ce nom se doit de se garantir le meilleur système de sécurité existant. Dans cet univers rythmé par l’avancement technologique, toutes les informations, même les plus confidentielles parmi elles se retrouvent dans un grand danger d’exposition dû au manque de contrôle d’accès des firmes les plus réputées du monde.
En Tunisie, cette culture de l’Access Control n’a pas encore atteint son apogée. Que cela soit au niveau physique, sur les serveurs en ligne ou bien les équipements mobiles, bon nombre de professionnels échouent sur ce point.
Nous allons tenter, par notre évènement, de démocratiser cette culture et de répondre à une série de questions à travers un programme dense et varié.
De plus, cette année s’avère être plus qu’exceptionnelle pour le 1er club de la sécurité informatique en Tunisie. Fondé en 2004, le club fête ses 10 ans d’existence. Dans une bonne ambiance, nous invitons tous ceux qui ont pu entendre parler de SecuriNets de prés ou de loin à assister à cette incroyable fête.
Nous vous donnons sans plus attendre le programme détaillé du Securiday 2014 Access Control et attendons votre présence avec impatience le Samedi 26 Avril 2014 à l’INSAT. 
https://www.youtube.com/watch?v=1zwXRYYnYsQ
Session 1 :

6h : lancement du challenge

8h : lancement de la journée
Session 2 : 

9h : Ouverture des portes de l’auditorium et streaming sur le challenge

9h30 : Présentation de la journée
9h40 : Mot de Monsieur le Directeur de l’INSAT
9h50 : Mot de Ahmed Amine Ben Souayah : Fondateur du club Securinets
9h55 : 1ère partie du documentaire Access Control 
10h00 : Conférence de Mr Haythem El Mir : Responsable Technique chez Positive Technologies sur la Sécurité des Systèmes Scada
10h25 : 2ème partie du documentaire Access Control 
10h45 : Conférence de Mr Helmi Rais : Senior Manager chez Alliacom France : Les fondamentaux du controle d'accès
11h10 : 3ème partie du documentaire Access control
11h17 : Intervention de Maître Yassine Younsi, Avocat associé chez YOUNSI&YOUNSI International Law Firm – LEXING Tunisia: Cloud Computing et Protection des données à caractère personnel
11h30 : 2ème Conférence de Mr Helmi Rais : Senior Manager chez Alliacom France : Access control et nouvelles infrastructures (Byod/Cloud/etc.)
11h55 : Magnéto « 10 années de Securinets »
12h : Surprise
12h30 : Pause déjeuner

Session 3 : 

13h30 : Lancement des ateliers 

15h15 : Quiz sur les ateliers
18h : Proclamation des résultats du challenge et remise des prix.
Tags: