Summary: Syslog servers can be subjected to DoS attacks both locally and remotely - take steps to protect your logs from abuse.

Your system logs are your first source of information about what has occurred on your computer. There are many different possible system logging daemons, syslogd and syslog-ng being the most popular. Both have a configuration file (/etc/syslog.conf and /etc/syslog-ng.conf respectively) that dictates where logs should be sent. You may just log everything to /var/log/messages, or you may break logs up by facility (/var/log/{daemon,mail,auth,etc}.log) for easier processing. You may send your logs to network-accessible log servers using UDP or TCP[1].

Aside from any network loggers, your system log daemon usually writes its logs to the /var/log directory. To keep this filesystem from filling up, many Linux distributions include daily, weekly, or monthly cron jobs which rotate your system logs so you do not fill up the /var/ partition. Syslog-ng can handle log rotation itself, without the need of a periodic cron job.

Unfortunately, most log rotation systems only keep a certain number of old log files around, and eventually old logs get deleted. An attacker can purposefully spew your syslog server with uninteresting log entries to cause the logs to rotate out of existence and hide any of his earlier logged activities. It's always a good idea to have a network system log server that gets copies of logs so you have more than one place to check logs, as well as making sure you have backups of your log files. Personally, I prefer to not allow anything to automatically rotate and discard my log files -- when /var gets too full, I back them up and rotate manually.

There are three ways an attacker can add entries to your system logs.

Over the Network

If your system log daemon listens for logs on a network port, the attacker can simply connect and send boatloads of bogus logs. Syslogd used to listen on the network by default, but newer versions do not, and require a -r flag to accept network syslogs. The easiest way for you to check if your system log daemon accepts logs from the network is to use netstat as follows:

  # netstat -nap | grep 514
  udp            0     0 0.0.0.0:514            0.0.0.0:*     120/syslogd
  
  # ps -fp 120
  UID        PID  PPID  C STIME TTY          TIME CMD
  root     17414     1  0 15:48 ?        00:00:00 /sbin/syslogd -r
  

In the above listing, we see that syslogd pid 120 is listening on UDP port 514. We should change the startup scripts to not include the -r flag for syslogd on this machine to prevent it from listening on the syslog port.

Syslog-ng can listen on both UDP and TCP as well, so be sure to be on the lookout for either. Of course Syslog-ng can also be configured to ignore messages from unauthorized hosts, so you should check your actual configuration to see if you are allowing unrestricted network logs or not.

/dev/log

Most system logging daemons listen on one or more unix sockets[2], the most typical being /dev/log:

  # lsof -c syslogd | egrep "unix|PID"
  COMMAND   PID USER   FD   TYPE     DEVICE    SIZE   NODE NAME
  syslogd   120 root    0u  unix 0xcee94370         150566 /dev/log
  
  # ls -l /dev/log
  srw-rw-rw-    1 root     root            0 Feb 20 15:56 /dev/log

Here we can see that our syslogd daemon is listening to the socket /dev/log. If you have programs that run in chrooted areas, you may have additional log sockets for syslogd to watch.

Any user that has write access to a logging socket can send send messages to the system log daemon. For example one could use the logger program:

  user$ cat spam_the_syslog
  #!/bin/sh
  while :
    do
      logger -p daemon.emerg "Whoa - catastrophic emergency!"
    done
  
  user$ ./spam_the_syslog

It's good to allow user processes to be able to send system log messages, so under normal circumstances this is not a problem. However if you have troublesome users or developers who have a tendency to spew tons of logs[3] then you can change the /dev/log permissions to protect your logs from excess junk:

Option one: allow only specific users to send syslog messages:

  # groupadd loggers
  # chgrp loggers /dev/log
  # chmod o-rw,ug+rw /dev/log
  # ls -l /dev/log
  srw-rw----    1 root     loggers         0 Feb 20 15:56 /dev/log
  
Or, you can disallow only troublesome users:

  # groupadd nolog
  # chgrp nolog /dev/log
  # chmod g-rw,o+rw /dev/log
  # ls -l /dev/log
  srw----rw-    1 root     nolog           0 Feb 20 15:56 /dev/log

Legitimate Daemons

An attacker can also cause legitimate daemons to make excessive log entries. For example by connecting unsuccessfully to an SSH daemon an attacker can generate a few syslog entries:

  PAM_unix: authentication failure; (uid=0) -> cracker for ssh service
  sshd: Failed password for cracker from 127.0.0.1 port 2003
  sshd: Failed password for cracker from 127.0.0.1 port 2003
  PAM_unix: 2 more authentication failures; (uid=0) -> cracker for ssh service

By hitting many daemons with many connections, lots of spurious logs can be generated. This is not a very popular attack, however, because most daemons log something about the cracker's machine (the IP address above, for example.)

NOTES:

[1] Syslogd does not support TCP, but Syslog-ng does. Syslog-ng supports a lot of great features not available in the near-ancient syslogd.

[2] Unix sockets are just special files that can be connected to processes, rather than the disk itself. They're similar to filesystem pipes.

[3] And for some reason you can't lock out their accounts and fire them...

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. Tomorrow is his birthday, and all he wants is some of that East Coast blizzard. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2003

This is the February 20, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.