Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditional Pipelines additional to filters? #1437

Open
ghost opened this issue Aug 15, 2019 · 3 comments
Open

Conditional Pipelines additional to filters? #1437

ghost opened this issue Aug 15, 2019 · 3 comments

Comments

@ghost
Copy link

ghost commented Aug 15, 2019

Idea: What about using Conditioned Pipelines additional to filters?
This might solve my requirement stated in #569 (comment)

Each destination pipeline has an entry-condition which has to be met before an event is inserted into the pipeline. Maybe you can imagine it like a bouncer in front of a club. The default condition for each pipeline is true, so every event can get into the pipeline.

2789_0_img_20170228_085913

How might this look in a pipeline.conf file?

    "parser": {
        "source-queue": "parser-queue",
        "destination-queues": {
            "expert1-queue": "if event.get(\"source.cc\") = \"DE\""
            "expert2-queue": "if event.get(\"source.cc\") != \"DE\""
        }
    },
    "expert2": {
        "source-queue": "expert2-queue",
        "destination-queues": {
            "another-expert-queue": true
            "yet-another-expert-queue": true
        }
    },

Problems:

  1. This allows the execution of arbitrary code from the *.conf files, if a programming language like python is used instead of a rule-language.

Questions:

  1. What happens to bounced events?

Originally posted by @dmth in #569 (comment)

@ghost ghost changed the title **Idea:** What about using **Conditioned Pipelines** additional to filters? Conditioned Pipelines additional to filters? Aug 15, 2019
@ghost ghost added this to the 2.1.0 milestone Aug 15, 2019
@ghost
Copy link
Author

ghost commented Aug 15, 2019

In order to not use python code in the configuration we could use the sieve's bot syntax and it's capabilities

@e3rd
Copy link
Member

e3rd commented Sep 3, 2019

That would effectively solve use case of MaltaCIP. :) They have a file collector that receives all shadowserver files in a directory whose contents should be divided into shadowserver parsers. I advised to use a sieve bot that will distribute events to according parsers. But as an expert, sieve cannot be placed between collector and parsers.

(Could you please remind me of the reason why expert can't be placed next to a collector, link me to the discussion? o:) I was searching on both intelmq and manager trackers but with no luck.)

@ghost
Copy link
Author

ghost commented Sep 3, 2019

That would effectively solve use case of MaltaCIP. :) They have a file collector that receives all shadowserver files in a directory whose contents should be divided into shadowserver parsers.

Haven't heard of that issue yet. But we can solve that use case differently. Namely by providing the file name in the report as extra.file_name and then using the field in the parser to determine the type of feed. HTTP, RT and Mail collectors already save this kind of information in the report, I'll add it for the file collector now. For the required changes in the shadowserver parser I opened #1442

I advised to use a sieve bot that will distribute events to according parsers. But as an expert, sieve cannot be placed between collector and parsers.

(Could you please remind me of the reason why expert can't be placed next to a collector, link me to the discussion? o:) I was searching on both intelmq and manager trackers but with no luck.)

That limitation does only exists in the GUI, if you just configure it, it works fine. Maybe some experts require fields only existing in events, but that could always be the case.

@ghost ghost modified the milestones: 2.1.0, 2.2.0 Oct 25, 2019
@ghost ghost removed this from the 2.2.0 milestone Jun 17, 2020
@sebix sebix changed the title Conditioned Pipelines additional to filters? Conditional Pipelines additional to filters? Feb 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant