OSSEC IDS on Windows only sending Error logs

222 views
Skip to first unread message

Ed Davison

unread,
Mar 1, 2017, 6:35:19 PM3/1/17
to ossec-list
I have OSSEC 2.8.3 installed on a Windows 2012R2 server and have added an eventchannel localfile option to gather logs from "Microsoft-Windows-Backup" log.  No errors on startup.

On the OSSIM side, I have logall enabled and am checking alerts.log file and can ONLY see Error logs being forwarded, not Information or Warning logs.  I need these latter as that is where the successful and successful with warning errors are logged as well as a backup was configured or cancelled.

How can I get ALL of the logs for all log severities sent to OSSIM using 2.8.3 OSSEC for Windows and eventchannel?

Thanks in advance.

InfoSec

unread,
Mar 7, 2017, 5:30:09 AM3/7/17
to ossec-list
To gain visibility into what is going on at the agent side, turn on debug mode on the agent.

In C:\Program Files (x86)\ossec-agent\internal_options.conf change:

# Windows debug (used by the windows agent)
windows.debug=0
to
# Windows debug (used by the windows agent)
windows.debug=2

and restart the agent. It will log all events it picks up in the agent log file: C:\Program Files (x86)\ossec-agent\ossec.log (Don't do it on a busy production system!)

By examining events in ossec.log, you will know what the agent is picking up, and should be able to determine whether you are faced with an agent issue, or a server issue.

lostinthetubez

unread,
Mar 7, 2017, 10:51:39 AM3/7/17
to ossec...@googlegroups.com

Hi Ed,

 

A couple things that might help here. When you enable logall, you’ll want to look inside archives.log, not alerts.log. Assuming this wasn’t a typo, here’s a few things that might help with your problem:

 

If you go look at your msauth_rules.xml file, you’ll note that OSSEC receives INFORMATION and WARNING events as level 0 alerts, meaning they aren’t retained. To change this, add the following to your local_rules.xml file and restart OSSEC services:

 

<!-- change level on warning level logs so they are retained -->

<rule id="18101" level="1" overwrite=”yes”>

    <if_sid>18100</if_sid>

    <status>^INFORMATION</status>

    <description>Windows informational event.</description>

</rule>

 

<!-- change level on warning level logs so they are retained -->

<rule id="18102" level="5" overwrite="yes">

    <if_sid>18100</if_sid>

    <status>^WARNING</status>

    <description>Windows warning event.</description>

</rule>

 

Retaining all warning logs is a reasonable approach, but retaining informational logs in a large deployment will get rather noisy rather quickly. You might just consider creating another custom rule looking for exactly what you want:

        <rule id="100001" level="3">

                <if_sid>18101</if_sid>

                <id>^4$</id>

                <match>The backup operation has finished successfully</match>

                <description>A backup has completed successfully.</description>

                <options>alert_by_email</options>

        </rule>

 

        <rule id="100002" level="10">

                <if_sid>18103</if_sid>

                <id>^5$</id>

                <match>backup</match>

                <description>A backup has failed. Please investigate.</description>

        </rule>

 

In addition, I don’t believe OSSEC recognizes CRITICAL events. These are for things like unclean reboots.

<rule id="100003" level="7">

    <if_sid>18100</if_sid>

    <status>^CRITICAL</status>

    <description>Windows critical event</description>

    <info>NOTE: you can’t analyze logs written before OSSEC starts unless you are using eventchannel to monitor the system logs</info>

    <group>system_error,</group>

</rule>

 

 

--

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

Ed Davison

unread,
Mar 7, 2017, 10:51:54 AM3/7/17
to ossec-list
Thanks; I will look into that and see what the logs show.
Reply all
Reply to author
Forward
0 new messages