On Tue, Apr 26, 2016 at 10:15 AM, Rob B <rba...@netorian.com> wrote:
> what _rules.xml file is 1002 located? I wish I had some kind of rules
> legend to reference..... Thanks. ;-)
>
[ddp@ix] :; grep '"1002"' /var/ossec/rules/*_rules.xml
/var/ossec/rules/syslog_rules.xml: <rule id="1002" level="2">
>
>
> 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, I feel them really useful and you can
>>>> find more rules for Amazon in the linked repository. Also, you can find
>>>> interesting this script 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.
--
---
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.
