Probably you can use something like fail2ban. It requires from rsyslog
write not only error messages but client ip address too. I'm not sure
that it's possible now with openssl or gnutls modules/
On 17/04/2019 16:59, Alan Martinovic via rsyslog wrote:
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.
_______________________________________________
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.
