It should be noted that the decoders seem fine for me (and I suspect
everyone else). I think that github issue is bogus.
Follow what I posted above... basically, IIS Manager > Default Web Site >
Logging > Log File Format: W3C - select fields. *Check all the boxes that
are not checked*!!!!! I think there were 4 that weren't checked.
Edit your OSSEC config on that box...
<localfile>
<location>C:\inetpub\logs\LogFiles\W3SVC1\u_ex%y%m%d.log</location>
<log_format>iis</log_format>
</localfile>
I've tested on IIS 7.5 and IIS 8.5, and both systems work flawlessly for
the built-in decoders in OSSEC. I even tested with Nexpose and they both
work.
I think there may be confusion on the net on how to set this up... and with
the out-of-the-box settings for W3C formatted logs, the decoders will not
work. Need to check all the boxes in the "Select Fields" dialog.
Also, thank you for bringing the IIS log file issue to my attention. I
thought OSSEC was working on the logs too!!! I should have known they were
too quiet! :)
HTH!
On Friday, December 12, 2014 3:02:52 PM UTC-8, James Whittington wrote:
> “Just a side note since you mention IIS is your biggest liability for
> some reason consider running the free version of dotDefender on your
> Windows server then monitor with OSSEC the Event logs for dotDefender.”
>
> Wow that’s a heck of a good idea, I haven’t heard of that product before
> but I am looking over it now.
>
> OSSEC doesn’t really have an automated for rules to be updated, so using a
> product that can do that then feed the results to OSSEC sounds like a good
> idea.
>
>
>
> I like the freedom OSSEC gives you for customization but it has been
> frustrating that some of the out of the box things that didn’t work
> especially on Windows newer than like Windows 2003. You would think a IIS
> 7 decoder would have been included with the default decoders but it wasn’t
> last couple of times I tested it.
>
>
>
> Luckily folks had posted samples of decoders for it and eventually I
> learned how to create one but that can be daunting learning curve for
> something I would have expected to just work.
>
> Then to discover that you have been happily scanning IIS logs and it
> appears web rules were being ignored just adds to the frustration.
>
>
>
> I understand some of the latest versions do offer eventchannel support so
> I keep meaning to check that out.
>
>
>
> I will have to check out dotDefender however…
>
>
>
> James Whittington
>
>
>
>
>
> *From:* [email protected] <javascript:> [mailto:
> [email protected] <javascript:>] *On Behalf Of *Nathaniel
> Bentzinger
> *Sent:* Friday, December 12, 2014 16:45
> *To:* [email protected] <javascript:>
> *Subject:* RE: [ossec-list] Re: anyone know the status of the issue where
> IIS logs are not able to trigger on web_rules.xml
>
>
>
> Just a side note since you mention IIS is your biggest liability for some
> reason consider running the free version of dotDefender on your Windows
> server then monitor with OSSEC the Event logs for dotDefender. That way you
> can create active-responses against what dotDefender finds and it finds
> everything. Just be sure to update your agent’s OSSEC config to look at
> dotdefender event logs.
>
>
>
> here are my local_rules for dotdefender:
>
> <rule id="100015" level="7">
>
> <if_sid>18100</if_sid>
>
> <match>Applicure|dotDefender</match>
>
> <description>dotDefender Alert</description>
>
> <group>system_error, Applicure</group>
>
> </rule>
>
>
>
> <rule id="100016" level="8" frequency="20" timeframe="120">
>
> <if_matched_sid>100015</if_matched_sid>
>
> <description>Multiple dotDefender Alerts</description>
>
> <group>system_error, Applicure</group>
>
> </rule>
>
>
>
> <rule id="100017" level="7">
>
> <if_sid>100015</if_sid>
>
> <match>Session Protection</match>
>
> <description>dotDefender Alert: Session Protection</description>
>
> <group>system_error, Applicure, Session_Protection</group>
>
> </rule>
>
>
>
> <rule id="100018" level="7">
>
> <if_sid>100015</if_sid>
>
> <match>SQL Injection|Classic SQL</match>
>
> <description>dotDefender Alert: SQL Injection Attempt</description>
>
> <group>system_error, Applicure, SQL_Injection_attempt</group>
>
> </rule>
>
>
>
> <rule id="100019" level="7">
>
> <if_sid>100015</if_sid>
>
> <match>Compromised/Hacked Servers</match>
>
> <description>dotDefender Alert: Compromised/Hacked
> Servers</description>
>
> <group>system_error, Applicure, Hacked_Servers</group>
>
> </rule>
>
>
>
> <rule id="100020" level="6">
>
> <if_sid>100015</if_sid>
>
> <match>Anti-Proxy Protection|Generic Anti-proxy Protection</match>
>
> <description>dotDefender Alert: Anti-proxy Protection</description>
>
> <group>system_error, Applicure, Anti-proxy_Protection</group>
>
> </rule>
>
>
>
> IIS will just give you 4xx/5xx ins OSSEC you’d have to adjust the rules to
> capture everything else.
>
>
>
>
>
> *From:* [email protected] <javascript:> [
> mailto:[email protected] <javascript:>] *On Behalf Of *Brent Morris
> *Sent:* Friday, December 12, 2014 4:07 PM
> *To:* [email protected] <javascript:>
> *Subject:* [ossec-list] Re: anyone know the status of the issue where IIS
> logs are not able to trigger on web_rules.xml
>
>
>
> OK - on another system I'm able to get the web_rules.xml to trigger.
>
>
>
> I setup IIS logging on this system... in W3C format. selected all the
> fields..
>
> #Fields: date time s-sitename s-computername s-ip cs-method cs-uri-stem
> cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie)
> cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes
> cs-bytes time-taken
>
>
>
> OSSEC config on the monitored system looks like this.
>
>
>
> <localfile>
> <location>C:\inetpub\logs\LogFiles\W3SVC1\u_ex%y%m%d.log</location>
> <log_format>iis</log_format>
> </localfile>
>
>
>
> restarted the ossec agent.... and iisreset too...
>
>
>
> hammered on it for cmd.exe
>
>
>
> and zoop zoop!
>
> OSSEC HIDS Notification.
> 2014 Dec 12 13:01:50
>
> Received From: (IIS8-5Server)
> 1.2.3.4->\inetpub\logs\LogFiles\W3SVC1\u_ex141212.log
> Rule: 31153 fired (level 10) -> "Multiple common web attacks from same
> souce ip."
> Portion of the log(s):
>
> 2014-12-12 21:00:55 W3SVC1 IIS8-5Server 1.2.3.4 GET /cmd.exe - 443 -
> 2.3.4.5 HTTP/1.1
> Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - -
> IIS8-5Server 404 0 2 1477 256 0
>
>
>
>
>
>
>
>
>
>
> On Friday, December 12, 2014 7:37:15 AM UTC-8, James Whittington wrote:
>
> I was just curious if anyone knew the status of the issue where IIS logs
> are not able to trigger on web_rules.xml?
>
> Basically even with a correct IIS decoder in place the web rules will
> never trigger.
>
>
>
> I came across some pretty obvious SQL Injection Attacks against IIS
> websites and was trying to determine why OSSEC didn’t catch those events.
>
>
>
> So really there is no point to running IIS logs through OSSEC if you can’t
> trigger against rules.
>
>
>
> I see the issue was raised here
> https://github.com/ossec/ossec-hids/issues/164
>
> With possible fix here https://github.com/ossec/ossec-hids/pull/434
>
>
>
> James Whittington
>
>
>
> --
>
> ---
> 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] <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.
