#210 Archive Database not copying all alert data

BASE
closed-fixed
nobody
Database (41)
5
2009-05-12
2009-02-20
No

When enabled, the Archive database doesn't acquire all necessary alert data copied/movied from the active database. When copying/moving, only the asset information gets copied to the database tables and does not include the signature information, packet information, header information, etc. This functionality was working on version 1.2.5.

Discussion

1 2 > >> (Page 1 of 2)
  • Screenshot of actual copied alert from Active to Archive database

     
  • Hello Michelle,

    the particular alert as shown in the *.jpg file is indeed an invalid entry. Nothing else but zeroes.
    Simply delete it.

    But what about BASE-1.4.2: Does archiving work with this new release for you?

    If not, then it depends:

    If you get such a NULL entry, again, could you enable debug_mode in base_conf.php
    and try and find out what exactly has produced this collection of zeroes?

    If proper alert has arrived in the archive database, could you try and find out
    which fields are missing by means of database queries on the command line?

    mysql or pgsql or whatever is the appropriate tool for you.

    Bye, bye

    Juergen

     
  • Hi Juergen,

    The new version 1.4.2 seems to have some linking issue with where we put our base path. I did test archiving alerts from the active to the archive and it's still manifesting the same issue.

    Debugging showed me this error when I try to copy an alert:
    /***/base/includes/base_state_criteria.inc.php:111: WARNING: The following query key has not been implemented, yet: "action_chk_lst".
    Report it to the BASE developers, please.

    Session Registered

     
  • Hello,

    What kind of alert is this, that triggers this error message?

    And what is filling your database: Is it snort itself,
    or any third party helper program, like barnyard?

    If you use barnyard: Can you let snort do the job
    for some time, and copy/move THESE alerts to
    the database. Same error, again?

    Bye, bye
    Juergen

     
  • I meant "...and copy/move THESE alerts to the archive database...".
    Sorry.

     
  • Hi, The error message gets triggered when you select alerts and move them or copy them to the archive database. We don't have any third party helper, and is just using the default from snort/base.

    Thanks,

    Michelle

     
  • Hello,

    provided, that there is no confidential info in your snort database -
    and that its size is no more than 1 or 2 Megabytes -
    can you send a dump of the whole snort database to my email address here?

    Something like

    mysqldump --databases snort > /tmp/snort_01.05.2009.sql
    bzip2 snort_01.05.2009.sql

    I am not sure, whether this email will pass all the filters before it arrives at my mailbox,
    but we will see what happens. Or if you have your own webspace you could put it there and mail me a link to it.
    Or use any of those public upload areas.

    BASE seems to stumble over some NULL entries (empty entries, maybe).
    And I do not have such a trash alert in my database. Of course, BASE should be robust
    against such kinds of alerts.

    Bye, bye

    Juergen

     
  • Unfortunately, I'm not able to perform the action due to policy.

    BASE doesnt seem to copy over the data from the active database as I was able to login to SQL and the active DB contains all the necessary entries. However, once they're being converted over to the archive DB, they lose the data within the tables being copied over.

     
  • So far my tests have shown, that archiving works for me in a
    "loss-free" way. But anyway, the problem in your case is
    more severe. Just have a look at includes/base_state_criteria.inc.php:

    88 if (
    89 ($debug_key != "new") && ($debug_key != "sort_order") &&
    (...)
    100 ($debug_key != "action_lst") && ($debug_key != "action") &&
    101 ($debug_key != "action_arg") && ($debug_key != "ag_id") &&
    102 ($debug_key != "ag_name") && ($debug_key != "ag_desc") &&
    103 ($debug_key != "ag_action") && ($debug_key != "action_chk_ls t") &&
    104 ($debug_key != "addr_type") /* && ($debug_key != "") &&
    105 ($debug_key != "") && ($debug_key != "") &&
    106 ($debug_key != "") && ($debug_key != "") &&
    107 ($debug_key != "") && ($debug_key != "") &&
    108 */
    109 )
    110 {
    111 ErrorMessage(__FILE__ . ":" . __LINE__ . ": " . "WARNING: The fo llowing query key has not been implemented, yet: \"" . $debug_key . "\".<BR> \n" . "Report it to the BASE developers, please.<BR>\n");
    112 }

    With such a source code, it is rather surprising, that you got an error message with
    the query key being "action_chk_lst".

    It is not as trivial as, say, one or two fields would have been forgotten in the archiving routines.
    It is more tricky...

     
  • Hello Michelle,

    Could you please,

    - check all the log files (syslog, http server error log, database log files)
    for error messages and for any indications whether a crash takes place?
    Be it segmentation fault or whatever.

    - download the current CVS version of BASE as described at

    https://sourceforge.net/cvs/?group_id=103348

    BASE will be under base-php4.

    - check whether the error persists

    - and if so, tell me the error message(s). There should also be a backtrace, now,
    if the same WARNING reappears as you mentioned earlier.
    Maybe this backtrace sheds some light on where the problem originates from.

    - Does your problem occur with really every alert you have in your database,
    or just with one particular alert?

    - Does it make any difference when you try and archive one alert or many alerts?

    Bye, bye

    Juergen

     
1 2 > >> (Page 1 of 2)