Question:
Quelqu'un essaie de forcer brutalement (?) Mon serveur de messagerie privé ... très ... lentement ... et avec des adresses IP changeantes
Heinzi
2017-11-27 13:22:53 UTC
view on stackexchange narkive permalink

Cela dure depuis environ 1 à 2 jours maintenant:

  heinzi @ guybrush: ~ $ less /var/log/mail.log | grep '^ 27 novembre. * suffixe / soumission. * avertissement' [...] 27 novembre 03:36:16 guybrush postfix / soumission / smtpd [7523]: avertissement: le nom d'hôte bd676a3d.virtua.com.br ne résout pas à adresse 189.103.106.61Nov 27 03:36:22 guybrush postfix / soumission / smtpd [7523]: avertissement: inconnu [189.103.106.61]: échec de l'authentification SASL PLAIN: 27 novembre 03:36:28 guybrush postfix / soumission / smtpd [7523 ]: avertissement: inconnu [189.103.106.61]: échec de l'authentification SASL LOGIN: VXNlcm5hbWU6Nov 27 04:08:58 guybrush postfix / submit / smtpd [8714]: avertissement: le nom d'hôte b3d2f64f.virtua.com.br ne se résout pas à l'adresse 179.210. 246.79Nov 27 04:09:03 guybrush postfix / submit / smtpd [8714]: avertissement: inconnu [179.210.246.79]: échec de l'authentification SASL PLAIN: 27 novembre 04:09:09 guybrush postfix / soumission / smtpd [8714]: avertissement : inconnu [179.210.246.79]: l'authentification SASL LOGIN a échoué: VXNlcm5hbWU6Nov 27 05:20:11 guybrush postfix / submit / smtpd [10175]: avertissement: hostname b3d0600e.virtua.com.br ne résout pas l'adresse 179.208.96.14Nov 2705:20:16 guybrush postfix / soumission / smtpd [10175]: avertissement: inconnu [179.208.96.14]: échec de l'authentification SASL PLAIN: 27 novembre 05:20:22 guybrush postfix / soumission / smtpd [10175]: avertissement: inconnu [ 179.208.96.14]: l'authentification SASL LOGIN a échoué: VXNlcm5hbWU6Nov 27 06:42:43 guybrush postfix / submit / smtpd [12927]: avertissement: le nom d'hôte b18d3903.virtua.com.br ne se résout pas à l'adresse 177.141.57.3 Nov 27 06:42 : 48 guybrush postfix / submit / smtpd [12927]: avertissement: inconnu [177.141.57.3]: échec de l'authentification SASL PLAIN: 27 novembre 06:42:54 guybrush postfix / soumission / smtpd [12927]: avertissement: inconnu [177.141.57.3 ]: L'authentification SASL LOGIN a échoué: VXNlcm5hbWU6Nov 27 08:01:08 guybrush postfix / submit / smtpd [14161]: avertissement: le nom d'hôte b3db68ad.virtua.com.br ne résout pas l'adresse 179.219.104.173
27 novembre 08:01:13 guybrush postfix / soumission / smtpd [14161]: avertissement: inconnu [179.219.104.173]: échec de l'authentification SASL PLAIN: 27 novembre 08:01:19 guybrush postfix / soumission / smtpd [14161]: avertissement: inconnu [179.219.104.173]: l'authentification SASL LOGIN a échoué: VXNlcm5hbWU6  

Une seule tentative de connexion a échoué toutes les 1 à 2 heures, toujours à partir du même domaine, mais à chaque fois depuis une adresse IP différente adresse. Ainsi, cela ne déclenchera pas fail2ban et les messages de vérification du journal commencent à m'ennuyer. :-)

Mes questions:

  1. Quel est l'intérêt de ce genre "d'attaque"? Le taux est beaucoup trop lent pour effectuer un forçage brutal efficace, et je doute vraiment que quelqu'un cible spécifiquement mon petit serveur personnel.

  2. Y a-t-il quelque chose que je puisse faire contre cela sauf interdire la plage IP complète de ce fournisseur? Je pourrais simplement arrêter de m'inquiéter et ajouter ces messages à ma configuration d'ignorer le contrôle de journal (puisque mes mots de passe sont forts), mais cela pourrait me faire manquer des attaques plus graves.

Que votre serveur personnel soit minuscule ou non n'a pas d'importance.De toute façon, le botnet peut devenir utile.Une vitesse lente pourrait être simplement pour éviter de déclencher les mécanismes de détection en place (bien que ce ne soit que mon avis, je ne ferai aucune déclaration dure).Quant à l'interdiction de la gamme de fournisseurs, cela n'a pas d'importance non plus.Botnet a beaucoup d'ips disponibles, et ils sont potentiellement spoofables.
Est-ce le même compte en cours d'essai ou des comptes différents?
@schroeder: Bonne question.Je viens d'activer la journalisation des noms d'utilisateur des tentatives infructueuses et je ferai un rapport.
@Heinzi cela semble être une information cruciale.Si c'est le même compte et pas celui que vous avez, alors quelqu'un a mal configuré son serveur
@schroeder: Les noms d'utilisateurs essayés au cours des deux dernières heures sont «info @ » (1 essai), «admin @ » (1 essai) et «AB » (2 essais).On dirait que la force brute classique me devine.
J'ai déjà vu ça sur mes pots de miel.C'est un "rayonnement de fond".Les tentatives de force brute s'étalent sur un champ très large.La réponse de l'invité est probablement la bonne.
Solution simple: [Fail2Ban] (https://www.fail2ban.org/wiki/index.php/Main_Page) avec une prison personnalisée et maxretry défini sur 1. C'est ce que j'utilise et cela fonctionne bien.
Fait intéressant, ils semblent tous provenir d'un centre de données appartenant à Virtua au Brésil.Ce qui me fait me demander, qui paierait pour les serveurs s'ils pouvaient aussi utiliser des bots qui ne coûtent pas d'argent et qui ne sont pas liés à leur carte de crédit?
@Damon Virtua comme centre de données?De quoi parlez-vous?Virtua est l'ancien nom de http://www.netcombo.com.br/, un fournisseur résidentiel de télévision par câble / Internet.Vous pouvez même voir que la première partie des adresses semble être des MAC des clients.
Cela semble être une recherche de mots de passe par défaut, car le LOGIN fourni est un nom d'utilisateur de `Username` et un mot de passe de la chaîne vide.
Si vous êtes assez petit, vous pouvez ajouter à la liste blanche tous les réseaux IP à partir desquels vos appareils peuvent consulter les e-mails.Ce serait donc n'importe quel bloc IP attribué à votre cellco, et les plages IP des sites distants où vous pourriez obtenir le sans fil (amis, lieu de travail, etc.) ou simplement rester sur les données cellulaires.Pas vraiment conseillé pour tout ce qui est plus grand qu'un environnement domestique.
Un autre moyen d'atténuation est d'interdire les connexions IPv4 et de n'autoriser que les vérifications de courrier via IPv6, en supposant que vous les ayez aux deux extrémités.Les script kiddies ont tendance à se concentrer uniquement sur les connexions IPv4.
@Heinzi Si l'attaque provient d'un hôte connecté à Virtua, c'est la raison pour laquelle vous voyez des adresses IP en constante évolution.Cette connexion est connue pour changer soudainement d'IP sans raison en cours d'utilisation et peut être source de maux de tête pour certaines applications.Il s'agit d'une connexion domestique, remarquez, la machine attaquante fait probablement partie d'un botnet d'un utilisateur domestique essayant de faire des "choses amusantes"
Google pour «fail2ban».
@peterh: Veuillez relire la question, fail2ban est déjà mentionné.
IIUC correctement, les attaques elles-mêmes n'ont à peu près aucune chance de réussir, mais le principal problème est qu'elles remplissent le logcheck et pourraient éventuellement masquer d'autres attaques plus graves.Droite?
@smci: Exactement.Je peux simplement ajouter ces messages à ma configuration ignorer logcheck, mais je craignais de manquer des attaques plus graves à ce moment-là.Cependant, après avoir lu les réponses, il semble qu'il n'y ait pas de réponse facile à ce problème et je devrais simplement filtrer ces messages et cesser de m'inquiéter.
@Heinzi: ok mais mon point est que vous voulez éditer et reformuler la question par ma paraphrase ci-dessus.
@smci: Terminé.J'ai essayé de faire le changement le plus petit possible, pour éviter d'invalider les réponses existantes.
Cinq réponses:
guest
2017-11-27 13:27:31 UTC
view on stackexchange narkive permalink

Quel est l'intérêt de ce genre "d'attaque"? Le taux est beaucoup trop lent pour effectuer un forçage brutal efficace, et je doute vraiment que quelqu'un cible spécifiquement mon petit serveur personnel.

Le taux est lent, ou le total la quantité de données envoyées est petite? Vous voyez peut-être très rarement des connexions, mais comment savez-vous que les robots effectuant le forçage brutal ne saturent pas constamment leurs liaisons montantes, et votre site est l'un des nombreux sites attaqués? Il n'y a aucun avantage pour un attaquant à passer peu de temps à s'attaquer à un site à la fois (et à déclencher fail2ban), par rapport à l'attaque d'un grand nombre de serveurs à la fois, où chaque serveur ne voit que des connexions peu fréquentes. Les deux peuvent avoir le même taux de tentatives d'authentification sortantes par seconde.

Y a-t-il quelque chose que je puisse faire contre cela, sauf interdire la plage d'adresses IP complète de ce fournisseur (ou ignorer les messages, car mes mots de passe sont forts) ?

Peu probable. Il y a de fortes chances que ceux-ci proviennent d'un botnet ou d'un cluster de VPS à faible coût. Il n'est pas possible de déterminer quelles autres plages d'adresses IP peuvent être utilisées simplement en voyant quelques-unes d'entre elles. S'ils ne sont pas sur le même sous-réseau, ils ne peuvent pas être prédits. Vous pouvez ignorer ces connexions en toute sécurité. Ce n’est rien de plus que le bruit de fond d’Internet.

à 1 essai / heure, il faut environ 4 jours pour essayer les 100 mots de passe les plus courants sur un compte sans rien déclencher ... Je peux voir un énorme retour sur ce genre d'attaque pour quelqu'un qui construit un botnet ...
Peut-être changer le mot de passe administrateur pour celui qu'ils ont déjà essayé.Cela les fera trébucher.
@Caterpillaraoz Vous suggérez donc de ne pas exécuter de serveurs sécurisés contre l'accès à distance par un mot de passe choisi parmi une liste de 100 mots de passe les plus courants?
@Caterpillaraoz Vous ne savez pas combien de serveurs ils touchent.En 4 jours, s'ils envoient les 100 mots de passe les plus importants à 30 000 serveurs de messagerie, ils ont très probablement pu accéder à certains d'entre eux.
Je suggère que nous utilisions tous "baseball!"comme mot de passe: P @Qwertie c'est ce que je veux dire, "aller lentement" sur des milliers de serveurs et frapper beaucoup de nombreux comptes, par curiosité, j'ai essayé de SSH en tant qu'administrateur par défaut dans F **** G de mon entrepriseBASE DE DONNÉES et je suis entré ...
Les mots de passe ne seraient pas couramment utilisés s'ils n'étaient pas bons, non?
@StigHemmer C'est pourquoi les entreprises ont pour la plupart normalisé "Password123!"
@James_pic: Je ne devinerais jamais Password123 !, J'abandonne généralement après Admin, admin et root et demande à quelqu'un qui connaît réellement le mot de passe
Une chose qui pourrait extraire une petite mesure de la douleur est si le temps de réponse pour une tentative de mot de passe échouée contre votre hôte a été augmenté.
@Christian Grâce à Apple, root est une hypothèse assez fantastique sur de nombreux Mac de nos jours.
@Daniel Comme nom d'utilisateur
David Rouse
2017-11-27 19:32:18 UTC
view on stackexchange narkive permalink

Question 1 - À moins qu'il s'agisse d'une mauvaise configuration (comme mentionné dans les commentaires), d'après mon expérience, il semble qu'il s'agisse d'attaques automatisées recherchant des comptes à partir desquels des courriels commerciaux non sollicités (ou des tentatives de phishing) peuvent être envoyés.

Question 2 - Si la plage d'adresses IP d'où proviennent vos identifiants légitimes est suffisamment petite et connaissable, il peut être plus facile de tout bloquer à l'exception de ces plages.

J'administre un e-mail de petite entreprise serveur, ce type de sondage se produit presque continuellement pour nous.

Tiberiu-Ionuț Stan
2017-11-28 03:51:13 UTC
view on stackexchange narkive permalink

1 tentative toutes les 1 à 2 heures? Ce n'est pas une force brute.

Peut-être que c'est l'iPhone de quelqu'un avec un mot de passe expiré. Probablement le vôtre! Ou, si vous réutilisez les adresses IP d'une société d'hébergement, l'ancien "propriétaire" pourrait encore avoir un client de messagerie quelque part, configuré pour accéder à [maintenant] vos adresses IP.

Si vous avez les adresses IP, le moins que vous puissiez faire est de les retracer.

VXNlcm5hbWU6 est apparemment un encodage base64 de "Username", qui apparemment Postfix envoie comme une invite encodée.Quelque chose en rapport avec "AUTH LOGIN" (beaucoup d'appels Google)
@infixed Oui, cette chaîne est une partie standard du mécanisme AUTH LOGIN.Dans AUTH LOGIN, tout est encodé en base64 dans les deux sens.Sous cet encodage, l'échange est simple: (1) le serveur envoie "Username" (2) le client envoie le nom d'utilisateur (3) le serveur envoie "Password" (4) le client envoie le mot de passe.(Bien que je me demande si la présence de la chaîne dans le fichier journal peut indiquer que le client envoie réellement "Username" comme nom d'utilisateur ...)
Si vous atteignez 30k serveurs toutes les 90 minutes, c'est toujours 5,5 requêtes par seconde, oui, c'est la force brute.
La force brute est une question d'approche, pas de vitesse.L'attaque décrite constitue définitivement une «force brute», même si son taux évoque plutôt des connotations avec «gentillesse douce».
Yakk
2017-11-28 01:58:53 UTC
view on stackexchange narkive permalink

La pratique courante d'interdiction des adresses IP qui tentent à plusieurs reprises de pénétrer dans un système ne fonctionne que contre les attaques ciblées.

Un botnet peut trouver une énorme liste de serveurs et distribuer à la fois qui est à l'origine de l'attaque et qui ils attaquent parmi le botnet. Le symptôme va être un niveau d'arrière-plan de tentatives de connexion infructueuses contre votre système, jusqu'à ce que l'une d'entre elles réussisse, auquel cas ils déploieront un kit qui escalade en racine et ajoutera votre système au botnet.

Vous peut se défendre contre cela de très peu de façons.

Les mots de passe forts sont une défense possible, mais doivent être associés à la protection de votre système contre les attaques non basées sur un mot de passe. Supposons qu'il y ait une attaque de débordement / sous-dépassement de tampon sur votre système de connexion; le botnet pourrait être commuté pour effectuer cette attaque et rooter des milliers de systèmes par minute, y compris le vôtre.

Une autre défense pourrait être l'obscurité. Ce genre d'attaques s'attaque aux fruits à portée de main. Modifiez votre système de connexion pour (par exemple) exiger un ping vers un numéro de port particulier avant de permettre les tentatives de connexion. C'est purement obscur, mais soudainement, il ne semble plus y avoir un endroit pour s'y connecter. Le coût est que vous devez maintenant créer un ping spécifique pour vous connecter à distance. Ou vous pouvez mettre sur liste blanche quelques adresses IP à partir desquelles vous êtes autorisé à vous connecter à distance.

Une dernière approche extrêmement difficile serait de générer un détecteur de système de piratage de mot de passe de botnet distribué. Tout comme les systèmes gardent une trace des adresses IP qui les attaquent, un système distribué peut garder une trace des botnets attaquant n'importe qui. Ajoutez un système de confiance et vous pourriez créer une infrastructure capable de détecter de tels botnets de piratage de mots de passe et de faire en sorte que tout le monde les bloque.

Un tel effort prendrait des années de travail et échouerait probablement. Mais c'est quelque chose que vous pouvez faire.

Pour en savoir plus, lisez sur [le Hail Mary Cloud] (http://bsdly.blogspot.co.uk/2013/10/the-hail-mary-cloud-and-lessons-learned.html).
@JdeBP Pouvez-vous répondre à ce court commentaire?Une réponse avec le terme "Hail Mary Cloud" et la référence donnée devraient être ici.
Harry McGovern
2017-11-28 21:03:51 UTC
view on stackexchange narkive permalink

L'authentification SASL PLAIN a échoué: andb3db68ad.virtua.com.br ne résout pas l'adresse 179.219.104.173

Tant que l'authentification PLAIN n'est activée pour aucun utilisateur, vous devriez être d'accord. De plus, ceci: b3db68ad.virtua.com.br ne se résout pas à l'adresse 179.219.104.173 vous indique que le (s) domaine (s) est un faux domaine, car il ne se résout pas à l'adresse IP utilisée. Un autre échec. Cela ne vient peut-être même pas de ce domaine, vous pouvez passer beaucoup de temps avec les règles d'écriture de Postfix pour interdire ce genre de chose, mais au final, le temps que vous passez dépasse de loin la charge de votre système. >

Des méthodes d'authentification plus sécurisées (hachage + - kerberos) ne protègent que le mot de passe d'être reniflé quelque part en cours de route ou des journaux, ce qui signifie qu'il protège l'utilisateur le mot de passe est utilisé, éventuellement via une connexion centralisée, pour l'authentification sur d'autres systèmes. Donc il ne va pas bien!La force brute fonctionne toujours, quelle que soit la sécurité des tests de mot de passe, même avec Kerberos qui utilise une sorte d'approche de hachage + défi (pour ne même pas envoyer de hachage réutilisable sur le réseau).


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...