Hi BJ, Happy to know, I hope it be working well, all the credits to Xavier and his post at: https://blog.rootshell.be/2013/05/13/improving-file-integrity-monitoring-with-ossec/ . Probably the error you were getting was related to ossec.conf XML tags.
I think Dan is integrating the same functionality in OSSEC, maybe you could use that PR: https://github.com/ossec/ossec-hids/pull/1091 Best regards, Pedro 'snaow' Sanchez. On Fri, Mar 10, 2017 at 11:26 PM, BJ <b...@bjtaylor.net> wrote: > Ok, I started over from scratch, and I must have copied over a config file > from my other server. I think we're good now. I'll let you know if I get > this completely up and running. > > BJ > > > On Friday, March 10, 2017 at 1:29:23 PM UTC-7, BJ wrote: >> >> Ok, I have more information now. By trial and error, I've discovered that >> the patch we used must have messed up something with the rule parsing. Only >> by entirely removing the <rules></rules> and everything in it could I get >> ossec to start. Obviously... that's not a good solution. :-) I'll start >> looking at your patch and seeing if I can see any reason why it would be >> doing this, but again, when it comes this code, I'm in over my head, so any >> help is appreciated. >> >> Thanks, >> BJ >> >> On Friday, March 10, 2017 at 11:28:42 AM UTC-7, BJ wrote: >>> >>> So... this time it compiled great, which was the issue I was having >>> before. But now, when I go to start it, I get the following: >>> >>> OSSEC analysisd: Testing rules failed. Configuration error. Exiting. >>> >>> >>> When I look in the logs, I get see the following: >>> >>> 2017/03/10 11:11:16 ossec-testrule(1230): ERROR: Invalid element in the >>>> configuration: 'rules'. >>>> 2017/03/10 11:11:16 ossec-testrule(1202): ERROR: Configuration error at >>>> '/var/ossec/etc/ossec.conf'. Exiting. >>>> 2017/03/10 11:11:16 ossec-testrule(1202): ERROR: Configuration error at >>>> '/var/ossec/etc/ossec.conf'. Exiting. >>> >>> >>> At this point, I'm using the default ossec.conf file, and I can't see >>> any issues in that file for the life of me (using XML viewer as well). >>> Normally, I'd turn the logging verbosity up at this point, but if it can't >>> even parse the conf file, I'm not sure that will work. I also compared this >>> config to the list of rules in the folder, and against another config I >>> have running. How can I dig into this further? (My ossec.conf file is >>> attached if you are curious.) >>> >>> Thanks again, >>> BJ >>> >>> On Thursday, March 9, 2017 at 10:02:42 AM UTC-7, Pedro Sanchez wrote: >>>> >>>> That is the right branch. >>>> >>>> Yes, it does. It is fully compatible with standard OSSEC clients, you >>>> could upgrade just the Manager side. >>>> >>>> Apply the patch by running: >>>> >>>>> patch -p0 < wazuh-master-md5dbchecksum-patch.patch >>>> >>>> >>>> BTW I am not sure but I assume you could use same patch for OSSEC >>>> master branch, I think there are some changed lines but you could try it. >>>> >>>> Regards, >>>> Pedro. >>>> >>>> On Thu, Mar 9, 2017 at 5:45 PM, BJ <b...@bjtaylor.net> wrote: >>>> >>>>> Awesome Pedro. >>>>> >>>>> I'll give this a try. Just for clarification, is this the correct >>>>> Wazuh master branch? https://github.com/wazuh/wazuh >>>>> >>>>> And do you know if it works with the standard ossec clients? Or will I >>>>> need to install new clients on my servers for this to work? >>>>> >>>>> Thanks, >>>>> BJ >>>>> >>>>> On Thursday, March 9, 2017 at 8:46:59 AM UTC-7, Pedro Sanchez wrote: >>>>>> >>>>>> Hi BJ, >>>>>> >>>>>> I did not know about that post, it looks great but it is a bit >>>>>> outdated. >>>>>> It helped me to add that functionality (code pieces) to Wazuh master >>>>>> branch. Wazuh is already working SQLite internally for some DB's (agent >>>>>> keys, syscheck data..) so the libraries are already compiled there. >>>>>> Everything is working on my labs as expected, every syscheck event is >>>>>> being checked against the Checksum DB created with the Python script, if >>>>>> there is a match, the alert won't be generated. >>>>>> >>>>>> I am attaching the patch and the Python script fixed (the one on the >>>>>> blog was not working). >>>>>> >>>>>> PS: I assume the errors you had were related to not compiling / >>>>>> including properly the SQLite libraries. >>>>>> >>>>>> Regards, >>>>>> Pedro Sanchez. >>>>>> >>>>>> On Thu, Mar 9, 2017 at 1:33 AM, BJ <b...@bjtaylor.net> wrote: >>>>>> >>>>>>> Thank you Pedro. That's good information. >>>>>>> >>>>>>> With that in mind, I've decided to give this a try: >>>>>>> https://blog.rootshell.be/2013/05/13/improving-file-int >>>>>>> egrity-monitoring-with-ossec/ >>>>>>> >>>>>>> Basically, he patched the code to make it look at a sqlite3 database >>>>>>> prior to alerting. >>>>>>> >>>>>>> Unfortunately, the code is a bit old, and I'm not sure he included >>>>>>> all of the steps. I couldn't use his patch because I wanted the latest >>>>>>> code, so I created my own based on his (attached). And although I have >>>>>>> installed libsqlite3-dev, it fails to compile. I keep getting the >>>>>>> following, which suggests it isn't pulling the code in from sqlite3.h >>>>>>> for >>>>>>> some reason. >>>>>>> >>>>>>> /usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:845: >>>>>>> undefined reference to `debug0' >>>>>>> /usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:849: >>>>>>> undefined reference to `sqlite3_open' >>>>>>> /usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:852: >>>>>>> undefined reference to `sqlite3_prepare_v2' >>>>>>> /usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:854: >>>>>>> undefined reference to `sqlite3_step' >>>>>>> /usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:859: >>>>>>> undefined reference to `sqlite3_finalize' >>>>>>> /usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:860: >>>>>>> undefined reference to `sqlite3_close' >>>>>>> /usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:861: >>>>>>> undefined reference to `debug0' >>>>>>> /usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:865: >>>>>>> undefined reference to `sqlite3_finalize' >>>>>>> /usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:866: >>>>>>> undefined reference to `sqlite3_close' >>>>>>> >>>>>>> Now, I haven't coded in C since.... high school? Like 20 years ago. >>>>>>> I remember some things, and have googled others, but I'm in over my >>>>>>> head. I >>>>>>> can't seem to figure out how to fix this, or what I might have done >>>>>>> wrong. >>>>>>> FYI, I'm on Ubuntu 16.04. >>>>>>> >>>>>>> If anyone could help me, I'd appreciate it. >>>>>>> >>>>>>> Thanks, >>>>>>> BJ >>>>>>> >>>>>>> On Wednesday, March 8, 2017 at 9:14:45 AM UTC-7, Pedro Sanchez wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I like your intention to create a whitelist for checksum using CDB >>>>>>>> lists, I think it will be a great functionality. Unfortunately you >>>>>>>> won't be >>>>>>>> able to do it, since OSSEC lists does not allow to match using >>>>>>>> "syscheck.md5_after" field. >>>>>>>> You can check here the available fields for matching a CDB List: >>>>>>>> https://github.com/wazuh/wazuh/blob/master/src/analysisd/ >>>>>>>> rules.c#L665 (srcip, srcport, dstip, dstport, user, url, id, >>>>>>>> hostname, program_name, status and action) >>>>>>>> >>>>>>>> Beside that, if somehow we add the funcionallity to match for that >>>>>>>> field, you could use a negative key match, adding the list sentence to >>>>>>>> syscheck rule 550. >>>>>>>> >>>>>>>> Negative key match: http://ossec-docs.readthedocs. >>>>>>>> io/en/latest/manual/rules-decoders/rule-lists.html#negative- >>>>>>>> key-match >>>>>>>> >>>>>>>> Rule 550 for syscheck integrity checksum changed, will trigger only >>>>>>>> if they md5 checksum is not present on the CDB list, how it would look >>>>>>>> like: >>>>>>>> >>>>>>>> <rule id="550" level="7"> >>>>>>>>> <category>ossec</category> >>>>>>>>> <decoded_as>syscheck_integrity_changed</decoded_as> >>>>>>>>> *<list field="syscheck.md5_after" >>>>>>>>> lookup="not_match_key">etc/lists/whitelist_md5</list>* >>>>>>>>> <description>Integrity checksum changed.</description> >>>>>>>>> <group>syscheck,pci_dss_11.5,</group> >>>>>>>>> </rule> >>>>>>>> >>>>>>>> >>>>>>>> *whitelist_md5* >>>>>>>> >>>>>>>> d41d8cd98f00b204e9800998ecf8427a:file1 >>>>>>>>> d41d8cd98f00b204e9800998ecf8427b:file2 >>>>>>>>> d41d8cd98f00b204e9800998ecf8427c:file3 >>>>>>>>> d41d8cd98f00b204e9800998ecf8427d:file4 >>>>>>>> >>>>>>>> >>>>>>>> ossec.conf >>>>>>>> >>>>>>>>> *<list>etc/lists/whitelist_md5</list>* >>>>>>>> >>>>>>>> >>>>>>>> *Compile CDB List* >>>>>>>> >>>>>>>>> /var/ossec/bin/ossec-makelists >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Maybe someone figure out a different way to do this. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Pedro Sanchez. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 8, 2017 at 1:13 AM, BJ <b...@bjtaylor.net> wrote: >>>>>>>> >>>>>>>>> I've seen the possibility mentioned in this forum a couple of >>>>>>>>> times regarding adding the ability to check an MD5sum CDB list with >>>>>>>>> rules. >>>>>>>>> Right now, I'm in a situation where I could use that ability. >>>>>>>>> However, I >>>>>>>>> can't see anywhere that describes how to use it. Was that ever >>>>>>>>> implemented? >>>>>>>>> Frankly, I'm interested enough in this feature that I'd do it myself >>>>>>>>> if I >>>>>>>>> could, but I don't know C/C++, and only do scripting in Python. >>>>>>>>> >>>>>>>>> I'm trying to monitor a web folder for changes, but of course I >>>>>>>>> don't want to be alerted on every file when a releases is done (they >>>>>>>>> can be >>>>>>>>> done at any time of day too). I can get md5 sums of each of the files >>>>>>>>> prior >>>>>>>>> to the release to whitelist them for ossec, but I can't seem to >>>>>>>>> figure out >>>>>>>>> how to tell ossec to use that database. Any help would be appreciated. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> --- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "ossec-list" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to ossec-list+...@googlegroups.com. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "ossec-list" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to ossec-list+...@googlegroups.com. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "ossec-list" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to ossec-list+...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
