MonitorWare Knowledge Base

rgerhards wrote:

abefroman wrote:Yes, but this is not for the server, but the CA cert itself. It needs to be present on each system. The CA private key MUST NOT be present on ANY system, you just need it when you generate new machine certificates.
Rainer

So the exact same cert.pem file should be on the server and the client?

Also, where does this key file come from thats in the client config file:
$DefaultNetstreamDriverKeyFile /home/rger/proj/rsyslog/contrib/rger/key.pem

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

Please read this doc:

http://www.rsyslog.com/doc-rsyslog_secure_tls.html

It currently is unfinished, but it (hopefully) explains what a CA is and which role it plays. It also (hopefully ) explains what are the machine certificates. Please read through it and tell me if it helps and which questions are open. I appreciate honest feedback, as this is under development. It may well be that the doc is not clear enough.

In any case, I think I better invest the time getting this straight by editing the document, because I obviously need to convey all that information so that the setup makes sense to everyone So I'll again begin to work on that doc and integrate your feedback.

Thanks,
Rainer

abefroman wrote:Odd, Im using the standard rsyslogd command to start it and rsyslogd -dn to debug. Does it think I have legacy options because of the way I have the modules in the config file?

The question is: what are your "standard rsyslogd command" - just nothing? In that case, -c3 is missing, which turns off the compatibility mode. But I guess you also use -r.

Rainer

abefroman wrote:Question, on your server config file, you have:
$ModLoad /home/rger/proj/rsyslog/plugins/imtcp/.libs/imtcp
that should be
$ModLoad /home/rger/proj/rsyslog/plugins/imtcp/.libs/imtcp.so
right?

Either way is fine, but without ".so" is preferred. Some time in the future we may not have .so any longer (think platform-compatibility). Rsyslog checks if it is present and adds it, if not. But, for example, on Windows (which we do not yet support and there are no porting plans so far), it may be .dll. Thus no extension is much better.

Rainer

Just FYI: I have updated http://www.rsyslog.com/doc-rsyslog_secure_tls.html with a graphic which hopefully is useful. Again, feedback is highly appreciated.

Rainer

abefroman wrote:

rgerhards wrote:Just FYI: I have updated http://www.rsyslog.com/doc-rsyslog_secure_tls.html with a graphic which hopefully is useful. Again, feedback is highly appreciated.

Rainer

Nice graphic! That definately makes more sense now.

Since I am using
$InputTCPServerStreamDriverAuthMode anon
Do I want to setup and ACL for which hosts can send TCP traffic on port 10514 to my server?

Well... the real solution is to drop anon mode. It is in the howto because it was the first mode rsyslog supported (3.19.0). At that time, it was obviously the best (because only) option. But that changed soon. We now have full-fledged authentication and anon should not be used in regular cases. You should go for x509/name and check the names on both the client and server. For the sample with the graphic, this is something along these lines (but beware, this is not coming from lab and may fail for one reason or the other, I can not test it right now, no lab at hand at this time):

Server:

$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverPermittedPeer *.example.net

This allows any host from the example.net domain, if (and only if) it's certificate was signed by the CA.

Client:

$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer contral.example.net

This makes sure that the client can talk to the central server only. A man in the middle, for example, is detected and the client will refuse to send it data.

With these two directives, you have a fairly secure setup. It is the one described in the paper.

Note that there are different authentication modes, most notably certificate fingerprints. In addition to this, you can also use $AllowedSender to permit only some IPs and/or firewall rules. If you use certificates, I'd not use $AllowedSender but rather use firewall rules.

HTH
Rainer

lol... I don't know what happens, but it looks like my postings are recorded under your name if I quote... Anyhow, see above, there is something new from me

I'm not sure I understand where we're at.. Are you saying that authenticated, encrypted tcp rsyslog should work? Is there a bug, or no? Thanks

mixtli wrote:I'm not sure I understand where we're at.. Are you saying that authenticated, encrypted tcp rsyslog should work? Is there a bug, or no? Thanks

Not sure, I got it work with the anonymous, but when I use x509 it gives this error:
not permitted to talk to peer, certificate invalid: signer not found: Resource temporarily unavailable

This message means that the machine certificate was not signed by a common CA. I am right now working on a full document on how to set things up. A preview is available at:

http://www.rsyslog.com/doc-rsyslog_secure_tls.html

Rainer

I have an error too with tls :-/

Code: Select all

7208.322511419:b7e0d930: logmsg: flags 5, from 'zephirlogs', msg could not load module '/usr/lib/rsyslog/lmnsd_gtls.so', rsyslog error -2078
: No such file or directory


but... :

Code: Select all

root@zephirlogs:~# ls -al /usr/lib/rsyslog/
total 268
drwxr-xr-x  2 root root  4096 2008-06-18 15:31 .
drwxr-xr-x 59 root root 16384 2008-06-16 22:12 ..
-rw-r--r--  1 root root 14336 2008-06-18 15:26 imgssapi.so
-rw-r--r--  1 root root 22596 2008-06-18 15:26 imklog.so
-rw-r--r--  1 root root  4692 2008-06-18 15:26 immark.so
-rw-r--r--  1 root root  8124 2008-06-18 15:26 imtcp.so
-rw-r--r--  1 root root  7964 2008-06-18 15:26 imudp.so
-rw-r--r--  1 root root 10204 2008-06-18 15:26 imuxsock.so
-rw-r--r--  1 root root  7548 2008-06-18 15:26 lmgssutil.so
-rw-r--r--  1 root root 21368 2008-06-18 15:26 lmnet.so
-rw-r--r--  1 root root 24248 2008-06-18 15:26 lmnetstrms.so
-rw-r--r--  1 root root 37428 2008-06-18 15:26 lmnsd_gtls.so
-rw-r--r--  1 root root 24760 2008-06-18 15:26 lmnsd_ptcp.so
-rw-r--r--  1 root root  4656 2008-06-18 15:26 lmregexp.so
-rw-r--r--  1 root root  9808 2008-06-18 15:26 lmtcpclt.so
-rw-r--r--  1 root root 27544 2008-06-18 15:26 lmtcpsrv.so


Anyone have an idea ?

response to my question... :

Code: Select all

8179.987151999:b7e0f930: GTLS CA file: '/etc/syslog-ca/ca.pem'
8179.989563849:b7e0f930: unexpected GnuTLS error -64 in nsd_gtls.c:517: Error while reading file.


rgerhards wrote:This message means that the machine certificate was not signed by a common CA. I am right now working on a full document on how to set things up. A preview is available at:

http://www.rsyslog.com/doc-rsyslog_secure_tls.html

Rainer

Thanks, I regenerated the certs, but now its giving this error:
rsyslogd:info on invalid cert: peer provided 1 certificate(s).

I ran:
certtool --certificate-info --infile cert.pem
but do not see anything obvious, I have a space in the Orgainization name, but I think that is valid for a request.

Any ideas?

saispo wrote:I have an error too with tls :-/

Code: Select all

7208.322511419:b7e0d930: logmsg: flags 5, from 'zephirlogs', msg could not load module '/usr/lib/rsyslog/lmnsd_gtls.so', rsyslog error -2078
: No such file or directory


>>Try using the path to lmnsd_gtls.so from where you extrated the tarball, I was getting that error to when I linked to it in /usr/lib/rsyslog

do a
locate lmnsd_gtls.so
and it will give you the full path

mixtli wrote:I'm not sure I understand where we're at.. Are you saying that authenticated, encrypted tcp rsyslog should work? Is there a bug, or no? Thanks

Yes, it looks like he is saying it should work.

Give it a whirl and then let us know if/where you get stuck/what error you get.

I'm having problems, but with the cert, once I get that straightened out it shoud work.