+------------------------------------------------------------------+ | Linux Security: Tips, Tricks, and Hackery | | Published by Onsight, Inc. | | | | 20-February-2003 | | http://www.hackinglinuxexposed.com/articles/20030220.html | +------------------------------------------------------------------+ This issue sponsored by Onsight, your Security Solution. Onsight, Inc is a consulting firm specializing in network security. Our network consultants have extensive experience in host security for all Unix flavours, from Solaris and *BSD to HP-UX and Irix. We can provide custom firewall solutions, Intrusion Detection systems, assist in log monitoring and analysis, and clean up your systems after successful cracker intrusions. Of course, our speciality is Linux security and systems - we wrote the book on it: Hacking Linux Exposed. If you want to protect your Unix network from crackers, you want to talk to us. For more information, see http://www.onsight.com or email securityat_private -------------------------------------------------------------------- Preventing Syslog Denial of Service attacks. By Brian Hatch 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... ------------- Brian 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. Brian can be reached at brianat_private -------------------------------------------------------------------- This newsletter is distributed by Onsight, Inc. The list is managed with MailMan (http://www.list.org). You can subscribe, unsubscribe, or change your password by visiting http://lists.onsight.com/ or by sending email to linux_security-requestat_private Archives of this and previous newsletters are available at http://www.hackinglinuxexposed.com/articles/ -------------------------------------------------------------------- Copyright 2003, Brian Hatch. - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Fri Feb 21 2003 - 05:18:12 PST