syslog Configuration

Making sure your system processes and critical applications log the events and states you're interested in with syslog.

Running syslogd

Just as the default syslog.conf may not meet your needs, the
default startup mode of syslogd may need tweaking. Table 2 and
subsequent paragraphs touch on some syslogd startup flags that are
particularly relevant to security, but for a complete list you
should refer to the man page sysklogd(8).

In addition, note that when you're changing and testing
syslog's configuration and startup options, it usually makes sense
to start and stop syslogd and klogd in tandem (see the Sidebar
“What about klogd?” if you don't know what klogd is). Since it
also makes sense to start and stop these the same way your system
does, I recommend that you use your system's syslogd/klogd startup
script.

On most Linux systems this startup script is either in
/etc/init.d/syslog or /etc/init.d/sysklog (sysklog is shorthand for
“syslog and klogd”).

The first syslogd flag we'll discuss is the only one used by
default by Red Hat 7.x in its /etc/init.d/syslog script: -m 0,
which disables mark messages. These messages contain only a
timestamp and the string “--MARK--”, which some people find
useful for navigating lengthy log files. Others find them
distracting and redundant, given that each message has its own
timestamp anyhow.

To turn mark messages on, specify a positive nonzero value
after -m that tells syslogd how many minutes should pass before it
sends itself a mark message. Remember that mark has its own
facility called, predictably, mark, and you must specify at least
one selector that matches mark messages (such as mark.*, which
matches all messages sent to the mark facility, or *.*, which
matches all messages in all facilities).

For example, to make syslogd generate mark messages every 30
minutes and record them in /var/log/messages, you first would add a
line to /etc/syslog.conf similar to

mark.* -/var/log/messages

You would then need to start syslogd as shown here:

mylinuxbox:/etc/init.d# ./syslogd -m 30

Another useful syslogd flag is -a [socket].
This allows you to specify one or more sockets in addition to
/dev/log for syslogd to accept messages from.

If you've ever secured a nameserver running BIND, you may
have used -a to allow a chroot-ed named process to bounce its
messages from a dev/log device file in the chroot jail to the
non-chroot-ed syslogd process. In such a case, since named can't
access /dev/log, it has its own, for example, /var/named/dev/log.
You therefore need a line in /etc/init.d/syslog like this:

daemon syslogd -m 0 -a /var/named/dev/log

Note that the dæmon function at the beginning of this
line is unique to Red Hat's init script functions; the important
part here is

Continuing down the list of flags in Table 2, suppose you need to
test a new syslog configuration file named syslog.conf.test but
prefer not to overwrite /etc/syslog.conf, which is where syslogd
looks for its configuration file by default. Use the -f flag to
tell syslogd to use your new configuration file:

mylinuxbox:/etc/init.d# ./syslogd -f ./syslog.conf.test

We've already covered use of the -r flag, which tells syslogd to
accept log messages from remote hosts, but we haven't talked about
the security ramifications. On the one hand, security clearly is
enhanced when you use a centralized logserver or do (almost)
anything else that makes it easier for you to manage and monitor
your logs.

On the other hand, you must take different threat models into
account. Are your logs sensitive? If log messages traverse any
untrusted network, and if the inner workings of the servers that
send those messages are best kept secret, then in fact the risks
may outweigh the benefit (at least, the specific benefit of
syslogd's unauthenticated clear-text remote logging
mechanism).

If this is the case for you, you definitely should consider
using syslog-ng. syslog-ng can
send remote messages via the TCP protocol and therefore can be used
in conjunction with stunnel, ssh and other tools that greatly can
enhance its security. Since syslog uses only the connectionless UDP
protocol for remote logging and, therefore, can't tunnel its
messages though stunnel or ssh, syslog is inherently less securable
than syslog-ng.

If your log messages aren't sensitive (at least, the ones you
send to a remote logger), then there's still the problem of
denial-of-service and message-forgery attacks. If you invoke
syslogd with the -r flag, it will accept all remote messages
without performing any checks whatsoever on the validity of the
messages themselves or on their senders. Again, this risk is most
effectively mitigated by using syslog-ng.

One tool you can use with syslog to mitigate partially the
risk of invalid remote messages is TCPwrappers. Specifically,
TCPwrappers' hosts-access authentication mechanism provides a
simple means of defining which hosts may connect, via which
protocols, to your logserver. Hosts-access authentication is
tricked easily by source-IP spoofing (especially since syslog
transactions are strictly one-way), but it's better than nothing
and is probably sufficient to prevent mischievous but lazy
attackers from interfering with syslog.

If you're willing to bet that it is, obtain and install
TCPwrappers (all modern Linux distributions have a binary package
of it; some even install it by default), and refer to its
hosts_access(5) man page for details. Note that despite its name,
TCPwrappers' hosts access can be used to control UDP-based
applications.

Geek Guides

Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.