On 05/02/2012 11:39 AM, Olivier Bilodeau wrote:
> Hi Andi,
> 
> [...]
> 
>> Ideally I would like packetfence to have a violation for a category, eg.
>> Worm infection, and this violation is triggered by ANY pattern matching
>> the behaviour within the relevant ruleset.  However, each time I come to
>> configure this it always seems that it actually needs the individual
>> pattern IDs, rather than the all-encompassing ruleset.  In my mind this
>> could potentially mean that there are thousands of individual IDs to be
>> associated with each violation, and then when oinkmaster updates the
>> ruleset, the administrator needs to go to each file and manually add in
>> the new pattern IDs.
>>
>> This seems like a huge admin burden, if I am indeed reading up on this
>> in the correct way. 
> 
> Yes, you are correct. It is currently difficult.
> 
>> Is it possible to, for example, associate the ‘Worm
>> Infection’ violation, with the emerging-worm.rules file, and it then
>> reads the entire ruleset into the violation?
>>
> 
> Not currently but I would like to discuss the option of doing so.
> 
> Here's a sample alert format:
> 
> 05/02-10:21:21.106049  [**] [1:2003494:20] ET POLICY AskSearch Toolbar
> Spyware User-Agent (AskTBar) [**] [Classification: Pot
> ential Corporate Privacy Violation] [Priority: 1] {TCP} 1.1.1.1:1390 ->
> 2.2.2.2:80
> 
> We could probably try to capture either the "ET <something>" prefix of
> the alert description or the classification. Can you look at the alerts
> generated in your environment and send us a good sample of what you
> would like to trap?
> 
> The result in conf/violations.conf could be:
> # {GPL,ET,VRT} <something> match
> trigger=snort-ruleset::ET MALWARE
> or
> # classification match
> trigger=snort-ruleset::A Network Trojan was Detected
> 
> There would be a lot of potential false positive going that route but
> since oinkmaster remembers the disabled rules I can definitely see it as
> a viable option. Administrators could enable a whole ruleset in log or
> email, then comment the noisy rules out and then finally enable it as a
> trap violation and handle new false positives on updates.
> 
> Code-wise, this involves parsing changes to the trigger format and
> refactoring of the whole trigger concept (is integer based but got too
> complex since introduction of bandwidth triggers) into objects to allow
> easier introduction of new triggers.
> 
> With proper integration / testing this is not a small change but not a
> huge one either.
> 
> Community, can you look at your snort output and decide whether it would
> be better to use the ruleset name convention ({ET,GPL,VRT} Something) or
> the classification? I'm not familiar enough with snort rules to know if
> classification strings can be relied upon.
> 
> This would be quite an improvement regarding our snort integration and I
> would like feedback early please!
> 
> Cheers!