what _rules.xml file is 1002 located?   I wish I had some kind of rules 
legend to reference.....  Thanks.  ;-)



On Tuesday, April 26, 2016 at 8:20:11 AM UTC-4, theresa mic-snare wrote:
>
> Also, I should explain why I first wrote 1002....
> I often check for this rule (2 - Unknown problem somewhere in the 
> system.) just to see if there are any false-positives that haven't been 
> covered by an existing rule yet.
> Then I would see which log event needs a new rule or decoder, so that it 
> would be covered the next time it occurs.... :)
>
>
> Am Dienstag, 26. April 2016 14:08:29 UTC+2 schrieb theresa mic-snare:
>>
>> I woke up this morning with a notification on my phone that this 
>> following rule fired again:
>>
>>     <rule id="31166" level="15">
>>         <if_sid>31108</if_sid>
>>         <regex>"\(\)\s*{\s*:;\s*}\s*;</regex>
>>         <description>Shellshock attack detected</description>
>>         <group>attack,pci_dss_11.4,</group>
>>     </rule>
>>
>> Just as I thought that the Shellshock hype was over......someone from 
>> China tried to penetrate my server again...
>> harmless since I patch my server frequently, but still interesting to see 
>> what's going on....
>>
>> Good to see that OSSEC is capable of detecting recent/modern threats :)
>>
>> Am Dienstag, 26. April 2016 13:44:42 UTC+2 schrieb Jesus Linares:
>>>
>>> Interesting thread. 
>>>
>>> lately I'm using Amazon EC2 Rules 
>>> <https://github.com/wazuh/ossec-rules/tree/master/rules-decoders/amazon-ec2>,
>>>  
>>> I feel them really useful and you can find more rules for Amazon in the 
>>> linked repository. Also, you can find interesting this script 
>>> <http://blog.wazuh.com/keep-your-ruleset-updated-automatically/>to 
>>> update your rules automatically.
>>>
>>> I would like to know what rules are you missing in OSSEC.
>>>
>>>
>>> Regards.
>>> Jesus Linares.
>>>
>>> On Monday, April 25, 2016 at 12:20:50 AM UTC+2, theresa mic-snare wrote:
>>>>
>>>> 1002 ;))))))
>>>>
>>>> Am Freitag, 22. April 2016 19:07:32 UTC+2 schrieb namobud...@gmail.com:
>>>>>
>>>>> These worked great, just wondering if you have any updates.
>>>>>
>>>>> On Thursday, March 3, 2016 at 12:46:38 PM UTC-5, LostInThe Tubez wrote:
>>>>>>
>>>>>> Good thread idea. I’ve copied a few Windows-centric rules below. Some 
>>>>>> of the rules that lean heavily on <match> could no doubt be improved, 
>>>>>> but 
>>>>>> they don’t bother me with false positives or performance issues in my 
>>>>>> small 
>>>>>> environment, so I don’t worry about it. YMMV. I also have some decoders 
>>>>>> and 
>>>>>> rules for Cowrie honeypots, but intend to polish those up and submit a 
>>>>>> pull 
>>>>>> request for those one of these days. If anyone is interested in testing 
>>>>>> them though, I could send those off list.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> <rule id="100006" level="8">
>>>>>>
>>>>>>         <if_sid>594</if_sid>
>>>>>>
>>>>>>         <match>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run</match>
>>>>>>
>>>>>>         <description>A change has been made to the software that 
>>>>>> automatically runs at startup.</description>
>>>>>>
>>>>>> </rule>
>>>>>>
>>>>>>  
>>>>>>
>>>>>> <rule id="100010" level="7">
>>>>>>
>>>>>>         <if_sid>18103</if_sid>
>>>>>>
>>>>>>         <match>Length specified in network packet</match>
>>>>>>
>>>>>>         <description>Somebody is sending malformed data to your SQL 
>>>>>> Server. You should probably investigate.</description>
>>>>>>
>>>>>> </rule>
>>>>>>
>>>>>>  
>>>>>>
>>>>>> <rule id="100011" level="10">
>>>>>>
>>>>>>         <if_sid>18101</if_sid>
>>>>>>
>>>>>>         <match>PSEXESVC|PsExec</match>
>>>>>>
>>>>>>         <description>Remote access via PSEXEC. If this wasn't 
>>>>>> initiated by you, then you've got a problem.</description>
>>>>>>
>>>>>> </rule>
>>>>>>
>>>>>>  
>>>>>>
>>>>>> <rule id="100013" level="8">
>>>>>>
>>>>>>         <if_sid>18102</if_sid>
>>>>>>
>>>>>>         <id>^2004$</id>
>>>>>>
>>>>>>         <match>diagnosed</match>
>>>>>>
>>>>>>         <description>There's a problem with abnormal memory usage on 
>>>>>> this system! Please investigate the indicated processes.</description>
>>>>>>
>>>>>> </rule>
>>>>>>
>>>>>>  
>>>>>>
>>>>>> <rule id="100014" level="7">
>>>>>>
>>>>>>         <if_sid>18104</if_sid>
>>>>>>
>>>>>>         <id>4698</id>
>>>>>>
>>>>>>         <description>A scheduled task has been created on this 
>>>>>> machine. Please review.</description>
>>>>>>
>>>>>>         <info>Requires group policy modification to the Advanced 
>>>>>> Security Audit policy/Audit Other Object Access Events. See: 
>>>>>> https://technet.microsoft.com/en-us/library/dn319119.aspx</info>
>>>>>>
>>>>>> </rule>
>>>>>>
>>>>>>  
>>>>>>
>>>>>> <rule id="100016" level="1">
>>>>>>
>>>>>>         <if_sid>18103</if_sid>
>>>>>>
>>>>>>         <id>36874|36888</id>
>>>>>>
>>>>>>         <group>recon_ssl,</group>
>>>>>>
>>>>>>         <description>Add Schannel errors to the custom recon_ssl 
>>>>>> group</description>
>>>>>>
>>>>>> </rule>
>>>>>>
>>>>>>  
>>>>>>
>>>>>> <rule id="100017" level="7" frequency="38" timeframe="120" 
>>>>>> ignore="1800">
>>>>>>
>>>>>>         <if_matched_group>recon_ssl</if_matched_group>
>>>>>>
>>>>>>         <description>There have been over 40 SSL cipher suite probes 
>>>>>> in the last two minutes. Someone may be performing reconnaissance on 
>>>>>> your 
>>>>>> servers, assessing whether one of your SSL-enabled services is 
>>>>>> vulnerable 
>>>>>> to exploits.</description>
>>>>>>
>>>>>>         <info>Unfortunately, Schannel errors are of limited 
>>>>>> usefulness. They occur without any indication of which IP address caused 
>>>>>> them, so consulting contextual log info or firewall logs is the only way 
>>>>>> to 
>>>>>> track down who is responsible.</info>
>>>>>>
>>>>>> </rule>
>>>>>>
>>>>>>  
>>>>>>
>>>>>> <rule id="100022" level="7">
>>>>>>
>>>>>>         <if_sid>18103</if_sid>
>>>>>>
>>>>>>         <id>^1000$|^1002$|^7023$|^7034$</id>
>>>>>>
>>>>>>         <!--<match>Fault|terminate</match>-->
>>>>>>
>>>>>>         <description>A program or service has crashed. Investigate as 
>>>>>> appropriate.</description>
>>>>>>
>>>>>> </rule>
>>>>>>
>>>>>>  
>>>>>>
>>>>>> <rule id="100026" level="7">
>>>>>>
>>>>>>         <if_sid>18101</if_sid>
>>>>>>
>>>>>>         <id>^7045$</id>
>>>>>>
>>>>>>         <description>A new service has been installed on this 
>>>>>> computer.</description>
>>>>>>
>>>>>> </rule>
>>>>>>
>>>>>>  
>>>>>>
>>>>>> *From:* ossec...@googlegroups.com [mailto:ossec...@googlegroups.com] *On 
>>>>>> Behalf Of *namobud...@gmail.com
>>>>>> *Sent:* Thursday, March 3, 2016 6:35 AM
>>>>>> *To:* ossec-list <ossec...@googlegroups.com>
>>>>>> *Subject:* [ossec-list] What's your favorite rules?
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I'm wondering what everyone's favorite rules are.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I'm trying to come up with some new rules to tighten security, so I 
>>>>>> would like to hear (and see code snippets) or folks favorites, and what 
>>>>>> they are designed to detect. I.E. detect commands run, look for certain 
>>>>>> IOC's and so on. I'm impressed with how much OSSEC does out of box too!
>>>>>>
>>>>>>  
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>  
>>>>>>
>>>>>> -- 
>>>>>>
>>>>>> --- 
>>>>>> 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 ossec-list+...@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>

-- 

--- 
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 ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to