Hi,

I tested that configuration at Windows agent's ossec.conf:

<syscheck> <frequency>300</frequency> <directories check_all="yes">
C:\Users/Administrator/AppData/Local/Temp</directories> </syscheck>


And I added this new rule on manager's local_fules.xml:

<group name="ossec,"> <rule id="100554" level="10"> <if_sid>554</if_sid> <
regex>C:\\Users/\S+/AppData/Local/Temp</regex> <description>File added to
the system at Temp directory.</description> <group>syscheck,pci_dss_11.5,</
group> </rule> </group>


This rule works with temporary files for any user. Unfortunately it seems
that wildcards (C:\Users/*/AppData/Local/Temp) do not work on Windows
agents, so you should add a <directories> entry for each user.

Note that new files are not reported on the first scan, so wait for this
message at agent's ossec.log:

2017/03/29 11:44:32 ossec-syscheckd: INFO: Ending syscheck scan (forwarding
database).


Now add any file to the Temp directory. When next scan is performed, an
alert like this one should appear in the manager:

** Alert 1490788534.45426831: - ossec,syscheck,pci_dss_11.5,
2017 Mar 29 04:55:34 (windows-agent) 10.1.2.3->syscheck
Rule: 100554 (level 10) -> 'File added to the system at Temp directory.'
New file 'C:\Users/Administrator/AppData/Local/Temp/Test Document.txt'
added to the file system.
File: C:\Users/Administrator/AppData/Local/Temp/Test Document.txt
New size: 0
New permissions: 100666
New user: Administrators (0)
New group:  (0)
New MD5: d41d8cd98f00b204e9800998ecf8427e
New SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709


Hope it help.

Best regards.



On Tue, Mar 28, 2017 at 4:01 AM, dan (ddp) <ddp...@gmail.com> wrote:

> On Mon, Mar 27, 2017 at 4:26 AM,  <henry.williamsgr...@gmail.com> 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, henry.wil...@gmail.com
> > 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 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.
>



-- 
Victor M. Fernandez-Castro
IT Security Engineer
Wazuh Inc.

-- 

--- 
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.

Reply via email to