Utilisation normale vs déni de service? Combien de demandes sont nécessaires pour parler d'un déni de service?
Récemment, j'ai utilisé un outil pour télécharger un site Web et dans le cadre de l'outil, on pouvait ajuster le nombre de connexions parallèles. Alors maintenant, je me suis retrouvé à demander: à partir du nombre de demandes qu'un fournisseur pourrait évaluer comme un déni de service. Je suis allé sur Google, mais je n'ai pas trouvé de chiffres spécifiques ou du moins des indices sur les dimensions dont nous parlons. Existe-t-il une définition, par exemple comme 100 demandes par seconde?
Ma question est donc la suivante: combien de demandes sont nécessaires pour déclarer qu'un déni de service est en cours?
Mise à jour: le contexte technique est certainement intéressant. Je comprends que un paquet malveillant pourrait être suffisant pour provoquer un déni de service ou l'effet slashdot en est un autre. Mais ce que je voulais savoir, c'était plus une règle de style pare-feu: certains serveurs/fournisseurs de services bloquent les utilisateurs qui envoient trop de demandes dans un certain laps de temps. De quelle dimension parlons-nous ici? Ou est-ce trop spécifique? Si oui, à quoi ressemblerait votre règle?
La question avait également une composante juridique - permettez-moi d'illustrer un scénario théorique élevé (!):
Un fournisseur de service vérifie ses journaux et constate qu'il y a eu un trafic élevé à partir d'une seule adresse IP. Maintenant, le fournisseur va au tribunal (pour une raison quelconque) et qualifie cela de tentative de déni de service. Le juge demanderait probablement leur définition d'un DoS. "Tout ce qui dépasse l'usage normal" serait leur réponse. Alors, où est le seuil entre une utilisation normale et "aucune" utilisation normale (qui pourrait être interprétée comme une tentative de DoS même si le serveur reste totalement impressionné et c'est probablement un scénario très construit ;-)
J'ai débattu de la possibilité de faire de cela une réponse, ce serait peut-être mieux en tant que commentaire.
Jetons un œil à votre question sous les deux angles.
De l'hôte
Quelque chose devient un DoS lorsque le trafic, ou ce que fait ce trafic, rend le serveur indisponible pour les autres. Quelques exemples;
- Exécution d'un rapport de longue durée 500 fois
- briser le rafraîchissement très rapidement sur un site Web qui ne peut pas le gérer
- en utilisant votre plus grande bande passante pour remplir leur canal de téléchargement afin que les autres perdent de la vitesse.
- gratter le site Web de manière à ce que l'hôte ne réponde pas aux autres.
Tous ces exemples sont possibles, mais peu probables. Lorsque nous parlons d'une attaque DoS, nous parlons d'une personne/d'un client qui fait tout cela, et la plupart des serveurs Web sont configurés pour gérer des centaines ou des milliers de demandes en même temps. C'est pourquoi DDoS est si populaire. Parce qu'il faut plus d'un client pour surcharger un serveur normal (dans des circonstances normales).
Pour ajouter des complications, de nombreux clients peuvent commencer à utiliser votre site pour la première fois après un certain marketing. Parfois, ce n'est même pas votre marketing qui le déclenche. Par exemple, une version populaire de téléphone portable peut provoquer une augmentation du trafic sur votre site Web. Il peut être très difficile de distinguer le trafic DDoS du trafic légitime.
Il existe cependant quelques règles de base. Ce que vous recherchez essentiellement, c'est une utilisation anormale.
- Y a-t-il des utilisateurs qui téléchargent bien plus que d'autres?
- Y a-t-il des utilisateurs qui restent connectés plus longtemps que les autres?
- Y a-t-il des utilisateurs qui se reconnectent bien plus que d'autres?
Ces guides et d'autres peuvent vous aider à déterminer quel trafic fait partie d'une attaque DDoS et à appliquer une sorte de filtre.
Du POV de l'utilisateur
Lorsque vous décidez de gratter un site Web, vous devez d'abord vérifier et voir s'ils ont une politique. Certains sites le font et d'autres non. Certains sites le considéreront comme un vol, d'autres non. Si un site n'a pas de politique, vous devez faire votre propre appel.
Votre objectif, s'ils n'ont pas de politique définie, est d'indiquer clairement que votre grattage (ne masquez pas l'agent utilisateur ou l'en-tête que votre outil pourrait utiliser) et d'essayer d'avoir le moins d'impact possible. Selon votre besoin de grattage, pouvez-vous gratter quelques pages ou avez-vous vraiment besoin de l'ensemble du site? Pouvez-vous gratter à un taux "utilisateur normal", peut-être 1 page toutes les 5 secondes environ (y compris le contenu multimédia)? Si vous souhaitez capturer les données rapidement, pouvez-vous simplement capturer les fichiers texte et ne pas capturer les images et autres supports? Pouvez-vous exclure les requêtes de longue durée et les fichiers multimédias plus volumineux.
Vous avez ici pour objectif général d'être respectueux des frais d'hébergement des hébergeurs et des autres utilisateurs du site. Plus lent est généralement meilleur dans ce cas. Si possible, contactez le propriétaire du site Web et demandez-lui. Et quoi qu'il en soit, suivez les règles du fichier robots.txt. Il peut avoir une limite de taux et des limites de page que vous devez suivre.
Assez pour que le service soit refusé à quelqu'un. Il peut s'agir d'une demande malveillante inattendue, qui entraîne une charge excessive sur le serveur. Peut-être plusieurs millions de demandes attendues, à partir d'une publicité télévisée avec une très bonne réponse.
Il n'y a pas de valeur spécifique, car tous les serveurs échoueront à différents niveaux - servir du contenu statique est beaucoup plus facile sur le serveur que générer du contenu hautement personnalisé pour chaque utilisateur, donc les services authentifiés auront généralement un seuil de "problème" plus bas que ceux non authentifiés ceux. Les serveurs envoyant le même fichier à plusieurs utilisateurs peuvent gérer plus de trafic que les serveurs envoyant des fichiers distincts à plusieurs utilisateurs, car ils peuvent conserver le fichier en mémoire. Un serveur avec une connexion rapide à Internet sera généralement capable de gérer plus de trafic qu'un serveur avec une connexion lente, mais la distinction pourrait en être moins dépendante si le trafic généré est lié au CPU.
J'ai vu des systèmes qui échouent à 3 requêtes par seconde. J'ai également vu des systèmes qui traitent tout jusqu'à 30 000 requêtes par seconde sans transpirer. Ce qui serait un DoS au premier, serait une période de faible trafic au second ...
Mis à jour pour répondre à la mise à jour
Comment les fournisseurs de pare-feu déterminent-ils quand le trafic provoque un déni de service?
Habituellement, ils surveillent les temps de réponse du serveur et limitent le trafic s'ils dépassent une limite prédéfinie (cela peut être décidé sur une base technique ou sur une base marketing - attendre x secondes provoque le départ des gens), ou si les réponses du serveur passent de réussi (200) à échec de serveur (50x).
Quelle est la définition légale du "déni de service"?
Identique à l'original que j'ai donné - ce n'est pas un déni de service si le service n'a pas été refusé. Cela pourrait être abusif, mais ce ne serait pas tout à fait la même chose.
Lorsque vous téléchargez (ou supprimez) un site Web, vous envoyez essentiellement un grand nombre de demandes GET pour chaque URL du site Web cible.
Voici un exemple de demande GET du site Web du World Wide Web Consortium:
GET /pub/WWW/TheProject.html HTTP/1.1
Hébergeur: www.w3.org
Comme vous pouvez le voir, le problème principal n'est pas la demande mais la réponse du serveur web, qui vous envoie toute la ressource identifiée par l'URL donnée.
Par conséquent, nous pouvons dire que
Nombre maximal de demandes par seconde = (Facteur de sécurité * bande passante)/Taille maximale d'une page Web
À en juger par une recherche rapide sur Google, la taille moyenne d'une page Web est d'environ 2 Mo et la bande passante d'un serveur Web peut aller de quelques Mbps à quelques Tbps.
Le facteur de sécurité est lié au fait que, pour provoquer une attaque DoS, vous n'aurez peut-être pas besoin d'envoyer un certain nombre de requêtes correspondant à 100% de la bande passante. Par exemple, si le serveur Web a une bande passante de 100 Mbps et que 50% de celle-ci est utilisée à un instant donné pour d'autres utilisateurs, il suffit d'envoyer un nombre de requêtes correspondant à 50%, voire un pourcentage plus faible, de la bande passante .
50% de 100 Mbps = 50 Mbps, ce qui correspond à 25 requêtes GET moyennes par seconde.
D'un autre côté, si personne d'autre ne visite le site Web, vous devrez utiliser au moins 80% de la bande passante pour provoquer un DoS, et 80% de 100 Mbps = 80 Mbps, ce qui correspond à 40 requêtes GET par seconde.
De toute évidence, pour (involontairement) faire un DoS sur un énorme site Web ayant une bande passante de 1 Tbps, vous devez envoyer au moins (80% de 1 Tbps)/2 Mbps = 400 000 requêtes GET par seconde. Etc.
Afin d'avoir une mesure plus précise, vous devez trouver la taille maximale d'une page Web dans le site Web cible et sa bande passante.
Attention: puisque vous pourriez potentiellement avoir des ennuis pour causer un déni de service, il est préférable d'arrondir le nombre de requêtes par seconde que vous obtenez via la formule précédente.
Pour tirer parti de la réponse de Matthew concernant le commentaire de Philip Rowlands:
La règle générale pour définir le trafic DoS est context.
Si vous venez de diffuser une publicité télévisée au superbowl, vous pouvez supposer que le flot de trafic qui en résulte n'est pas contextuellement malveillant (qu'il ne soit pas pertinent de provoquer une interruption de service).
Alors que, s'il ne s'agit que d'un autre mardi matin et que votre site est inondé de demandes sans raison identifiable, il serait prudent de supposer que le trafic est malveillant (ou au moins suspect, par exemple, un message reddit inconnu par opposition à une attaque ciblée) .