28 avril 2016

En Avril, ne te découvre pas d’un fil !

Ça n’a absolument aucun rapport avec cet article, mais je n’avais pas de phrase d’ouverture.

 

Petit tour d’horizon de l’existant et des nouveautés chez notre partenaire Juniper Networks

Sécurité:

La première nouvelle de ce début d’année est l’arrivée des nouvelles plateformes SRX « branch »

portfolio

 

L’un des buts principaux de ce rafraichissement du matériel étant le respect de la norme environnementale ROHSv2, le deuxième effet « Kiss Cool » offre en conséquence des appliances (beaucoup) plus puissantes.

Seconde évolution sur le plan logiciel cette fois, le licencing Junos évolue et se décompose en 2 options:

  • JSB pour Junos Base: Firewall niveau 4 (routage, commutation, Firewall, NAT, VPNs)
  • JSE pour Junos Enhanced: JSB+ MPLS et la suite AppSecure (L7)

Cela permet une plus grande modularité, et plus de fonctions pour un même ordre de prix avec l’ajout d’AppSecure dans une licence perpétuelle JSE.

Les nouveaux modèles « Branch »: SRX 300/320/340/345 qui viennent remplacer les 100/110/220/240

Le 550 demeure avec tout de même la compatibilité ROHSv2 (550-M)

Le SRX1500 qui vient se positionner en milieu de gamme:  sur 1U avec nativement 16 ports 1G et 4 ports 10G: must have!

Le 1500 est le premier de la nouvelle gamme à supporter SKY ATP. Je vous en parlerai plus en détail dès qu’on aura le reçu le notre, en attendant, un petit trailer: SKY ATP

L’ajout de cette fonctionnalité ajoute un niveau de sécurité supplémentaire, en permettant (via le Cloud et la collaboration des différents partenaires et clients dans le monde) la détection des malwares, virus et 0-day qui transiteraient par votre SRX, et de les bloquer le cas échéant.

 

Et on n’oublie bien sur pas le vSRX en version 2.0 qui permet de traiter jusqu’à 5G de trafic, et qui peut être déployé aussi bien en micro-périmètrique pour vos environnements virtualisés, ou directement dans le cloud AWS par exemple, le tout managé dans un même Junos Space-SD (voir plus bas).

Pour clore le chapitre « virtualisation », j’ai pu assister aux premiers tests du « cSRX » (c pour container), dont la beta démarre d’ici quelques semaines. Il s’agit comme son nom l’indique d’utiliser SRX avec Docker (ce n’est donc pas un équivalent du vSRX, mais une autre approche).

 

Pour rappel et clarification si nécessaire, voici une vue de toutes les services L7 disponibles sur SRX:

L7_srx

Cette suite déjà bien fournie qui permet une sécurité globale est complétée désormais par Spotlight, qui nécessiterait un article dédié (peut être prochainement ! )

spotlight-secure-intel-platform

 

Spotlight permet d’intégrer des flux Juniper ou personnalisés, permettant la détection et le blocage des menaces types Command & Control, botnet.

Les politiques de sécurité des SRX utilisent ces « feeds » comme paramètre d’acceptation ou de blocage, et ceux-ci sont mis à jour dynamiquement (sans « commit ») nécessaire.

Cela permet de se protéger d’un nombre et types d’attaques encore plus important, et plus ciblés par rapport à l’activité de l’entreprise.

 

Côté Administration, la J-Web nouvelle sera disponible sur ces nouveaux équipements, avec de nombreuses améliorations à venir sur le management par ce biais.

Junos Space Security Director fait également « peau neuve », en cohérence avec le nouveau look de la JWeb, offrant de nouvelles options de monitoring et des améliorations sur la partie visibilité applicative par exemple.

Il est la aussi déployé chez nous, une petite démonstration de la chaîne complète est en cours de préparation 😉

SD 15.2

SD

Infrastructures d’entreprise et Data-Center:

Côté produit, la gamme Datacenter/Cloud s’est étoffée avec l’arrivée des QFX5200 et QFX10000.

 

Pour le QFX5200, il existe en version -32C (1U/32 ports QSFP+ ou QSFP28) ou -64Q (2U/64 ports QSFP+ ou 32 QSFP28).

Ces configurations permettent une modularité de ports pouvant être configurés en 10, 25, 40, 50 et 100GbE

Ce modèle est destiné à être utilisé dans des architectures Layer 3 Fabric, ou Junos Fusion en tant que « leafs »

Il dispose de plus des fonctions permettant l’overlay VXLAN (avec VMware NSX et OpenContrail), ou encore les protocoles de DCI (Data-Center Interconnect) comme EVPN, VXLAN, MPLS et GRE.

 

Les QFX10000 (10008 et 10016) sont deux chassis pouvant être utilisés en Spines de Fabric L3, ou Junos Fusion et MC-LAG.

Ils permettent la encore une grande modularité de ports, en 10, 40 et 100GbE grâce aux 3 types de line-cards: -36Q, 30C, 60S-6Q et à l’utilisation de QSFP28 DACBO (Direct Access Cabler Break-Out)

QFX10K

 

Le tout résumé dans 2 autres petites vidéos, moins de 5 minutes 🙂

 

QFX5200

QFX10K

 

Post-Credits Scene: Automatisation first step

Bravo et merci à ceux qui ont lu jusqu’ici, bonus track pour vous!

On entend beaucoup parler d’automatisation, et une grande partie des clients que nous sommes amenés à rencontrer est souvent rebutée par la supposée complexité de la chose, voici un exemple très simple d’automatisation possible avec les équipements Juniper, et accessible sans aucune expérience en programmation autre que les restes de nos lointaines années d’études 🙂

 

Une VM pré-packagée avec tous les pré-requis existe (ainsi qu’un container docker),si, comme moi, vous êtes vraiment très mauvais:

  • Ubuntu 14.04.01 with LXDE
  • Eclipse with SLAX plugin
  • JUISE
  • JSNAP
  • Perl 5.18.2 with perl-netconf
  • Python 2.7.6 with python-netconf
  • Python Py EZ-NC
  • Python SpaceEZ
  • Local copy of Junoscriptorium
  • git
  • Virtual Machine Manager with a vMX instance pre-configured with 3 logical systems (R1, R2, R3)

JSNAP:

Cet exemple utilise JSNAP. Il utilise des scripts SLAX, et bientôt python.

Le but est simple: automatiser les vérifications sur vos équipements, suite à une migration, une mise à jour ou une modification de configuration.

Il nous est tous arrivé d’intervenir de nuit, le weekend end pour une opération de ce type, et de passer plus de temps à faire les différentes vérification post-opération que l’opération en elle même. Avec JSNAP, vous pourrez gagner 2h de sommeil (je suis en contact avec le service marketing de Juniper pour imposer ce slogan).

 

Avec cet utilitaire et un script de à peine 50 lignes pour commencer (de nombreux existent déjà de plus, pas besoin de tout refaire vous même), que l’on exécute avant migration et après migration (et qui n’est pas copié ici pour des raisons de lisibilité), vous serez en mesure d’avoir en une commande l’état de toutes vos interfaces et de vos sessions BGP avant et après migration:

automation@automation:~$ jsnap --check post_op,pre_op -l root -t <IP_de_mon_super_SRX> -p <password(le nom de mon chat comme d'habitude>) /home/automation/mon_super_script_jsnap_de_winner.conf
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>
>>> TARGET: IP_de_mon_super_SRX
>>>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
---------------------------------------------------------------------------
CHECKING SECTION: check-interfaces
---------------------------------------------------------------------------
- TEST FAILED: "Checking physical interface admin-status ..."

 ERROR: the interface ge-0/0/7 has changed from up to down.

- TEST FAILED: "Checking physical interface oper-status ..."

 ERROR: the interface ge-0/0/7 has changed from up to down.

+ TEST PASSED: "Checking logical interface admin-status ..."
- TEST FAILED: "Checking logical interface oper-status ..."

 ERROR: the interface ge-0/0/7.100 has changed from up to down.

 ERROR: the interface ge-0/0/7.101 has changed from up to down.

 ERROR: the interface ge-0/0/7.32767 has changed from up to down.

+ TEST PASSED: "Checking for missing logical interfaces ..."
+ TEST PASSED: "Checking for new logical interfaces ..."

---------------------------------------------------------------------------
CHECKING SECTION: check-bgp-summary
---------------------------------------------------------------------------
- TEST FAILED: "Checking the state of BGP Session ..."

 ERROR: the BGP session with 10.0.100.2 has changed from Established to Idle.

 ERROR: the BGP session with 10.0.101.2 has changed from Established to Idle.

+ TEST PASSED: "Checking for missing BGP sessions ..."
+ TEST PASSED: "Checking for new BGP sessions ..."
+ TEST PASSED: "Checking number of received prefixes ..."
]0;automation@automation: ~automation@automation:~$

30s plus tard, je sais qu’une interface portant 2 vlans est tombée, entraînant la chute de 2 sessions BGP (et du coup, je ne rentre finalement pas dormir).

Bon, ici c’était facile, un stagiaire avait débranché le câble.



Partager : 

						
Auteurs