Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

No Data in Alerts section of Base

BASE-user
2008-01-17
2013-06-03
1 2 > >> (Page 1 of 2)
  • Brian Green
    Brian Green
    2008-01-17

    I am using base 1.3.9 and I'm having some problems with it displaying the alerts.  My statistics are showing just fine, so I can see how many alerts I have, just not what type of alerts.  For example, I can click "Most frequent Addresses " and see the list of IP's the alerts come from, but if I click something like "Today's alerts" I get the colum headers of signature, classification, and such, but nothing is displayed below that. This just started occuring today.  So far I have upgrading from a previous version (1.2.5) as well as repairing data tables and finally just clearing them. I tried checking the apache error logs and saw the error of
    "PHP Fatal error:  Allowed memory size of 8388608 bytes exhausted (tried to allocate 3495869 bytes) in /srv/www/htdocs/base-1.3.9/includes/base_signature.inc.php on line 233".
    I'm not sure if that's significant to this situation or not though. 

     
    • Brian Green
      Brian Green
      2008-01-17

      I have also deleted my base_conf.php file and gone back through the setup to see if that would help and it did not.

       
    • Hello Brian,

      I am not sure, whether I understand you correctly. You click either at
      "unique" or at "listing", but not at "Today's alerts".

      If you click at unique, there is the MetaData table, then "Displaying alerts 1-6 of 6 total" (for example). And below that a table with the
      columns "Signature", "Classification" "Total#" and so on. This table is just a sort of summary. To get further details you click at,
      for example, "46" directly in the "Total#" column, to reach the alert listing,
      and then, for example at "#1-(1-4062404)" for one particular alert.

      And if you had clicked at "Listing", you would have got to the alert table one step quicker.

      So I think you weren't fully aware of this distinction (summary list vs. detailed list of alerts).

      Anyway. A different question is the one about the php error. This has nothing to do with the layout question, but it could be of interest anyway.

      But if you could reproduce it, I would be interested in the "sid" number of the alert that has triggered this message. This number can be found by pointing the mouse cursor at "snort" in the alert listing.

      The url will be something like

      http://www.snort.org/pub-bin/sigs.cgi?sid=1:2003195

      The number I would be interested in is in this case "1:2003195."

      However, if you can not report it, it is ok, as well.

      Bye, bye

      Juergen

       
    • Brian Green
      Brian Green
      2008-01-17

      There have been some developments since I last posted, but here's what it was doing.  I would click on the "Total number of Alerts" section, I would get the top part of the screen fine and the table header for ID, Signature, timestamp, etc, but not the actual data.
      Now, I've found that this and the php errors were related.  I edited the includes/base_signature.inc.php file to allocate a bunch of memory by placing ini_set("memory_limit","100M"); at the top of the script.  This crashed my browser because of the memory, but I was able to what was actually happening.  The php code was going through each letter of each alert (creating a huge memory hog situation) and trying to put a link to whitehats.com which I found on line 228 of the code.  I commented out that part of the code in the BuildSigLookup() function, which looks like this now
        $pattern=array("/(IDS)(\d+)/",
                       //"/(IDS)(0+)(\d+)/",
                       //"/BUGTRAQ ID (\d+)/",
                       //"/MCAFEE ID (\d+)/",
                       "/(CVE-\d+-\d+)/");
      I left the first and last line intact, and now it displays the information I need, however I'm still seeing some other issues and hate to leave it with code that is modified.
      The problem I'm seeing now is when I click on a particular type of alert to see which machies have experienced this.  In the "Meta Criteria" section it'll display links for each letter in the alert for example of the http_inspect BARE BYTE UNICODE alert it will display something like

      Signature "<FONT SIZE=-1>[<A HREF="http://www.snort.org/pub-bin/sigs.cgi?sid=119:4" TARGET="_ACID_ALERT_DESC">snort</A>]</FONT> <A HREF="http://cve.mitre.org/cgi-bin/cvename.cgi?name=" TARGET="_ACID_ALERT_DESC"></A>(<A HREF="http://cve.mitre.org/cgi-bin/cvename.cgi?name=" TARGET="_ACID_ALERT_DESC"></A>h<A HREF="http://cve.mitre.org/cgi-bin/cvename.cgi?name=" TARGET="_ACID_ALERT_DESC"></A>t<A HREF="http://cve.mitre.org/cgi-bin/cvename.cgi?name=" TARGET="_ACID_ALERT_DESC"></A>t<A HREF="http://cve.mitre.org/cgi-bin/cvename.cgi?name=" TARGET="_ACID_ALERT_DESC"></A>p<A HREF="http://cve.mitre.org/cgi-bin/cvename.cgi?name=" TARGET="_ACID_ALERT_DESC"></A>_<A HREF="http://cve.mitre.org/cgi-bin/cvename.cgi?name=" TARGET="_ACID_ALERT_DESC"></A>i<A
      .....and on and on for each letter of the alert.....
      Now, in my apache error log I'm showing.  PHP Fatal error:  Call to a member function MoveNext() on a non-object in /srv/www/htdocs/base-1.3.9/includes/base_db.inc.php on line 464,
      I could probably go into that file and fix something up, but fishing through the various includes seems to not be too fun.  I was hoping I could find some other simpler solution closer to the source of the actual problem as opposed to hacking at good php code.

       
      • Hello Brian,

        if I understood you correctly, "raw" html commands have been printed to your screen, rather than in interpreted form.

        Is this right?

        If yes, then I may possibly be able to help, as I have faced a similar phaenomenon (just when coming via
        "unique").

        If no, then I would ask you, whether
        there is a way to provide me with the
        packet that triggered that alert? I seem to be unable to produce a packet out of gen_id:sid_id == 119:4 . (pastebin.com or sth like that)

        I would need sth in pcap form, that I could feed tcpreplay with...

        Bye, bye,

        Juergen

         
        • Brian Green
          Brian Green
          2008-01-18

          You are correct in this.  It has been displaying raw html instead of interpreting them.  

           
    • Hello Brian,

      this raw html problem can be fixed by removing one single "htmlentities" command
      in the file "base-1.3.9/includes/base_state_citems.inc.php":

      --- base_state_citems.inc.php.orig      2007-11-21 02:58:48.000000000 +0100
      +++ base_state_citems.inc.php   2008-01-01 21:32:09.000000000 +0100
      @@ -440,7 +440,7 @@ class SignatureCriteria extends SingleEl

               $tmp = $tmp._SIGNATURE.' '.$tmp_human.' "';
               if ( ($this->db->baseGetDBversion() >= 100) && $this->sig_type == 1 )
      -          $tmp = $tmp.htmlentities(BuildSigByID($this->criteria[1], $this->db)).'" '.$this->cs->GetClearCriteriaString($this->export_name);
      +          $tmp = $tmp.(BuildSigByID($this->criteria[1], $this->db)).'" '.$this->cs->GetClearCriteriaString($this->export_name);
               else
                 $tmp = $tmp.htmlentities($this->criteria[1]).'"'.$this->cs->GetClearCriteriaString($this->export_name);

      While this does work for me, I have some doubt, whether this is already the whole story. Therefore I haven't submitted this, yet. We'll see how it does for you.

      Just to be sure:

      When you access the very same alert, that has previously triggered your error message, via "listing" rather than via "unique", then you do NOT face the error message. The error appears for this particular alert ONLY, when you have taken your way via "unique".

      Is this correct?

      Bye, bye,

      Juergen

       
    • Brian Green
      Brian Green
      2008-01-18

      nope, this happens for every alert.  I tried commenting out the lines you mentioned, but that did not appear to work either. 

       
      • strange.

        In the meantime I was able to produce a packet that triggers a 119:4 "(http_inspect) BARE BYTE UNICODE ENCODING" alert. But I could not detect any display problems with an unpatched base-1.3.9 version, apart from that raw html bug.

        Now, do you use an old php version?
        php -info | grep "PHP Version"

        Or an old snort version?
        snort --version

        Or at least an old database scheme?
        mysql> select * from `schema`;

        Are you sure, that $BASE_urlpath in base_conf.php does not point into a different and therefore wrong directory, so that a strange mixture of php files from different BASE version would be the result?

        And you didn't really comment out whole lines in base_state_citems.inc.php, you just removed one single word ("htmlentities") from one line in that file?

        Is it just the 119:4 alert type, that causes your display problems, or are the meta infos displayed completely wrong with
        other alert types (rules, other preprocessors), as well?

        Now, that I have my own BARE BYTE UNICODE ENCODING alert entry, I think, I do not need your pcap data, any more, because I would not know, how your meta data would be different from my own meta data.

        Bye, bye

        Juergen

         
    • Brian Green
      Brian Green
      2008-01-21

      to answer a few of the questions
      PHP Version => 5.1.2

      Snort Version 2.8.0.1 (Build 72)  i386

      select * from `schema`;
      +------+---------------------+
      | vseq | ctime               |
      +------+---------------------+
      |  107 | 2008-01-10 13:27:39 |
      +------+---------------------+
      1 row in set (0.02 sec)

      my $BASE_URL seems to be correct in the config file. 

      As far as the lines of code I commented out, I commented lines 441-445 in the base_state_citems_inc.php file which were:

      $tmp = $tmp._SIGNATURE.' '.$tmp_human.' "';
      if ( ($this->db->baseGetDBversion() >= 100) && $this->sig_type == 1 )
          $tmp = $tmp.htmlentities(BuildSigByID($this->criteria[1], $this->db)).'" '.$this->cs->GetClearCriteriaString($this->export_name);
      else
          $tmp = $tmp.htmlentities($this->criteria[1]).'"'.$this->cs->GetClearCriteriaString($this->export_name);

      I did this because there are alot of items in the code that say htmlentities and these were the lines that seemed most appropriate. 

      It is not just the 119:4 Bare Byte Unicode Alert that I'm having problems with.  It is with every alert from all preprocessors.  I just chose the Bare Byte Unicode alert as an example of every other one because it came first alphabetically, so it was the first in the list. 

       
      • Kevin Johnson
        Kevin Johnson
        2008-01-22

        Can you download the latest copy from CVS?  We had a bug that sounds like what you are describing and it was fixed in CVS.  I apologize for the delay in answering as I have been out of town teaching.

        Kevin

         
    • Hello Brian,

      not all htmlentities calls in the code are wrong. Actually, it is just one single call that is to be removed, as far as I can see right now. So the lines in question should look like these:

              $tmp = $tmp._SIGNATURE.' '.$tmp_human.' "';
              if (($this->db->baseGetDBversion() >= 100) && $this->sig_type == 1 )                  
                $tmp = tmp.BuildSigByID($this->criteria[1], $this->db).'"'.$this->cs->GetClearCriteriaString($this->export_name);
              else
                $tmp = $tmp.htmlentities($this->criteria[1]).'"'.$this->cs->GetClearCriteriaString($this->export_name);

      And they should not be commented out completely.

      This does fix the raw html bug. A different question is, whether it solves all of your problems.

      The $BASE_URL is important, because it must not lead any browser into one of your old BASE directories. It must lead a browser into the new directory, i.e. that of BASE-1.3.9.

      Now, as I am running out of ideas: If one of those PHP Fatal Errors reoccurs, I would like to ask you whether you could enable debug mode in base_conf.php, i.e.

      $debug_mode = 1;

      This provides you with a lot of additional  
      output. Maybe you could post it here. If it is long, it does not matter.
      Maybe this gives some additional hints.

      There must be anything on your system that  
      is fundamentally different from mine...

      Bye, bye

      Juergen

       
    • Brian Green
      Brian Green
      2008-01-22

      Taking that one htmlentities line out now seemed to fix the issue of the raw text dump.  I then tried uncommenting out the lines I had commented out before, but I'm still having the same problem with that, but I don't think I'm missing too much with that.
      Thanks Very Much for the help with that issue!!!!
        One other possible problem you may be able to help me with that may be somewhat related.  When I go to any page that has to do with "Ports" (such as clicking last source ports) the entire page is pretty much blank.  All I'm seeing is the BASE header, home & search  on the left side, and back on the right.  When I check my apache log this time, I receive the error "PHP Fatal error:  Call to a member function MoveNext() on a non-object in /srv/www/htdocs/base-1.3.9/includes/base_db.inc.php on line 464".  Any idea what could cause that?  The line it is referring to is in the function baseFetchRow
        function baseFetchRow()
        {
           if ( !$this->row->EOF )
           {
              $temp = $this->row->fields;
              $this->row->MoveNext();
              return $temp;
           }
           else
              return "";
        }

       
    • Brian Green
      Brian Green
      2008-01-24

      I looked and CVS didn't appear to be installed at all.  I installed CVS 1.12.12, but did not see a change.  Where would be the best place to download a more up to date version if possible?

       
      • Kevin Johnson
        Kevin Johnson
        2008-01-24

        Hi-

        I didn't mean to install CVS, I meant to download the latest copy of BASE from our CVS repository.  Sorry for the confusion.

        Kevin

         
    • Brian Green
      Brian Green
      2008-01-24

      I believe I am currently running the most current version of base which is 1.3.9 which I installed from http://sourceforge.net/project/showfiles.php?group_id=103348.  I can reinstall it if necessary though.

       
    • Randal Rioux
      Randal Rioux
      2008-01-24

      Brian,

      1.3.9 is the latest release, however the most current development updates are in the CVS repository. To grab the latest revisions, install the cvs client and enter:

      With proxy server:

      cvs "-d:pserver;proxy=x.x.x.x;proxyport=xx:anonymous@secureideas.cvs.sourceforge.net:/cvsroot/secureideas" co -P base-php4

      Without proxy server:

      cvs -d:pserver:anonymous@secureideas.cvs.sourceforge.net:/cvsroot/secureideas co -P base-php4

      This will download the latest into a folder called base-php4. And there you go. Please update this thread with your results after testing.

      Thanks!
      Randy

       
    • Brian Green
      Brian Green
      2008-01-24

      I'm still receiving the same errors as before when using the base-php4 setup.

       
      • Hello Brian,

        could you just check the following:

        mysql> select encoding from sensor;

        And when you use the cvs version of BASE (that one under base-php4): You are sure, that
        $BASE_urlpath is a path that does lead any browser into the new directory that contains the cvs version of BASE, and not into any directory with an older version, aren't you?

        So please enter into debugmode:
        Set in base_conf.php

        $debug_mode = 1;

        And post the complete output of the page
        when that "call on a non-object" error occurs. The output may be long, but that doesn't matter. Perhaps this sheds some light into what's going on here.

        Bye, bye

        Juergen

         
    • Blaine Forbush
      Blaine Forbush
      2008-02-16

      I don't mean to interfere but I seem to be having the same problem as what you have described. I try to view a list of alerts but all I get is a blank screen practically. I turned on debug mode and got the following. I'm not that familiar with BASE so hopefully you guys can make sense of all of this.

      Basic Analysis and Security Engine (BASE)
      Home  |   Search 
      [ Back ]

               URL: '/base/base_qry_main.php?&num_result_rows=-1&submit=Query+DB&current_view=-1'
               (referred by: '')
               PARAMETERS: '&num_result_rows=-1&submit=Query+DB&current_view=-1'
               CLIENT: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20060911 SUSE/2.0.0.2-2.13 Firefox/2.0.0.2
               SERVER: Apache/2.2.3 (Linux/SUSE)
               SERVER HW: Linux linux-n2qt 2.6.16.46-0.12-default #1 Thu May 17 14:00:09 UTC 2007 i686
               DATABASE TYPE: mysql  DB ABSTRACTION VERSION: V5.04 13 Feb 2008  (c) 2000-2008 John Lim (jlim#natsoft.com.my). All rights reserved. Released BSD & LGPL.
               PHP VERSION: 5.1.2  PHP API: apache2handler
               BASE VERSION: 1.3.9 (anne)
               SESSION ID: u81tdt106vvqfpaqld0plknjh2( 3647 bytes )
              

      Checking for DB abstraction lib in '/srv/www/adodb5/adodb.inc.php'
      sensor #2: event.cid = 7, acid_event.cid = 7

                  new: ''  
                  submit: 'Query DB'
                  sort_order: 'none'
                  num_result_rows: ''  current_view: ''
                  layer4: ''  caller: ''
                  action: ''  action_arg: ''
                 

      Initial/Canned Query or Sort Clicked

      SUBMIT: Query DB

      sort_order: none

      SQL (save_sql): SELECT acid_event.sid, acid_event.cid, signature, timestamp, acid_event.ip_src, acid_event.ip_dst, acid_event.ip_proto FROM acid_event WHERE 1 = 1

      SQL (sort_sql):
      Valid Canned Query List

      Array
      (
          [last_tcp] => Array
              (
                  [0] => 15
                  [1] => Last TCP Alerts
                  [2] => time_d
              )

          [last_udp] => Array
              (
                  [0] => 15
                  [1] => Last UDP Alerts
                  [2] => time_d
              )

          [last_icmp] => Array
              (
                  [0] => 15
                  [1] => Last ICMP Alerts
                  [2] => time_d
              )

          [last_any] => Array
              (
                  [0] => 15
                  [1] => Last Alerts
                  [2] => time_d
              )

      )

      Query State
      caller = ''
      num_result_rows = '7'
      sort_order = ''
      current_view = '0'
      action_arg = ''
      action = ''
      SELECT acid_event.sid, acid_event.cid, signature, timestamp, acid_event.ip_src, acid_event.ip_dst, acid_event.ip_proto FROM acid_event WHERE 1 = 1
      Queried on : Sat February 16, 2008 14:22:12
      Meta Criteria        any  
      IP Criteria        any  
      Layer 4 Criteria       none
      Payload Criteria        any  
         
      Summary Statistics

          * Sensors
          * Unique Alerts
          *    ( classifications )
          * Unique addresses: Source | Destination
          * Unique IP links
          * Source Port: TCP | UDP
          * Destination Port: TCP | UDP

          * Time profile of alerts

      Displaying alerts 1-7 of 7 total

              ID       < Signature >       < Timestamp >       < Source Address >       < Dest. Address >       < Layer 4 Proto >

      It just cuts off here --->
      It says Displaying alerts 1-7 of 7 total but nothing shows up. This leaves me with very little functionality. It doesn't seem to be a Snort problem because I found the following data in the acid_alert table of my MySQL database.

      2 3 6 (snort_decoder): Tcp Window Scale Option found with length > 14    0   3   2008-02-16 20:41:23     3232235521  3232235650     6     40252     113
      2 4 6 (snort_decoder): Tcp Window Scale Option found with length > 14    0   3   2008-02-16 20:41:23     3232235521  3232235650     6     40252     113
      2 5 6 (snort_decoder): Tcp Window Scale Option found with length > 14    0   3   2008-02-16 20:41:23     3232235521  3232235650     6     40252     113
      2 6 6 (snort_decoder): Tcp Window Scale Option found with length > 14    0   3   2008-02-16 20:41:23     3232235521  3232235650     6     40252     113
      2 1 4 (portscan) TCP Portscan 0     3     2008-02-16 20:41:22     3232235521     3232235650     255    
      2 2 5 (portscan) Open Port     0     3     2008-02-16 20:41:22     3232235521     3232235650     255    
      2 7 7 (snort_decoder): Tcp Options found with bad lengths     0     3     2008-02-16 21:01:57     3232235521  3232235650     6     17306     17306

      Once again, any help would be appreciated.

       
      • Hello Blaine,

        many thanks, indeed, for providing the debug and mysql output. Unfortunately I am still unable to reproduce the problem. To me, the debug output looks rather usual.

        I managed to create one of those packets that trigger
        "(snort_decoder): Tcp Window Scale Option found with length > 14".
        However, it gets displayed in the expected way
        with BASE-1.3.9.

        One thing is clear: BASE is dieing on your computer.

        But apparently not because of one of the die() or
        exit() commands in the BASE source code, as they are
        accompanied by proper error messages.

        Just to make sure: What can be found in
        apache's error log, when BASE is dieing?
        /var/log/httpd/error_log or ssl_error_log,
        or wherever that is with SUSE.

        What does the following mysql command return?
        mysql> select encoding from sensor;

        And could you please try and find out, what the
        last mysql commands are, when BASE is about to die?
        This can be setup in base_conf.php as follows:

        $sql_trace_mode = 1;
        $sql_trace_file = '/tmp/base_sql_trace_file.log';

        There can be found, for example, the SELECT statement that
        is also visible in the debug output. But maybe there are
        some more mysql commands, just before BASE is dieing.
        Just a guess, though...

        Bye, bye,

        Juergen

         
    • Blaine Forbush
      Blaine Forbush
      2008-02-18

      Here is what I got from follwing the instructions you gave me. Apparently Apache didn't report any problems when opening up base. I opened up the error_log and there weren't any new errors. I checked the encoding like you requested and got the following.

      mysql> select encoding from sensor;
      +----------+
      | encoding |
      +----------+
      |        0 |
      +----------+
      1 row in set (0.00 sec)

      Here is the output from the base_sql_trace_file.log file that base created when I click on the link to view the 7 alerts that snort logged.

      --------------------------------------------------------------------------------
      PConnect [mysql] snort@localhost: as snort
      [Feb 18 2008 09:39:10] /base/base_qry_main.php - db version 107
      --------------------------------------------------------------------------------

      SELECT role_id FROM base_users where usr_login=NULL and usr_pwd='';

      --------------------------------------------------------------------------------
      PConnect [mysql] snort@localhost: as snort
      [Feb 18 2008 09:39:10] /base/base_qry_main.php - db version 107
      --------------------------------------------------------------------------------

      --------------------------------------------------------------------------------
      PConnect [mysql] snort@localhost: as snort
      [Feb 18 2008 09:39:10] /base/base_qry_main.php - db version 107
      --------------------------------------------------------------------------------

      SELECT sid FROM sensor
      SELECT MAX(cid) FROM event WHERE sid='2'
      SELECT MAX(cid) FROM acid_event WHERE sid='2'
      UPDATE sensor SET last_cid=7 WHERE sid=2
      SELECT COUNT(acid_event.cid) FROM acid_event  WHERE  1 = 1
      SELECT acid_event.sid, acid_event.cid, signature, timestamp, acid_event.ip_src, acid_event.ip_dst, acid_event.ip_proto FROM acid_event WHERE  1 = 1 
      SELECT sig_name FROM signature WHERE sig_id='6'
      SELECT ref_seq, ref_id FROM sig_reference WHERE sig_id='6'
      SELECT sig_sid, sig_gid FROM signature WHERE sig_id='6'

      Hopefully this output gives you some useful information. I looked over the output and noticed that when selecting role_id it is using NULL as the username and nothing as the password. Would this cause a problem? Do I need to setup users and roles to access the information that snort has logged to the database? Either way, let me know when you get a chance. Thanks for your help!

      Blaine

       
      • well, from the SELECT statements I would say
        BASE is stumbling over a bug that has already been fixed in CVS, although I am not sure.

        Could you please try and download the CVS version of BASE?

        This is one single line:

        cvs -z3 -t -d:pserver:anonymous@secureideas.cvs.sourceforge.net:/cvsroot/secureideas co -P base-php4

        And BASE can then be found in "base-php4" in your current working directory. You just need a CVS client on your computer to get this version, not also a CVS server (just in case you must install a cvs package).

        Now, if that CVS version does NOT solve your problems, I have added some debug code.

        Set in base_conf.php

            $debug_mode = 2;
            $debug_time_mode = 1;
            $html_no_cache = 1;
            $sql_trace_mode = 1;
            $sql_trace_file = '/tmp/base_sql_trace.log';

        The mode "2" ensures that noone else will be bothered with the debug output. In the base_sql_trace.log there should be a lot more output than before.

        Please post the contents of this file here.

        I hope this narrows down the line in the code, where the crash happens.

        Bye, bye

        Juergen

         
    • Brian Green
      Brian Green
      2008-04-28

      I received a message from Kevin Johnson who said this issue was resolved in version 1.4.  I downloaded 1.4 and I'm still having the same issue.  here is the information requested in the last update
      --------------------------------------------------------------------------------
      PConnect [mysql] snort@127.0.0.1: as snort
      [Apr 28 2008 09:42:55] /base-1.4.0/base_main.php - db version 107
      --------------------------------------------------------------------------------

      --------------------------------------------------------------------------------
      PConnect [mysql] snort@127.0.0.1: as snort
      [Apr 28 2008 09:42:55] /base-1.4.0/base_main.php - db version 107
      --------------------------------------------------------------------------------

      SELECT ip_src FROM iphdr
      SELECT count(*) FROM sensor
      SELECT sid FROM sensor
      SELECT MAX(cid) FROM event WHERE sid='3'
      SELECT MAX(cid) FROM acid_event WHERE sid='3'
      UPDATE sensor SET last_cid=252028 WHERE sid=3
      SELECT min(timestamp), max(timestamp) FROM acid_event
      SELECT COUNT(DISTINCT acid_event.sid) FROM acid_event
      SELECT COUNT(DISTINCT sensor.sid) FROM sensor
      SELECT COUNT(DISTINCT acid_event.signature) FROM acid_event
      SELECT count(*) FROM acid_event
      SELECT COUNT(DISTINCT acid_event.ip_src), COUNT(DISTINCT acid_event.ip_dst) FROM acid_event
      SELECT COUNT(DISTINCT acid_event.ip_src, acid_event.ip_dst, acid_event.ip_proto) FROM acid_event
      SELECT COUNT(DISTINCT layer4_sport),  COUNT(DISTINCT layer4_dport) FROM acid_event
      SELECT COUNT(DISTINCT acid_event.layer4_sport),  COUNT(DISTINCT acid_event.layer4_dport) FROM acid_event WHERE ip_proto='6'
      SELECT COUNT(DISTINCT acid_event.layer4_sport),  COUNT(DISTINCT acid_event.layer4_dport) FROM acid_event WHERE ip_proto='17'
      SELECT count(DISTINCT(sig_class_id)) FROM acid_event
      SELECT count(*) FROM acid_event WHERE ip_proto=6
      SELECT count(*) FROM acid_event WHERE ip_proto=17
      SELECT count(*) FROM acid_event WHERE ip_proto=1
      SELECT count(*) FROM acid_event WHERE ip_proto=255

      --------------------------------------------------------------------------------
      PConnect [mysql] snort@127.0.0.1: as snort
      [Apr 28 2008 09:43:01] /base-1.4.0/base_qry_main.php - db version 107
      --------------------------------------------------------------------------------

      SELECT role_id FROM base_users where usr_login=NULL and usr_pwd='';

      --------------------------------------------------------------------------------
      PConnect [mysql] snort@127.0.0.1: as snort
      [Apr 28 2008 09:43:01] /base-1.4.0/base_qry_main.php - db version 107
      --------------------------------------------------------------------------------

      --------------------------------------------------------------------------------
      PConnect [mysql] snort@127.0.0.1: as snort
      [Apr 28 2008 09:43:02] /base-1.4.0/base_qry_main.php - db version 107
      --------------------------------------------------------------------------------

      SELECT count(*) FROM sensor
      SELECT sid FROM sensor
      SELECT MAX(cid) FROM event WHERE sid='3'
      SELECT MAX(cid) FROM acid_event WHERE sid='3'
      UPDATE sensor SET last_cid=252028 WHERE sid=3
      SELECT acid_event.sid, acid_event.cid, signature, timestamp, acid_event.ip_src, acid_event.ip_dst, acid_event.ip_proto FROM acid_event WHERE  1 = 1  ORDER BY timestamp DESC

      /srv/www/htdocs/base-1.4.0/base_qry_sqlcalls.php:171:
      ############## <calls to BuildSigByID> ##################
      /srv/www/htdocs/base-1.4.0/includes/base_signature.inc.php:279:BuildSigByID: Before GetSignatureName()
      SELECT sig_name FROM signature WHERE sig_id='157'
      /srv/www/htdocs/base-1.4.0/includes/base_signature.inc.php:284:BuildSigByID: After GetSignatureName()
      /srv/www/htdocs/base-1.4.0/includes/base_signature.inc.php:292:BuildSigByID: Before BuildSigLookup()

       
      • Hello Brian,

        could you please update from CVS?  I have added some checks and further debug output.  I still wonder why BASE is dieing on your machine while trying to translate the references inside the signatures.

        I mean, wrong links or some error messages would be "ok", but an exit() is more severe.  I need to understand this.  I know that whitehats.com is currently not reachable, but this should be
        no reason for BASE to die.

        The CVS version of BASE can be found under the subdirectory base-php4.  You need a "login" and "checkout" command (or "login" and "update").

        For further instructions on CVS see

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

        Bye, bye

        Juergen

         
1 2 > >> (Page 1 of 2)