217
Unfortunately, many services traditionally dont do logging, either through the syslog facility or otherwise. If these services are started by inetd, you have a couple of alternatives.
Some implementations of inetd have options that will allow connection logging. That is, each time a connection is made to one of these services, the connection is logged. With inetd on Solaris, the -t
option traces all connections. On FreeBSD, the -l option records all successful connections. The problem with this approach is that it is rather indiscriminate.
One alternative is to replace inetd with Panos Tsirigotiss xinetd. xinetd is an expanded version of inetd that greatly expands inetd s functionality, particularly with respect to logging. Another program to
consider is tcpwrappers.
11.2.3.1 tcpwrappers
The tcpwrappers program was developed to provide additional security, including logging. Written by Wietse Venema, a well-respected security expert, tcpwrappers is a small program that sits between
inetd or inetd-like programs and the services started by inetd. When a service is requested, inetd calls the wrapper program, tcpd, which checks permission files, logs its actions, and then, if
appropriate, starts the service. For example, if you want to control access to telnet, you might change the line in etcinetd.conf that starts the telnet daemon from:
telnet stream tcp nowait root usrlibexectelnetd telnetd
to:
telnet stream tcp nowait root usrsbintcpd telnetd
Now, the wrapper daemon tcpd is started initially instead of telnetd, the telnet daemon. Youll need to make similar changes for each service you want to control. If the service is not where tcpd expects it,
you can give an absolute path as an argument to tcpd in the configuration file.
Actually, there is an alternative way of configuring tcpwrappers. You can leave the inetd configuration file alone, move each service to a new location,
and replace the service at its default location with tcpd. I strongly discourage this approach as it can create maintenance problems, particularly when you
upgrade your system.
As noted, tcpwrappers is typically used for two functions—logging and access control.
[2]
Logging is done through syslog. The particular facility used will depend on how tcpwrappers is compiled.
Typically, mail or local2 is used. You will need to edit etcsyslog.conf and recompile tcpwrappers if you want to change how logging is recorded.
[2]
tcpwrappers provides additional functionality not described here, such as login banners.
Access is typically controlled through the file etchosts.allow, though some systems may also have an etchosts.deny file. These files specify which systems can access which services. These are a few
potential rules based on the example configuration:
ALL : localhost : allow sendmail : nice.guy.example.com : allow
sendmail : .evil.cracker.example.com : deny
218
sendmail : ALL : allow
tcpwrappers uses a first match wins approach. The first rule allows all services from the local machine without further testing. The next three rules control the sendmail program. The first rule allows a
specific host, nice.guy.example.com. All hosts on the domain .evil.cracker.example.com are blocked. Note the leading dot. Finally, all other hosts are permitted to use sendmail.
There are a number of other forms for rules that are permitted, but these are all pretty straightforward. The distribution comes with a very nice example file. But, should you have problems, tcpwrappers
comes with two utilities for testing configuration files. tcpdchk looks for general syntax errors within the file. tcpdmatch can be used to check how tcpd will respond to a specific action. Kudos to Venema
for including these
The primary limitation to tcpwrappers is that, since it disappears after it starts the target service, its control is limited to the brief period while it is running. It provides no protection from attacks that
begin after that point.
tcpwrappers is a ubiquitous program. In fact, it is installed by default on many Linux systems. Incidentally, some versions of inetd now have wrappers technology built-in. Be sure to review your
documentation.
11.3 NTP
One problem with logging events over a network is that differences in system clocks can make correlating events on different systems very difficult. It is not unusual for the clock on a system to
have drifted considerably. Thus, there may be discrepancies among timestamps for the same events listed in different log files. Fortunately, there is a protocol you can use to synchronize the clocks on
your system.
Network Time Protocol NTP provides a mechanism so that one system can compare and adjust its clock to match another systems clock. Ideally, you should have access to a very accurate clock as
your starting point. In practice, you will have three choices. The best choice is an authoritative reference clock. These devices range from atomic clocks to time servers that set their clocks based on
time signals from radios or GPS satellites.
The next best source is from a system that gets its clock setting from one of these reference clocks. Such systems are referred to as stratum 1 servers. If you cant get your signal from a stratum 1 server,
the next best choice is to get it from a system that does, a stratum 2 server. As you might guess, there is a whole hierarchy of servers with the stratum number incrementing with each step you take away
from a reference clock. There are public time servers available on the Internet with fairly low stratum numbers that you can coordinate to occasionally, but courtesy dictates that you ask before using these
systems.
Finally, if you are not attached to the Internet, you can elect to simply designate one of your systems as the master system and coordinate all your other systems to that system. Your clocks wont be very
accurate, but they will be fairly consistent, and you will be able to compare system logs.
NTP works in one of several ways. You can set up a server to broadcast time messages periodically. Clients then listen for these broadcasts and adjust their clocks accordingly. Alternately, the server can
