Sur cette page
À retenir
- L’emplacement d’abordUn filtre performant derrière un lien saturé reçoit déjà un trafic incomplet.
- Comparer des configurations complètesVitesse des ports, fonctions actives et capacité de transfert mesurée décrivent des réalités différentes.
- Inclure le comportement en panneUn bypass, un processus arrêté et une route retirée n’ont pas le même effet sur le service.
Commencer par le trajet du trafic
Matériel et logiciel décrivent la fourniture d’un composant, pas sa capacité à protéger un service précis. Un équipement peut combiner matériel spécialisé et logiciel ; un filtre sur serveur dépend toujours des cartes réseau, du PCIe, de la mémoire et du CPU. La question utile est de savoir où il voit le trafic et quelle ressource il protège.
Dessinez le trajet de l’opérateur à l’application, avec les liens partagés, tunnels et points de livraison nettoyée. Indiquez chaque limite de capacité. Un appareil placé après un lien saturé ne récupère pas les paquets perdus avant leur arrivée. Si la limite est applicative, le comportement de l’application et les sessions légitimes nécessitent leurs propres mesures et protections.
Distinguer les grandeurs derrière une capacité annoncée
Par exemple, 100 Gbit/s avec des trames Ethernet minimales de 64 octets et 20 octets de surcharge sur le fil correspondent à environ 148,81 Mpps. C’est un calcul de débit physique, pas une mesure de pare-feu ou de mitigation. Précisez si le chiffre compte les trames Ethernet, les octets IP, un seul sens ou les deux.
Demandez la configuration associée au résultat : distribution des tailles, trafic présenté et transmis, nombre de règles, fonctions protocolaires actives, états simultanés, durée, pertes et latence. Un essai de rejet seul et le transfert de trafic nettoyé avec inspection répondent à des questions différentes.
| Grandeur | Ce qu’elle indique | Ce qu’elle ne démontre pas |
|---|---|---|
| Vitesse du port | Le débit physique de l’interface. | La capacité de transfert avec vos règles et votre mélange de paquets. |
| Débit de paquets | Le nombre de paquets traités aux tailles indiquées. | Une bande passante équivalente sans taille ni convention de comptage. |
| Traitement d’attaque | La charge indésirable présentée, inspectée ou rejetée lors d’un essai défini. | Le volume de trafic légitime encore livré avec succès. |
| Capacité de plateforme | Un agrégat sur un système ou réseau défini. | Une capacité réservée à un client ou à son port de livraison. |
Comparer les modèles de déploiement
Ces modèles peuvent se combiner lorsque l’architecture le nécessite. La décision doit suivre les besoins mesurés et les responsabilités d’exploitation, sans imposer l’achat de chaque couche. Distinguez clairement l’observation du trafic, le détournement des routes et le composant qui inspecte ou rejette effectivement les paquets.
- Équipement réseau
- Vérifiez le modèle devisé, les fonctions sous licence, les interfaces, les composants redondants et le bypass. Identifiez la configuration correspondant au chiffre de performance du fournisseur.
- Logiciel sur vos serveurs
- Vérifiez cartes et pilotes pris en charge, placement CPU et mémoire, files, chemin des paquets et procédure de mise à jour. Un port rapide ne démontre pas une capacité de filtrage durable.
- Transit protégé géré
- Vérifiez la portée de la mitigation amont, la capacité livrée, le routage, les tunnels ou la remise physique, le commit commercial et les dépassements. La capacité globale du réseau n’est pas votre capacité de réception.
- Proxy adapté au protocole
- Vérifiez l’application précise prise en charge, les ports, l’identité des clients et le comportement des connexions. Un proxy pour un protocole ne protège pas automatiquement tous les services de l’origine.
Tester la protection et le comportement en panne
Vérifier l’usage légitime sous charge
Testez l’application réelle, les nouvelles connexions, les sessions établies, la supervision et le trafic de contrôle nécessaire. Relevez les transactions réussies et la latence en plus des compteurs de paquets.
Contrôler la répartition et la réception
Mesurez les files et les cœurs de traitement, pas seulement le CPU total. Vérifiez la sortie nettoyée et chaque lien récepteur. Plusieurs ports ou opérateurs amont n’impliquent pas une répartition égale du trafic.
Exercer la procédure de panne
Testez la panne convenue de lien, processus ou nœud sur un chemin isolé ou dans une fenêtre autorisée. Relevez détection, convergence, effet sur les sessions et rétablissement. Un bypass matériel peut maintenir la connectivité en laissant passer du trafic non filtré.
Prouver la maîtrise opérationnelle
Vérifiez la transmission des règles, le refus d’une mise à jour invalide, la visibilité des versions, le retour arrière, les journaux et l’accès pendant une panne de données. Définissez les intervenants et l’engagement de support de chaque composant.
Exemple : un dédié derrière une livraison limitée
Considérons un service livré par un lien de 10 Gbit/s. Un filtre local peut protéger le serveur contre une pression en paquets tant que le lien garde de la marge. Si le trafic présenté dépasse la capacité du lien, un serveur local plus puissant ne déplace pas cette limite. Il faut y répondre par le filtrage amont ou une autre architecture de livraison.
Après filtrage amont, le trafic résiduel doit encore tenir dans la livraison et la capacité applicative. Une politique locale peut être utile contre un motif résiduel vérifié, mais son coût et ses faux positifs entrent dans la recette. C’est un exemple d’architecture, pas un déploiement client mesuré.
Budgéter l’exploitation autant que les équipements
Comparez achat ou location, abonnement logiciel, support, pièces de rechange, énergie, baie, connectivité amont et temps humain sur la même durée. Identifiez si le devis comprend détection, filtrage des paquets, contrôleur, rapports et instance redondante. Des unités de licence différentes ne sont pas directement interchangeables.
Prévoyez aussi les évolutions : qualification firmware et noyau, revue des règles, fenêtres de maintenance et exercices de reprise. Un composant bon marché peut coûter cher si personne n’en maîtrise l’exploitation. À l’inverse, un équipement dédié ne dispense pas de valider routage, compatibilité applicative et procédure d’intervention.
Transformer la comparaison en sélection concrète
Rédigez une courte fiche avec topologie, pic légitime attendu, mélange de paquets, destinations, protocoles, pertes acceptables et objectifs de reprise. Demandez ensuite à chaque fournisseur les composants exacts et les preuves correspondantes. Gardez les fonctions non vérifiées sous forme de questions ; une absence dans le marketing ne prouve pas une absence technique.
Questions fréquentes
Le matériel est-il toujours plus rapide que le logiciel ?
Aucun classement général n’est fiable. Comparez le matériel réel, l’implémentation, les fonctions actives, le trafic et les conditions de mesure.
Un bypass garantit-il le maintien de la protection ?
Non. Il peut préserver un lien en faisant contourner le composant de filtrage. Vérifiez à la fois la joignabilité et l’état de protection obtenu.
L’achat du logiciel inclut-il une mitigation amont ?
Pas automatiquement. Logiciel, capacité serveur, connectivité et filtrage amont sont des éléments distincts de l’architecture et du devis. Vérifiez le périmètre de l’offre concernée.
