On Mon, Mar 27, 2017 at 4:26 AM, <[email protected]> wrote: > Hello Dan, > > Thank you for your feedback. I have changed the frequency to 900 > sec, and inspected the ossec.log. I noted that inside the log file none of > the agent.conf directories where present. Any theories on why the ossec.conf > syscheck content is showing up in ossec.log, and the agent.conf syscheck is > not? >
Can OSSEC read the agent.conf (permissions)? Is the updated agent.conf transferred to the agent (you can open the file in a text editor to check)? Other than that, no real idea. > cheers, > Henry > > On Saturday, March 25, 2017 at 6:50:03 AM UTC-6, [email protected] > wrote: >> >> Hello fellow googlers, >> >> >> The GOAL: >> >> For every user on my windows OSSEC agent, generate OSSEC alert severity 10 >> when new file added to >> >> C:\Users/*/%AppData%/Local/Temp directory >> >> Where star was supposed to be the wildcard place holder to instruct OSSEC >> to mean ANY user >> >> >> >> The Attempt & RESULTS: >> >> >> In an effort to get OSSEC to generate an alert upon new file created in >> %AppData% I have conducted the following steps. >> >> >> http://ossec-docs.readthedocs.io/en/latest/faq/syscheck.html#why-aren-t-new-files-creating-an-alert >> >> Why aren’t new files creating an alert? >> >> By default OSSEC does not alert on new files. To enable this >> functionality, <alert_new_files> must be set to yes inside the <syscheck> >> section of the manager’s ossec.conf. Also, the rule to alert on new files >> (rule 554) is set to level 0 by default. The alert level will need to be >> raised in order to see the alert. Alerting on new files does not work in >> realtime, a full scan will be necessary to detect them. >> >> Add the following to local_rules.xml: >> >> <rule id="554" level="10" overwrite="yes"> >> >> <category>ossec</category> >> >> <decoded_as>syscheck_new_entry</decoded_as> >> >> <description>File added to the system.</description> >> >> <group>syscheck,</group> >> >> </rule> >> >> The <alert_new_files> entry should look something like this: >> >> <syscheck> >> >> <frequency>7200</frequency> >> >> <alert_new_files>yes</alert_new_files> >> >> <directories check_all="yes">/etc,/bin,/sbin</directories> >> >> </syscheck> >> >> >> >> In my OSSEC environment, I have a CENTos (current build) host for my OSSEC >> manager. I also have windows OS host for my OSSEC agent (agent id=001). To >> test the agent.conf setup of OSSEC I have on the OSSEC Manger host two >> configuration files, both the original ossec.conf file located @ directory >> var/ossec/etc/ as well as the agent.conf file located @ directory >> var/ossec/etc/shared. I have made the <alert_new_files> entry in both these >> configuration files. As well as add rule id 554 to local_rules.xml as >> depicted above from OSSEC documentation. >> >> >> To confirm settings are correct I ran logtest without error. Additionally, >> I preformed the following self-checks: >> >> >> Confirmed level=”10” for rule id 554 in local_rules.xml AND >> On OSSEC Manager inside the ossec.conf file that setting for alert >> threshold was set to alert on level>=1 >> Md5sum on Manager = on Agent copy of agent.conf >> Reduced frequency to 60 for troubleshooting/testing create new file >> feature. >> create new file in directory %AppData% ‘test.txt’ >> >> No immediate result, additionally let sit and wait for 24hrs to ensure >> syscheck could run multiple times. >> Result new file ‘test.txt’ was not alerted on. >> >> To arrive at this conclusion, I inspected the following results: >> >> nano /var/ossec/logs/alerts/alerts.log >> >> I can see .nix directories are firing for rule id 554. However, no >> %AppData% windows file creation detected. >> >> /var/ossec/bin/agent_control -i 001 >> /var/ossec/bin/agent_control -r -u 001 >> /var/ossec/bin/syscheck_control -u 001 >> >> OUTPUT >> ** Integrity check database updated. >> >> /var/ossec/bin/syscheck_control -i 001 >> >> OUTPUT >> Integrity changes for agent 'WinBox (001) - 192.168.0.2': >> ** No entries found. >> >> ls /var/ossec/queue/diff >> >> No entries for Windows agent >> >> nano /var/ossec/logs/alerts/alerts.log >> >> I am able to see entries for rule id 554 on .nix localhost /tmp test >> efforts for 554. Other windows content is present such as authentication >> logs and registry edits. Additionally,I can get C:\Temp new file creation to >> detect but not any new file alerts for the %AppData%. >> >> ls /var/ossec/queue/syscheck/ >> >> I can see the text files I was testing with from C:\Temp but no %AppData% >> content. >> >> >> >> From the above I gather that my test new file creations are being detected >> and alerted on my localhost. However, the syntax or other issue appears to >> be causing problems such that the %AppData% directory is not being properly >> monitored by syscheck as was the case for the C:\Temp directory for example. >> >> >> I am hoping for some guidance on how I go about testing the alert on new >> file creation for windows OS %AppData% directory. Such as how to confirm >> windows agent is detecting the new file created, and that the Master OSSEC >> is receiving this event from the windows agent correctly, then Master OSSEC >> is alerting on new file detection by rule 554 properly. >> >> The other threads discussing %AppData% indicate attention to syntax for >> adding directory entry into the ossec.conf file is important step but do not >> provide guidance into the proper syntax for such cases like wildcard use. >> Please let me know if any additional details are required to assist with my >> request. Any help or guidance is much appreciated. >> >> >> Cheers, >> >> Henry > > -- > > --- > 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.
