Preventing Syslog Denial of Service attacks.

Guys, just read the following article



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...