[SOLVED] Objects removed since Tripwire database last updated

OtagoHarbour · 05-26-2013, 01:03 PM

I have just installed Tripwire on a freshly installed Debian 7.0.0.

For installation I ran

Code:

sudo apt-get install tripwire

I then did

Code:

sudo tripwire --init

I then edited tripwire --init and commented out all the files that had generated a

Code:

### Warning: File system error.
### Filename: /whatever
### No such file or directory

message. I then ran

Code:

sudo tripwire --update-policy --secure-mode low /etc/tripwire/twpol.txt

and got a bunch of error messages like this

Code:

### Warning: Policy Update Removed Object.
### An object has been removed since the database was last updated.
### Object name: /proc/547/net/dev_snmp6
### Continuing...
### Warning: Policy Update Removed Object.
### An object has been removed since the database was last updated.
### Object name: /proc/547/net/dev_snmp6/eth0
### Continuing...
### Warning: Policy Update Removed Object.
### An object has been removed since the database was last updated.
### Object name: /proc/547/net/dev_snmp6/lo
### Continuing...
### Warning: Policy Update Removed Object.
### An object has been removed since the database was last updated.
### Object name: /proc/547/net/snmp6
### Continuing...
### Warning: Policy Update Removed Object.
### An object has been removed since the database was last updated.
### Object name: /proc/547/net/sockstat6
### Continuing...

These files had gererated

Code:

### Warning: File system error.
### Filename: /whatever
### No such file or directory

errors when I ran the --init operation.

Are these messages something I should be concerned about?

Thanks,
Peter.

unSpawn · 05-26-2013, 01:29 PM

First of all the message speaks for itself: by updating the policy file, and consequently updating the database, the file set has changed. This should be of concern if files go missing that should be monitored or if you have made certain you did not update the policy file. Secondly you probably do not want to monitor directory contents of virtual file systems (virtual as in 'grep ^nodev /proc/filesystems') if they contain transient entities (/proc/[0-9]*/) or if it holds a large amount of entities that can't be written to (/sys) even as root account user. Finally do realize AIDE and tripwire are passive, post-incident audit tools: they only audit the system and warn you when you run them manually or via an at or cron job. Examples of active, continuously auditing services are the auditd service and Samhain (using its inotify feature).

OtagoHarbour · 05-26-2013, 03:06 PM

Quote:

Originally Posted by unSpawn

First of all the message speaks for itself: by updating the policy file, and consequently updating the database, the file set has changed. This should be of concern if files go missing that should be monitored or if you have made certain you did not update the policy file. Secondly you probably do not want to monitor directory contents of virtual file systems (virtual as in 'grep ^nodev /proc/filesystems') if they contain transient entities (/proc/[0-9]*/) or if it holds a large amount of entities that can't be written to (/sys) even as root account user. Finally do realize AIDE and tripwire are passive, post-incident audit tools: they only audit the system and warn you when you run them manually or via an at or cron job. Examples of active, continuously auditing services are the auditd service and Samhain (using its inotify feature).

It looks like the objects being removed are all objects that I should not monitor anyway. I will look into Samhain.

Thanks,
Peter.