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

Disabled YARA sources are still used #327

Open
kam193 opened this issue Feb 24, 2025 · 3 comments
Open

Disabled YARA sources are still used #327

kam193 opened this issue Feb 24, 2025 · 3 comments
Assignees
Labels
accepted This issue was accepted, we will work on this at some point bug Something isn't working ui-frontend

Comments

@kam193
Copy link

kam193 commented Feb 24, 2025

Describe the bug
I've recently tried a new set of YARA rules, but after a few days I decided that it looks too big and causes timeouts. I wanted to pause using it until I find time to better select useful rules from it. I decided to disable the update source, but I'm still getting hits from this ruleset (after a day since disabling it).

To Reproduce
Steps to reproduce the behavior:

  1. Have a YARA ruleset and let it first sync.
  2. Disable the ruleset.
  3. Upload a file that is expected to trigger one of the rules from the disables source. To ensure rules sync, you can repeat it a few times.
  4. See that rules are triggered.

Expected behavior
When I disable a source, I do not expect related rules to be used at all. However, it looks like disabling YARA rules disables just updating it.

My theory is that disabled rules are ignored from generating the new rules file for the service etc., but already generated files are still present and never deleted.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information if pertinent):

  • Assemblyline Version: 4.5.0.76, YARA 4.5.0.35

Additional context

@kam193 kam193 added assess We still haven't decided if this will be worked on or not bug Something isn't working labels Feb 24, 2025
@cccs-rs cccs-rs self-assigned this Feb 24, 2025
@cccs-rs
Copy link
Contributor

cccs-rs commented Feb 24, 2025

This one would be a bit tricky as the the original intention of the feature was to prevent downloads that we know will fail (ie. expired authentication). Mostly because it's possible you still want to use the rules for detection even though you can't get any new rules because the source is failing for XYZ reason.

We could add a secondary action to the UI that can prompt "Do you want to disable all signatures under the source as well?" and that will update the state of the signatures in the Signature page.

A more general approach would be a way to select multiple signatures (either manual or by query) in the UI and update the state of them all at once (but I don't think our search table component supports something like that atm 😅)

@kam193
Copy link
Author

kam193 commented Feb 24, 2025

Ahh, so it's partially my misunderstanding. I'd then suggest renaming it to "disable updating" and then thinking, in the future, if disabling using the source would also be in scope. I think it would be nice, but I have also realised that we would then need to somehow present in the signatures view, that they have been disabled because of disabling the source. And it should not be the same as just disabling because I'd expect them to come back after re-enabling source: But only those, which have been disabled because of disabling the source (not signatures that have been manually disabled).

A more general approach would be a way to select multiple signatures (either manual or by query) in the UI and update the state of them all at once (but I don't think our search table component supports something like that atm 😅)

Ah yeah, I did looked for that a few times :)

@cccs-rs cccs-rs added ui-frontend accepted This issue was accepted, we will work on this at some point and removed assess We still haven't decided if this will be worked on or not labels Feb 24, 2025
@cccs-rs
Copy link
Contributor

cccs-rs commented Feb 24, 2025

Will be included in this PR with other UI-related fixes: CybercentreCanada/assemblyline-ui-frontend@0fa0b12

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted This issue was accepted, we will work on this at some point bug Something isn't working ui-frontend
Projects
None yet
Development

No branches or pull requests

2 participants