This supports the use of rkhunter and running it once on first install but you can manually find file changes systematically by becoming root and going to the top level directory and running “find -ctime 1”, “find -ctime -2” etc ad infinitum until you find all files that may have been compromised. This method will not find deleted files so some expertise in the Linux file system is necessary when not using rkhunter.
Thanks, Michael Lazin On Mon,May 9, 2022 at 4:04 AM Elmar Stellnberger <[email protected]> wrote: > Am 09.05.22 um 00:48 schrieb Tomasz Ciolek: > > 5. have we eliminated other causes of file mismatch - bad/incomplete > > updates, corrupted HDD, bad RAM, user error ? > > If exactly such files have been changed where there is reason to > manipulate them for a rootkit then one shall assume unequivocally that > there is a rootkit installed. With bad RAM you get a system crash and > with a physically bad hard disk you get filesystem errors on fsck, none > of which you get with a rootkit where only certain files have been > manipulated intentionally. A broken update could theoretically result in > a singleton file of half the size. Usually running programs keep to use > the old version of the file under Linux while newly issued open > operations on the same file name will use the file as replaced by an > update. A file of half the size would however result in an unusable > program, none of which you would usually observe with a rootkit. > > Elmar > > -- Michael Lazin .. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.
