On Tuesday 18 March 2008 02:11:15 pm Gerrard Geldenhuis wrote: > The only arguments for keeping the feature that I got on my lug was the > preservartion of disk/network IO. > > I think to prevent DOS attacks is a valid argument but as you said can > be easily circumvented by randomizing messages. I'm afraid it's not true in all cases. What if you do DOS attach not directly to do rsyslog, but via other daemon. In situation when you can't send message directly to syslog, but you can make some daemon generate message for you. This message would be probably always the same content.
> To safeguard against dos attacks you could have a monitor that monitors > for extra ordinary amount of traffic and then generate a snmp trap. > Whether that should be a rsyslog plugin or part of other software is > open to debate. > > Regards > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:rsyslog- > > [EMAIL PROTECTED] On Behalf Of Rainer Gerhards > > Sent: 18 March 2008 11:42 > > To: rsyslog-users > > Subject: Re: [rsyslog] Feedback requested "Last message logged n > > times"... > > > Good discussion, thanks all :) ... some more points below ... > > > > > > I have asked the question on a local lug to get some more > > opinions. > > > I > > > > > > will post the results if any here. > > > > > > I did the same. :) > > > > > > The only arguments against removal I have received until now were: > > > > > > 1. DoS (but nobody explained how) > > > > I think this is along the lines of making it easy to flood the log > > with > > > similar messages. If that's the case, I think it is a (too) weak > > argument because an attacker could easily include a random pattern > > inside the message. > > > > HOWEVER, the current logic indeed prevents flooding the log from equal > > messages, e.g. if a process runs wild. > > > > > 2. cleanness of logs (relative) > > > > > > I'm thinking about forwarding discussion to fedora-devel :) > > > > Excellent. > > > > Maybe there are also alternatives to the current behavior, something > > in > > > between. Right now, the core engine does this, so the reduction > > capability is inherent to every action (except if an action > > specifically > > > forbids it, because it can not intelligently handle it - e.g. database > > writers). So it applies to forwarding, snmp, whatever, ... One > > alternative would be to remove it from the core engine and move it > > into > > > the *file write* output plugin (omfile). This has its subtleties, too, > > so I don't like to take that approach lightly. Plus, it than means > > that > > > the network may become spammed. I think one core requirement is to > > find > > > people who actually *intentionally* use this feature and ask for their > > reasoning. That will probably be the best way to tell us if its really > > needed. And, of course, we need to weigh the negative effects of it > > against these con-points. > > > > Rainer > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
