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

key-43992_640.png

Si nous observons l’évolution des technologies informatiques au cours de 25 dernières années, il semble que le développement des malwares ou le vol de données suivent de près les avancées technologiques majeures. Examinons les exemples suivants :

  • Le développement des serveurs et des PC de bureau a rapidement été suivi par l’apparition des virus informatiques. Vous souvenez-vous de Cascade, l'un des premiers virus ?
  • Ensuite, nous avons vu l’émergence d’Internet, une invention révolutionnaire pour qui y avait accès en 1994, notamment pour les hackers qui trouvaient des données d'entreprise et des identités en ligne faciles à récupérer.
  • Aujourd'hui, nous avons l'IoT, qui entraîne l'adoption du cloud et de la mobilité mais qui entraine également des attaques DDoS, via des botnets et par le biais d’ingénierie sociale, car les acteurs malveillants suivent l'innovation.
Read more...

Si vous n'aviez pas déjà mis une alerte sur votre smartphone ou dans votre calendrier, de nouveaux bouquins Day One sont apparus pour la nouvelle année!!

Cliquez sur le Day One qui vous intéresse pour accéder directement à la page de téléchargement...

 

D1-cli-2nd-edition-cover.pngLa seconde édition du Day One Junos CLI:

 

Les deux bouquins Day One les plus téléchargés ont été mis à jour, révisés et regroupés en un seul Day One!

 

Tout ce que vous devez savoir pour configurer Junos OS dans votre équipement, modifier, sauvegarder, charger, fusionner des configurations et les vérifier!

 

Explorez toutes les capacités de Junos OS avec ce guide d'utilisation complet!

  

 

 D1-bgp-flowspec-cover.pngComment déployer BGP Flowspec:

  

Au moment où les attaques DDoS reprennent de plus belle sur Internet, et font perdre des centaines de milliers d'Euros, voire des millions, aux Entreprises connectées sur la toile, ce petit bouquin est le bienvenu pour mettre en place rapidement les outils de protection dans vos routeurs, afin de minimiser automatiquement l'impact de ce type d'attaques.

 

Utilisez la techonolgie Junos BGP Flowspec sans modération ;-)

 

 

D1-routing-internet-protocol.jpg

 Apprendre facilement à configurer RIP, OSPF, ISIS, BGP:

 

En quelques lignes d'explication, vous saurez configurer les différents protocoles de routage IP. Ce petit manuel vous rappelle les principes de ces algorithmes de routage et comment les utiliser et les mettre en place sur votre réseau de routeurs Junos.

 

Vous maîtriserez ainsi en l'espace d'une journée seulement tous les aspects

du routage IP.

  

 

ambassadors-cookbook-2017.pngL'édition Cookbook 2017 de nos ambassadeurs:

 

Nos ambassadeurs ont travaillé pour vous et vous donnent dans celle nouvelle édition leurs trucs et astuces pour gagner du temps à configurer par exemple de la QoS de base, migrer votre Cisco LNS vers un vLNS sur nos Juniper vMX Series, mais aussi faire vos premiers pas avec la technologie EVPN/VxLAN, travailler vos premiers scripts Python avec Junos PyEZ pour tester votre réseau ou encrore migrer votre coeur de réseau avec Segment Routing...

 

Avantage: ce sont des exemples de configuration testée et déployés par les auteurs ;-)  

 

 

cgnat-up-runnning-mx-series.pngLe CGNAT sur MX:

 

Les cartes MS-MPC et MS-MIC sur MX ont des fonctions avancées pour supporter le NAT dynamique, des fonctions NAT avancées comme le PAT, les ALG... tout cela à très grande échelle.

 

 Apprenez à configurer du NAT avancé pour vos différents besoins de translation réseau!

 

 

 

  

Et bien sûr, retrouvez tous nos autres Day One et Posters d'aide à la configuration Junos sur: 

http://www.juniper.net/uk/en/training/jnbooks/day-one/

http://www.juniper.net/uk/en/training/jnbooks/day-one/day-one-posters/

 

Bonne lecture!

 

arduino-1128227_640.jpg

L'Internet des objets est partout. On compte à l'heure actuelle environ 15 milliards d'appareils connectés dans le monde , représentant malheureusement presqu’autant d'occasions d’être victime d’une cyber-attaque.

Read more...

umbrella-158164_640.png

Il y a trois ans, le concept d’Internet des objets (Internet of Things ou IoT) était encore une nouveauté. On achetait des objets connectés parce qu’ils étaient à la mode ou pour le confort de vie qu’ils étaient censés nous procurer. Ce marché connaît une très forte croissance depuis et l’IoT a évolué. Presque tous les appareils sont dorénavant proposés avec cette nouvelle fonctionnalité, que l’on se procure un traditionnel smartphone ou une caméra de surveillance, voire même une cafetière ou encore un parapluie.

Read more...

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...