Tripwire reports many violations but no errors

I have tripwire set up in Debian and it produces a report every day via
cron.

I get messages of this kind:

Section: Unix File System
-------------------------------------------------------------------------------

Rule Name Severity Level Added Removed Modified
--------- -------------- ----- ------- --------
Invariant Directories 66 0 0 0
Tripwire Data Files 100 0 0 0
* Other binaries 66 219 10 635
Tripwire Binaries 100 0 0 0
* Other libraries 66 499 315 3442
* Root file-system executables 100 0 0 92
* System boot changes 100 73 36 49
* Root file-system libraries 100 3 2 153
(/lib)
* Critical system boot files 100 66 0 10
* Other configuration files 66 60 5 573
(/etc)
* Boot Scripts 100 3 7 20
* Security Control 66 0 0 2
* Root config files 100 7 0 1
* Devices & Kernel information 100 10 0 0

Total objects scanned: 13724
Total violations found: 6292


However, at the end of the report it says:

================================================== =============================
Error Report:
================================================== =============================

No Errors

-------------------------------------------------------------------------------
*** End of report ***


I have no idea what these violations mean or whether they are serious.
Can anyone explain what is happening please?

AC

--
Using Linux GNU/Debian - Windows-free zone
http://www.acampbell.org.uk (book reviews and articles)
Email: replace "www." with "ac@"

Anthony Campbell <me@privacy.net> said:
>I have tripwire set up in Debian and it produces a report every day via
>cron.

Yep -- setting up tripwire so that it is useful yet doesn't drown you
in needless alerts is quite a task.

>I get messages of this kind:
>
> Section: Unix File System
>-------------------------------------------------------------------------------
>
> Rule Name Severity Level Added Removed Modified
> --------- -------------- ----- ------- --------
> Invariant Directories 66 0 0 0
> Tripwire Data Files 100 0 0 0
>* Other binaries 66 219 10 635

So, this means that since the tripwire database was last refreshed (I guess
this was when it was initially built, i.e. when you "set up" tripwire),
of files recorded in class "other binaries", 219 new files of this class
have been added, 10 of the initially existing ones have been removed and
635 of the initially existing ones have changed in some way.

Whether this is result of a break-in or just administrative work is up to
you to determine -- and similarly for the other classes (rule names).

>However, at the end of the report it says:
>
>================================================= ==============================
>Error Report:
>================================================= ==============================
>
>No Errors

Error would more or less be that a file required to exist has disappeared.

>I have no idea what these violations mean or whether they are serious.
>Can anyone explain what is happening please?

Basically you should refresh tripwire database after each time you do
a change to the system. This cannot be automated, since automating the
database refresh would more or less defeat any use of tripwire. You,
as the administrator, must "sign off" any differences reported by
tripwire (after checking that they were not result of malicious action)
so that these are not reported in future reports.

To find detailed lists of what has chnaged for each object tripwire reports
as changed, you an run "twprint -m r" for the latest tripwire report file.

If you absolutely trust that your system has not been compromised, and
that the current changes reported by tripwire are just results of
maintenance work, you could run "tripwire -m u -r reportfile -a" to
have your database updated with the current differences. After that,
start looking at the detailed difference lists for each tripwire run,
and check by them whether tripwire reports things that should not be
reported (f.ex. on my machine tripwire initially was set to report on
permissions of tty device files; as the permissions change based on
who is logged in on a terminal, tripwire was consistently complaining
about the permissions, so I changed tripwire configuration to not
check tty device file permissions). This'll gradually bring your
config file to sane settings, and tripwire starts to pay off -- explicitly
telling you about unexpected changes.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

On 2004-05-03, Juha Laiho <Juha.Laiho@iki.fi> wrote:
> Anthony Campbell <me@privacy.net> said:
>>I have tripwire set up in Debian and it produces a report every day via
>>cron.
>
> Yep -- setting up tripwire so that it is useful yet doesn't drown you
> in needless alerts is quite a task.
>
>>I get messages of this kind:
>>
>> Section: Unix File System
>>-------------------------------------------------------------------------------
>>
>> Rule Name Severity Level Added Removed Modified
>> --------- -------------- ----- ------- --------
>> Invariant Directories 66 0 0 0
>> Tripwire Data Files 100 0 0 0
>>* Other binaries 66 219 10 635
>
> So, this means that since the tripwire database was last refreshed (I guess
> this was when it was initially built, i.e. when you "set up" tripwire),
> of files recorded in class "other binaries", 219 new files of this class
> have been added, 10 of the initially existing ones have been removed and
> 635 of the initially existing ones have changed in some way.
>
> Whether this is result of a break-in or just administrative work is up to
> you to determine -- and similarly for the other classes (rule names).
>
>>However, at the end of the report it says:
>>
>>================================================ ===============================
>>Error Report:
>>================================================ ===============================
>>
>>No Errors
>
> Error would more or less be that a file required to exist has disappeared.
>
>>I have no idea what these violations mean or whether they are serious.
>>Can anyone explain what is happening please?
>
> Basically you should refresh tripwire database after each time you do
> a change to the system. This cannot be automated, since automating the
> database refresh would more or less defeat any use of tripwire. You,
> as the administrator, must "sign off" any differences reported by
> tripwire (after checking that they were not result of malicious action)
> so that these are not reported in future reports.
>
> To find detailed lists of what has chnaged for each object tripwire reports
> as changed, you an run "twprint -m r" for the latest tripwire report file.
>
> If you absolutely trust that your system has not been compromised, and
> that the current changes reported by tripwire are just results of
> maintenance work, you could run "tripwire -m u -r reportfile -a" to
> have your database updated with the current differences. After that,
> start looking at the detailed difference lists for each tripwire run,
> and check by them whether tripwire reports things that should not be
> reported (f.ex. on my machine tripwire initially was set to report on
> permissions of tty device files; as the permissions change based on
> who is logged in on a terminal, tripwire was consistently complaining
> about the permissions, so I changed tripwire configuration to not
> check tty device file permissions). This'll gradually bring your
> config file to sane settings, and tripwire starts to pay off -- explicitly
> telling you about unexpected changes.


Thanks for this explanation, which confirms what I suspected and
provides useful details. I do an upgrade from unstable most days which
no doubt explains the report. I'm beginning to wonder if it is worth
having tripwire there on a standalone system. I installed it after I had
to reinstall my system following a compromise, but keeping it up to date
seems to be fairly time-consuming.

AC

--
Using Linux GNU/Debian - Windows-free zone
http://www.acampbell.org.uk (book reviews and articles)
Email: replace "www." with "ac@"

Anthony Campbell <me@privacy.net> said:
>Thanks for this explanation, which confirms what I suspected and
>provides useful details. I do an upgrade from unstable most days which
>no doubt explains the report. I'm beginning to wonder if it is worth
>having tripwire there on a standalone system. I installed it after I had
>to reinstall my system following a compromise, but keeping it up to date
>seems to be fairly time-consuming.

It's somewhat time-consuming, but if you can restrict your updates
(_and_ check that the configuration file doesn't report unnecessary
changes), you could refresh the database manually after each update
(preferably running a check just before the update). But yes, it's
work, and I'm also considering whether running tripwire is worth
anything for me.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)