Beaucoup d'erreurs d'authentification PAM sur mes journaux ciblant mon serveur de messagerie. Comment puis-je l'arrêter?
J'ai besoin d'aide pour identifier certaines erreurs dans mon fichier auth.log sur mon serveur Ubuntu. Il y a quelques semaines, j'ai trouvé une pléthore de tentatives de connexion à mon port SSH (22) sur auth.log, alors j'ai changé de port SSH. C'était propre pendant une semaine, puis j'ai trouvé un autre groupe de tentatives de connexion via un port différent.
Je reçois beaucoup de doublons de lignes en rouge (dans l'image). Les lignes répétitives sont les suivantes:
saslauthd[1140]: pam_unix(smtp:auth): check pass; user unknown
saslauthd[1140]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
saslauthd[1140]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
saslauthd[1140]: do_auth : auth failure: [user=roselia] [service=smtp] [realm=mail.mydomain.com] [mech=pam] [reason=PAM auth error]
Je peux dire qu'ils essaient de se connecter à mon serveur de messagerie (puisque le domaine est mail.mydomain.com), mais je ne peux pas dire exactement ce qu'ils essaient de faire, car je ne sais pas ce qu'est PAM. Qu'est-ce que PAM? Et que dois-je faire pour arrêter ces tentatives d’authentification sur mon serveur de messagerie (port 25)?
Je reçois aussi occasionnellement des logs CRON dans mon auth.log qui est lié à PAM, et ce serait génial si quelqu'un pouvait me dire ce que cela signifie aussi:
CRON[32236]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32235]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[32236]: pam_unix(cron:session): session closed for user root
CRON[32235]: pam_unix(cron:session): session closed for user root
Tout d'abord, il n'est pas rare de voir cela sur les serveurs de messagerie. Every Le serveur de messagerie sur Internet les voit si le port 25 est exposé au Web. Même les passerelles de messagerie et les serveurs de messagerie de mon lieu de travail sont frappés par ceux-ci. La raison pour laquelle beaucoup de ces tentatives sont filtrés et bloqués est le système de détection/prévention des intrusions IDS/IPS (IPS) situé à la frontière de le réseau qui fait référence à de nombreuses sources de OSINT (Open Source Intelligence) pour créer un ensemble d'adresses IP incorrectes bloquées basé sur la réputation. Certaines de ces sondes réussissent, mais elles échouent lorsqu'elles tentent.
Selon toute vraisemblance, ce n'est pas une force brute ciblée contre votre serveur, mais bien "les scanners et les sondes d'Internet" qui agissent de la sorte envers chaque serveur SMTP connecté à Internet. Ce sont probablement des spambots qui tentent de rechercher des relais ouverts, et s’ils ne trouvent pas de relais ouvert, ils tenteront probablement d’obtenir l’accès à des comptes afin d’utiliser le serveur SMTP comme relais de messagerie. Ou bien c'est un scanner de service qui essaie de voir si vous avez des "mots de passe faibles" en jeu afin qu'ils puissent les exploiter, puis votre serveur pour envoyer leur propre courrier via vos serveurs de messagerie.
Tant que vous suivez les autres pratiques de sécurité, à savoir les mots de passe forts, et que vous ne donnez pas d'accès aux utilisateurs à moins qu'ils n'en aient besoin, etc., vous devriez pouvoir vous débrouiller pour qu'ils ne pénètrent pas sur votre serveur. Je serais moins préoccupé par les échecs d'authentification, et plus inquiet si les autorisations étaient réussies.
Une option de sécurité supplémentaire consiste à configurer Fail2Ban, qui fonctionnera pour interdire les utilisateurs. Cependant, je n’ai pas encore réussi à le faire fonctionner et je n’ai pas eu le temps de creuser pour que fail2ban fonctionne pour que mon serveur de messagerie fonctionne avec des adresses IP en cas d’échec. d'autoriser trop de fois). Cependant, cela peut marcher, car il peut également bloquer vous si vous ne faites pas attention. (Une fois que ma configuration Fail2Ban fonctionnera, je la partagerai comme commentaire à cette réponse, mais il a été difficile de la faire fonctionner comme je le voulais.)
En ce qui concerne les entrées cron:session dans votre auth.log, il ne faut pas oublier que le démon cron du système exécute cron tâches à partir de /etc/crontab, /etc/cron.{d,daily,hourly,monthly,weekly}/* et la crontab utilisateur root selon la planification définie pour les tâches cron en tant qu'utilisateur root (les crontabs étant configurés pour s'exécuter en tant que root). Celles-ci sont généralement acceptables, à condition que vous vérifiiez chaque crontab sous le compte root pour vous assurer que rien de "mauvais" ne s'exécute automatiquement en tant que root.