Donner du fil à retordre aux robots d'exploration et aux scripts malveillants
Mon serveur Web fonctionne depuis moins de 25 heures et a déjà été exploré pour diverses pages par défaut, pour n'en nommer qu'une /administrator/index.php.
Je comprends que c'est très courant et ce n'est pas vraiment un problème pour moi, car j'ai sécurisé le serveur de manière décente.
Pour l'idée suivante, supposons que je ne me soucie pas du trafic résultant.
Et si je devais créer un certain nombre des fichiers les plus demandés, représentant généralement des interfaces administrateur ou d'autres vecteurs d'attaque d'un site Web commun.
Le fichier (par exemple /administrator/index.php) pourrait ressembler à ceci:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>/administrator/index.php</title>
</head>
<body>
content ^1
</body>
</html>
Mais pour le contenu réel du corps, je viens de ramer quelques Go avec des chaînes aléatoires.
Par exemple dd if=/dev/urandom bs=10M count=400 | base64 > /tmp/content, puis enroulez les balises HTML ci-dessus autour du fichier.
Que feraient les robots typiques lors d'un tel événement?
Tu te fais du mal.
"L'attaquant"/robot d'exploration ... ne paie probablement pas pour son trafic ou sa puissance de traitement (c'est-à-dire qu'il utilise un botnet, des serveurs piratés ou au moins est sur une connexion qui ne lui fait pas payer pour le trafic), mais vous sera facturé pour le trafic et le CPU/stockage/mémoire, ou l'hébergeur de votre serveur a une clause "fair use", en vertu de laquelle la connexion de votre serveur sera limitée ou coupée si vous fournissez des gigaoctets de données à court terme, ou votre bande passante de stockage sera réduit, ou votre utilisation du processeur limitée.
Aussi, pourquoi quelqu'un devrait-il être aussi stupide de télécharger des gigaoctets de données alors qu'il ne recherche qu'une page spécifique? Soit ils recherchent juste existence de cette page, auquel cas la taille de la page n'aura pas d'importance, soit ils définiront à la fois un délai d'expiration et une taille maximale - pas besoin d'attendre quelques secondes pour un serveur pour terminer une réponse si vous avez des centaines d'autres serveurs à analyser, et surtout pas lorsque la liste grise est une technologie bien connue pour ralentir les attaquants.
Considérez que servir autre chose que la page HTTP 404 pour /administrator/index.php peut placer votre serveur dans les listes de cibles potentielles, ce qui signifie encore plus d'analyses à l'avenir. Étant donné que les crackers qui paient pour ces listes n'ont pas besoin d'analyser eux-mêmes des millions d'adresses IP, ils peuvent se concentrer sur vous avec des attaques beaucoup plus sophistiquées que de rechercher la page d'administration par défaut.
À moins que votre serveur ne soit configuré dans le but d'attirer des activités malveillantes, ressembler à une victime potentielle ne vous sera d'aucune utilité.
Comme déjà dit, ce n'est probablement pas la peine, mais c'est un sujet très intéressant à penser. Il y a eu une très bonne conférence sur ce sujet au DEF CON 21 intitulée " Making Problems for Script Kiddies and Scanner Monkeys " que vous pouvez trouver ici: - https://www.youtube.com/watch?v=I3pNLB3Cq24
Plusieurs idées sont présentées, et certaines sont très simples et efficaces comme l'envoi de certains codes de réponse HTTP aléatoires, qui n'affectent pas l'utilisateur final, mais ralentissent considérablement les scanners. Le discours vaut le détour :)
Edit: Ceci est un bref résumé de l'exposé pour ceux qui n'ont pas le temps de le regarder: les navigateurs interprètent de nombreuses réponses HTTP de la même manière, indépendamment de leur Code de réponse. Ce n'est bien sûr pas le cas pour tous les codes de réponse (comme les redirections 302), mais par exemple si votre navigateur obtient un code 404 "non trouvé", il rendra la page de la même manière s'il s'agissait d'un code 200 "OK". Mais les scanners/robots d'exploration sont différents. Ils dépendent principalement du code de réponse renvoyé. Par exemple, s'ils obtiennent un code de réponse 404, ils concluent que le fichier n'existe pas, mais s'ils obtiennent un code de réponse 200, ils concluent que le fichier existe et feront des trucs avec lui (scannez-le, signalez-le à l'utilisateur , ou autre chose).
Mais que se passe-t-il si vous configurez votre serveur Web pour n'envoyer que 200 codes (même si la ressource n'existe pas)? Les utilisateurs normaux ne le remarqueront probablement pas, mais les scanners seront confus car toutes les ressources auxquelles ils tentent d'accéder (par exemple par force brute) seront signalées comme existantes. Ou si vous ne renvoyez que 404 réponses? La plupart des scanners penseront qu'aucune des ressources auxquelles ils tentent d'accéder n'est disponible.
La conférence aborde cela et teste divers codes de réponse et divers scanners, et la plupart d'entre eux peuvent facilement être confondus de cette façon.
Edit2: Une autre idée que je viens de recevoir. Au lieu d'envoyer 10 Go de données comme vous l'avez dit à ceux que vous pensez être des scanners, pourquoi ne pas simplement envoyer une réponse HTTP avec un en-tête Content-Length d'une valeur de 10000000000, mais n'ajouter que quelques octets de données dans le corps de la réponse HTTP? La plupart des clients attendent le reste de la réponse, jusqu'à ce que la connexion expire. Cela ralentirait massivement les scanners. Mais encore une fois, cela n'en vaut probablement pas la peine, et vous devez vous assurer de ne le faire que pour ceux que vous détectez en tant que scanners.
Oubliez les gigaoctets. Utilisez des minutes ou des heures de retard. De nombreux serveurs Web ont des modules qui introduisent des retards artificiels (aka tarpits). Il occupe un thread/processus sur votre serveur, mais il réconforte quelques autres serveurs sur Internet qui auraient été sondés pendant le temps. Bien sûr, d'autres bots et autres threads de ce bot continuent leur travail, donc la gêne est mineure.
C'est un sujet qui me tient à cœur, j'ai lutté contre les bots, etc. depuis des lustres. Ma conclusion est que votre meilleure stratégie toujours, bien que pas très gratifiante, consiste simplement à absorber le trafic, c'est-à-dire à détecter qu'il s'agit d'un bot, puis à neutraliser toute autre action de sa part, sans donner d'indication programmatique évidente que vous avez fait (évident serait d'envoyer un gros fichier en réponse à une demande de page html; servir une page en leur disant qu'ils sont mauvais et non autorisés - une erreur que j'ai faite pendant des siècles, ne réalisant pas que c'est un logiciel, pas une personne). Par programmation non évidente, cela signifie que pour les logiciels automatisés d'araignée de robots, la réponse semble normale et ne déclenche pas de signal d'alarme en interne.
Pour comprendre à quoi ressemblent les pages non évidentes par programmation, prenez le temps d'examiner, par exemple, un site Web de spam créé par SEO que vous accédez à une recherche Google. Ces pages sont conçues pour contourner les filtres de robots Google, c'est-à-dire qu'elles ne déclenchent pas de drapeaux rouges internes de Google Spidering, c'est pourquoi elles vous ont été proposées en tant que résultat SERP) dans votre recherche. Les bots ne sont pas très compliqués (la vitesse/efficacité est plus critique pour les activités des bots) en termes de sophistication de la programmation, c'est-à-dire que leur capacité à `` lire '' la page ou la réponse a tendance à être assez basique, et il n'est pas très difficile de leur donner quelque chose cela ressemble à une réponse normale.
Certaines des réponses ici pointent vers un problème qui, jusqu'à ce que vous l'ayez personnellement expérimenté, est facile à ne pas comprendre la gravité, et cela sous-estime les ressources, et la vindicte possible, des maîtres de bot. Si vous vous engagez dans le type d'astuces envisagées ici, seules quelques choses se produiront:
vous utilisez les ressources du serveur sans raison ni gain
vous exaspérez les opérateurs de robots, qui peuvent ensuite vous ajouter à des listes réparties dans le monde entier qui sont essentiellement des bases de données de sites à cibler fortement, généralement parce que ce sont de bonnes cibles, mais ils peuvent tout aussi facilement ajouter votre site à cette liste. Cela m'est déjà arrivé auparavant, et il m'a fallu des mois pour programmer les attaques parce que bien qu'elles ressemblent à DDOS, elles ne le sont pas réellement, ce sont simplement divers opérateurs de logiciels de robots utilisant ces listes principales.
J'ai à certains moments essayé d'envoyer un gros fichier à des contrevenants, mais ce n'est pas seulement une perte de temps, c'est généralement contre-productif.
Il y a aussi des idées fausses fondamentales sur le fonctionnement du logiciel bot, c'est souvent assez simple et conçu pour une action rapide, donc les chances sont assez bonnes que dès qu'une limite de taille est atteinte, elle s'arrête.
Pour clarifier certaines idées fausses courantes sur les robots et leur fonctionnement, construisons-en une simple:
wget --spider -t 1 --read-timeout=5 -U "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0" [target url]
il s'agit du composant bot initial du générateur de base de données URL. Il ne fait que demander la HEAD, c'est-à-dire vérifier si le fichier existe. Cela va générer un code de réponse du serveur. Comme certaines personnes ici l'indiquent, une excellente stratégie consiste simplement à utiliser cette étape pour leur envoyer un 404, une fois que leur bot a été détecté. Le bot est un logiciel, pas une personne, donc il haussera simplement les épaules virtuelles et ira, très bien, la page n'existe pas, la prochaine URL. Il s'agit d'une très bonne stratégie, et la moins susceptible de déclencher des alertes de drapeau rouge. Cela indique également au serveur que c'est Firefox sur Windows 10, ou cela pourrait être autre chose qu'ils ont choisi d'y entrer, mais les fausses listes d'agents utilisateurs qui sont commutés ou tournés sont des caractéristiques courantes des mauvais robots décemment conçus.
Cependant, servir le 404 prend toujours quelques ressources de serveur, en particulier si votre page 404 est construite par un cms. Si vous utilisez simplement le serveur par défaut 404, c'est léger, mais laid pour les vrais utilisateurs qui pourraient également avoir frappé un 404.
Un 301 va simplement envoyer la demande ailleurs, quoi que vous fassiez, ne l'envoyez pas à un site Web anti spam/bot connu, ils le savent aussi bien ou mieux que vous. Envoyez-le quelque part qui n'existe pas.
Cependant, les bots ne respectent généralement pas les 301 avec une cohérence, parfois ils le font, parfois non, cela dépend de leur programmation.
Il y a donc des décisions sur la façon de gérer un bot au stade de l'araignée. Un 404 est une assez bonne solution, mais assurez-vous de tester réellement les vrais codes de réponse du serveur afin que vous sachiez que la réponse envoyée est un vrai 404, pas seulement une redirection vers une page 404, que la plupart des bots ne réaliseront pas était un échec. tester.
Maintenant, nous pouvons saisir le fichier:
wget -t 1 -Nc --read-timeout=5 -U "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0" [target url]
Notez à nouveau, nous le chronométrons à nouveau, ce qui met fin à l'idée de gros fichier, et en fait un gaspillage total de vos ressources de serveur, et l'envoi d'un faux agent utilisateur.
De toute évidence, les bots seront généralement écrits pour être beaucoup plus efficaces que l'envoi de demandes wget, ou curl, mais la facilité de contourner la plupart des idées ici devrait être évidente car j'écris mon bot en utilisant wget et des options intégrées, pour tout bot décent logiciel, ce sera bien sûr beaucoup plus sophistiqué, ou du moins, plus sophistiqué et plus facile à utiliser.
Tout auteur de bot qui se respecte prendra bien sûr le temps de consulter des fils de discussion comme celui-ci pour voir ce que les gens font actuellement, et d'ajouter simplement des protections d'araignée/téléchargeur pour gérer ces idées, c'est pourquoi vous ne les utilisez pas. Les auteurs de bots sont souvent des professionnels sérieux et compétents, dont le travail se concentre sur une activité de bot réussie, c'est leur travail, il vaut donc la peine de les respecter un peu pour éviter de les aggraver, ce qui ressemble à du geai devant un policier, c'est juste une provocation inutile.
Pour la phase de téléchargement, vous pouvez à nouveau utiliser le fait de la détection pour leur servir simplement de fausses pages sans contenu, ou quoi que ce soit qui aura très peu de charge sur le serveur. Quoi que vous fassiez, vous ne voulez pas utiliser beaucoup de ressources pour leur donner du faux contenu.
Il y a aussi beaucoup d'idées assez stupides qui flottent sur Internet, ce qui montre généralement plus le manque d'expérience des personnes qui les flottent, par exemple, en passant du temps à bloquer les adresses IP. La plupart des bots sont exécutés à partir d'adresses IP aléatoires, peuvent être sur un réseau de bots, peuvent être des centres de données, peuvent être des sites/IP temporaires AWS configurés puis supprimés, quoi qu'il en soit, il existe peu de façons moins productives de bloquer les bots qu'en bloquant les IP. Cela le deviendra encore plus lorsque IPv6 deviendra standard, avec sa capacité à effectuer des réaffectations aléatoires d'adresses IP publiques en fonction de temporisateurs ou de plannings ou de configurations de périphériques.
L'analyse des données IP peut être utile pour vous faire savoir à quoi vous avez affaire, par exemple, peut-être que la plupart viennent de Roumanie ou de Chine, et cela vous dit quelque chose, mais ils peuvent, et font, passer de l'un à l'autre, et d'un centre de données/botnet à un autre, donc l'analyse IP est plus un bon outil de backend pour vous permettre de voir quel type de problème de bot vous traitez.
C'est toujours une bonne stratégie de respecter l'intelligence des auteurs de logiciels de l'outil d'araignée (alias, les bots), et de ne pas supposer qu'ils sont stupides, ou de contrarier inutilement les utilisateurs de ce logiciel, faites simplement votre affaire, gérez le bot puis laissez il passe au site suivant sans enregistrer de problèmes sur le vôtre.
En outre, il est important de comprendre qu'il n'y a pas de robots en soi, ce qu'il y a généralement des robots à usage unique. Un `` bot '' en soi est un logiciel qui, dans presque tous les cas, demande automatiquement des URL dans sa base de données, il peut également dans le cadre de sa fonction créer cette base de données d'URL, ou il peut utiliser des bases de données disponibles dans le commerce. Certains robots analysent automatiquement l'intégralité des plages IP d'Internet, ils recherchent simplement des choses, d'autres sont ciblés et, comme pour les robots de recherche, suivent des liens. Notez que si vous n'avez pas bloqué toutes les pages/répertoires de type administrateur dans robots.txt, vous ne pouvez pas dire quel bot est correct et lequel ne l'est pas, c'est donc la première étape que vous prenez. Vous n'avez pas besoin de tout le chemin du fichier, juste le début de celui-ci qui le rend unique en tant que chemin, comme:/admin
- robots de recherche, légitimes
- seo bots, prétendant généralement légitimes. Le blocage des useragents dans le fichier robots.txt, puis l'analyse des fichiers journaux pour les demandes ultérieures peuvent vous montrer lesquels sont réels et quelles ordures.
- page de contact envoi automatique/remplissage des bots
- blog bots autopost
- inscription au forum/publication de bots
- les bots blackhat recherchant des URL d'application facilement exploitables, pour des outils souvent non sécurisés et/ou non mis à jour comme: wordpress, phpmyadmin, drupal, etc. Ceux-ci peuvent généralement être détectés dans les statistiques en voyant ce qui demande certaines URL qui ne sont généralement pas liées à.
- bots de disponibilité du site, voir # 2 pour savoir si ils sont réels. Fondamentalement, si vous ne vous êtes pas inscrit au service, c'est gris ou noir.
- robots expérimentaux, nouveaux moteurs de recherche, services Web, parfois corrects, parfois mal écrits, généralement pas malveillants mais méritent d'être examinés.
- l'indexation des robots, par exemple, pourrait être la vente d'index de sites à divers autres opérateurs de robots.
Ensuite, il y a des choses de type non bot comme les attaquants DDOS, qui utilisent généralement des PC zombie net, ou des serveurs piratés (voir # 6, c'est une des raisons pour lesquelles ils vont se lancer - pour trouver des sites exécutant des logiciels avec des problèmes de sécurité connus, ou zéro jour. Vous pouvez découvre en fait généralement lorsqu'un problème de sécurité apparaît dans le monde du blackhat en recherchant simplement des demandes pour certaines URL de logiciels courantes). Les serveurs piratés sont un produit haut de gamme dans le monde souterrain car ils ont tendance à avoir accès à beaucoup plus de bande passante et de cpu/ram qu'un appareil PC personnel ordinaire.
Ce n'est bien sûr pas une liste exhaustive, juste un échantillon de différents bots et le genre de chose qu'ils recherchent.
Notez que certains robots de recherche peuvent agir comme de mauvais robots s'ils sont mal configurés, encore une fois, vous pouvez donner des directives dans robots.txt et voir s'ils leur obéissent, s'ils ne le font pas, vous pouvez les bloquer, s'ils ne respectent pas les blocs , vous avez une variété de choix.
La raison pour laquelle il y a une telle activité de robots est que la plupart des utilisateurs ne sont tout simplement pas totalement équipés pour être un webmaster de leur site, ils sont essentiellement des canards et utilisent des logiciels mal écrits avec une mauvaise sécurité ou une mauvaise programmation qui ne parvient pas à protéger contre les vecteurs d'attaque courants comme l'injection sql, il y a donc un avantage/récompense significatif à l'activité de balayage de bots constant. Évidemment, vous pouvez atténuer un peu en mettant toujours à jour tous vos logiciels que vous utilisez ou, mieux encore, éliminer les outils inutiles et très peu sûrs comme phpmyadmin en premier lieu pour supprimer toute la surface d'attaque. Ou au moins protéger par mot de passe le dossier contenant ses fichiers.
J'ai eu un client qui a eu la terrible idée de gérer son propre IIS webserver, qui était à l'époque si radicalement précaire que, comme dans le cas OP, la seconde où je l'ai mis en ligne, j'ai vu bot instantané sonde pour les points d'accès courants IIS, même s'il n'y avait jamais eu de lien vers l'IP. J'ai dit à mon client le lendemain matin qu'il devait fermer le IIS instance et abandonner, car il ne serait jamais en mesure de maintenir des systèmes locaux sécurisés, heureusement pour moi, il l'a fait.
J'utilise grep, sed, awk pour la plupart de mes analyses, bien que je sois sûr qu'il doit y avoir des outils graphiques pour faire certaines choses, aucune idée, je n'en ai jamais eu besoin.
Vous n'examinez pas des dizaines de milliers d'accès dans vos fichiers journaux, en passant, vous recherchez les modèles, en utilisant des outils conçus pour ce travail (comme awk/sed/grep), puis vous voyez si vous pouvez détecter des modèles qui peut être résolu avec des réponses de programmation. Il existe également des outils de pare-feu qui peuvent être programmés pour bloquer les demandes qui correspondent à certaines règles, mais celles-ci sont plus difficiles à configurer correctement.
Project Honeypot le fait déjà. Vous devriez peut-être rejoindre Project Honeypot. Si vous voulez "leur donner du fil à retordre", la 404 le fait déjà. Il semble que vous soyez dans la même entreprise qu'eux si vous décidez de vous lancer dans des fistuffs numériques avec eux.
Comme déjà dit un nombre incalculable de fois - ils ont plus de ressources disponibles que vous, donc - c'est une guerre d'usure que vous perdrez, à mon avis.
J'ai un serveur basé sur l'IoT (Intel Galileo) qui reçoit presque zéro trafic légitime qui n'est pas moi. Il reçoit une bonne partie du trafic que vous mentionnez. Je collecte ces adresses IP et les ai signalées - en vain.
Vous vous faites du mal si vous essayez de contrarier l'attaquant. Ils ont des ressources infinies tandis que les vôtres sont limitées.
Si vous expédiez suffisamment de données pour que tous leurs réseaux de zombies épuisent les limites du FAI, je suppose que vous avez gagné. Mais ce n'est pas possible tant que vos ressources sont limitées.
Ce que vous pouvez éventuellement faire est de tarpit leurs collecteurs jusqu'à ce qu'ils soient à court de sockets utilisables, mais si vous deviez le faire à partir de votre serveur Web, il est probable que vous manquiez de mémoire car Apache HTTPd/nginx/vernis sont assez gourmands en mémoire. , en particulier Apache avec quelques modules chargés.
Ce que vous pourriez éventuellement faire est d'utiliser un pare-feu pour diriger le trafic vers quelque chose comme un proxy léger qui cible certaines URL mais toutes les autres vont vers le vrai serveur. Cela prendra beaucoup de travail pour un gain minimal.
BTW, comment avez-vous eu autant de trafic de robots? J'essaie depuis longtemps de faire en sorte que mes pots de miel soient consommés et ils n'obtiennent pratiquement aucun trafic! Un mec chanceux.