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.
