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!
--
Olivier Bilodeau
[email protected] :: +1.514.447.4918 *115 :: www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
