From owner-freebsd-stable@FreeBSD.ORG Sun Apr 17 06:06:51 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AC7716A4CE for ; Sun, 17 Apr 2005 06:06:51 +0000 (GMT) Received: from gizmo04bw.bigpond.com (gizmo04bw.bigpond.com [144.140.70.14]) by mx1.FreeBSD.org (Postfix) with SMTP id D6A9043D3F for ; Sun, 17 Apr 2005 06:06:49 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: (qmail 29341 invoked from network); 14 Apr 2005 03:00:07 -0000 Received: from unknown (HELO bwmam02.bigpond.com) (144.135.24.72) by gizmo04bw.bigpond.com with SMTP; 14 Apr 2005 03:00:07 -0000 Received: from cpe-138-130-183-186.nsw.bigpond.net.au ([138.130.183.186]) by bwmam02.bigpond.com(MAM REL_3_4_2a 17/9094762) with SMTP id 9094762; Thu, 14 Apr 2005 13:00:07 +1000 Received: (qmail 96289 invoked by uid 1000); 14 Apr 2005 02:59:50 -0000 Date: Thu, 14 Apr 2005 12:59:49 +1000 From: Andrew Reilly To: freebsd-stable@freebsd.org Message-ID: <20050414025949.GA94683@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Misleading security message output X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2005 06:06:51 -0000 I had an interesting experience, this morning. The nightly security message from a CVS server machine that runs a version of FreeBSD-4 had arrived, and it claimed that someone who hadn't done any work for us for some considerable time had had three failed login attempts, late that night. Curious. After much hunting around, and checking perimeter logs, it turned out that nothing of the sort had happened. The security log script had been fooled by the age of the messages.0.gz file, which contained messages from more than a year ago. The search pattern "$yesterday" doesn't contain a year, because log file timestamps don't contain years. The log file was so old because rotation is determined by size, and this machine simply doesn't have much to log, despite being used daily. It never goes down, and is basically completely stable. This could be avoided, perhaps, with a NetBSD-style backup/diff mechanism, or (incompatibly) with daemontools/multilog-style 64-bit time stamps in the log files. It can be worked-around by forcing faster log-file rotations, now that I know about the problem. I can't think of a really good widely-applicable solution, using the existing framework, though. Suggestions? -- Andrew