source: branches/samhain-2_2-branch/docs/HOWTO-client+server-troubleshooting.html@ 340

Last change on this file since 340 was 1, checked in by katerina, 19 years ago

Initial import

File size: 12.0 KB
Line 
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
2<html>
3<head>
4<title>HOWTO client+server troubleshooting</title>
5<style type="text/css">
6<!--
7
8html { background: #eee; color: #000; }
9
10body { background: #eee; color: #000; margin: 0; padding: 0;}
11
12div.body {
13 background: #fff; color: #000;
14 margin: 0 1em 0 1em; padding: 1em;
15 font-family: serif;
16 font-size: 1em; line-height: 1.2em;
17 border-width: 0 1px 0 1px;
18 border-style: solid;
19 border-color: #aaa;
20}
21
22div.block {
23 background: #b6c5f2; color: #000;
24 margin: 1em; padding: 0 1em 0 1em;
25 border-width: 1px;
26 border-style: solid;
27 border-color: #2d4488;
28}
29
30div.warnblock {
31 background: #b6c5f2; color: #000;
32 margin: 1em; padding: 0 1em 0 1em;
33 border-width: 1px;
34 border-style: solid;
35 border-color: #FF9900;
36}
37
38table {
39 background: #F8F8F8; color: #000;
40 margin: 1em;
41 border-width: 0 0 0 1px;
42 border-style: solid;
43 border-color: #C0C0C0;
44}
45
46td {
47 border-width: 0 1px 1px 0;
48 border-style: solid;
49 border-color: #C0C0C0;
50}
51
52th {
53 background: #F8F8FF;
54 border-width: 1px 1px 2px 0;
55 border-style: solid;
56 border-color: #C0C0C0;
57}
58
59
60/* body text, headings, and rules */
61
62p { margin: 0; text-indent: 0em; margin: 0 0 0.5em 0 }
63
64h1, h2, h3, h4, h5, h6 {
65 color: #206020; background: transparent;
66 font-family: Optima, Arial, Helvetica, sans-serif;
67 font-weight: normal;
68}
69
70h1 { font-size: 1.69em; margin: 1.4em 0 0.4em 0; }
71h2 { font-size: 1.44em; margin: 1.4em 0 0.4em 0; }
72h3 { font-size: 1.21em; margin: 1.4em 0 0.4em 0; }
73h4 { font-size: 1.00em; margin: 1.4em 0 0.4em 0; }
74h5 { font-size: 0.81em; margin: 1.4em 0 0.4em 0; }
75h6 { font-size: 0.64em; margin: 1.4em 0 0.4em 0; }
76
77hr {
78 color: transparent; background: transparent;
79 height: 0px; margin: 0.6em 0;
80 border-width: 1px ;
81 border-style: solid;
82 border-color: #999;
83}
84
85/* bulleted lists and definition lists */
86
87ul { margin: 0 1em 0.6em 2em; padding: 0; }
88li { margin: 0.4em 0 0 0; }
89
90dl { margin: 0.6em 1em 0.6em 2em; }
91dt { color: #285577; }
92
93tt { color: #602020; }
94
95/* links */
96
97a.link {
98 color: #33c; background: transparent;
99 text-decoration: none;
100}
101
102a:hover {
103 color: #000; background: transparent;
104}
105
106body > a {
107 font-family: Optima, Arial, Helvetica, sans-serif;
108 font-size: 0.81em;
109}
110
111h1, h2, h3, h4, h5, h6 {
112 color: #2d5588; background: transparent;
113 font-family: Optima, Arial, Helvetica, sans-serif;
114 font-weight: normal;
115}
116
117 -->
118</style></head>
119
120<body>
121<div class="body">
122<p style="text-align: center; background: #ccc; border: 1px solid #2d5588;"><a
123 style="text-decoration: none;"
124 href="http://www.la-samhna.de/samhain/">samhain file integrity
125 scanner</a>&nbsp;|&nbsp;<a style="text-decoration: none;"
126 href="http://www.la-samhna.de/samhain/s_documentation.html">online
127 documentation</a></p>
128<br><center>
129<h1>Samhain client/server: What can go wrong, and how can you fix it ?</h1>
130</center>
131<br>
132<hr>
133<p>
134This document aims to explain how to diagnose and fix common problems that
135may result from misunderstanding or misconfiguration when setting up
136a client/server samhain system. This document is divided in several sections
137more or less corresponding to the different stages when a client
138connects to a server. Each section starts with a brief explanation that
139should provide a basic understanding of what is going on.
140</p>
141<p>
142This document does not discuss <i>how</i> to setup a client/server (for
143this, look into the manual and/or the HOWTO-client+server).
144</p>
145
146<h2><a name="sect1">Table of Contents</a></h2>
147<p>
148<a href="#sect1">Connecting to the server</a><br>
149<a href="#sect2">Authentication</a><br>
150<a href="#sect3">Downloading config/database files</a><br>
151<a href="#sect4">Other connection problems</a><br>
152</p>
153
154<h2><a name="sect1">Connecting to the server</a></h2>
155
156<p>
157Client/server connections are always initiated from the client. The port
158is compiled in (there is a configure option to change the default).
159The default port is 49777.
160</p>
161
162<h3>Problem #1</h3>
163<p>
164The client reports: <b>Connection refused</b>. The server reports nothing.
165</p>
166<p>
167The server is down, listens on the wrong port, or network failure.
168</p>
169
170<h3>Problem #2</h3>
171<p>
172The client reports: <b>Connection error: Connection reset by peer</b>, and
173later also <b>Session key negotiation failed</b>. The server reports:
174<b>msg=&quot;Refused connection from ...&quot; subroutine=&quot;libwrap&quot;</b>.
175</p>
176<p>
177The server is compiled with libwrap (TCP Wrapper) support, and the
178client is either in <tt>/etc/hosts.deny</tt>, or you have set <i>yule: ALL</i>
179in <tt>/etc/hosts.deny</tt>, and forgot to put the client in
180<tt>/etc/hosts.allow</tt>.
181</p>
182<p>
183To fix: make proper entries in <tt>/etc/hosts.allow</tt> and/or
184<tt>/etc/hosts.deny</tt>. There is no need to restart/reload the server.
185</p>
186
187
188<h2><a name="sect2">Authentication</a></h2>
189<p>
190The client has a password that is used to authenticate to the server.
191This password is located within the binary, and is set with the
192<tt>samhain_setpwd</tt> helper application, as explained e.g. in the
193manual or in the Client+Server HOWTO.
194</p><p>
195The server has a list of clients that are allowed to connect, and the
196verifiers corresponding to the passwords of these clients.
197</p>
198<p>
199Upon successful authentication, client and server will negotiate
200a <b>session key</b> that is used for signing further messages
201from the client.
202</p>
203
204<h3>Problem #1</h3>
205
206<p>
207If the password is wrong, the client will report
208<b>Session key negotiation failed</b>. The server will
209report: <b>Invalid connection attempt: Session key mismatch</b>
210</p>
211<p>
212To fix: make sure that the password has in fact been set, that you are
213using the correct executable for the client (the one where the password is
214set), and that the entry in the server config file is the one generated
215for this password (also look out for double entries for this client).
216</p>
217
218<h3>Problem #2</h3>
219
220<p>
221If the client name (as resolved on the server) is wrong, the client
222will report
223<b>Session key negotiation failed</b>. The server will
224report: <b>Invalid connection attempt: Not in client list</b>,
225<i>and</i> it will tell you in the same error message
226what name it has inferred for the connecting
227client (example): <b>client=&quot;client.mydomain.com&quot;</b>.
228</p>
229<p>
230The fix depends on the nature of the problem. In principle, it should be
231sufficient to change the name of the client in the config file entry, which
232isn't really a solution if e.g. the server thinks the client is 'localhost'.
233</p>
234<p>
235There are two different ways to determine the client name.
236Unfortunately, judging
237from customer feedback as well from common sense, both do not work very well
238with a messed up local DNS (including /etc/hosts files) and/or
239&uuml;berparanoid or misconfigured firewalls (in case of connections
240across one).
241</p>
242<ul>
243 <li>
244 <p>
245 <i>First method: Determine client name on client, and
246 try to cross-check on server</i>
247 <p>
248 <p>
249 This does not work for a number of people because (1) the
250 <tt>/etc/hosts</tt> file on the client machine has errors
251 (yes, there are plenty machines with a completely
252 messed up <tt>/etc/hosts</tt> file), (2) the
253 server cannot resolve the client address because the local DNS is
254 f***ed up, or (3) the client machine has multiple network interfaces, and
255 the interface used is not the one the client name resolves to.
256 </p>
257 <p>
258 If the client uses the wrong interface on a multi-interface machine,
259 there is a config file option
260 <tt>SetBindAddress=</tt><i>IP address</i>
261 that allows to choose the interface the client will use for
262 outgoing connections.
263 </p>
264 <p>
265 If you want to download the config file from the server, you
266 should instead use the corresponding command line
267 <tt>--bind-address=</tt><i>IP address</i>
268 to select the interface.
269 </p>
270
271 <p>
272 If you encounter problems, you may (1) fix your
273 <tt>/etc/hosts</tt> file(s), (2) fix your local DNS, or
274 (3) switch to the second method.
275 </p>
276 <p>
277 Errors in name resolving/cross-checking can be avoided by setting a
278 very low severity (lower than the logging threshold), e.g.
279 </p>
280 <p>
281 <tt>SeverityLookup=</tt><i>debug</i>
282 </p>
283 <p>
284 in the <i>Misc</i> section of the server configuration,
285 if you prefer running <i>unsafe</i> at any speed
286 instead of fixing the problem (you have been warned). Doing so will
287 allow an attacker to pose as the client.
288 </p>
289 </li>
290 <li>
291 <p><i>Second method: Use address of connecting entity as
292 known to the communication layer</i></p>
293 <p>
294 This has been dropped as default
295 long ago because it may not always be the
296 address of the client machine.
297 To enable this method, use
298 </p>
299 <p>
300 <tt>SetClientFromAccept=</tt><i>true</i>
301 </p>
302 <p>
303 in the <i>Misc</i> section of the server configuration
304 file. If the address cannot be resolved, or reverse lookup of the
305 resolved name fails, <i>no</i> error message will be issued,
306 but the numerical address will be used.
307 </p>
308 </li>
309</ul>
310
311
312<h2><a name="sect3">Downloading config/database files</a></h2>
313
314<p>
315The client does <i>not</i> tell the server the path to the requested
316file - it just requests a config or a database file. It's entirely the
317responsibility of the server to locate the correct file and send it.
318</p>
319<p>
320The server has a <i>data directory</i>, which by default would be
321<tt>/var/lib/yule</tt>. Here the config/database files should be placed.
322</p>
323<p>
324Configuration files: <tt>rc.</tt><i>client.mydomain.tld</i> or
325simply <tt>rc</tt>
326(this can be used as a catchall file).
327</p>
328<p>
329Database files: <tt>file.</tt><i>client.mydomain.tld</i> or
330simply <tt>file</tt>
331(this can be used as a catchall file).
332</p>
333
334<h3>Problem #1</h3>
335
336<p>
337If the server cannot access the configuration (or database) file, either
338because it does not exist or the server has no read permission, the
339client will report <b>File download failed</b>. The server will
340report: <b>File not accessible</b>, <i>and</i> it will tell you in the
341same report the path where it would have expected the file (example):
342<b>path=&quot;/var/lib/yule/rc.client.mydomain.com&quot;</b>
343</p>
344<p>
345To fix: put the file in the correct location, make sure the permissions
346are ok.
347</p>
348
349
350<h2><a name="sect4">Other connection problems</a></h2>
351
352<p>
353The server has a table with client names and their session keys. If
354another client process accesses the server from the same host,
355it will negotiate a fresh session key for that host. As a consequence,
356the session key of the first client process will become <i>invalid</i>.
357</p>
358<p>
359Also, the server keeps track of the status of a client. If a client
360process does not announce its termination to the server, the server
361will not expect a <i>startup</i> message, and issue a warning for any
362such message.
363</p>
364
365<h3>Problem #1</h3>
366
367<p>
368The client reports: <b>Invalid connection state</b>. The server reports:
369<b>Invalid connection attempt: Signature mismatch</b>. This is a sign that
370a client has tried to connect using an invalid session key. Most probably,
371another instance of the client is/was started on the respective host.
372</p>
373<p>
374To fix: if you need to have concurrent access to the server,
375suspend the first process with SIGUSR2 before starting the second. Use
376SIGUSR2 again to wake up the first process. Give the process a second or two
377to return into the main event loop and go into suspend mode. Do not just use
378SIGSTOP/SIGCONT: it is important that the client tells the server that
379it will go into suspend.
380</p>
381
382<h3>Problem #2</h3>
383
384<p>
385The server reports:
386<b>Restart without prior exit</b> for a client.
387This is a sign that
388a client has re-started without informing the server about a previous
389termination.
390</p>
391<p>
392This would happen if the client was killed with SIGKILL, or if it terminated
393within the routine to send a message to the server (the routine is
394not re-entrant). You may want to investigate messages logged via another
395logging facility (e.g. the client's local logfile). Of course it <i>may</i>
396also be a segfault, which would be reported via syslog.
397</p>
398
399</div>
400</body>
401</html>
Note: See TracBrowser for help on using the repository browser.