summaryrefslogtreecommitdiffstats
path: root/doc/tls_cert_client.html
blob: dbe7961b56439db6573dba027d40dbc52d10b4dc (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>TLS-protected syslog: client setup</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-07-03)</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>

<h3>Setting up a client</h3>
<p>In this step, we configure a client machine. We from our scenario, we use
zuse.example.net. You need to do the same steps for all other clients, too (in the
example, that meanst turng.example.net). The client check's the server's identity and
talks to it only if it is the expected server. This is a very important step.
Without it, you would not detect man-in-the-middle attacks or simple malicious servers
who try to get hold of your valuable log data.
<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>
<p><center><img src="tls_cert_100.jpg"></center>
<p>Steps to do:
<ul>
<li>make sure you have a functional CA (<a href="tls_cert_ca.html">Setting up the CA</a>)
<li>generate a machine certificate for zuse.example.net (follow instructions in
    <a href="tls_cert_machine.html">Generating Machine Certificates</a>)
<li>make sure you copy over ca.pem, machine-key.pem ad machine-cert.pem to the client.
Ensure that no user except root can access them (<b>even read permissions are really bad</b>).
<li>configure the client so that it checks the server identity and sends messages only
if the server identity is known. Please note that you have the same options as when
configuring a server. However, we now use a single name only, because there is only one
central server. No using wildcards make sure that we will exclusively talk to that server
(otherwise, a compromised client may take over its role). If you load-balance to different
server identies, you obviously need to allow all of them. It still is suggested to use
explcit names.
</ul>
<p><b>At this point, please be reminded once again that your security needs may be quite different from
what we assume in this tutorial. Evaluate your options based on your security needs.</b>
<h3>Sample syslog.conf</h3>
<p>Keep in mind that this rsyslog.conf sends messages via TCP, only. Also, we do not
show any rules to write local files. Feel free to add them.
<code><pre>
# make gtls driver the default
$DefaultNetstreamDriver gtls

# certificate files
$DefaultNetstreamDriverCAFile /rsyslog/protected/ca.pem
$DefaultNetstreamDriverCertFile /rsyslog/protected/machine-cert.pem
$DefaultNetstreamDriverKeyFile /rsyslog/protected/machine-key.pem

$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer central.example.net
$ActionSendStreamDriverMode 1 # run driver in TLS-only mode
*.* @@central.example.net:10514 # forward everything to remote server
</pre></code>
<p>Note: the example above forwards every message to the remote server. Of course,
you can use the normal filters to restrict the set of information that is sent.
Depending on your message volume and needs, this may be a smart thing to do.
<p><font color="red"><b>Be sure to safeguard at least the private key (machine-key.pem)!</b>
If some third party obtains it, you security is broken!</font>
<h2>Copyright</h2>
<p>Copyright &copy; 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>