On Tue, May 6, 2014 at 3:11 PM, Thomas D. <[email protected]> wrote: > Hi, > > Rainer Gerhards wrote: > > Well, that's actually a broader question. You can repeat it for any other > > output. Granted, it may not disturb the admin from doing something but an > > attack could still exhaust resources like file system or database space > or > > ... > > I understand. > > > > The key point is to guard the ingres points. That's even better to do > today > > than in the distant past, because rate-limiting applies on a per-process > > basis. > > When I read "per-process" basis I am currently thinking about logger > which will bypass the MsgReduction feature because each logger message > comes from a new process.. > > you can't get everything. And as I wrote, whatever you do is too simplistic for any decent attack. We could apply rate-limiting without looking at the process (maybe there even is an option for that, if not we could implement it, but nobody ever really asked for it...). Then, the runaway process case (which I consider more important) is much worse, because you don't detect dupes as messages from different processes. It's one way or the other, these are conflicting goals and you can't get both. IMHO the current way makes most sense.
> > >> Now I wanted to see if it is possible to disturb the administrator > >> (root) from doing its job as user. So I run > >> > >> $ logger -p local0.alert -t flood-test I am flooding root > >> > >> as user in loop. > >> > >> The messages appeared as expected in root's terminal, so root was unable > >> to do something. The messages appeared from "syslogd". > >> > >> Also, "# mesg n" as root didn't stop that. > >> > >> Like I have learned today, "$RepeatedMsgReduction = on" just before the > >> omusrmsg actions wouldn't help when the "attacker" uses logger. > >> > > > > wouldn't stop any decent attacker. I would just insert random gibberish. > > Rate-limiting, however, does not look at the message content but at the > > message rate, and it will stop this -- except, if it different sources > > (e.g. processes) are used. > > Rate-Limiting at queue level, right? > > At the input level. Have a look at imudp doc: http://www.rsyslog.com/doc/imuxsock.html search for "ratelimit". Please also have a look here: http://blog.gerhards.net/2012/10/rate-limiting-in-rsyslog-732.html > > >> How to react on this issue when this will happen? Stopping (r)syslog is > >> not an option, because this will stop logging (this is what an attacker > >> would want... doing something which won't be logged). > >> > >> And this doesn't need to be an attack at all. Think about a RAID > >> monitoring tool which goes crazy when your RAID degraded... > >> > >> > > That's a case for rate-limiting. Note that we had imuxsock ratelimiting > > active by default for some time, and received soooo many complains about > > missing log records that we disabled it by default. > > > > Another thing that you can do (and probably should) is to make sure that > > only such and such many messages get through during a time interval. > There > > is an option to specify how often an action at most should be executed. > It > > is usually used with ommail and I think this would solve your case. A > > sample is in the ommail doc. > > I tested the same scenario with > > > *.emerg action( > > type="omusrmsg" > > Users="*" > > action.execOnlyOnceEveryInterval="10" > > ) > > and it seems like that this is the way to go, thanks. > > 10s between each "interruption" should be enough time to stop whatever > went crazy and no messages will be lost because other rules are still > logging *.emerg messages to disk. > > yup :) Rainer > > -Thomas > > _______________________________________________ > 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.
