Question Est-il normal de faire des centaines de tentatives d'effraction par jour?


Je viens de vérifier mon serveur /var/log/auth.log et j'ai constaté que je reçois plus de 500 notifications de tentative de mot de passe / tentative de tentative d'échec par jour! Mon site est petit et son URL est obscure. Est-ce normal? Devrais-je prendre des mesures?


196
2018-03-08 11:26


origine


Jusqu'à ce que nous verrouillions tous les ports externes inutiles, je me souviens que non seulement nous avions eu beaucoup de tentatives de piratage, mais qu'un jour, c'était tellement grave que nous étions piratés de deux pays différents - en même temps! Alors oui, des centaines de tentatives d'effraction sont parfaitement normales. - Django Reinhardt
Nous avons des serveurs qui subissent une nouvelle "séquence" d'attaque toutes les 16 secondes. Une séquence unique est généralement un lot d'environ 100 tentatives sur différents ports. Juste pour le plaisir un jour, j'ai allumé un serveur non corrigé en dehors de notre pare-feu; il a fallu moins de 10 minutes à partir du moment où il a été allumé pour obtenir le mot de passe. Le point est l'Internet est vraiment une jungle; essayez de ne pas vous faire manger. - NotMe
Je vois que j'ai posté ma question sur le mauvais site: superuser.com/questions/200896/… - Justin C
Bien que je sois d’accord avec d’autres, c’est normal sur les ports communs requis (80, 443). J’ai pratiquement éliminé ces tentatives contre mon port SSH en changeant simplement le port par défaut de 22 en quelque chose d’obscur tel que 6022 par exemple. Rien que cela, à lui seul, a presque éliminé 99% de ce type d’attaque. - Kilo
Si vous envisagez de modifier votre port SSH, des raisons de sécurité vous poussent à le maintenir sous le port 1024 (seul le compte root peut ouvrir les ports <1024 afin de vous protéger des autres utilisateurs qui détournent SSH). - Brendan Long


Réponses:


Malheureusement, sur Internet, c'est tout à fait normal. Des hordes de botnets tentent de se connecter à chaque serveur trouvé sur des réseaux IP entiers. Ils utilisent généralement des attaques par dictionnaire simples sur des comptes connus (tels que les comptes root ou certains comptes d’applications).

Les cibles d'attaque ne sont pas trouvées via des entrées Google ou DNS, mais les attaquants essaient simplement toutes les adresses IP d'un sous-réseau donné (par exemple, des sociétés d'hébergement de serveurs racine connues). Donc, peu importe que votre URL (d'où l'entrée DNS) soit plutôt obscure.

C'est pourquoi il est si important de:

  • interdire la connexion root dans SSH (comment)
  • utilisez des mots de passe forts partout (également dans vos applications Web)
  • pour SSH, utilisez si possible l’authentification par clé publique et désactivez complètement l’authentification par mot de passe (comment)

De plus, vous pouvez installer fail2ban qui analysera l’authlog et s’il trouve un certain nombre de tentatives de connexion infructueuses à partir d’une adresse IP, il ajoutera cette adresse IP à /etc/hosts.deny ou iptables / netfilter afin de verrouiller l'attaquant pendant quelques minutes.

Outre les attaques SSH, il est également de plus en plus courant d’analyser votre serveur Web à la recherche d’applications Web vulnérables (certaines applications de blogage, les CMS, phpmyadmin, etc.). Veillez donc également à ce que ces informations soient à jour et correctement configurées!


207
2018-03-08 11:35



Des applications telles que fail2ban peuvent beaucoup aider à empêcher "temporairement" ces robots de frapper votre serveur à des heures bêtes le matin :-) J'ai le mien mis en place pour interdire 3 tentatives incorrectes pendant 24 heures. - emtunc
Et déplacez le port de ssh de 22 à 222. Cela fonctionne assez bien. - Tom O'Connor
+1, authentification par clé publique uniquement :) - 0xC0000022L
@STATUS_ACCESS_DENIED: les actions entreprises par fail2ban ne sont que des listes de commandes shell à exécuter. Il est donc très flexible et facile de faire fonctionner correctement toute configuration personnalisée. La meilleure référence est de le télécharger et de regarder action.d/iptables.conf. - mattdm
Bloquer de tels attaquants est une perte de temps. Si vous désactivez la connexion root, il y a de fortes chances que personne ne devine jamais votre nom de connexion correct, et encore moins votre mot de passe. SSH lui-même limite déjà les demandes de mot de passe, donc même s'ils connaissent votre nom d'utilisateur (les robots aléatoires ne le sauront pas), si vous avez un mot de passe correct, ils ne le devineront jamais. - Brendan Long


Quelques 100, c'est très bien ... Le mois dernier, j'ai découvert qu'un de mes serveurs avait échoué à 40 000 tentatives. J'ai eu la peine de les comploter: Carte

Une fois que j'ai changé le port ssh et mis en œuvre Port Knocking, le nombre est tombé à 0 :-)


58
2018-03-08 11:36



Belle carte. J'aimerais savoir comment faire cela! - jftuga
@ jftuga J'ai d'abord toutes les adresses IP des journaux. grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(supprimez le | uniq à la fin si vous voulez autoriser les doublons). Vous pouvez ensuite les placer dans un fichier CSV et le télécharger sur zeemaps.com. J'ai vu de meilleures cartes que les miennes, où ils utiliseraient le décompte pour colorer la carte (de vert en rouge pour le nombre de tentatives par comté) mais je n'ai pas encore pensé à cela. - Bart De Vos
Que voulez-vous dire par 'mise en œuvre de port knocking'? Existe-t-il une application que je peux installer via apt-get pour le faire? Le nombre qui tombe à 0 sonne bien
La sécurité à travers l'obscurité est mal accueillie. C'est parfaitement bien tant que c'est partie de la stratégie globale plutôt que de la stratégie entière. Après tout, quoi d'autre est un mot de passe autre qu'une chaîne obscure? - Joel Coel
@ Joel Coel, c'est un secret chaîne, par opposition à la plupart des problèmes de sécurité liés à l'obscurité - processus obscur, mais pas nécessairement secret. - tobyodavies


Pour ma part, j'utilise un "tarpit" en plus de n'autoriser que l'authentification par clé publique et d'interdire les connexions root.

Dans netfilter Il y a un recent module, que vous pouvez utiliser avec (INPUT chaîne):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Cela signifie que chaque tentative de connexion au port 22 est répertoriée par le recent module avec IP et quelques autres trucs sous le nom de "tarpit" (si vous êtes curieux, regardez /proc/net/xt_recent/tarpit). De toute évidence, vous pouvez utiliser d'autres noms.

Pour lister ou supprimer des IP, utilisez:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Ce taux limite les tentatives à 5 en 300 secondes. Veuillez noter que cette limite ne gêne pas les utilisateurs disposant d'une connexion existante, car ils disposent déjà d'une connexion établie et sont autorisés à en créer davantage (même au-delà de la limite de débit).

Ajustez les règles à votre convenance, mais assurez-vous qu’elles soient ajoutées dans cet ordre (c’est-à-dire que lorsqu’elles sont ajoutées, utilisez-les dans cet ordre, puis insérez-les dans l’ordre inverse).

Cela réduit énormément le bruit. Il fournit également une sécurité réelle (contre la force brutale) contrairement à la sécurité perçue de la modification du port. Cependant, je recommanderais toujours de changer le port si cela est faisable dans votre environnement. Cela réduira également beaucoup le niveau de bruit ...

Vous pouvez toujours combiner cela avec fail2ban, bien que je me sente parfaitement bien sans lui et uniquement les règles ci-dessus.

MODIFIER:

Il est possible de le verrouiller pour pouvoir ajouter quelque chose comme ce qui suit, qui vous permet de supprimer votre interdiction en frappant sur un port particulier:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

29
2018-03-08 14:24



J'utilise cela et je parviens à me bloquer de temps en temps, alors vous souhaitez configurer un autre port sur lequel vous pouvez "frapper" pour supprimer votre interdiction. - benlumley
@benlumley: bon point. Le portage à la porte peut également être utile pour changer le port par défaut - ou même les deux en combinaison ... - 0xC0000022L
@benlumley: vu votre commentaire (maintenant supprimé par Sam). Cela ne me dérange absolument pas si la réponse est modifiée / améliorée;) - 0xC0000022L


Vous pourriez implémenter fail2ban, ou des méthodes similaires telles que le verrouillage de SSH sur votre IP. Malheureusement, les bots tentent de forcer brutalement l'accès tout le temps, alors c'est tout à fait normal, vous devez vous assurer que vous avez un bon mot de passe.


15
2018-03-08 11:32



Si vous utilisez SSH, envisagez l'authentification par clé publique. C'est un peu plus sécurisé que l'authentification par mot de passe. - Piskvor


Oui. C'est tout à fait normal de nos jours.

Veuillez utiliser, si possible, uniquement l'authentification par clé publique à des fins administratives. Générez une clé privée sur votre poste de travail:

$ ssh-keygen -t dsa

Copypastez le contenu de ~ / .ssh / id_dsa.pub à vous serveurs ~ / .ssh / registered_keys (et /root/.ssh/authorized_keys, si vous avez besoin d’un identifiant root direct).

Configurez vos serveurs / etc / ssh / sshd_config accepter uniquement l'authentification par clé publique:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Si vous avez trop de serveurs, vous pouvez utiliser Fantoche pour exécuter des clés publiques et des configurations à eux.

Examiner Denyhosts et fail2ban bloquer les tentatives de connexion SSH répétées et voir Grognement si vous avez besoin du système IDS / IPS complet.


12
2018-03-09 23:32



Je ne recommanderais pas l'utilisation de l'authentification par clé publique dans SSH pour un accès shell à votre serveur. Si votre poste de travail est compromis ou, pire encore, volé, quelqu'un dispose désormais d'un accès ouvert à vos serveurs sans qu'un mot de passe ne soit nécessaire. L'authentification par clé publique est plus adaptée aux situations dans lesquelles vous avez besoin de quelque chose comme un script ou un programme pour pouvoir accéder SSH à un autre système sans avoir besoin d'un mot de passe. Vous n'avez donc pas à insérer de mot de passe en texte brut dans votre script / programme. - Registered User
@Deleted Account: Vous pouvez définir une phrase secrète pour la clé privée SSH. - Phil Cohen
Le commentaire "Utilisateur enregistré" est erroné. Juste pour clarifier: toujours définir un bon mot de passe sur votre clé privée, et ne stockez pas la clé privée sur aucun serveur. Conservez la clé privée sur votre propre poste de travail. Une fois que vous avez ajouté la clé à un programme ssh-agent et que vous avez entré votre mot de passe, vous pouvez vous connecter à tous les systèmes sur lesquels la clé publique est installée, sans avoir à ressaisir votre mot de passe. Activez le transfert d’agent dans votre client ssh pour pouvoir vous connecter d’un serveur à l’autre. Obtenir votre clé privée volée est mauvais, mais avec un mot de passe décent, ce n'est pas aussi grave qu'un mot de passe volé. - Martijn Heemels
D'accord, ne pensez même pas à stocker les clés privées de l'administrateur sans les chiffrer. - yarek


utilisation http://denyhosts.sourceforge.net/

et oui, vous devez utiliser l'authentification par clé publique et désactiver l'authentification par mot de passe.


8
2018-03-09 09:37



La désactivation de l'authentification par mot de passe n'est pas toujours une solution viable. - Publiccert


Les tentatives sont mécanisées, donc les chiffres semblent corrects (oui, ils sont élevés par rapport à certains sites et faibles par rapport à d'autres). Vous devez normalement suivre les étapes suivantes: Vous considérez vos sites comme des cibles d’attaque chaque jour, même si vous ne détectez pas d’attaque; ne pas détecter une attaque, ne signifie pas qu'elle n'existe pas.


6
2018-03-08 11:33





Je dirais que seulement 500, c'est un peu bas.

Chez un ancien employeur, l’un des chercheurs en sécurité informatique a qualifié le "flux constant de tentatives d’intrusion" l'équivalent Internet de bruit cosmique". Il a décrit cela comme un flux normal et continu de trafic malveillant cherchant des systèmes sur Internet et exploitant automatiquement les scripts pour tenter de le pirater. Les réseaux de robots et autres systèmes malveillants analysent et analysent en permanence les systèmes vulnérables un peu comme SETI.


6
2018-03-08 17:06





Oui,

c'est courant, mais cela ne signifie pas que vous ne devriez pas combattre le bon combat. Voici quelques étapes sur la façon de rendre votre serveur plus sécurisé.

Eviter les adresses IP associées au DNS

Vous pouvez réduire considérablement ce nombre dans les environnements partagés ou en colocation en désactivant l'accès SSH sur les adresses IP associées aux noms de domaine. Les adresses IP hors domaine non répertoriées recevront moins de ce type de trafic. Achetez donc une adresse IP non répertoriée et utilisez-la uniquement pour l'accès SSH.

Utiliser un VPN pour tous les accès SSH

Si vous êtes dans un environnement dans lequel vous pouvez implémenter IPsec/ VPN vers un réseau privé dans votre environnement de serveur, c’est l’idéal. Désactivez tous les accès Internet SSH, assurez-vous de disposer d’une solution d’éclairage intégrée. Configurez votre VPN et n'autorisez que l'accès SSH à partir de votre VPN.

Implémenter des règles d'adresse IP pour l'accès SSH

Si le VLAN n'est pas une option, configurez votre routeur ou les règles de pare-feu pour autoriser uniquement les connexions SSH à partir d'une plage d'adresses IP connue.

Si vous suivez ces étapes, vous dormirez beaucoup plus facilement la nuit en sachant que quelqu'un devra compromettre le réseau de votre hébergeur pour accéder au serveur via SSH.


6
2018-03-08 21:56





Assez normal de voir des centaines de connexions SSH échouées.

Si vous avez l'option, je change simplement mon port SSH en quelque chose de non standard. Cela ne rend pas nécessairement votre serveur plus sécurisé, mais il nettoie certainement les journaux (et vous permet de voir quiconque tente délibérément de s’immiscer!)


5
2018-03-08 11:43





Outre l’utilisation d’un mécanisme de verrouillage automatique tel que fail2ban, vous disposez d’une option supplémentaire: contactez l’adresse d’abus du fournisseur de services Internet de l’attaquant. Cela peut sembler complètement inutile, mais dans le cas du script-kiddie, leur fournisseur de services Internet est plus que disposé à agir contre eux.

Pour trouver l'adresse de l'abus, commencez par arin.net et recherchez l'adresse IP à l'aide de whois. Vous serez peut-être redirigé vers un autre registre régional, mais vous pourrez éventuellement trouver le fournisseur d'accès Internet responsable du bloc IP contenant l'adresse. Recherchez l'adresse d'abus @ ou envoyez simplement un courrier au contact technique.

Envoyez-leur un message poli avec les entrées de fichier journal appropriées (assurez-vous de supprimer toute information privée) et demandez-leur de prendre des mesures contre l'hôte en cause.


5
2018-03-08 18:20



Nous avions l'habitude de faire cela. Cependant, le temps passé par rapport aux avantages reçus était si minime que cela importait peu. - NotMe
Une variante de cette tactique plus efficace, mais beaucoup plus risquée, consiste à signaler le fournisseur de services Internet au nœud intermédiaire. Mais toi DOIT avoir des preuves solides de votre rapport. Cela a posé de graves problèmes à tout un fournisseur d'accès, car ils ignoraient leurs rapports d'abus. - staticsan
Une fois que j'ai fait cela, le message d'abus est parvenu au pirate informatique au lieu d'un responsable des serveurs. Depuis lors, je ne me dérange plus, juste trop de problèmes. - wump
Cela ne va vraiment pas aider dans la plupart des cas et peut prendre beaucoup de temps - RichVel