web-dev-qa-db-fra.com

Qu'est-ce que ce type d'attaque de faible intensité et sans piratage sur un service Web?

Je vois depuis environ 10 jours maintenant un tas de machines EC2 (environ 30, distribuées dans toutes les régions) qui attaquent un de mes serveurs.

Le fait intéressant (ou inintéressant, je ne sais pas encore) est que

  • ils ciblent un service Web ouvert sur un port non descriptif (qui a probablement été trouvé lors d'une analyse antérieure)
  • ce port répond par un 200 à une requête HTTP
  • les requêtes se trouvent uniquement à la racine de l'URL ...
  • ... ce qui leur apporte une page vide

En d'autres termes, ils font continuellement un GET / sur ce service Web.

Cela aurait pu être un DDoS, sauf que

  • le nombre de machines est très limité et bien défini
  • il y a 4 requêtes par minute, toutes soigneusement regroupées (en ~ 5 secondes) au milieu de la minute

Donc, ce n'est pas un DoS (le taux est insignifiant), pas un DDoS (à côté du taux, la population est petite), pas de tentatives de piratage (la demande est obstinément sur une URL, j'ai regardé le trafic et c'est le seul port ciblé ).

Je vais le classer comme "riche (de nombreuses machines EC2, ils peuvent également utiliser le niveau gratuit) mais stupide, pas sûr de quoi" si personne n'a une idée de ce que c'est.

networkattacks
78
WoJ

Cela ressemble au comportement d'un service de disponibilité. Ceux-ci se connectent à partir de plusieurs emplacements à intervalles réguliers et sont conçus pour alerter le propriétaire du serveur en cas de problèmes.

Dans ce cas, il semble que le propriétaire du serveur ait mis en place un tel service, puis l'ait oublié, car le serveur n'a eu aucun problème - le service d'alerte n'enverrait pas d'alertes sauf en cas de problème, il est donc facile de oubliez-les.

Répondre à une question en commentaire: pourquoi effectuer des vérifications supplémentaires? Plusieurs raisons:

  • Vérifie qu'un problème existe sur le serveur cible, plutôt que sur le serveur de test
  • Permet des tests géographiques, en faisant des demandes depuis plusieurs endroits
  • Permet des tests plus complexes, tels que les temps de réponse, tout en évitant les problèmes de réseau qui pourraient affecter les serveurs individuels
  • Garantit que le service de disponibilité lui-même ne subit pas de pannes de serveurs uniques en panne!
145
Matthew