NM, found it! ;-) syslog.... duh. On Tuesday, April 26, 2016 at 10:15:03 AM UTC-4, Rob B wrote: > > 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.