IPLOGs question

msmitha · ‎07-03-2003

Hello,

My questions are related to the IPLOGs (raw packet payload data). I'm planning to setup IPLOG for high/medium events only because they're the ones we usually need to look into the raw data.

1. When a high/medium event is triggered, it would generate IPLOG. What is a reasonable time period for logging a high/medium event? 5 minutes?

2. From the CLI, I noticed that I can modify these parameters:

NumberOfIPLogFiles: 20 <defaulted>

MaxOpenIPLogFiles: 20 <defaulted>

MaxIPLogFileSize: 1000000 <defaulted>

Can I increase the number of IPLOG files that are stored as well as their MAXIPLogFileSize? This is because in a high traffic environment, there might be times when we need to look up IPLOG raw data and if the file size it too short, it would be over-written. What is a MAX size I could change it to without causing any problems?

3. Using IDM if I wanted to check out a particular IPLOG file, I noticed that there is a LOG ID which is a unique identifier for the IPLOG files. If I wanted to look up raw data for a particular eventID how can I find out which IPLOG file to lookup?

Thanks,

marcabal · ‎07-03-2003

Just talked with the developers to get the inside scoop.

The original intent was to allow users to modify those 3 parameters to change how the sensor stored the IP Logs.

So they were added to sensorApp's XML and show up in the CLI.

However, during development it was decided not to allow these values to be user modifiable.

IP Logging can have a severe impact on performance and correct operating of the sensor. Too better control this impact, it was decided to hardcode these into the sensor rather than allowing them to be user modified.

Here are the hardcoded settings being used in the current version:

NumberOfLogFiles=512

SizeOfLogFiles=1000000

MaxOpenLogFiles=20

So the current settings allow the storage of up to 512 IP Logs that can each be up to 1 Meg in size, and only 20 of the IP Logs can be written to a time.

NOTE: Any modifications to these 3 CLI parameters will have no affect on the handling of IP Logs in the current versions.

In the future the user may be able to modify the IP Log storage with the 3 parameters in a future version of the sensor, however, this has not been committed to so I can't quote a version number where this feature may be implemented.

HOWEVER, the other 3 parameters in that same area in the CLI are implemented and do work for controlling how large an individual IP Log can be:

IPLogPackets: 0

IPLogTime: 30

IPLogBytes: 0

By default the sensor will log the packets for only 30 seconds, but it can be increased to a maximum of 300 seconds (5 minutes).

Optionally you could use the other 2 parameters to set the number of packets or number of bytes to log. NOTE: Number of bytes would be limited to 1 Meg.

As for your other question:

If I remember correctly, sensorApp will create a status message when it start or stops an IP Log (a different message than the alert/alarm).

This status message I believe will list the eventId of the alert that started the IP Log.

NOTE: I haven't verified this.

msmitha · ‎07-07-2003

Thanks for the information.

I got some events to generate IPlogs. Using IDM, I can look at the different IPlog files created and download them. However, I am unable to view the raw packet payload. Is there a particular program I'm supposed to use to be able to view the IPLog files? I'm very interested to see the hex packet payload and if available, the ASCII equivalent to understand more. Please let me know.

ywadhavk · ‎07-07-2003

Hi Smitha,

We use the Ethereal network sniffer software to look into these files. Its available as a freeware at

http://www.ethereal.com/

Thanks,

yatin

pheuch · ‎07-08-2003

Be careful when setting up the iplogs. 5 minutes is a very long time. We set the value to 1 minute. This is enough to decide if a hacker was successful or not. If they were not successful, they will try again, which retrigger the iplog capturing.

The problem with the iplogs is the design of the IDS (at least up to version 3.x, I''m not familar with 4.x). There is only one level and one action for an event possible. So it is only possible to ignore and event for a connection, or to use the "global" definition. This is fine , if you do not want to monitor in- and outgoing traffic. In such a case you could ignore any outgoing events. But this is not very usual.

Asume some events are triggered by your main proxy. You will get a bunch of iplog files within only one minute. Or one of your web server triggers an event while sending its reply. All the replies of your server will be stored in the iplog file for the next minute (this is a bit unlikely, but may happen after signature updates).

Regards Peter

msmitha · ‎07-08-2003

Thanks, Peter.

From MARCOA CABALLERO's posting above, I understand that the maximum number of IPlog files are limited to 512 with a max file size of 1MB each. Also, I imagine the CIDS daemons/services would take care of over-writing older IPlog files with newer ones. In this scenario, is there a possibility for an improper IPLog setting to cause problems to the CIDS application or with disk space?

In large enterprise deployments with several CSIDS sensors, a fairly large degree of automation is required. Right now, when I see certain events on my main console and I decide to look up IPlog files on the corresponding sensor(s) for investigation/forensics, I need to get to the specific CSIDS sensor, look up its status log to find out which IPlog file matches with the eventID i'm looking for and then use IDM to download the IPLOG file for forensics. All this involves a reasonable amount of time and depending on the number of sensors in the environment and the volume of events/IPlog files generated, chances are my IPlog files are long gone before I get there.

I would be very interested if the sensors could archive IPlog files, compress them and store them offline in another fileserver for instance. This would ensure that we haven't lost any IPlogs and forensics folks can do their work in peace.

It is possible that my understanding is flawed or I'm missing something. Your comments are welcome.

pheuch · ‎07-09-2003

There is a lot room for improvements. We do automatically list all iplog files on a sensor, scan the events in the log files, scan packetd.conf and SigSettings.conf to find out which events are causing ip logs, correlate the iplog files with the events causing the iplogs and the events captured in an iplog (but not triggering an iplog), decide which iplogs are interesting by certain rules and download them automatically.

After download we are using self written programs to analyse the iplogs, for example follow http converstations and ignore complete conversations with good answers ....

So the Cisco Software is a good starting point, but you need more...