Douglas Garstang <doug.garst...@gmail.com> writes: > What about the script that mounts the file system? That could be > compromised. This seems somewhat like security via obscurity to me. > Your security is only as good as it's weakest link, and the script that > runs every day would be the weakest link. Therefore, there doesn't seem > to be much point in going into an extra level of effort to secure other > parts of tripwire if the script is still a vulnerability.
I was assuming you'd leave the file system mounted all the time. > And... this doesn't help with my key issue anyway. Lets say that the > client system mounts /etc/tripwire every day so that it can run it's > check. This means that puppet has to put the client side key on the > network file server, which means it's still not running on the same > machine as the puppet master, which is essentially the same > configuration in the first place. Right, but you're only putting it on one system that has write access to it, namely the file server, and you can lock that system down much more completely. That one system holds all the keys for all your Tripwire databases, server and site. At that point, it's not clear that you need to use Puppet to manage the database and keys on the file server, since they're just data that lives in one place at that point. (Well, you might want a backup.) Of course, if you want to treat them as configuration, then yes, you have a Puppet issue still -- I didn't mean to say it's not a reasonable question. But I think you're in a better spot for the client systems. But yes, you need to ensure that the attacker can't just unmount the file system and replace it with local directories with a new database, etc. The normal way that one does this is that one puts the checking binary on the network file system as well, compiles a cryptographic key into the checking binary, and then has the binary checksum itself and then sign its report with that key. You then need infrastructure to check that the report is signed with a valid key, and also that you get a report every day, and that it's not a replay of the previous day's. Samhain does some stuff like this. In practice, most people stop some point short of this, since after all, a sophisticated attacker may be able to load a kernel module that will prevent Tripwire from seeing that binaries have changed. It's all just moving the problem, and it's a question of how much you want to defend against. I just like network file systems for this stuff because if you have them handy, it's an easy way to make the database part more robust. (For the record, we put our Tripwire databases in AFS so that they're read-only and put the Tripwire binary in AFS, run it from cron on each server, mail the results to a central collection point, and check for servers that aren't sending reports. We don't defend against replacing the cron job with just mailing out a clean report, and we don't use cryptographically signed binaries, although we keep thinking about a project to do both of those.) -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
