Cookies nécessaires
Conditions de déploiement
Protection DDoS pour hébergeurs et fournisseurs de serveurs
L’attaque d’un client ne devrait pas devenir une panne inexpliquée de toute une baie ou d’un cluster de virtualisation. Identifiez les ressources partagées, les politiques propres à chaque client et le point d’entrée du trafic protégé.
Partir des limites de l’hébergement invisibles pour le client
- Un point de saturation commun derrière des machines isolées
- L’isolation des VM ne sépare pas la capacité de l’uplink, des files de la carte réseau ou de l’hyperviseur. Un hôte peut épuiser son traitement des paquets avec un débit apparemment modeste. Distinguez les observations de l’interface physique, de l’hôte et des machines invitées.
- Des usages différents sur le même réseau
- VPN, messagerie, jeu et site public n’ont pas les mêmes paquets légitimes. Une règle générale peut remplacer une surcharge par des faux positifs. Définissez le préfixe ou le service concerné et la personne autorisée à modifier sa politique.
- Des responsabilités réparties dans la chaîne de revente
- Hébergeur, client final et opérateur amont peuvent chacun gérer une partie des adresses, des routes et de la réponse aux incidents. Convenez de qui valide une annonce, signale un faux positif et informe le client du rétablissement.
Choisir qui exploite la couche de filtrage
Un service réseau protégé peut être livré à la bordure de l’hébergeur. Les opérateurs équipés peuvent aussi étudier Defense Fabric pour le filtrage local. Licence, transport et service vendu au client restent des responsabilités distinctes.
Protéger l’entrée partagée
Définissez préfixes ou points d’accès publics, débit livré et périmètre de la protection amont.
Appliquer une politique locale maîtrisée
Si le filtrage local est nécessaire, qualifiez le matériel, la disposition des ports, la répartition du trafic et les règles choisies.
Valider l’expérience du client
Testez de vraies connexions dans les usages pris en charge et conservez un moyen de revenir à la politique précédente.
Exemple de cheminement. Le devis et le procès-verbal de recette définissent le service livré.
Les questions qui changent l’architecture
- Souhaitez-vous une livraison gérée ou exploiter vos propres filtres ?
- Comparez le périmètre d’exploitation, pas seulement le prix de la licence et du transit. Le filtrage local nécessite matériel compatible, maintenance, observation et procédure de réponse convenue.
- Quel trafic peut traverser plusieurs nœuds de filtrage ?
- Définissez entrée, retour, responsabilité de l’état et comportement de bascule. Ajouter des nœuds ou des interfaces ne garantit pas une capacité utilisable lors de la perte d’un nœud.
- Comment distinguer les clients dans l’exploitation ?
- Gardez une correspondance à jour entre préfixes ou points d’accès autorisés, responsable du service et politique. Utilisez-la lors des incidents ; une adresse partagée ou une règle large n’identifie pas nécessairement un seul client.
Tester un ensemble représentatif de services hébergés
- Relevez les connexions réussies des services réellement vendus, y compris les usages partageant des adresses sources.
- Observez files de l’hôte, pertes, compteurs de règles et succès applicatif sur le même intervalle.
- Testez le retour à la politique précédente et le chemin de secours convenus, puis vérifiez le service des clients non concernés.
Questions sur ce déploiement
La licence Defense Fabric inclut-elle le transit protégé et les serveurs ?
Non. Matériel compatible, hébergement et transport sont à budgéter séparément. Un éventuel service réseau Peeryx figure comme un composant distinct.
Un profil de jeu couvre-t-il toutes les applications hébergées ?
Non. Utilisez les fonctions documentées pour le protocole réel et testez le trafic légitime. Les livraisons FiveM et Minecraft Java demandent leur propre étude de compatibilité.