Comment arrêter l'attaque hack / DOS sur l'API Web
Mon site Web a subi une attaque par déni de service/piratage au cours de la dernière semaine. L'attaque frappe notre API Web avec des clés API invalides générées de manière aléatoire dans une boucle.
Je ne sais pas s'ils essaient de deviner une clé (mathématiquement impossible en tant que clés 64 bits) ou s'ils essaient d'attaquer DOS sur le serveur. L'attaque est distribuée, je ne peux donc pas interdire toute l'adresse IP, car elle se produit à partir de centaines de clients.
Je suppose que c'est une application Android par les IP, donc quelqu'un a des logiciels malveillants dans une application Android, et utilise toutes les installations pour attaquer mon serveur) .
Le serveur est Tomcat/Java, actuellement l'API Web ne répond que 400 aux clés non valides et met en cache les adresses IP qui ont effectué plusieurs tentatives de clé non valides, mais doit encore effectuer un traitement pour chaque mauvaise demande.
Des suggestions sur la façon d'arrêter l'attaque? Existe-t-il un moyen d'identifier l'application Android faisant la demande à partir de l'en-tête HTTP?
Prévention des attaques par force brute:
Il existe un large éventail d'outils et de stratégies disponibles pour vous aider à le faire, et celui à utiliser dépend entièrement de la mise en œuvre et des exigences de votre serveur.
Sans utiliser un pare-feu, un IDS ou d'autres outils de contrôle réseau, vous ne pouvez pas vraiment empêcher un DDOS de refuser le service à votre application. Vous pouvez cependant modifier votre application pour rendre une attaque par force brute beaucoup plus difficile.
La manière standard de procéder consiste à implémenter un verrouillage ou un retard progressif . Un verrouillage empêche une adresse IP de faire une demande de connexion pendant X minutes si elle ne parvient pas à se connecter N fois. Un délai progressif ajoute un délai de plus en plus long au traitement de chaque mauvaise demande de connexion.
Si vous utilisez le système d'authentification de Tomcat (c'est-à-dire que vous avez un <login-constraint> dans votre configuration webapp), vous devez utiliser Tomcat LockoutRealm , qui vous permet de placer facilement des adresses IP sur un verrouillage une fois qu'elles ont émis un certain nombre de requêtes incorrectes.
Si vous n'utilisez pas le système d'authentification de Tomcat, vous devrez publier plus d'informations sur ce que vous utilisez pour obtenir des informations plus spécifiques.
Enfin, vous pouvez simplement augmenter la longueur de vos clés API. 64 bits semble être un espace de clé insurmontablement énorme à rechercher, mais son poids insuffisant par rapport aux normes modernes. Un certain nombre de facteurs pourraient contribuer à le rendre beaucoup moins sûr que prévu:
- Un botnet (ou un autre grand réseau) pourrait faire des dizaines de milliers de tentatives par seconde, si vous n'avez aucune protection en place.
- Selon la façon dont vous générez vos clés et récupérez l'entropie, votre de facto espace de clés peut être beaucoup plus petit.
- À mesure que votre nombre de clés valides augmente, le nombre de clés qui doivent être tentées pour en trouver une (au moins en théorie) diminue fortement.
Augmenter la longueur de la clé API à 128 (ou 256 ou 512) ne coûtera pas cher, et vous augmenterez considérablement l'espace de recherche (et donc la difficulté) de toute attaque par force brute.
Atténuation des attaques DDOS:
Pour atténuer les attaques DDOS, cependant, vous devez faire un peu plus de travail. Les attaques DDOS sont difficiles à défendre, et c'est particulièrement difficile si vous ne contrôlez pas le réseau sur lequel votre serveur est.
Cela étant dit, vous pouvez faire quelques choses côté serveur:
- Installer et configurer un pare-feu d'application Web, comme mod_security , pour rejeter les connexions entrantes qui violent les règles que vous définissez.
- Mettre en place un système IDS, comme Snort , pour détecter quand une attaque DDOS se produit et prendre les premières mesures pour l'atténuer
- Voir @ Martin Muller post pour une autre excellente option, fail2ban
- Créer votre propre Tomcat
Valve, comme décrit ici , pour rejeter les demandes entrantes par leurUser-Agents(ou tout autre critère) comme dernière ligne de défense.
En fin de compte, cependant, vous ne pouvez pas faire grand-chose pour arrêter gratuitement une attaque DDOS. Un serveur n'a que tant de mémoire, autant de cycles CPU et autant de bande passante réseau; avec suffisamment de connexions entrantes, même le pare-feu le plus efficace ne vous empêchera pas de tomber en panne. Vous pourrez mieux résister aux attaques DDOS si vous investissez dans une connexion Internet à bande passante plus élevée et plus de serveurs, ou si vous déployez votre application sur Amazon Web Services , ou si vous avez acheté l'un des nombreux consommateurs et les produits d'atténuation DDOS d'entreprise ( @ SDude a d'excellentes recommandations dans son article ). Aucune de ces options n'est bon marché, rapide ou facile, mais c'est ce qui est disponible.
Conclusion:
Si vous comptez sur votre code d'application pour atténuer un DDOS, vous avez déjà perdu
S'il est assez grand, vous ne pouvez pas l'arrêter seul. Vous pouvez faire toute l'optimisation que vous souhaitez au niveau de l'application, mais vous continuerez à descendre. En plus de la sécurité au niveau de l'application pour la prévention (comme dans la réponse de la FSQ), vous devez utiliser des solutions éprouvées laissant le gros du travail aux professionnels (si vous êtes sérieux au sujet de votre entreprise). Mon conseil est:
- Inscrivez-vous à CloudFlare ou Incapsula . C'est au jour le jour pour eux.
- Envisagez d'utiliser passerelle AWS API comme deuxième étape pour vos demandes d'API. Vous apprécierez le filtrage, la limitation, la sécurité, la mise à l'échelle automatique et la HA pour votre API à l'échelle d'Amazon . Ensuite, vous pouvez transférer les demandes valides vers vos machines (dans ou en dehors d'Amazon)
Internet -> CloudFlare/Incapsula -> AWS API Gateway -> Votre serveur API
0,02
PS: Je pense que cette question appartient à Sec
La meilleure façon est d'empêcher l'accès à vos services entièrement pour les adresses IP qui ont échoué, disons 3 fois. Cela prendra la majeure partie de la charge de votre serveur car l'attaquant est bloqué avant que Tomcat ne doive même démarrer un thread pour cet utilisateur.
L'un des meilleurs outils pour y parvenir s'appelle fail2ban ( http://www.fail2ban.org ). Il est fourni sous forme de package dans toutes les principales distributions Linux.
Ce que vous devez faire est essentiellement de consigner les tentatives infructueuses dans un fichier et de créer un filtre personnalisé pour fail2ban. Darryn van Tonder a un bel exemple sur la façon d'écrire votre propre filtre sur son blog: https://darrynvt.wordpress.com/tag/custom-fail2ban-filters/
Si l'attaque D-DOS est grave, les vérifications au niveau de l'application ne fonctionnent pas du tout. Toute la bande passante sera consommée par les clients D-DOS et vos vérifications de niveau d'application ne seront pas déclenchées. Pratiquement, votre service Web ne fonctionne pas du tout.
Si vous devez protéger votre application contre les attaques D-DOS sévères, vous n'avez pas d'autre option que de compter sur des outils tiers en payant de l'argent. Un des outils de fournisseur de tuyaux propres (qui envoie uniquement du bon trafic) sur lequel je peux miser sur mon expérience passée: Neustar
Si l'attaque D-DOS est légère sur votre site Web, vous pouvez implémenter des vérifications au niveau de l'application. Par exemple, la configuration ci-dessous restreindra le nombre maximal de connexions à partir d'une seule IP, comme indiqué dans Restreindre les appels à partir d'une seule IP
<Directory /home/*/public_html> -- You can change this location
MaxConnPerIP 1
OnlyIPLimit audio/mpeg video
</Directory>
Pour plus d'informations sur les attaques D-DOS, visitez lien Wiki . Il fournit une liste d'outils préventifs et réactifs qui comprend: Pare-feu, commutateurs, routeurs, prévention basée sur IP, défenses basées sur D-DOS
et enfin
Nettoyer les tuyaux (Tout le trafic passe par un "centre de nettoyage" ou un "centre de lavage" via diverses méthodes telles que en tant que proxys, tunnels ou même circuits directs, qui sépare le "mauvais" trafic (DDoS et autres attaques Internet courantes) et envoie uniquement un bon trafic au-delà vers le serveur)
Vous pouvez trouver 12 distributeurs de tuyaux propres.
Voici quelques idées. Il existe en outre un certain nombre de stratégies, mais cela devrait vous aider à démarrer. Sachez également qu'Amazon est fréquemment consulté et que leurs systèmes ont tendance à avoir quelques heuristiques qui les renforcent (et donc vous) de ces attaques, en particulier si vous utilisez l'équilibrage de charge élastique, que vous devriez utiliser de toute façon.
- Utilisez un CDN - ils ont souvent des moyens de détecter et de se défendre contre les ddos. Akamai, la maîtrise ou les amazones possèdent un front de nuages.
- Utilisez iptables pour mettre sur liste noire les ips offensifs. Plus vous disposez d'outils à ce sujet, plus vous pouvez bloquer/débloquer rapidement
Utiliser des mécanismes de limitation pour empêcher un grand nombre de demandes
Refuser automatiquement les demandes très volumineuses (disons supérieures à 1 à 2 Mo; sauf si vous disposez d'un service de téléchargement de photos ou similaire) avant qu'elles n'atteignent votre application
Empêchez les défaillances en cascade en limitant le nombre total de connexions à d'autres composants de votre système; par exemple, ne laissez pas votre serveur de base de données devenir surchargé en lui ouvrant mille connexions.
Pour une attaque DOS ciblée et hautement distribuée, la seule solution pratique (autre que de fournir la capacité de l'absorber) consiste à profiler l'attaque, à identifier les 'tell' et à acheminer ce trafic vers un gestionnaire de ressources faibles.
Votre question en dit long - que la demande n'est pas valide, mais il y a sans doute trop de frais pour le déterminer. Que les demandes proviennent d'un groupe spécifique de réseaux et qu'elles se produisent vraisemblablement par rafales.
Dans vos commentaires, vous nous avez dit au moins un autre tell - l'agent utilisateur est nul.
Sans ajouter de composants supplémentaires, vous pouvez commencer par cibler la connexion - si une demande correspondant au profil arrive, allez-y et validez la clé, mais laissez votre code dormir pendant une seconde ou deux. Cela réduira le taux de demandes de ces clients à un faible coût.
Une autre solution consisterait à utiliser les échecs de journal correspondant au tell et à utiliser fail2ban pour reconfigurer votre pare-feu en temps réel pour supprimer tous les paquets de l'adresse source pendant un certain temps.
Non, il est peu probable que vous puissiez identifier l'application sans mettre la main sur un appareil affecté.