Add a new section on creating a syslog server and client.
Reviewed by: keramida, remko, rene, pgj
This commit is contained in:
Tom Rhodes
parent
ea68fe73ed
commit
dde7370d73
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=33529
1 changed files with 280 additions and 0 deletions
|
|
@ -71,6 +71,12 @@
|
|||
time server, with the NTP protocol.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>How to configure the standard logging daemon,
|
||||
<command>syslogd</command>, to accept logs from remote
|
||||
hosts.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>Before reading this chapter, you should:</para>
|
||||
|
|
@ -4948,6 +4954,280 @@ driftfile /var/db/ntp.drift</programlisting>
|
|||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="network-syslogd">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Tom</firstname>
|
||||
<surname>Rhodes</surname>
|
||||
<contrib>Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect1info>
|
||||
|
||||
<title>Remote Host Logging with <command>syslogd</command></title>
|
||||
|
||||
<para>Interacting with system logs is a crucial aspect of both
|
||||
security and system administration. Monitoring the log files of
|
||||
multiple hosts can get very unwieldy when these hosts are
|
||||
distributed across medium or large networks, or when they are
|
||||
parts of various different types of networks. In these cases,
|
||||
configuring remote logging may make the whole process a lot more
|
||||
comfortable.</para>
|
||||
|
||||
<para>Centralized logging to a specific logging host can reduce
|
||||
some of the administrative burden of log file administration. Log
|
||||
file aggregation, merging and rotation can be configured in one
|
||||
location, using the native tools of &os;, such as &man.syslogd.8;
|
||||
and &man.newsyslog.8;. In the
|
||||
following example configuration, host <hostid>A</hostid>, named
|
||||
<hostid role="fqdn">logserv.example.com</hostid>, will collect
|
||||
logging information for the local network.
|
||||
Host <hostid>B</hostid>, named
|
||||
<hostid role="fqdn">logclient.example.com</hostid> will pass
|
||||
logging information to the server system. In live
|
||||
configurations, both hosts require proper forward and reverse
|
||||
<acronym>DNS</acronym> or entries in
|
||||
<filename>/etc/hosts</filename>. Otherwise, data will be
|
||||
rejected by the server.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Log Server Configuration</title>
|
||||
|
||||
<para>Log servers are machines configured to accept logging
|
||||
information from remote hosts. In most cases this is to ease
|
||||
configuration, in other cases it may just be a better
|
||||
administration move. Regardless of reason, there are a few
|
||||
requirements before continuing.</para>
|
||||
|
||||
<para>A properly configured logging server has met the following
|
||||
minimal requirements:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The firewall ruleset allows for <acronym>UDP</acronym>
|
||||
to be passed on port 514 on both the client and
|
||||
server;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>syslogd has been configured to accept remote messages
|
||||
from client machines;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The syslogd server and all client machines must have
|
||||
valid entries for both forward and reverse
|
||||
<acronym>DNS</acronym>, or be properly configured in
|
||||
<filename>/etc/hosts</filename>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>To configure the log server, the client must be listed
|
||||
in <filename>/etc/syslog.conf</filename>, and the logging
|
||||
facility must be specified:</para>
|
||||
|
||||
<programlisting>+logclient.example.com
|
||||
*.* /var/log/logclient.log</programlisting>
|
||||
|
||||
<note>
|
||||
<para>More information on various supported and available
|
||||
<emphasis>facilities</emphasis> may be found in the
|
||||
&man.syslog.conf.5; manual page.</para>
|
||||
</note>
|
||||
|
||||
<para>Once added, all <literal>facility</literal> messages will
|
||||
be logged to the file specified previously,
|
||||
<filename>/var/log/logclient.log</filename>.</para>
|
||||
|
||||
<para>Finally, the log file should be created. The method used
|
||||
does not matter, but &man.touch.1; works great for situations
|
||||
such as this:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>touch <filename>/var/log/logclient.log</filename></userinput></screen>
|
||||
|
||||
<para>At this point, the <command>syslogd</command> daemon should
|
||||
be restarted and verified:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput>
|
||||
&prompt.root; <userinput>pgrep syslog</userinput></screen>
|
||||
|
||||
<para>If a <acronym>PID</acronym> is returned, the server has been
|
||||
restarted successfully, and client configuration may begin. If
|
||||
the server has not restarted, consult the
|
||||
<filename>/var/log/messages</filename> log for any
|
||||
output.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Log Client Configuration</title>
|
||||
|
||||
<para>A logging client is a machine which sends log information
|
||||
to a logging server in addition to keeping local copies.</para>
|
||||
|
||||
<para>Similar to log servers, clients must also meet a few minimum
|
||||
requirements.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>&man.syslogd.8; must be configured to send messages of
|
||||
specific types to a log server, which must accept
|
||||
them;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The firewall must allow <acronym>UDP</acronym> packets
|
||||
through on port 512;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Both forward and reverse <acronym>DNS</acronym> must
|
||||
be configured or have proper entries in the
|
||||
<filename>/etc/hosts</filename>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Client configuration is a bit more relaxed when compared
|
||||
to that of the servers. The client machine must also have the
|
||||
following listing placed inside
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>syslogd_enable="YES"
|
||||
syslogd_flags="-a logclient.example.com -vv"</programlisting>
|
||||
|
||||
<para>The first option will enable the <command>syslogd</command>
|
||||
daemon on boot up, and the second line allows data from the
|
||||
client to be accepted on this server. The latter part, using
|
||||
<option>-vv</option>, will increase the verbosity of logged
|
||||
messages. This is extremely useful for tweaking facilities as
|
||||
administrators are able to see what type of messages are being
|
||||
logged under which facility.</para>
|
||||
|
||||
<para>Facilities describe the system part for which a message
|
||||
is generated. For an example, <acronym>ftp</acronym> and
|
||||
<acronym>ipfw</acronym> are both facilities. When log messages
|
||||
are generated for those two services, they will normally include
|
||||
those two utilities in any log messages. Facilities are
|
||||
accompanied with a priority or level, which is used to mark how
|
||||
important a log message is. The most common will be the
|
||||
<literal>warning</literal> and <literal>info</literal>. Please
|
||||
refer to the &man.syslog.3; manual page for a full list of
|
||||
available facilities and priorities.</para>
|
||||
|
||||
<para>The logging server must be defined in the client's
|
||||
<filename>/etc/syslog.conf</filename>. In this instance,
|
||||
the <literal>@</literal> symbol is used to send logging
|
||||
data to a remote server and would look similar to the
|
||||
following entry:</para>
|
||||
|
||||
<programlisting>*.* @logserv.example.com</programlisting>
|
||||
|
||||
<para>Once added, <command>syslogd</command> must be restarted
|
||||
for the changes to take effect:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput></screen>
|
||||
|
||||
<para>To test that log messages are being sent across the network,
|
||||
use &man.logger.1; to send a message to
|
||||
<command>syslogd</command>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>logger "Test message from logclient"</userinput></screen>
|
||||
|
||||
<para>This message should now exist in
|
||||
<filename>/var/log/messages</filename> on both the client
|
||||
and the server.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Debugging Log Servers</title>
|
||||
|
||||
<para>In certain cases, debugging may be required if messages are
|
||||
not being received on the log server. There are several reasons
|
||||
this may occur; however, the most common two are network
|
||||
connection issues and <acronym>DNS</acronym> issues. To test
|
||||
these cases, ensure both hosts are able to reach other
|
||||
using the hostname specified in
|
||||
<filename>/etc/rc.conf</filename>. If this appears to be
|
||||
working properly, an alternation to the
|
||||
<literal>syslogd_flags</literal> option in
|
||||
<filename>/etc/rc.conf</filename> will be required.</para>
|
||||
|
||||
<para>In the following example,
|
||||
<filename>/var/log/logclient.log</filename> is empty, and the
|
||||
<filename>/var/log/messages</filename> files indicate no reason
|
||||
for the failure. To increase debugging output, change the
|
||||
<literal>syslogd_flags</literal> option to look like the
|
||||
following example, and issue a restart:</para>
|
||||
|
||||
<programlisting>syslogd_flags="-d -a logclien.example.com -vv"</programlisting>
|
||||
|
||||
<screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput></screen>
|
||||
|
||||
<para>Debugging data similar to the following will flash on the
|
||||
screen immediately after the restart:</para>
|
||||
|
||||
<screen>logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
|
||||
syslogd: restarted
|
||||
logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
|
||||
Logging to FILE /var/log/messages
|
||||
syslogd: kernel boot file is /boot/kernel/kernel
|
||||
cvthname(192.168.1.10)
|
||||
validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
|
||||
rejected in rule 0 due to name mismatch.</screen>
|
||||
|
||||
<para>It appears obvious the messages are being rejected due
|
||||
to a name mismatch. After reviewing the configuration bit
|
||||
by bit, it appears a typo in the following
|
||||
<filename>/etc/rc.conf</filename> line has an issue:</para>
|
||||
|
||||
<programlisting>syslogd_flags="-d -a logclien.example.com -vv"</programlisting>
|
||||
|
||||
<para>The line should contain <literal>logclient</literal>, not
|
||||
<literal>logclien</literal>. After the proper alterations
|
||||
are made, a restart is issued with expected results:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput>
|
||||
logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
|
||||
syslogd: restarted
|
||||
logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
|
||||
syslogd: kernel boot file is /boot/kernel/kernel
|
||||
logmsg: pri 166, flags 17, from logserv.example.com,
|
||||
msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2
|
||||
cvthname(192.168.1.10)
|
||||
validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
|
||||
accepted in rule 0.
|
||||
logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2
|
||||
Logging to FILE /var/log/logclient.log
|
||||
Logging to FILE /var/log/messages</screen>
|
||||
|
||||
<para>At this point, the messages are being properly received
|
||||
and placed in the correct file.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Security Considerations</title>
|
||||
|
||||
<para>As with any network service, security requirements should
|
||||
be considered before implementing this configuration. At times,
|
||||
log files may contain sensitive data about services enabled on
|
||||
the local host, user accounts, and configuration data. Network
|
||||
data sent from the client to the server will not be encrypted
|
||||
nor password protected. If a need for encryption exists, it
|
||||
might be possible to use
|
||||
<filename role="package">security/stunnel</filename>, which
|
||||
will transmit data over an encrypted tunnel.</para>
|
||||
|
||||
<para>Local security is also an issue. Log files are not
|
||||
encrypted during use or after log rotation. Local users may
|
||||
access these files to gain additional insight on system
|
||||
configuration. In those cases, setting proper permissions
|
||||
on these files will be critical. The &man.newsyslog.8;
|
||||
utility supports setting permissions on newly created and
|
||||
rotated log files. Setting log files to mode
|
||||
<literal>600</literal> should prevent any unwanted snooping
|
||||
by local users.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
|
|
|
|||
Loading…
Reference in a new issue