From owner-freebsd-questions@freebsd.org Fri Nov 20 17:39:02 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D53BA339A6 for ; Fri, 20 Nov 2015 17:39:02 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from cosmo.uchicago.edu (cosmo.uchicago.edu [128.135.70.90]) by mx1.freebsd.org (Postfix) with ESMTP id DE96019D8 for ; Fri, 20 Nov 2015 17:39:01 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: by cosmo.uchicago.edu (Postfix, from userid 48) id ACD41CB8C9D; Fri, 20 Nov 2015 11:38:54 -0600 (CST) Received: from 128.135.52.6 (SquirrelMail authenticated user valeri) by cosmo.uchicago.edu with HTTP; Fri, 20 Nov 2015 11:38:54 -0600 (CST) Message-ID: <19577.128.135.52.6.1448041134.squirrel@cosmo.uchicago.edu> In-Reply-To: <564F51BD.4080103@artem.ru> References: <564F51BD.4080103@artem.ru> Date: Fri, 20 Nov 2015 11:38:54 -0600 (CST) Subject: Re: Forbid user set file mtime in the past From: "Valeri Galtsev" To: "Artem Kuchin" Cc: freebsd-questions@freebsd.org Reply-To: galtsev@kicp.uchicago.edu User-Agent: SquirrelMail/1.4.8-5.el5.centos.7 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 17:39:02 -0000 On Fri, November 20, 2015 11:00 am, Artem Kuchin wrote: > Hello! > > > Is there any way to forbid users to set file modification time in the > past? > > I am asking because many php viruses somehow set modification time in > the past > and just checking what php files were created/modified for the last n > hours just does > not work at all. > I know, this is not an answer to you question. Still, relying on anything on compromised system for forensics is counter productive. Much better approach would be to keep checksums (and all from long listing including inode number) of all files on trusted clean ultimately secure machine. Another thing one can do is to compare all files with, say, backup on the time before the moment the bad even happened. No mater what time stamps are, if files differ from backup, there were modified _after_ that time point. But again, as always they advise, recovery from compromise begins with fresh system installation, patching, setting up whatever you choose for "file integrity" checks... Just my $0.02 Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++