| View previous topic :: View next topic |
| Author |
Message |
jagdpanther
l33t
Joined: 22 Nov 2003
Posts: 729
|
 Posted: Fri Feb 24, 2017 6:20 pm Post subject: tripwire dies with Fatal Exception |
 |
|
Tripwire has been running well for years on my Gentoo system. Today, after a udev upgrade, I receive a "*** Fatal exception: std::exception" when I try to run tripwire. I did try re-emerging tripwire, but after a successful emerge, I receive the same error when trying to run tripwire:
| Code: | # /usr/sbin/tripwire --check -v
Open Source Tripwire(R) 2.4.3.1.0 built for x86_64-pc-linux-gnu
Open Source Tripwire 2.4 Portions copyright 2000 Tripwire, Inc. Tripwire is a registered
trademark of Tripwire, Inc. This software comes with ABSOLUTELY NO WARRANTY;
for details use --version. This is free software which may be redistributed
or modified only under certain conditions; see COPYING for details.
All rights reserved.
Opening configuration file: /etc/tripwire/tw.cfg
This file is encrypted.
Opening key file: /etc/tripwire/site.key
Opening key file: /etc/tripwire/runone-local.key
Opening database file: /var/lib/tripwire/runone.twd
This file is encrypted.
*** Fatal exception: std::exception
*** Exiting... |
Any ideas on how to fix this?
Last edited by jagdpanther on Fri Feb 24, 2017 6:33 pm; edited 1 time in total |
|
| Back to top |
|
 |
jagdpanther
l33t
Joined: 22 Nov 2003
Posts: 729
|
| Posted: Fri Feb 24, 2017 6:33 pm Post subject: |
|
|
| This is not a udev issue. I see that my cron.daily run of tripwire failed Early today, before the udev upgrade. The cron.daily tripwire run did work two days ago. |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Fri Feb 24, 2017 6:51 pm Post subject: |
|
|
You may need to rebuild the "encrypted database" using `tripwire --init`
Edit to add, if runone.twd is "corrupted," you should wonder how that happened. I don't believe an update to libcrypto or anything else involved in building tripwire will throw this sort of error. I'm sure we can get the error to go away, but that doesn't answer why you suddenly got this error. Did somebody try to cover their tracks? or has your filesystem just developed a random error "there"?
One more edit to add: you have a backup database file. It goes back to "before you last updated the database," and is going to be the same name as the database with ".bak" appended. Try running `tripwire --check --dbfile [full path to and mae of .bak file]` |
|
| Back to top |
|
|
jagdpanther
l33t
Joined: 22 Nov 2003
Posts: 729
|
| Posted: Fri Feb 24, 2017 7:18 pm Post subject: |
|
|
Yes rebuilding the tripwire database "fixed" the issue.
Yesterday, after an 'emerge --update --deep ....' I ran '/etc/cron.daily/tripwire' by hand and then '/usr/sbin/tripwire -m u -r runone-201702....' to account for the system changes. I wonder if my 'tripwire -m u' did something to the data base. I may start running an additional /etc/cron.daily/tripwire after future /usr/sbin/tripwire -m u' to ensure I don't do something bad to the tripwire database. |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Fri Feb 24, 2017 7:32 pm Post subject: |
|
|
I don't recall ever triggering a corrupt database with the --update thing, which I do fairly often.
A few bash aliases for your consideration ...
| Code: | alias last.tw.report='echo `ls -t /var/lib/tripwire/report/* | head -1`'
alias tw.check='tripwire --check --quiet > /dev/null 2>&1'
alias tw.report='twprint --print-report -t 1 -r `last.tw.report`'
alias tw.update='tripwire --update -r `last.tw.report`' |
After a world update, I run "tw.check" to catch the stuff the emerge changed, then "tw.update" to get the database in sync with the emerge. I wonder if your database got munged on account of referring to a "stale" report file. it shouldn't. Tripwire does a good job of reporting report/data mismatch when you try to update from a stale report.
Edit to add, for those reading along, `tripwire -m u` is synonymous with `tripwire --update` |
|
| Back to top |
|
|
jagdpanther
l33t
Joined: 22 Nov 2003
Posts: 729
|
| Posted: Fri Feb 24, 2017 10:23 pm Post subject: |
|
|
| Quote: | | I don't recall ever triggering a corrupt database with the --update thing, which I do fairly often. |
I agree and run update about once a week.
Paranoia ON
Because it appears that this tripwire database corruption occurred Thursday evening this is what I did:
1. moved /etc/tripwire to /etc/tripwire-keep and /var/lib/tripwire to /var/lib/tripwire-keep.
2. restored /etc/tripwire and /var/lib/tripwire from the early Thursday morning backups.
3. ran ' tripwire --check' (which worked ... no corruption this time)
4. from /var/lib/tripwire/report I ran
'twprint --print-report -t 1 -r runone-20170224-....twr'
5. I looked through the report and saw all of the things I expected from my 'emerge --update ...', re emerge of tripwire, etc. I guess this means it was probably database corruption and not malicious activity.
Paranoia OFF |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Fri Feb 24, 2017 11:24 pm Post subject: |
|
|
I keep a close eye on auth.log too, and at least think I know the open ports and services for entry, which are watched as well. I make a few file changes on an almost daily basis, and tripwire catches all that I expect it to. Still, I'd probably have the same sort of paranoia that you dealt with if tripwire threw me an error even if it looked like database corruption.
FWIW, even with the database corruption, you should be able to see the recent reports from `tripwire --check`, at least up to the date that `tripwire --check` stopped working. Do you get those reports on a daily basis? If not that, see the one-liner report in /var/log/user.log, as often as `tripwire --check` is run. |
|
| Back to top |
|
|
|
Networking & Security
