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 <[email protected] <javascript:>>
> 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 <[email protected]> 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-integrity-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 <[email protected]> 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 [email protected].
>>>>>> 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 [email protected].
>>>> 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 [email protected] <javascript:>.
>> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
<ossec_config>
<global>
<email_notification>yes</email_notification>
<email_to>[email protected]</email_to>
<smtp_server>smtp.xxx.com.</smtp_server>
<email_from>[email protected].</email_from>
</global>
<rules>
<include>rules_config.xml</include>
<include>pam_rules.xml</include>
<include>sshd_rules.xml</include>
<include>telnetd_rules.xml</include>
<include>syslog_rules.xml</include>
<include>arpwatch_rules.xml</include>
<include>symantec-av_rules.xml</include>
<include>symantec-ws_rules.xml</include>
<include>pix_rules.xml</include>
<include>named_rules.xml</include>
<include>smbd_rules.xml</include>
<include>vsftpd_rules.xml</include>
<include>pure-ftpd_rules.xml</include>
<include>proftpd_rules.xml</include>
<include>ms_ftpd_rules.xml</include>
<include>ftpd_rules.xml</include>
<include>hordeimp_rules.xml</include>
<include>roundcube_rules.xml</include>
<include>wordpress_rules.xml</include>
<include>cimserver_rules.xml</include>
<include>vpopmail_rules.xml</include>
<include>vmpop3d_rules.xml</include>
<include>courier_rules.xml</include>
<include>web_rules.xml</include>
<include>web_appsec_rules.xml</include>
<include>apache_rules.xml</include>
<include>nginx_rules.xml</include>
<include>php_rules.xml</include>
<include>mysql_rules.xml</include>
<include>postgresql_rules.xml</include>
<include>ids_rules.xml</include>
<include>squid_rules.xml</include>
<include>firewall_rules.xml</include>
<include>cisco-ios_rules.xml</include>
<include>netscreenfw_rules.xml</include>
<include>sonicwall_rules.xml</include>
<include>postfix_rules.xml</include>
<include>sendmail_rules.xml</include>
<include>imapd_rules.xml</include>
<include>mailscanner_rules.xml</include>
<include>dovecot_rules.xml</include>
<include>ms-exchange_rules.xml</include>
<include>racoon_rules.xml</include>
<include>vpn_concentrator_rules.xml</include>
<include>spamd_rules.xml</include>
<include>msauth_rules.xml</include>
<include>mcafee_av_rules.xml</include>
<include>trend-osce_rules.xml</include>
<include>ms-se_rules.xml</include>
<!-- <include>policy_rules.xml</include> -->
<include>zeus_rules.xml</include>
<include>solaris_bsm_rules.xml</include>
<include>vmware_rules.xml</include>
<include>ms_dhcp_rules.xml</include>
<include>asterisk_rules.xml</include>
<include>ossec_rules.xml</include>
<include>attack_rules.xml</include>
<include>local_rules.xml</include>
</rules>
<syscheck>
<!-- Frequency that syscheck is executed -- default every 20 hours -->
<frequency>1800</frequency>
<!-- Directories to check (perform all possible verifications) -->
<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes">/bin,/sbin</directories>
<!-- Files/directories to ignore -->
<ignore>/etc/mtab</ignore>
<ignore>/etc/hosts.deny</ignore>
<ignore>/etc/mail/statistics</ignore>
<ignore>/etc/random-seed</ignore>
<ignore>/etc/adjtime</ignore>
<ignore>/etc/httpd/logs</ignore>
</syscheck>
<rootcheck>
<rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
<rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
</rootcheck>
<global>
<white_list>127.0.0.1</white_list>
<white_list>192.168.2.1</white_list>
<white_list>192.168.2.190</white_list>
<white_list>192.168.2.32</white_list>
<white_list>192.168.2.10</white_list>
</global>
<remote>
<connection>secure</connection>
</remote>
<alerts>
<log_alert_level>1</log_alert_level>
<email_alert_level>7</email_alert_level>
</alerts>
<command>
<name>host-deny</name>
<executable>host-deny.sh</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
<command>
<name>firewall-drop</name>
<executable>firewall-drop.sh</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
<command>
<name>disable-account</name>
<executable>disable-account.sh</executable>
<expect>user</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
<!-- Active Response Config -->
<active-response>
<!-- This response is going to execute the host-deny
- command for every event that fires a rule with
- level (severity) >= 6.
- The IP is going to be blocked for 600 seconds.
-->
<disabled>yes</disabled>
<command>host-deny</command>
<location>local</location>
<level>6</level>
<timeout>600</timeout>
</active-response>
<active-response>
<!-- Firewall Drop response. Block the IP for
- 600 seconds on the firewall (iptables,
- ipfilter, etc).
-->
<disabled>yes</disabled>
<command>firewall-drop</command>
<location>local</location>
<level>6</level>
<timeout>600</timeout>
</active-response>
<!-- Files to monitor (localfiles) -->
<localfile>
<log_format>syslog</log_format>
<location>/var/log/messages</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/authlog</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/secure</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/xferlog</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/maillog</location>
</localfile>
<localfile>
<log_format>apache</log_format>
<location>/var/www/logs/access_log</location>
</localfile>
<localfile>
<log_format>apache</log_format>
<location>/var/www/logs/error_log</location>
</localfile>
</ossec_config>
