NOOOOO ! This release is a pure, ALPHA, development release. Installing it on a real, commercial, system would be suicide since it will open more security breaches than it protects!
But our goal is to have a fully working and secure product soon, and at that moment, YES, ImSafe will be a good tool to have in your Security Toolbox. But it is only a component of a bigger security architecture. I don't believe that there is One way to do IDS. You have to watch the system, the users, the network, the physical infrastructure, etc... to do real and effective Intrusion Detection.
Q2. How does it work ?
ImSafe is doing Host based intrusion detection by analyzing audit trails of system calls generated by a process. The system try to predict the next call with a certain accuracy. If it fails to predict what's going on for a certain time, it means that the system is in an unknown state.. and an alarm is raised.
If you want to learn more, read the Inside ImSafe, the papers, or my thesis (in french).
Q3. Do you detect all attacks ?
No, ImSafe can only detect "process based" attacks. So if someone gets your password and enter the system with your login, we won't see it. But if someone executes a buffer overflow, a DOS, a brute force attacks... on your FTP server it will be detected.
In fact, it's wrong, you could detect that someone else than the usual user is logged in, since this cracker will execute different applications, and thus generates different audit trails... But I do think that they are better way to do "user profiling" than just auditing system call ! One of the extension of ImSafe is to use the exact same approach to profile users behavior.
Q4. Do I need to recompile my applications ?
No, don't change anything about your system. ImSafe is just hooking to a process to monitor it, either by using the device driver (in that case you need to recomile your Linux kernel) or by using a "sensor" (ideal if you just want to play with ImSafe on any UNIX box).
Q5. Is it slowing down the system ?
It depends. Tracing the system calls does not, especially when you use the kernel built-in driver. In fact a system call is usually an I/O operation which is going to take far more time than the few instructions we added in the kernel.
Using the "sensor" feature is like using the trace command (it is build upon strace 4.2). In that cas eyou slow down your monitored process (you have context switch, lot's of treatments, etc...)
Anyway, if there is a slowdown, we can always decide not to trace some calls that should be executed fast (like the memory related calls) and actual testing proved that it won't be a real problem for the detection system.
What IS slowing down the system (but not a lot at all !) is the analysis of the datas. But it is not a problem since :
it could (maybe even should) be done on a remote system, doing IDS only.
You can lower this process priority, thus skipping detection if overloaded system
Q6. Is there a WinNT/Win2000 version ?
The WinNT/2000 architecture is different as UNIX systems, in fact they are far more API calls than UNIX system calls. But YES we have a driver (based on ???) to monitor the "system calls" of an NT system. Yet, the results are not that good and the system need more tweaking. We also don't have the GUI for Windows yet...
Q7. Do I have to create the profile of every application that I watch ?
At this point, yes. But in the future you could receive those profiles directly from the vendor of the application of from security web sites. Those profiles will also include specifics signatures of known possible attacks so that those attacks are detected with 100% accuracy. You could also share those profile across your own network as part of a Distributed intrusion detection system.
Qx. Where can I get help ? More information ?
You can always send me an e-mail, or post your questions/comments on the various project boards on sourceforge.net
