0

I used Nano to access the secure log since I had found Fail2ban is no longer working. I didn't make any changes but simply exited the file. Now logging to that file has stopped at the exact time I accessed the file.

I've rebooted the server twice since then but still the logging has stopped on 16:30 yesterday.

Why has this happened?

11
  • 1
    Perhaps you have inadvertently changed the permissions (or SELinux context?) of the file. What does ls -lhZ /var/log/secure and sestatus say. I would also recommend using less or something similarly read-only when viewing logs. nano is kinda dangerous in my (admittedly dated) experience (nano -w is much safer when looking at config files especially). May 23, 2017 at 10:29
  • @CameronKerr Permissiong are -rw------- root root ? and sestatus says disabled. Thanks!
    – HippoDuck
    May 23, 2017 at 10:35
  • Odd that even a reboot didn't resolve it. How about forcing a log rotation using logrotate -f /etc/logrotate.conf (check using the manual page that -f will do a force though). If you do something like a login, then you should see that new entries in the file. You might also look for other reasons it might fail (eg. do df -h /var/log/ or df -hi /var/log/ show using at 100%). Failing that, you might check that your syslog (rsyslogd / syslogd) is still running. What version of ContOS are you using? May 23, 2017 at 10:46
  • I used your logrotate command and the secure file is now empty. I'm getting 1000+ failed login attempts every hour but that file has remained blank. CentOS 7.2. 18% space used also. The server did stop working yesterday and apache errors said out of memory, but the memory and disk weren't being used much. The restart fixed that anyway.
    – HippoDuck
    May 23, 2017 at 14:30
  • Turn your attention to the configuration of your logging. What is in /etc/syslogd.conf or /etc/rsyslogd.conf? Also check the configuration of /etc/ssh/sshd_config and your fail2ban and show what the logging configuration is for that. What does ls -lh /dev/log show? May 23, 2017 at 19:22

2 Answers 2

1

This happens when you re-create or mess with /var/log/secure file. This will break file permissions, especially if SELinux is enabled.

Do the following:

Make sure /var/log/secure is owned by root:root

$ sudo chown root:root /var/log/secure

Make sure the permission is set to 600

$ sudo chmod 600 /var/log/secure

If SELinux is enabled, you can temporarily disable while troubleshooting your issue

$ sudo setenforce 0

If you decide to keep SELinux enabled, make sure the file has the following context:

$ ls -lZh /var/log/secure
system_u:object_r:var_log_t:s0

To manipulate SELinux on the fly (copy context from an existing known working):

$ sudo chcon --reference /var/log/dmesg /var/log/secure

To manipulate SELinux context permanently, use the semanage command instead.

1
  • 1
    I'd rather use restorecon to reset the context and ausearch -m avc -i to troubleshoot. Disabling SELinux isn't necessary.
    – fuero
    Jan 8, 2022 at 17:07
0

I found myself in this same situation recently. The fix is quite simple, restart the rsyslog service:

systemctl restart rsyslog

This will recreate the /var/log/secure file and re-enable logging.

1
  • Thanks I will give this a try (despite this being a problem for nearly 5 years now).
    – HippoDuck
    Jan 10, 2022 at 16:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .