Your message dated Wed, 29 Nov 2017 23:06:19 +0100
with message-id <[email protected]>
and subject line Re: rsyslog: does not clean TLS contexts on connection loss
has caused the Debian Bug report #804525,
regarding rsyslog: does not clean TLS contexts on connection loss
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
804525: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804525
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: rsyslog
Version: 8.4.2-1
Severity: important
Tags: security
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
We are using rsyslog to send logs from machine A to machine B through a
TLS-authenticated TCP connection.
Sometimes, the network between the two machines becomes unreliable. If
the TCP connections breaks without proper indication, the server side
does not seem to clean some context or state. This results in the
connection not being re-established after the network comes back, which
breaks logging on the client because the log buffers run over and Syslog
is designed to block in that case.
I could imagine this is security-relevant. *If* an admin sees need to
use TLS on Syslog, then they obviously have an untrusted network between
machines, so deliberately breaking the TLS connection and thus causing a
Denial of Service on the server becomes an attack vector.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQJOBAEBCAA4BQJWQGVJMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZQmxAAs07EusSEu0ZGw07m1g9d
wcMkiPKmE3rpzjPTFQkTGwP26l7x+1qKcOgPRQ5gaFWxHHUmVDpgCdU+RN5b2Yih
A8KAaoccKzwONhCecHFMLLbmjZFh6ZqI0OI1i4DUnfLb/zKWmcNMjh8LWBGdDC3T
rApopmBIGeOcnhvdHMIiSlkRl1av560eyEwrUW5A6p4OqS6CeWX8Kl5olMPtTnhO
0RsNqXCnQluQOO0oQA5G7WcNl9DHVj4VvUte8nbm+tN+3D1fTrGywQ65gIi9nPWQ
AHQ6lM2FPFLVv4QBejI9VT262u2BelrFMB5JGWZr2YsW7Jzzspq+s4Wn1PQqEJm2
i9t0A/4pTGBeJWs1wrVqVMGhNfWOZQczrtyYoE658flXv4fR2HalW2aoy9SWTtxs
i3//zQmMaEgKzmG8EI8PW8T/pVuBjuXOKCsV+CJkpLimIlwHt1+VClqUBtV0UVYp
zQsC+qeeHwWfLjpBhQ8lIfJQqsblR14hwESaXrcPV7wnsFjQx6ViIhQLn+b/ktOg
O9ihZ79n4xMPZjAhpDBvO8WYZT7nZnvjUbTXr86bf9eU7IJF7jcrlq80JnCfARR5
+DFSwgYY2cfGuPyuP4pYYc5HdKNPFiuF7SmodIwTndKBfbMSeLrJF+tlWNa7qT+Y
U+ZCTX3RsqS9Q6dgXcn3Nao=
=dy+L
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
Hi,
given the information in
https://bugzilla.redhat.com/show_bug.cgi?id=1279514#c6 I'm going to
close this bug report.
Here's the relevant part:
> The problem is resolved by having a queue for the forwarding action, allowing
> to get the network part asynchronous.
>
> E.g. :
> $ActionQueueType LinkedList
> $ActionQueueFileName forward_to_server
> $ActionResumeRetryCount -1
> $ActionQueueSaveOnShutdown on
> *.* @@<server>:10514 # forward everything to remote server
>
> See
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-working_with_queues_in_rsyslog.html
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
