Passerelle de filtrage Juniper MX : firewall anti-DDoS permanent au débit de ligne
Un pare-feu de filtrage DDoS prêt à déployer pour Juniper MX204 (4×100GE) en bordure des réseaux de FAI et de data centers : des filtres firewall sans état et des policers rejettent le trafic d'attaque dans le PFE au débit de ligne. Configuré et déployé par ITORO pour votre routeur.
Protection, télémétrie, deux tableaux de bord Grafana et des rapports e-mail envoyés uniquement lorsqu'un problème est détecté, livrés comme un seul produit.
Fonctionne de manière autonome. Avec WanGuard, la détection d'attaque injecte en plus automatiquement des règles BGP FlowSpec dans le routeur ; WanGuard est optionnel.
Un produit, quatre composants
Pas seulement un tableau de bord : quatre composants, chacun fonctionnant indépendamment de l'infrastructure ITORO.
Protection du routeur de bordure
Filtres firewall et policers sur le routeur pour le trafic entrant et sortant, plus un filtre lo0 dédié qui protège le Routing Engine.
Télémétrie sans charge sur le Routing Engine
Télémétrie Junos native émise directement depuis le PFE. Pas de polling SNMP, pas de sessions CLI périodiques.
Visibilité des attaques DDoS
Trafic de transit et de peering par lien, trafic par client, trafic d'attaque par vecteur et règles de mitigation actives dans une seule vue.
État du routeur et rapports d'incident
Huit tuiles d'état adossées à des panneaux détaillés ; un rapport e-mail n'est envoyé qu'en cas de problème détecté.
Un produit autonome
Les quatre composants fonctionnent sans WanGuard. Lorsque WanGuard est déployé, la détection d'attaque injecte des règles BGP FlowSpec dans le routeur et le tableau de bord DDoS Streams les affiche à côté des filtres permanents.
Filtrage matériel au débit de ligne, en permanence
Le scrubbing cloud a besoin de dizaines de secondes pour rediriger le trafic et se facture au Gbps. Une passerelle Juniper MX sur site filtre le trafic d'attaque sur le routeur lui-même, en matériel, sans redirection.
Débit de la passerelle MX204, dimensionné pour les périphéries ISP et de centres de données.
Le trafic d'attaque est rejeté en matériel, le trafic propre passe intact.
Avec WanGuard, la détection d'attaque injecte automatiquement des règles FlowSpec dans le MX.
Juniper MX: protection DDoS permanente
Un pare-feu sans état au débit de ligne, actif avant qu'une attaque n'atteigne votre réseau : filtrage DDoS de transit sur les interfaces WAN/LAN (Couche 1) et protection du routing engine via lo0 CoPP (Couche 2).
Couverture des filtres et déploiement
- Chaînes de filtres distinctes pour le trafic entrant depuis Internet et le trafic sortant de votre réseau.
- Plus de 40 types de trafic classifiés : vecteurs reflection/amplification, paquets malformés, adresses source bogon et martian.
- Policers pour certains protocoles et prefix-lists de sources de confiance exclues du filtrage.
- Un filtre lo0 dédié avec policers limite le trafic destiné au Routing Engine, afin qu'une attaque volumétrique ne déstabilise pas les protocoles de routage.
- Déploiement par étapes : les terms fonctionnent d'abord en mode accept + count pour mesurer le trafic réel, puis discard est activé pour les vecteurs confirmés. Aucun service client n'est bloqué à l'aveugle.
Package de filtres Juniper MX, profondeur & complexité
Livré par ITORO sous forme de configuration prête à déployer.
Filtres de transit: catégories bloquées en dur
- Limité en débit (contrôlé, non rejeté) : SYN floods · fragments IP · ICMP · DNS · NTP.
Routing Engine CoPP
- Refus par défaut, tout trafic non correspondant est bloqué.
- Des milliers de vecteurs d'attaque potentiels éliminés par la seule architecture.
Chaque terme de filtre possède un compteur nommé
- Visibilité en temps réel via Grafana et Juniper Telemetry.
- Les compteurs suivent une nomenclature structurée: protocole, direction, type d'attaque.
- Surveillance en direct disponible à tout moment également depuis la CLI JunOS.
Anti-spoofing : RPF check sur les interfaces
- Nous recommandons d'activer un RPF check sur les interfaces afin de rejeter le trafic aux adresses source usurpées.
Télémétrie Junos vers Grafana sans charge sur le Routing Engine
Les capteurs de télémétrie Junos natifs exportent les données en UDP toutes les 60 secondes, directement depuis le PFE. Le Routing Engine n'intervient pas dans l'export, sans sessions CLI périodiques ni polling SNMP.
Export toutes les 60 secondes
Un flux continu au lieu d'un polling SNMP toutes les quelques minutes : la saturation d'un lien est visible pendant qu'elle se produit.
Compte read-only
Le compte sur le routeur dispose d'une classe de connexion read-only et ne peut pas modifier la configuration.
Fonctionne sur votre infrastructure
Les collecteurs et les tableaux de bord fonctionnent indépendamment de l'infrastructure ITORO.
DDoS Streams : la vue complète de l'attaque DDoS dans Grafana
Trafic par lien de transit et de peering et par interface client, trafic d'attaque par vecteur et par action de filtre (discard, policer, accept), et règles BGP FlowSpec actives avec la bande passante retenue par chacune. Les données proviennent des compteurs de filtres firewall et de la télémétrie des interfaces, actualisées toutes les 60 secondes.
- Trafic de transit et de peering par lien, dans les deux sens, étiqueté avec les noms d'opérateurs issus des descriptions d'interfaces.
- Trafic vers et depuis chaque interface client, identifiant à la fois les cibles d'attaque et les sources de trafic anormal.
- Trafic d'attaque par vecteur et action de filtre : discard, policer ou accept + count (mode observation avant l'activation de discard).
- Règles BGP FlowSpec actives avec le volume de trafic correspondant à chaque règle.
Router Health : état du RE, du PFE, de l'optique et des interfaces dans une seule vue
Les principaux paramètres d'état du routeur avec historique : Routing Engine, PFE et NPU, optique, interfaces et files d'attente, policers de protection DDoS du plan de contrôle et environnement du châssis. Chaque panneau décrit la métrique et fournit des commandes Junos CLI prêtes à coller pour la vérifier sur le routeur, par exemple show pfe statistics traffic ou show chassis fpc.
- Utilisation CPU et mémoire du Routing Engine et de la carte de ligne.
- Charge et utilisation mémoire du PFE et du NPU.
- Températures du Routing Engine et des composants du châssis, état des fan trays.
- Optique : puissance Rx/Tx par voie (dBm), température du transceiver et courant de polarisation laser, indicateurs précoces de la dégradation d'un lien.
- Erreurs et discards d'interface, erreurs FCS signalant des connecteurs ou une fibre encrassés, et drops dans les files de sortie.
- Instabilités de lien (link flaps) : la cause la plus fréquente d'instabilité du routage, souvent confondue avec une attaque.
- Protection DDoS du plan de contrôle (jddosd) : quels policers ont été dépassés, et quand.
- Inventaire du châssis avec l'état et la température de chaque composant.
Rapports e-mail uniquement en cas de problème détecté
Pas de rapport quotidien de routine : un e-mail n'est envoyé qu'en cas de problème détecté. Il contient des fiches d'état par routeur, huit graphiques couvrant les 12 dernières heures et un tableau des incidents de protection du plan de contrôle, avec le même rapport joint en PDF.
- Les seuils d'alerte sont configurables et adaptés au profil de fonctionnement normal de votre réseau.
- Il fonctionne que quelqu'un surveille ou non les tableaux de bord.
- Il surveille aussi la chaîne de collecte et alerte lorsque la télémétrie cesse d'arriver.
- L'historique conservé alimente l'analyse post-incident et la planification de capacité.
WanGuard détecte, Juniper MX filtre
WanGuard voit votre trafic via un port miroir et identifie l'attaque en quelques secondes. Il pousse ensuite des règles BGP FlowSpec granulaires vers le Juniper MX, qui les applique au débit de ligne sur le plan de transfert. RTBH reste disponible comme solution de dernier recours pour les attaques trop importantes pour un filtrage granulaire.
- Toujours active: aucune redirection de trafic, aucune latence de centre de nettoyage.
- FlowSpec sur les cartes de ligne MX ; RTBH en solution de secours.
- Package de filtres préconfiguré et optimisé par ITORO.
- La télémétrie et les tableaux de bord font partie du même déploiement.
Elle complète la protection de votre réseau et protège son cœur : le routeur
Un routeur stable sous attaque
Sous attaque, un routeur peut perdre sa stabilité. Les filtres firewall et la protection du Routing Engine (filtre lo0) maintiennent la stabilité du routage pendant toute l'attaque.
Filtrage à la vitesse de l'interface
Le trafic d'attaque est filtré à la vitesse de l'interface, sans impact sur le reste du réseau, tant que l'attaque tient dans la capacité de vos liens de transit et de peering.
La forme de protection la moins coûteuse
Un paiement unique. Le support technique est disponible en option et n'est pas obligatoire.
Déployé par des ingénieurs certifiés Juniper
Des ingénieurs certifiés Juniper JNCIS et JNCIE livrent le pare-feu de filtrage, la télémétrie et les tableaux de bord comme une seule solution, avec l'intégration WanGuard si vous l'utilisez.
Toutes les données restent chez vous
Toutes les données sont stockées chez vous. L'ensemble peut tourner sur un serveur existant, la collecte et la présentation générant une charge négligeable. Le plus souvent, nous l'installons sur le même serveur que WanGuard ; les besoins dépendent du nombre de routeurs.
Firewall Juniper MX : questions fréquentes
Combien de temps dure un déploiement standard ?
Un déploiement standard pour deux routeurs prend jusqu'à une semaine, souvent moins. Cela dépend de la rapidité avec laquelle l'administrateur réseau prépare avec nous la configuration cible et de la méthode de déploiement retenue comme la plus pratique. Les changements sont effectués dans une fenêtre de maintenance, car ils concernent à la fois les liens de transit et les interfaces côté clients (downstream).
Comment les nouveaux filtres sont-ils déployés ?
Les nouveaux filtres sont déployés en au moins deux ou trois étapes. La première bloque les protocoles et les paquets malformés que l'on peut rejeter sans risque, même sur le trafic de transit. Dans la deuxième, nous durcissons les protocoles : les terms passent de accept à policer (rate-limit) ou discard. La dernière étape durcit le périmètre restant pas à pas. Tous les compteurs sont visibles dans Grafana : avant chaque changement, nous voyons le volume de trafic concerné et activons le filtrage de façon incrémentale, sans impact sur le trafic des clients ni blocage trop agressif.
Le firewall et la télémétrie chargent-ils le routeur pendant une attaque DDoS ?
Non. Les règles de firewall filter sont programmées en matériel sur les interfaces, de sorte que les paquets d'attaque sont rejetés au débit de ligne. La télémétrie utilise le Junos Telemetry Interface natif, qui exporte les statistiques directement depuis le PFE sans solliciter le Routing Engine. Nous n'utilisons ni polling SNMP ni sessions périodiques sur le routeur.
Une passerelle de filtrage Juniper MX active vous intéresse ?
Pour définir le périmètre et vérifier si votre déploiement entre dans le prix affiché, il nous faut :
- le nombre de routeurs Juniper concernés,
- la série et le modèle de ces routeurs,
- la configuration des routeurs (sans SECRETS), pour évaluer la mise en œuvre de tous les filtres. Exemple de commande :
show configuration | display inheritance no-comments | display omit | except SECRET-DATA | no-more
Nous vous enverrons un guide complet de préparation des données au format PDF.
Chaque déploiement comprend l'adaptation des filtres à votre réseau et aux descriptions d'interfaces. Nous suivons votre convention de nommage existante ou ajustons légèrement les descriptions pour que Grafana affiche aussi la capacité du lien et l'engagement (commit) de l'uplink.