diff options
| author | Rainer Gerhards <rgerhards@adiscon.com> | 2008-06-18 14:40:08 +0200 |
|---|---|---|
| committer | Rainer Gerhards <rgerhards@adiscon.com> | 2008-06-18 14:40:08 +0200 |
| commit | abc7034f0d3833da588bd636ed71542f94d3995e (patch) | |
| tree | ab224ebfb48d7d04529a952b8038ba6e8fc8988d /doc/rsyslog_secure_tls.html | |
| parent | dc88ff72346ae3104caaa98bc94aaf4ef9882605 (diff) | |
| download | rsyslog-abc7034f0d3833da588bd636ed71542f94d3995e.tar.gz rsyslog-abc7034f0d3833da588bd636ed71542f94d3995e.tar.xz rsyslog-abc7034f0d3833da588bd636ed71542f94d3995e.zip | |
begun step-by-step guide for TLS protected syslog
Diffstat (limited to 'doc/rsyslog_secure_tls.html')
| -rw-r--r-- | doc/rsyslog_secure_tls.html | 86 |
1 files changed, 36 insertions, 50 deletions
diff --git a/doc/rsyslog_secure_tls.html b/doc/rsyslog_secure_tls.html index 29f17585..16f6835a 100644 --- a/doc/rsyslog_secure_tls.html +++ b/doc/rsyslog_secure_tls.html @@ -2,10 +2,22 @@ <html><head><title>TLS-protected syslog: recommended scenario</title> </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-06-06)</i></small></p> -<h2>Introduction</h2> +Gerhards</a> (2008-06-17)</i></small></p> +<ul> +<li><a href="rsyslog_secure_tls.html">Overview</a> +<li><a href="tls_cert_scenario.html">Sample Scenario</a> +<li><a href="tls_cert_ca.html">Setting up the CA</a> +<li><a href="tls_cert_machine.html">Generating Machine Certificates</a> +<li><a href="tls_cert_server.html">Setting up the Central Server</a> +<li><a href="tls_cert_client.html">Setting up syslog Clients</a> +<li><a href="tls_cert_udp_relay.html">Setting up the UDP syslog relay</a> +<li><a href="tls_cert_summary.html">Wrapping it all up</a> +</ul> + +<h2>Overview</h2> <p>This document describes a secure way to set up rsyslog TLS. A secure logging environment requires more than just encrypting the transmission channel. This document provides one possible way to create such a secure system. @@ -25,6 +37,19 @@ below. Do not blame us if it doesn't provide what you need ;)</p> </ul> <p>Our secrity goals are achived via public/private key security. As such, it is vital that private keys are well protected and not accessible to third parties. +<span style="float: left"> +<script type="text/javascript"><!-- +google_ad_client = "pub-3204610807458280"; +/* rsyslog doc inline */ +google_ad_slot = "5958614527"; +google_ad_width = 125; +google_ad_height = 125; +//--> +</script> +<script type="text/javascript" +src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> +</script> +</span> I private keys have become known to third parties, the system does not provide any security at all. Also, our solution bases on X.509 certificates and a (very limited) chain of trust. We have one instance (the CA) that issues all machine @@ -71,52 +96,13 @@ does not protect against this (but it may help, properly used). Keep in mind that syslog-transport-tls provides hop-by-hop security. It does not provide end-to-end security and it does not authenticate the message itself (just the last sender).</p> -<h3>Sample Szenario</h3> -<p> We have a quite simple scenario. There is one central syslog server, -named central.example.net. These server is being reported to by two Linux -machines with name zuse.example.net and turing.example.net. Also, there is a -third client - ada.example.net - which send both its own messages to the central -server but also forwards messages receive from an UDP-only capable router. We -hav decided to use ada.example.net because it is in the same local network -segment as the router and so we enjoy TLS' security benefits for forwarding the -router messages inside the corporate network.</p> -<h3>Setting up the CA</h3> -<p>The first step is to set up a certificate authoroty (CA). It must be -maintained by a trustworthy person (or group) and approves the indentities of -all machines. It does so by issuing there certificates. In a small setup, the -administrator can provide the CA function. What is important is the the CA's -private key is well-protocted and machine certificates are only issued if it is -know they are valid (in a single-admin case that means the admin should not -issue certificates to anyone else except himself).</p> -<p>The CA creates a so-called self-signed certificate. That is, it approves its -own authenticy. This sounds useless, but the key point to understand is that -every machine will be provided a copy of the CA's certificate. Accepting this -certificate is a matter of trust. So by configuring the CA certificate, the -administrator tells rsyslog which certificates to trust. This is the root of all -trust under this model. That is why the CA's private key is so important - -everyone getting hold of it is trusted by our rsyslog instances.</p> -<p>In our example, we will use the name "example.net" for our network. You may -use any domain name of your liking. -<p>To create a self-signed certificate, use the following commands with GnuTLS (which -is currently the only supported TLS library, what may change in the future): </p> -<ol> -<li>generate the private key: -<pre>certtool --generate-privkey --outfile ca-key.pem</pre> -<br> -This takes a short while. Be sure to do some work on your workstation, -it waits for radom input. Switching between windows is sufficient ;) -</li> -<li>now create the (self-signed) CA certificate itself:<br> -<pre>certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem</pre> -This generates the CA certificate. This command queries you for a -number of things. Use appropriate responses. When it comes to -certificate validity, keep in mind that you need to recreate all -certificates when this one expires. So it may be a good idea to use a -long period, eg. 3650 days (roughly 10 years). You need to specify that -the certificates belongs to an authority. The certificate is used to -sign other certificates.<br> -</li> -</ol> +<h3>A very quick Intro</h3> +<p>If you'd like to get all information very rapidly, the graphic below contains +everything you need to know (from the certificate perspective) in a very condensed +manner. It is no surprise if the graphic puzzles you. In this case, <a href="tls_cert_scenario.html">simply read on</a> +for full instructions. +<p> +<img align="center" alt="TLS/SSL protected syslog" src="tls_cert.jpg"> <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... ;)), @@ -124,8 +110,8 @@ please <a href="mailto:rgerhards@adiscon.com">let me know</a>.</p> <h2>Revision History</h2> <ul> -<li>2008-06-06 * <a href="http://www.gerhards.net/rainer">Rainer -Gerhards</a> * Initial Version created</li> +<li>2008-06-06 * <a href="http://www.gerhards.net/rainer">Rainer Gerhards</a> * Initial Version created</li> +<li>2008-06-18 * <a href="http://www.gerhards.net/rainer">Rainer Gerhards</a> * Greatly enhanced and modularized the doc</li> </ul> <h2>Copyright</h2> <p>Copyright (c) 2008 <a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer |