You are not logged in.
Hello everyone,
I'm doing differential backups using dar, and dar says:
SECURITY WARNING! SUSPICIOUS FILE /usr/include/kasten2/abstractview.h: ctime changed since archive of reference was done, while no other inode information changed
This warning is printed many times for many files in the follwing locations:
/etc/xdg/*.knsrc
/usr/include/{some kde applications / framework}/
/usr/include/qt4-32/
/usr/include/KDE/
/usr/share/{some KDE application}/
/usr/share/doc/{path to some kde docs}
/usr/lib/qt/
/usr/lib/perl5/vendor_perl/SVN/
/usr/lib/kde4/
/usr/bin/krdb
/var/cache/man/[/*/]
While I can turn off these warnings, I would like to know the reason for them. I will quote what the dar website says about this warning:
When dar reports the following message:
SECURITY WARNING! SUSPICIOUS FILE <filepath>: ctime changed since archive of reference was done, while no inode or data changed
You should be concerned by finding an explanation to the root cause that triggered dar to ring this alarm. As you probably know, a unix file has three dates:
atime is changed anytime you read the file's contents or write to it (this is the last access time)
mtime is changed anytime you write to the file's data (this is the last modification time)
ctime is changed anythime ou modify the file's attributs (the is the last change time)
In other words:
if you only read the data of file, only its atime will be updated
if you write some data to a file, its atime and mtime will change, ctime will stay unchanged
if you change ownership, permission, extended attributes, etc, only ctime will change
if you write to a file and modify its atime or mtime to let think the file has not been read or modified, ctime will change in nay case.
Yes, the point is that in most (if not all) unix systems, over the kernel itself, user program can also manually set the atime and mtime manually to any arbitrary value (see the "touch" command for example), but to my knowledge, no system provides a mean to manually set the ctime of a file. This value cannot thus be faked.However, some rootkits and other nasty programs that tend to hide themselves from the system administrator use this trick and modify the mtime to become more difficult to detect. However the ctime keeps track of the date and time of their infamy. However, ctime may also change while neither mtime nor atime do, in several almost rare but normal situations. Thus, if you are faced to this message, you should first verify the following points before thinking your system has been infected by a rootkit:
have you added or removed a hardlink pointing to that file and this file's data has not been modified since last backup?
have you changed this file's extended attributs (including Linux ACL and MacOS file forks) while file's data has not been modified since last backup?
have you recently restored your data and are now performing a differential backup taking as reference the archive used to restore that same data? Or in other words, does that particular file has just been restored from a backup (was removed by accident for example)?
have you just moved from a dar version older than release 2.4.0 to dar version 2.4.0 or more recent?
How to know atime/mtime/ctime of a file?
mtime is provided by the command: ls -l
atime is provided by the command : ls -l --time=atime
ctime is provided by the command : ls -l --time=ctime
Note: With dar version older than 2.4.0 (by default, unless -aa option is use) once a file has been read for backup, dar set back the atime to the value it had before dar read it. This trick was used to accomodate some programs like leafnode (NNTP caching program) that base their cache purging scheme on the atime of files. When you do a backup using dar 2.3.11 for example, file that had their mtime modified are saved as expected and their atime is set back to their original values (value they had just before dar read them), which has the slide effect to modify the ctime. If then you upgrade to dar 2.4.0 or more recent and do a differential backup, if that same file has not been modified since, dar will see that the ctime has changed while no other metadata did (user, ownership, group, mtime), thus this alarm message will show for all saved files in the last 2.3.11 archive made. The next differential backup made using dar 2.4.0 (or more recent), the problem will not show anymore.Well, if you cannot find an valid explanation from the one presented above, you'd better consider that your system has been infected by a rootkit or virus and use all the necessary tools (see below for examples) to find some evidence of it.
Rootkit Hunter
Unhide
clam anti-virus
and others...Last point, if you can explain the cause of the alarm and are annoyed by it (you have hundred of files concerned for example ) you can disable this feature adding the "-asecu" switch to the command-line.
I did a check with rkhunter and unhide, but those didn't find any suspicious files.
I'm asking whether this is normal behavior or I should worry about a malware infection.
Thank you, David
Offline