Reducing logging to /var/log/auth.log generated by internal HestiaCP housekeeping tasks

Hi all,

I wonder if anyone else feels that the amount of logging into /var/log/auth.log is currently excessive and that perhaps we should try to reduce it.

On my unused testing server (Debian 10 & HestiaCP 1.5.1) the /var/log/auth.log file has grown by 23k lines in 4 days.

I’ve noticed that /etc/sudoers.d/admin file includes a !syslog entry …

TIA, K.

Edit: Sorry for the misunderstanding, I was referring to the auth.log entries generated by internal HestiaCP housekeeping tasks e.g.

Dec 9 19:50:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 19:50:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 19:50:02 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 19:50:02 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 19:50:02 myserver CRON[2999]: pam_unix(cron:session): session closed for user admin
Dec 9 19:50:02 myserver CRON[3000]: pam_unix(cron:session): session closed for user admin
Dec 9 19:50:02 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 19:50:02 myserver CRON[2998]: pam_unix(cron:session): session closed for user admin
Dec 9 19:52:01 myserver CRON[3275]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 19:52:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 19:52:01 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 19:52:01 myserver CRON[3275]: pam_unix(cron:session): session closed for user admin
Dec 9 19:53:51 myserver su: (to root) root on none
Dec 9 19:53:51 myserver su: pam_unix(su-l:session): session opened for user root by (uid=0)
Dec 9 19:53:51 myserver systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)
Dec 9 19:54:00 myserver su: pam_unix(su-l:session): session closed for user root
Dec 9 19:54:01 myserver CRON[3916]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 19:54:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 19:54:01 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 19:54:01 myserver CRON[3916]: pam_unix(cron:session): session closed for user admin
Dec 9 19:54:10 myserver systemd: pam_unix(systemd-user:session): session closed for user root
Dec 9 19:55:01 myserver CRON[3944]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 9 19:55:01 myserver CRON[3946]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 19:55:01 myserver CRON[3945]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 19:55:01 myserver CRON[3944]: pam_unix(cron:session): session closed for user root
Dec 9 19:55:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 19:55:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 19:55:01 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 19:55:01 myserver CRON[3946]: pam_unix(cron:session): session closed for user admin
Dec 9 19:55:02 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 19:55:02 myserver CRON[3945]: pam_unix(cron:session): session closed for user admin
Dec 9 19:56:01 myserver CRON[4195]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 19:56:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 19:56:01 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 19:56:01 myserver CRON[4195]: pam_unix(cron:session): session closed for user admin
Dec 9 19:58:01 myserver CRON[4223]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 19:58:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 19:58:01 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 19:58:01 myserver CRON[4223]: pam_unix(cron:session): session closed for user admin
Dec 9 20:00:01 myserver CRON[4251]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 20:00:01 myserver CRON[4252]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 20:00:01 myserver CRON[4250]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 20:00:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 20:00:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 20:00:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 20:00:01 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 20:00:01 myserver CRON[4251]: pam_unix(cron:session): session closed for user admin
Dec 9 20:00:01 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 20:00:01 myserver CRON[4252]: pam_unix(cron:session): session closed for user admin
Dec 9 20:00:01 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 20:00:01 myserver CRON[4250]: pam_unix(cron:session): session closed for user admin
Dec 9 20:02:01 myserver CRON[4529]: pam_unix(cron:session): session opened for user admin by (uid=0)
Dec 9 20:02:01 myserver sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 9 20:02:01 myserver sudo: pam_unix(sudo:session): session closed for user root
Dec 9 20:02:01 myserver CRON[4529]: pam_unix(cron:session): session closed for user admin
Dec 9 20:02:05 myserver su: (to root) root on none
Dec 9 20:02:05 myserver su: pam_unix(su-l:session): session opened for user root by (uid=0)
Dec 9 20:02:06 myserver systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)

Change ssh port and it should reduce by 99%

Also using ipset with blacklists will reduce the noice a lot: Firewall / Fail2ban / Ipset — Hestia Control Panel documentation

I change the port, do not allow root login and use fail2ban with recidive rules.

The ipsets are interesting you may only allow IPS from your country to ssh port.

Other things that you can do are to set a honeypot on port 22 after you change the port or only access via ssh via a reversed tunnel to one of your servers.

You may also use keys to access and stop the use of passwords.

Usually disable root login and disable the use of passwords… Seems to be working fine…

1 Like

I was referring to the /var/log/auth.log entries generated by the HestiaCP system itself (I just added a log sample in the original post). Sorry for the misunderstanding, I should have been more specific.

I already use hashlimit and ipsets to block unwanted ssh traffic.

Fail2ban should track that too.
You may allow connections to hestia from ipsets or singular IPs.

I’m talking about /var/log/auth.log entries generated by internal HestiaCP housekeeping tasks (cron and sudo by admin).

There is a hestia jail in fail2ban.

As I have commented above, this post refers to INTERNALLY GENERATED /var/log/auth.log ENTRIES (by cron and sudo tasks performed by admin), not log spam by failed ssh attempts.

So fail2ban jails and ssh port change etc are not a solution.

As it currently is, potentially significant auth logfile entries may be missed (or overwritten by logrotate).

Missed from what? fail2ban still checks it properly, also the logs are due to os design and the way how sudo commands get logged. I dont think there is anything we can do to minimize them

I am playing right now with settings in PAM and rsyslog to see if I can reduce the amount of log-spam by cron/sudo …

root@myserver:/etc# tail -2 /etc/pam.conf
session [success=1 default=ignore] pam_succeed_if.so quiet uid=0 ruser=admin

root@myserver:/etc#

I have found a few topics at stackexchange about this issue e.g.

Note: check the answer by user [not2qubit]

I chose the quick and dirty way out, by suppressing those logs with rsyslog (rather than reconfiguring PAM & sudo) using :msg, contains, "session xyz" stop

Btw is it normal for v-update-sys-queue to run so often?

tail -f /var/log/cron.log 
Dec 13 22:24:01 myserver CRON[29784]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
Dec 13 22:25:01 myserver CRON[29813]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Dec 13 22:25:01 myserver CRON[29814]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
Dec 13 22:25:01 myserver CRON[29815]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
Dec 13 22:26:01 myserver CRON[30165]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
Dec 13 22:28:01 myserver CRON[30193]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
Dec 13 22:30:01 myserver CRON[30238]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue backup)
Dec 13 22:30:01 myserver CRON[30239]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-rrd)
Dec 13 22:30:01 myserver CRON[30240]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
Dec 13 22:32:01 myserver CRON[30518]: (admin) CMD (sudo /usr/local/hestia/bin/v-update-sys-queue restart)
^C

By default every 5 min

Restart probally even faster…

It checks the /data/queue folder

According to the log timestamps above, restart seems to run every 2 min (note: this is a test system, I haven’t changed anything from the defaults afaik).

2min sound fine for restart

If its really bothering you, you can tell rsyslog to log cron commands to a different file.
On my Ubuntu 20 server, this seems to work.
In /etc/rsyslog.d/50-default.conf, change these two lines

*.*;auth,authpriv.none               -/var/log/syslog
# cron.*                          /var/log/cron.log

to

*.*;auth,authpriv.none,cron.none                -/var/log/syslog
cron.*                          /var/log/cron.log

and then systemctl restart rsyslog.service

Indeed and as you can see in my previous message (see #13 above, marked as the solution), I’m already logging cron separately.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.