Juniper France Tech Blog
Showing results for 
Search instead for 
Do you mean 

Première Partie : Les nouveaux investissements des DSI dans leur stratégie de Cyberdéfense

Read more...

Ce test a été réalisé en par l’université de Nantes (Yan Dupont) et RENATER.

 

RENATER, Réseau National de télécommunications pour la Technologie l’Enseignement et la Recherche, fédère les infrastructures de télécommunication pour la recherche et l’éducation. RENATER interconnecte les centres de recherche et d’éducation aux autres réseaux nationaux de la recherche (NREN) via le réseau pan-européen  GÉANT.

Le réseau RENATER permet la collaboration des chercheurs et enseignants français entre eux et avec leurs collègues dans le monde grâce à des services de vidéo-conférence, transfert de données ultra-performant.

 

L’interconnexion des centres de calcul (centres de données) est un sujet majeur pour l’éducation et la recherche. Par exemple, c’est grâce à la construction d’une grille mondiale de calcul composée de dizaines de centre de calculs travaillant en collaboration avec le CERN (Centre Européen de Recherche Nucléaire) que le Bosons de Higgs a été découvert. La science est par nature un gros consommateur de calcul et de données. Les réseaux de nationaux de la recherche considèrent que dans un futur proche les centres de calcul vont grossir et que le nombre de leurs utilisateurs va aussi croitre rapidement avec l’émergence des technologies liées au Cloud.

 

Les centres de calculs sont très importants pour nous et nous avons la chance de posséder des relations fortes avec nos utilisateurs. Nous travaillons à leur fournir des services qui correspondent à leur besoin mais nous essayons d’aller au-delà en leur proposant des services innovants qui pourraient leur offrir de nouvelle opportunité de développement. Nous étudions Ethernet VPN (EVPN) pressenti comme futur protocole pour l’interconnexion des centres de calcul. Il est crucial de vérifier auprès de ces centres de calcul si EVPN correspond à leur attente et à leur cas d’usage. La capacité de pouvoir démontrer grâce à un PoC (Proof of Concept) les nouvelles fonctionnalités est un atout important. Un centre de calcul est opérationnel 24/7, il est vital de démontrer la fiabilité de toute brique ou service que nous proposons à nos utilisateurs.  

 

L’utilisation de routeur virtuel comme les Juniper Networks® vMX 3D Universal Edge Router correspond à notre besoin en terme de simulation pour notre ingénierie. Nous pouvons créer facilement des backbone complets permettant de valider le control plane et le forwarding plane. La démonstration de concept de mobilité de machine virtuelle sur EVPN nous permet notamment de juger la maturité de l’implémentation. Ce type de testbed n’est pas utilisé dans notre environnement comme test de performance. La mobilité de Machine Virtuelle (VM) est attendue depuis longtemps dans le monde des centres de calcul notamment pour développer de nouveau paradigme de services.

Démonstration de mobilité de machine virtuel

Démonstration

Objectifs et dispositif

Le but est de démontrer une mobilité de VM entre 2 sites sur un backbone EVPN.  Le routage à l’intérieur de l’instance EVPN doit être maintenu opérationnel après la migration. Le routage entre l’intérieur de l’instance EVPN et l’extérieure de l’instance (Internet) doit être maintenu opérationnel et optimal après la migration.

 

Notre installation est la suivante. Trois serveurs x86 jouent le rôle de 2 centre de calcul et le backbone EVPN :

  • Serveur Testbed-renater-a jouera le rôle du centre de calcul 1
  • Serveur Testbed-renater-c jouera le rôle du centre de calcul 1
  • Serveur Testbed-renater-b jouera le rôle du backbone EVPN + celui de l’Internet. Dans Testbed-renater-b, nous utilisons des virtual MXs :
    • vMX1 est un PE (Provider Edge) qui connecte le DC1 et une instance EVPN (EVI) appelée “BD3”
    • vMX2 est un PE (Provider Edge) qui connecte le DC2 et une instance EVPN (EVI) appelé e“BD3”
    • vMX3 est un PE qui interconnecte l’EVI “BD3” à l’Internet public.
      • Sur vMX3 un Logical System “VM133” (avec pour adresse IP 77.77.77.77) émule un “pseudo Internet” afin de vérifier le routage optimal entre l’instance EVPN et le reste du monde. VM133 échange via BGP de préfixes avec vMX3
      • Du point de vue de vMX3, VM133 est client de la VRF appelé IPVPN-1

 Visio 1 hi res.jpg

Figure 1: Nantes University Testbed (source RENATER®)

 

Visio 2 hi res.jpg

Visio 3 hi res.jpg

 

Figure 2: Final objective – Keeping routing optimal in VM mobility context (source RENATER®)

 

Après la mobilité de la VM, le trafic issu de l’Internet reste optimal. Ce trafic utilize le chemin direct (optimal) vers l’endroit où la VM a été déplacée sans passer par le PE où la VM était connecté orginellement. La flèche pointillée rouge de la Figure 2 illustre ce point.

 

Design

Le design suit principalement la documentation Juniper : DAY ONE: Using Ethernet VPNS for Data Center Interconnect. La différence principale est que l’EVI “BD3” n’est pas du type VLAN-aware bundle service mais VLAN-based service. Ce point n’a pas d’influence sur l’objectif de la démonstration.

 

Protocole implémenté sur le backbone : OSPF, BGP avec la family EVPN, MPLS, RSVP.

 

Les 3 serveurs utilisent KVM comme hyperviseur mais de toute façon EVPN est agnostique à la technologie de virtualisation employée. Pour la machine testbed-renater-b qu’héberge les vMX, nous avons choisi le para-virtualization qui permet la mobilité de machine d’un hyperviseur vers un autre sans reconfiguration de la VM. Nous avons implémenté les vMX routeurs en utilisant virtio. Pour la migration de VM d’un hyperviseur à l’autre, nous avons utilisé les outils standards de “KVM”.

 

Conclusion

Le test été un succès important pour nous. Il va nous aider à déployer de nouveaux services réseaux à la pointe du développement dans notre portfolio de services. L’utilisation de routeurs virtuels MX a démontré son utilité pour notre activité d’ingénierie réseau. Cela ouvre de nouvelles opportunités notamment dans le contexte des Network Function Virtualization (NFV).

 

Le déploiement d’Ethernet VPN est très important pour RENATER et cette expérience démontre que l’implémentation d’EVPN fourni par Juniper a un bon niveau de maturité. Grâce à Juniper, nous avons pu démontrer à nos utilisateurs que RENATER travaille à fournir des nouveaux services réseaux adaptés à leur besoin. Ils ont apprécié cette démonstration et nous espérons démarrer bientôt avec eux une collaboration sur ce sujet EVPN. Cette preuve de concept a été très utile, mais nous devons prendre en considération que cette fonctionnalité nécessite de fortes performances notamment lorsque les centres de calcul sont éloignés et la latence importante. Nous allons donc continuer notre étude sur EVPN dans ce cas mais aussi à propos d’autres fonctionnalités comme le load balancing par flow.

 


EVPN_VM_Mobility_demo_RENATER by xavier-jeannin

Network Test a réalisé cet automne des tests de capacité et de performances sur notre nouveau switch de coeur Datacenter Juniper QFX10002-72Q. Celui-ci a été testé à pleine charge, soit dans sa configuration 72 ports 40GE, soit dans sa configuration 24 ports 100GE, connectés sur un testeur Spirent N11U avec le même type d’interfaces.

 

 

Network Test est un organisme indépendant et reconnu pour ses services de mesure et tests d'équipements réseaux des constructeurs ou directement dans les environnements réseaux opérateurs ou grandes entreprises.

 

Ces tests sont disponibles en détail ici: http://networktest.com/jnprqfx10k/ et ont consisté à évaluer les éléments suivants:

- ses capacités de routage 40GE EVPN à travers des tunnels VxLAN

- son throughput 40GE et 100GE selon la RFC2544 unicast

- son throughput 40GE et 100GE selon la RFC3918 multicast

- sa consommation électrique

- sa capacité de buffering à 40GE et 100GE

- ses capacités en nombre d’ARP, de MAC RFC2889, d’IPv4/v6, de FW Filters (ACL)

- le nombre d'instances L3VPN et VRF lite en OSPF ou BGP associé à BFD

 

Tous ces tests devaient durer 2 semaines selon Network Test mais ils ont été finalement effectués en seulement 4 jours !

Grâce notamment à des outils d’automatisation, comme la création de templates Jinja2 et l’utilisation de PyEZ sur JunOS, les configurations de tests ont pu être préparées à l'avance et ainsi exécutées rapidement à la demande.

 

Le premier test EVPN/VxLAN était important car c'est le premier réalisé publiquement. EVPN/VxLAN est en effet devenu le standard maintenant adopté par les acteurs du Cloud et Datacenter hautes performances, c’est pourquoi Juniper tenait à démontrer comment et jusqu’à quel niveau de capacité, le QFX pouvait supporter ce type de technologie. Les hautes performances obtenues pour ces tests sont la preuve que Juniper a bien fait de choisir de développer son propre ASIC Q5 pour la nouvelle gamme de switchs QFX10000 de Datacenter, contrairement à ses concurrents qui continuent de s’appuyer sur les développements de Broadcom.

 

En effet, grâce à sa capacité mémoire embarquée directement sur l’ASIC Q5 pour faire des lookups, le QFX10002 obtient des résultats line-rate dès la taille de 400 octets par paquet routé à travers des tunnels VxLAN.

En ce qui concerne les RFC 2544, et RFC 3918, le QFX10002 atteint des valeurs line-rate en unicast et en multicast pour du trafic IMIX mais aussi pour des tailles de paquets plus petites à compter de 160 octets par paquet.

Le QFX10002 se positionne donc également comme un très bon équipement de diffusion vidéo avec plus de 128000 groupes multicast supportés.

 

Il est capable de supporter jusque 434000 MACs sans aucune collision et peut enregistrer jusque 512000 adresses.

Le QFX10002 a été capable d’enregistrer jusque 500000 routes IPv4 et IPv6 simultanément et d'acheminer sans perte le trafic envoyé vers ces destinations.

 

Les tests concernant le plan de contrôle ont pu démontrer la capacité à monter 4000 L3VPN avec 4000 instances VRF-lite, que ce soit en utilisant OSPF ou BGP comme protocole.

BFD a également été testé avec 4000 sessions en parallèle de celles en OSPF ou BGP en configurant un intervalle de détection à 3x1s.

60000 FW filters (ACL) ont pu être configurés (2500 par port 100GE) sans réduire les capacités de throughput de la machine.

 

Enfin, le QFX10002 consomme un peu moins de 1kW à pleine charge, ce qui est moins qu’indiqué dans nos datasheets qui précisent le pire des cas possibles (température anormalement élevée, ventilateurs à pleine vitesse).

 

Le QFX10002 présente déjà des références à peine sorti des usines de production de Juniper, notamment chez les grands acteurs du Cloud et de l'hébergement. Il est principalement déployé comme coeur de Fabric IP/BGP Datacenter pour interconnecter en 40GE plusieurs dizaines de switchs ToR 10GE déployés dans les baies de serveurs.

Le support à grande échelle de EVPN/VxLAN est donc essentiel dans ce cas de déploiement pour interconnecter en niveau 2 au-dessus de la Fabric IP tous les serveurs physiques ou virtuels qui y sont interconnectés dans un ou plusieurs Datacenters !

 

Lors d'une récente revue interne, Juniper a découvert un code non autorisé dans certaines versions ScreenOS qui permettrait à un attaquant chevronné d’obtenir un accès administrateur sur nos Firewalls ancienne génération NetScreen® et d’avoir la possibilité de déchiffrer les connexions VPN.

 

Ces failles de sécurité ne concernent que les codes ScreenOS 6.2.0r15 à 6.2.0r18 et ScreenOS 6.3.0r12 à 6.3.0r20. Vous pouvez vous référer au bulletin JSA10713 pour tous les détails.

Dès cette découverte, nos équipes de sécurité ont lancé une enquête, et nous avons développé rapidement des versions corrigées qui ont été mises à disposition sur notre site de téléchargement (http://www.juniper.net/support/downloads/screenos.html) en même temps que la révélation publique de ces failles de sécurité ScreenOS. Les anciennes versions impactées ont toutes été retirées.

 

Un certain nombre de medias a diffusé l’information sans avoir pris connaissance des conditions réelles et des règles de sécurité que les responsables réseaux et sécurité mettent en place dans leur entreprise.

 

 

Il est crucial en effet de comprendre ici que ces failles de sécurité sont difficiles à exploiter sans se faire prendre d’une part, et dans les conditions décrites ci-dessous qui constituent les bonnes pratiques à suivre lors d’un déploiement d’équipement réseau connecté à l’Internet. Jusqu’à présent, nous n’avons d’ailleurs eu aucune preuve qu’une de nos configurations clients ait été exploitée malicieusement.

 

Oui, le code espion comprenait le nom d'utilisateur et le mot de passe écrits en dur, pouvant donner à un attaquant chevronné et informé, un accès en tant qu’administrateur sur le Firewall. Mais en respectant les bonnes pratiques de sécurité et la configuration ScreenOS par défaut, cette vulnérabilité reste extrêmement difficile à exploiter pour les raisons suivantes:

  • L'administration à distance ne devrait pas être autorisée par l'Internet (zone de sécurité "untrust" par défaut)
  • Un administrateur interne devrait être autorisé à y accéder à partir d’un réseau dédié out-of-band d’administration uniquement ou d’un réseau plus spécifique contrôlé.
  • Un environnement sûr de cyber sécurité utilise également une base de données externe pour l’authentification sur les équipements réseau (par exemple RADIUS) et interdit l’authentification en local d’un Firewall, ceci pour des raisons de vérification et d’unicité des comptes et mots de passe d’accès.
  • Le déploiement d’un serveur externe de logs ou un SIEM (JSA-series, par exemple) est préconisé pour facilement détecter tout accès non autorisé qui exploiterait cette vulnérabilité.

Ainsi toutes ces bonnes pratiques citées ci-dessus empêchent et rendent l’exploitation de cette faille de l’accès à distance impossible.

 

En ce qui concerne la deuxième faille annoncée qui permettrait le déchiffrement du trafic VPN, son exploitation est encore plus difficile car elle implique une logique plus complexe et des compétences confirmées.

 

Le point important qu’il faut souligner ici est qu'avant de pouvoir déchiffrer le trafic, il faut pouvoir le récupérer ou du moins, le contrôler en mettant en place une solution de miroir ou de déviation de ce trafic sans que l’administrateur du Firewall ne puisse le soupçonner… Pas simple ! C’est un sacré challenge pour les attaquants qui doivent en plus le faire à distance, à moins que l’opérateur Telecom soit complice de ses actes.

 

De surcroît, pour déchiffrer le trafic VPN IPSEC, l'attaquant doit disposer d'informations qui sont elles-mêmes intégrées dans l'algorithme de chiffrement. Bien qu'il soit théoriquement possible de les déchiffrer, il est très difficile de le faire en pratique pour toute personne autre que celle qui a inventé la clé.

 

En tout état de cause, il est très important de comprendre que ces failles de sécurité annoncées publiquement par Juniper peuvent être corrigées dès maintenant avec la mise à jour du code Screenos éliminant ces possibilités d’intrusion. L'autre point important est de vous assurer que les bonnes pratiques de configuration et d’administration des équipements de son réseau décrites dans ce billet sont bien en place pour éviter toute tentative d’accès non autorisée ;- )

 

N’hésitez pas à contacter votre équipe Juniper ou votre partenaire intégrateur pour toute aide et toute information sur l’impact de ces vulnérabilités dans votre réseau. Nous nous tenons à votre disposition.

 

Vous avez juste à cliquer sur le lien: https://www.juniper.net/customers/support/#task et vous y trouverez les outils en ligne suivants dans la rubrique Use Tools:

 

  • SRX HA Configurator Generator: grâce à cet outil vous serez capable de générer la configuration intiale d'un cluster de chassis SRX branch très facilement et en gagnant du temps; notamment pour savoir quelles interfaces de contrôle et de fabric il faut définir et configurer selon le type de plateforme choisi :-)

 

 

  • SRX VPN Configurator: outil très intéressant pour vous guider dans la configuration de VPN site à site si vous n'avez pas notre GUI Security Director pour générer la configuration automatiquement ou si vous désirez configurer un VPN offline sans utiliser le wizard disponible dans le SRX :-)

 

Le vSRX2.0, le firewall virtuel de Juniper le plus performant du marché est enfin arrivé avec une bonne surprise sur ses capacités.

Read more...

Comme la plupart des lecteurs de blogs sur l’environnement IT, je suis attentif aux publications à des fins professionnelles, mais aussi par curiosité personnelle. Je vous propose ma contribution avec ce billet.

 

L’équipe d’architecture réseau que j’anime au sein de les services informatiques de Docapost (http://www.docapost.com, filiale du groupe La Poste) a récemment été confrontée à des challenges que nous connaissons de façon récurrente : la transition vers une nouvelle organisation de nos datacenters, au niveau de la commutation et de la mise en service progressive d’interfaces 10 Gbps sur les équipements raccordés.

Read more...

Pas un jour sans que les offres Cloud, quelque soit leur forme, ne soient présentées comme une avancée majeure supportant le développement de votre entreprise!

 

Plus d’agilité, moins d’investissement, des ressources à la demande et donc une meilleure satisfaction « client » (qu’il soit interne ou externe), les bénéfices promis sont plus ou moins confirmés. Les débats sont importants et normaux au sujet d’un modèle de consommation de l’IT nouveau et pas encore contrôlable.

 

Juniper Networks participe à la Cloud Week (du 6 au 10 juillet) à Paris, et notamment aux Etats Généraux d’Eurocloud le 9 juillet; et ces sujets seront largement abordés dans les conférences et tables rondes durant toute la semaine.

 

Cependant la partie la moins « médiatisée » de la construction d’un Cloud est peut-être celle où les progrès à faire sont les plus importants pour les entreprises et les fournisseurs de Cloud : le datacenter, et plus précisément son infrastructure réseau, sont-ils prêts pour le Cloud ?

 

Juniper Networks a mandaté IDC France pour réaliser deux études desquelles ont été émis des livres blancs. La première, réalisée mi 2014, a interrogé les entreprises privées et publiques de plus de 1000 employés. La seconde, déroulée il y a quelques mois, s’est intéressée aux fournisseurs de Cloud. Les résultats sont clairs : peu d’organisations ont leur(s) datacenter(s) prêt(s) à répondre aux attentes ou pas suffisamment avec les bénéfices attendus.

 

Si les parties serveurs et stockage (consolidation, virtualisation et standardisation) ont énormément progressé, la partie réseau est en retard. Simplifier les infrastructures devient une exigence. L’automatisation est l’étape suivante :

  • 43% des responsables de datacenters estiment que leurs équipements réseaux sont inadaptés. (1)
  • 60% veulent investir pour bénéficier d’une gestion simplifiée, d’une automatisation renforcée et d’une fiabilité améliorée. (1)

 

 

Les fournisseurs de Cloud, acteurs de plus en plus nombreux de l’offre du marché, ont également ces challenges à relever :

 

  • 56% veulent faire évoluer leur architecture réseau, qu’il s’agisse de renouvellement par des équipements nouvelle génération (33%) ou de refonte totale (14%) (2)

 

Leurs exigences sont aussi la fiabilité, la simplicité, l’efficacité et l’optimisation des investissements et enfin le « time to market », nécessité clé pour délivrer les services attendus par leurs clients et facteur déterminant pour gagner des parts de marché.

 

Alors chez vous ou chez votre fournisseur « votre datacenter est-il prêt pour le Cloud ? »

 

Pour en savoir plus sur les conclusions des études IDC citées (1) – Segment Entreprises – Avril 2014 et (2) – Segment Fournisseurs de Cloud – Janvier 2015, consultez les livres blancs édités par IDC France sur notre site www.juniper.net/fr .

 

Plus de liens:

Url : La flexibilité de l'entreprise passe par le datacenter

Blog: Les nouvelles orientations du DC

Video: Juniper Networks QFX10000 Data Center and Cloud Switches

Press Release: Juniper Networks Innovation Showcase Features New Lineup of Breakthrough-Performance Networking Prod...

Juniper Networks QFX Series of Switches: http://www.juniper.net/us/en/products-services/switching/qfx-series/

 

 

Comment appliquer des règles de sécurité et de segmentations dans l'environnement virtuel ? Et pour quels services ? Quel composant (de sécurité ou non) peut le faire dans un environnement virtuel ?

 

Read more...

Firefly, ou plutôt vSRX comme on l'appelle plus souvent, est tout simplement une version virtualisée du Firewall SRX de Juniper avec de nombreuses fonctionnalités citées dans cet article.

Read more...