Preventing Syslog Denial of Service attacks.

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  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 
security () onsight com

--------------------------------------------------------------------

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 brian () hackinglinuxexposed com.

--------------------------------------------------------------------
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-request () lists onsight com.

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 majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.