Bug #2483
closedfilemd5 rule blocks/alerts on files not in the list ..
Description
I have been trying to debug this issue for a while, but so far I'm have not been able to pinpoint the root cause, so maybe someone else is seeing this as well?
I have a rule that uses a blacklist (filemd5:blacklist.md5) this works for most of the time flawless, but at times it starts to block/alert on files that are not in the blacklist.
One thing that I could map it against, is during long runs (no reboots), just a lot of restarts of Suricata, that the issue seems to resurface (as it's the only way known to be that enables you to update the hash list used in the rule), but that's just a guess.
Another things that "seems" strange is that they eve log payload for the said alerts is not valid base64 (I log the payload in the base64 format), other "proper" IDS alerts have decodable payload.
So any thoughts about this issue?
https://redmine.openinfosecfoundation.org/issues/2015 that "glongo" has been working on would shed some more insight as it also logs the checksum that Suricata believes it's seeing in the eve log, but it does not solve the underlaying issue ..
OS: Ubuntu 16.04
Suricata: 4.0.4
Updated by Peter Manev over 6 years ago
Is it possible to share a reproducible case or pcap?
Are you using the Ubuntu PPAs or your own compiled version of Suricata?(ips/ids mode?)
Updated by Mikael Keri over 6 years ago
Thank you Peter for getting back to me!
As I mention, I did see this kind of behaviour for a while without getting a sense on what's triggered it. When I wrote the ticket I finally I thought that I had a easy reproducible item that triggered the occurrence. Sadly that case ended up being a fault on my side. So you can go a head and close this one, if the "bug" resurface I will open a new case with some more background data.
But the second part with the payload not being valid base64, that "issue" played well into my wild goose chase. But that case is easy to re-produce, with the following steps :
- Put Suricata in IPS mode
- Enable eve logging with base64 payload set to enabled (payload: yes)
- Include the rule file for the below rule in suricata.yaml
- Create and activate a rule like this: drop http any any -> any any (msg:"Blacklisted File Blocked"; flow:established; filemd5:bl.md5; classtype:misc-activity; sid:666; rev:1;)
- Hash a file that you can upload to your monitored asset
- Include the file hash in the bl.md5 file
- Restart or start Suricata
The eve alert should be generated with a payload, base64 decode it. In my tests payloads for all other alerts are valid base64 but not for this type. This could of course have more to do with the drop keyword then filemd5..
I'm using your PPA in IPS mode (NFQUEUE)
Sorry for wasting your time on this..
Updated by Peter Manev over 6 years ago
- Status changed from New to Closed
Closing as requested as per the bug description relevance.
@Mikael - can you please open another ticket for the base64 stuff with the explanation/step by step process you mentioned.
It would be even more helpful if you could share a reproducible pcap (was thinking if it is easy to reproduce with "--simulate-ips")