as I understand it, the answer right now is to use stunnel or something
similar (you could use ipsec or any other VPN between machines)
David Lang
On Mon, 3 Jan 2011, Mathieu Lemoine wrote:
Date: Mon, 3 Jan 2011 16:43:16 -0500
From: Mathieu Lemoine <[email protected]>
Reply-To: rsyslog-users <[email protected]>
To: [email protected]
Subject: [rsyslog] reliability/security (RELP/TLS) trade off
Hello,
I have looked for an answer in both Rainer's Blog and the rsyslog doc
(on rsyslog.com).
I am using rsyslog in a cloud environment (namely Amazon EC2).
Since I have several web servers and need centralized aggregation for
both easier management and reliable gross stats, I forward the syslog
messages toward a central instance.
Since the cloud environment should be considered as hostile (potential
MITM attacks and so on) and the system log are critical data, SSL/TLS
appears to be the best solution.
However It appears that TLS in rsyslog is available only for PTCP
transport and not RELP, at lest if I believe what's written on
http://www.rsyslog.com/doc/rsyslog_tls.html .
Moreover, although PTCP has increased reliability ("decreased
unreliability"?), as mentioned in various Rainer's blogposts, it is
still far to be reliable.
Although I don't need to be audit-grade reliable, I would still prefer
to have reasonable reliability and as far as I understand PTCP is not
even close to it.
My question is therefore the following :
Is there a solution appart from stunnel to have RELP over TLS ? and
btw, what about TLS authentication ?
It seems that currently we are faced with a trade-off between
reliability and security.
Since cloud-type architecture will be (in my opinion) more and more
used, I guess that could be something very relevant to have in
rsyslog.
Btw, referring to
http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html
Rainer speaks of double-acking.
Although the overhead and delay involved with double acking are very
low, I though re-acking with silent drop would be more efficient :
The receiver sends only one ack, if it is lost and the message is
repeated by the client (detected by the mean of, e.g., a sequence
number) the receiver drop the message (this avoid duplication) and
re-send the ACK.
This could be improved by sending NACK in case of "hole" in the
sequence numbers, triggering instant resending of previously dropped
messages.
Sequential number collisions could then be addressed with sliding windows.
If the message was dropped, it is simply resent by the client (after
an ACK timeout or a NACK reception) and if the ACK is lost, the
duplicated message does not appear but the ACK is sent again.
Imho, the sequence numbers and sliding windows do not yield neither
development nor complexity overhead because they still need to be
implemented with double-acking, in case of a losed reACK.
Well that was just my two cents on this idea.
It would be great if someone could keep me posted with respect to the
RELP/TLS issue.
Regards,
Mathieu Lemoine
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
