|sections in this module||City
College of San Francisco - CS260A
Unix/Linux System Administration
There are two primary reasons for using log files. The first, monitoring system events such as hardware issues, is secure on a local machine. If your reason for monitoring log files is to monitor security, you must ask yourself: if the system has a break-in, can I rely on the log files?
For this reason, rsyslog is often used to log information remotely. Designating a remote server with heightened security as the recipient of copies of log information is an easy way to duplicate information, provide a central repository, and improve your chances of tracing any surreptitious activity.
Consider this simple scenario
A junior system administrator makes a mistake when logged in as root. In order to cover his tracks, he simply deletes the entries in /var/log/secure that show he logged in as root. Since the wtmp log only shows direct root logins (not su logins), there is no record of a root user being logged on when the damage occurred.
This scheme might sound pretty good if you're the junior administrator, but not if you're responsible for the system. If the system had been configured to log authorization records to a secure server as well as the local system, the suspicious login could be traced.
Remote logging with rsyslog
Configuring rsyslog to log remotely consists of two parts: the client must have a remote log destination indicated in /etc/rsyslog.conf. This is simple. For example, suppose in foo.org they have designated a secure logging machine as x.foo.org. (Of course, x.foo.org should not be accessible to any but the most trusted users.) You could create an entry in the /etc/rsyslog.conf of other machines in foo.org like this:
This logs all authpriv and auth messages (except auth.debug) remotely to x.foo.org. Their destination on x.foo.org is determined by the /etc/rsyslog.conf file on x.foo.org (they are intermingled with the local messages of the same type on x.foo.org )
NOTE: if you are logging to a machine that is running sysklogd rather than rsyslogd, you must configure your default format for forwarded messages on the client like this:
Even using this default template for forwarded messages you will
see that the hostname is duplicated in each message, but the
message will be logged at least! (Without the directive, sysklogd will ignore the
remote message as invalid.)
For brevity, we will only cover UDP logging. On x.foo.org, you must configure rsyslogd to listen to the syslog port (udp port 514). This can be accomplished either through the GUI interface to system-config-firewall, or by adding the following line to /etc/sysconfig/system-config-firewall
You must also ensure the port is specified in /etc/services with the line
Traditionally syslogd was always configured to listen to its port for remotely logged messages. This is not a good idea for two reasons:
After consideration of these two potential problems, you should configure your version of rsyslogd to ensure it either listens to its port or not by modifying /etc/rsyslog.conf appropriately. To enable remote logging (the receipt of remotely-logged messages), add these lines to /etc/rsyslog.conf:
Then you must restart rsyslogd. It is a subsystem. You can restart it like this:
service rsyslog restart
(Note the confusion between rsyslog and rsyslogd. Be careful which name is used when. It is inconsistent. Why is the name for rsyslogd's configuration file /etc/sysconfig/rsyslog for example? Better yet, why does the rsyslogd daemon still create a file named syslogd.pid in /var/run?)
Excessive log traffic
As mentioned in the previous section, a common hack is to overwhelm rsyslog with log traffic. There are two problems associated with this
|Prev|| This page was made entirely
with free software on linux:
the Mozilla Project and Openoffice.org