On Thu, Dec 12, 2013 at 9:14 AM, Radu Gheorghe <[email protected]>wrote:
> Hi Luca, > > Maybe create a "whitelist" > array<http://www.rsyslog.com/filter-optimization-with-arrays/>of > allowed senders and then drop the messages? Or maybe do that from the > firewall (although one from the firewall's whitelist could easily spoof the > hostname variable). > > actually, the best cure is TLS-proteced syslog with mutual authentication. Of course I know that nobody wants to do that ;) Rainer > Best regards, > Radu > > > 2013/12/12 Luca Carettoni <[email protected]> > > > Hello folks, > > By googling for example configurations and templates, I've noticed a > fairly > > common insecure configuration and I would like to get your opinion on > this > > matter. > > > > It's a common practice to use property replacers (like %hostname% and > > %syslogtag%) to ship logs to specific files. > > For instance, $template logFile,"/var/log/%HOSTNAME%.log" and similar. > > > > By looking at the documentation and all those examples, it's however not > > clear that those properties are directly parsed by rsyslogd from the > > user-supplied event messages while trying to parse RFC3164-formatted > > messages. > > > > I started looking at the source code and noticed that those properties > are > > derived in pmrfc3164.c. > > A whitelist approach has been used to allow alphanumeric, ".", "_","-" > > chars thus preventing common security issues (e.g. directory traversal). > > Although it doesn't seem possible to override existent files either, a > > remote attacker would still be able to create new files and/or > directories. > > Eventually, this may allow to reach inodes limit and potentially result > in > > a denial of service. > > > > Besides removing property replacers, is there any other workaround (e.g. > > limit #events/sender/seconds)? > > > > Would it be possible to update the documentation (e.g. > > http://www.rsyslog.com/doc/property_replacer.html) and include those > > considerations? Kind of "use at your own risk" warning. > > > > Cheers, > > Luca > > > > -- > > > > Luca Carettoni <[email protected]> > > _______________________________________________ > > 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.
