Vtyjkyuk

I need help pinpointing some errors in my auth.log file on my Ubuntu server. A few weeks ago, I found a plethora of login attempts to my SSH port (22) on auth.log, so I changed my SSH port. It was clean for a week, and then I found another bunch of login attempts through a different port.

I'm getting a lot of duplicates of the lines in red (in the image). The repeating lines are as follows:

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]

I can tell that they are trying to login to my mailserver (since the realm is mail.mydomain.com), but I can't tell exactly what they are trying to do, since I don't know what PAM is. What is PAM? And what should I do to stop these auth attempts on my mailserver (port 25)?

I'm also occasionally getting some CRON logs in my auth.log that's related to PAM, and it'll be great if someone can tell me what these mean too:

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

Firstly, this is not uncommon to see on mail servers. Every Mail Server on the Internet sees these if port 25 is exposed to the web. Even the mail gateways and mail servers at my workplace get hit with these, the reason that many of these attempts get filtered out and blocked is the IDS/IPS (Intrustion Detection / Prevention System) on the border of the network which refers to many sources of OSINT (Open Source Intelligence) to create a reputation-based set of bad IPs which are blocked. Some of these probes get through, but they are not successful when they try.

In all likelihood, it's not a targeted brute force against your server, it's "the scanners and probes of the Internet" doing their thing to every Internet-facing SMTP server. These're probably spambots attempting to probe for open relays, and if they don't find an open relay, they're likely probing to try and gain access to accounts in order to use the SMTP server as a mail relay. Or it's a service scanner trying to see if you've got any 'weak passwords' in play so they can exploit them and then exploit your server to send their own mail via your mailservers.

So long as you follow the other security practices of strong passwords, not giving users access unless they need it, etc., you should be good to go in terms of them not breaking into your server. I would be less concerned with the authentication failures, and more concerned if the auths were successful.

An additional security option is to set up Fail2Ban which will work to ban users, however I've yet to get this functioning properly and haven't had time to dig into it to make fail2ban work for my mail server to autoban IPs if they fail to auth too many times). Tread lightly with this though, because it can also block you if you aren't careful. (Once I have a 'working' Fail2Ban config I'll share that as a comment to this answer, but it's been tricky to get it to behave the way I want it to)

As for the cron:session entries in your auth.log, that's just a note that the system's cron daemon is running cron tasks from /etc/crontab, /etc/cron.d,daily,hourly,monthly,weekly/*, and the root user crontab per the schedule set for cron jobs as the root user (where the crontabs are set to run as root). Those are typically OK, provided that you actually check every single crontab under the root account to make sure nothing 'bad' is running automatically as root.