summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat
-rw-r--r--ChangeLog10
-rw-r--r--doc/Makefile.am1
-rw-r--r--doc/features.html35
-rw-r--r--doc/manual.html2
-rw-r--r--doc/rsyslog_ng_comparison.html33
-rw-r--r--doc/rsyslog_stunnel.html488
-rw-r--r--doc/rsyslog_tls.html170
-rw-r--r--doc/status.html14
-rw-r--r--plugins/imklog/ksym.c65
-rw-r--r--plugins/imklog/ksym_mod.c1
-rw-r--r--plugins/imklog/linux.c7
-rw-r--r--runtime/cfsysline.c4
-rw-r--r--runtime/ctok.c2
-rw-r--r--runtime/linkedlist.c2
-rw-r--r--runtime/sysvar.c2
-rw-r--r--tools/syslogd.c18
16 files changed, 519 insertions, 335 deletions
diff --git a/ChangeLog b/ChangeLog
index 71766d1d..6f73db81 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -10,9 +10,12 @@ Version 3.19.0 (rgerhards), 2008-04-??
runtime
- changed directory structure, files are now better organized
- a lot of cleanup in regard to modularization
+- -c option no longer must be the first option - thanks to varmjofekoj
+ for the patch
---------------------------------------------------------------------------
Version 3.17.2 (rgerhards), 2008-04-??
- this version is the new beta
+- merged in imklog bug fix from v3-stable (3.16.1)
---------------------------------------------------------------------------
Version 3.17.1 (rgerhards), 2008-04-15
- removed dependency on MAXHOSTNAMELEN as much as it made sense.
@@ -65,7 +68,12 @@ Version 3.17.0 (rgerhards), 2008-04-08
Plus a number of bugfixes that were applied to v3-stable and beta
branches (not mentioned here in detail).
---------------------------------------------------------------------------
-Version 3.16.0 (rgerhards), 2008-04-??
+Version 3.16.1 (rgerhards), 2008-05-02
+- fixed a bug in imklog which lead to startup problems (including
+ segfault) on some platforms under some circumsances. Thanks to
+ Vieri for reporting this bug and helping to troubleshoot it.
+---------------------------------------------------------------------------
+Version 3.16.0 (rgerhards), 2008-04-24
- new v3-stable (3.16.x) based on beta 3.15.x (RELP support)
- bugfix: omsnmp had a too-small sized buffer for hostname+port. This
could not lead to a segfault, as snprintf() was used, but could cause
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 0b3f9da2..da2e2328 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -21,6 +21,7 @@ html_files = \
rsyslog_high_database_rate.html \
rsyslog_php_syslog_ng.html \
rsyslog_recording_pri.html \
+ rsyslog_tls.html \
rsyslog_stunnel.html \
syslog-protocol.html \
version_naming.html \
diff --git a/doc/features.html b/doc/features.html
index f9d17818..9fbebedf 100644
--- a/doc/features.html
+++ b/doc/features.html
@@ -1,5 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html><head><title>rsyslog features</title></head>
+<html><head><title>rsyslog features</title>
+
+</head>
<body>
<h1>RSyslog - Features</h1>
<p><b>This page lists both current features as well as
@@ -23,13 +25,18 @@ to MySQL databases</a></li>
<li> native support for writing to Postgres databases</li>
<li>direct support for Firebird/Interbase,
OpenTDS (MS SQL, Sybase), SQLLite, Ingres, Oracle, and mSQL via libdbi,
-a database abstraction layer (almost as good as native)</li><li>native support for <a href="ommail.html">sending mail messages</a> (first seen in 3.17.0)</li>
+a database abstraction layer (almost as good as native)</li>
+<li>native support for <a href="ommail.html">sending
+mail messages</a> (first seen in 3.17.0)</li>
<li>support for (plain) tcp based syslog - much better
reliability</li>
<li>support for sending and receiving compressed syslog messages</li>
<li>support for on-demand on-disk spooling of messages that can
not be processed fast enough (a great feature for <a href="rsyslog_high_database_rate.html">writing massive
-amounts of syslog messages to a database</a>)</li><li>support for selectively <a href="http://wiki.rsyslog.com/index.php/OffPeakHours">processing messages only during specific timeframes</a> and spooling them to disk otherwise</li>
+amounts of syslog messages to a database</a>)</li>
+<li>support for selectively <a href="http://wiki.rsyslog.com/index.php/OffPeakHours">processing
+messages only during specific timeframes</a> and spooling them to
+disk otherwise</li>
<li>ability to monitor text files and convert their contents
into syslog messages (one per line)</li>
<li>ability to configure backup syslog/database servers - if
@@ -49,8 +56,9 @@ substrings</li>
command execution</li>
<li>support for running multiple rsyslogd instances on a single
machine</li>
-<li>support for <a href="rsyslog_stunnel.html">
-ssl-protected syslog</a> (via stunnel)</li>
+<li>support for <a href="rsyslog_tls.html">TLS-protected
+syslog</a> (both <a href="rsyslog_tls.html">natively</a>
+and via <a href="rsyslog_stunnel.html">stunnel</a>)</li>
<li>ability to filter on any part of the message, not just
facility and severity</li>
<li>ability to use regular expressions in filters</li>
@@ -70,8 +78,7 @@ high log volume on multicore machines)</li>
compliant messages (it is volatile because standardization is currently
underway and this is a proof-of-concept implementation to aid this
effort)</li>
-<li> experimental support for syslog-transport-tls based
-framing on syslog/tcp connections</li>
+<li> world's first implementation of syslog-transport-tls</li>
<li> the sysklogd's klogd functionality is implemented as the <i>imklog</i>
input plug-in. So rsyslog is a full replacement for the sysklogd package</li>
<li> support for IPv6</li>
@@ -90,7 +97,13 @@ via custom plugins</li>
<li>support for arbitrary complex boolean, string and
arithmetic expressions in message filters</li>
</ul>
-<p>&nbsp;</p>
+<h2>World's first</h2>
+Rsyslog has an interesting number of "world's firsts" - things that
+were implemented for the first time ever in rsyslog. Some of them are still features not available elsewhere.<br><ul>
+<li>world's first implementation of IETF I-D syslog-protocol (February 2006, version 1.12.2 and above)</li><li>world's first implementation of dynamic syslog on-the-wire compression (Deceber 2006, version 1.13.0 and above)</li><li>world's first open-source implementation of a disk-queueing syslogd (January 2008, version 3.11.0 and above)</li>
+<li>world's first implementation of IETF I-D
+syslog-transport-tls (May 2008, version 3.19.0 and above)</li>
+</ul>
<h2>Upcoming Features</h2>
<p>The list below is something like a repository of ideas we'd
like to implement. Features on this list are typically NOT scheduled
@@ -105,11 +118,9 @@ to the bugzilla tracker.</p>
<ul>
<li>port it to more *nix variants (eg AIX and HP UX) - this
needs volunteers with access to those machines and knowledge </li>
-<li>support for native SSL enryption of plain tcp syslog
-sessions. This will most probably happen based on syslog-transport-tls.</li>
<li>pcre filtering - maybe (depending on feedback)&nbsp; -
simple regex already partly added. So far, this seems sufficient so
-that there is no urgent need to do pcre</li>
+that there is no urgent need to do pcre. If done, it will be a loadable RainerScript function.</li>
<li>support for <a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">RFC
3195</a> as a sender - this is currently unlikely to happen,
because there is no real demand for it. Any work on RFC 3195 has been
@@ -122,4 +133,4 @@ future of RFC 3195 in rsyslog</a>.</li>
<p>To see when each feature was added, see the
<a href="http://www.rsyslog.com/Topic4.phtml">rsyslog
change log</a> (online only).</p>
-</body></html>
+</body></html> \ No newline at end of file
diff --git a/doc/manual.html b/doc/manual.html
index 894a7876..1719ef5e 100644
--- a/doc/manual.html
+++ b/doc/manual.html
@@ -16,7 +16,7 @@ relay chains while at the same time being very easy to setup for the
novice user. And as we know what enterprise users really need, there is
also <a href="professional_support.html">professional
rsyslog support</a> available directly from the source!</p>
-<p><b>This documentation is for version 3.17.1 (devel branch) of rsyslog.</b>
+<p><b>This documentation is for version 3.17.2 (devel branch) of rsyslog.</b>
Visit the <i> <a href="http://www.rsyslog.com/doc-status.html">rsyslog status page</a></i></b> to obtain current
version information and project status.
</p><p><b>If you like rsyslog, you might
diff --git a/doc/rsyslog_ng_comparison.html b/doc/rsyslog_ng_comparison.html
index 0d57a374..72fee210 100644
--- a/doc/rsyslog_ng_comparison.html
+++ b/doc/rsyslog_ng_comparison.html
@@ -1,11 +1,9 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html><head><title>rsyslog vs. syslog-ng - a comparison</title>
-
-</head>
+<html><head><title>rsyslog vs. syslog-ng - a comparison</title></head>
<body>
<h1>rsyslog vs. syslog-ng</h1>
<p><small><i>Written by <a href="http://www.gerhards.net/rainer">Rainer Gerhards</a>
-(2008-04-08)</i></small></p>
+(2008-05-06)</i></small></p>
<p>We have often been asked about a comparison sheet between
rsyslog and syslog-ng. Unfortunately, I do not know much about
syslog-ng, I did not even use it once. Also, there seems to be no
@@ -101,7 +99,7 @@ Network (Protocol) Support</b><br>
<tr>
<td valign="top">support for GSS-API</td>
<td valign="top">yes</td>
-<td valign="top">no (?)</td>
+<td valign="top">no</td>
</tr>
<tr>
<td valign="top">ability to limit the allowed
@@ -141,20 +139,24 @@ reliable <a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">RFC
<td valign="top">no</td>
</tr>
<tr>
-<td valign="top">support for <a href="rsyslog_stunnel.html">ssl-protected
+<td valign="top">support for <a href="rsyslog_tls.html">TLS/SSL-protected
syslog</a> </td>
-<td valign="top"><a href="rsyslog_stunnel.html">via
+<td valign="top"><a href="rsyslog_tls.html">natively</a> (since 3.19.0)<br><a href="rsyslog_stunnel.html">via
stunnel</a></td>
<td valign="top">via stunnel<br>
paid edition natively</td>
</tr>
<tr>
-<td valign="top">support for IETF's new
-syslog-protocol draft</td>
+<td valign="top">support for IETF's new syslog-protocol draft</td>
<td valign="top">yes</td>
<td valign="top">no</td>
</tr>
<tr>
+<td valign="top">support for IETF's new syslog-transport-tls draft</td>
+<td valign="top">yes<br>(since 3.19.0 - world's first implementation)</td>
+<td valign="top">no</td>
+</tr>
+<tr>
<td valign="top">support for IPv6</td>
<td valign="top">yes</td>
<td valign="top">yes</td>
@@ -162,7 +164,7 @@ syslog-protocol draft</td>
<tr>
<td valign="top">native ability to send SNMP traps</td>
<td valign="top">yes</td>
-<td valign="top">?</td>
+<td valign="top">no</td>
</tr>
<tr>
<td valign="top">ability to preserve the original
@@ -426,8 +428,10 @@ including ability to present channel and priority as visible log data</td>
<td valign="top">yes</td>
<td valign="top">not sure...</td>
</tr>
-<tr><td valign="top">native ability to send mail messages</td>
-<td valign="top">yes (<a href="ommail.html">ommail</a>, introduced in 3.17.0)</td>
+<tr>
+<td valign="top">native ability to send mail messages</td>
+<td valign="top">yes (<a href="ommail.html">ommail</a>,
+introduced in 3.17.0)</td>
<td valign="top">not sure...</td>
</tr>
<tr>
@@ -578,6 +582,5 @@ feature sheet. I have not yet been able to fully work through it. In
the mean time, you may want to read it in parallel. It is available at
<a href="http://www.balabit.com/network-security/syslog-ng/features/detailed/">Balabit's
site</a>.</p>
-<p>This document is current as of 2008-04-08 and definitely
-incomplete (I did not yet manage to complete it!).</p>
-</body></html>
+
+</body></html> \ No newline at end of file
diff --git a/doc/rsyslog_stunnel.html b/doc/rsyslog_stunnel.html
index 9d944521..104a672e 100644
--- a/doc/rsyslog_stunnel.html
+++ b/doc/rsyslog_stunnel.html
@@ -1,248 +1,240 @@
-<html><head>
-<title>SSL Encrypting syslog with stunnel</title>
-<meta name="KEYWORDS" content="syslog encryption, rsyslog, stunnel, secure syslog, tcp, reliable, howto, ssl">
-</head>
-<body>
-<h1>SSL Encrypting Syslog with Stunnel</h1>
- <P><small><i>Written by
- <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer
- Gerhards</a> (2005-07-22)</i></small></P>
-<h2>Abstract</h2>
-<p><i><b>In this paper, I describe how to encrypt <a href="http://www.monitorware.com/en/topics/syslog/">syslog</a>
-messages on the network.</b> Encryption
-is vital to keep the confidiental content of syslog messages secure. I describe the overall
-approach and provide an HOWTO do it with the help of
-<a href="http://www.rsyslog.com">rsyslogd</a> and <a href="http://www.stunnel.org">stunnel</a>.</i></p>
-<h2>Background</h2>
-<P><b>Syslog is a
-clear-text protocol. That means anyone with a sniffer can have
-a peek at your data.</b> In some environments, this is no problem at all. In
-others, it is a huge setback, probably even preventing deployment of syslog
-solutions. Thankfully, there is an easy way to encrypt syslog communication. I
-will describe one approach in this paper.</P>
-<P>The most straigthforward solution would be that the syslogd itself encrypts
-messages. Unfortuantely, encryption is only standardized in
-<a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">RFC 3195</a>. But there
-is currently no syslogd that implements RFC 3195's encryption features,
-so this route leads to nothing. Another approach would be to use vendor- or
-project-specific syslog extensions. There are a few around, but the problem here
-is that they have compatibility issues. However, there is one surprisingly easy
-and interoperable solution: though not standardized, many vendors and projects
-implement plain tcp syslog. In a nutshell, plain tcp syslog is a mode where
-standard syslog messages are transmitted via tcp and records are separated by
-newline characters. This mode is supported by all major syslogd's (both on Linux/Unix
-and Windows) as well as log sources (for example,
-<a href="http://www.eventreporter.com/en/">EventReporter</a> for Windows
-Event Log forwarding). Plain tcp syslog offers reliability, but it does not
-offer encryption in itself. However, since it operates on a tcp stream, it is now easy
-to add encryption. There are various ways to do that. In this paper, I will
-describe how it is done with stunnel (an
-other alternative would be <a href="http://en.wikipedia.org/wiki/IPSec">IPSec</a>, for example).</P>
-<P>Stunnel is open source and it is available both for Unix/Linux and Windows.
-It provides a way to
- use ssl communication for any non-ssl aware client and server - in this case,
- our syslogd.</P>
- <P>Stunnel works much like a wrapper. Both on the client and on the server machine,
- tunnel portals are created. The non-ssl aware client and server software is
- configured to not directly talk to the remote partner, but to the local
- (s)tunnel portal instead. Stunnel, in turn, takes the data received from the
- client, encrypts it via ssl, sends it to the remote tunnel portal and that
- remote portal sends it to the recipient process on the remote machine. The
- transfer to the portals is done via unencrypted communication. As such,
- it is vital that
- the portal and the respective program that is talking to it are on the same
- machine, otherwise data would travel partly unencrypted. Tunneling, as done by stunnel,
- requires connection oriented communication. This is why you need to use
- tcp-based syslog. As a side-note, you can also encrypt a plain-text RFC
- 3195 session via stunnel, though this definitely is not what the
- protocol designers had on their mind ;)</P>
-<P>In the rest of this document, I assume that you use rsyslog on both the
-client and the server. For the samples, I use <a href="http://www.debian.org/">Debian</a>.
-Interestingly, there are
-some annoying differences between stunnel implementations. For example, on
-Debian a comment line starts with a semicolon (';'). On
-<a href="http://www.redhat.com">Red Hat</a>, it starts with
-a hash sign ('#'). So you need to watch out for subtle issues when setting up
-your system.</P>
-<h2>Overall System Setup</h2>
-<P>In ths paper, I assume two machines, one named &quot;client&quot; and the other named &quot;server&quot;.
-It is obvious that, in practice, you will probably have multiple clients but
-only one server. Syslog traffic shall be transmitted via stunnel over the
-network. Port 60514 is to be used for that purpose. The machines are set up as
-follows:</P>
-<P><b>Client</b></P>
-<ul>
- <li>rsyslog forwards&nbsp; message to stunnel local portal at port 61514</li>
- <li>local stunnel forwards data via the network to port 60514 to its remote
- peer</li>
-</ul>
-<P><b>Server</b></P>
-<ul>
- <li>stunnel listens on port 60514 to connections from its client peers</li>
- <li>all connections are forwarded to the locally-running rsyslog listening
- at port 61514</li>
-</ul>
-<h2>Setting up the system</h2>
-<P>For Debian, you need the &quot;stunnel4&quot; package. The &quot;stunnel&quot; package is the
-older 3.x release, which will not support the configuration I describe below.
-Other distributions might have other names. For example, on Red Hat it is just &quot;stunnel&quot;.
-Make sure that you install the appropriate package on both the client and the
-server. It is also a good idea to check if there are updates for either stunnel
-or openssl (which stunnel uses) - there are often security fixes available and
-often the latest fixes are not included in the default package.</P>
-<P>In my sample setup, I use only the bare minimum of options. For example, I do
-not make the server check client cerficiates. Also, I do not talk much about
-certificates at all. If you intend to really secure your system, you should
-probably learn about certificates and how to manage and deploy them. This is
-beyond the scope of this paper. For additional information,
-<a href="http://www.stunnel.org/faq/certs.html">
-http://www.stunnel.org/faq/certs.html</a> is a good starting point.</P>
-<P>You also need to install rsyslogd on both machines. Do this before starting
-with the configuration. You should also familarize yourself with its
-configuration file syntax, so that you know which actions you can trigger with
-it. Rsyslogd can work as a drop-in replacement for stock
-<a href="http://www.infodrom.org/projects/sysklogd/">sysklogd</a>. So if you know
-the standard syslog.conf syntax, you do not need to learn any more to follow
-this paper.</P>
-<h3>Server Setup</h3>
-<P>At the server, you need to have a digital certificate. That certificate
-enables SSL operation, as it provides the necessary crypto keys being used to
-secure the connection. Many versions of stunnel come with a default certificate,
-often found in /etc/stunnel/stunnel.pem. If you have it, it is good for testing
-only. If you use it in production, it is very easy to break into your secure
-channel as everybody is able to get hold of your private key. I didn't find an
-stunnel.pem on my Debian machine. I guess the Debian folks removed it because of
-its insecurity.</P>
-<P>You can create your own certificate with a simple openssl tool - you need to
-do it if you have none and I highly recommend to create one in any case. To
-create it, cd to /etc/stunnel and type:</P>
-<p><blockquote><code>openssl req -new -x509 -days 3650 -nodes -out
-stunnel.pem -keyout stunnel.pem</code></blockquote></p>
-<P>That command will ask you a number of questions. Provide some answer for
-them. If you are unsure, read
-<a href="http://www.stunnel.org/faq/certs.html">
-http://www.stunnel.org/faq/certs.html</a>. After the command has finished, you
-should have a usable stunnel.pem in your working directory.</P>
-<P>Next is to create a configuration file for stunnel. It will direct stunnel
-what to do. You can used the following basic file:</P>
-<P><blockquote><code><pre>; Certificate/key is needed in server mode
-cert = /etc/stunnel/stunnel.pem
-
-<i>; Some debugging stuff useful for troubleshooting
-debug = 7
-foreground=yes</i>
-
-[ssyslog]
-accept = 60514
-connect = 61514</pre>
-</code></blockquote></P>
-<p>Save this file to e.g. /etc/stunnel/syslog-server.conf. Please note that the
-settings in <i>italics</i> are for debugging only. They run stunnel
-with a lot of debug information in the foreground. This is very valuable while
-you setup the system - and very useless once everything works well. So be sure
-to remove these lines when going to production.</p>
-<p>Finally, you need to start the stunnel daemon. Under Debian, this is done via
-&quot;stunnel /etc/stunnel/syslog.server.conf&quot;. If you have enabled the debug
-settings, you will immediately see a lot of nice messages.</p>
-<p>Now you have stunnel running, but it obviously unable to talk to rsyslog -
-because it is not yet running. If not already done, configure it so that it does
-everything you want. If in doubt, you can simply copy /etc/syslog.conf to /etc/rsyslog.conf
-and you probably have what you want. The really important thing in rsyslogd
-configuration is that you must make it listen to tcp port 61514 (remember: this
-is where stunnel send the messages to). Thankfully, this is easy to achive: just
-add &quot;-t 61514&quot; to the rsyslogd startup options in your system startup script.
-After done so, start (or restart) rsyslogd.</p>
-<p>The server should now be fully operational.</p>
-<h3>Client Setup</h3>
-<P>The client setup is simpler. Most importantly, you do not need a certificate
-(of course, you can use one if you would like to authenticate the client, but
-this is beyond the scope of this paper). So the basic thing you need to do is
-create the stunnel configuration file.</P>
-<P><blockquote><code><pre><i>; Some debugging stuff useful for troubleshooting
-debug = 7
-foreground=yes</i>
-
-<b>client=yes</b>
-
-[ssyslog]
-accept = 127.0.0.1:61514
-connect = <font color="#FF0000">192.0.2.1</font>:60514
-</pre>
-</code></blockquote></P>
-<P>Again, the text in <i>italics</i> is for debugging purposes only. I suggest
-you leave it in during your initial testing and then remove it. The most
-important difference to the server configuration outlined above is the &quot;client=yes&quot;
-directive. It is what makes this stunnel behave like a client. The accept
-directive binds stunnel only to the local host, so that it is protected from
-receiving messages from the network (somebody might fake to be the local sender).
-The address &quot;192.0.2.1&quot; is the address of the server machine. You must change it
-to match your configuration. Save this file to /etc/stunnel/syslog-client.conf.</P>
-<P>Then, start stunnel via &quot;stunnel4 /etc/stunnel/syslog-client.conf&quot;.&nbsp; Now
-you should see some startup messages. If no errors appear, you have a running
-client stunnel instance.</P>
-<P>Finally, you need to tell rsyslogd to send data to the remote host. In stock
-syslogd, you do this via the &quot;@host&quot; forwarding directive. The same works with
-rsyslog, but it suppports extensions to use tcp. Add the following line to your
-/etc/rsyslog.conf:</P>
-<P><blockquote><code><pre>*.* @<font color="#FF0000">@</font>127.0.0.1:61514
-</pre>
-</code></blockquote><i></P>
-
-</i>
-
-<P>Please note the double at-sign (@@). This is no typo. It tells rsyslog to use
-tcp instead of udp delivery. In this sample, all messages are forwarded to the
-remote host. Obviously, you may want to limit this via the usual rsyslog.conf
-settings (if in doubt, use man rsyslog.con).</P>
-<P>You do not need to add any special startup settings to rsyslog on the client.
-Start or restart rsyslog so that the new configuration setting takes place.</P>
-<h3>Done</h3>
-<P>After following these steps, you should have a working secure syslog
-forwarding system. To verify, you can type &quot;logger test&quot; or a similar smart
-command on the client. It should show up in the respective server log file. If
-you dig out you sniffer, you should see that the traffic on the wire is actually
-protected. In the configuration use above, the two stunnel endpoints should be
-quite chatty, so that you can follow the action going on on your system.</P>
-<P>If you have only basic security needs, you can probably just remove the debug
-settings and take the rest of the configuration to production. If you are
-security-sensitve, you should have a look at the various stunnel settings that
-help you further secure the system.</P>
-<h2>Preventing Systems from talking directly to the rsyslog Server</h2>
-<P>It is possible that remote systems (or attackers) talk to the rsyslog server
-by directly connecting to its port 61514. Currently (July of 2005), rsyslog does
-not offer the ability to bind to the local host, only. This feature is planned,
-but as long as it is missing, rsyslog must be protected via a firewall. This can
-easily be done via e.g iptables. Just be sure not to forget it.</P>
-<h2>Conclusion</h2>
-<P>With minumal effort, you can set up a secure logging infrastructure employing
-ssl encrypted syslog message transmission. As a side note, you also have the
-benefit of reliable tcp delivery which is far less prone to message loss than
-udp.</P>
-<h3>Feedback requested</h3>
-<P>I would appreciate feedback on this tutorial. If you have additional ideas,
-comments or find bugs (I *do* bugs - no way... ;)), please
-<a href="mailto:rgerhards@adiscon.com">let me know</a>.</P>
-<h2>Revision History</h2>
-<ul>
- <li>2005-07-22 *
- <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a> * Initial Version created</li>
- <li>2005-07-26 *
- <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a> * Some text brush-up, hyperlinks added</li>
- <li>2005-08-03 *
- <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a>
- * license added</li>
-</ul>
-<h2>Copyright</h2>
-<p>Copyright (c) 2005
-<a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a> and
-<a href="http://www.adiscon.com/en/">Adiscon</a>.</p>
-<p> Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.2
- or any later version published by the Free Software Foundation;
- with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. A copy of the license can be viewed at
-<a href="http://www.gnu.org/copyleft/fdl.html">
-http://www.gnu.org/copyleft/fdl.html</a>.</p>
-
-</body>
-</html> \ No newline at end of file
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html><head>
+
+<title>SSL Encrypting syslog with stunnel</title><meta name="KEYWORDS" content="syslog encryption, rsyslog, stunnel, secure syslog, tcp, reliable, howto, ssl"></head><body>
+<h1>SSL Encrypting Syslog with Stunnel</h1>
+ <p><small><i>Written by
+ <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer
+ Gerhards</a> (2005-07-22)</i></small></p>
+<h2>Abstract</h2>
+<p><i><b>In this paper, I describe how to encrypt <a href="http://www.monitorware.com/en/topics/syslog/">syslog</a>
+messages on the network.</b> Encryption
+is vital to keep the confidiental content of syslog messages secure. I describe the overall
+approach and provide an HOWTO do it with the help of
+<a href="http://www.rsyslog.com">rsyslogd</a> and <a href="http://www.stunnel.org">stunnel</a>.</i></p><p><span style="font-weight: bold;">Please note that starting with rsyslog 3.19.0, </span><a style="font-weight: bold;" href="rsyslog_tls.html">rsyslog provides native TLS/SSL encryption</a><span style="font-weight: bold;"> <span style="font-style: italic;">without</span> the need of stunnel. </span>I
+strongly recomend to use that feature instead of stunnel. The stunnel
+documentation here is mostly provided for backwards compatibility. New
+deployments are advised to use native TLS mode.<i></i></p>
+<h2>Background</h2>
+<p><b>Syslog is a
+clear-text protocol. That means anyone with a sniffer can have
+a peek at your data.</b> In some environments, this is no problem at all. In
+others, it is a huge setback, probably even preventing deployment of syslog
+solutions. Thankfully, there is an easy way to encrypt syslog communication. I
+will describe one approach in this paper.</p>
+<p>The most straigthforward solution would be that the syslogd itself encrypts
+messages. Unfortuantely, encryption is only standardized in
+<a href="http://www.monitorware.com/Common/en/glossary/rfc3195.php">RFC 3195</a>. But there
+is currently no syslogd that implements RFC 3195's encryption features,
+so this route leads to nothing. Another approach would be to use vendor- or
+project-specific syslog extensions. There are a few around, but the problem here
+is that they have compatibility issues. However, there is one surprisingly easy
+and interoperable solution: though not standardized, many vendors and projects
+implement plain tcp syslog. In a nutshell, plain tcp syslog is a mode where
+standard syslog messages are transmitted via tcp and records are separated by
+newline characters. This mode is supported by all major syslogd's (both on Linux/Unix
+and Windows) as well as log sources (for example,
+<a href="http://www.eventreporter.com/en/">EventReporter</a> for Windows
+Event Log forwarding). Plain tcp syslog offers reliability, but it does not
+offer encryption in itself. However, since it operates on a tcp stream, it is now easy
+to add encryption. There are various ways to do that. In this paper, I will
+describe how it is done with stunnel (an
+other alternative would be <a href="http://en.wikipedia.org/wiki/IPSec">IPSec</a>, for example).</p>
+<p>Stunnel is open source and it is available both for Unix/Linux and Windows.
+It provides a way to
+ use ssl communication for any non-ssl aware client and server - in this case,
+ our syslogd.</p>
+ <p>Stunnel works much like a wrapper. Both on the client and on the server machine,
+ tunnel portals are created. The non-ssl aware client and server software is
+ configured to not directly talk to the remote partner, but to the local
+ (s)tunnel portal instead. Stunnel, in turn, takes the data received from the
+ client, encrypts it via ssl, sends it to the remote tunnel portal and that
+ remote portal sends it to the recipient process on the remote machine. The
+ transfer to the portals is done via unencrypted communication. As such,
+ it is vital that
+ the portal and the respective program that is talking to it are on the same
+ machine, otherwise data would travel partly unencrypted. Tunneling, as done by stunnel,
+ requires connection oriented communication. This is why you need to use
+ tcp-based syslog. As a side-note, you can also encrypt a plain-text RFC
+ 3195 session via stunnel, though this definitely is not what the
+ protocol designers had on their mind ;)</p>
+<p>In the rest of this document, I assume that you use rsyslog on both the
+client and the server. For the samples, I use <a href="http://www.debian.org/">Debian</a>.
+Interestingly, there are
+some annoying differences between stunnel implementations. For example, on
+Debian a comment line starts with a semicolon (';'). On
+<a href="http://www.redhat.com">Red Hat</a>, it starts with
+a hash sign ('#'). So you need to watch out for subtle issues when setting up
+your system.</p>
+<h2>Overall System Setup</h2>
+<p>In ths paper, I assume two machines, one named "client" and the other named "server".
+It is obvious that, in practice, you will probably have multiple clients but
+only one server. Syslog traffic shall be transmitted via stunnel over the
+network. Port 60514 is to be used for that purpose. The machines are set up as
+follows:</p>
+<p><b>Client</b></p>
+<ul>
+ <li>rsyslog forwards&nbsp; message to stunnel local portal at port 61514</li>
+ <li>local stunnel forwards data via the network to port 60514 to its remote
+ peer</li>
+</ul>
+<p><b>Server</b></p>
+<ul>
+ <li>stunnel listens on port 60514 to connections from its client peers</li>
+ <li>all connections are forwarded to the locally-running rsyslog listening
+ at port 61514</li>
+</ul>
+<h2>Setting up the system</h2>
+<p>For Debian, you need the "stunnel4" package. The "stunnel" package is the
+older 3.x release, which will not support the configuration I describe below.
+Other distributions might have other names. For example, on Red Hat it is just "stunnel".
+Make sure that you install the appropriate package on both the client and the
+server. It is also a good idea to check if there are updates for either stunnel
+or openssl (which stunnel uses) - there are often security fixes available and
+often the latest fixes are not included in the default package.</p>
+<p>In my sample setup, I use only the bare minimum of options. For example, I do
+not make the server check client cerficiates. Also, I do not talk much about
+certificates at all. If you intend to really secure your system, you should
+probably learn about certificates and how to manage and deploy them. This is
+beyond the scope of this paper. For additional information,
+<a href="http://www.stunnel.org/faq/certs.html">
+http://www.stunnel.org/faq/certs.html</a> is a good starting point.</p>
+<p>You also need to install rsyslogd on both machines. Do this before starting
+with the configuration. You should also familarize yourself with its
+configuration file syntax, so that you know which actions you can trigger with
+it. Rsyslogd can work as a drop-in replacement for stock
+<a href="http://www.infodrom.org/projects/sysklogd/">sysklogd</a>. So if you know
+the standard syslog.conf syntax, you do not need to learn any more to follow
+this paper.</p>
+<h3>Server Setup</h3>
+<p>At the server, you need to have a digital certificate. That certificate
+enables SSL operation, as it provides the necessary crypto keys being used to
+secure the connection. Many versions of stunnel come with a default certificate,
+often found in /etc/stunnel/stunnel.pem. If you have it, it is good for testing
+only. If you use it in production, it is very easy to break into your secure
+channel as everybody is able to get hold of your private key. I didn't find an
+stunnel.pem on my Debian machine. I guess the Debian folks removed it because of
+its insecurity.</p>
+<p>You can create your own certificate with a simple openssl tool - you need to
+do it if you have none and I highly recommend to create one in any case. To
+create it, cd to /etc/stunnel and type:</p>
+<p></p><blockquote><code>openssl req -new -x509 -days 3650 -nodes -out
+stunnel.pem -keyout stunnel.pem</code></blockquote><p></p>
+<p>That command will ask you a number of questions. Provide some answer for
+them. If you are unsure, read
+<a href="http://www.stunnel.org/faq/certs.html">
+http://www.stunnel.org/faq/certs.html</a>. After the command has finished, you
+should have a usable stunnel.pem in your working directory.</p>
+<p>Next is to create a configuration file for stunnel. It will direct stunnel
+what to do. You can used the following basic file:</p>
+<p></p><blockquote><code></code><pre>; Certificate/key is needed in server mode<br>cert = /etc/stunnel/stunnel.pem<br><br><i>; Some debugging stuff useful for troubleshooting<br>debug = 7<br>foreground=yes</i>
+
+[ssyslog]
+accept = 60514
+connect = 61514</pre>
+</blockquote><p></p>
+<p>Save this file to e.g. /etc/stunnel/syslog-server.conf. Please note that the
+settings in <i>italics</i> are for debugging only. They run stunnel
+with a lot of debug information in the foreground. This is very valuable while
+you setup the system - and very useless once everything works well. So be sure
+to remove these lines when going to production.</p>
+<p>Finally, you need to start the stunnel daemon. Under Debian, this is done via
+"stunnel /etc/stunnel/syslog.server.conf". If you have enabled the debug
+settings, you will immediately see a lot of nice messages.</p>
+<p>Now you have stunnel running, but it obviously unable to talk to rsyslog -
+because it is not yet running. If not already done, configure it so that it does
+everything you want. If in doubt, you can simply copy /etc/syslog.conf to /etc/rsyslog.conf
+and you probably have what you want. The really important thing in rsyslogd
+configuration is that you must make it listen to tcp port 61514 (remember: this
+is where stunnel send the messages to). Thankfully, this is easy to achive: just
+add "-t 61514" to the rsyslogd startup options in your system startup script.
+After done so, start (or restart) rsyslogd.</p>
+<p>The server should now be fully operational.</p>
+<h3>Client Setup</h3>
+<p>The client setup is simpler. Most importantly, you do not need a certificate
+(of course, you can use one if you would like to authenticate the client, but
+this is beyond the scope of this paper). So the basic thing you need to do is
+create the stunnel configuration file.</p>
+<p></p><blockquote><code></code><pre><i>; Some debugging stuff useful for troubleshooting<br>debug = 7<br>foreground=yes</i>
+
+<b>client=yes</b>
+
+[ssyslog]
+accept = 127.0.0.1:61514
+connect = <font color="#ff0000">192.0.2.1</font>:60514<br></pre>
+</blockquote><p></p>
+<p>Again, the text in <i>italics</i> is for debugging purposes only. I suggest
+you leave it in during your initial testing and then remove it. The most
+important difference to the server configuration outlined above is the "client=yes"
+directive. It is what makes this stunnel behave like a client. The accept
+directive binds stunnel only to the local host, so that it is protected from
+receiving messages from the network (somebody might fake to be the local sender).
+The address "192.0.2.1" is the address of the server machine. You must change it
+to match your configuration. Save this file to /etc/stunnel/syslog-client.conf.</p>
+<p>Then, start stunnel via "stunnel4 /etc/stunnel/syslog-client.conf".&nbsp; Now
+you should see some startup messages. If no errors appear, you have a running
+client stunnel instance.</p>
+<p>Finally, you need to tell rsyslogd to send data to the remote host. In stock
+syslogd, you do this via the "@host" forwarding directive. The same works with
+rsyslog, but it suppports extensions to use tcp. Add the following line to your
+/etc/rsyslog.conf:</p>
+<p></p><blockquote><code></code><pre>*.* @<font color="#ff0000">@</font>127.0.0.1:61514<br></pre>
+</blockquote><i><p></p>
+
+</i>
+
+<p>Please note the double at-sign (@@). This is no typo. It tells rsyslog to use
+tcp instead of udp delivery. In this sample, all messages are forwarded to the
+remote host. Obviously, you may want to limit this via the usual rsyslog.conf
+settings (if in doubt, use man rsyslog.con).</p>
+<p>You do not need to add any special startup settings to rsyslog on the client.
+Start or restart rsyslog so that the new configuration setting takes place.</p>
+<h3>Done</h3>
+<p>After following these steps, you should have a working secure syslog
+forwarding system. To verify, you can type "logger test" or a similar smart
+command on the client. It should show up in the respective server log file. If
+you dig out you sniffer, you should see that the traffic on the wire is actually
+protected. In the configuration use above, the two stunnel endpoints should be
+quite chatty, so that you can follow the action going on on your system.</p>
+<p>If you have only basic security needs, you can probably just remove the debug
+settings and take the rest of the configuration to production. If you are
+security-sensitve, you should have a look at the various stunnel settings that
+help you further secure the system.</p>
+<h2>Preventing Systems from talking directly to the rsyslog Server</h2>
+<p>It is possible that remote systems (or attackers) talk to the rsyslog server
+by directly connecting to its port 61514. Currently (July of 2005), rsyslog does
+not offer the ability to bind to the local host, only. This feature is planned,
+but as long as it is missing, rsyslog must be protected via a firewall. This can
+easily be done via e.g iptables. Just be sure not to forget it.</p>
+<h2>Conclusion</h2>
+<p>With minumal effort, you can set up a secure logging infrastructure employing
+ssl encrypted syslog message transmission. As a side note, you also have the
+benefit of reliable tcp delivery which is far less prone to message loss than
+udp.</p>
+<h3>Feedback requested</h3>
+<p>I would appreciate feedback on this tutorial. If you have additional ideas,
+comments or find bugs (I *do* bugs - no way... ;)), please
+<a href="mailto:rgerhards@adiscon.com">let me know</a>.</p>
+<h2>Revision History</h2>
+<ul>
+ <li>2005-07-22 *
+ <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a> * Initial Version created</li>
+ <li>2005-07-26 *
+ <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a> * Some text brush-up, hyperlinks added</li>
+ <li>2005-08-03 *
+ <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a>
+ * license added</li><li>2008-05-05 * <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a>
+ * updated to reflect native TLS capability of rsyslog 3.19.0 and above</li>
+</ul>
+<h2>Copyright</h2>
+<p>Copyright (c) 2008 <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a> and
+<a href="http://www.adiscon.com/en/">Adiscon</a>.</p>
+<p> Permission is granted to copy, distribute and/or modify this document
+ under the terms of the GNU Free Documentation License, Version 1.2
+ or any later version published by the Free Software Foundation;
+ with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
+ Texts. A copy of the license can be viewed at
+<a href="http://www.gnu.org/copyleft/fdl.html">
+http://www.gnu.org/copyleft/fdl.html</a>.</p>
+
+</body></html> \ No newline at end of file
diff --git a/doc/rsyslog_tls.html b/doc/rsyslog_tls.html
new file mode 100644
index 00000000..c0ebb9c8
--- /dev/null
+++ b/doc/rsyslog_tls.html
@@ -0,0 +1,170 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html><head><title>TLS (SSL) Encrypting syslog</title>
+
+<meta name="KEYWORDS" content="syslog encryption, rsyslog, secure syslog, tcp, reliable, howto, ssl, tls">
+</head>
+<body>
+<h1>Encrypting Syslog Traffic with TLS (SSL)</h1>
+<p><small><i>Written by <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer
+Gerhards</a> (2008-05-06)</i></small></p>
+<h2>Abstract</h2>
+<p><i><b>In this paper, I describe how to encrypt <a href="http://www.monitorware.com/en/topics/syslog/">syslog</a>
+messages on the network.</b> Encryption
+is vital to keep the confidiental content of syslog messages secure. I
+describe the overall
+approach and provide an HOWTO do it with <a href="http://www.rsyslog.com">rsyslog's</a> TLS
+features.&nbsp;</i></p><p>Please
+note that TLS is the more secure successor of SSL. While people often
+talk about "SSL encryption" they actually mean "TLS encryption". So
+don't look any further if you look for how to SSL-encrypt syslog. You
+have found the right spot.<i></i></p>
+<h2>Background</h2>
+<p><b>Traditional syslog is a clear-text protocol. That
+means anyone with a sniffer can have a peek at your data.</b> In
+some environments, this is no problem at all. In others, it is a huge
+setback, probably even preventing deployment of syslog solutions.
+Thankfully, there are easy ways to encrypt syslog
+communication.&nbsp;</p>
+The traditional approach involves <a href="rsyslog_stunnel.html">running
+a wrapper like stunnel around the syslog session</a>. This works
+quite well and is in widespread use. However, it is not thightly
+coupled with the main syslogd and some, even severe, problems can
+result from this (follow a mailing list thread that describes <a href="http://lists.adiscon.net/pipermail/rsyslog/2008-March/000580.html">total
+loss of syslog messages due to stunnel mode</a> and the <a href="http://rgerhards.blogspot.com/2008/04/on-unreliability-of-plain-tcp-syslog.html">unreliability
+of TCP syslog</a>).
+<p><a href="gssapi.html">Rsyslog supports syslog via
+GSSAP</a>I since long to overcome these limitatinos. However,
+syslog via GSSAPI is a rsyslog-exclusive transfer mode and it requires
+a proper Kerberos environment. As such, it isn't a really universal
+solution. The <a href="http://www.ietf.org/">IETF</a> has begun standardizing syslog over plain tcp over
+TLS for a while now. While I am not fully satisfied with the results so
+far, this obviously has the&nbsp; potential to become the long-term
+solution. The Internet Draft in question, syslog-transport-tls has been
+dormant for some time but is now (May of 2008) again being worked on. I
+expect it to turn into a RFC within the next 12 month (but don't take
+this for granted ;)). I didn't want to wait for it, because there
+obviously is need for TLS syslog right now (and, honestly, I have waited long enough...). Consequently, I have
+implemented the current draft, with some interpretations I made (there
+will be a compliance doc soon). So in essence, a TLS-protected syslog
+transfer mode is available right now. As a side-note, Rsyslog is&nbsp;the world's first
+implementation of syslog-transport-tls.</p>
+<p>Please note that in theory it should be compatible with other,
+non IETF syslog-transport-tls implementations. If you would like to run
+it with something else, please let us know so that we can create a
+compatibility list (and implement compatbility where it doesn't yet
+exist).&nbsp;</p>
+<h2>Overall System Setup</h2>
+<p>Encryption requires a reliable stream. So It will not work
+over UDP syslog. In rsyslog, network transports utilize a so-called
+"network stream layer" (netstream for short). This layer provides a
+unified view of the transport to the application layer. The plain TCP
+syslog sender and receiver are the upper layer. The driver layer
+currently consists of the "ptcp" and "gtls" library plugins. "ptcp"
+stands for "plain tcp" and is used for unencrypted message transfer. It
+is also used internally by the gtls driver, so it must always be
+present on a system. The "gtls" driver is for GnutTLS, a TLS library.
+It is used for encrypted message transfer. In the future, additional
+drivers will become available (most importantly, we would like to
+include a driver for NSS).</p>
+<p>What you need to do to build an encrypted syslog channel is to
+simply use the proper netstream drivers on both the client and the
+server. Client, in the sense of this document, is the rsyslog system
+that is sending syslog messages to a remote (central) loghost, which is
+called the server. In short, the setup is as follows:</p>
+<p><b>Client</b></p>
+<ul>
+<li>forwards messages via plain tcp syslog using gtls netstream
+driver to central sever on port 10514<br>
+</li>
+</ul>
+<p><b>Server</b></p>
+<ul>
+<li>accept incoming messages via plain tcp syslog using gtls
+netstream driver on port 10514</li>
+</ul>
+<h2>Setting up the system</h2>
+<h3>Server Setup</h3>
+<p>At the server, you need to have a digital certificate. That
+certificate enables SSL operation, as it provides the necessary crypto
+keys being used to secure the connection. There is a set of default
+certificates in ./contrib/gnutls. These are key.pem and cert.pem. These
+are&nbsp;good for testing. If you use it in production,
+it is very easy to break into your secure channel as everybody is able
+to get hold of your private key. So it is&nbsp;a good idea to
+generate the key and certificate yourself.</p>
+<p>You also need a root CA certificate. Again, there is a sample
+CA certificate in ./contrib/gnutls, named ca.cert. It is suggested to
+generate your own.</p>
+<p>To configure the server, you need to tell it where are its
+certificate files, to use the gtls driver and start up a listener. This
+is done as follows:<br>
+</p>
+<blockquote><code></code>
+<pre># make gtls driver the default<br>$DefaultNetstreamDriver gtls<br><br># certificate files<br>$DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem<br>$DefaultNetstreamDriverCertFile /path/to/contrib/gnutls/cert.pem<br>$DefaultNetstreamDriverKeyFile /path/to/contrib/gnutls/key.pem<br><br>$ModLoad /home/rger/proj/rsyslog/plugins/imtcp/.libs/imtcp # load listener<br><br>$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode<br>$InputTCPServerRun 10514 # start up listener at port 10514<br></pre>
+</blockquote>
+This is all you need to do. You can use the rest of your rsyslog.conf
+together with this configuration. The way messages are received does
+not interfer with any other option, so you are able to do anything else
+you like without any restrictions.
+<p>Restart (or HUP) rsyslogd. The server should now be fully
+operational.</p>
+<h3>Client Setup</h3>
+<p>The client setup is equally&nbsp;simple. You need less
+certificates, just the CA cert.&nbsp;</p>
+<blockquote>
+<pre># certificate files - just CA for a client<br>$DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem<br><br># set up the action<br>$DefaultNetstreamDriver gtls # use gtls netstream driver<br>$ActionSendStreamDriverMode 1 # require TLS for the connection<br>*.* @@(o)server.example.net:10514 # send (all) messages<br><br></pre>
+</blockquote>
+<p>Note that we use the regular TCP forwarding syntax (@@) here.
+There is nothing special, because the encryption is handled by the
+netstream driver. So I have just forwarded every message (*.*) for
+simplicity - you can use any of rsyslog's filtering capabilities (like
+epxression-based filters or regular expressions). Note that the "(o)"
+part is not strictly necessary. It selects octet-based framing, which
+provides compatiblity to IETF's syslog-transport-tls draft. Besides
+compatibility, this is also a more reliable transfer mode, so I suggest
+to always use it.</p>
+<h3>Done</h3>
+<p>After
+following these steps, you should have a working secure
+syslog forwarding system. To verify, you can type "logger test" or a
+similar "smart" command on the client. It should show up in the
+respective server log file. If you dig out your sniffer, you should see
+that the traffic on the wire is actually protected.</p><h3>Limitations</h3>
+<p>The current implementation has a number of limitations. These are
+being worked on. Most importantly, neither the client nor the server
+are authenticated. So while the message transfer is encrypted, you can
+not be sure which peer you are talking to. Please note that this is a
+limitation found in most real-world SSL syslog systems. Of course, that
+is not an excuse for not yet providing this feature - but it tells you
+that it is acceptable and can be worked around by proper firewalling,
+ACLs and other organizational measures. Mutual authentication will be
+added shortly to rsyslog.</p><p>Secondly, the plain tcp syslog listener
+can currently listen to a single port, in a single mode. So if you use
+a TLS-based listener, you can not run unencrypted syslog on the same
+instance at the same time. A work-around is to run a second rsyslogd
+instance. This limitation, too, is scheduled to be removed soon.</p><p>The
+RELP transport can currently not be protected by TLS. A work-around is
+to use stunnel. TLS support for RELP will be added once plain TCP
+syslog has sufficiently matured.</p><h2>Conclusion</h2>
+<p>With minumal effort, you can set up a secure logging
+infrastructure employing TLS encrypted syslog message transmission.</p>
+<h3>Feedback requested</h3>
+<p>I would appreciate feedback on this tutorial. If you have
+additional ideas, comments or find bugs (I *do* bugs - no way... ;)),
+please
+<a href="mailto:rgerhards@adiscon.com">let me know</a>.</p>
+<h2>Revision History</h2>
+<ul>
+<li>2008-05-06 * <a href="http://www.gerhards.net/rainer">Rainer
+Gerhards</a> * Initial Version created</li></ul>
+<h2>Copyright</h2>
+<p>Copyright (c) 2008 <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer
+Gerhards</a> and
+<a href="http://www.adiscon.com/en/">Adiscon</a>.</p>
+<p> Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version
+1.2 or any later version published by the Free Software Foundation;
+with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
+Texts. A copy of the license can be viewed at
+<a href="http://www.gnu.org/copyleft/fdl.html">http://www.gnu.org/copyleft/fdl.html</a>.</p>
+</body></html> \ No newline at end of file
diff --git a/doc/status.html b/doc/status.html
index 63a3f588..684afe2d 100644
--- a/doc/status.html
+++ b/doc/status.html
@@ -2,19 +2,21 @@
<html><head><title>rsyslog status page</title></head>
<body>
<h2>rsyslog status page</h2>
-<p>This page reflects the status as of 2008-04-15.</p>
+<p>This page reflects the status as of 2008-05-04.</p>
<h2>Current Releases</h2>
+<!--
<p><b>development:</b> 3.17.1 -
<a href="http://www.rsyslog.com/Article213.phtml">change log</a> -
<a href="http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-98.phtml">download</a>
+-->
-<br><b>beta:</b> 3.15.1 -
-<a href="http://www.rsyslog.com/Article210.phtml">change log</a> -
-<a href="http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-97.phtml">download</a></p>
+<br><b>beta:</b> 3.17.2 -
+<a href="http://www.rsyslog.com/Article220.phtml">change log</a> -
+<a href="http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-101.phtml">download</a></p>
-<p><b>v3 stable:</b> 3.14.2 - <a href="http://www.rsyslog.com/Article209.phtml">change log</a> -
-<a href="http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-96.phtml">download</a>
+<p><b>v3 stable:</b> 3.16.1 - <a href="http://www.rsyslog.com/Article218.phtml">change log</a> -
+<a href="http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-100.phtml">download</a>
<br><b>v2 stable:</b> 2.0.4 - <a href="http://www.rsyslog.com/Article197.phtml">change log</a> -
<a href="http://www.rsyslog.com/Downloads-index-req-getit-lid-90.phtml">download</a>
diff --git a/plugins/imklog/ksym.c b/plugins/imklog/ksym.c
index 1c2af124..f636a7bb 100644
--- a/plugins/imklog/ksym.c
+++ b/plugins/imklog/ksym.c
@@ -138,7 +138,7 @@ static char *system_maps[] =
/* Function prototypes. */
-static char * FindSymbolFile(void);
+static char *FindSymbolFile(void);
static int AddSymbol(unsigned long, char*);
static void FreeSymbols(void);
static int CheckVersion(char *);
@@ -173,29 +173,28 @@ extern int InitKsyms(char *mapfile)
auto FILE *sym_file;
+ BEGINfunc
/* Check and make sure that we are starting with a clean slate. */
if ( num_syms > 0 )
FreeSymbols();
- /*
- * Search for and open the file containing the kernel symbols.
- */
- if ( mapfile != (char *) 0 ) {
- if ( (sym_file = fopen(mapfile, "r")) == (FILE *) 0 )
+ /* Search for and open the file containing the kernel symbols. */
+ if ( mapfile != NULL ) {
+ if ( (sym_file = fopen(mapfile, "r")) == NULL )
{
imklogLogIntMsg(LOG_WARNING, "Cannot open map file: %s.", mapfile);
return(0);
}
} else {
- if ( (mapfile = FindSymbolFile()) == (char *) 0 ) {
+ if ( (mapfile = FindSymbolFile()) == NULL ) {
imklogLogIntMsg(LOG_WARNING, "Cannot find map file.");
dbgprintf("Cannot find map file.\n");
return(0);
}
- if ( (sym_file = fopen(mapfile, "r")) == (FILE *) 0 ) {
+ if ( (sym_file = fopen(mapfile, "r")) == NULL ) {
imklogLogIntMsg(LOG_WARNING, "Cannot open map file.");
dbgprintf("Cannot open map file.\n");
return(0);
@@ -203,8 +202,7 @@ extern int InitKsyms(char *mapfile)
}
- /*
- * Read the kernel symbol table file and add entries for each
+ /* Read the kernel symbol table file and add entries for each
* line. I suspect that the use of fscanf is not really in vogue
* but it was quick and dirty and IMHO suitable for fixed format
* data such as this. If anybody doesn't agree with this please
@@ -248,6 +246,7 @@ extern int InitKsyms(char *mapfile)
}
fclose(sym_file);
+ ENDfunc
return(1);
}
@@ -292,44 +291,42 @@ extern void DeinitKsyms(void)
**************************************************************************/
static char *FindSymbolFile(void)
{
- auto char *file = (char *) 0,
+ auto char *file = NULL,
**mf = system_maps;
-
auto struct utsname utsname;
static char mysymfile[100];
+ auto FILE *sym_file = NULL;
+ BEGINfunc
- auto FILE *sym_file = (FILE *) 0;
-
- if ( uname(&utsname) < 0 ) {
+ if(uname(&utsname) < 0) {
imklogLogIntMsg(LOG_ERR, "Cannot get kernel version information.");
return(0);
}
dbgprintf("Searching for symbol map.\n");
- for(mf = system_maps; *mf != (char *) 0 && file == (char *) 0; ++mf) {
-
+ for(mf = system_maps; *mf != NULL && file == NULL; ++mf) {
snprintf(mysymfile, sizeof(mysymfile), "%s-%s", *mf, utsname.release);
dbgprintf("Trying %s.\n", mysymfile);
- if ( (sym_file = fopen(mysymfile, "r")) != (FILE *) 0 ) {
- if (CheckMapVersion(mysymfile) == 1)
+ if((sym_file = fopen(mysymfile, "r")) != NULL) {
+ if(CheckMapVersion(mysymfile) == 1)
file = mysymfile;
fclose(sym_file);
}
- if (sym_file == (FILE *) 0 || file == (char *) 0) {
+ if(sym_file == NULL || file == NULL) {
sprintf (mysymfile, "%s", *mf);
dbgprintf("Trying %s.\n", mysymfile);
- if ( (sym_file = fopen(mysymfile, "r")) != (FILE *) 0 ) {
+ if((sym_file = fopen(mysymfile, "r")) != NULL ) {
if (CheckMapVersion(mysymfile) == 1)
file = mysymfile;
fclose(sym_file);
}
}
-
}
/* At this stage of the game we are at the end of the symbol tables. */
dbgprintf("End of search list encountered.\n");
+ ENDfunc
return(file);
}
@@ -464,7 +461,7 @@ static int CheckMapVersion(char *fname)
auto char type,
sym[512];
- if ( (sym_file = fopen(fname, "r")) != (FILE *) 0 ) {
+ if ( (sym_file = fopen(fname, "r")) != NULL ) {
/*
* At this point a map file was successfully opened. We
* now need to search this file and look for version
@@ -527,7 +524,7 @@ static int AddSymbol(unsigned long address, char *symbol)
/* Then the space for the symbol. */
sym_array[num_syms].name = (char *) malloc(strlen(symbol)*sizeof(char) + 1);
- if ( sym_array[num_syms].name == (char *) 0 )
+ if ( sym_array[num_syms].name == NULL )
return(0);
sym_array[num_syms].value = address;
@@ -566,13 +563,13 @@ char * LookupSymbol(unsigned long value, struct symbol *sym)
struct symbol ksym, msym;
if (!sym_array)
- return((char *) 0);
+ return(NULL);
last = sym_array[0].name;
ksym.offset = 0;
ksym.size = 0;
if ( value < sym_array[0].value )
- return((char *) 0);
+ return(NULL);
for(lp = 0; lp <= num_syms; ++lp) {
if ( sym_array[lp].value > value ) {
@@ -587,7 +584,7 @@ char * LookupSymbol(unsigned long value, struct symbol *sym)
name = LookupModuleSymbol(value, &msym);
if ( ksym.offset == 0 && msym.offset == 0 ) {
- return((char *) 0);
+ return(NULL);
}
if ( ksym.offset == 0 || msym.offset < 0 ||
@@ -602,7 +599,7 @@ char * LookupSymbol(unsigned long value, struct symbol *sym)
}
- return((char *) 0);
+ return(NULL);
}
/**************************************************************************
@@ -683,7 +680,7 @@ extern char *ExpandKadds(char *line, char *el)
* open for patches.
*/
if ( i_am_paranoid &&
- (strstr(line, "Oops:") != (char *) 0) && !InitMsyms() )
+ (strstr(line, "Oops:") != NULL) && !InitMsyms() )
imklogLogIntMsg(LOG_WARNING, "Cannot load kernel module symbols.\n");
@@ -692,7 +689,7 @@ extern char *ExpandKadds(char *line, char *el)
* messages in this line.
*/
if ( (num_syms == 0) ||
- (kp = strstr(line, "[<")) == (char *) 0 ) {
+ (kp = strstr(line, "[<")) == NULL ) {
#ifdef __sparc__
if (num_syms) {
/* On SPARC, register dumps do not have the [< >] characters in it.
@@ -780,7 +777,7 @@ extern char *ExpandKadds(char *line, char *el)
*elp++ = *sl++;
/* Now poised at a kernel delimiter. */
- if ( (kp = strstr(sl, ">]")) == (char *) 0 ) {
+ if ( (kp = strstr(sl, ">]")) == NULL ) {
strcpy(el, sl);
return(el);
}
@@ -788,7 +785,7 @@ extern char *ExpandKadds(char *line, char *el)
strncpy(num,sl+1,kp-sl-1);
num[kp-sl-1] = '\0';
value = strtoul(num, (char **) 0, 16);
- if ( (symbol = LookupSymbol(value, &sym)) == (char *) 0 )
+ if ( (symbol = LookupSymbol(value, &sym)) == NULL )
symbol = sl;
strcat(elp, symbol);
@@ -805,10 +802,10 @@ extern char *ExpandKadds(char *line, char *el)
strncat(elp, kp, value);
elp += value;
sl = kp + value;
- if ( (kp = strstr(sl, "[<")) == (char *) 0 )
+ if ( (kp = strstr(sl, "[<")) == NULL )
strcat(elp, sl);
}
- while ( kp != (char *) 0);
+ while ( kp != NULL);
dbgprintf("Expanded line: %s\n", el);
return(el);
diff --git a/plugins/imklog/ksym_mod.c b/plugins/imklog/ksym_mod.c
index bef810b4..6e48e89e 100644
--- a/plugins/imklog/ksym_mod.c
+++ b/plugins/imklog/ksym_mod.c
@@ -163,7 +163,6 @@ extern int InitMsyms(void)
else
imklogLogIntMsg(LOG_ERR, "Error loading kernel symbols " \
"- %s\n", strerror(errno));
- fclose(ksyms);
return(0);
}
diff --git a/plugins/imklog/linux.c b/plugins/imklog/linux.c
index 32cf70c4..853c8b2c 100644
--- a/plugins/imklog/linux.c
+++ b/plugins/imklog/linux.c
@@ -229,8 +229,8 @@ static void LogLine(char *ptr, int len)
*/
*line = 0; /* force null terminator */
- dbgprintf("Line buffer full:\n");
- dbgprintf("\tLine: %s\n", line);
+ //dbgprintf("Line buffer full:\n");
+ //dbgprintf("\tLine: %s\n", line);
Syslog(LOG_INFO, line_buff);
line = line_buff;
@@ -499,7 +499,8 @@ rsRetVal klogWillRun(void)
symbol_lookup = (InitKsyms(symfile) == 1);
symbol_lookup |= InitMsyms();
if (symbol_lookup == 0) {
- imklogLogIntMsg(LOG_WARNING, "cannot find any symbols, turning off symbol lookups\n");
+ dbgprintf("cannot find any symbols, turning off symbol lookups\n");
+ imklogLogIntMsg(LOG_WARNING, "cannot find any symbols, turning off symbol lookups");
}
}
}
diff --git a/runtime/cfsysline.c b/runtime/cfsysline.c
index ffc49057..0043ce5c 100644
--- a/runtime/cfsysline.c
+++ b/runtime/cfsysline.c
@@ -3,6 +3,10 @@
*
* File begun on 2007-07-30 by RGerhards
*
+ * Copyright (C) 2007, 2008 by Rainer Gerhards and Adiscon GmbH.
+ *
+ * This file is part of rsyslog.
+ *
* This file is part of the rsyslog runtime library.
*
* The rsyslog runtime library is free software: you can redistribute it and/or modify
diff --git a/runtime/ctok.c b/runtime/ctok.c
index 98d5b63b..de2bd8a8 100644
--- a/runtime/ctok.c
+++ b/runtime/ctok.c
@@ -8,6 +8,8 @@
*
* Module begun 2008-02-19 by Rainer Gerhards
*
+ * Copyright (C) 2008 by Rainer Gerhards and Adiscon GmbH.
+ *
* This file is part of the rsyslog runtime library.
*
* The rsyslog runtime library is free software: you can redistribute it and/or modify
diff --git a/runtime/linkedlist.c b/runtime/linkedlist.c
index ce20651e..8f842e43 100644
--- a/runtime/linkedlist.c
+++ b/runtime/linkedlist.c
@@ -11,7 +11,7 @@
*
* File begun on 2007-07-31 by RGerhards
*
- * Copyright (C) 2007, 2008 by Rainer Gerhards and Adiscon GmbH
+ * Copyright (C) 2007, 2008 by Rainer Gerhards and Adiscon GmbH.
*
* This file is part of the rsyslog runtime library.
*
diff --git a/runtime/sysvar.c b/runtime/sysvar.c
index 14e32b96..5eec8f67 100644
--- a/runtime/sysvar.c
+++ b/runtime/sysvar.c
@@ -5,6 +5,8 @@
*
* Module begun 2008-02-25 by Rainer Gerhards
*
+ * Copyright (C) 2008 by Rainer Gerhards and Adiscon GmbH.
+ *
* This file is part of the rsyslog runtime library.
*
* The rsyslog runtime library is free software: you can redistribute it and/or modify
diff --git a/tools/syslogd.c b/tools/syslogd.c
index 4327ab7f..835a020d 100644
--- a/tools/syslogd.c
+++ b/tools/syslogd.c
@@ -1553,8 +1553,7 @@ submitMsg(msg_t *pMsg)
}
-/*
- * Log a message to the appropriate log files, users, etc. based on
+/* Log a message to the appropriate log files, users, etc. based on
* the priority.
* rgerhards 2004-11-08: actually, this also decodes all but the PRI part.
* rgerhards 2004-11-09: ... but only, if syslogd could properly be initialized
@@ -2208,12 +2207,12 @@ init(void)
tplDeleteNew();
/* re-setting values to defaults (where applicable) */
- /* TODO: once we have loadable modules, we must re-visit this code. The reason is
+ /* once we have loadable modules, we must re-visit this code. The reason is
* that config variables are not re-set, because the module is not yet loaded. On
* the other hand, that doesn't matter, because the module got unloaded and is then
- * re-loaded, so the variables should be re-set via that way. In any case, we should
- * think about the whole situation when we implement loadable plugins.
- * rgerhards, 2007-07-31
+ * re-loaded, so the variables should be re-set via that way. And this is exactly how
+ * it works. Loadable module's variables are initialized on load, the rest here.
+ * rgerhards, 2008-04-28
*/
conf.cfsysline((uchar*)"ResetConfigVariables");
@@ -2952,7 +2951,6 @@ int realMain(int argc, char **argv)
extern int optind;
extern char *optarg;
struct sigaction sigAct;
- int bIsFirstOption = 1;
int bEOptionWasGiven = 0;
int bImUxSockLoaded = 0; /* already generated a $ModLoad imuxsock? */
char *arg; /* for command line option processing */
@@ -2997,11 +2995,6 @@ int realMain(int argc, char **argv)
CHKiRet(bufOptAdd(ch, optarg));
break;
case 'c': /* compatibility mode */
- if(!bIsFirstOption) {
- fprintf(stderr, "-c option MUST be specified as the first option - aborting...\n");
- usage();
- exit(1);
- }
iCompatibilityMode = atoi(optarg);
break;
case 'd': /* debug - must be handled now, so that debug is active during init! */
@@ -3042,7 +3035,6 @@ int realMain(int argc, char **argv)
default:
usage();
}
- bIsFirstOption = 0; /* we already saw an option character */
}
if ((argc -= optind))
generated by cgit (git 2.34.1) at 2024-11-20 10:26:20 +0000