[Software] Tripewire report: only inodes changed

[sylvain_48]

Hello!

My recent Tripewire report has switch my mind into a paranoia state...

Several software in /sbin, /bin, etc. are noticed as changed. But when I look deeper in the report it seems that only the inode has changed for a great number of these binaries. The size, MD5 and every over properties did not change.

What could be the explanation?

Thanks!

[Aki]

Hello,

What is your Debian installed version ?

Last 10 February, Debian stable (bookworm) was upgraded from version 12.4 to 12.5. As a result, many files changed when you upgraded.

Can you please confirm you did the upgrade ?

Hope this helps. Please let me know.

[sylvain_48]

Hello,

Thank you for your help.
Yes, I keep my system up to date.
My daughter told me the problem could come from the use of an old SSD (10 years). Indeed, the files concerned are on this drive...

[Uptorn]

I also run file integrity monitoring and it's maddening the little things that can trip it. I've learned not to immediately jump to "it's compromised!" and to poke around when these changes show up. For some reason my /root/.less-hst had been showing as changed, and with a bit of digging I've found that my search queries while viewing config files with root privs in pager and vim tiny were updating the file. I know they're mine because I remember making those lookups.

Would you mind sharing which files have had inode information changed?

My daughter told me the problem could come from the use of an old SSD (10 years). Indeed, the files concerned are on this drive...

I would be curious how she arrived at such a conclusion.

[Aki]

Hello,

My daughter told me the problem could come from the use of an old SSD (10 years). Indeed, the files concerned are on this drive...

The first inode changes also when the file is moved. Did files reported by tripwire were moved ?

[sylvain_48]

Hi!

Sorry for my late answer.
Thank you for your replies.

I have dug much deeper in my log. It's not so easy because, as far as I know, Tripewire has no tool to do that simply, with a GUI for example.

I now understand that the files with changed inode but with the same MD5 are simply files of updated packet that have not been changed. Like "exim files", it seems that only the file "exim4" has changed. All over files of this packet did not changed, but they where written on the disk. As a result, there inode changed and there modification time too. Tripwire saw that and report it.

There's still a question concerning the file "synaptic". It didn't change at all but it's inode. The modification time did not changed. The packet has been updated on Feb 10 2024.
Size: 838232
Modify Time: sat. 11 feb. 2023 09:56:53
Blocks: 1640
CRC32: C5EgSa
MD5: DldgQRJ2Q85hfsfOazyIkg

Concerning the directories /bin and /sbin I must apology: today I can't find them in my logs.

So... I wonder if it is a good idea too use a tool like Tripwire for a final user like me. If a real problem occurs on my desktop, I don't think I would be able to find it without spending too much time. Perhaps I didn't tune my Tripwire well...

[Aki]

Unless your computer use puts you at particular risk, tripwire may not be necessary.
If there is no particular risk, there is no need for tripwire.

[Uptorn]

Unless your computer use puts you at particular risk, tripwire may not be necessary.

What kind of use constitutes particular risk?

[Aki]

Unless your computer use puts you at particular risk, tripwire may not be necessary.

What kind of use constitutes particular risk?

Sorry, my mistake. I meant "If there is no particular risk, there is no need for tripwire.". Thanks for pointing that out.

[Uptorn]

Not pointing anything out, but a genuine question. Aside from servers hosting extensive services, I can think of few cases where an end user desktop might benefit from integrity monitoring. May elaborate on that later on those narrow cases.