No Payload data displayed

  • Tom Fischer

    Tom Fischer - 2007-07-08

       I just setup a box with Fedora Core 6, MYSQl 5.0.27, ADODB 4.8.0, and BASE 1.3.6. The database schema is 107, and I   am feeding the database from a remote sensor running SNORT and Barnyard 2.0. I have verified that the alerts are correctly being stored in the database. When I try to view the details of an alert, the payload field is blank. I have verified that the payload is in the database, and when I setup MYSQL trace in the BASE.conf.php file there are no errors accessing the database. Here is an excerpt from the log:

    PConnect [mysql] snort@localhost:3306 as snort
    [Jul 08 2007 15:01:57] /base/base_qry_alert.php - db version 107

    SELECT sid FROM sensor
    SELECT MAX(cid) FROM event WHERE sid='1'
    SELECT MAX(cid) FROM acid_event WHERE sid='1'
    UPDATE sensor SET last_cid=8498 WHERE sid=1
    SELECT acid_event.sid, acid_event.cid FROM acid_event  WHERE  1 = 1
    SELECT signature, timestamp FROM acid_event WHERE sid='1' AND cid='8308'
    SELECT hostname, interface, filter, encoding, detail FROM sensor  WHERE sid='1'
    SELECT sig_name FROM signature WHERE sig_id='48'
    SELECT ref_seq, ref_id FROM sig_reference WHERE sig_id='48'
    SELECT sig_sid, sig_gid FROM signature WHERE sig_id='48'
    SELECT acid_ag_alert.ag_id, ag_name, ag_desc FROM acid_ag_alert LEFT JOIN acid_ag ON acid_ag_alert.ag_id = acid_ag.ag_id WHERE ag_sid='1' AND ag_cid='8308'
    SELECT ip_src, ip_dst, ip_ver, ip_hlen, ip_tos, ip_len, ip_id, ip_flags, ip_off, ip_ttl, ip_csum, ip_proto FROM iphdr  WHERE sid='1' AND cid='8308'
    SELECT * FROM opt  WHERE sid='1' AND cid='8308' AND opt_proto='0'
    SELECT tcp_sport, tcp_dport, tcp_seq, tcp_ack, tcp_off, tcp_res, tcp_flags, tcp_win,        tcp_csum, tcp_urp FROM tcphdr  WHERE sid='1' AND cid='8308'
    SELECT * FROM opt  WHERE sid='1' AND cid='8308' AND opt_proto='6'
    SELECT data_payload FROM data WHERE sid='1' AND cid='8308'

       If I connect to the database and manually run the last line, I receive the data. It just doesn't show on the web page. I tried upgrading BASE to 1.3.8 and downgrading it to 1.2.7. This box was previously running BASE 1.2.7 on FC3. I did a complete re-format to install FC6. Can someone please help me find a solution?

    • Kevin Johnson

      Kevin Johnson - 2007-07-08

      Are you running SELinux?  We have seen oddities like this in that case?


    • Tom Fischer

      Tom Fischer - 2007-07-08

      No, I disabled SELinux during the install. I just checked the config and verified that it is disabled.

    • No Please

      No Please - 2007-07-25

      I am suffering the exact same problem with Snort 2.7.0, barnyard 0.2.0 and BASE 1.3.6. SElinux is also disable (running Ubuntu 7.10 gutsy). Anyone have any ideas on this?

    • jerry shenk

      jerry shenk - 2008-10-16

      I'm having the same symptom as this but, the "last line of the above" doesn't show any data for me.  Obviously my numbers are different:

      SELECT data_payload FROM data WHERE cid='51183';

      - returns "Empty set"

      SELECT tcp_sport FROM tcphdr WHERE cid='51183';

      - returns a valid response - port 28001

      If however I view the file in BASE, I can click on the "Download in pcap format" but, things don't seem to match.  I just downloaded another one that triggered on the "WEB-CGI calendar access" rule but the pcap file clearly does not match.  I was thinking that barnyard was dumping the data to the MySQL database but now I'm not sure.  I have looked through the unified alert file using strings and I can see data that would have matched some alerts so, it seems like it's at least being sent out from Snort.  I'm not sure if barnyard is failing to log the data into MySQL or if BASE is failing to display it.  Based on my SQL queries, I think Barnyard isn't putting the data into the database but I haven't done that test in the past so I'm really not too sure.

    • jerry shenk

      jerry shenk - 2008-10-16

      Ok, I found the problem - In my barnyard startup script, I had specified the logfile as snort-unified.alert instead of snort-unified.log.  Changing that solved my problem.

      Thanks for Tom Fischer for posting the "raw SQL queries" that I could use to work this out!!


Log in to post a comment.