It seems WAF[1] (Web Application Firewall) was the concept I was looking for. Seems like the safest option would be to set up a reverse proxy in front of rsyslog with something like ModSecurity[2].
In the conceptual scenario, the job of the WAF would be to: 1. unencrypt incoming connection (that would have to be taken away from rsyslog) 2. drop connections that don't follow certain rules. Perhaps a regex of the log content 3. pass the (now unencrypted connections) connections to rsyslog This is just a conceptual scenario, not clear on the feasibility. It seems to save rsyslog from connections that aren't legit logs. I might be missing something essential complexity which this reverse proxy might introduce, like would queuing be affected by the middle man... etc. Comments are welcome :) On Wed, Apr 17, 2019 at 3:15 PM Alan Martinovic <[email protected]> wrote: > > Hey Rainer, > thanks for the feedback. > The IP layer filtering isn't applicable in my case. > Don't know what IPs the clients might end up having. > > > On Wed, Apr 17, 2019 at 2:50 PM Rainer Gerhards > <[email protected]> wrote: > > > > If you expose the host to the Internet, you should at least install > > iptables or similar solution. There is some access control directly in > > rsyslog, but using ip layer firewall is much more robust (by design). > > > > Rainer > > > > El mié., 17 abr. 2019 a las 14:14, Alan Martinovic via rsyslog > > (<[email protected]>) escribió: > > > > > > Hey, > > > I have a rsyslog server which will accept everything that want's to log > > > TLS > > > encrypted data to it. (Server - anon, Client - x509/name) > > > > > > It turned out the Internet is much more interested in spamming my logging > > > server > > > then I thought when doing the implementation. > > > So now I'm getting a lot of: > > > > > > ``` > > > gnutls returned error on handshake: An unexpected TLS packet was received. > > > unexpected GnuTLS error -110 in nsdsel_gtls.c:178: The TLS connection > > > was non-properly terminated. > > > unexpected GnuTLS error -15 in nsdsel_gtls.c:178: An unexpected TLS > > > packet was received. > > > gnutls returned error on handshake: Error in the pull function. > > > ``` > > > > > > At some point I couldn't send any more logs before restarting rsyslog. > > > The service was still running and there were no exceptional logs to relate > > > to that, besides the upper ones which occur in working conditions also. > > > > > > Even if I introduce client authentication on the server side, that > > > wouldn't help much against bad TLS packets from unexpected clients. > > > > > > Anyways, would like to hear your thoughts on how to harden an anon server. > > > Is it possible to drop connections by log content? > > > Or perhaps install some kind of an application layer firewall to > > > protect rsyslog? > > > > > > Be Well, > > > Alan > > > _______________________________________________ > > > 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.
