Est-il pratique de forcer un nombre à 10 chiffres par URL
Exemple d'URL www.[somewebsite].com/[10_digit_number]
Obtenir le bon numéro charge une page.
Je sais qu'il y aurait 10 milliards de chiffres possibles, mais combien de temps cela prendrait-il? De quelles ressources aurait-on besoin?
Environ un jour
Si nous sommes chanceux: il n'y a pas de limitation, nous pouvons effectuer chaque test avec une demande HEAD, nous pouvons effectuer de nombreux tests sur une seule connexion HTTP avec Keepalive et avoir plusieurs connexions simultanées).
Dans ce cas, nous sommes principalement limités par la bande passante. Supposons que nous élaborons une demande stricte de 100 octets, cela signifie que nous devons envoyer un total de 100 * 10dix octets. Et supposons que nous ayons une connexion décente de 100 Mbps, ce qui fera environ 10 mégaoctets par seconde. Cela prendrait 100 000 secondes - un peu plus d'une journée.
Dans le meilleur des cas, dans la pratique, il est probable que des problèmes l'empêchent de fonctionner si rapidement. Nous pourrions avoir plusieurs systèmes fonctionnant simultanément pour le rendre plus rapide - mais à un moment donné, nous surchargerons le serveur.
Rouler un nombre à 10 chiffres ne prend pas beaucoup de temps sur la plupart des systèmes, quel que soit le script/langage utilisé. Le plus gros problème ici est le nombre de connexions que vous ouvrez simultanément et le délai entre les demandes. Un bon système configuré bloquera trop de requêtes provenant de la même adresse (soit par le pare-feu, soit par le démon lui-même).
Par exemple:
#!/bin/bash
for i in {1..1000}
do
curl "www.[somewebsite].com/$i" > "${i}_out.txt"
done
Vous voudrez peut-être en parler.
Cela dépend de plusieurs facteurs.
Du côté serveur
- Bande passante du serveur
- Ce numéro demandé génère-t-il une requête sur une base de données?
- Tout pare-feu/script de sécurité pour détecter ce type d'activité et le bloquer
- Toutes les autres ressources qui peuvent être un goulot d'étranglement comme le processeur ou la mémoire.
- Si vous êtes ce genre de gens chanceux qui l'essayeront sur un serveur où les journaux sont stockés sur un système de fichiers très limité, et ce type d'activité en consommera chaque octet gratuit, ce qui arrêtera l'application.
Côté client
- Votre bande passante
Mes considérations concernant cette activité:
Faites d'abord une requête DNS et voyez s'il y a plus d'un serveur pour cette adresse. Cela vous aidera, plus de serveur, plus vous pouvez répartir la charge.
Testez le pare-feu, obtenez un VPS et faites des tests pour obtenir une idée de votre environnement sans mettre votre adresse IP sur liste noire. Testez certains taux, 100, 1000, 10000, par seconde. Testez le temps de réponse moyen pour chaque heure de la journée. Si les temps de réponse changent, votre serveur a donc des fenêtres temporelles qui reçoivent plus de trafic/demandes et ce sera le bon moment pour ne pas stresser le serveur.
Avec tous les résultats ci-dessus, vous saurez quoi faire. Si le serveur a plus de bande passante que vous, ce qui se produit presque tout le temps, vous pouvez obtenir un VPS pour vous aider, choisissez-en un près du serveur. Vous aurez votre plan sur le nombre de requêtes qui sera optimal pour archiver votre solution, par exemple, si les serveurs reçoivent plus de charge le matin, vous pouvez utiliser 1000/s pendant la journée, par exemple de 8h à 22h, et utiliser autant les serveurs peuvent répondre de 22h à 8h.
Sachez simplement que ce type d'activité peut entraîner le plantage de certains services ou une charge si importante qu'ils ne pourront pas répondre aux utilisateurs et que cela peut être considéré comme une attaque par déni de service. Il peut vous causer des ennuis en raison de plusieurs facteurs, je ne connais pas tous les pays, dans plusieurs pays, ce type d'attaque est un crime. Contactez l'administrateur système au sujet de vos intentions, avant de planter un système et de devenir responsable d'un temps d'arrêt.
Une journée est extrêmement irréaliste , quelles que soient les ressources.
Il y a 86 400 secondes par jour. Arrondissez jusqu'à 100k. Divisez 1B par 100k et vous obtenez 10 000 requêtes par seconde. C'est assez grand. Le serveur aura besoin d'une histoire d'équilibrage de charge décente et d'une bonne quantité de capacité de calcul. Pour référence, si nous avons 100 machines avec 8 cœurs chacune (pour un total de 800 cœurs), nous aurons besoin de tourner autour de chaque demande au maximum 80 ms , ce qui est serré mais pas entièrement déraisonnable . Le client aura également besoin d'une capacité proportionnelle à celle du serveur, et en supposant que vous êtes un attaquant black hat, vous utilisez probablement un botnet ou quelque chose de ce genre.
En fait, vous devez exploiter un botnet, car le client doit être réparti géographiquement de telle sorte que le serveur puisse équilibrer la charge sans traverser les liaisons réseau à latence élevée. Ceci est essentiel car la latence entre le serveur et le client compte pour notre budget de 80 ms. Si le client est entièrement en Amérique mais que la moitié du serveur est en Europe, la latence transatlantique ruinera complètement nos performances, et nous aurons besoin de beaucoup plus de capacité pour compenser cela (ou bien nous devrons simplement traiter toutes les demandes avec la moitié américaine du serveur, qui rencontre des problèmes de capacité similaires).
Mais attendez! Vous avez dit "quelles que soient les ressources". Pourquoi me lancez-vous des numéros de ressource?
Parce que les personnes qui exploitent des services Web à cette échelle ont généralement une surveillance suffisante pour détecter une inondation soudaine de trafic QPS de 10 000 à partir d'un botnet. Selon toute vraisemblance, votre cible déterminera que vous les attaquez par DDoS (ce qui est essentiellement ce que vous faites) et déploiera des atténuations standard (par exemple, servir des 503 ou des CAPTCHA, noircir le trafic, etc.). À ce stade, votre attaque échouera ou prendra au moins beaucoup plus de temps que prévu, et les autorités s'efforceront désormais de démanteler votre botnet.
Donc, si vous voulez que votre attaque fonctionne réellement, vous ne pouvez pas le faire à cette vitesse. Soit votre cible ne peut pas gérer le trafic, soit elle est suffisamment intelligente pour le détecter et le bloquer.