Slashdot Mirror
Tripwire Goes Open Source
Brian McLaughlin writes: "Tripwire posted the source code to their integrity checking tool at SourceForge today. The press release can be consumed here."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
I know there was a commercial product that did this (and much more) for Solaris back about 3-4 years ago, but I haven't heard about it since. There are some other triggers that would be nice:
- On any of unlink, rename, creat, mkdir
- On failed system calls that fail due to permissions (e.g. the above calls as well as kill, socket, etc)
I know you could do most of this in libc, but I don't think that would be wise, as someone with enough smarts could always do the syscalls directly using asm().Now we need distribution specific policy files, currently the policy files are only for redhat. It would be nice to see policy files for suse, debian, turbo, caldera, etc.. as they apply to that particular disribution.
For example, alot of the files in the default policy file (setup for redhat) don't exist on my system (suse) and if they do exist, their in different locations. I can guess that this will be pretty much the same with debian, turbo, caldera and others as well.
This can (and should be) used by anyone who runs *NIX.
/tmp (since anyone can put files in there), but all of your other important area on your drive should be watched. Example: Someone gets root on your box, and they replace /bin/su (switch user, usually to root), with a trojan that has a backdoor. Tripwire will notice that it's not the correct file, and e-mail/page/alert someone.
Actually, it's quite simple: It makes sure that when files change, someone is notified. Now, obviously you don't want Tripwire watching your logs (since they change constantly) or
As for the "policy language" they refer to, that's just another way of saying "a way to tell Tripwire what to watch, how to watch it, and what to do if something has changed".
To put it all in context, here is an example. Note that Tripwire is much more advanced than this, but essentially, this does the same thing: When I first install my system, I patch it, and capture all of the `ls -la` output of my important files to a file. Once an hour, I have a task (cron job) that does the same `ls -la` and compares the output to the original file. If they're different, either I changed something and forgot to update the original file, or someone is up to something. It then sends me an e-mail and I look into it.
I hope that explains what Tripwire does in a nutshell. If you would like more information, let me know.
I wonder if it'd be easier/faster to 'chattr +i' certain critical files like /bin/login and then add logging code to the appropriate syscall to warn you when somebody changes it back.
Why allow anyone to change this back? Set the immutable attribute (+i) on anything that won't ever change, make your log records permanent with 'chattr +a /var/log/messages' so that the logs can't be editted, just appended to, and then install lids and set CAP_LINUX_IMMUTABLE to remove the ability to change these attributes on this system under this kernel. If you need to change things over, you'll need a second kernel image elsewhere for administration purposes (i.e. on floppy) but your key system will remain inviolate.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
This is so cool, I remember when I started using Tripwire about 3 years ago and it irked me that the source wasn't open.
I had been running it on a RH 4.2 box. I was trying to use the version that was linked against libc5 (the only binary they had at the time) on a RH5.0 box, and was told I would have to wait several months before they released a new version that would link against glibc (aka libc6).
Source code gives a whole new meaning to free software.
Mike
"I would kill everyone in this room for a drop of sweet beer."
Free (as in speech) tripwire.
Free (as in beer) posters. (You just have to figure out how to get past their poorly coded form validation to order one...).
--- Where's my X.400 protocol decoder?
Of course, since the open source release is GPLed, porting it to other OSes is perfectly legitimate.
In other words, Do The Work Yourselves. If you're upset that there's no BSD or other version, form a group and use the GPL to do it yourself. Don't complain, get to work.
It's not like it's closed source proprietary, where you can't do that.
--- Will in Seattle - What are you doing to fight the War?
Their database seems like the greatest potential gain for the community. The hashing of files is pretty simple, given the number of crytographically strong open-source hashes out there. The UI/customization end of tripwire seems like it would be relatively straightforward to design. It seems to me that most of the room for real software engineering is in the database file format.
People have already created driver-level crypto filesystems, but has anyone ever proposed a driver-level tripwire filesystem? Of course, you would need to tell the fs whcih files and directories to keep track of or you would be swamped with change logs.
Has anyone ever proposed a secured journaling filesystem? While we're replacing/overhauling the Linux filesystem, we might as well add secure functionality. (Assuming we don't cause a false sense of security.) Setting a file attribute flag to secure could cause any changes to the file or directory (including mv and cp) to be logged in a compact format. Any changes in the secure-log flag for all files in the fs would also have to be logged. In ultra-paranoid environments, one could even securely log file reads. (It's not that much more work to include this in a new driver.) Use an itterative one-time password scheme to watermark the logs (even a 64 bit hash would be relatively secure, because of the number of hashes that would need to be matched to change logs very far back in time). The easiest way to sign the hash is just to encrypt it with the one-time password. You keep the first one-time password on a locked floppy, along with a copy of the executable for checking the logs and computing the hashes of the files stored in the logs (add a hash to the logifile only when something changes). With the first password, you can compute the second, with the second you can compute the third, etc. This means that you can decrypt all of the hashes of the logfile if you have the floppy.
On the other hand, if the filesystem driver keeps only the current one-time password, then any attacker will be detected if s/he alters the logs for any time earlier than when they broke in. (Since creating the correct hashes requires knowing the password for that time, and passwords for earlier times cannot be computed from passwords for later times.) You can keep snapshots of the logfile if you like, but they are not necessary for intrusion detection. One only needs to first check the integrity of the logfile, then trace through the changes according to the logfile. Any discrepincies between a file and it's last recorded hash indicate file corruption or a security breach. People could "turn back the clock" on the filesystem by changing the files back to a previous state and deleting any logs since, but any subsequent changes to the fs would be logged with the wrong one-time-password and this would be detected.
First pos.. wow that took a while to write and revise! I'm surprised you actually read this far.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
Has anybody else wondered why only Linux versions of software are made open source? For example, "At the present time, Tripwire has no plans to make its commercial UNIX versions or NT available as open source." (from the FAQ) and AFAIK Troll Tech has made only the Linux version of qt open.
Is the reason the background of the OS? Linux users are used to having the source and a product which doesn't offer source can't expect a very wide acceptance in the Linux world (see for example some of the originally-closed drivers). In Windows, everybody is used to proprietary software, so they couldn't care less.
Another peculiar thing is, why do they keep different versions for different architechtures? I'd think it would be easier to manage only one code base with #ifdef's or separate low-level files. It might be possible that they only omit the Windows-specific files, but in this case any GPL additions to the Linux version (made by users) couldn't be compiled into the Windows version.
This, on the other hand, would mean that the Linux version would inevitably become better than the corresponding Windows version. The only legal way they could get the same features into the Windows version would be to code them themselves from scratch, and who's to say they didn't use any GPL-only code? Or do they demand everybody who contributes anything to dual-licence it so they can use it in the closed Windows version also?
Any ideas, anyone?
I doubt, therefore I may be.
See the news from tripwire's new site TripWire.org which has the skinny from Tripwire directly. LinuxPower has an article. As does IGN over here.
T here is also a great article here regarding file system monitoring - and alternatives (additional OpenSource) to TripWire. Not quite as relevant now that TripWire is OpenSource but still a good read.
They are changed their source encryption to ASCII encoding, triple ROT-26 under the provisions of the DMCA which just went into effect.
Also, you are allowed to view the source, but comprehension of it is a violation of the terms of use statement you agreed to when you first became aware of the term Tripwire. Failure to not comprehend the source is punishable by, but not limited to, confiscation of any or all of the following:
Who needs Tripwire when we have AIDE?
To quote the web page: "AIDE (Advanced Intrusion Detection Environment) is a free replacement for Tripwire. It does the same things as the semi-free Tripwire and more."
Check it out!
http://www.cs.tut.fi/~rammer/aide.html
If the log files can't be tampered with, does that include log rotation? If you can rotate them then so can a cracker, and if you can't then you'd better make sure you've got plenty of disk space...
Do you need to put other mechanisms in place to cope with this?