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
You would then need to start syslogd as shown here:
mylinuxbox:/etc/init.d# ./syslogd -m 30Another 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
syslogd -m 0 -a /var/named/dev/logMore than one -a flag may be specified, like this:
syslogd -a /var/named/dev/log -a /var/otherchroot/dev/log -a /additional/dev/logContinuing 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.testWe'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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide