Feature #1828
closedYARA support
Updated by Victor Julien over 8 years ago
- Subject changed from YA to YARA support
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to TBD
"The pattern matching swiss knife for malware researchers (and everyone else)" http://virustotal.github.io/yara/
License recently changed to BSD: https://github.com/VirusTotal/yara/commit/3a53f063c6ccd4849c6b8c58979bf3b609f881e6
It would be nice to support YARA rules to be applied to the file tracking/extraction in Suricata.
Updated by Victor Julien almost 8 years ago
- Status changed from Assigned to New
- Assignee changed from Victor Julien to Anonymous
Updated by Victor Julien almost 7 years ago
- Status changed from New to Assigned
- Assignee changed from Anonymous to Ingve Skåra
Updated by Victor Julien almost 7 years ago
- Related to Task #2309: SuriCon 2017 brainstorm added
Updated by Raymond Hansen about 6 years ago
Discussion at SuriCon 2018 resulted in decision to not pursue this at this time.
Updated by Victor Julien about 5 years ago
- Status changed from Assigned to New
- Assignee changed from Ingve Skåra to Community Ticket
Updated by Victor Julien about 5 years ago
- Status changed from New to Rejected
- Assignee deleted (
Community Ticket) - Target version deleted (
TBD)
We decided over several discussions that we consider this out of scope for Suricata. I realize this may be disappointing especially to people of have already spent time on this. Our own views on this have shifted over time.
Some of the reasons are:
1. yara's concept of what a reasonable time to inspect is not in line with how Suricata works. Suricata threads can't block for long which is very different from yara which can take a much larger time budget
2. we got feedback that the libyara was too fragile to be used safely. I have no further details on this. In general we'd like to move to using Rust only for untrusted input.
3. file analysis frameworks that are in the post-processing pipeline running on data that suricata produces are a better location for yara or other expensive file analysis methods.
Updated by Simon Hardy-Francis about 4 years ago
FYI I'm currently in the process of getting a PR accepted by YARA which would very much change the types of scanning scenarios in which libyara can operate.
Instead of having to have all the blocks of a file to scan present (and then blocking while scanning the entire file), the change enables a single thread calling libyara to incrementally scan multiple files as their next blocks become available (via the network?).
This new functionality may or may not result in you guys wanting to re-open this ticket, but I thought it maybe worth mentioning :-)