Thanks again Jesus! Will try and get my test rule working as per your instruction. In my case I would need to make an exception to rule 31108 given the current result from ossec_logtest (previous example). I would like to ignore URLs (simple queries) for the most part, but not for a specific URL.
Definitely :) I will put together a new thread with my current thoughts on building something for connecting devices, hopefully it will pique a few peoples interest even if I haven't gathered all my thoughts on the matter yet. 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.
