Excellent! Easy to read, provides quality material, must have for each system administrator!

Anyone seeking to set up any manner of internet service would be well advised to start here.

A must-have book for Linux Admins, and a should have book for Unix admins.

Linux consistently turns up high in the list of popular Internet servers, whether it's for the Web, anonymous FTP, or general services like DNS and routing mail. But security is uppermost on the mind 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.

As the cost of broadband and other high-speed Internet connectivity has gone down, and its availability has increased, more Linux users are providing or considering providing Internet services such as HTTP, Anonymous FTP, etc., to the world at large. At the same time, some important, powerful, and popular Open Source tools have emerged and rapidly matured--some of which rival expensive commercial equivalents--making Linux a particularly appropriate platform for providing secure Internet services.

Building Secure Servers with Linux will help you master the principles of reliable system and network security by combining 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 larger Internet--and shows readers how to harden their hosts against attacks. Author Mick Bauer, a security consultant, network architect, and lead author of the popular Paranoid Penguin column in Linux Journal, carefully outlines the security risks, defines precautions that can minimize those risks, and offers recipes for robust security. The book does not cover firewalls, but covers the more common situation where an organization protects its hub using other systems as firewalls, often proprietary firewalls.

The book includes:

Precise directions for securing common services, including the Web, mail, DNS, and file transfer.

Ancillary tasks, such as hardening Linux, using SSH and certificates for tunneling, and using iptables for firewalling.

Basic installation of intrusion detection tools.

Writing for Linux users with little security expertise, the author explains security concepts and techniques in clear language, beginning with the fundamentals. Building Secure Servers with Linux provides a unique balance of "big picture" principles that transcend specific software packages and version numbers, and very clear procedures on securing some of those software packages. An all-inclusive resource for Linux users who wish to harden their systems, the book covers general security as well as key services such as DNS, the Apache Web server, mail, file transfer, and secure shell. With this book in hand, you'll have everything you need to ensure robust security of your Linux system.

This text should help you master the principles of reliable system and network security by combining practical advice with a firm knowledge of the tech nical 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 larger Internet--and shows readers how to harden their hosts against attacks. Author Mick Bauer, a security consultant, network architect, and lead author of the popular Paranoid Penguin column in Linux Journal, carefully outlines the security risks, defines precautions that can minimize those risks, and offers recipes for robust security. The book does not cover firewalls, but covers the more common situation where an organization protects its hub using other systems as firewalls, often proprietary firewalls. The book includes: precise directions for securing common services, including the Web, mail, DNS, and file transfer. Ancillary tasks, such as hardening Linux, using SSH and certificates for tunnelling, and using iptables for firewalling. Basic installation of intrusion detection tools.

Writing for Linux users with little security expertise, the author explains security concepts and techniques in clear language, beginning with the fundamentals. "Building Secure Servers with Linux"provides a balance of "big picture" principles that transcend specific software packages and version numbers, and very clear procedures on securing some of those software packages. An all-inclusive resource for Linux users who wish to harden their systems, the book covers general security as well as key services such as DNS, the Apache Web server, mail, file transfer, and secure shell. With this book in hand, you'll have everything you need to ensure robust security of your Linux system.

This book provides a unique balance of "big picture" principles that transcend specific software packages and version numbers, and very clear procedures on securing some of those software packages. An all-inclusive resource for Linux users who wish to harden their systems, the book covers general security as well as key services such as DNS, the Apache Web server, mail, file transfer, and secure shell.

CHAPTER 10 - 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 us troubleshoot virtually 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.

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.

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 10-1,mail. notice is the selector and /var/log/mail is the action (i.e.,"write messages to /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:

Example 10-1. Sample syslog.conf line
mail. notice /var/log/mail 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.

ocal7
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 . "

Actions
In practice,most log messages are written to files. If you list the full path to a file-name as a line?s action in syslog. conf, messages that match that line will be appended to that file. (If the file doesn?t exist,syslog will create it.) In Example 10-1, we instructed syslog to send matched messages to the file /var/log/mail.

You can send messages other places too. An action can be a file, a named pipe, a device file,a remote host,or a user?s screen. Pipes are usually used for debugging. Device files that people use are usually TTYs. Some people also like to send security information to /dev/lp0 ?i.e., to a local line printer. Logs that have been printed out can?t be erased or altered by an intruder,but they also are subject to mechanical problems (paper jams, inkdepletion, etc.) and are harder to parse if you need to find something in a hurry.

Remote logging is one of the most useful features of syslog. If you specify a host-name or IP address preceded by an @sign as a line?s action, messages that match that line will be sent to UDP port 514 on that remote host. For example, the line:

*.emerg @mothership.mydomain.org

will send all messages with emerg priority to UDP port 514 on the host named mothership.mydomain.org . Note that the remote host?s (in this example, mothership?s )syslogd process will need to have been started with the -r flag for it to accept your log messages. By default, syslogd does not accept messages from remote systems.

2004-07-08 Superb tutorial and reference

I have used this book for over a year, and return to it regularly, despite having many other Linux books. Covers most of what you need to know to set up a server with firewall, e-mail (postfix and sendmail), Apache, and FTP. The coverage of remote administration with SSH is excellent, and there are also useful sections on tripwire (intrusion detection), log management, and general security concepts. It does not cover installing Linux or getting TCP/IP going, but it's simply the best book I have seen for setting up a Linux server once the basic Linux installation is done. Highly recommended!