Date: Tue, 27 May 2014 01:54:13 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: freebsd-security@freebsd.org, "Ronald F. Guilmette" <rfg@tristatelogic.com> Subject: Re: NEVERMIND! Message-ID: <20140527004708.U5669@sola.nimnet.asn.au> In-Reply-To: <86r43gr5nb.fsf@nine.des.no> References: <2218.1401075427@server1.tristatelogic.com> <86r43gr5nb.fsf@nine.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 May 2014 16:11:52 +0200, Dag-Erling Smørgrav wrote: > > "Ronald F. Guilmette" <rfg@tristatelogic.com> writes: >> I forgot that newsyslog(8) should limit the size of /var/log/messages, and >> that as long as you limit the size of that to a reasnable value, and as >> long as you have newsyslog(8) only keeping a finite & reasonable number >> of "rotated out" copies, then /var won't fill up. > It can still happen, since newsyslog only runs once per hour. If > /var fills up between two newsyslog runs, there is no guarantee that > the space freed up by deleting the oldest logs is sufficient to > compress the newest log. The only way to really handle this issue > would be to fold newsyslog into syslog. Mitigating that - in the case of single repeating messages at least - is that syslog accumulates these and reports totals at a certain interval. At 5.5-stable (yes, I know) it was 10 minutes, just one example: May 16 19:17:05 x inetd[5768]: pop3 from 92.247.169.210 exceeded counts/min (limit 4/min) May 16 19:17:26 x last message repeated 30 times May 16 19:19:37 x last message repeated 55 times May 16 19:29:44 x last message repeated 450 times May 16 19:39:44 x last message repeated 367 times [.. every 10 minutes until ..] May 16 22:09:42 x last message repeated 349 times May 16 22:10:57 x last message repeated 54 times Of course just to blow my case, tonight I find 967 lines in 82418 bytes from two hosts apparently in Mexico doing the same gig in parallel, for less than two minutes - over a very slow ADSL line. syslog doesn't need the complication of attempts at such pattern matching. Rather than merging the two, might syslog trigger adhoc rotations by newsyslog - of a particular log, not all - after learning how to measure 'stress', perhaps by rates of delta filesize, diskspace consumption etc? Then newsyslog would only need to learn how to be so invoked? just a thought, Ian From owner-freebsd-security@FreeBSD.ORG Mon May 26 20:01:56 2014 Return-Path: <owner-freebsd-security@FreeBSD.ORG> Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCD5B2BB for <freebsd-security@freebsd.org>; Mon, 26 May 2014 20:01:56 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id B2488262C for <freebsd-security@freebsd.org>; Mon, 26 May 2014 20:01:56 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 0FFDD3ACAE for <freebsd-security@freebsd.org>; Mon, 26 May 2014 13:01:56 -0700 (PDT) From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Re: NEVERMIND! In-Reply-To: <86r43gr5nb.fsf@nine.des.no> Date: Mon, 26 May 2014 13:01:56 -0700 Message-ID: <7159.1401134516@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" <freebsd-security.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-security>, <mailto:freebsd-security-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security/>; List-Post: <mailto:freebsd-security@freebsd.org> List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, <mailto:freebsd-security-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 26 May 2014 20:01:56 -0000 In message <86r43gr5nb.fsf@nine.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> wrote: >"Ronald F. Guilmette" <rfg@tristatelogic.com> writes: >> I forgot that newsyslog(8) should limit the size of /var/log/messages, >and >> that as long as you limit the size of that to a reasnable value, and as >> long as you have newsyslog(8) only keeping a finite & reasonable number >> of "rotated out" copies, then /var won't fill up. > >It can still happen, since newsyslog only runs once per hour. If /var >fills up between two newsyslog runs... Yes. Good point. So should I file a PR on this, or what? My first thought is that perhaps what's needed is per-account logging quotas, so that loging could be limited... on a per account basis... much as the usage of memory and other finite resources are. However it occurs to me that perhaps the scenario I mentioned is only one of a number of plausible scenarios that might result in total exhaustion of /var between hourly newsyslog runs. For example, I can easily envision remotely filling up your /var simply by sending you, in rapid succession, a sufficient quantity of malformed http requests, or perhaps even just an endless set of minimalist HELO/QUIT sequences to your mail server. Of course, none of these kinds of attacks will really be all that harmful to any well-attended machines that are being properly monitored by even minimally competent system administrators. But given that more and more machines these days run as "appliances" for long periods with no monitoring whatsoever, attacks which exhaust /var, or which attemp to do so, might actually be an issue worthy of attention.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140527004708.U5669>