Items related to Linux Server Security
Synopsis
Linux consistently appears high up in the list of popular Internet servers, whether it's for the Web, anonymous FTP, or general services such as DNS and delivering mail. But security is the foremost concern of anyone providing such a service. Any server experiences casual probe attempts dozens of time a day, and serious break-in attempts with some frequency as well.This highly regarded book, originally titled Building Secure Servers with Linux, combines practical advice with a firm knowledge of the technical tools needed to ensure security. The book focuses on the most common use of Linux--as a hub offering services to an organization or the Internet--and shows readers how to harden their hosts against attacks. An all-inclusive resource for Linux users who wish to harden their systems, Linux Server Security covers general security such as intrusion detection and firewalling a hub, as well as key services such as DNS, the Apache Web server, mail, and secure shell.Author Michael D. Bauer, a security consultant, network architect, and lead author of the popular Paranoid Penguin column in the Linux Journal, carefully outlines the security risks, defines precautions that can minimize those risks, and offers recipes for robust security. He is joined on several chapters by administrator and developer Bill Lubanovic.A number of new security topics have been added for this edition, including:
- Database security, with a focus on MySQL
- Using OpenLDAP for authentication
- An introduction to email encryption
- The Cyrus IMAP service, a popular mail delivery agent
- The vsftpd FTP server
"synopsis" may belong to another edition of this title.
About the Author
Michael D. (Mick) Bauer, CISSP, is Network Security Architect for alarge financial services provider. He is also Security Editor forLinux Journal Magazine, and author of its monthly "Paranoid Penguin" security column. Mick's areas of expertise include Linux security and general Unix security, network (TCP/IP) security, security assessment, and the development of security policies and awareness programs.
Excerpt. © Reprinted by permission. All rights reserved.
CHAPTER 12 System Log Management and Monitoring
Whatever else you do to secure a Linux system, it must have comprehensive, accurate, and carefully watched logs. Logs serve several purposes. First, they help to troubleshoot all kinds of system and application problems. Second, they provide valuable early warning signs of system abuse. Third, after all else fails (whether that means a system crash or a system compromise), logs can provide us with crucial forensic data.
This chapter is about making sure your system processes and critical applications log the events and states you’re interested in and dealing with this data once it’s been logged. The two logging tools we’ll cover are syslog and the more powerful Syslog-ng ("syslog new generation"). In the monitoring arena, we’ll discuss Swatch (the Simple Watcher), a powerful Perl script that monitors logs in real time and takes action on specified events, plus a few "offline" log-reporting tools.
syslog
syslog is the tried-and-true workhorse of Unix logging utilities. It accepts log data from the kernel (by way of klogd), from any and all local process, and even from processes on remote systems. It’s flexible as well, allowing you to determine what gets logged and where it gets logged to.
A preconfigured syslog installation is part of the base operating system in virtually all variants of Unix and Linux. However, relatively few system administrators customize it to log the things that are important for their environment and disregard the things that aren’t. Since, as few would dispute, information overload is one of the major challenges of system administration, this is unfortunate. Therefore, we begin this chapter with a comprehensive discussion of how to customize and use syslog.
What About klogd?
One daemon you probably won’t need to reconfigure but should still be aware of is klogd, Linux’s kernel log daemon. This daemon is started automatically at boot time by the same script that starts the general system logger (probably /etc/init.d/syslogd or /etc/init.d/sysklogd, depending on which Linux distribution you use).
By default, klogd directs log messages from the kernel to the system logger, which is why most people don’t need to worry about klogd: you can control the handling of kernel messages by editing the configuration file for syslogd.
This is also true if you use Syslog-ng instead of syslog, but since Syslog-ng accepts messages from a much wider variety of sources, including /proc/kmsg (which is where klogd receives its messages), some Syslog-ng users prefer to disable klogd. Don’t do so yourself unless you first configure Syslog-ng to use /proc/kmsg as a source.
klogd can be invoked as a standalone logger; that is, it can send kernel messages directly to consoles or a logfile. In addition, if it isn’t already running as a daemon, klogd can be used to dump the contents of the kernel log buffers (i.e., the most recent kernel messages) to a file or to the screen. These applications of klogd are especially useful to kernel developers.
For most of us, it’s enough to know that for normal system operations, klogd can be safely left alone (that is, left with default settings and startup options—not disabled). Just remember that when you use syslog in Linux, all kernel messages are handled by klogd first.
Configuring syslog
Whenever syslogd, the syslog daemon, receives a log message, it acts based on the message’s type (or "facility") and its priority. syslog’s mapping of actions to facilities and priorities is specified in /etc/syslog.conf. Each line in this file specifies one or more facility/priority selectors followed by an action; a selector consists of a facility or facilities and a (single) priority.
In the following syslog.conf line in Example 12-1, mail.notice is the selector and /var/log/mail is the action (i.e., "write messages to /var/log/mail").
Example 12-1. Sample syslog.conf line
mail.notice /var/log/mail
Within the selector, mail is the facility (message category) and notice is the level of priority.
Facilities
Facilities are simply categories. Supported facilities in Linux are auth, auth-priv, cron, daemon, kern, lpr, mail, mark, news, syslog, user, uucp, and local0 through local7. Some of these are self-explanatory, but the following are of special note:
auth
Used for many security events.
auth-priv
Used for access-control-related messages.
daemon
Used by system processes and other daemons.
kern
Used for kernel messages.
mark
Messages generated by syslogd itself, which contain only a timestamp and the string --MARK--; to specify how many minutes should transpire between marks, invoke syslogd with the -m [minutes] flag.
user
The default facility when none is specified by an application or in a selector.
local4
The default facility for OpenLDAP daemon (slapd) messages.
local6
The default facility for Cyrus Imapd messages.
local7
Boot messages.
*
Wildcard signifying "any facility."
none
Wildcard signifying "no facility."
Priorities
Unlike facilities, which have no relationship to each other, priorities are hierarchical. Possible priorities in Linux are (in increasing order of urgency): debug, info, notice, warning, err, crit, alert, and emerg. Note that the "urgency" of a given message is determined by the programmer who wrote it; facility and priority are set by the programs that generate messages, not by syslog.
As with facilities, the wildcards * and none may also be used. Only one priority or wildcard may be specified per selector. A priority may be preceded by either or both of the modifiers, = and !
If you specify a single priority in a selector (without modifiers), you’re actually specifying that priority plus all higher priorities. Thus the selector mail.notice translates to "all mail-related messages having a priority of notice or higher," i.e., having a priority of notice, warning, err, crit, alert, or emerg.
You can specify a single priority by prefixing a = to it. The selector mail.=notice translates to "all mail-related messages having a priority of notice." Priorities may also be negated: mail.!notice is equivalent to "all mail messages except those with priority of notice or higher," and mail.!=notice corresponds to "all mail messages except those with the priority notice."
"About this title" may belong to another edition of this title.
- ISBN 10 1600330363
- ISBN 13 9781600330360
- BindingPaperback
- LanguageEnglish
(No Available Copies)
Search Books: Create a WantCan't find the book you're looking for? We'll keep searching for you. If one of our booksellers adds it to AbeBooks, we'll let you know!
Create a Want
