Misc: Syslog daemon configuration

Title:

Misc: Syslog daemon configuration

Author:

Douglas O’Leary <dkoleary@olearycomputers.com>

Description:

Misc: Syslog daemon configuration

Date created:

02/2001

Date updated:

10/03/2015

Disclaimer:

Standard: Use the information that follows at your own risk. If you screw up a system, don’t blame it on me…

NOTE (10/03/15): The info below is still good for the standard syslog daemon; however, lately, I’ve been setting up rsyslog for clients as a syslog collector and using filter scripts for parsing things like ssh traffic. Works really well; but, I need to come up with some notes that will probably end up reaplacing these.

I will usually reconfigure the syslog daemon on most systems that I manage for two reasons:

1. Security

2. Useability

The log files are the first things that the bad guys are going to try to get at if you’re being hacked. Even if they don’t have root, they’ll be interested in what you’re logging so they’ll know what to avoid. Therefore, you want to move the log files from their default location into a directory that’s 750 permissions (at a minimum). It’ll help the admins if you make the group something like sysadmin so the admins don’t have to be root to read the logs. Helps prevent accidnts and gets admins into the habit of not always logging in as root. Both Solaris and HPUX put them in directories that everyone can get into and read. Usually, they can’t write to them; however, I’ve seen some clients that had that enabled as well… Best case scenario has the logs going both internally and to an external log host.

On the useability front, the log files are one of the first places to check into when looking into system problems. Now, under Solaris, for example, if you suspect some type of daemon problem, you have to go paging through all the other messages to find anything about daemon messages. Of course, you could grep the stuff out, but why work when you can get the system to do it for you?

The other benefit from setting up logging in a standard way is you don’t have to go looking for it on each system. Solaris: /var/adm/messages. HPUX /var/adm/syslog/syslog.log, Irix: Also /var/adm/messages, if I remember right. Make it standard across all systems and you won’t have to worry about figuring out where the logs are when you need them.

man syslog on whatever system you’re running to find out which facilities are supported - they do change from system to system. At a minimum, it should have:

1. Kernel

2. User

3. Daemon

4. mail

5. Auth

Facilities, from what I’ve seen, actually seem to be fairly well standardized across platforms. The levels, from highest to lowest:

1. emerg

2. alert

3. crit

4. err

5. warning

6. notice

7. info

8. debug

9. none

The specific steps to reconfiguring the syslog daemon:

1. Create the logging directory with appropriate permissions and ownership.

   # mkdir /var/logs
   # chown root:sysadmin /var/logs
   # chmod 750 /var/logs
   

2. Make a backup copy of the current syslog.conf file:

3. Edit it to separate out the files. This one off of an HP, for instance:

   #############################################
   mail.info        /var/logs/mail.log
   daemon.notice    /var/logs/daemon.log
   auth.info        /var/logs/auth.log
   kern.info        /var/logs/kernel.log
   *.info;mail.none /var/logs/syslog.log
   *.emerg          *
   

This separates out mail, daemon, auth, and kernel messages into their own log files while still maintaining one single log file for everything. Use that one in case you haven’t a clue what’s causing the problem and want to see everything at the same time.

4. Create all the log files:

   for file in $(grep -v '^#' /etc/syslog.conf | grep -v '\*' | \
      awk '{print $2}')
   do
      touch ${file}
   done
   

5. SIGHUP syslogd.

   # ps -ef | grep syslogd ## Note the PID
   # kill -HUP ${PID}
   

6. Test out the new syslog functionality with a variety of facilities and levels:

   logger -p mail.info "Testing the mail.info facility.level"
   logger -p daemon.notice "Testing the daemon.notice facility"
   

   You can try the kernel facility; however, I haven’t seen a system yet where that works from the command line.

Finally, remember to check the log files daily. I wouldn’t even hazard a guess at how many problems I managed to head off before they were issues just by keeping an eyeball on the log files…