As I understand your situation I don't think there's much you can do.
The port scans and connection attempts will come, thousands of them
every day. Your best option is to hide your listener on a port no one
uses, and instruct your clients to use that port number. This doesn't
eliminate the scans and connection attempts, it only reduces the number
because most attacks and probes are against known and high reward targets.
As an example I moved a publicly facing SSH server to listen on a port
other than 22 and the attack load dropped by several orders of magnitude.
Regards,
On 4/17/19 8:15 AM, Alan Martinovic via rsyslog 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.
