|
|
|
| An example for your lab |
Here is a step by step guide for you to have fun with ImSafe.
First of all be sure that you have installed everything on your system, read the FAQ, the User Guide, the Installation guide, etc.. for more informations.
Our lab today will consist of looking at how ImSafe reacts when monitoring an FTP server during a Buffer overflow attack. This lab should be enough for you to understand the software and to try it with other types of attacks and softwares.
1. Preparing the lab
You need to install wu-ftpd-2.6.0 since we will exploit the SITE EXEC buffer overflow. If you have a RedHat 6.2, it's perfect since it is already installed on your system ! Otherwise download it here and install it. If you work on a "sensible" system, be sure that you don't erase your current "maybe secure" ftp server since wu-ftpd-2.6.0 is vulnerable !
ftp://ftp.redhat.com/pub/redhat/redhat-6.2/i386/RedHat/RPMS/wu-ftpd-2.6.0-3.i386.rpm
Now you need to get the buffer overflow attack that we will use on this server.
http://www.securityfocus.com/data/vulnerabilities/exploits/wu-lnx.c
or http://packetstorm.securify.com/0012-exploits/7350wu-v5.tar.gz (seems more complete but I didn't test it.)
Just configure the server, configure the attack, try it, be sure that it is working fine and we are ready to start !
If you don't understand what's a buffer overflow, can't configure the attack, etc... you can still continue this lab with your actual ftp server, or any other application, just to understand the concepts.
2. Recording a trace to generate the profile
2.1 Using the GUI
Launch the ImSafe program and configure the device you want to use to record the trace in the File menu. If you have installed the patch then you may want to use the device driver, otherwise use the ims-sensor.
Now go in the Tools menu and use the Trace to file feature.
Configure what needs to be done and click start.
Connect to your ftp server, for example :
ftp 127.0.0.1
If you use the driver, the system will start logging directly.
If you use the sensor mode, you need to launch a sensor now.
Get the PID of the current in.ftpd process:
#ps -el |grep in.ftpd
1 909 ....
Launch the sensor:
Ims-trace -g -f -F -p 909
If everything is fine, you should have a message in the event window explaining you that the trace record started.
Note that I'm using the -f and -F flags to follow the fork() which is important since I want to get as much information as possible on the process.
Now go back to you ftp client window and do stuff... try to create dirs, rename, upload, etc etc.. try to cover as much "normal" actions as possible.
If you know that none of your users is supposed to upload a file, then don't upload any file, etc...
When you are done, close the tracer, and check that you have a file containing a trace looking like this:
1 909 45
2 909 6
3 909 12
....
2.2 Using the command line tools
Ok, now you know... Creating a trace by training the system yourself is quite boring ! The solution is to hook up a sensor to your ftp server for one week and to let your users do the job. Of course you should be sure that you don't have any attacks during that learning stage, otherwise... you guessed.. :)
If you use the device driver, you just have to instal the ims-trace as a daemon like any other daemon on your system. If the daemon has any problem it will communicate with you through syslog to the console.
If you want to use the sensor you have to modify your inetd.conf file
3 Creating a profile from a trace
Not really difficult, just use the Tools->Learn profile feature. If your trace file is correct it will be easy. You have the choice of the sequence length, I use 6 as default. You can check my thesis or some other papers to understand why.
You can use the ims-learn command line tool to learn in batch if you have multiple files of trace that you want to add in a same data-base.
4 Using the system to detect intrusions
Ok, now that we have a profile (in the future you will download it directly, and securely, from the web) you can start looking at how ImSafe behave during an intrusion. If you have no profile, you can download the one of wu-ftpd2.6.0 here.
Launch ImSafe and configure the device/sensor as for recording a trace.
Configure the monitor by specifying where is the profile data-base, and if you want to log the results to a file. It will log the system state ("normality") generated after each system call. Logging is important if you want to be able to plot a full graph of what happened during execution.
Start the monitor, and connect to your ftp server.
If you use the sensor mode, don't forget to hook up to the process...
Now play with your ftp server and you will see the evolution of the "normality" of the system. If you had a good training and that you redo the same kind of actions, you should not get an alarm. (it depends also on the sequence length, the anomaly threshold and the mean length).
5 Launching the attack
Now it's time for buffer overflow !
The problem is that if you use the sensor, you won't have time to hook it up to the process before the attack occurs.
One solution is to have the sensor configured in your inetd.conf file, or to edit the c code of the attack and add a sleep(30) in the code, after the connection to the ftp server, but before the attack begin... so you have some time to hook up to the process...
If everything goes fine, you will detect the attack immediately... Cool huh ?
6 Tweaking the system
You know understand all the difficulties of such a system. If you don't detect the attacks, you can increase the sequence length so that your profile "fits" more the application.. but that means more learning and more false positives.
You can minimize false positives by modifying the anomaly threshold or by increasing the mean length. This second approach is quite good since it will smooth the curve. Thus only attacks which lead to a "long term" anomaly will be detected... The problem is that it is then possible to a good cracker to write an exploit that will be short enough not to be detected...
That's why we need other feature to be included in the system, like our Fast Buffer Overflow Detection.
| |
| |
