Consequently, you need to use a Syslog implementation that supports TCP, either non-standard raw TCP or one of the newer standards like RFC 3195 (RFC 3195 supports encryption by itself, so it is best to check first if your application supports this – if it does, this is better than setting up a tunnel). As such, classical UDP-based syslog can not be used for tunneling. Tunneling, as done by stunnel, requires connection oriented communication. As such, it is vital that the portal and the respective program that is talking to it are on the same machine, otherwise data would travel partly unencrypted. The transfer to the portals is done via unencrypted communication. Stunnel, in turn, takes the data received from the client, encrypts it via ssl, sends it to the remote tunnel portal and that remote portal sends it to the recipient process on the remote machine.
#Stunnel tutorial software
The non-ssl aware client and server software is configured to not directly talk to the remote partner, but to the local (s)tunnel portal instead.
Both on the client and on the server machine, tunnel portals are created.
The free stunnel project provides a way to use ssl communication for any non-ssl aware client and server (daemon).
It is a mini-howto that primarily focusses on the Windows side because there are many good descriptions for the UNIX/Linux side. This article describes why and how this can be done. Windows Event Log data can securely be forwarded to a UNIX/Linux based syslogd via stunnel.
0 kommentar(er)
