On Mon, 2 Mar 2015, stephane martin wrote:

Thanks. Let me elaborate.

The typical use case could be something like:

- I have dozens (or hundreds) of servers that act as syslog clients.
- Log content is pretty sensitive.
- Servers operate on a private WAN (eg VPN MPLS).
- The WAN is owned by some telco.
- I don't trust the telco for confidentiality or network integrity.
- Regulatory compliance says that you can't use the same X509 certificate
for different servers (The X509 DN must match the FQDN of server)

I want to transfer logs from clients to a centralized syslog server. I want
to ensure log confidentiality. I want to be sure that logs go the
legitimate syslog server.

Scenario A - RELP (or TCP syslog) without TLS: no confidentiality

Scenario B - RELP (or TCP syslog) over TLS, no certificate for server, no
certificate for client (just tls="on" in rsyslog conf) : some
confidentiality (won't resist IP spoofing or DNS poisoning). I can't be
sure that logs to the legitimate syslog server.

there are two ways that the logs could not go to the legitimate server

1. DNS spoofing: fix this by making an entry in /etc/hosts so that DNS is not used

2. IP spoofing: It is possible to make static entries in the arp table (assuming you are on the same subnet), but you should also monitor ARP for changes, or at least the cases where you have two different ARP responses for one IP.

If you can do this, then the worst that the telco can do is to monitor the connection, they can't insert themselves in the connection (which is what's needed to be a MITM, unless they have a cert)

Scenario C - RELP (or TCP syslog) over TLS, certificates for each side.
Security is OK... but thats quite impractical: i have to generate a
certificate for each syslog client. Certificate generation is an expensive
operation in my context (eg roughly 30 euros for one certificate), and
deploying them to clients automatically and securely is not trivial.

Create your own CA so you can use your own certs. This eliminates the cost, and since you can script this, it makes it easier to deploy them to the clients (although it's still not trivial)

see https://help.ubuntu.com/12.04/serverguide/certificates-and-security.html

http://www.ghacks.net/2009/09/16/create-your-own-certificate-authority-with-tinyca/ (tinyca is in the ubuntu repository)

So i was looking for something like :

Scenario D - RELP (or TCP syslog) over TLS
Client has: tls="on", tls.caCert, tls.authmode="name", tls.permittedpeer
(but NO tls.myCert, tls.myPrivKey)
Server has : tls="on", tls.myCert, tls.myPrivKey (but NO tls.authmode)

In scenario D: logs will most certainly go to the legitimate server. Log
confidentiality is ensured within transfer. Configuration is easy to
deploy. Only one X509 certificate to generate.

Uncovered risks with D: an attacker located inside the telco can
- swallow some client log (data loss), but can't read it.
- swallow some client log and send fake logs to the legitimate server.

I'm not saying your use case is invalid, I'm just saying that I don't think it was considered when the TLS support was added to rsyslog. I'll readily admit that I am not an expert in this area (I haven't needed to use encryption, yet), so I'm hoping that someone else with more knowlege will correct me if I'm wrong.

David Lang

Regards,
Stephane



2015-03-02 0:38 GMT+01:00 David Lang <[email protected]>:

I don't believe that this is currently supported. the main reason for
implementing this is almost always either to have the data encrypted when
going over the Internet or to prevent unknown/untrusted systems from
delivering logs to rsyslog. The mode where the server doesn't care who is
sending it logs but the client cares that it's sending to the right server
is not a use case that was considered as far as I know.

David Lang


On Mon, 2 Mar 2015, stephane martin wrote:

 Date: Mon, 2 Mar 2015 00:17:15 +0100
From: stephane martin <[email protected]>
Reply-To: rsyslog-users <[email protected]>
To: [email protected]
Subject: [rsyslog] TLS with RELP or TCP syslog: certificate just for the
      server
     ?


Hello,

i've been playing with rsyslog for a few months. The product is so great
:)

Just a quick question : i'd like to have a rsyslog server, offering RELP
and TCP over TLS to clients. So far, the configuration examples I've found
need the client to show certificates to the server.

Is it possible to have a scheme so that only the server has a X509
certificate, and the client just connects to it, like in a typical HTTPS
use case?

Regards,
Stephane
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T LIKE THAT.

 _______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T LIKE THAT.

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Reply via email to