Does your site have a central logserver which has been configured to report on logs received from all systems? If so:
$ sudo rm /etc/cron.daily/0logwatchIf no logserver exists, it will be necessary for each system to run Logwatch individually. Using a central logserver provides the security and reliability benefits discussed earlier, and also makes monitoring logs easier and less time-intensive for administrators.
The logrotate utility allows for the automatic rotation of log files. The frequency of rotation is specified in /etc/logrotate.conf, which triggers a cron task or a timer. To configure logrotate to run daily, add or correct the following line in /etc/logrotate.conf:
# rotate log files frequency daily
Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full.
Ensure that the system real-time clock (RTC) is set to Coordinated Universal Time (UTC).
If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the operating system include date and time. Time is commonly expressed in UTC, a modern continuation of GMT, or local time with an offset from UTC.
The journald system can compress large log files to avoid fill the system disk.
Log files that are not properly compressed run the risk of growing so large that they fill up the log partition. Valuable logging information could be lost if the log partition becomes full.
Data from journald may be stored in volatile memory or persisted locally. Utilities exist to accept remote export of journald logs.
Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system.
The journald system may store log files in volatile memory or locally on disk. If the logs are only stored in volatile memory they will we lost upon reboot.
Log files contain valuable data and need to be persistent to aid in possible investigations.
On a central logserver, you want Logwatch to summarize all syslog entries, including those which did not originate on the logserver itself. The HostLimit setting tells Logwatch to report on all hosts, not just the one on which it is running.
HostLimit = no
If SplitHosts is set, Logwatch will separate entries by hostname. This makes the report longer but significantly more usable. If it is not set, then Logwatch will not report which host generated a given log entry, and that information is almost always necessary
SplitHosts = yes
logrotate is installed by default. The logrotate package can be installed with the following command:
$ sudo yum install logrotate
The logrotate package provides the logrotate services.
TLS protocol support for rsyslog is installed.
The rsyslog-gnutls package can be installed with the following command:
$ sudo yum install rsyslog-gnutls
The rsyslog-gnutls package provides Transport Layer Security (TLS) support for the rsyslog daemon, which enables secure remote logging.
Rsyslog is installed by default. The rsyslog package can be installed with the following command:
$ sudo yum install rsyslog
The rsyslog package provides the rsyslog daemon, which provides system logging services.
syslog-ng can be installed in replacement of rsyslog.
The syslog-ng-core package can be installed with the following command:
$ sudo yum install syslog-ng-core
The syslog-ng-core package provides the syslog-ng daemon, which provides system logging services.
Journald (via systemd-journal-remote ) supports the ability to send log events it gathers to a remote log host or to receive messages from remote hosts, thus enabling centralised log management.
Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system.
The rsyslog daemon should not accept remote messages unless the system acts as a log server. If the system needs to act as a central log server, add the following lines to /etc/rsyslog.conf to enable reception of messages over TCP:
$ModLoad imtcp $InputTCPServerRun 514
If the system needs to act as a log server, this ensures that it can receive messages over a reliable TCP connection.
The rsyslog daemon should not accept remote messages unless the system acts as a log server. If the system needs to act as a central log server, add the following lines to /etc/rsyslog.conf to enable reception of messages over UDP:
$ModLoad imudp $UDPServerRun 514
Many devices, such as switches, routers, and other Unix-like systems, may only support the traditional syslog transmission over UDP. If the system must act as a log server, this enables it to receive their messages as well.
Cron logging must be implemented to spot intrusions or trace cron job status. If cron is not logging to rsyslog, it can be implemented by adding the following to the RULES section of /etc/rsyslog.conf:
cron.* /var/log/cron
Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users.
Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs the remote system must be authenticated.
The audit records generated by Rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Audit records should be protected from unauthorized access.
Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs off a encrpytion system must be used.
The audit records generated by Rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Audit records should be protected from unauthorized access.
Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs off an encryption system must be used.
The audit records generated by Rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Audit records should be protected from unauthorized access.
rsyslog will create logfiles that do not already exist on the system. This settings controls what permissions will be applied to these newly created files.
It is important to ensure that log files have the correct permissions to ensure that sensitive data is archived and protected.
The group-owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's group owner:
$ ls -l LOGFILEIf the owner is not root, run the following command to correct this:
$ sudo chgrp root LOGFILE
The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.
The owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's owner:
$ ls -l LOGFILEIf the owner is not root, run the following command to correct this:
$ sudo chown root LOGFILE
The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.
The file permissions for all log files written by rsyslog should be set to 640, or more restrictive. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's permissions:
$ ls -l LOGFILEIf the permissions are not 640 or more restrictive, run the following command to correct this:
$ sudo chmod 640 LOGFILE"
Log files can contain valuable information regarding system configuration. If the system log files are not protected unauthorized users could change the logged data, eliminating their forensic value.
The /etc/rsyslog.conf and /etc/rsyslog.d/*.conf files specifies rules for logging and which files are to be used to log certain classes of messages.
A great deal of important security-related information is sent via rsyslog (e.g., successful and failed su attempts, failed login attempts, root login attempts, etc.).
The rsyslog daemon should not accept remote messages unless the system acts as a log server. To ensure that it is not listening on the network, ensure any of the following lines are not found in rsyslog configuration files. If using legacy syntax:
$ModLoad imtcp $InputTCPServerRun port $ModLoad imudp $UDPServerRun port $ModLoad imrelp $InputRELPServerRun portIf using RainerScript syntax:
module(load="imtcp") module(load="imudp") input(type="imtcp" port="514") input(type="imudp" port="514")
Any process which receives messages from the network incurs some risk of receiving malicious messages. This risk can be eliminated for rsyslog by configuring it not to listen on the network.
Logging of remote access methods must be implemented to help identify cyber attacks and ensure ongoing compliance with remote access policies are being audited and upheld. An examples of a remote access method is the use of the Remote Desktop Protocol (RDP) from an external, non-organization controlled network. The /etc/rsyslog.conf or /etc/rsyslog.d/*.conf file should contain a match for the following selectors: auth.*, authpriv.*, and daemon.*. If not, use the following as an example configuration:
auth.*;authpriv.*;daemon.* /var/log/secure
Logging remote access methods can be used to trace the decrease the risks associated with remote user access management. It can also be used to spot cyber attacks and ensure ongoing compliance with organizational policies surrounding the use of remote access methods.
To configure rsyslog to send logs to a remote log server,
open /etc/rsyslog.conf and read and understand the last section of the file,
which describes the multiple directives necessary to activate remote
logging.
Along with these other directives, the system can be configured
to forward its logs to a particular log server by
adding or correcting one of the following lines,
substituting $rsyslog_remote_loghost_address appropriately.
The choice of protocol depends on the environment of the system;
although TCP and RELP provide more reliable message delivery,
they may not be supported in all environments.
To use UDP for log message delivery:
*.* @$rsyslog_remote_loghost_address
*.* @@$rsyslog_remote_loghost_address
*.* :omrelp:$rsyslog_remote_loghost_address
A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise.
Configure rsyslog to use Transport Layer Security (TLS) support for logging to remote server for the Forwarding Output Module in /etc/rsyslog.conf using action. You can use the following command:
echo 'action(type="omfwd" protocol="tcp" Target="<remote system>" port="6514"
StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" streamdriver.CheckExtendedKeyPurpose="on")' >> /etc/rsyslog.conf
Replace the <remote system> in the above command with an IP address or a host name of the remote logging server.
For protection of data being logged, the connection to the remote logging server needs to be authenticated and encrypted.
Configure CA certificate for rsyslog logging to remote server using Transport Layer Security (TLS) using correct path for the DefaultNetstreamDriverCAFile global option in /etc/rsyslog.conf, for example with the following command:
echo 'global(DefaultNetstreamDriverCAFile="/etc/pki/tls/cert.pem")' >> /etc/rsyslog.confReplace the /etc/pki/tls/cert.pem in the above command with the path to the file with CA certificate generated for the purpose of remote logging.
The CA certificate needs to be set or rsyslog.service fails to start with
error: ca certificate is not set, cannot continue
The rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 7.
The rsyslog service can be enabled with the following command:
$ sudo systemctl enable rsyslog.service
The rsyslog service must be running in order to provide logging services, which are essential to system administration.
The syslog-ng service (in replacement of rsyslog) provides syslog-style logging by default on Debian.
The syslog-ng service can be enabled with the following command:
$ sudo systemctl enable syslog-ng.service
The syslog-ng service must be running in order to provide logging services, which are essential to system administration.
The systemd-journald service is an essential component of
systemd.
The systemd-journald service can be enabled with the following command:
$ sudo systemctl enable systemd-journald.service
In the event of a system failure, Red Hat Enterprise Linux 7 must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to system processes.
Journald supports the ability to receive messages from remote hosts, thus acting as a log server. Clients should not receive data from other hosts. NOTE: The same package, systemd-journal-remote , is used for both sending logs to remote hosts and receiving incoming logs. With regards to receiving logs, there are two Systemd unit files; systemd-journal-remote.socket and systemd-journal-remote.service.
If a client is configured to also receive data, thus turning it into a server, the client system is acting outside it's operational boundary.
The logrotate timer can be enabled with the following command:
$ sudo systemctl enable logrotate.timer
Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full.