web-dev-qa-db-fra.com

Un nombre significatif de requêtes non-HTTP frappant mon site

Je vois un nombre important de requêtes non-HTTP sur un site que je viens de lancer. Ils apparaissent dans les journaux du serveur (nginx) en tant que non-ASCII et sont rejetés (correctement) avec un statut 400. Voici quelques lignes du journal:

95.132.198.189 - - [09/Jan/2011: 13: 53: 30-0500] "œ $ A\x10õœ²É9J" 400 173 "-" "-" 
 79.100.145.126 - - [09/Jan/2011: 13: 57: 42 -0500] "# §i²¸oYi Ṅ\x13VJ — x · —œ\x04N\x1DÔvbÛè½\x10§¬\x1E0œ_ ^ ¼ +\x09ÜÅ\x08DÌíiie € x ßýúê5Ǹ "400 173" - "" - "
 79.100.145.126 - - [09/Jan/2011: 13: 58: 33 -0500]" ¯Ú% ø = Œ ›D @\x12î½ ‰ ¼\x1C † de\x015mˆàd˜Û% pÛÿ "400 173" - "" - "

Que devrais-je en faire? Est-ce une sorte d'attaque scriptée? Ou pourrait-il s'agir de demandes correctes qui ont été déformées?

Ils n'affectent pas les performances du site et je ne vois aucun autre signe d'attaque (par exemple, aucun POST étrange), donc, à ce stade, je suis plus curieux que craintif.

nginxsecurity
1
Mark Westling

J'ai travaillé sur de très gros sites (1 milliard de PV/jour sur le plus grand), environ 1 à 2% de leur trafic était constitué de sondages d'exploits aléatoires/d'araignées/de robots d'exploration.

  • Trucs de manipulation de chemin classique comme ..\..\..\cmd etc.
  • Les dépassements de tampon plus sophistiqués dans POST et/ou GET sont similaires à ceux de vos journaux.
  • Des crawlers simples et mal alignés qui ont mal codé ou omis certains aspects essentiels du protocole HTTP.
  • connexions clientes enchevêtrées altérant les données transmises.

Il semble plausible qu'il s'agisse d'une attaque par dépassement de tampon. Voyez-vous d'autres instances du même modèle de demande? Il est tout à fait plausible de voir des clients et des connexions foutus. L'activation de la journalisation pour d'autres variables du W3C telles que l'agent utilisateur, etc. peut également vous donner plus d'indices. par exemple. l'absence d'en-têtes réguliers comme accept, méthode, etc.

Nous avons généralement:

  1. veillé à ce que nos serveurs soient corrigés régulièrement au cas où ;-)
  2. utilisé des outils tels que UrlScan (nous utilisions IIS) pour rejeter les demandes malformées au début du pipeline de demandes.
  3. nous avons limité la taille de nos demandes POST et GET afin d'empêcher certaines des attaques les plus folles de DDoS.
  4. Tous les trafics non-2xx/3xx enregistrés dans les journaux sont régulièrement surveillés et surveillent les nouveaux modèles. Croyez-le ou non, Excel est un excellent outil pour numériser, découper et découper des données rapidement.

Bien que certaines actions soient IIS spécifiques, je ne doute pas que nginx dispose d'outils similaires. En général, il y a maintenant tellement de bruit sur Internet de bots aléatoires que j'ai appris à être simplement vigilant et à rechercher les nouvelles tendances émergentes.

2
stephbu