“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] [mailto:[email protected]] On Behalf Of Nathaniel Bentzinger Sent: Friday, December 12, 2014 16:45 To: [email protected] 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] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Brent Morris Sent: Friday, December 12, 2014 4:07 PM To: [email protected] <mailto:[email protected]> 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] <mailto:[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] <mailto:[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.
