Each element in the list on the selector overrides previous elements. It is thus possible to restrict a set or to exclude certain elements from it. For example, kern.info;kern.!err means messages from the kernel with priority between info and warn. The none priority indicates the empty set (no priorities), and may serve to exclude a subsystem from a set of messages. Thus, *.crit;kern.none indicates all the messages of priority equal to or higher than crit not coming from the kernel.
9.5.2.2. Syntax of Actions
BACK TO BASICS The named pipe, a persistent pipe
A named pipe is a particular type of file that operates like a traditional pipe (the pipe that you make with the “|” symbol on the command line), but via a file. This mechanism has the advantage of being able to relate two unrelated processes. Anything written to a named pipe blocks the process that writes until another process attempts to read the data written. This second process reads the data written by the first, which can then resume execution.
Such a file is created with the mkfifo command.
The various possible actions are:
add the message to a file (example: /var/log/messages);
send the message to a remote syslog server (example: @log.falcot.com);
send the message to an existing named pipe (example: |/dev/xconsole);
send the message to one or more users, if they are logged in (example: root,rhertzog);
send the message to all logged in users (example: *);
write the message in a text console (example: /dev/tty8).
SECURITY Forwarding logs
It is a good idea to record the most important logs on a separate machine (perhaps dedicated for this purpose), since this will prevent any possible intruder from removing traces of their intrusion (unless, of course, they also compromise this other server). Furthermore, in the event of a major problem (such as a kernel crash), you have the logs available on another machine, which increases your chances of determining the sequence of events that caused the crash.
To accept log messages sent by other machines, you must reconfigure rsyslog: in practice, it is sufficient to activate the ready-for-use entries in /etc/rsyslog.conf ($ModLoad imudp and $UDPServerRun 514).
9.6. The inetd Super-Server
Inetd (often called “Internet super-server”) is a server of servers. It executes rarely used servers on demand, so that they do not have to run continuously.
The /etc/inetd.conf file lists these servers and their usual ports. The inetd command listens to all of them; when it detects a connection to any such port, it executes the corresponding server program.
DEBIAN POLICY Register a server in inetd.conf
Packages frequently want to register a new server in the /etc/inetd.conf file, but Debian Policy prohibits any package from modifying a configuration file that it doesn't own. This is why the updated-inetd script (in the package with the same name) was created: It manages the configuration file, and other packages can thus use it to register a new server to the super-server's configuration.
Each significant line of the /etc/inetd.conf file describes a server through seven fields (separated by spaces):
The TCP or UDP port number, or the service name (which is mapped to a standard port number with the information contained in the /etc/services file).
The socket type: stream for a TCP connection, dgram for UDP datagrams.
The protococlass="underline" tcp or udp.
The options: two possible values: wait or nowait, to tell inetd whether it should wait or not for the end of the launched process before accepting another connection. For TCP connections, easily multiplexable, you can usually use nowait. For programs responding over UDP, you should use nowait only if the server is capable of managing several connections in parallel. You can suffix this field with a period, followed by the maximum number of connections authorized per minute (the default limit is 40).
The user name of the user under whose identity the server will run.
The full path to the server program to execute.
The arguments: this is a complete list of the program's arguments, including its own name (argv[0] in C).
The following example illustrates the most common cases:
Example 9.1. Excerpt from /etc/inetd.conf
talk dgram udp wait nobody.tty /usr/sbin/in.talkd in.talkd
finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd
ident stream tcp nowait nobody /usr/sbin/identd identd -i
The tcpd program is frequently used in the /etc/inetd.conf file. It allows limiting incoming connections by applying access control rules, documented in the hosts_access(5) manual page, and which are configured in the /etc/hosts.allow and /etc/hosts.deny files. Once it has been determined that the connection is authorized, tcpd executes the real server (like /usr/bin/in.fingerd in our example).
COMMUNITY Wietse Venema
Wietse Venema, whose expertise in security has made him a renowned programmer, is the author of the tcpd program. He is also the main creator of Postfix, the modular e-mail server (SMTP, Simple Mail Transfer Protocol), designed to be safer and more reliable than sendmail, which features a long history of security vulnerabilities.
ALTERNATIVE Other inetd commands
There is no lack of alternatives. In addition to openbsd-inetd and netkit-inetd already mentioned, there are inetutils-inetd, micro-inetd, rlinetd and xinetd.
This last incarnation of a super-server offers very interesting possibilities. Most notably, its configuration can be split into several files (stored, of course, in the /etc/xinetd.d/ directory), which can make an administrator's life easier.
9.7. Scheduling Tasks with cron and atd
cron is the daemon responsible for executing scheduled and recurring commands (every day, every week, etc.); atd is that which deals with commands to be executed a single time, but at a specific moment in the future.
In a Unix system, many tasks are scheduled for regular execution:
rotating the logs;
updating the database for the locate program;
back-ups;
maintenance scripts (such as cleaning out temporary files).
By default, all users can schedule the execution of tasks. Each user has thus their own crontab in which they can record scheduled commands. It can be edited by running crontab -e (its content is stored in the /var/spool/cron/crontabs/user file).
SECURITY Restricting cron or atd
You can restrict access to cron by creating an explicit authorization file (whitelist) in /etc/cron.allow, in which you indicate the only users authorized to schedule commands. All others will automatically be deprived of this feature. Conversely, to only block one or two troublemakers, you could write their username in the explicit prohibition file (blacklist), /etc/cron.deny. This same feature is available for atd, with the /etc/at.allow and /etc/at.deny files.