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.
