Comment limiter l'impact des sondes ssh?

Mon serveur Web est constamment attaqué par diverses adresses IP. Ils essaient cinq mots de passe, puis changent l'adresse IP.

J'ai effectué divers verrouillages comme l'utilisation de clés ssh et ne pas autoriser les mots de passe, ni autoriser la connexion root à distance.

Puis-je faire quelque chose pour me débarrasser de ces tentatives d'attaque? À défaut, y a-t-il des moyens de défense spécifiques à mettre en place?

C'est en effet une réalité de la vie. Vous pouvez installer des outils pour filtrer les hôtes qui vous attaquent après quelques tentatives infructueuses.

DenyHosts analyse vos fichiers journaux et ajoute automatiquement des attaquants à votre /etc/hosts.denyfichier.

Consultez la documentation sur la façon de le configurer selon vos besoins.

Mise à jour : quelques points importants suggérés dans les commentaires

• assurez-vous de configurer correctement les outils en tant que DenyHosts car vous pouvez vous verrouiller (par exemple, vous pouvez configurer une machine ou un réseau qui n'est jamais filtré)

• DenyHosts n'augmente pas la sécurité de votre système: il filtre uniquement les attaques au niveau IP (cela peut réduire la charge sur les petites machines et réduire la taille des fichiers journaux mais rien de plus)

J'ai suivi ces instructions pour ajouter un délai de 7 secondes à chaque tentative de connexion SSH avec un mot de passe incorrect. J'ai fait de mon sshd un "tarpit" pour les scanners à force brute.

Je devrais également ajouter que j'ai mon journal tarsh sshd modifié les mots de passe échoués. Cela peut ne pas être entièrement éthique, car cela donne à l'utilisateur root un aperçu de ce que les utilisateurs réguliers saisissent mal comme leurs propres mots de passe, mais comme je suis le seul "vrai" utilisateur, je pense que c'est OK.

Je ne l'ai pas exécuté sur un port non standard, car l'aspect "tarpit" ne ferait perdre de temps à personne.

Si seul un petit nombre de personnes ont besoin de SSH sur le système, envisagez de déplacer SSH vers un port non standard (par exemple 6422, 8080, etc.). Cela seul réduira considérablement le nombre de tentatives de connexion (et vous protégera éventuellement de Ver basé sur l'exploit SSH, par exemple).

Approuve la réponse de @ Matteo; ce que vous voyez, ce sont essentiellement des milliers de systèmes zombies exécutant une attaque par force brute distribuée sur votre serveur car il y a un site Web en cours d'exécution, ce qui signifie qu'il peut y avoir des utilisateurs qui pourraient avoir un compte de connexion qui pourrait être deviné effort minimal de la part du script kiddie - il a un programme qui ordonne aux milliers de zombies de faire des tentatives de bruteforce sur quelques centaines d'hôtes de sites Web à la fois et juste de compiler une liste des retours réussis.

De même, vous pouvez parfois voir beaucoup de permations de "http://your.web.host/phpmyadmin/" dans vos /var/log/apache2/access.logfichiers; ce sont des analyses automatisées pour les moyens les plus courants de configurer PHPMyAdmin, et tenteront un certain nombre d'exploits connus si l'un d'eux est trouvé (c'est d'ailleurs la raison pour laquelle j'ai commencé à dire aux clients d'utiliser le site PMA que j'ai personnellement créé et garder à jour plutôt que d'installer leur propre version et oublier de la mettre à jour, mais maintenant nous sommes sur une tangente).

Mis à part l'envoi de la commande d'origine, cela ne lui coûte même pas de temps ou de bande passante; c'est du feu et oublie.

Un autre logiciel très utile pour des situations comme celle-ci est fail2ban , qui utilise iptables pour bloquer les tentatives de connexion après plusieurs ouvertures de session clairement fausses ou d'autres tentatives d'exploitation.

Essayez de configurer Fail2ban . Il fournit un moyen très flexible de rechercher les tentatives ayant échoué et il dispose de modèles pour SSH, HTTP et les services communs.

Fail2ban mettra à jour iptables en fonction de vos actions .. Je l'adore.

Vous pouvez utiliser IPTABLES pour arrêter le trafic sans exécuter un démon comme Fail2Ban ou DenyHosts.

#  Allows SSH connections (only 4 attempts by an IP every 3 minutes, drop the rest to prevent SSH attacks)
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

Si vous pouvez le gérer, je trouve que la meilleure façon de gérer des trucs comme celui-ci est d'utiliser un VPN. De cette façon, la seule chose qu'ils peuvent cibler est le VPN. Il ne devrait pas y avoir de services ouverts sur le monde dans son ensemble, à l'exception de ceux qui sont nécessaires à "tout le monde" pour accéder, comme votre serveur Web. Tout le reste doit être bloqué par le pare-feu. Maintenant, la seule chose que vous devez vraiment vous soucier de la sécurité est votre VPN. Si vous le pouvez, obtenez une IP statique pour les ordinateurs à partir desquels vous gérez vos serveurs et verrouillez votre VPN à cette adresse IP spécifique. C'est vraiment le seul moyen d'empêcher les gens d'essayer de forcer les mots de passe par force brute.

Sshguard fonctionne très bien. Je l'utilise avec iptables.