Hi all.
This might seem really naive, but can mtree be used effectively as
a native-to-core-OS tripwire equivalent? Would it be as efficient in
terms of time-to-run and resource requirements?
What sort of pitfalls should I be aware of?
Has anyone here done this? If so, would you care to share your
scripts/techniques?
Thanks,
Dave
--
______________________ ______________________
\__________________ \ D. J. HAWKEY JR. / __________________/
\________________/\ hawkeyd@visi.com /\________________/
http://www.visi.com/~hawkeyd/
Quoting D J Hawkey Jr (hawkeyd@visi.com):> This might seem really naive, but can mtree be used effectively as > a native-to-core-OS tripwire equivalent? Would it be as efficient in > terms of time-to-run and resource requirements? > > What sort of pitfalls should I be aware of?Yes, it can: Pro: distributed with base Con: Only available for *BSD architectures as far as my knowledge goes. What it means is that if you want to cryptographically hash a Linux-box tripwire might be better to use because you would get a common interface across your platforms. On the other hand, last time I looked tripwire was a magnificient piece of bloat. -- j.
--- D J Hawkey Jr <hawkeyd@visi.com> wrote:> Hi all. > > This might seem really naive, but can mtree be used > effectively as > a native-to-core-OS tripwire equivalent? Would it be > as efficient in > terms of time-to-run and resource requirements? >Theoretically, and practical for small configurations, yes.> What sort of pitfalls should I be aware of? >IMHO, you can use any tool you want to compute some "signature" for files you deem relevant. But you have to carefully consider the scalability problem, the problem of false/negatives (how you/your program deal with a modified file? bin/config/data/tmp file) and so on. Tripwire (coorect me if I am wrong, but last time I looked it was still to be updated in FreeBSD, focus was on "aide") is a targetted tool that helps with the information management... probably bloated :). Like any tool, it is up to you to decide what's useful or not ;) HTH, /Dorin.> Has anyone here done this? If so, would you care to > share your > scripts/techniques? > > Thanks, > Dave > > -- > ______________________ > ______________________ > \__________________ \ D. J. HAWKEY JR. / > __________________/ > \________________/\ hawkeyd@visi.com > /\________________/ > http://www.visi.com/~hawkeyd/ > > _______________________________________________ > freebsd-security@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-security> To unsubscribe, send any mail to"freebsd-security-unsubscribe@freebsd.org" __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
<<On Wed, 14 Jan 2004 07:42:15 -0600, D J Hawkey Jr <hawkeyd@visi.com> said:> What sort of pitfalls should I be aware of?mtree files don't scale very well, and to make proper use of them for this purpose requires a great deal more thought. Tripwire is a bit more "pre-thunk", and uses a database instead of a flat file, which speeds updates. (With mtree you'd have to rescan the entire filesystem.) -GAWollman
Gregory Neil Shapiro <gshapiro@freebsd.org> writes:> > Is your reply from personal experience, or is it the same "Hey, it > > could..." as is my question? If the former, would you elaborate on the > > implementation details? > > I use: > > mtree -K sha1digest -c -X mtree.exclude -p / > mtree.out > > where mtree.exclude is: > > ./home > ./mnt > ./proc > ./tmp > ./var/account > ./var/backups > ./var/db > ./var/imap > ./var/lock > ./var/log > ./var/mail > ./var/run > ./var/spool > ./var/tmp > > Although I am sure there is a better way to do it with mtree, to > see if something has changed, I repeat the process and diff the > output.That would be mtree < mtree.out to have mtree do it itself.