Protection DDoS pour un VPS : capacité, règles applicatives et récupération

Un chemin réseau saturé, une table de connexions épuisée et une requête applicative coûteuse nécessitent des contrôles différents. Collectez les compteurs réseau, les taux de requêtes et les temps de réponse. Le premier symptôme est une preuve à examiner, pas la preuve d'un seul type d'attaque.

La vitesse de port du serveur, l'allocation de transfert sur la période et la capacité d'atténuation sont des spécifications différentes. Les valeurs d'atténuation du catalogue préparé vont de 10 à 400 Gbps selon le forfait. Aucune ne modifie le temps CPU nécessaire pour répondre à une requête coûteuse.

Umbra 1 indique un port serveur 1 Gbps, un transfert mensuel de 1 TB et une spécification d'atténuation 10 Gbps. Le premier décrit la connexion, le deuxième une allocation sur une période et le troisième une enveloppe de filtrage proposée. Aucun ne signifie que l'application peut répondre à 10 Gbps de requêtes utiles. Le comportement de filtrage et le trafic autorisé doivent être validés sur le réseau de lancement.

La conception préparée détecte les anomalies de trafic, redirige les attaques vers le filtrage et renvoie le trafic autorisé. Son objectif d'activation prévu est inférieur à 60 secondes, mais le routage en direct et les contrôles amont doivent être testés avant que cela ne devienne une promesse. Demandez ce qui se passe au-delà de l'enveloppe incluse et comment le trafic légitime est rétabli.

Mettez en cache les réponses appropriées, limitez le débit des chemins coûteux et sécurisez l'accès administratif. Un WAF ou un proxy inverse doit être configuré et maintenu comme une couche distincte. Restreignez l'accès web à l'origine aux sources proxy de confiance si cela fait partie de la conception, sans fermer la voie de récupération.

Attribuez qui peut modifier les règles, quelles preuves appartiennent à un ticket et comment les utilisateurs apprennent le statut. Testez la livraison des alertes et la route de remplacement. Une sauvegarde fonctionnelle et un registre d'incident sobre sont utiles même lorsque l'événement s'avère être une défaillance d'application.

Les incidents L3/L4 peuvent impliquer une amplification UDP via DNS, NTP ou memcached, ou des inondations TCP SYN qui sollicitent l'état des connexions. Les incidents L7 ciblent le travail applicatif, comme des recherches ou des tentatives de connexion répétées. Comparez séparément les bits par seconde, les paquets par seconde et les requêtes par seconde. Un filtre en périphérie, un contrôle de connexion et une règle applicative résolvent différentes parties du problème.

• Fermez ou restreignez les services UDP publics inutiles et gardez l'accès à l'origine délibéré.
• Une conception anycast géographiquement distribuée nécessite le retrait de routes, la gestion d'état et des tests de basculement ; elle n'est pas établie par un chiffre de capacité d'atténuation.

Un défi, un CAPTCHA ou une porte de preuve de travail peut ajouter des frictions aux requêtes suspectes. Cela peut aussi affecter les visiteurs légitimes, les clients automatisés et l'accessibilité, donc appliquez-le aux points de terminaison appropriés et mesurez le résultat. Une réponse lente ou un tarpit occupe aussi des ressources ; testez le coût avant de supposer qu'il est moins cher que de rejeter la requête.

• Gardez une voie de récupération ou de support accessible lorsqu'un défi empêche l'entrée.
• Les limites de requêtes, la mise en cache et les correctifs applicatifs restent utiles même lorsqu'un défi est activé.