Hi Jesus!
So, sorry! My bad! Like you said, my last example did work - I made a typo in the string I used to test the rule :( Thanks for looking into it though and also explaining the group concatenation! Best regards, Fredrik On Friday, February 19, 2016 at 2:06:51 PM UTC+1, Jesus Linares wrote: > > Hi Fredrik, > > OSSEC concatenates groups using ','. So you need the last ',' in group > tag. Now you rule has the groups: web,accesslog,access_allowed. If you > don't use the last comma you will have: web,accesslogaccess_allowed. > > That rule is working for me: > > 10.10.10.01 example.com - [18/Feb/2016:00:00:00 -0500] "GET > /images/logo2.png/ HTTP/1.1" 302 Text... > > **Phase 1: Completed pre-decoding. > full event: '10.10.10.01 example.com - [18/Feb/2016:00:00:00 > -0500] "GET /images/logo2.png/ HTTP/1.1" 302 Text...' > hostname: 'LinMV' > program_name: '(null)' > log: '10.10.10.01 example.com - [18/Feb/2016:00:00:00 -0500] "GET > /images/logo2.png/ HTTP/1.1" 302 Text...' > > > **Phase 2: Completed decoding. > decoder: 'web-accesslog' > srcip: '10.10.10.01' > url: '/images/logo2.png/' > id: '302' > > > **Phase 3: Completed filtering (rules). > Rule id: '100120' > Level: '12' > Description: 'URL requested -- images/logo2.png' > **Alert to be generated. > > > Are you sure about the url?. Could you paste here the log?. > > Try always your rules with /var/ossec/bin/ossec-logtest. > > Regards. > Jesus Linares > > On Thursday, February 18, 2016 at 10:42:16 PM UTC+1, Fredrik wrote: >> >> Hi again :) >> >> >> Looking at your previous example I put this together while looking in the >> book where rule hierarchies are discussed. As an exemple if I wanted to >> make an exception to webrule 31108 and say to ignore 2xx and 3xx code >> unless a specific URL is requested (GET). I placed the below in my >> local_rules.xml, but as expected from Noob - it won't fire ;) >> >> <group name="web,accesslog,"> >> <rule id="100120" level="12"> >> <if_sid>31108</if_sid> >> <group>access_allowed</group> >> <options>alert_by_email</options> >> <url>/images/logo2.png/</url> >> <description>URL requested -- images/logo2.png</description> >> </rule> >> </group> >> >> >> One more specific question, in this example what does the <Group Name=> >> and especially the last ',' instruct OSSEC to do? >> >> Best regards, >> Fredrik >> >> On Monday, February 15, 2016 at 11:58:13 AM UTC+1, Jesus Linares wrote: >>> >>> Hi Fredrik, >>> >>> user-created rules are defined in *local_rules.xml* and the range is >>> from 100000 to 119999. If you want to change the behaviour of a rule you >>> have to use the option *overwrite*. Using the *overwrite *option >>> instructs rule engine to use the local rule definition instead of the one >>> found in the */var/ossec/rules/* directory. >>> >>> Example: Change message in ssh authentication. local_rules.xml: >>> <group name="local,ssh,"> >>> <rule id="5715" level="3" overwrite="yes"> >>> <if_sid>5700</if_sid> >>> <match>^Accepted|authenticated.$</match> >>> <description>SSHD authentication success LOCAL RULES TEST. >>> </description> >>> <group>authentication_success,pci_dss_10.2.5,</group> >>> </rule> >>> </group> >>> >>> It would be very interesting if you share the stuff about track >>> connecting devices ;) >>> >>> Regards. >>> Jesus Linares. >>> >>> On Sunday, February 14, 2016 at 8:26:49 PM UTC+1, Fredrik wrote: >>>> >>>> Good example! Definitely helpful! Thanks! >>>> >>>> One thing, I know I read about it somewhere, but how do I group my >>>> entries in the local_rules file to make them fire. Say for example that I >>>> would like to change the behavior of the 31008 rule with an exception? >>>> Will >>>> go back through the collection of links to see if I can figure it out :) >>>> Also, saw some interesting stuff on how to track connecting devices >>>> (dhcp) >>>> through MAC-addresses -- obviously unrelated to IIS logs though ;) >>>> >>>> Best regards, >>>> Fredrik >>>> >>>> On Thursday, February 11, 2016 at 12:25:33 AM UTC+1, Brent Morris wrote: >>>>> >>>>> eesh... hotkeys got away from me and I posted too fast. >>>>> >>>>> Sure.. >>>>> >>>>> You can do some active response stuff on ID 400... That's fun to do! >>>>> >>>>> For me personally, I took a fingerprint of all the web vulnerability >>>>> scanners and made it into a CDB list. This was from Nexpose, OpenVAS, >>>>> and >>>>> a pilfered some extras from old logs... put those all in a CDB list and >>>>> added a rule. >>>>> >>>>> Local_rules.xml >>>>> >>>>> <rule id="184780" level="12"> >>>>> <if_sid>31100</if_sid> >>>>> <list field="url">lists/urlblacklist</list> >>>>> <description>Web Vulnerability Scanner Detected</description> >>>>> </rule> >>>>> --- >>>>> ossec.config >>>>> >>>>> <ossec_config> >>>>> <rules> >>>>> <list>lists/urlblacklist</list> >>>>> .... >>>>> >>>>> then >>>>> <active-response> >>>>> <command>firewall-drop</command> >>>>> <location>server</location> >>>>> <rules_id>31100</rules_id> >>>>> <timeout>300</timeout> >>>>> </active-response> >>>>> >>>>> --- >>>>> >>>>> sample content of urlblacklist (it's a long file) >>>>> >>>>> /bblog/xmlrpc.php -:17 >>>>> /scripts/root.exe -:17 >>>>> /msadc/msadcs.dll -:17 >>>>> /cgi-bin/test-cgi -:17 >>>>> /cgi-bin/htsearch -:17 >>>>> /CFIDE/adminiapi/ -:17 >>>>> /cgi-bin/faxquery -:17 >>>>> /CFIDE/scheduler/ -:17 >>>>> /CFIDE/websocket/ -:17 >>>>> /common/index.jsf -:17 >>>>> /cgi-bin/home.tcl -:17 >>>>> /bblog/xmlrpc.php -:17 >>>>> /cfdocs/index.htm -:17 >>>>> >>>>> --------------------- >>>>> >>>>> Now you can detect and block those pesky web vulnerability >>>>> scanners.... You'll have to connect the active response to your actual >>>>> firewall and configure the script accordingly. And you'll likely have >>>>> some >>>>> samples of web scanners if you have a web server connected to the net. >>>>> We >>>>> get scanned all the time... >>>>> >>>>> And you could block repeat 404 errors too... >>>>> >>>>> This isn't a complete tutorial; you'll need to read up on creating CDB >>>>> lists, and compiling them. You'll also need to get active response >>>>> working. And, ALWAYS test it when you're done so you can be sure you're >>>>> blocking those pesky scanners but not blocking valid traffic. One wrong >>>>> URL in that CDB list and OSSEC suddenly turns on you and bites. And one >>>>> wrong character on a line can be the difference between a hit and a miss. >>>>> >>>>> HTH!!! >>>>> >>>>> >>>>> >>>>> >>>>> On Wednesday, February 10, 2016 at 3:15:49 PM UTC-8, Brent Morris >>>>> wrote: >>>>>> >>>>>> Sure.. >>>>>> >>>>>> You can do some active response stuff on ID 400... That's fun to do! >>>>>> >>>>>> For me personally, I took a fingerprint of all the web vulnerability >>>>>> scanners and made it into a CDB list. This was from Nexpose, OpenVAS, >>>>>> and >>>>>> a pilfered some extras from old logs... put those all in a CDB list and >>>>>> added a rule. >>>>>> >>>>>> Local_rules.xml >>>>>> >>>>>> <rule id="184780" level="12"> >>>>>> <if_sid>31100</if_sid> >>>>>> <list field="url">lists/urlblacklist</list> >>>>>> <description>Web Vulnerability Scanner Detected</description> >>>>>> </rule> >>>>>> >>>>>> ossec.config >>>>>> >>>>>> <ossec_config> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, February 9, 2016 at 1:24:24 PM UTC-8, Fredrik wrote: >>>>>>> >>>>>>> Hi Brent, >>>>>>> >>>>>>> >>>>>>> Just mentioned in post to Jesus that I have been (still am) learning >>>>>>> as I go :) Your recommendation to stick with the three fields url, >>>>>>> srcip >>>>>>> and ID makes sense in my case as well. I noticed that the logging >>>>>>> settings >>>>>>> in IIS7.5 looks somewhat different, but as expected all options were >>>>>>> not >>>>>>> checked in this server's configuration. >>>>>>> >>>>>>> Regarding the alerts, I'm more trying to set up a few samples to see >>>>>>> what I can catch. Do you have any recommendations of things to try? >>>>>>> Maybe >>>>>>> one for requests resulting in ID 400? >>>>>>> >>>>>>> Best regards, >>>>>>> Fredrik >>>>>>> >>>>>>> On Monday, February 8, 2016 at 9:24:18 PM UTC+1, Brent Morris wrote: >>>>>>>> >>>>>>>> Fredrik, >>>>>>>> >>>>>>>> The stuff you cooked up has some issues. If you want those fields >>>>>>>> extracted and were going to use them for alerts, I'd go with Jesus' >>>>>>>> 2nd >>>>>>>> recommendation. It's a good expansion of the default IIS logging >>>>>>>> decoders >>>>>>>> from the OSSEC git repository. >>>>>>>> >>>>>>>> If you change your logging per the OSSEC instructions, I don't >>>>>>>> believe that his recommended decoder will work and the built-in >>>>>>>> decoder >>>>>>>> will trigger. Which by default, only pulls out the url, srcip and ID. >>>>>>>> It >>>>>>>> doesn't get the destip, port and action. I've found the srcip, URL, >>>>>>>> and ID >>>>>>>> to be the most valuable. If you had a large farm or servers with >>>>>>>> multiple >>>>>>>> addresses, I can see why destip would be useful.... Or the action (IIS >>>>>>>> verb). Give us a little more background as to what problem you're >>>>>>>> trying >>>>>>>> to solve and I'm sure we can help you further :) >>>>>>>> >>>>>>>> -Brent >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Saturday, February 6, 2016 at 12:04:53 PM UTC-8, Fredrik wrote: >>>>>>>>> >>>>>>>>> Guys! Thanks both for taking the time to respond! So, if I >>>>>>>>> understand this correctly I could use default IIS logging and go with >>>>>>>>> Jesus >>>>>>>>> suggestion - this would require updating the OSSEC binaries though, >>>>>>>>> correct? as you suggest Brent, having a look at the logging settings >>>>>>>>> in IIS >>>>>>>>> makes sense regardless. Provided I'm able to update the logging, what >>>>>>>>> decoder settings should I use? Go with Jesus', or is the stuff I >>>>>>>>> cooked up >>>>>>>>> worth pursuing? >>>>>>>>> >>>>>>>>> Thanks again! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Fredrik >>>>>>>>> >>>>>>>>> On Thursday, February 4, 2016 at 9:05:09 PM UTC+1, Brent Morris >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> In order to get OSSEC to work with IIS logs, you have to >>>>>>>>>> basically enable all the Extended logging options... Be sure to >>>>>>>>>> check the >>>>>>>>>> "use local time for file naming and rollover" - otherwise your OSSEC >>>>>>>>>> will >>>>>>>>>> be dark for a few hours while it catches up with IIS's GMT time. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://ossec-docs.readthedocs.org/en/latest/manual/monitoring/file-log-monitoring.html >>>>>>>>>> >>>>>>>>>> - scroll down from there to see the screen shots. >>>>>>>>>> >>>>>>>>>> Jesus' recommendation is a change committed in the next release >>>>>>>>>> of the version of OSSEC. You could add that to your >>>>>>>>>> local_decoder.xml if >>>>>>>>>> you wanted. We put that in there as a catch-all for the IIS logs >>>>>>>>>> still in >>>>>>>>>> default mode. But it's can't hurt to turn up the logging in IIS me >>>>>>>>>> thinks. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wednesday, February 3, 2016 at 12:59:25 PM UTC-8, Fredrik >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Gone through a few threads about decoders for IIS. I'm just >>>>>>>>>>> getting started and, so far, have only managed easy stuff. I'm >>>>>>>>>>> trying to >>>>>>>>>>> extract the fields mentioned in decoder from the log entry using >>>>>>>>>>> the >>>>>>>>>>> decoder below, but the logtester still give the result below. What >>>>>>>>>>> am I >>>>>>>>>>> missing this time :) >>>>>>>>>>> >>>>>>>>>>> FULL LOG ENTRY: >>>>>>>>>>> 2016-02-02 08:45:31 10.32.10.14 GET /images/logo2.png - 80 - >>>>>>>>>>> 10.32.5.145 >>>>>>>>>>> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.3;+WOW64;+Trident/7.0;+Touch;+.NET4.0E;+.NET4.0C;+.NET+CLR+3.5.30729;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+Tablet+PC+2.0) >>>>>>>>>>> >>>>>>>>>>> 200 0 0 15 >>>>>>>>>>> >>>>>>>>>>> LOGTEST RESULTS: >>>>>>>>>>> **Phase 1: Completed pre-decoding. >>>>>>>>>>> full event: '2016-02-02 08:45:31 10.46.10.101 GET >>>>>>>>>>> /images/logo2.png - 80 - 10.46.5.145 >>>>>>>>>>> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.3;+WOW64;+Trident/7.0;+Touch;+.NET4.0E;+.NET4.0C;+.NET+CLR+3.5.30729;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+Tablet+PC+2.0) >>>>>>>>>>> >>>>>>>>>>> 200 0 0 15' >>>>>>>>>>> hostname: 'sto-lab99' >>>>>>>>>>> program_name: '(null)' >>>>>>>>>>> log: '2016-02-02 08:45:31 10.46.10.101 GET >>>>>>>>>>> /images/logo2.png - 80 - 10.46.5.145 >>>>>>>>>>> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.3;+WOW64;+Trident/7.0;+Touch;+.NET4.0E;+.NET4.0C;+.NET+CLR+3.5.30729;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+Tablet+PC+2.0) >>>>>>>>>>> >>>>>>>>>>> 200 0 0 15' >>>>>>>>>>> >>>>>>>>>>> **Phase 2: Completed decoding. >>>>>>>>>>> decoder: 'windows-date-format' >>>>>>>>>>> >>>>>>>>>>> DECODER: >>>>>>>>>>> <decoder name="web-accesslog-iis"> >>>>>>>>>>> <parent>windows-date-format</parent> >>>>>>>>>>> <type>web-log</type> >>>>>>>>>>> <use_own_name>true</use_own_name> >>>>>>>>>>> <regex offset="after_parent">^\d+-\d+-\d+ \d+:\d+:\d+ (\S+) >>>>>>>>>>> (\S+) - (\S+) - (\d+.\d+.\d+.\d+) </regex> >>>>>>>>>>> <order>srcip, action, url, srcip, dstport</order> >>>>>>>>>>> </decoder> >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Fredrik >>>>>>>>>>> >>>>>>>>>>> -- --- 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.
