J'ai besoin d'aide pour identifier certaines erreurs dans mon auth.log fichier 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 , j'ai donc changé mon 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 des 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 journaux CRON dans mon auth.log c'est lié à PAM, et ce serait bien 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
Réponse acceptée :
Tout d'abord, ce n'est pas rare de voir sur les serveurs de messagerie. Tous 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 en sont touchés, la raison pour laquelle beaucoup de ces tentatives sont filtrées et bloquées est l'IDS/IPS (Intrusion Detection / Prevention System) à la frontière du réseau qui fait référence à de nombreuses sources d'OSINT (Open Source Intelligence) pour créer un ensemble de mauvaises adresses IP basées sur la réputation qui sont bloqué. Certaines de ces sondes réussissent, mais elles ne réussissent pas lorsqu'elles essaient.
Selon toute vraisemblance, ce n'est pas une force brute ciblée contre votre serveur, ce sont "les scanners et les sondes d'Internet" qui font leur travail sur chaque serveur SMTP faisant face à Internet. Ce sont probablement des spambots qui tentent de rechercher des relais ouverts, et s'ils ne trouvent pas de relais ouvert, ils essaient probablement d'accéder aux comptes afin d'utiliser le serveur SMTP comme relais de messagerie. Ou c'est un scanner de service essayant de voir si vous avez des "mots de passe faibles" en jeu afin qu'ils puissent les exploiter, puis exploiter votre serveur pour envoyer leur propre courrier via vos serveurs de messagerie.
Connexe :Hibernate manquant dans le menu d'alimentation et lorsque j'appuie sur le bouton d'alimentation de l'ordinateur portable ?Tant que vous suivez les autres pratiques de sécurité des mots de passe forts, ne donnant pas accès aux utilisateurs à moins qu'ils n'en aient besoin, etc., vous devriez être prêt à ne pas pénétrer dans votre serveur. Je serais moins préoccupé par les échecs d'authentification, et plus préoccupé si les authentifications réussissaient.
Une option de sécurité supplémentaire consiste à configurer Fail2Ban qui fonctionnera pour interdire les utilisateurs, mais je n'ai pas encore réussi à le faire fonctionner correctement et je n'ai pas eu le temps de creuser dedans pour que fail2ban fonctionne pour mon serveur de messagerie pour interdire automatiquement les adresses IP si elles échouent à auth trop de fois). Soyez prudent avec cela, car cela peut également vous bloquer vous si vous ne faites pas attention. (Une fois que j'aurai une configuration Fail2Ban "fonctionnelle", je la partagerai en commentaire de cette réponse, mais il a été difficile de la faire se comporter comme je le souhaite)
Quant au cron:session entrées dans votre auth.log , c'est juste une note que le système cron le démon exécute cron tâches de /etc/crontab , /etc/cron.{d,daily,hourly,monthly,weekly}/* , et la root l'utilisateur crontab selon le calendrier défini pour les tâches cron en tant qu'utilisateur root (où les crontabs sont configurés pour s'exécuter en tant que root ). Ce sont généralement OK, à condition que vous vérifiiez réellement chaque crontab sous le compte root pour vous assurer que rien de "mauvais" ne s'exécute automatiquement en tant que root .