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 |
|
---|
8 | html { background: #eee; color: #000; }
|
---|
9 |
|
---|
10 | body { background: #eee; color: #000; margin: 0; padding: 0;}
|
---|
11 |
|
---|
12 | div.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 |
|
---|
22 | div.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 |
|
---|
30 | div.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 |
|
---|
38 | table {
|
---|
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 |
|
---|
46 | td {
|
---|
47 | border-width: 0 1px 1px 0;
|
---|
48 | border-style: solid;
|
---|
49 | border-color: #C0C0C0;
|
---|
50 | }
|
---|
51 |
|
---|
52 | th {
|
---|
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 |
|
---|
62 | p { margin: 0; text-indent: 0em; margin: 0 0 0.5em 0 }
|
---|
63 |
|
---|
64 | h1, h2, h3, h4, h5, h6 {
|
---|
65 | color: #206020; background: transparent;
|
---|
66 | font-family: Optima, Arial, Helvetica, sans-serif;
|
---|
67 | font-weight: normal;
|
---|
68 | }
|
---|
69 |
|
---|
70 | h1 { font-size: 1.69em; margin: 1.4em 0 0.4em 0; }
|
---|
71 | h2 { font-size: 1.44em; margin: 1.4em 0 0.4em 0; }
|
---|
72 | h3 { font-size: 1.21em; margin: 1.4em 0 0.4em 0; }
|
---|
73 | h4 { font-size: 1.00em; margin: 1.4em 0 0.4em 0; }
|
---|
74 | h5 { font-size: 0.81em; margin: 1.4em 0 0.4em 0; }
|
---|
75 | h6 { font-size: 0.64em; margin: 1.4em 0 0.4em 0; }
|
---|
76 |
|
---|
77 | hr {
|
---|
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 |
|
---|
87 | ul { margin: 0 1em 0.6em 2em; padding: 0; }
|
---|
88 | li { margin: 0.4em 0 0 0; }
|
---|
89 |
|
---|
90 | dl { margin: 0.6em 1em 0.6em 2em; }
|
---|
91 | dt { color: #285577; }
|
---|
92 |
|
---|
93 | tt { color: #602020; }
|
---|
94 |
|
---|
95 | /* links */
|
---|
96 |
|
---|
97 | a.link {
|
---|
98 | color: #33c; background: transparent;
|
---|
99 | text-decoration: none;
|
---|
100 | }
|
---|
101 |
|
---|
102 | a:hover {
|
---|
103 | color: #000; background: transparent;
|
---|
104 | }
|
---|
105 |
|
---|
106 | body > a {
|
---|
107 | font-family: Optima, Arial, Helvetica, sans-serif;
|
---|
108 | font-size: 0.81em;
|
---|
109 | }
|
---|
110 |
|
---|
111 | h1, 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> | <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>
|
---|
134 | This document aims to explain how to diagnose and fix common problems that
|
---|
135 | may result from misunderstanding or misconfiguration when setting up
|
---|
136 | a client/server samhain system. This document is divided in several sections
|
---|
137 | more or less corresponding to the different stages when a client
|
---|
138 | connects to a server. Each section starts with a brief explanation that
|
---|
139 | should provide a basic understanding of what is going on.
|
---|
140 | </p>
|
---|
141 | <p>
|
---|
142 | This document does not discuss <i>how</i> to setup a client/server (for
|
---|
143 | this, 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>
|
---|
157 | Client/server connections are always initiated from the client. The port
|
---|
158 | is compiled in (there is a configure option to change the default).
|
---|
159 | The default port is 49777.
|
---|
160 | </p>
|
---|
161 |
|
---|
162 | <h3>Problem #1</h3>
|
---|
163 | <p>
|
---|
164 | The client reports: <b>Connection refused</b>. The server reports nothing.
|
---|
165 | </p>
|
---|
166 | <p>
|
---|
167 | The server is down, listens on the wrong port, or network failure.
|
---|
168 | </p>
|
---|
169 |
|
---|
170 | <h3>Problem #2</h3>
|
---|
171 | <p>
|
---|
172 | The client reports: <b>Connection error: Connection reset by peer</b>, and
|
---|
173 | later also <b>Session key negotiation failed</b>. The server reports:
|
---|
174 | <b>msg="Refused connection from ..." subroutine="libwrap"</b>.
|
---|
175 | </p>
|
---|
176 | <p>
|
---|
177 | The server is compiled with libwrap (TCP Wrapper) support, and the
|
---|
178 | client is either in <tt>/etc/hosts.deny</tt>, or you have set <i>yule: ALL</i>
|
---|
179 | in <tt>/etc/hosts.deny</tt>, and forgot to put the client in
|
---|
180 | <tt>/etc/hosts.allow</tt>.
|
---|
181 | </p>
|
---|
182 | <p>
|
---|
183 | To 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>
|
---|
190 | The client has a password that is used to authenticate to the server.
|
---|
191 | This password is located within the binary, and is set with the
|
---|
192 | <tt>samhain_setpwd</tt> helper application, as explained e.g. in the
|
---|
193 | manual or in the Client+Server HOWTO.
|
---|
194 | </p><p>
|
---|
195 | The server has a list of clients that are allowed to connect, and the
|
---|
196 | verifiers corresponding to the passwords of these clients.
|
---|
197 | </p>
|
---|
198 | <p>
|
---|
199 | Upon successful authentication, client and server will negotiate
|
---|
200 | a <b>session key</b> that is used for signing further messages
|
---|
201 | from the client.
|
---|
202 | </p>
|
---|
203 |
|
---|
204 | <h3>Problem #1</h3>
|
---|
205 |
|
---|
206 | <p>
|
---|
207 | If the password is wrong, the client will report
|
---|
208 | <b>Session key negotiation failed</b>. The server will
|
---|
209 | report: <b>Invalid connection attempt: Session key mismatch</b>
|
---|
210 | </p>
|
---|
211 | <p>
|
---|
212 | To fix: make sure that the password has in fact been set, that you are
|
---|
213 | using the correct executable for the client (the one where the password is
|
---|
214 | set), and that the entry in the server config file is the one generated
|
---|
215 | for this password (also look out for double entries for this client).
|
---|
216 | </p>
|
---|
217 |
|
---|
218 | <h3>Problem #2</h3>
|
---|
219 |
|
---|
220 | <p>
|
---|
221 | If the client name (as resolved on the server) is wrong, the client
|
---|
222 | will report
|
---|
223 | <b>Session key negotiation failed</b>. The server will
|
---|
224 | report: <b>Invalid connection attempt: Not in client list</b>,
|
---|
225 | <i>and</i> it will tell you in the same error message
|
---|
226 | what name it has inferred for the connecting
|
---|
227 | client (example): <b>client="client.mydomain.com"</b>.
|
---|
228 | </p>
|
---|
229 | <p>
|
---|
230 | The fix depends on the nature of the problem. In principle, it should be
|
---|
231 | sufficient to change the name of the client in the config file entry, which
|
---|
232 | isn't really a solution if e.g. the server thinks the client is 'localhost'.
|
---|
233 | </p>
|
---|
234 | <p>
|
---|
235 | There are two different ways to determine the client name.
|
---|
236 | Unfortunately, judging
|
---|
237 | from customer feedback as well from common sense, both do not work very well
|
---|
238 | with a messed up local DNS (including /etc/hosts files) and/or
|
---|
239 | überparanoid or misconfigured firewalls (in case of connections
|
---|
240 | across 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>
|
---|
315 | The client does <i>not</i> tell the server the path to the requested
|
---|
316 | file - it just requests a config or a database file. It's entirely the
|
---|
317 | responsibility of the server to locate the correct file and send it.
|
---|
318 | </p>
|
---|
319 | <p>
|
---|
320 | The 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>
|
---|
324 | Configuration files: <tt>rc.</tt><i>client.mydomain.tld</i> or
|
---|
325 | simply <tt>rc</tt>
|
---|
326 | (this can be used as a catchall file).
|
---|
327 | </p>
|
---|
328 | <p>
|
---|
329 | Database files: <tt>file.</tt><i>client.mydomain.tld</i> or
|
---|
330 | simply <tt>file</tt>
|
---|
331 | (this can be used as a catchall file).
|
---|
332 | </p>
|
---|
333 |
|
---|
334 | <h3>Problem #1</h3>
|
---|
335 |
|
---|
336 | <p>
|
---|
337 | If the server cannot access the configuration (or database) file, either
|
---|
338 | because it does not exist or the server has no read permission, the
|
---|
339 | client will report <b>File download failed</b>. The server will
|
---|
340 | report: <b>File not accessible</b>, <i>and</i> it will tell you in the
|
---|
341 | same report the path where it would have expected the file (example):
|
---|
342 | <b>path="/var/lib/yule/rc.client.mydomain.com"</b>
|
---|
343 | </p>
|
---|
344 | <p>
|
---|
345 | To fix: put the file in the correct location, make sure the permissions
|
---|
346 | are ok.
|
---|
347 | </p>
|
---|
348 |
|
---|
349 |
|
---|
350 | <h2><a name="sect4">Other connection problems</a></h2>
|
---|
351 |
|
---|
352 | <p>
|
---|
353 | The server has a table with client names and their session keys. If
|
---|
354 | another client process accesses the server from the same host,
|
---|
355 | it will negotiate a fresh session key for that host. As a consequence,
|
---|
356 | the session key of the first client process will become <i>invalid</i>.
|
---|
357 | </p>
|
---|
358 | <p>
|
---|
359 | Also, the server keeps track of the status of a client. If a client
|
---|
360 | process does not announce its termination to the server, the server
|
---|
361 | will not expect a <i>startup</i> message, and issue a warning for any
|
---|
362 | such message.
|
---|
363 | </p>
|
---|
364 |
|
---|
365 | <h3>Problem #1</h3>
|
---|
366 |
|
---|
367 | <p>
|
---|
368 | The client reports: <b>Invalid connection state</b>. The server reports:
|
---|
369 | <b>Invalid connection attempt: Signature mismatch</b>. This is a sign that
|
---|
370 | a client has tried to connect using an invalid session key. Most probably,
|
---|
371 | another instance of the client is/was started on the respective host.
|
---|
372 | </p>
|
---|
373 | <p>
|
---|
374 | To fix: if you need to have concurrent access to the server,
|
---|
375 | suspend the first process with SIGUSR2 before starting the second. Use
|
---|
376 | SIGUSR2 again to wake up the first process. Give the process a second or two
|
---|
377 | to return into the main event loop and go into suspend mode. Do not just use
|
---|
378 | SIGSTOP/SIGCONT: it is important that the client tells the server that
|
---|
379 | it will go into suspend.
|
---|
380 | </p>
|
---|
381 |
|
---|
382 | <h3>Problem #2</h3>
|
---|
383 |
|
---|
384 | <p>
|
---|
385 | The server reports:
|
---|
386 | <b>Restart without prior exit</b> for a client.
|
---|
387 | This is a sign that
|
---|
388 | a client has re-started without informing the server about a previous
|
---|
389 | termination.
|
---|
390 | </p>
|
---|
391 | <p>
|
---|
392 | This would happen if the client was killed with SIGKILL, or if it terminated
|
---|
393 | within the routine to send a message to the server (the routine is
|
---|
394 | not re-entrant). You may want to investigate messages logged via another
|
---|
395 | logging facility (e.g. the client's local logfile). Of course it <i>may</i>
|
---|
396 | also be a segfault, which would be reported via syslog.
|
---|
397 | </p>
|
---|
398 |
|
---|
399 | </div>
|
---|
400 | </body>
|
---|
401 | </html>
|
---|