On Wed, Aug 24, 2005 at 05:54:36PM +0100, Jose Manuel dos Santos Calhariz wrote: > tripwire detected that the date of two binaries, bash and nano, > changed. I have looked into the logs and between the two runs of > tripwire, the machine didn't rebooted or had new software instaled. > > As I don't remeber a good reason for a system file change is date, I > am asking for your experience. There is no "good" reason, but a sysadmin might have changed this inadvertently - if /usr is not mounted 'ro' - with a bad placed 'touch' command. If you want to be really sure that they have not been tampered with, take the system offline (preferably disconnecting the power cord if you can afford it), and either a) boot the system up with a forensic CD (do not use a Knoppix CD, since that might mount your local partitions automatically) or a rescue CD (the recovery console of the installation CD might be used for this although I have not done the steps below in that environment) or b) take the hard disk drive to another system And then: mount the partitions (use the following mount options: ro, nodev, noexec, nosuid, noatime), take a MD5sum of bash and nano and compare it with trusted sources (i.e download the bash binary packages you were using or take the sums from /var/lib/dpkg/info/bash.md5sums if you have another system that runs the same binary versions) and compare it with the MD5sum reported by Tripwire and with the MD5sum of the trusted source binary. If it matches you are ok. In any case you might want to use 'debsums' with the --root option to do a full MD5sum check on the harddisk, however). If they don't match, assume it has been compromised, recover the data (if you don't have alternative backups, of course) you believe cannot be recovered (if that includes binaries or scripts you better treat them with care and review them before reusing them), build a new system from scratch and restore the data there. Not nice, but that's the only way to make sure the system has not been compromised. Cursory analysis with the system booted up can be fooled due to rootkits (either through binary substitution or kernel-level changes). Regards Javier PS: If you are _very_ paranoid you can check the SHA-1 sum of those binaries too (use 'sha1sum')
Attachment:
signature.asc
Description: Digital signature