Im having several issues and questions about what the best practices would be for surronding ageout policys.
Still going through configurations via trial-and-error approach as the indicator numbers are not looking correct at all.
Reviewing configuration for Output of class minemeld.ft.taxii.DataFeed
Added the following config:
infilters: - actions: - accept conditions: - __method == 'withdraw' name: accept withdraws - actions: - accept conditions: - type == 'IPv4' name: accept IPv4 - actions: - drop name: drop all
Would it be helpful to add "store_value: true" and how?
Is there anything that may be helpful to add to an OUTPUT configuration to make sure the node (somehow) does not keep accumulating indicators after every update and ignores indicators that have already been seen/aged-out ?
Any and all assistance or feedback is very much appreciated.
There are still unanswered questions regarding aging of indicators, as well as minemeld working output configuration.
We are also trying to understand behaviors showing in our Minemeld instance such as:
Miner node #1 has 7413 indicators
Miner node #2 has 783 indicators
Processor, with Miner node #1 and Miner node #2 as input, has 8196 indicators
Output (minemeld.ft.redis.RedisSet) has 7413 indicators
Same processor with different Output (minemeld.ft.taxii.DataFeed) and it currently has 587479 indicators – this number keeps on growing as indicators just keep getting added on until the next service restart.
Any advice, guides or hints are much appreciated and thank you very much for your time and assistance.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!