UNITY 360: Issueshttp://www.prelude-siem.org/http://www.prelude-siem.org/welcome/themes/prelude/favicon/Prelude-icon.png2008-06-25T16:38:01ZUNITY 360
Redmine Libprelude - Feature #293 (Closed): Libprelude EasyBindingshttp://www.prelude-siem.org/issues/2932008-06-25T16:38:01ZYoann VANDOORSELAERE
<p>[[EasyBindings]] are an enhancement to the current low-level languages bindings exported by libprelude.</p>
<p>The project is about making the Libprelude API trivial to use from the C++, Perl, and Python language. Improvement to the C API are also planned.</p>
<p>The current development code is available from the <a href="https://trac.prelude-ids.org/browser/libprelude/branches/libprelude-easy-bindings" class="external">EasyBindings branche</a> in the svn repository, which can be checked out using the following command:</p>
<pre>
svn co http://svn.prelude-ids.org/libprelude/branches/libprelude-easy-bindings
</pre> PRELUDE SIEM - Feature #292 (Closed): Native Prelude support for ClamAVhttp://www.prelude-siem.org/issues/2922008-06-25T16:30:35ZYoann VANDOORSELAERE
<p>Native Prelude support for <a href="http://www.clamav.net/" class="external">ClamAV</a> is being developed. This ticket will serve as a central point for discussion and progress tracking of this development.</p> Prelude-LML - Bug #214 (New): Invalid classification reference in several LML rulesetshttp://www.prelude-siem.org/issues/2142007-04-03T17:37:44ZYoann VANDOORSELAERE
<p>Some LML rulesets are missing an "url" field for the Classification Reference. IDMEF specify that the "url" member of a Reference has to be specified.</p>
Example of such rulesets are:
<ul>
<li>cisco-vpn.rules</li>
<li>cisco-css.rules</li>
</ul> Prelude-LML - Bug #213 (New): LML rulesets should be updated to use IDMEF Actionhttp://www.prelude-siem.org/issues/2132007-04-03T17:31:44ZYoann VANDOORSELAERE
<p>Current rulesets (except modsecurity) does not make use of the IDMEF Action class.</p>
<pre>
4.2.6.2. The Action Class
The Action class is used to describe any actions taken by the
analyzer in response to the event.
category
The type of action taken. The permitted values are shown below.
The default value is "other". (See also Section 10.)
+------+-------------------+----------------------------------------+
| Rank | Keyword | Description |
+------+-------------------+----------------------------------------+
| 0 | block-installed | A block of some sort was installed to |
| | | prevent an attack from reaching its |
| | | destination. The block could be a |
| | | port block, address block, etc., or |
| | | disabling a user account. |
| | | |
| 1 | notification-sent | A notification message of some sort |
| | | was sent out-of-band (via pager, |
| | | e-mail, etc.). Does not include the |
| | | transmission of this alert. |
| | | |
| 2 | taken-offline | A system, computer, or user was taken |
| | | offline, as when the computer is shut |
| | | down or a user is logged off. |
| | | |
| 3 | other | Anything not in one of the above |
| | | categories. |
+------+-------------------+----------------------------------------+
The element itself may be empty, or may contain a textual
description of the action, if the analyzer is able to provide
additional details.
</pre> Prelude Correlator - Bug #141 (Closed): Support for setting multiple context at once from multipl...http://www.prelude-siem.org/issues/1412006-04-01T00:35:53ZYoann VANDOORSELAERE
<p>Support need to be implemented so that it is possible to retrieve list of IDMEF value and assign multiple context for each retrieved value. For example, we might want to create multiple address context out of the content of alert.source(<strong>).node.address(</strong>).address.</p>
<p>When retrieving such an object, the IDMEF value API should be used in order to iterate the returned idmef_value_t object. We should then be able to bind these value to a specific action (in the example ahead $1* would mean to replicate the create action for each value contained in $1).</p>
<pre>
pattern = alert.source(*).node.address(*).address: (.*);
action = create TARGET_ADDRESS_$1*;
</pre>
<p>For example, if the resulting IDMEF value contain x.x.x.x and y.y.y.y, the action should expand to:</p>
<pre>
create TARGET_ADDRESS_x.x.x.x;
create TARGET_ADDRESS_y.y.y.y;
</pre> Prelude Correlator - Feature #128 (Closed): Prelude integration within SEChttp://www.prelude-siem.org/issues/1282006-01-28T01:33:55ZYoann VANDOORSELAERE
<p>Following the recent discussion about integrating correlation capability<br />in Prelude using the SEC program, which would currently consist of:</p>
<pre>
Prelude-Manager(XMLmod) -> SEC(logfile) -> Prelude-LML ->
Prelude-Manager
</pre>
<p>I thought that we should rather try to get it done right the first time rather than satisfying of the hack described above. I talked with Rob Holland from Inverse Path (Perl coder and Prelude contributor) about integrating directly Prelude support within SEC.</p>
<p>The integration is going to be done in two steps:</p>
<pre><code>1. Integrate Prelude like reporting capability within SEC, so that it can directly report alert to Prelude. This way, the schema above will be changed to:</code></pre>
<pre>
Prelude-Manager (XMLmod) -> SEC -> Prelude-Manager
</pre>
2. Implement the ability in SEC to directly match IDMEF message. This will change the schema above to:
<pre>
Prelude-Manager <-> SEC
</pre>
<p>We hope that the result of this effort will then be included in the vanilla SEC distribution. Please post any thought or comment about the upcoming Prelude integration within the SEC program here.</p> Prewikka - Bug #49 (Closed): Do not rely on ident to get the latest alert/heartbeathttp://www.prelude-siem.org/issues/492004-10-28T19:01:50ZYoann VANDOORSELAERE
<p>Currently, Prewikka consider the heartbeat in database with the highest ident to be the last heartbeat that has been added to the database. This is wrong since the ident allocation scheme drasticaly changed, and even through ident are unique, it shouldn't be assumed that there number is increasing incrementaly. Moreover this specificity is not described by the IDMEF standard and would result in incorrect behavior with other IDMEF database implementation.</p>
<p>In order to get the latest heartbeat in database, Prewikka should rely on the create_time field contained within the heartbeat.</p> Prewikka - Bug #48 (Closed): Additional data of type 'byte' dumped incorrectly.http://www.prelude-siem.org/issues/482004-10-28T18:57:57ZYoann VANDOORSELAERE
<p>Currently, Prewikka simply print the content of additional data without taking care of the 'type' of the data represented.</p>
<p>Typically, in case theses data are raw byte, Prewikka should issue two dump of the data:<br />- An ASCII dump of the printable byte.<br />- An hexadecimal dump of the whole data.</p> Libprelude - Bug #40 (Closed): Use pointer for optionnal idmef_string_t.http://www.prelude-siem.org/issues/402004-07-14T18:30:51ZYoann VANDOORSELAERE
<p>Optionnal IDMEF string field should be referenced by their IDMEF parent through a pointer, and not directly 'hard coded' within the parent.</p> LibpreludeDB - Bug #37 (Closed): Handling of idmef_time_t in libpreludedbhttp://www.prelude-siem.org/issues/372004-07-05T22:29:25ZYoann VANDOORSELAERE
<p>idmef_time_t has been modified so that the time reported by sensor is UTC, and a sensor specific GMT offset is provided in case the user want to sort alert by the sensor specific timezone.</p>
<p>This modification has to be implemented in libpreludedb: the GMT offset of the sensor should be stored in the database.</p> LibpreludeDB - Bug #36 (Closed): Introduce a backward compatible version of 'classic' database pl...http://www.prelude-siem.org/issues/362004-07-05T22:22:38ZYoann VANDOORSELAERE
<p>A version of classic compatible with existing 0-8 databases should be re-introduced in libpreludedb. This plugin don't have to support writing to the database as some of the recent IDMEF structure changes make this impossible. It would be interesting to add two new libpreludedb plugin flags: a capability flags (read/write), plus a version flags (classic 0.8/0.9).</p> LibpreludeDB - Bug #35 (Closed): Handle analyzer chaining insertion/selectionhttp://www.prelude-siem.org/issues/352004-07-05T22:19:00ZYoann VANDOORSELAERE
<p>Analyzer chaining is not supported in libpreludedb yet.</p> Prewikka - Feature #15 (Closed): Heartbeat viewhttp://www.prelude-siem.org/issues/152004-06-03T11:25:34ZYoann VANDOORSELAERE
<p>We need an heartbeat view, similar to the alert view, in prewikka, providing:</p>
<p>- Heartbeat list, similar to the one Piwi provide.<br />- Ability to see heartbeat detail.<br />- Statistical analysis of heartbeat reception linearity.</p> Libprelude - Bug #11 (Closed): idmef-criteria-string.lex.l require recent flex versionhttp://www.prelude-siem.org/issues/112004-06-02T15:31:29ZYoann VANDOORSELAERE
<p>Which sacrifice portability, and is not widely adopted for this reason. We should stop using it in favor of a less recent version, and mutex should be used in order to protect the parser.</p> LibpreludeDB - Feature #2 (Closed): Implement a new database creation/update methodhttp://www.prelude-siem.org/issues/22004-05-22T21:46:26ZYoann VANDOORSELAERE
<p>Database creation should be done automatically if the database is empty - and if possible.</p>
<p>We should have some kind of updater script that will check whether the database is up-to-date, and propose to upgrade it if it's not.</p>