Bug #2688
closed
filemd5 files are not migrated /w rules
Added by Kenneth Kolano over 5 years ago.
Updated over 3 years ago.
Description
When rules using a filemd5 directive are imported the rules are migrated to /var/lib/suricata/rules/suricata.rules, but the related files are left in their original location (likely /etc/suricata/rules), which breaks the references.
alert http any any -> $HOME_NET any (msg:"OTX - FILE MD5 from pulse Threats Targeted against Civil Society"; filemd5:5bedad78bb5ab60a53de19a4.txt; reference: url, otx.alienvault.com/pulse/5bedad78bb5ab60a53de19a4; sid:411683; rev:1;)
Referenced files should be migrated along with their related rules.
To work around this I currently run the following command prior to Suricata-Update to generate hard links on relevant files between the two locations:
sudo cp -l /etc/suricata/rules/???????????*.txt /var/lib/suricata/rules
Files
- Assignee changed from Jason Ish to Shivani Bhardwaj
- Target version set to TBD
- Status changed from New to Assigned
@Kenneth Kolano: Are you able to provide us with an example of this ruleset (how the md5 file is put in the tarball for example). Private is OK, we can use it to craft some test cases with no private info in them.
Thanks.
Sorry for my delayed response here.
The default OTX ruleset (as generated by this tool: https://github.com/AlienVault-OTX/OTX-Suricata) would be relevant. I provided an example rule above. There is no tarball, just a rules file, and series of text files with MD5 hashes. I've attached a complete rules file here and an example of one of the MD5 txt files.
- Blocks Bug #2691: Error thrown with -o option added
- Target version changed from TBD to 1.2.0
- Priority changed from Normal to High
- Related to Bug #3528: dataset files are not migrated /w rules added
- Status changed from Assigned to In Review
- Status changed from In Review to Closed
- Target version changed from 1.2.0 to 1.2.0rc1
Also available in: Atom
PDF