Ich brauche Hilfe bei der Lokalisierung einiger Fehler in meinem auth.log Datei auf meinem Ubuntu-Server. Vor ein paar Wochen fand ich eine Fülle von Anmeldeversuchen an meinem SSH-Port (22) auf auth.log , also habe ich meinen SSH-Port geändert. Es war eine Woche lang sauber, und dann fand ich eine weitere Reihe von Anmeldeversuchen über einen anderen Port.
Ich bekomme viele Duplikate der Linien in Rot (im Bild). Die sich wiederholenden Zeilen lauten wie folgt:
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]
Ich kann erkennen, dass sie versuchen, sich bei meinem Mailserver anzumelden (da der Realm mail.mydomain.com ist ), aber ich kann nicht genau sagen, was sie versuchen, da ich nicht weiß, was PAM ist. Was ist PAM? Und was soll ich tun, um diese Authentifizierungsversuche auf meinem Mailserver (Port 25) zu stoppen?
Ich erhalte gelegentlich auch einige CRON-Protokolle in meinem auth.log das hängt mit PAM zusammen, und es wäre toll, wenn mir jemand sagen könnte, was diese auch bedeuten:
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
Akzeptierte Antwort:
Erstens ist dies auf Mailservern nicht ungewöhnlich. Alle Der Mailserver im Internet erkennt diese, wenn Port 25 dem Internet ausgesetzt ist. Sogar die Mail-Gateways und Mail-Server an meinem Arbeitsplatz werden davon getroffen, weshalb viele Einer der Versuche, die herausgefiltert und blockiert werden, ist das IDS/IPS (Intrustion Detection / Prevention System) an der Grenze des Netzwerks, das auf viele OSINT-Quellen (Open Source Intelligence) verweist, um einen auf Reputation basierenden Satz von schlechten IPs zu erstellen verstopft. Einige dieser Sonden kommen durch, aber sie sind nicht erfolgreich, wenn sie es versuchen.
Aller Wahrscheinlichkeit nach handelt es sich nicht um eine gezielte Brute Force gegen Ihren Server, sondern um „die Scanner und Sonden des Internets“, die ihr Ding mit jedem mit dem Internet verbundenen SMTP-Server machen. Dies sind wahrscheinlich Spambots, die versuchen, nach offenen Relays zu suchen, und wenn sie kein offenes Relay finden, versuchen sie wahrscheinlich, Zugriff auf Konten zu erhalten, um den SMTP-Server als Mail-Relay zu verwenden. Oder es ist ein Service-Scanner, der versucht zu sehen, ob Sie „schwache Passwörter“ im Spiel haben, damit sie diese ausnutzen und dann Ihren Server ausnutzen können, um ihre eigenen E-Mails über Ihre Mailserver zu senden.
Verwandt:Ruhezustand fehlt im Energiemenü und wenn ich den Netzschalter des Laptops drücke?Solange Sie die anderen Sicherheitspraktiken von starken Passwörtern befolgen, Benutzern keinen Zugriff gewähren, es sei denn, sie benötigen ihn usw., sollten Sie in Bezug darauf, dass sie nicht in Ihren Server einbrechen, gut gerüstet sein. Ich wäre weniger besorgt über die Authentifizierungsfehler und mehr besorgt darüber, ob die Authentifizierungen erfolgreich waren.
Eine zusätzliche Sicherheitsoption ist die Einrichtung von Fail2Ban, mit der Benutzer gesperrt werden können. Ich muss dies jedoch noch richtig zum Laufen bringen und hatte keine Zeit, mich damit zu beschäftigen, damit Fail2ban für meinen Mailserver funktioniert, um IPs automatisch zu sperren, wenn sie ausfallen zu oft authentifizieren). Gehen Sie damit jedoch vorsichtig um, denn es kann Sie auch blockieren wenn du nicht aufpasst. (Sobald ich eine „funktionierende“ Fail2Ban-Konfiguration habe, werde ich das als Kommentar zu dieser Antwort teilen, aber es war schwierig, sie dazu zu bringen, sich so zu verhalten, wie ich es möchte)
Wie für cron:session Einträge in Ihrem auth.log , das ist nur ein Hinweis, dass der cron des Systems Daemon läuft cron Aufgaben aus /etc/crontab , /etc/cron.{d,daily,hourly,monthly,weekly}/* , und die root Benutzer crontab gemäß dem für Cron-Jobs festgelegten Zeitplan als Root-Benutzer (wobei die Crontabs so eingestellt sind, dass sie als root ausgeführt werden ). Diese sind normalerweise in Ordnung, vorausgesetzt, Sie überprüfen tatsächlich jede einzelne Crontab unter dem Root-Konto, um sicherzustellen, dass nichts „Schlechtes“ automatisch als root ausgeführt wird .