There are a couple of ways to track connected devices.
It depends on where DHCP lives. If it's on a windows computer, add DHCP
logs to your OSSEC configuration.
<localfile>
<location>%windir%\sysnative\Dhcp\DhcpSrvLog-%a.log</location>
<log_format>syslog</log_format>
</localfile>
Then inside your DHCP MMC, right click on the IPV4 scope and go to
properties. General tab and check "Enable DHCP audit logging".
If you have Cisco switches, you could do a couple of tricks to do some
tracking of MACs to IP addresses, but it would require some scripting
through OSSEC. Not impossible, but it hasn't been written yet.
On Sunday, February 14, 2016 at 11:26:49 AM UTC-8, 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.
