Showing results for 
Search instead for 
Did you mean: 
Reliable Contributor sssyyy
Reliable Contributor
Report Inappropriate Content
Message 11 of 17

Re: ds rules

create a ASP, order it to be on the top of DS rules. and it will fire on the ASP.

Level 7
Report Inappropriate Content
Message 12 of 17

Re: ds rules


what data source type should i choose ?

as you can see I'm using generic and there is no generic data source type in "order ASP rules"


Re: ds rules

You don't need to reorder the rule.  What is occuring is because you selected generic syslog it is creating a DS rule for each unique syslog entry the receiver receives.

What you need to do is write a custom parser. See - McAfee Corporate KB - Writing Custom Parsing Rules in McAfee ESM PD24926

Make sure the parser is enabled in the policy bound to the data source.  Then all events will fire off that parser.  (You may need to create more than one parser).  But you may want to check the security onion distro, you may be able to set the output to CEF (Common Event Format).  IF so, start with CEF and that can help out a lot!

Level 7
Report Inappropriate Content
Message 14 of 17

Re: ds rules

as  i wrote before, i have a working custom parser , but still this data source contain more then 7000 rules

i just want to understand why....


Reliable Contributor sssyyy
Reliable Contributor
Report Inappropriate Content
Message 15 of 17

Re: ds rules

Don't worry about those data source rules, they must have been created by SIEM when you had "create user defined rules" on under Support Generic Syslogs. You can now create your ASP rule or existing custom ASP rule, move them over from unordered rule windows to ordered, left to right. Place them on top and roll out, new incoming events should match these custom ASP rules rather than data source rules.

Level 7
Report Inappropriate Content
Message 16 of 17

Re: ds rules

yes , the ASP rules are working fine

but I'm not understand why i have this DS auto leaned rules

what you mean by "write the DS config to the reciever" ?


McAfee Employee andy777
McAfee Employee
Report Inappropriate Content
Message 17 of 17

Re: ds rules

Auto-learning rules are critical and powerful so understanding how they work is important.

First of all, as has been mentioned, there is an option for "Parse as Generic Syslog" under the Data Source settings. It's really a remnant of an earlier era and should never be used under any circumstances. The reason is that every time a different event is received, it will be learned as its own rule. Almost all events are going to have a timestamp and this will be different with every event leading to the creation of a rule and filing up the rule table quickly (1 million rule limit).

The way to leverage auto-learning to your advantage is when you have events with the same structure and the dynamic piece is finite. For instance, let's say I have the following events:

Nov  4 17:48:47 tecate dovecot: imap(lisa): Disconnected: Logged out in=578 out=75618

Nov  4 17:53:27 tecate dovecot: imap(tori): Disconnected for inactivity in=7875 out=141041

I could write a single parsing rule like this:


and set the Signature Name to: "Linux IMAP: "+1:4

They would show up as:

Linux IMAP Disconnected for inactivity

Linux IMAP Disconnected: Logged out

thus we have two auto-learned rules.

If the vendor has the insight to create their log output with a consistent format, we can parse all of the messages with a small number of rules. Another example would be a device that outputs the facility, e.g. debug, info, error, critical, fatal in that we can use auto-learning to correctly classify and parse the data regardless of the content. This is ideal. This is the case and goal with formats like CEF and JSON.

So the gist is that auto-learning is great for creating parsing rules without the need to create a rule for every single variation. When you see a pattern, make it part of the rule. However, it's important to not include anything in the rule name that shows a lot of variation, like a timestamp, IP address, hostname, etc... lest your rule table fill up. There's nothing wrong with a complex product requiring a large number of rules (BRO, Security Onion, pfSense) so long as you're on top of approximately how many rules are being created, and why.

If you blow up your rules table, you can delete specific auto-learned rules, rules learned for a particular data source type*, rules learned during a particular window or all rules. When you delete auto-learned rules that include existing events, the event name will show up as '0' until the rule is auto-learned again. Be aware of this in the instance where you might change a parsing rule and delete the auto-learned rules. New rules may not ever match the original rule again thus leaving the event name at '0', so do be aware of deleting auto-learned rules that may never be relearned if you are required to maintain that data.

* Notable since I did not say a specific data source, only the type. We're not able to delete rules for a single Data Source unless it is the only one of its type.

There is a bit of nuance in parsing and auto-learning, but it's gratifying once you're able to understand why they work the way they do. Please continue to ask more questions if you have them. Thanks.

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • Community Help Hub

      New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

    • Find Forum FAQs
    • Learn How to Earn Badges
    • Ask for Help
    Go to Community Help

    Join the Community

      Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

    • Get helpful solutions from McAfee experts.
    • Stay connected to product conversations that matter to you.
    • Participate in product groups led by McAfee employees.
    Join the Community
    Join the Community