[ISN] Preventing Syslog Denial of Service attacks.

From: InfoSec News (isnat_private)
Date: Fri Feb 21 2003 - 02:54:46 PST

  • Next message: InfoSec News: "[ISN] New HIPAA security rules could open door to litigation"

    |  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 
    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
    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  *     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.
        Most system logging daemons listen on one or more unix sockets[2]
        , the most typical being /dev/log:
          # lsof -c syslogd | egrep "unix|PID"
          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
          while :
              logger -p daemon.emerg "Whoa - catastrophic emergency!"
          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 port 2003
          sshd: Failed password for cracker from 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.)
    [1] Syslogd does not support TCP, but Syslog-ng does. Syslog-ng
    supports a lot of great features not available in the near-ancient
    [2] Unix sockets are just special files that can be connected to
    processes, rather than the disk itself. They're similar to filesystem
    [3] And for some reason you can't lock out their accounts and fire
    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
    Archives of this and previous newsletters are available at
    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